RAG в production: что меняется после демо
Демо RAG делается за полдня: загрузить документы, посчитать embeddings, задать вопрос, получить хороший ответ. Система в production это другой проект. Модель в ней самая маленькая часть. Основная работа в том, что попадает в индекс, что из него достаётся, кому это можно видеть и как понять, что ответы всё ещё верны через месяц.
Кратко
Работает ли RAG в production, решают восемь областей: загрузка, которая сохраняет структуру документа и метаданные; поиск, который сочетает векторы с поиском по ключевым словам и reranker; актуальность, чтобы изменённые и удалённые документы уходили из индекса; права доступа, которые применяются до поиска, а не в промпте; оценка на фиксированном наборе вопросов с известными источниками; ссылки и отказы, чтобы система отвечала только по найденному; безопасность от инструкций, спрятанных в документах; и observability для каждого этапа. Выбор архитектуры разобран в отдельной статье, а эта статья про эксплуатацию.
1. Загрузка: что попадает в индекс
Документы лучше резать по структуре, а не по фиксированному числу символов. Фрагмент, который начинается посреди таблицы или разрывает инструкцию пополам, хуже находится и ещё хуже отвечает. Заголовки нужно держать вместе с текстом под ними, таблицы не резать.
С каждым фрагментом нужно хранить метаданные: источник, версию, дату изменения и кто может его читать. От этого потом зависят и качество поиска, и актуальность, и права доступа.
Модель embeddings это часть индекса. Сменили модель, и все векторы нужно пересчитать. Храните имя модели рядом с векторами, чтобы частичная переиндексация была видна.
2. Поиск: что достаётся из индекса
Чисто векторный поиск плохо справляется с точными терминами: артикулами, номерами деталей, именами и сокращениями. Гибридный поиск добавляет к векторам поиск по ключевым словам и объединяет результаты. Затем reranker переставляет лучших кандидатов по тому, насколько каждый из них отвечает на вопрос.
Сколько фрагментов передавать модели, подбирают на своих вопросах, а не берут по умолчанию. Если их слишком мало, ответ теряет контекст; если слишком много, нужный фрагмент тонет в шуме, а стоимость растёт.
3. Актуальность: когда документы меняются
Нужно инкрементально переиндексировать документы при изменениях и следить, чтобы удаления доходили до индекса. Документ, удалённый из источника, но оставшийся в индексе, продолжает отвечать на вопросы.
Удаление нужно проверять подсчётом, а не по ответу. Некоторые векторные хранилища сообщают, что удаление по фильтру выполнено, даже если фильтр ничего не нашёл. Посчитайте точки до и после: только это доказывает, что старого содержимого больше нет.
4. Права доступа: до поиска, а не в промпте
Если разные пользователи могут видеть разные документы, фильтр должен стоять прямо в поисковом запросе, по правам, сохранённым с каждым фрагментом. Просьба к модели не раскрывать то, что пользователю нельзя видеть, это не контроль доступа: как только фрагмент попал в контекст, он может попасть и в ответ.
5. Оценка: как понять, что всё ещё работает
Соберите фиксированный набор реальных вопросов и для каждого определите документы, которые должны на него отвечать. Измеряйте отдельно две вещи: находит ли поиск правильные источники и остаётся ли ответ верен им. Прогоняйте этот набор при каждом изменении нарезки, embeddings, настроек поиска или промпта.
В production стоит добавить LLM-as-judge на небольшой выборке реальных ответов и следить за отзывами пользователей. Падение любого из этих показателей обычно становится первым признаком того, что изменился индекс или сами вопросы.
6. Ссылки и отказы
Требуйте от системы отвечать только по найденному контексту, указывать источник каждого утверждения и говорить «не знаю», если ничего подходящего не нашлось. Следите за долей отказов: если она растёт, это указывает на дыры в индексе; если она около нуля, это часто значит, что система угадывает.
7. Безопасность: инструкции, спрятанные в документах
Найденный текст это данные, а не инструкции. Документ, письмо или веб-страница в индексе могут содержать текст, написанный так, чтобы управлять моделью, и RAG доставит его прямо в контекст. Помечайте найденное содержимое в промпте как недоверенное, ограничивайте инструменты, которые модель может вызывать, и убирайте персональные данные до индексации и до записи в логи.
8. Observability: каждый этап отдельно
Трассируйте поиск, reranking и генерацию как отдельные шаги, с задержкой, числом фрагментов и токенов на каждом этапе. Когда ответ неверный, трасса показывает, пропустил ли поиск источник или модель его проигнорировала, а для этих случаев нужны разные исправления.
Частые вопросы
Какие практики важны для RAG в production?
Нарезка по структуре с метаданными, гибридный поиск с reranker, инкрементальная переиндексация, которая убирает и удалённые документы, права доступа в поисковом запросе, оценка на фиксированном наборе вопросов, ссылки на источники и отказ, когда ничего не найдено, защита от инструкций внутри документов и трассировка каждого этапа.
Почему RAG, который работал в демо, ломается в production?
Реальные документы грязнее демонстрационных, они меняются и удаляются, разные пользователи могут видеть разные документы, а качество после запуска никто не измеряет. Каждому из этого нужен свой механизм, а не модель получше.
Как оценивать RAG-систему?
С помощью фиксированного набора реальных вопросов, каждый из которых связан с документами, которые должны на него отвечать. Поиск оценивают по тому, нашлись ли нужные источники, а ответ по тому, верен ли он им. Набор прогоняют при каждом изменении, а выборку ответов из production проверяют постоянно.
Где в RAG должны быть права доступа?
В поисковом запросе, как фильтр по правам, сохранённым с каждым фрагментом. Инструкции в промпте это не контроль доступа.