RAG в проде: 6 правил, как не превратить AI-агента в генератора лжи

Обратите внимание на изображение, оно фиксирует главный сдвиг, который делает RAG практичной архитектурой. Слева - источник знаний: документы, регламенты, wiki, инструкции. Справа - модель, которая умеет качественно генерировать ответь. Между ними - RAG и две стрелки, которые задают порядок действий: сначала RETRIEVE (извлечь, найти), потом GENERATE (сгенерировать, сформулировать ответ). И в этом порядке вся суть.

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

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

RETRIEVE (извлечь, найти) на картинке - отдельный шаг не случайно. Это не кнопка поиска. Это цепочка решений, которая определяет, что именно попадет в контекст модели. Внешними источниками могут быть база знаний, Notion/Confluence, файлы PDF и DOCX, договоры и приложения, тарифные таблицы и оферты, тикеты поддержки, логи, CRM и продуктовые данные. Чтобы RETRIEVE работал надежно, корпус знаний нужно подготовить, документы разбить на осмысленные фрагменты, проиндексировать (часто через эмбеддинги и векторный поиск), отфильтровать по правам доступа и актуальности, а затем правильно ранжировать. Главная идея здесь жесткая: сначала найти факты, а не сразу генерировать текст.

GENERATE (сгенерировать, сформулировать ответ) - это шаг, где модель получает найденные фрагменты и отвечает, опираясь на них. В продакшене это всегда про правила: отвечать по переданным данным, не придумывать числа, условия и формулировки, и если фактов не хватает - честно сказать, чего именно не хватает, и попросить уточнение. Смысл GENERATE в RAG не в том, чтобы модель стала умнее, а в том, чтобы ее ответ был ограничен тем, что реально извлечено на предыдущем шаге.

Дальше важная оговорка, без которой картинка вводит в заблуждение. RAG снижает галлюцинации только тогда, когда RETRIEVE приносит правильные и актуальные фрагменты. Если данные плохие (дубли, противоречия, устаревшие версии, кривая структура PDF, разорванные таблицы) или поиск устроен неправильно (неверное разбиение на фрагменты, слабое ранжирование, нет фильтров по версии и правам), модель будет уверенно отвечать неправильно, и это будет выглядеть даже убедительнее, потому что рядом появится видимость опоры на источники. Поэтому в продакшене RAG оценивают не по гладкости текста, а по тому, какие фрагменты реально извлекаются на запрос и насколько они актуальны.

Если с картинкой и логикой RAG всё ясно, следующий шаг - не усложнять, а правильно расставить приоритеты. Вот шесть уроков, которые собирают RAG в работающую систему.

Самая дорогая формулировка в RAG-проектах - @пусть отвечает на внутренние вопросы». Это не сценарий. Сценарий - когда понятно, кто спрашивает, что именно он хочет сделать, и что считается правильным результатом.

Я фиксирую задачу через три вопроса:

• Какое решение человек должен принять после ответа, или какое действие он должен сделать.
• Какие документы являются источником истины для этого решения.
• Как выглядит правильный ответ: коротко, со ссылкой на раздел, с условиями и исключениями, с датой версии.

Если вы не можете измерить ценность в сэкономленном времени, снижении ошибок или уменьшении ручных уточнений, RAG превращается в «потому что у всех есть». Это плохая причина. Рынок прощает отсутствие ассистента. Рынок не прощает ассистента, который врет.

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

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

Минимум, который я бы заложил сразу:

• Убрать дубли и противоречивые версии, оставить одну действующую.
• Привести документы к читабельному виду, особенно PDF с таблицами и разрывами строк.
• Добавить метаданные: версия, дата, статус действует или устарело, владелец документа.
• Ввести простые проверки пайплайна: пустые фрагменты, битые кодировки, слишком короткие куски, повторяющиеся фрагменты.

Никакая умная модель не компенсирует ситуацию, когда данные сами по себе плохие.

Если фрагменты нарезаны по токенам или по символам, вы почти гарантированно разрежете мысль пополам. А потом модель додумает вторую половину. Иногда красиво. Иногда не очень.

Хорошее разбиение делает одну вещь: каждый фрагмент должен быть самодостаточным по смыслу. Чтобы его можно было прочитать отдельно и понять, о чём речь, без догадок.

Практика, которая обычно работает:

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

Это способ не дать RETRIEVE приносить обрывки, по которым потом невозможно отвечать аккуратно.

Самая незаметная причина, почему RAG со временем деградирует - устаревшие эмбеддинги. Документы обновились, правила поменялись, а векторная база продолжает выдавать прошлую реальность. Ответы становятся не просто неверными. Они становятся уверенно неверными, потому что выглядят как подкреплёнными источниками.

Обновление векторной базы технически тяжелее, чем обновление SQL.

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

Рабочая стратегия обычно событийная.

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

Если у вас нет механики обновления, вы строите систему, которая неизбежно начнет лгать со временем.

Если вы не измеряете качество, вы не управляете системой. В RAG проблемы почти всегда проявляются через пользователей: ответы начинают казаться странными, доверие падает, и люди просто возвращаются к ручному поиску.

Оценка RAG должна быть многоуровневой, потому что система тоже многоуровневая:

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

И есть важная дисциплина: проверять надо не «красоту текста», а фактическую опору. Какие именно фрагменты система достала под вопрос. Если внизу лежит не то - наверху будет неправда, даже если она звучит уверенно.

Я регулярно вижу, как команды тащат agentic workflow просто потому, что слово agent сейчас везде. Это почти всегда преждевременно. Сложность добавляет стоимость, задержку, точки отказа и новые классы ошибок.

Почти всегда правильный порядок такой:

• Базовый RAG. Нашли нужные фрагменты, ответили строго по ним.
• RAG с уточнением запроса. Сначала система переформулирует вопрос в точный поисковый запрос, потом извлекает фрагменты и отвечает. Подходит, когда пользователь пишет расплывчато.
• RAG со сценариями. Используется, когда одного ответа мало и нужно выполнить цепочку шагов: найти, сравнить, собрать краткую выжимку, подготовить черновик письма, сформировать задачу. Здесь поиск и ответ - лишь часть процесса.

RAG - это не способ сделать модель умнее. Это способ не дать ей врать. Вы выигрываете не за счет магии ИИ, а за счет дисциплины: сначала найти факты в актуальных документах, потом сформулировать ответ строго по ним.

Шесть правил сводятся к одному: доверие держится на поиске и данных. Модель может быть сильной, интерфейс - удобным, но если система приносит в контекст не те фрагменты, устаревшие версии или обрывки смысла, она будет уверенно ошибаться. А доверие к таким системам восстанавливается тяжело: пользователи быстро возвращаются к ручному поиску и редко дают второй шанс.

RAG (Retrieval-Augmented Generation) - подход, при котором ассистент сначала извлекает факты из базы знаний, и только потом формирует ответ на их основе.
Извлечение (Retrieve) - шаг, на котором система ищет и выбирает релевантные фрагменты из документов, базы знаний, тикетов, CRM и других источников.

Генерация (Generate) - шаг, на котором модель формирует ответ, опираясь на найденные фрагменты, а не на догадки.

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

Смысловые фрагменты - части документа, на которые его делят для поиска. Хороший фрагмент самодостаточен по смыслу и не рвет определения, условия, исключения и шаги инструкций.

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

Векторная база - хранилище, где лежат эмбеддинги фрагментов и откуда система быстро достает кандидатов для ответа.

Ранжирование - правила, по которым система выбирает лучшие фрагменты из найденных и ставит их выше остальных.

Фильтры по доступам и актуальности - ограничения, которые не дают извлечению возвращать устаревшие документы и данные, а также защищают информацию по ролям и правам.

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

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

Галлюцинации - ситуация, когда модель уверенно придумывает факт. RAG снижает риск, но не спасает, если извлечение принесло неправильные или устаревшие фрагменты.