FLARE: Активная генерация с расширенным поиском

На прошлой неделе я читал фундаментальную статью о RAG авторов Lewis и др. — выполнить поиск один раз, добавить результат в начало, сгенерировать текст. Это работает, но подразумевает, что вы заранее знаете, что вам понадобится. FLARE (EMNLP 2023) атакует это предположение напрямую: что если подходящий момент для поиска наступает в середине предложения, именно тогда, когда модель начинает терять уверенность? Над этим вопросом стоит тщательно подумать для любой системы — например, агента Beancount — которой необходимо анализировать историю книги учета, не вмещающуюся в одно окно контекста.

Статья

«Active Retrieval Augmented Generation» Чжэнбао Цзяна, Фрэнка Сюя, Лую Гао, Чжицина Суня, Цяня Лю, Джейн Двиведи-Ю, Имина Яна, Джейми Каллана и Грэма Ньюбига предлагает FLARE: Forward-Looking Active REtrieval augmented generation (активная генерация с упреждающим расширенным поиском). Проблема, которую они решают, — это галлюцинации при генерации длинных текстов, где модель должна извлекать несколько фрагментов знаний на протяжении всего вывода. Стандартный RAG выполняет поиск один раз во время запроса и надеется, что извлеченный фрагмент покроет все, что понадобится при генерации — это подходит для коротких ответов, но ненадежно для ответов из нескольких абзацев.

FLARE разделяет генерацию на шаги на уровне предложений. На каждом шаге создается кандидат на следующее предложение. Если вероятность предсказания любого токена в этом кандидате ниже порога θ, FLARE рассматривает эти фрагменты с низкой уверенностью как сигналы для поиска, использует их (в маскированном или завершенном виде) для формирования запроса, выполняет поиск в Википедии и заново генерирует предложение с учетом извлеченного контекста. В результате система выполняет поиск только тогда и примерно там, где она не уверена, не загружая заранее контент, который может не понадобиться. Все эксперименты проводились на GPT-3.5 (text-davinci-003) без какой-либо тонкой настройки.

Ключевые идеи

• Уверенность как триггер поиска: вероятность токена ниже θ сигнализирует о том, что модель, скорее всего, начнет галлюцинировать; поиск запускается только в этот момент, а не по умолчанию. Авторы обнаружили, что запуск поиска для 40–80% предложений обычно дает наилучшие результаты.
• Упреждающие запросы: вместо того чтобы использовать в качестве запроса только то, что уже было сгенерировано (подход «предыдущего окна»), FLARE использует предсказанное будущее предложение — то, что модель предполагает сказать — в качестве гораздо более точного поискового запроса.
• Два варианта: FLARE-instruct маскирует токены с низкой уверенностью и использует маскированный фрагмент в качестве запроса; FLARE-direct использует все предсказанное предложение целиком. На 2WikiMultihopQA вариант direct достигает 51,0 EM против 42,4 у варианта instruct.
• Преимущества над однократным поиском реальны, но неоднородны: на 2WikiMultihopQA FLARE-direct достигает 51,0 EM против 39,4 при однократном поиске и 28,2 без поиска — решительное улучшение. На ASQA разрыв намного меньше (41,3 против 40,0), а в WikiAsp (UniEval 53,4 против 52,4) результаты почти равны.
• Явные случаи неудач: авторы сообщают, что FLARE не дает преимуществ на наборах данных Wizard of Wikipedia и ELI5, где короткие ответы означают, что многоэтапный поиск создает накладные расходы без пользы.
• Стоимость: поскольку генерация и поиск чередуются, каждый пример может инициировать несколько вызовов языковой модели и поисковых запросов. Кэширование здесь не является тривиальной задачей.

Что подтверждается, а что — нет

Концепция упреждающего поиска — это действительно умная часть работы. Использование предсказанного контента в качестве поискового запроса более информативно, чем просто префикс, особенно для многоходовых задач, где промежуточные выводы определяют, какой факт понадобится следующим. Разрыв в 51,0 против 39,4 EM на 2WikiMultihopQA подтверждает это.

Однако сигнал уверенности FLARE полностью зависит от того, насколько хорошо откалибрована модель. Вероятности токенов базовой модели, такой как text-davinci-003, неплохо коррелируют с неопределенностью. Это не относится к чат-моделям, настроенным на инструкции или с помощью RLHF, которые часто излишне самоуверенны — они выдают токены с высокой вероятностью даже при галлюцинациях. Исследование 2024 года, Unified Active Retrieval (UAR, arXiv:2406.12534), тестирует FLARE на более широком наборе сценариев принятия решений о поиске и находит, что он достигает точности лишь 56,50% в различных ситуациях по сравнению с 85,32% у подхода UAR на основе классификатора. Проблема калибровки — это не частный случай, это основное допущение, на котором строится метод.

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

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

Почему это важно для финансового ИИ

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

Однако проблема калибровки вызывает серьезные опасения. Промышленные финансовые агенты почти повсеместно используют чат-модели, настроенные на инструкции (GPT-4, Claude, Gemini), а не базовые модели генерации. Если эти модели излишне уверены в себе — что часто случается с числовыми утверждениями — они пропустят поиск именно тогда, когда его следовало бы запустить. Агент записи Beancount, который уверенно галлюцинирует дату транзакции и никогда не выполняет поиск для проверки, хуже, чем бесполезен.

Практический урок заключается в том, чтобы сочетать построение упреждающих запросов FLARE с триггером поиска, который не полагается исключительно на вероятность токена. Явные маркеры неопределенности (фразы-хеджирования, круглые числа, именованные сущности, которые модель давно не видела) могли бы дополнить сигнал уверенности. Или можно использовать подход UAR: обучить легкий классификатор на скрытых состояниях модели, который более устойчив к плохой калибровке, чем необработанные логиты.

Что почитать дальше

• IRCoT: "Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions" (arXiv:2212.10509) — связывает поиск с шагами цепочки рассуждений (CoT), а не с уверенностью в токенах; стоит сравнить напрямую с FLARE в многоходовых задачах.
• Unified Active Retrieval (UAR, arXiv:2406.12534) — прямое продолжение, раскрывающее проблему калибровки FLARE и предлагающее решения на основе классификаторов для четырех сценариев поиска.
• "Adaptive Retrieval without Self-Knowledge? Bringing Uncertainty Back Home" (arXiv:2501.12835) — статья 2025 года, в которой пересматривается возможность восстановления триггеров на основе вероятности токенов с помощью улучшенных методов калибровки.