Self-RAG: как ИИ проверяет найденные документы

Self-RAG: как ИИ проверяет найденные документы — это метод, при котором языковая модель сама решает, нужен ли поиск, оценивает найденные фрагменты и проверяет, опирается ли её ответ на источник. Исходный Self-RAG обучает модель особым токенам рефлексии; прикладная цепочка собирает те же проверки из внешних вызовов.

Исходный Self-RAG: обучение, reflection tokens и retrieval по необходимости

Первичная работа описывает Self-RAG как фреймворк, который учит модель искать, генерировать и критиковать собственный вывод. На странице проекта selfrag.github.io сказано, что метод повышает качество и фактичность ответов через поиск и саморефлексию. Обучение идёт на трёх компонентах: Retriever, Critic и Generator. Сначала тренируют Critic и размечают обучающие данные токенами рефлексии, затем Generator учится предсказывать обычные продолжения вместе со специальными токенами.

Ключевая идея — retrieval по необходимости. Модель на каждом сегменте (например, предложении) сама решает, нужен ли внешний поиск. Если поиск не нужен, она генерирует продолжение как обычная языковая модель. Если нужен — вызывает внешний модуль поиска, получает документы и продолжает генерацию с их учётом. Это отличает метод от стандартного RAG, который извлекает фиксированное число фрагментов независимо от того, помогает это или нет.

Токены рефлексии делятся на несколько типов. Retrieval-токен решает, нужен ли поиск. ISREL оценивает релевантность найденного фрагмента. ISSUP проверяет, подтверждается ли сгенерированный текст источником. ISUSE оценивает общую полезность ответа. На странице проекта перечислены эти типы и указано, что они добавляются в словарь модели во время обучения.

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

Исходная работа относится к конкретным моделям на 7B и 13B параметров и к набору задач того времени. Сравнения с ChatGPT и retrieval-augmented Llama2-chat, приведённые на странице проекта, относятся именно к этим моделям и задачам. Переносить эти сравнения на современные модели без отдельной проверки нельзя.

Прикладная self-reflective цепочка с внешними grader-проверками

Прикладная цепочка воспроизводит логику Self-RAG без обучения модели токенам. Вместо этого проверки выносятся во внешние вызовы: модель-градер оценивает документы и ответы по отдельным запросам. Такой подход описан в блоге LangChain о self-reflective RAG с LangGraph. Автор материала отмечает, что базовый RAG-конвейер просто передаёт найденные документы в модель, а self-reflective RAG добавляет обратную связь: переформулировку запроса и повторный поиск.

В блоге LangChain перечислены четыре типа токенов из работы Self-RAG и показано, как их можно представить в виде графа состояний. Retrieve-токен решает, извлекать ли фрагменты. ISREL определяет релевантность прохода. ISSUP проверяет, подтверждается ли генерация фрагментом. ISUSE оценивает полезность ответа по шкале от 1 до 5. В прикладной цепочке каждый из этих шагов становится отдельным узлом графа.

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

Учебный пример IBM на сайте ibm.com показывает ещё один вариант прикладной цепочки. В туториале модель Granite просят печатать строки рефлексии через обычный промпт, а оценка используется для управления следующим шагом графа. Это иллюстративный внешний workflow, который не воспроизводит исходное обучение Self-RAG. Автор туториала прямо описывает его как практическое руководство по сборке агента.

Прикладная цепочка удобна тем, что не требует дообучения. Её можно собрать на любой модели, поддерживающей вызовы через API. Плата за это — дополнительные вызовы на каждую проверку и зависимость от качества внешнего градера. Градер остаётся ошибающейся моделью, и его оценка не является объективной гарантией.

Как проверить релевантность документа, grounding и полезность ответа

Три проверки отвечают на три разных вопроса. Релевантность спрашивает: относится ли найденный документ к запросу. Grounding спрашивает: подтверждается ли утверждение в ответе конкретной строкой источника. Полезность спрашивает: отвечает ли текст именно на заданный вопрос.

Проверку релевантности удобно формулировать как бинарный вопрос по каждому документу. Модель получает запрос и фрагмент и возвращает «релевантен» или «нерелевантен». В блоге LangChain описано, что при отсутствии релевантных документов цепочка переформулирует запрос и повторяет поиск. Это защищает от генерации по мусорным фрагментам.

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

Проверка полезности оценивает, отвечает ли текст на вопрос. Здесь частая ошибка — принять пересказ инструкции за ответ. Если вопрос про восстановление пароля, а ответ пересказывает всю инструкцию сервиса, полезность низкая, даже если grounding пройден. В блоге LangChain приведён пример, где генерация прошла проверку относительно документов, но не была признана полностью полезной для вопроса, и цепочка перезапустилась с переформулированным запросом.

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

Полный учебный пример Вектора с текущей и архивной инструкциями

Разберём учебный пример. База содержит три документа. D-current: «Сервис Вектор. Действующая инструкция: пароль восстанавливают через ссылку из письма». D-old: «Архивная инструкция: пароль меняет администратор». D-other: «Сервис Лира: сброс пароля через SMS». Вопрос: «Как восстановить пароль Вектора?»

Проверка документов оставляет D-current. D-old помечается архивным, потому что описывает устаревший порядок. D-other помечается другим продуктом, потому что относится к сервису Лира. Кандидат ответа «Введите код из SMS» не проходит grounding: он опирается на D-other — инструкцию другого сервиса. Исправленный ответ «Откройте ссылку восстановления из письма» сопровождается D-current и проходит проверку.

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

Для вопроса «Сколько действует ссылка?» база не содержит срока. Итог: «В этих документах срок не указан». Это корректный результат проверки — модель фиксирует границу известного. Такой ответ полезнее выдуманного срока, потому что читатель знает, что нужно искать в другом месте.

Учебная схема допускает один повтор генерации после замечания, затем завершает работу с отказом от неподтверждённого ответа. Этот предел выбран автором упражнения и не взят из исходного Self-RAG. В прикладной цепочке число повторов задаётся настройкой графа.

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

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

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

Практический порядок действий при неподтверждённом ответе:

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

Отказ должен быть информативным. Формулировка «В этих документах срок не указан» полезнее, чем «Не могу ответить». Читатель понимает, что вопрос корректен, но база его не покрывает. Это подсказывает следующий шаг: искать в другом источнике или дополнить базу.

Отдельно стоит обрабатывать случай, когда документ релевантен, но устарел. В учебном примере D-old помечается архивным. Если бы цепочка использовала его, ответ «пароль меняет администратор» был бы подтверждён документом, но противоречил бы действующей инструкции. Проверка статуса документа — часть проверки релевантности.

Как ограничить повторы и расходы своей реализации

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

В учебном примере допускается один повтор генерации после замечания. Это значение выбрано автором упражнения. В прикладной цепочке на LangGraph, описанной на сайте ibm.com, в состоянии агента задан счётчик сегментов и порог оценки. В этом примере граф завершается, когда ответ отмечен законченным или достигнут предел числа сегментов. Низкая оценка направляет граф на повторный поиск перед следующим сегментом. Автор туториала приводит конкретные значения порога и весов оценки, но они относятся к его примеру и его модели.

Способы снизить расходы:

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

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

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

Как оценивать ошибки проверяющей модели на эталонных вопросах

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

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

Метрики, которые имеет смысл считать:

• Доля документов, ошибочно признанных релевантными.
• Доля релевантных документов, ошибочно отброшенных.
• Доля утверждений, пропущенных проверкой grounding.
• Доля ответов, ошибочно признанных полезными.

В учебном примере эталон прост: D-current релевантен, D-old и D-other — нет. Ответ «Введите код из SMS» не проходит grounding. Ответ «Откройте ссылку из письма» проходит. Вопрос про срок даёт итог «не указан». Прогон проверок на этом наборе покажет, ошибается ли градер на каждом из случаев.

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

Проверяющая модель остаётся моделью. Её оценка используется как сигнал для управления цепочкой. Финальное решение о выдаче ответа принимает человек или заданное правило.

Частые вопросы

Что такое Self-RAG простыми словами?

Это метод, при котором языковая модель сама решает, нужен ли поиск, оценивает найденные документы и проверяет, подтверждается ли её ответ источником. Исходный Self-RAG обучает модель особым токенам рефлексии. Прикладная цепочка собирает те же проверки из внешних вызовов без дообучения.

Чем Self-RAG отличается от обычного RAG?

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

Нужно ли обучать модель для Self-RAG?

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

Что делать, если документ не подтверждает ответ?

Нужно переформулировать запрос и повторить поиск. Если поддержки нет и после повтора, цепочка возвращает отказ с указанием, что данных недостаточно. В учебном примере ответ «Введите код из SMS» не проходит grounding, потому что опирается на документ другого сервиса.

Как ограничить расходы на проверки?

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