Поиск и оценка в рамках RAG: почему для извлечения информации требуется отдельный этап повторной ранжировки
RAG требует механизма поиска и оценки: эмбеддинги находят кандидатов, но не могут определить их релевантность. Используется двухэтапная структура с RRF, кросс-энкодерами, ColBERT и моделями LLM для переориентации ранжирования.
Многие команды сталкиваются с одинаковыми проблемами при использовании генерации с усилением на основе поиска. На доске объяснений всё выглядит просто: вводится запрос, сопоставляются векторы, лучшие результаты передаются в модель, и получается ответ. Однако в реальных условиях быстро появляются проблемы: упускаются релевантные документы, проникают нерелевантные фрагменты, небольшая изменение формулировки вопроса меняет ответ, а галлюцинации сохраняются даже тогда, когда поиск, казалось бы, сработал.
Обычным решением является замена модели эмбеддингов на более совершенную, увеличение размерности векторов или настройка параметров top-k и размера фрагментов. Такие действия разумны, но они касаются не той части проблемы. Коренная причина кроется в архитектуре: традиционная схема поручает одному механизму — сравнению сходства эмбеддингов — выполнять две совершенно разные задачи: находить кандидатов и определять, какие из них важны.
Решение заключается в разделении задач. Используйте поиск по шаблонам и оценку: двухэтапная схема, при которой генерация кандидатов и оценка их релевантности являются отдельными инженерными задачами, решаемыми с помощью отдельных инструментов.
Почему одной лишь схожести недостаточно
Примитивный подход RAG преобразует запрос в векторное представление, извлекает K наиболее близких фрагментов из базы знаний, вставляет их рядом с вопросом и позволяет модели дать ответ. Неявным предположением здесь является то, что близость равносильна релевантности, поэтому список K наиболее близких фрагментов принимается без какой-либо проверки. При этом возникают четыре проблемы.
Похожее не всегда означает релевантное. Расстояние вживления является приблизительным показателем тематической близости. Два отрывка могут находиться рядом друг с другом, но один из них не обязательно отвечает на вопрос, поставленный другим. Текст с рекомендациями по лечению гипертонии и текст о методологии тестирования кардиоваскулярных препаратов могут располагаться рядом, однако только первый может помочь человеку, принимающему решение о лечении пациента.
Порядок расположения ненадежен. Векторное расстояние представляет собой эвристику, а не функцию ранжирования, предназначенную для отражения степени релевантности. Разница между третьим и седьмым результатами в ранжировании по коэффициенту косинуса часто является шумом.
Контекст разрывается на фрагменты. Разбиение текста на части нарушает взаимосвязи, иерархию и причинно-следственные связи. Фрагмент, описывающий дозировку, может оказаться отдельно от фрагмента с информацией о противопоказаниях, и ни один из них сам по себе не является полным.
Результаты нестабильны. Небольшие изменения формулировок могут привести к смене набора элементов из группы top-K. Запросы о побочных эффектах метформина и о нежелательных реакциях на него могут дать разные кандидаты, и окончательный ответ может изменяться в зависимости от этого. Это недостаток надежности, а не деталь настройки.
Короче говоря, поиск предоставляет кандидатов, но не гарантирует их корректности.
Двухэтапная схема
Вместо одной системы, которая одновременно находит и оценивает, создайте два этапа, каждый из которых настраивается под свою цель.
Первый этап — поиск, предполагает использование широкого диапазона критериев. Выбирают примерно от 50 до 200 кандидатов, что во много раз больше, чем модель сможет обработать, поскольку здесь важна полнота покрытия. Достаточно, чтобы нужные документы находились где-то в этом наборе, даже если он содержит много лишней информации.
Второй этап, уважаемый судья, предусматривает гораздо более строгий критерий оценки. Обычно это кросс-кодер-реранкер, который совместно анализирует запрос и каждый из кандидатов, вычисляя реальный показатель релевантности. Он сокращает список до пяти-десяти фрагментов с высокой степенью достоверности. Только затем собранный контекст передается языковой модели.
Что на самом деле вносят эмбеддинги
Неправильное понимание роли эмбеддингов приводит к тому, что команды слишком сильно на них полагаются. Представьте библиотекаря, который не читает каждую книгу, но присваивает каждой несколько ключевых тем. Когда поступает вопрос, библиотекарь преобразует его в аналогичные теги и выбирает книги, теги которых наиболее соответствуют. Это быстро и обычно позволяет найти что-то полезное, но такой подход основан на поверхностных темах, а не на глубоком понимании, поэтому некоторые книги могут быть связаны с вопросом, но не соответствовать его истинным потребностям.
Последствие: ваша модель эмбеддингов определяет поведение поиска. Она решает, что будет найдено, а что — пропущено. Она не определяет, что является правильным, и именно это — задача этапа оценки.
Поэтому выбор модели эмбеддингов — это решение, связанное с показателем воспроизводимости. Вы выбираете способ, с помощью которого первый этап будет анализировать корпус данных. Учитывайте такие критерии, как показатели воспроизводимости, такие как MTEB и BEIR, охват языков, размер модели в сравнении с вашим оборудованием, размер векторов, максимальную длину входных данных и скорость обработки. Все это связано с показателем воспроизводимости.
Варианты роли оценщика и ситуации их применения
Роль оценщика существует в архитектуре. Её может выполнять несколько реализаций, при этом существуют различия в точности, задержке, сложности и стоимости.
Слияние рангов по принципу взаимности
RRF вообще не оценивает релевантность. Он объединяет ранжированные списки из нескольких источников, например поиска по ключевым словам и семантического поиска, в один порядок. Для каждого документа он добавляет значение 1 / (k + ранг) по всем спискам, где k — константа, обычно равная 60, которая снижает влияние документов, занимающих самые высокие позиции. Документы, которые занимают высокие позиции в нескольких списках, поднимаются в рейтинге.
Этот метод быстр, детерминистичен, не требует инференса модели и практически не добавляет задержек. Поскольку он использует позиции в ранжировании, а не сырые оценки, он избегает несоответствия между оценками BM25 и косинусными сходствами, поэтому нормализация не требуется.
Его ограничение заключается в том, что он учитывает лишь согласованность. Если несколько поисковых агентов считают документ важным, RRF предполагает, что он действительно таков. Это разумная гистеретическая стратегия, но всё же она остаётся гистеретической. Он не может найти релевантный документ, который проигнорировали все поисковые агенты, и не может отличить документ, тематически связанный с запросом, от документа, который действительно отвечает на вопрос.
Используйте его для гибридного поиска, когда вам нужен простой способ объединения списков. Он применяется на этапе поиска для улучшения списка кандидатов, но не заменяет человека-оценщика.
Кросс-кодеры
Кросс-энкодер передаёт запрос и один из кандидатов в модель в виде объединённой последовательности и возвращает оценку релевантности. Би-энкодеры закодируют запрос и документ отдельно друг от друга, тогда как здесь каждый токен вопроса может взаимодействовать с каждым токеном текста. Таким образом модель может анализировать, как конкретные фразы в вопросе связаны с конкретными фразами в тексте. Типичными примерами являются модели Sentence Transformers, такие как cross-encoder/ms-marco-MiniLM-L-12-v2, сервисы для переранкинга и кросс-энкодеры, отрегулированные на медицинских, юридических или научных данных.
Их сильная сторона — точность. На тестовых площадках для оценки ранкинга они обычно превосходят другие подходы, поскольку способны улавливать тонкие взаимодействия, которые невозможно определить с помощью сходства эмбеддингов. Это ближайшее к способу определения того, действительно ли документ отвечает на вопрос, без использования полноценной модели LLM.
Стоимость заключается в отдельной обработке каждой пары запроса и кандидата. Набор из 100 документов означает 100 запусков модели на каждый запрос, поэтому задержка растет линейно с размером набора, а более крупные модели усугубляют ситуацию.
Они являются стандартным выбором там, где в первую очередь важен качество ответа: в сфере здравоохранения, права, соблюдения нормативов, финансового анализа — в любом месте, где неверный поиск имеет серьезные последствия. Если бюджет на задержку позволяет примерно 50–200 миллисекунд на переранжирование, что позволяют большинство нереальных времени систем, начните с них.
ColBERT и поздняя интеракция
ColBERT, сокращение от contextualized late interaction over BERT, находится между би-кодерами и кросс-кодерами. Он независимо кодирует запрос и документ в векторы по токенам, затем оценивает их путем сопоставления токенов запроса с токенами документа. Поскольку векторы документов могут быть предварительно вычислены, его использование во время обработки запроса значительно дешевле, чем у кросс-кодера, при этом он сохраняет больше деталей, чем один объединенный вектор. Недостатком является увеличение размера индекса, поскольку каждому токену требуется свой вектор. Он подходит для систем, которым нужна лучшая классификация, чем у обычных эмбеддингов, и которые требуют более высокой пропускной способности, чем позволяют кросс-кодеры.
Языковая модель в роли судьи
Общая модель языка может напрямую оценивать кандидатов. Она способна учитывать тонкие аспекты многократной релевантности, например, понимать, что документ о взаимодействии лекарств связан с вопросом о безопасности лечения, даже если их лексика не пересекается. Кроме того, она может следовать явным критериям релевантности, указанным в запросе, что позволяет ей адаптироваться к доменно-специфическому пониманию релевантности.
Это также, безусловно, самый дорогой вариант. Один вызов для переоценки может занять от одной до пяти секунд и стоить в десять–сто раз дороже, чем один проход через кросс-кодер. Оценки могут различаться при разных запусках, а модели демонстрируют смещение в пользу документов, указанных ранее в запросе. Модели, размещаемые на серверах, создают дополнительную внешнюю зависимость.
Это имеет смысл в двух сценариях: офлайн-режиме или при обработке пакетных задач, где задержка не имеет значения, например при создании тщательно отобранных баз знаний, оценке процесса поиска во время разработки или генерации обучающих данных для специализированного инструмента переупорядочивания результатов; а также в инструментах с высокой степенью важности, но небольшим объемом данных, где ценность правильного ответа оправдывает затраты на обработку каждого запроса, например при проведении исследований в медицине или юриспруденции на уровне экспертов.
Выбор моделей для каждого этапа
Понимание закономерностей — это одно, а выбор моделей — другое. Архитектура предоставляет два варианта выбора, каждый из которых определяется характером задачи.
Начните с задачи
Ответы на клинические вопросы, анализ документов и соблюдение нормативных требований требуют разных подходов. Проверка качества требует высокой точности при небольшом объеме данных. Анализ документов ценит широту охвата и разнообразие информации. Соблюдение нормативов требует детерминистичного поиска с возможностью аудита и минимальным количеством ложноотрицательных результатов. Характер задачи определяет все последующие решения.
Модель вживления задает верхний предел воспроизводимости
Она определяет, что система может найти до того, как вступит в дело человек-эксперт. Релевантный документ, который так и не попадает в список кандидатов, невозможно восстановить с помощью любого алгоритма переупорядочивания. Сравнивайте кандидатов по следующим критериям:
- Эталонные показатели. Обратите внимание на результаты MTEB и BEIR для типа задачи, ближайшего к вашему, такого как поиск отрывков или ответы на вопросы, а не только на общий балл.
Принцип: настраивайте модель встраивания с учётом охвата и скорости, а не точности. Точность — это задача алгоритма оценки.
Ранжировщик определяет окончательную точность
Это последний фильтр перед LLM, поэтому его качество напрямую влияет на точность ответа. Оценивайте его по:
- Точность ранжирования. Основной показатель. Проверяйте nDCG, MRR и MAP на тестовых данных, близких к вашей области применения. Небольшие улучшения здесь могут существенно снизить количество ложных ответов.
- Задержка. Ранжировщик выполняется один раз для каждого кандидата, поэтому если количество кандидатов — 100, это означает 100 итераций. Время на одну итерацию и общее время являются важными ограничениями в производственных условиях.
- Соответствие домену. Общие инструменты переранкинга хорошо справляются с широким поиском, но в критически важных доменах часто более эффективны инструменты, отрегулированные с учётом данных о релевантности для конкретного домена. Инструмент переранкинга, обученный на медицинской литературе, будет лучше оценивать клинические запросы, чем общий инструмент, даже если последний показывает более высокие результаты на универсальных тестах.
- Пропускная способность. При высокой нагрузке инструмент переранкинга может стать узким местом. Стоит рассмотреть группировку задач, параллелизм моделей, а также возможность использования более лёгких вариантов — упрощённых кросс-кодеров или моделей с задержкой интеракции — которые обеспечивают приемлемую точность при значительно более высокой пропускной способности.
Инвестируйте в оба решения
Самые эффективные системы не выбирают между хорошим инструментом для генерации эмбеддингов и хорошим инструментом для переранжирования, поскольку эти два инструмента выполняют независимые друг от друга задачи. Сильный инструмент для генерации эмбеддингов в сочетании с слабым инструментом для переранжирования обеспечивает высокий уровень воспроизведения результатов, но при этом генерирует шумные итоговые результаты. Слабый инструмент для генерации эмбеддингов в сочетании с сильным инструментом для переранжирования позволяет получить точное порядок элементов в неполном наборе кандидатов. Ни один из этих подходов сам по себе недостаточен.
Секрет эффективности заключается в быстром поиске с высоким уровнем воспроизведения результатов в сочетании с точным и надежным переранжированием. Подбирайте инструмент для генерации эмбеддингов в соответствии с требованиями к уровню воспроизведения результатов, а инструмент для переранжирования — в соответствии с требованиями к точности, затем настраивайте размер набора кандидатов на разных этапах, чтобы сбалансировать охват результатов и время их переранжирования.
Пример реализации
Возьмём пример: клинического ассистента спрашивают, может ли пациент, принимающий определённый препарат от диабета, безопасно принимать ещё одно лекарство. На этапе поиска одновременно выполняются поиск по ключевым словам и векторный поиск; результаты объединяются с помощью метода RRF, после чего остаётся 100 кандидатов. Среди них — монография по каждому препарату, статья о методике проведения исследований, общий брошюре по питанию и несколько таблиц взаимодействия препаратов. Только на основе сходства статья о исследовании и брошюра могут оказаться выше в рейтинге, чем таблицы взаимодействия, поскольку их лексика ближе к формулировке вопроса.
На этапе судьи читается вопрос рядом с каждым из ста отрывков, и оценивается, действительно ли отрывок касается совместного использования. Таблица взаимодействия и соответствующий параграф с противопоказаниями перемещаются вверх, листовка опускается, и модель получает шесть отрывков вместо шумных десяти. То же корпус, те же эмбеддинги, но другой результат — потому что второй компонент принял решение, для которого первый никогда не был создан.
Настройка перехода между этапами
Размер пула кандидатов является ключевым параметром. Если он слишком мал, судья никогда не увидит правильный отрывок, что ограничивает показатель воспроизведения для всей системы. Если же он слишком велик, задержки и затраты на переранжирование растут без значительной пользы. Практический способ настройки — записать на отмеченном примере ранг, на котором правильный отрывок появляется на первом этапе, а затем выбрать пул, охватывающий почти все такие примеры. Если правильный отрывок регулярно находится за рангом 150, проблема, скорее всего, кроется на этапе поиска: требуется лучший инструмент встраивания данных, гибридный метод поиска или улучшенное разбиение на фрагменты, а не более мощный механизм переранжирования.
Также помогают другие привычки:
- Оценивайте оба этапа отдельно. Измеряйте показатель воспроизведения в пуле до оценки и точность окончательного списка после нее, чтобы можно было определить, в каком именно этапе происходит ухудшение качества.
- Храните результаты переранжирования для часто запрашиваемых запросов, если корпус данных меняется медленно.
- Сохраняйте небольшой объем итогового контекста. Лучше использовать пять качественных фрагментов, чем двадцать смешанных, поскольку дополнительный материал конкурирует за внимание.
- Повторно анализируйте настройки при изменении состава корпуса или запроса, так как алгоритм ранжирования, отрегулированный для одной области, может плохо справляться в другой.
Рассматривайте это как гипотезу, которую нужно проверить на собственных данных, а не как гарантию, поскольку эффективность различается в зависимости от области и от того, насколько слабым был исходный уровень.
Вывод
Надежный RAG достигается не путем поиска лучших эмбеддингов. Он основан на разделении поиска и оценки: на одном этапе максимизируется охват, а на другом — точность.
Это изменение сначала концептуальное, а уже затем техническое. Перестаньте рассматривать результаты top-K как окончательный ответ — считайте их набором кандидатов. Перестаньте воспринимать сходство как истину — рассматривайте его как гипотезу, требующую проверки. Сначала проводите широкий поиск, затем точно оценивайте результаты.
Связанные статьи
- Расширенные технологии RAG в Milvus: гибридный поиск, HyDE, переписывание запросов и их переранжирование — Пошаговое создание пайплайна RAG в Milvus: плотные и BM25-векторы, гибридный поиск RRF, фильтры метаданных, переписывание запросов, технология HyDE, декомпозиция и переранжирование с использованием кросс-кодеров.
- Практические заметки: ИИ-агентам больше не нужен векторный поиск: внутреннее устройство системы Agentic — Подробное руководство по использованию технологий, описанных в статье «Практические заметки: ИИ-агентам больше не нужен векторный поиск: внутреннее устройство системы Agentic», включая замену технологии RAG в 2026 году: контракты, проверки и готовый код.