RAG-системы

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

Источники и индексация

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

Поиск и подача контекста

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

Оценка качества

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

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

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