Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Появился способ проверять, какие темы пропускает поиск в системе генерации с дополненным поиском (RAG), даже если для корпуса нет полной разметки релевантности. В препринте JPMorgan Chase, который не прошёл рецензирование и содержит замеры самих авторов, Re:CAP нашёл на TREC-COVID документы, из которых 21,2% не извлекло даже объединение трёх вариантов поиска. Такой аудит можно запускать перед заменой индекса, модели векторизации или ранжирования, а не проверять качество только по готовым ответам.
Хороший ответ может скрывать плохое покрытие
Обычная оценка RAG часто смотрит, соответствует ли ответ найденному контексту и отвечает ли он на вопрос. Но модель может составить точный и связный текст по доступным документам, пропустив другие существенные аспекты темы.
Например, на вопрос о решении центрального банка поиск может вернуть пресс-релиз и новостную заметку, но не найти прогнозы, стенограмму пресс-конференции и мнения аналитиков. Проверка готового ответа не обнаружит пропуск: каждое утверждение по-прежнему опирается на источник.
Увеличение глубины выдачи помогает не всегда. Исходный запрос задаёт одно ранжирование корпуса, поэтому дополнительные документы часто приходят из уже найденной области. Повторное ранжирование тоже не исправляет этот пробел: оно меняет порядок кандидатов, но не добавляет материалы, которых среди них не было.
Классическая полнота показывает долю релевантных документов, которые нашёл поиск. Для постоянно обновляемого корпоративного корпуса её трудно посчитать: пришлось бы заново размечать документы после каждого изменения индекса или поисковой модели. Re:CAP вместо полного перечня релевантных материалов ищет положительные свидетельства конкретных пропусков.
Как дополнительные вопросы открывают другую часть корпуса
Сначала рабочая RAG-система выполняет запрос без изменений. Re:CAP получает исходный ответ и найденные документы, а затем составляет реестр уже покрытых тем. Документы сверяются с реестром отдельно, чтобы не принять за ошибку поиска тему, которую генератор увидел в контексте, но не включил в ответ.
Из запроса и ответа метод также извлекает сущности, даты и числовые ориентиры. Они становятся буквальными якорями для дополнительных вопросов. Это мешает генератору перефразировать запрос так широко, что он потеряет название организации, события или другого связующего объекта.
На каждой итерации Re:CAP формулирует вопросы о вероятно пропущенных аспектах. Одни сохраняют сущность и меняют рассматриваемое свойство, другие ослабляют или уточняют ограничения, третьи проверяют обратную формулировку. Каждый вопрос отправляется в тот же поисковик, который использует основная система: аудит показывает слепые зоны текущего контура, а не подменяет его другим решением.
Новые кандидаты проверяет модель-оценщик. Она решает, добавляет ли документ новую тему или подтему, повторяет уже найденное, не относится к вопросу либо противоречит контексту. Полезные темы пополняют реестр, а вопросы без результата сохраняются как неудачные, чтобы следующая итерация не повторяла тот же путь.
Цикл заканчивается, когда новые темы перестают появляться. На выходе команда получает список пробелов, документы-свидетельства и долю найденных тем, отсутствовавших в исходной выдаче. Один проверяемый запрос требует примерно 250–500 обращений к LLM, поэтому метод рассчитан на периодический аудит выборки, а не на обработку каждого пользовательского запроса. В рекомендованной конфигурации один такой аудит стоил авторам $0,59.
Где аудит меняет планы разработки
Метод проверяли на MuSiQue, HotPotQA, MultiHop-RAG и TREC-COVID, а также на двух рабочих системах с закрытыми корпусами. В опытах использовали BM25, плотный векторный поиск и их гибрид; генератор ответа оставляли неизменным, чтобы измерять именно поиск. MultiHop-RAG служил проверкой верхней границы: его небольшой корпус обычная глубокая выдача почти полностью покрывала и преимущество цикла сокращалось.
На MuSiQue Re:CAP повысил полноту на 12,9 процентного пункта относительно гибридной выдачи top-500, просмотрев меньше половины её документов. На TREC-COVID совокупная полнота, напротив, уступила плоской выдаче на 2 пункта, но метод находил другой срез релевантных материалов. Независимые оценщики решили, что 78,9% документов из этого среза добавляли к исходному ответу новую информацию.
На рабочем трафике новую информацию содержали 73,9% отмеченных документов. Это делает Re:CAP полезным не как замену метрикам ответа, а как отдельную проверку перед обновлением корпуса, поисковика или модели векторизации. Если после изменения реестр пробелов растёт, команда получает примеры документов и тем для диагностики, а не только ухудшившийся общий балл.
Результат не означает, что аудит доказывает полное покрытие корпуса. Он обнаруживает только те пробелы, до которых смогли добраться дополнительные вопросы и текущий поисковик; часть кандидатов также может ошибочно отклонить модель-оценщик. Поэтому метод лучше использовать как повторяемый тест на представительной выборке и дополнять ручной проверкой самых важных находок.
Источники
Иллюстрация: рисунок из статьи «Re:CAP - Auditing Retrieval Coverage in Production RAG Pipelines», Aviral Joshi, Hanoz Bhathena, Max Nelson и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
