RAG в продакшене: 5 решений, которые отличают рабочую систему от демо

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

Решение 1. Чанкинг — это решение про поиск, а не про текст

Первая версия пайплайна использовала фиксированные куски по 512 токенов. Так делают во всех туториалах, поэтому казалось безопасным. Но для 40% документов такой подход не подходил. В базе были технические мануалы, ветки поддержки и внутренние спеки. В мануалах нумерованные шаги разбиваются между чанками; в ветках поддержки вопрос висит в начале, а принятый ответ — через десять абзацев. Фиксированные куски одинаково ломали оба сценария: смысловая единица — законченный шаг или связка «вопрос-ответ» — разрезалась посреди предложения.

Мы перешли на чанкинг по структуре: для мануалов — по заголовкам, для веток — по границам обсуждения, для кода — по блокам кода. Точность поиска на оценочном наборе выросла с 61% до 83%. Не потому, что изменились эмбеддинги. Потому, что изменились единицы. Если ваши чанки не совпадают с атомарными единицами, которые человек процитировал бы в ответе, никакой реранкинг не спасёт.

Решение 2. Гибридный поиск побеждает чистый векторный

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

Мы добавили BM25 как параллельный ретривер и объединили результаты с весовым скором до реранкинга. Теперь точные запросы почти всегда выводят нужную страницу в топ-3. Урок скучный, но важный: гибридный поиск (вектор + ключевые слова) — это базовая норма для продакшен-RAG в 2026 году, а не оптимизация. Если вы отдаёте пользователям, которые вводят названия продуктов и коды ошибок, чистый векторный поиск — вы отдаёте демо.

Решение 3. Свежесть важнее релевантности

Самая коварная ошибка — уверенный ответ, который уже устарел. В базе было 12 000 документов, около 8% менялось ежемесячно. Вторая версия пайплайна искала «семантически самый близкий чанк» — и часто это была страница с ценами за прошлый квартал. Пользователи не жаловались на неверный ответ. Они молча теряли доверие и переставали спрашивать.

Исправление состояло из трёх частей:

1. Метка версии на каждом документе — каждый чанк хранит дату обновления.
2. Бонус за свежесть в скор-функции — если два чанка различаются менее чем на 15%, побеждает более новый.
3. Периодическое обновление — ночная задача проверяет изменённые источники и переиндексирует только затронутые чанки, а не весь корпус.

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

Решение 4. Реранкинг — лучшее вложение в качество

Все спрашивают, какую модель эмбеддингов взять. В наших бенчмарках апгрейд модели эмбеддингов улучшил качество поиска на 4–6 пунктов. Добавление кросс-энкодера поверх топ-20 кандидатов дало 12 пунктов — вдвое больше за небольшую часть стоимости индексации (реранкинг работает на запросе и касается только уже найденных кандидатов).

Мы используем маленький кросс-энкодер, который обрабатывает запрос за ~30 мс на CPU. Пайплайн забирает 20 кандидатов из гибридного поиска, сжимает до 5 и отдаёт их LLM. Пользователи заметили разницу сразу.

Retrieve cheap, rerank precise, generate last — вот архитектура, которая делает систему «умной».

Решение 5. Оценка — это задача про данные, а не про метрики

Мы собрали оценочный набор из 200 реальных запросов с эталонными ответами, написанными экспертами. Любое изменение пайплайна — новый чанкинг, новый реранкер, новый промпт — проверяется на этом наборе. Звучит очевидно, но именно этого не хватает большинству демо. Без базовой линии невозможно понять, стало лучше или хуже.

Набор версионируется в git вместе с кодом. Когда пользователь сообщает о плохом ответе, этот случай добавляется в оценку до того, как мы что-то чиним. Так «исправить баг» и «не допустить регресс» становятся одной задачей. Точность ответов выросла с 74% на старте до 91% сейчас — и именно оценочный набор позволил доказать, что каждый шаг что-то улучшил.

Демо и продакшен: таблица различий

Как выглядит рабочий пайплайн

1. Загрузка — чанкинг по структуре, под каждый тип документа.
2. Индексация — эмбеддинги + BM25, оба пишутся на этапе загрузки.
3. Поиск — гибридный запрос отдаёт 20 кандидатов.
4. Реранкинг — кросс-энкодер оставляет 5.
5. Генерация — LLM получает 5 чанков с метаданными источника и меткой версии.
6. Оценка — каждый ответ логируется, плохие становятся новыми кейсами.

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

Если вы строите RAG, начните с решений 1 и 5 — чанкинга и оценки. Они наименее эффектные и наиболее решающие. Модель редко бывает вашим узким местом. Ваш контент-пайплайн — да.