Инженерия контекста: почему RAG ломается в проде

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

«Векторная база с промптом» — это прототип

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

Индекс устаревает. Документы меняются, а индекс пересобирается раз в неделю по расписанию или вручную. Система отвечает по старому регламенту, формально уверенно. Пользователь не видит, что ответ устарел — он видит уверенный ответ.

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

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

Из чего состоит работающий RAG

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

Гибридный поиск и переранжирование. Плотный (векторный) поиск находит кандидатов по смыслу, лексический отсекает «похоже, но не то», переранжирование расставляет по релевантности к конкретному запросу. В контекст идёт не топ-N по косинусной близости, а переранжированный минимум.

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

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

Где обычно проходит граница

Несколько практических наблюдений:

• Если на демо качество отличное, а в проде «иногда врёт» — почти всегда виноват не retrieval-алгоритм, а свежесть индекса и отсутствие переранжирования. Это первое, что нужно проверять, а не менять модель.
• «Добавим больше контекста» чаще ухудшает, чем улучшает. Точность ответа сильнее зависит от того, насколько контекст релевантен, чем от того, насколько он полон.
• Обоснованность важнее беглости. Ответ, который честно говорит «в источниках этого нет», полезнее уверенного домысла — но это поведение нужно специально проектировать и проверять, само оно не появится.

Вывод

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