Почему ответы RAG кажутся полными, хотя поиск в Azure DevOps показывает обратное?

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

Вопрос, выявивший пробел

На первые вопросы приходили четкие ответы с указанием источников, без лишних выдумок. Более обширный запрос — «Какая работа с ИИ ведется в этой организации?» — тоже давал неплохие результаты: несколько абзацев, несколько цитат, ничего явно ошибочного. Однако при использовании команды az boards query, представляющей собой поиск методом грубой силы без функций ранжирования, были получены десятки результатов, которые не упоминались в отредактированном ответе. Группы информации о оценке помощников для программирования, сравнении стоимости моделей или отладке конкретного инструмента отсутствовали, поскольку их формулировки мало соответствовали вопросу, и они не попадали в верхнюю часть результатов семантического поиска.

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

Запрос, который помогал лишь иногда

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

Инструкция для языковой модели — это подсказка, а не гарантия. Когда важна полнота информации, тщательность не может зависеть от решения модели в моменте быть ли ей тщательной.

Сделать процесс детерминированным

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

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

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

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

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

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

Увеличение объема получаемого контекста ухудшало ответы

Вопреки здравому смыслу, когда качество поиска улучшилось настолько, что количество элементов в наборе модели выросло с нескольких сотен до более тысячи, ответы стали короче и менее полными. Модель не выходила из строя; она просто начала писать меньше, несмотря на наличие большего количества достоверных данных. При превышении определенного объема качество ответов не улучшается с ростом объема контекста — оно снижается. Показатели поиска улучшались, в то время как показатели качества окончательных ответов ухудшались в том же эксперименте. Решением было не «добавлять больше», а определить предел и держаться ниже его.

Решение проблемы прозрачности, приводящее к перегрузке при ответах на узкие вопросы

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

Постоянным решением стало не только установление числового лимита. Необходимо было разделить два вида «найденных, но не названных» элементов: небольшой набор точных совпадений, которые всегда должны отображаться, и большой объем элементов с размытыми тегами, для которых требовались четкий лимит и указание на наличие дополнительных элементов. Это различие имело большее значение, чем сам лимит.

Предоставление модели инструментов с ограничениями

Остальная часть работы была сформирована одним важным вопросом: почему человек может ответить на то, что не может сделать система, если оба видят одни и те же данные? Люди могут составить новый запрос, когда стандартные инструменты не подходят, и они перепроверяют ответы, которые кажутся неверными. У модели не было ни одной из этих способностей. Ей предоставился инструмент для написания собственного запроса к базе данных с режимом только для чтения — режим только для чтения обеспечивался самой базой данных, срок действия запроса был ограничен, а размер результата — ограничен.

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

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

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

Как тестирование оставалось честным

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

Упорядочивание процесса обработки без перегрузки модели

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

Цитаты против вычисленных фактов

Правило «цитирование каждого утверждения» защищает от вымысла, когда модель цитирует элементы работы. Оно становится вредным, когда модель выполняет арифметические операции или объединяет результаты инструментов. Разделение «цитируемого утверждения» и «рассчитанного агрегата» в инструкциях восстановило показатель двадцати пяти совместных проектов, не ослабляя при этом дисциплину цитирования для повествовательных утверждений. Системы RAG с использованием инструментов нуждаются в обоих правилах, что должно быть четко указано.

Текущее состояние дел

Чистый запрос к базе данных по своей конструкции является исчерпывающим: совпадающие строки невозможно пропустить. Он также не может объяснять, группировать или излагать смысл — он возвращает список, а не ответ. Теперь система учитывает полноту такого запроса в сложных случаях, которые были найдены и протестированы, при этом продолжая объяснять результаты в прозе с проверяемыми источниками. Этот результат измеряется, а не предполагается.

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

Честный итог таков: проблема полноты RAG не решена. Были устранены все конкретные пробелы, которые удалось обнаружить и проверить, при этом приводятся цифры до и после внесения изменений. Невозможно гарантировать отсутствие новых пробелов, и ни одна система такого рода не должна создавать подобных ожиданий. Фраза «модель обычно дает правильный ответ» не является основанием для надежности — именно слово «обычно» становится причиной ошибок в критически важных случаях.