Иллюзия готовности RAG к релизу — классическая проблема enterprise-разработки. На стадии прототипа система на небольшом объеме вычищенных документов демонстрирует впечатляющую точность. Однако после интеграции с реальной корпоративной базой знаний (где годами накапливаются дубли, противоречия и устаревшие регламенты) ответы начинают стремительно деградировать. При этом в большинстве случаев виновата не языковая модель и ее пресловутые галлюцинации, а архитектурные просчеты в обработке данных и поиске.
Базовая архитектура: классика против агентов
Попытка сразу внедрить сложный агентский пайплайн — распространенная ошибка. Агентские циклы, в которых модель самостоятельно определяет стратегию поиска и делает несколько итераций, увеличивают задержку ответа, растут расходы на токены и усложняется отладка.
Практика показывает, что около 80% запросов пользователей тривиальны и закрываются классическим однопроходным RAG. Оптимальная схема строится на гибридной модели:
- Легковесный классификатор-маршрутизатор оценивает сложность входящего запроса.
- Стандартные вопросы направляются по прямому детерминированному маршруту.
- Сложные многосоставные запросы уходят в агентский цикл с оценкой промежуточных результатов.
Секреты подготовки данных и индексации
Ни один продвинутый алгоритм генерации не исправит выдачу, если этап подготовки данных выполнен некорректно.
Ошибки чанкинга
Разбиение документов требует учета специфики языка и предметной области. Слишком мелкие чанки (например, порядка 100 токенов) разрушают семантические связи, превращая технические инструкции или формулы в разрозненный шум. Оптимальные ориентиры для нарезки текста:
- Базы типа FAQ: около 200 токенов (вопрос и ответ должны находиться в едином фрагменте).
- Связные статьи на русском языке: в среднем 1000 токенов с нахлестом (overlap) около 10% для сохранения контекста на границах блоков.
- Сложная верстка (таблицы, сквозные схемы): сегментация смысловых границ с помощью LLM, несмотря на повышенную стоимость индексации.
Выбор поискового движка
Полагаться исключительно на семантические векторы рискованно: плотный векторный поиск может упустить конкретные термины, артикулы или фамилии. Наилучшую стабильность обеспечивает сочетание двух подходов:
| Тип индекса | Механизм | Сильные стороны |
|---|---|---|
| Семантический | Плотные векторы (OpenAI text-embedding-3-large для облака или BGE-M3 для локального контура) | Понимание интонации, синонимов и общего контекста запроса. |
| Полнотекстовый | Разреженные векторы (алгоритм BM25) | Точное нахождение терминологии, кодов и ключевых фраз. |
| Графовый | Выделение сущностей и связей через LLM | Эффективен для multi-hop запросов, но крайне дорог и сложен в поддержке. |
Сложные графовые структуры («путь через Мордор») целесообразно внедрять только тогда, когда потенциал комбинации векторного и полнотекстового поиска полностью исчерпан.
Пайплайн поиска и ловушки Top-N
Типовой отказоустойчивый конвейер включает подготовку исходной реплики (переписывание с учетом последних k сообщений истории), гибридную выборку и последующее слияние списков по алгоритму Reciprocal Rank Fusion (RRF). Отобранный топ кандидатов (например, 10 чанков) пропускается через cross-encoder реранкер, который отсекает нерелевантные фрагменты и передает в генератор 3–5 лучших кусков.
Однако фиксированный поиск Top-N несет скрытые уязвимости:
- Эвристический барьер: чанк с критически важным ответом может занять место N+1 и не попасть в контекст.
- Кластеризация дубликатов: семантический поиск заполняет топ-выдачу близкими по смыслу чанками, не оценивая их взаимную информативность.
- Слепота к широкому контексту: система не способна ответить на обобщающие вопросы («О чем эта документация?»), поскольку оперирует лишь фрагментами.
Диагностика и контроль качества на проде
Когда ассистент начинает давать неверные ответы, проблему локализуют строго последовательно: сначала проверяют, попал ли нужный фрагмент в выборку реранкера. Если чанк присутствует, ошибку ищут в промпте и температуре (для точных фактов она должна быть близка к нулю). Если же документа в выдаче нет — перенастраивают поиск, очищают запрос от шума или изолируют домены данных.
Разделение хранилища по доменным блокам (например, изолированные индексы для HR, IT и бухгалтерии) предотвращает утечку контекста и повышает точность. Для автоматизированного тестирования изменений используется связка реальных диалогов и методики LLM-as-a-judge с градуированной шкалой оценки от 1 до 10, тогда как классический сбор пользовательских лайков и дизлайков практически не дает данных для инженерного анализа поломок.