Улучшение ответов RAG: по одному измеримому изменению за раз

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

Сначала рассматривайте плохие ответы как проблемы с поиском контекста

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

Делайте фрагментацию по смысловым границам

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

Настройте параметр top_k вместо того, чтобы угадывать его значение

Многие системы извлекают пять наиболее похожих фрагментов просто потому, что пять — это распространённый стандартный значение. Однако правильный отрывок может находиться на шестой или седьмой позиции. Увеличение значения top_k может улучшить точность воспроизведения информации, но каждый дополнительный фрагмент также добавляет шум и токены в запрос. Рассматривайте top_k как параметр, который необходимо тестировать с учётом ваших собственных вопросов, а не как константу, которую следует копировать. Ещё одним вариантом являются пороги релевантности, о которых говорится в статье «Выход за рамки top-k: пороги релевантности, гибридный поиск и переранжирование».

Добавление этапа переранжирования

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

Сочетание семантического и поиска по ключевым словам

Эмбеддинги хорошо передают смысл, но иногда конкретные токены важнее, чем смысл. Запрос вроде ERROR_CODE_4291 содержит мало семантической информации, поэтому поиск по сходству может пропустить документ, в котором он упоминается. Методы ранжирования по ключевым словам, такие как BM25, хорошо справляются с подобными случаями. Поэтому многие системы используют одновременно векторный и поиск по ключевым словам, объединяя результаты, что называется гибридным поиском.

Преодоление пробела в словарном запасе запросов

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

Оценка каждого изменения по базовому уровню

Самая важная привычка — не делать поспешных выводов. Фраза «Мы добавили механизм переранжирования, поэтому качество поиска улучшилось» является гипотезой до тех пор, пока она не будет проверена. Составьте небольшой набор реальных вопросов с известными соответствующими фрагментами текста, затем отслеживайте такие показатели, как:

• Recall@K: присутствует ли правильная информация среди первых K найденных фрагментов.

Точность контекста: насколько полученный контекст был действительно полезен.

Верность: остается ли ответ основан на полученном контексте.

Релевантность ответа: отвечает ли ответ на поставленный вопрос.

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

Baseline Recall@5: 68%

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

Better chunking: 74%
Hybrid search: 82%
Reranking: 89%

Эти цифры — пример, а не эталон; ваши собственные данные будут отличаться. Суть в том, что журнал изменений позволяет определить, какой шаг привёл к увеличению сложности, а какой — нет. Для более подробного рассмотрения способов выявления сбоев см. оценку RAG по стадиям сбоев.

Заключение

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