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

Закономерным ответом на эту проблему стал RAG (Retrieval-Augmented Generation) — подход, который дает LLM поисковик по актуальной внешней базе и «заставляет» опираться только на выданный контекст. В этой статье разберем по шагам, как устроен этот механизм, почему он снижает число галлюцинаций и где RAG всё же дает слабину.

Почему LLM галлюцинируют?

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

В фазе претрейна LLM работает как продвинутая статистическая машина для предсказания следующего токена. Нейросеть не мыслит понятиями правды или лжи, она оперирует вероятностями. Ее базовая задача — сгенерировать текст, который будет максимально правдоподобным с точки зрения выученных языковых паттернов.

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

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

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

Казалось бы, если нужной информации в весах нет, почему бы просто ответить «я не знаю». Но здесь в дело вмешивается этап выравнивания. В процессе SFT (Supervised Fine-Tuning) мы целенаправленно учим модель быть полезной и выполнять инструкции. Побочным эффектом такого тюнинга становится потеря способности к отказу: модель приучается генерировать ответ при любых обстоятельствах.

Ситуацию усугубляет RLHF (Reinforcement Learning from Human Feedback). Оно оптимизирует метрику полезности по человеческим оценкам, и модель приобретает склонность к сикофантии как побочный эффект. Если пользователь заложит в промпт ложную предпосылку или спорное утверждение, модель вероятнее всего подстроится под него, так как алгоритм поощряет ответы, с которыми человеку комфортно согласиться.

В итоге становится очевидно, что для создания надежных систем необходимо разделить «мозги» и «память». Языковая модель должна отвечать исключительно за понимание запроса и формулирование ответа, а источником фактуры должна служить независимая, легко обновляемая база данных. Это понимание и привело индустрию к концепции Retrieval-Augmented Generation.

Что такое RAG?

В 2020 году исследователи формализовали подход, который решал проблему статических весов и галлюцинаций. Они предложили архитектуру Retrieval-Augmented Generation (RAG).

Суть концепции сводится к созданию гибридной системы, которая оперирует двумя типами памяти: 

1. Первый тип — параметрическая память (parametric memory). Это сами веса предварительно обученной языковой модели, ее «мозги», отвечающие за понимание языка, логику и синтез текста.

2. Второй — непараметрическая память (non-parametric memory). Это внешняя база знаний, например, векторный индекс корпоративной документации или просто выгрузка из источника, которую можно обновлять сколько угодно и когда угодно без какого-либо файнтюнинга самой нейросети.

Вместо того чтобы заставлять модель по памяти отвечать на сложные вопросы (что, как мы выяснили, чревато выдумками), RAG переводит LLM в режим работы с документами. Исследователи называют эту базовую схему парадигмой Retrieve-Read («Найди и прочитай»). Когда поступает запрос, система сначала обращается к внешней базе, достает релевантные куски текста, и только потом отдает их языковой модели вместе с изначальным промптом. По сути, мы ставим перед моделью задачу: «Вот вопрос, а вот набор сырых фактов — сформулируй итоговый ответ, опираясь на этот контекст».

Это дает два практических преимущества. Во-первых, можно «на лету» подменять базу знаний (index hot-swapping). Дообучать модель под каждый новый регламент — долго и дорого, из-за таких задержек знания LLM будут отставать от реальности. С RAG же в этом плане проще: вы просто обновляете внешнюю базу, и нейросеть сразу начинает отвечать с учетом новых знаний. Во-вторых, система становится прозрачной — мы всегда можем проследить, на какой именно документ сослалась нейросеть при генерации ответа.

Как RAG работает

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

Шаг 1. Индексирование: подготовка и хранение базы знаний

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

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

Чтобы обойти эту проблему, в продвинутых RAG-системах применяют более гибкие подходы. Например, используют скользящее окно (sliding window), когда чанки нарезаются с небольшим нахлестом текста друг на друга для сохранения связности. Или применяют стратегию Small2Big, когда текст индексируется на уровне отдельных предложений, но если алгоритм находит нужное предложение, он вытягивает из базы окружающие его предложения, давая языковой модели более полный контекст.

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

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

Шаг 2. Поиск: извлечение релевантных фрагментов

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

И здесь система сталкивается со второй проблемой: люди часто формулируют вопросы плохо. Они пестрят аббревиатурами, скрытыми контекстами или состоят из нескольких подвопросов. Поэтому сырой запрос редко отправляется в базу как есть — поверх базового пайплайна добавляют опциональный слой оптимизации запроса. К примеру, один из таких методов улучшения — query rewriting: вспомогательная модель переформулирует вопрос в более подходящий для поиска вид. Другой, более замысловатый — HyDE: языковую модель просят сгенерировать гипотетический (пусть даже выдуманный) ответ на вопрос пользователя, а затем система ищет в базе совпадения не по исходному короткому вопросу, а по этому сгенерированному тексту. Как ни иронично, поиск по галлюцинации отлично помогает найти реальные факты, так как сокращает семантический разрыв.

С годами этап поиска, конечно, во многом эволюционировал. Классический семантический поиск отлично улавливает контекст, но дает слабину, когда нужно найти точный артикул детали или специфическую фамилию. Чтобы закрыть эту дыру, индустрия пришла к гибридному поиску (Hybrid Retrieval), который объединяет векторы и старый добрый поиск по ключевым словам (BM25). 

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

Шаг 3. Генерация: формирование ответа с опорой на найденный контекст

На финальном этапе у нас на руках есть отсортированный список качественных чанков и исходный запрос. Теперь «память» должна передать эстафету «мозгам». 

Чаще всего применяется подход раннего слияния (Early Fusion). Найденные текстовые фрагменты физически вклеиваются в единый промпт. В итоге модель видит жесткую системную инструкцию: «Отвечай на вопрос только на основе фактов ниже. Если ответа там нет, скажи, что не знаешь. [Чанк 1, Чанк 2...]. Вопрос: ...». 

Если чанков много, возникает риск эффекта lost-in-the-middle: модель лучше обрабатывает начало и конец контекстного окна, а середина нередко выпадает из внимания. Один из способов борьбы с этим — контекстная компрессия: в модульных RAG-архитектурах перед подачей в генератор контекст пропускают через модель-компрессор вроде LLMLingua, которая удаляет незначимые токены и уплотняет текст до формата, трудновоспринимаемого для человека, но эффективно воспринимаемого языковой моделью.

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

Что RAG дает на практике

Во-первых, снижение галлюцинаций, что логично вытекает из самой механики. Как мы уже выяснили на этапе генерации, благодаря RAG нейросети больше не нужно мучительно угадывать факты из своих статических весов — она работает как аналитик с предоставленным документом. В результате, как показали еще первые тесты, эксперты в независимой оценке признавали ответы RAG фактически точнее в 42,7% случаев против 7,1% у модели без поиска по базе. Но снижение галлюцинаций — это скорее следствие архитектуры, чем самостоятельное преимущество. 

Возьмем проблему актуальности данных. Мир меняется каждый день: выходят новые законы, обновляются финансовые отчеты и регламенты. В классической парадигме пришлось бы постоянно дообучать модель, надеясь, что она усвоит новые факты. Выше мы уже упоминали, что в RAG реализован принцип подмены индекса на лету. Насколько это эффективно, создатели архитектуры из Facebook AI показали в наглядном эксперименте еще в 2020 году с базовой версией метода. Они собрали список из 82 мировых лидеров, которые сменяли посты в период с 2016 по 2018 год. Затем они подменили под капотом модели старый дамп Википедии за 2016 год на новый за 2018-й, и запустили одну и ту же модель на двух разных индексах. С совпадающим индексом точность составила 68–70%, с несовпадающим — упала до 4–12%. 

Вторая боль — это проверяемость. Для бизнеса языковая модель — это черный ящик. Если бот техподдержки называет клиенту размер штрафа, нужно понимать, откуда взялась эта цифра. Поскольку в RAG каждый факт в ответе привязан к конкретному чанку, система возвращает не только красивый ответ, но и метаданные источника. В реализациях вроде SELF-RAG, генератор обучают выдавать служебные токены самооценки (reflection tokens). Модель буквально сама себя проверяет на каждом шаге: нужен ли вообще поиск, релевантен ли найденный документ, и действительно ли сгенерированный ответ полностью подтверждается тем, что принес ретривер. И если факт выдуман, система это отловит. 

Наконец, RAG позволяет безопасно работать с закрытыми корпоративными данными. Поднимать собственную LLM уровня GPT с нуля в изолированном контуре дорого, RAG же позволяет использовать относительно легкие on-premise опенсорс-модели в связке с защищенной внутренней базой. Например, Rocket Companies используют RAG для ускорения обработки ипотечных кредитов на основе своих проприетарных финансовых документов, а корпорация Bayer интегрировала эту архитектуру для управления сельскохозяйственными данными, чтобы выдавать фермерам точные рекомендации из закрытых баз. Секретная информация не «зашивается» в веса нейросети, а лежит в контролируемом векторном индексе, к которому легко прикрутить ролевую модель доступа: если у сотрудника нет прав на чтение документа, ретривер его просто не достанет.

Ограничения RAG и подводные камни

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

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

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

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

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

В-третьих, это банально дороже. RAG требует дополнительных вызовов LLM, а в саму генеративную модель каждый раз отправляется контекст из найденных чанков. Чем больше токенов на входе, тем выше итоговые счета за API или вычислительные мощности. 

К тому же RAG создает дополнительные лазейки для атак по данным. Если в системе лежит закрытая медицинская или финансовая база, злоумышленники могут с помощью инъекций промптов заставить модель выдать конфиденциальные куски из векторной базы. Что касается этики, система работает как увеличительное стекло для человеческой предвзятости. Модель отбирает информацию по релевантности. Но релевантность — не то же самое, что объективность: предвзятый текст может отлично совпадать с запросом по смыслу. Если внешняя база перекошена в сторону определенного мнения или содержит заблуждения, ретривер послушно принесет эти данные, а генератор завернет их в связный, экспертно звучащий ответ.

Вместо вывода: когда RAG действительно нужен

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

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

К тому же, RAG не стоит на месте. Появляются подходы, закрывающие пробелы базовой версии. Например, Modular RAG превращает систему в конструктор, где можно комбинировать разные алгоритмы и на лету обращаться к внешним инструментам. Для аналитических задач набирает популярность Graph RAG, который помогает модели распутывать сложные логические связи с помощью графов знаний. А наиболее «модным» в текущих реалиях выглядит Agentic RAG — подход, при котором автономный ИИ-агент сам управляет процессом: декомпозирует запрос, итеративно ищет данные и решает, когда информации достаточно для ответа. И это только начало списка.

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