Как создать RAG-систему, которая не врёт в проде

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

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

RAG (retrieval augmented generation) задумывался как способ убрать выдумку: модель отвечает не из памяти, а по найденному фрагменту. Но сам по себе RAG галлюцинации не убирает — он переносит их с уровня модели на уровень поиска. Если найден не тот фрагмент или фрагмент устарел, модель аккуратно и убедительно перескажет неправильное.

Гипотеза: качество RAG определяется инженерией контекста, а не моделью

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

Из этого следует, что строить RAG-систему — это в основном строить конвейер контекста, а не подбирать модель.

Проблема: демо работает на статике, прод — на изменениях и объёме

У демо три удобства, которых нет в проде. Документов мало, поэтому почти любой поиск возвращает релевантное. Документы не меняются, поэтому ответ не устаревает. Вопросы задают «правильные», близкие к тексту источника.

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

Почему обычные подходы не работают

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

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

Инженерная модель: конвейер, а не «база плюс модель»

Работающая RAG-система — это конвейер с явными слоями.

Нормализация источников. Разные форматы приводятся к единому виду, у каждого фрагмента есть метаданные: источник, версия, дата, права доступа. Без этого нельзя ни отсечь устаревшее, ни ограничить выдачу по пользователю.

Индексация по событиям, а не по расписанию. Индекс обновляется тогда, когда меняется источник (документ переподписан, регламент отменён), а не раз в сутки «пакетом». Устаревший ответ — это почти всегда индекс, отставший от реальности.

Гибридный поиск с переранжированием. Векторный поиск даёт семантические кандидаты, лексический — точные совпадения терминов и номеров; затем отдельный шаг переранжирования отбирает из кандидатов те, что действительно отвечают на вопрос. Это тот шаг, которого нет в наивной схеме и который сильнее всего влияет на «не врёт / врёт».

Бюджет контекста. В модель подаётся не «всё найденное», а переранжированный минимум в пределах заданного лимита токенов. Это одновременно про качество (меньше смешивания источников) и про стоимость (контекст не растёт тихо).

Оценка обоснованности. Для части трафика автоматически проверяется, опирается ли ответ на поданные фрагменты, и нет ли утверждений «из воздуха». Это превращает «кажется, работает» в измеримую величину.

Практический вывод для бизнеса

Что из этого следует для решения о проекте.

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

Цена ошибки определяет архитектуру, а не наоборот. Там, где неверный ответ — это юридический или финансовый риск, отсутствие ответа дешевле уверенной ошибки; система должна уметь молчать. Это проектное решение, принимаемое до разработки.

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

Приложить это к вашим процессам — обсудить с инженером → .

Открытые вопросы

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

Если у вас есть база знаний, по которой люди отвечают вручную, и цена ошибки в ответе высока — это кандидат на RAG, сделанный как система, а не как демо. Обсудить ваш случай → — разберём источники, частоту изменений и где проходит граница «честно не знаю».