Год корпоративного RAG в проде: что работает и что нет

Около года назад мы перевели первый RAG-пайплайн в продуктивный контур. С тех пор накопилось несколько инсталляций у разных клиентов, разный масштаб базы знаний, разный уровень требований к качеству ответов. Сейчас есть смысл остановиться и посмотреть, что за это время поменялось в нашем понимании задачи.

Главный вывод коротко: мы слишком долго смотрели не туда. Полгода мы занимались моделями - выбирали, сравнивали, тестировали. А узким местом всё это время был retrieval.

Как мы это поняли

Один из клиентов - производственная компания с базой знаний в несколько тысяч документов - жаловался на качество ответов. Мы методично улучшали промпт, попробовали переход с одной модели на другую, подбирали температуру. Качество менялось в пределах погрешности. Потом кто-то из команды сел и руками прошёлся по 50 случаям, где пользователи явно переспрашивали: задали вопрос, получили ответ, тут же переформулировали.

Картина оказалась однозначной: в 38 случаях из 50 правильный документ в базе был. Ретривер его не достал. Не потому что модель слабая - потому что в топ-5 retrieved чанков нужного куска не было.

Это не открытие само по себе - о важности retrieval говорят давно. Но когда видишь это на конкретных числах своего проекта, а не в чужой статье, как-то иначе воспринимается.

Переход на гибридный поиск

До этого момента мы использовали pgvector с косинусным поиском по плотным эмбеддингам. Работало, но с характерной проблемой: точные термины, артикулы, названия процессов - всё это семантический поиск теряет, если нет похожих по смыслу соседей в пространстве векторов. «ИТС-442» и «инструкция по техническому обслуживанию узла 442» в векторном пространстве далеко друг от друга, хотя это один и тот же документ.

Решение, к которому мы пришли - гибридный поиск: плотный эмбеддинг-поиск через pgvector плюс разреженный BM25 через отдельный индекс, финальный rerank по score от обоих методов. Схема не новая, но вопрос был в том, насколько это оправдано для наших объёмов.

Оправдалось. На тестовом наборе из 200 вопросов recall@5 (доля случаев, когда нужный документ попал в топ-5) вырос с примерно 60% до примерно 80%. Точные цифры зависят от конкретной базы, но направление было одинаковым на двух клиентах, где мы это тестировали.

Что сложно в этом переходе:

• Поддерживать два индекса. BM25 и векторный индекс нужно держать консистентными при обновлении документов. Это не катастрофа, но лишняя точка, за которой нужно следить.
• Scoring не складывается напрямую. Нормализация score-ов от BM25 и косинусного поиска - отдельная задача. Мы используем reciprocal rank fusion, это работает предсказуемо.
• BM25 требует качественного текста. Если документы плохо написаны или содержат много OCR-мусора - разреженный индекс только мешает. Пришлось улучшить пайплайн предобработки документов.

Что с моделями

После того как retrieval наладили - да, качество генерации тоже имеет значение. Но разница между моделями на хорошо отретриверованном контексте значительно меньше, чем мы ожидали. У нас работают инсталляции на GigaChat API и на локальных моделях (Qwen2.5 в нескольких вариантах размера), и при хорошем retrieval разница в итоговом качестве ответа - рабочая, но не кардинальная.

Там, где модель реально решает - это «нечёткие» вопросы, где пользователь формулирует неточно или смешивает несколько тем. Но это скорее задача query expansion на входе в ретривер, чем задача мощности генеративной модели.

Для КИИ-клиентов вариант с облачными API не работает по контрактным причинам - это не изменилось. Локальный инференс остаётся единственным путём.

Что сейчас в работе

Мониторинг на уровне span-ов дал нам метрику, которую теперь смотрим отдельно: доля запросов, где score лучшего retrieved документа ниже порога. Это ранний сигнал, что какая-то категория вопросов плохо покрыта базой знаний - не потому что модель плохая, а потому что документа нет или он написан так, что ни один из индексов его не находит.

Параллельно тестируем reranker-модель поверх гибридного поиска - дополнительный проход, который переранжирует топ-15 кандидатов перед подачей в генерацию. На синтетических тестах это даёт ещё один заметный прирост recall, но у нас нет достаточной production-статистики, чтобы говорить уверенно.

Где мы стоим

RAG в корпоративном проде работает. Не без усилий, не «запустил и забыл», но работает. Основная часть усилий уходит не на модели и не на инфраструктуру - она уходит на качество данных и качество retrieval. Это скучнее, чем обсуждать GPT-5 против локальных моделей, но это честная картина.

Переход с чистого векторного поиска на гибридный был правильным решением, и мы жалеем, что не сделали его раньше. Не потому что pgvector плох - он справляется с объёмами нормально - а потому что один тип индекса физически не покрывает все сценарии поиска в корпоративных документах.