Глава 5.2 — Генерация с дополненным поиском

Содержание

1. От расходования большего объёма вычислений к расходованию их на нужные знания
2. Два вида сбоя параметрической памяти
3. Генерация с дополненным поиском: исходная формулировка
4. Dense Passage Retrieval: делаем поиск обучаемым
5. Собираем всё вместе: что реально даёт RAG
6. Честные виды сбоя
7. Взгляд с точки зрения собеседования
8. Вопросы для самопроверки
9. Источники

1. От расходования большего объёма вычислений к расходованию их на нужные знания

Глава 5.1 установила, что реальная возможность модели зависит не только от её весов, но и от того, сколько вычислений ей позволено потратить на этапе инференса, и что расходование большего объёма этих вычислений на рассуждение способно раскрыть скрытую способность, уже заложенную в весах. Эта глава — про другой, дополняющий пробел: никакое количество дополнительных вычислений на рассуждение не может произвести факт, которому модель никогда не училась, и никакой хитрый промптинг не может обновить факт, который модель усвоила неверно или который устарел уже после того, как она его усвоила. Вычисления на этапе рассуждения помогают модели усерднее думать над тем, что она уже знает; генерация с дополненным поиском (retrieval-augmented generation, RAG) — стандартный инженерный ответ на отдельную проблему того, что модель знает изначально, и как это исправить без переобучения.

2. Два вида сбоя параметрической памяти

Всё, что предобученная языковая модель «знает», хранится неявно в её весах — и вероятностная формулировка из главы 1.1, и рассмотрение предобучения в части IV ясно показывают, что эти знания — побочный продукт оптимизации предсказания следующего токена на фиксированном обучающем корпусе, а не намеренно спроектированная база знаний. Отсюда вытекают два следствия, чрезвычайно важных в продакшене. Во-первых, знания заморожены на том, что содержали обучающие данные на момент отсечения предобучения; всё, что произошло позже, или что не было хорошо представлено в корпусе, попросту отсутствует, как бы модель ни промптировали. Во-вторых, и это тоньше, даже те знания, что присутствовали при обучении, хранятся диффузно, распределённо по миллиардам параметров через процесс с потерями, управляемый градиентным спуском, а значит, воспроизведение моделью любого конкретного факта не гарантированно точно — она может выдать беглые, уверенные, синтаксически безупречные утверждения, которые попросту ложны, — сбой, обычно называемый галлюцинацией. Критически важно, что галлюцинация — не баг, который надёжно устраняется лучшим промптингом, потому что у модели нет встроенного механизма, отличающего «я воспроизвожу факт, которому меня обучили» от «я генерирую правдоподобно звучащее продолжение», поскольку оба процесса проходят через один и тот же механизм предсказания следующего токена.

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

3. Генерация с дополненным поиском: исходная формулировка

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

Формально Lewis и соавторы формулируют это как модель со скрытой переменной над извлекаемыми документами, структурно похожую на маргинализацию скрытого пути рассуждения в обсуждении самосогласованности из главы 5.1: получив запрос $q$, модель обусловливается не напрямую на $q$, а рассматривает извлечённый документ (или набор документов) $z$ как скрытую переменную: $P(y \mid q) = \sum_z P(y \mid q, z) P(z \mid q)$, где $P(z \mid q)$ — распределение поиска по корпусу, а $P(y \mid q, z)$ — генератор, обусловленный и запросом, и извлечёнными доказательствами. В исходной формулировке ретривер (модуль поиска) и генератор обучаются совместно, сквозным образом (end-to-end), так что ретривер учится извлекать фрагменты, которые действительно помогают генератору произвести верный вывод, а не фрагменты, которые лишь лексически похожи на запрос. Эту совместную формулировку стоит запомнить для целей собеседования: RAG — это не просто «поищи и вставь в промпт» — вклад исходной статьи состоял в том, что она показала, как поиск и генерацию можно объединить в единую обученную систему, превосходящую чисто параметрические модели на задачах, требующих знаний, будучи при этом более интерпретируемой, поскольку можно проверить, на какие именно фрагменты опирался ответ.

На практике большинство современных продакшен-систем RAG не выполняют полное сквозное совместное обучение ретривера и генератора — это дорого и требует обратного распространения через этап поиска, что нетривиально. Вместо этого используется предобученный, замороженный (или отдельно дообученный) ретривер и генератор, которому просто подают промпт с извлечёнными фрагментами, объединёнными в его контекстном окне. Это упрощение исходной формулировки, и стоит явно проговорить, что это упрощение, поскольку интервьюеры иногда прощупывают именно это различие: «это всё ещё RAG в том смысле, что имели в виду Lewis и соавторы?» Честный ответ таков: это практический, разделённый потомок той же базовой идеи — внешней непараметрической памяти, обусловливающей генератор, — но без совместного сквозного обучения.

4. Dense Passage Retrieval: делаем поиск обучаемым

Поисковая половина такой системы требует собственного ответа на проектный вопрос: как определить, какие фрагменты из корпуса, содержащего, возможно, миллионы или миллиарды их, релевантны данному запросу? Классический ответ, применявшийся десятилетиями в информационном поиске, — разреженное лексическое сопоставление: TF-IDF или BM25, — оценивающее документы по совпадению терминов, взвешенному по информативности каждого термина (редкие термины ценятся выше распространённых). Это работает достаточно хорошо, когда запрос и релевантный фрагмент используют общую лексику, но даёт сбой всякий раз, когда релевантность зависит от смысла, а не от точной формулировки: запрос «кто снял фильм про акулу, терроризирующую прибрежный город» должен извлечь фрагмент про «Челюсти», даже если он ни разу дословно не использует слова «акула» или «прибрежный город».

Karpukhin и соавторы (2020) предложили Dense Passage Retrieval (DPR) как ныне стандартную альтернативу: кодировать запросы и фрагменты в общее непрерывное пространство эмбеддингов с помощью двух обученных энкодеров (обычно трансформерных энкодеров в стиле BERT, один для запросов и один для фрагментов), и определять релевантность как сходство эмбеддингов — обычно скалярное произведение или косинусное сходство между вектором запроса и вектором фрагмента, — а не как лексическое совпадение. Энкодеры обучаются с использованием контрастивной целевой функции: для обучающего запроса, сопоставленного с фрагментом, заведомо релевантным («позитивным»), и набором фрагментов, заведомо нерелевантных (смесь случайных и «трудных» негативов — фрагментов, лексически похожих, но фактически нерелевантных), функция потерь подталкивает эмбеддинг запроса ближе к эмбеддингу позитивного фрагмента и дальше от эмбеддингов негативных, обычно посредством чего-то структурно похожего на softmax по показателям сходства — тот же базовый контрастивный паттерн, который снова появится в обсуждении CLIP в главе 5.3 применительно к согласованию изображений и текста. После обучения поиск сводится к поиску ближайших соседей в пространстве эмбеддингов: закодируйте запрос один раз и используйте эффективный приближённый индекс ближайших соседей по заранее вычисленным эмбеддингам фрагментов корпуса, чтобы найти ближайшие совпадения, — что достаточно быстро для работы при продакшен-объёмах запросов над корпусами с миллионами документов.

Эмпирический результат DPR — то, что плотный (dense) поиск существенно превзошёл разреженный лексический поиск вроде BM25 в задачах открытого вопросно-ответного поиска, — сделал плотные эмбеддинги стандартным механизмом поиска практически в каждом современном конвейере RAG, и именно поэтому «модель эмбеддингов» и «векторная база данных» теперь являются стандартной лексикой при проектировании продакшен-систем на основе LLM.

Плотный поиск всё ещё вынужден наводить мост через асимметрию, которую собственные энкодеры DPR наследуют, а не по-настоящему устраняют: вопрос сформулирован совсем не так, как отрывок, который на него отвечает, а энкодер запроса, обученный сближать их в пространстве эмбеддингов, работает вопреки тому факту, что как текст они попросту не похожи друг на друга. HyDE (Hypothetical Document Embeddings), предложенный Gao с соавторами, обходит это, вовсе не эмбеддируя сырой запрос: вместо этого языковую модель просят написать гипотетический, правдоподобно выглядящий ответ на запрос, без требования, чтобы этот ответ был фактически верным, а эмбеддируется уже этот сгенерированный отрывок для поиска по корпусу. Поскольку гипотетический ответ написан в том же стиле и регистре, что и настоящий отрывок-ответ, — текст в форме документа сопоставляется с текстом в форме документа, — итоговый поиск по сходству обычно оказывается лучшим сигналом, чем прямое сопоставление краткого, по-другому сформулированного вопроса с полным отрывком, ценой дополнительного шага генерации ещё до начала самого поиска.

5. Собираем всё вместе: что реально даёт RAG

Сочетание плотного ретривера в стиле DPR с генератором даёт практическую архитектуру, лежащую в основе почти каждой продакшен-системы RAG: закодировать входящий запрос, извлечь $k$ наиболее похожих фрагментов из векторного индекса по вашему корпусу, объединить эти фрагменты в контексте генератора (часто вместе с запросом) и позволить генератору произвести ответ, обусловленный и запросом, и извлечёнными доказательствами. Ключевое инженерное обещание состоит в том, что корпус теперь становится основным местом, где живут актуальные, исправляемые, проверяемые знания, а модель вносит вклад беглостью, синтезом и рассуждением над предоставленными ей доказательствами — а поскольку извлечённые фрагменты видимы, хорошо спроектированная система может показать свои источники, позволяя человеку убедиться, что ответ не просто выдуман. Это напрямую устраняет оба вида сбоя из раздела 2: устаревание — поскольку обновление корпуса немедленно обновляет то, о чём система может говорить, и галлюцинации — по крайней мере частично, поскольку привязка генерации к извлечённому тексту даёт модели что-то конкретное, на что можно опереться, вместо того чтобы реконструировать факты исключительно из параметрической памяти.

6. Честные виды сбоя

RAG — не волшебное лекарство от галлюцинаций или устаревания знаний, и опытный инженер должен уметь точно назвать её реальные виды сбоя, поскольку интервьюеры прощупывают именно это, чтобы отличить людей, реально развёртывавших RAG в продакшене, от тех, кто лишь читал о ней. Первый и наиболее фундаментальный вид сбоя — то, что качество поиска становится узким местом для качества генерации: если ретривер не находит фрагмент, действительно содержащий ответ — потому что его нет в корпусе, потому что модель эмбеддингов не улавливает нужное сходство, потому что запрос сформулирован так, как ретривер плохо обрабатывает, — генератор работает с неполным или нерелевантным контекстом, и никакая способность генератора не восстановит информацию, которая никогда не была найдена. Это строгая зависимость «мусор на входе — мусор на выходе», и на практике это означает, что большая часть усилий по построению хорошей системы RAG уходит на качество поиска — стратегию разбиения на фрагменты (chunking), выбор модели эмбеддингов, гибридный разреженно-плотный поиск, переранжирование (re-ranking) — а не на сам генератор.

Во-вторых, даже когда поиск успешен и правильный фрагмент действительно находится в контекстном окне, генератор всё равно может проигнорировать его, неправильно истолковать или перекрыть противоречащим ему параметрическим убеждением; предоставление верного контекста необходимо, но не достаточно для верного вывода, потому что внимание генератора над его контекстом — не гарантированный, достоверный механизм поиска. В-третьих, RAG никак не устраняет сбои рассуждения: если вопрос требует многошагового инференса над извлечёнными фактами — объединения двух фрагментов для получения того, что ни один из них не утверждает напрямую, — поиск лишь поставляет сырой материал, а способность генератора к рассуждению (тема главы 5.1) по-прежнему должна проделать реальную работу, со всеми теми же ограничениями. В-четвёртых, и это часто недооценивают, — синтез из нескольких документов: сшивание нескольких извлечённых фрагментов, возможно, из разных документов с разными формулировками, контекстами или даже противоречиями, не производит автоматически связного, корректно согласованного ответа — генератор может смешать детали из разных фрагментов, приписать факт из одного документа другому или попросту не заметить противоречие, которое заметил бы внимательный человек-читатель. Строгая продакшен-система обычно вынуждена решать эти виды сбоя с помощью дополнительных механизмов — переранжирования, проверок обоснованности цитирования, обнаружения противоречий, — ни один из которых не «решён» одной лишь базовой архитектурой RAG.

Стоит назвать два дальнейших расширения, поскольку они атакуют конкретные виды сбоя выше, а не являются общими улучшениями. GraphRAG, описанный исследователями Microsoft, напрямую нацелен на проблему синтеза из нескольких документов: вместо того чтобы полагаться исключительно на поиск ближайших соседей по независимым фрагментам, он сначала заставляет LLM извлечь из корпуса сущности и связи в граф знаний, а затем строит саммари по кластерам («сообществам») связанных сущностей в этом графе, так что запрос, требующий чего-то, охватывающего весь корпус, — «какие повторяющиеся темы прослеживаются во всех этих документах» — можно ответить из саммари уровня сообществ графа, а не требовать от ретривера как-то самостоятельно найти каждый по отдельности релевантный фрагмент с нуля, с чем обычный поиск ближайших соседей по независимым отрывкам структурно справляется плохо. Agentic RAG вместо этого решает проблему сбоя многошагового рассуждения: вместо фиксированного однопроходного конвейера «поиск-затем-генерация» модель обращается с поиском как с инструментом, который можно вызывать многократно и адаптивно (это напрямую тема главы 5.4), — выдавая запрос, изучая, что вернулось, переформулируя запрос или выдавая последующий, если свидетельств недостаточно, и самостоятельно решая, когда собрано достаточно, чтобы ответить, а не привязываясь к тому, что случайно нашёл единственный исходный проход поиска.

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

7. Взгляд с точки зрения собеседования

Вопрос: Проведите меня через то, как бы вы спроектировали систему RAG для внутренней документации компании, и что бы вы оптимизировали в первую очередь? Сильный ответ определяет качество поиска как основное узкое место, ещё до того, как трогать генератор: стратегию разбиения на фрагменты (как документы делятся так, чтобы фрагмент был извлекаем как связная единица), выбор модели эмбеддингов и, возможно, доменное дообучение, гибридный поиск, сочетающий плотные (в стиле DPR) и разреженные (BM25) сигналы для покрытия и семантических запросов, и запросов с точным лексическим совпадением, а также этап переранжирования над кандидатами перед финальной сборкой контекста. Он должен явно указать, что более сильный генератор не может компенсировать ретривер, который никогда не находит нужный фрагмент.

Вопрос: В чём реальное отличие метода из исходной статьи о RAG от того, как «RAG» используется на практике сегодня? Сильный ответ отмечает, что исходная формулировка Lewis и соавторов совместно обучает ретривер и генератор сквозным образом, маргинализируя по извлечённым документам как скрытой переменной, тогда как большинство продакшен-систем используют замороженный или отдельно обученный ретривер и просто промптируют генератор объединёнными извлечёнными фрагментами — разделённое, несквозное упрощение той же базовой идеи, выбранное потому, что совместное обучение через этап поиска дорого и операционно неудобно.

Вопрос: Почему плотный поиск (DPR) превосходит TF-IDF/BM25 во многих постановках, и когда разреженный поиск всё же может победить? Сильный ответ объясняет, что плотный поиск улавливает семантическое сходство через обученные эмбеддинги и контрастивную целевую функцию обучения, поэтому может сопоставить запрос с релевантным фрагментом даже без пересечения лексики, тогда как BM25 зависит от общих терминов. Также стоит отметить контрапункт: BM25 может превосходить плотный поиск для запросов, завязанных на точных терминах — редких идентификаторах, кодах товаров, точных фразах, — где лексическое совпадение и есть верный сигнал, поэтому многие продакшен-системы используют гибридный поиск, а не только плотный.

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

Вопрос: Как бы вы обнаруживали и снижали галлюцинации в системе на основе RAG? Сильный ответ охватывает проверки обоснованности (проверку того, что сгенерированные утверждения действительно подкреплены извлечёнными фрагментами, например, через проверку логического следования или привязку к цитированию), ужесточение инструкций генератора, чтобы он воздерживался от ответа при недостаточном извлечённом контексте, и чётко отмечает, что это меры, наложенные поверх RAG, а не доказательство того, что RAG «решает» галлюцинации полностью.

8. Вопросы для самопроверки

1. Каковы два различных вида сбоя чисто параметрической памяти, мотивирующих дополнение поиском, и почему ни один из них не устраняется одним лишь улучшением промптинга?
2. Выпишите формулировку RAG со скрытой переменной по Lewis и соавторам и объясните, что представляют собой $P(z \mid q)$ и $P(y \mid q, z)$.
3. В чём именно большинство продакшен-систем RAG отклоняются от исходной формулировки со сквозным совместным обучением?
4. Чем DPR определяет релевантность иначе, чем BM25, и какая целевая функция обучения используется для обучения энкодеров запросов и фрагментов?
5. Почему качество поиска описывается как строгое узкое место для качества генерации, а не просто один из многих влияющих факторов?
6. Приведите пример сбоя RAG, происходящего даже тогда, когда ретривер находит именно нужный фрагмент.
7. Почему дополнение поиском не устраняет сбои многошагового рассуждения и как это связано с обсуждением рассуждения в главе 5.1?

9. Источники

• Lewis, P., Perez, E., Piktus, A., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arXiv:2005.11401. https://arxiv.org/abs/2005.11401
• Karpukhin, V., Oğuz, B., Min, S., et al. (2020). Dense Passage Retrieval for Open-Domain Question Answering. EMNLP 2020. arXiv:2004.04906. https://arxiv.org/abs/2004.04906
• Gao, L., Ma, X., Lin, J., & Callan, J. (2022). Precise Zero-Shot Dense Retrieval without Relevance Labels (HyDE). arXiv:2212.10496. https://arxiv.org/abs/2212.10496
• Edge, D., Trinh, H., Cheng, N., Bradley, J., Chao, A., Mody, A., Truitt, S., & Larson, J. (2024, Microsoft Research). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130. https://arxiv.org/abs/2404.16130