Генерация с расширенным поиском для задач NLP с интенсивным использованием знаний

Работа Льюиса и соавторов «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks» (NeurIPS 2020), вероятно, является той самой статьей, которая в наибольшей степени определила архитектуру современных производственных систем ИИ. Спустя пять лет после публикации она остается базовым уровнем, с которым сравнивают практически любую языковую систему, основанную на документах. Я читаю ее сейчас, потому что все задачи в моем бэклоге Bean Labs — от ответов на вопросы по леджеру до объяснения аномалий — в конечном итоге упираются в проблему поиска информации, и я хочу четко понять первоначальные проектные решения, прежде чем переходить к преемникам этой технологии.

Статья

Основная проблема, которую решает RAG, заключается в том, что предобученные языковые модели «запекают» знания в веса во время обучения, делая эти знания статичными, непрозрачными и невозможными для обновления без переобучения. Льюис и др. предлагают гибридную архитектуру: параметрическую память (BART-large в качестве генератора) в паре с непараметрической памятью (плотный индекс FAISS по 21 миллиону пассажей из Википедии), соединенных обучаемым ретривером на базе Dense Passage Retrieval (DPR, Karpukhin et al. 2020). Во время инференса модель извлекает K наиболее релевантных пассажей, а затем маргинализирует их для получения итогового результата.

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

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

• RAG-Sequence достигает 44,5 Exact Match на Natural Questions, 56,8 EM на TriviaQA и 68,0 EM на WebQuestions — лучшие показатели на момент публикации.
• В абстрактивных ответах на вопросы MS-MARCO RAG-Sequence набирает 40,8 ROUGE-L против 38,2 у базовой модели BART — скромный, но стабильный прирост.
• Генерация вопросов для Jeopardy: эксперты-оценщики признали ответы RAG более фактическими, чем у BART, в 42,7% случаев (BART был лучше лишь в 7,1%).
• В верификации фактов FEVER RAG достигает точности 72,5% (на 4,3 пункта ниже специализированных SOTA-решений) без какой-либо специфической для задачи инженерии.
• Замораживание кодировщика документов во время обучения стоит всего около 3 пунктов EM на NQ (44,0 → 41,2), что делает подход вычислительно осуществимым ценой использования «устаревших» знаний в индексе.
• Плотный поиск превосходит BM25 во всех задачах, кроме FEVER, где ориентированные на сущности запросы выигрывают от совпадения терминов — конкретный сигнал о том, что разреженный поиск не является однозначно худшим.

Что выдержало проверку временем, а что нет

Фундаментальная идея — отделение хранилища знаний от логического движка — сохранилась отлично. Это дает вам обновляемые знания (просто переиндексируйте), указание источников (извлеченные пассажи можно проверить) и универсальность для задач QA, генерации и верификации фактов без специфических архитектур. Эти свойства на практике все еще значат больше, чем конкретные цифры Exact Match.

Рецензенты NeurIPS были правы в том, что техническая новизна здесь ограничена. DPR и BART уже существовали; RAG — это тщательная интеграция, а не фундаментальный алгоритмический прорыв. Решение о заморозке кодировщика документов также создает тонкую проблему, которую в статье несколько обходят стороной: индекс строится один раз и становится «снимком» во времени. Любой факт, изменившийся после построения индекса, невидим для модели. Для статических корпусов, таких как отчетность SEC, это приемлемо. Для живых систем — цен в реальном времени, ежедневных потоков транзакций — это серьезное архитектурное ограничение, а не мелкая деталь.

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

Объем памяти также нетривиален: один только индекс Википедии требует около 100 ГБ оперативной памяти CPU. В статье это преподносится как преимущество (непараметрическую память «быстро обновлять»), но это реальные эксплуатационные расходы, которые определили развитие метода в последующие годы — в сторону сжатых индексов и приближенного поиска.

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

Архитектура поиска естественным образом ложится на структуру задач Beancount. Леджер Beancount — это большой корпус документов, доступный только для добавления, где отдельные записи семантически связаны: налогооблагаемый расход ссылается на категорию, категория — на правило, правило — на финансовый год. Никакая параметрическая модель, обученная на публичных данных, не знает специфического плана счетов пользователя. Разделение логики и знаний в RAG делает его правильным структурным ответом: дообучите генератор форматам бухгалтерских задач, но основывайте фактический поиск на реальном индексе леджера пользователя.

Практическая проблема та же, которую авторы статьи выявили, но недооценили: устаревшие индексы. Если агент Beancount извлекает данные из индекса, построенного вчера, он может пропустить сегодняшние транзакции. Инкрементальная индексация и триггерная переиндексация при записи в леджер должны быть частью архитектуры системы с самого начала, а не добавляться потом. Другая проблема — точность поиска по структурированным данным. RAG был разработан для прозы Википедии. В леджере Beancount есть диапазоны дат, иерархии счетов и обозначения валют, с которыми оптимизированные под текст ретриверы не справляются «из коробки». Вопрос «могут ли LLM рассуждать над табличными данными», который я исследовал ранее, напрямую ограничивает то, что RAG может полезно извлечь.

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

• Fusion-in-Decoder (FiD), Izacard & Grave 2020 (arXiv:2007.01282) — независимо обрабатывает каждый извлеченный пассаж и объединяет их в декодере, достигая более высоких показателей NQ, чем RAG, при более простой архитектуре; стоит изучить перед внедрением подхода совместного чтения RAG-Token.
• FLARE: Active Retrieval Augmented Generation, Jiang et al. 2023 (arXiv:2305.06983) — выполняет поиск по требованию во время генерации, предсказывая, когда модель вот-вот начнет галлюцинировать; наиболее естественное развитие идей RAG в сторону более адаптивных агентов.
• «Fine-Tuning or Retrieval?» Ovadia et al. 2023 (arXiv:2312.05934) — систематическое сравнение методов внедрения знаний; эмпирические данные, которые вам понадобятся перед тем, как решать, дообучать ли специфический для леджера генератор или просто улучшать поиск.