Сначала встраивание, потом расчленение: Более разумный поиск по RAG с помощью Max-Min семантического расчленения

ТехнологияRetrieval Augmented Generation (RAG) стала стандартным подходом к обеспечению контекста и памяти для приложений ИИ - на нее полагаются агенты ИИ, ассистенты поддержки клиентов, базы знаний и поисковые системы.

Почти в каждом конвейере RAG стандартный процесс одинаков: берем документы, разбиваем их на фрагменты, а затем встраиваем эти фрагменты для поиска по сходству в векторную базу данных, например Milvus. Поскольку разбивка происходит заранее, качество этих фрагментов напрямую влияет на то, насколько хорошо система извлекает информацию и насколько точными получаются конечные ответы.

Проблема заключается в том, что традиционные стратегии разбиения на куски обычно разбивают текст без какого-либо семантического понимания. При разбиении текста на куски фиксированной длины учитывается количество лексем, а при рекурсивном разбиении используется структура поверхностного уровня, но в обоих случаях не учитывается реальный смысл текста. В результате связанные идеи часто оказываются разделенными, несвязанные строки - сгруппированными, а важный контекст - разрозненным.

В этом блоге я хочу рассказать о другой стратегии разбиения текста на части: Max-Min Semantic Chunking. Вместо того чтобы сначала разбивать текст на куски, она встраивает его в текст и использует семантическое сходство, чтобы решить, где должны формироваться границы. Благодаря встраиванию перед разрезанием, конвейер может отслеживать естественные изменения смысла, а не полагаться на произвольные ограничения по длине.

Принцип работы типичного конвейера RAG

Большинство конвейеров RAG, независимо от фреймворка, следуют одному и тому же четырехэтапному конвейеру. Вероятно, вы и сами написали какую-то версию этого конвейера:

1. Очистка и разбивка данных

Конвейер начинается с очистки исходных документов: удаляются заголовки, нижние колонтитулы, навигационный текст и все, что не является реальным содержимым. Как только шум удален, текст разбивается на более мелкие фрагменты. Большинство команд используют фрагменты фиксированного размера - обычно 300-800 лексем, - поскольку это позволяет сделать модель встраивания управляемой. Недостатком является то, что разбиение происходит по длине, а не по смыслу, поэтому границы могут быть произвольными.

2. Встраивание и хранение

Затем каждый чанк встраивается с помощью модели встраивания, например, OpenAI text-embedding-3-small или кодировщика BAAI. Полученные векторы хранятся в базе данных векторов, например Milvus или Zilliz Cloud. База данных обрабатывает индексацию и поиск сходства, чтобы вы могли быстро сравнивать новые запросы со всеми сохраненными чанками.

3. Запрос

Когда пользователь задает вопрос - например, "Как RAG уменьшает галлюцинации?" - система встраивает запрос и отправляет его в базу данных. База данных возвращает топ-K фрагментов, чьи векторы наиболее близки к запросу. Именно на эти фрагменты текста будет опираться модель при ответе на вопрос.

4. Генерация ответа

Полученные фрагменты объединяются с запросом пользователя и поступают в LLM. Модель генерирует ответ, используя предоставленный контекст в качестве основы.

Чанкинг находится в самом начале всего этого конвейера, но он имеет огромное влияние. Если фрагменты соответствуют естественному смыслу текста, поиск будет точным и последовательным. Если же фрагменты были вырезаны в неудобных местах, системе будет сложнее найти нужную информацию, даже при наличии сильных вкраплений и быстрой векторной базы данных.

Трудности правильного использования чанков

Большинство систем RAG сегодня используют один из двух основных методов разбиения на куски, оба из которых имеют свои ограничения.

1. Куски фиксированного размера

Это самый простой подход: разбиение текста по фиксированному количеству лексем или символов. Он быстр и предсказуем, но совершенно не учитывает грамматику, темы и переходы. Предложения могут сокращаться вдвое. Иногда даже слова. Вложения, которые вы получаете из этих кусков, как правило, шумные, потому что границы не отражают реальную структуру текста.

2. Рекурсивное разбиение символов

Этот метод немного умнее. Он делит текст на иерархические части, основываясь на таких признаках, как абзацы, переносы строк или предложения. Если раздел слишком длинный, он рекурсивно делит его дальше. В целом результат получается более последовательным, но все равно непоследовательным. Некоторые документы не имеют четкой структуры или имеют неравномерную длину разделов, что снижает точность поиска. А в некоторых случаях этот подход все равно выдает фрагменты, которые превышают контекстное окно модели.

Оба метода сталкиваются с одним и тем же компромиссом: точность против контекста. Маленькие фрагменты повышают точность поиска, но теряют окружающий контекст; большие фрагменты сохраняют смысл, но рискуют добавить нерелевантный шум. Нахождение правильного баланса - это то, что делает куски одновременно основополагающими и разочаровывающими при разработке систем RAG.

Максимально-минимальный семантический чанкинг: Сначала встроить, потом разбить

В 2025 году С.Р. Бхат и др. опубликовали статью Rethinking Chunk Size for Long-Document Retrieval: A Multi-Dataset Analysis. Один из ключевых выводов, к которому они пришли, заключается в том, что не существует единого "оптимального" размера куска для RAG. Маленькие куски (64-128 лексем), как правило, лучше работают с фактологическими вопросами или вопросами типа поиска, в то время как большие куски (512-1024 лексем) помогают при решении задач повествования или высокоуровневых рассуждений. Другими словами, разбивка на части фиксированного размера - это всегда компромисс.

В связи с этим возникает естественный вопрос: вместо того чтобы выбирать одну длину и надеяться на лучшее, можем ли мы разбивать фрагменты по смыслу, а не по размеру? Max-Min Semantic Chunking - один из найденных мною подходов, который пытается сделать именно это.

Идея проста: сначала встраиваем, потом разбиваем. Вместо того чтобы разбивать текст на части, а затем встраивать все выпавшие куски, алгоритм встраивает все предложения вперед. Затем он использует семантические связи между этими вложениями предложений, чтобы решить, где должны проходить границы.

Диаграмма, показывающая рабочий процесс embed-first chunk-second в Max-Min Semantic Chunking

С концептуальной точки зрения, метод рассматривает разбиение на части как ограниченную задачу кластеризации в пространстве вкраплений. Вы проходите документ по порядку, по одному предложению за раз. Для каждого предложения алгоритм сравнивает его вложения с вложениями в текущем куске. Если новое предложение достаточно близко по семантике, оно присоединяется к куску. Если оно слишком далеко, алгоритм начинает новый чанк. Ключевым ограничением является то, что чанки должны следовать оригинальному порядку предложений - никакого переупорядочивания, никакой глобальной кластеризации.

В результате получается набор фрагментов переменной длины, которые отражают те места, где смысл документа действительно меняется, а не те, где счетчик символов случайно достиг нуля.

Принцип работы стратегии Max-Min Semantic Chunking

Max-Min Semantic Chunking определяет границы фрагментов, сравнивая, как предложения соотносятся друг с другом в высокоразмерном векторном пространстве. Вместо того чтобы полагаться на фиксированную длину, он смотрит на то, как меняется смысл в документе. Процесс можно разбить на шесть этапов:

1. Встраивание всех предложений и создание фрагмента

Модель встраивания преобразует каждое предложение в документе в векторное вложение. Она обрабатывает предложения по порядку. Если первые n-k предложений образуют текущий чанк C, то следующее предложение (sₙ₋ₖ₊₁) должно быть оценено: должно ли оно присоединиться к C или начать новый чанк?

2. Измерьте, насколько последовательным является текущий чанк.

Внутри чанка C рассчитайте минимальное парное косинусное сходство между всеми вкраплениями предложений. Это значение отражает, насколько тесно связаны между собой предложения в этом блоке. Более низкое минимальное сходство указывает на то, что предложения менее связаны между собой, что говорит о необходимости разделения блока.

3. Сравните новое предложение с фрагментом.

Далее рассчитайте максимальное косинусное сходство между новым предложением и любым предложением, уже содержащимся в C. Это отражает, насколько хорошо новое предложение семантически соответствует существующему блоку.

4. Решите, стоит ли расширять чанк или начинать новый.

Это основное правило:

• Если максимальное сходство нового предложения с чанком C больше или равно минимальному сходству внутри C, → новое предложение вписывается в чанк и остается в нем.

• В противном случае → начинаем новый чанк.

Это гарантирует, что каждый чанк сохраняет внутреннюю семантическую согласованность.

5. Регулировка пороговых значений по мере изменения документа

Для оптимизации качества чанков такие параметры, как размер чанка и пороги сходства, можно динамически корректировать. Это позволяет алгоритму адаптироваться к изменяющимся структурам документов и семантической плотности.

6. Обработка первых нескольких предложений

Если чанк содержит только одно предложение, алгоритм обрабатывает первое сравнение, используя фиксированный порог сходства. Если сходство между предложением 1 и предложением 2 выше этого порога, они образуют чанк. Если нет, они сразу же разделяются.

Сильные и слабые стороны семантического разбиения по методу Max-Min

Max-Min Semantic Chunking улучшает работу систем RAG по разбиению текста, используя смысл вместо длины, но это не серебряная пуля. Вот практический взгляд на то, что он делает хорошо, и на то, где он все еще не работает.

Что он делает хорошо

Max-Min Semantic Chunking улучшает традиционную разбивку на части тремя важными способами:

1. Динамические, управляемые смыслом границы чанков

В отличие от подходов, основанных на фиксированном размере или структуре, этот метод опирается на семантическое сходство для определения границ кусков. Он сравнивает минимальное сходство внутри текущего куска (насколько он связный) с максимальным сходством между новым предложением и этим куском (насколько хорошо оно вписывается). Если последний показатель выше, предложение присоединяется к куску, в противном случае начинается новый кусок.

2. Простая и практичная настройка параметров

Алгоритм зависит всего от трех основных гиперпараметров:

• максимальный размер куска,

• минимальное сходство между первыми двумя предложениями и

• порог сходства для добавления новых предложений.

Эти параметры настраиваются автоматически в зависимости от контекста - для сохранения связности большие куски требуют более жестких порогов сходства.

3. Низкие накладные расходы на обработку

Поскольку конвейер RAG уже вычисляет вкрапления предложений, Max-Min Semantic Chunking не требует больших вычислений. Все, что ему нужно, - это набор проверок косинусного сходства при сканировании предложений. Это делает его дешевле многих методов семантического расщепления, требующих дополнительных моделей или многоступенчатой кластеризации.

Что она все еще не может решить

Max-Min Semantic Chunking улучшает границы фрагментов, но не устраняет все проблемы сегментации документов. Поскольку алгоритм обрабатывает предложения по порядку и кластеризует только локально, он все равно может упустить дальние связи в длинных или более сложных документах.

Одна из распространенных проблем - фрагментация контекста. Когда важная информация распределена по разным частям документа, алгоритм может поместить эти части в отдельные куски. При этом каждый кусок несет в себе лишь часть смысла.

Например, в примечаниях к выпуску Milvus 2.4.13, как показано ниже, один фрагмент может содержать идентификатор версии, а другой - список функций. Запрос типа "Какие новые функции были представлены в Milvus 2.4.13?" зависит от обоих. Если эти сведения разделены по разным фрагментам, модель встраивания может не связать их, что приведет к ухудшению поиска.

• Пример фрагментации контекста в Milvus 2.4.13 Release Notes с идентификатором версии и списком функций в отдельных фрагментах

Эта фрагментация также влияет на этап генерации LLM. Если ссылка на версию находится в одном чанке, а описание характеристик - в другом, модель получает неполный контекст и не может точно определить взаимосвязь между ними.

Для смягчения последствий таких случаев системы часто используют такие техники, как скользящие окна, перекрывающиеся границы чанков или многопроходное сканирование. Эти подходы позволяют восстановить часть недостающего контекста, уменьшить фрагментацию и помочь этапу поиска сохранить связанную информацию.

Заключение

Max-Min Semantic Chunking не является волшебным решением всех проблем RAG, но он дает нам более разумный способ думать о границах фрагментов. Вместо того чтобы позволять ограничениям на лексемы решать, где идеи будут измельчаться, он использует вкрапления, чтобы определить, где смысл действительно меняется. Для многих реальных документов - API, спецификаций, журналов, заметок о выпуске, руководств по устранению неполадок - только это может заметно повысить качество поиска.

Что мне нравится в этом подходе, так это то, что он естественно вписывается в существующие конвейеры RAG. Если вы уже внедряете предложения или абзацы, дополнительные затраты сводятся к нескольким проверкам косинусного сходства. Вам не нужны дополнительные модели, сложная кластеризация или тяжелая предварительная обработка. И когда этот метод работает, создаваемые им фрагменты кажутся более "человеческими" - более близкими к тому, как мы мысленно группируем информацию при чтении.

Но у метода все еще есть "слепые пятна". Он видит смысл только локально и не может соединить информацию, которая намеренно разнесена в разные стороны. Перекрывающиеся окна, многопроходное сканирование и другие трюки, сохраняющие контекст, все еще необходимы, особенно для документов, где ссылки и объяснения находятся далеко друг от друга.

Тем не менее, Max-Min Semantic Chunking двигает нас в правильном направлении: от произвольной нарезки текста к поисковым конвейерам, которые действительно уважают семантику. Если вы изучаете способы сделать RAG более надежным, с этим стоит поэкспериментировать.

У вас есть вопросы или вы хотите глубже изучить вопрос повышения производительности RAG? Присоединяйтесь к нашему Discord и общайтесь с инженерами, которые каждый день создают и настраивают реальные поисковые системы.