Как Битрикс24 перестроил RAG-поиск для ИИ-помощника Марты и вдвое ускорил ответы

Помощник Марта в чате Битрикс24 отвечает на вопросы пользователей, опираясь на документацию helpdesk.bitrix24.ru. Год назад первая версия поиска работала через API стороннего вендора: эмбеддинги для индекса, эмбеддинги для запроса, генерация ответа — всё уходило наружу. Система справлялась, но накопила системные проблемы: только русский язык, растущие расходы на каждый запрос и низкий recall — агент отвечал лишь в 58% случаев, в остальных уходил в уточнение.

Целью переработки был не просто новый RAG, а перевод всего на внутренний стек с одновременным улучшением качества. Внешние модели заменили на внутренние аналоги — embedding, реранкер, LLM — и прогнали систему через серию контролируемых экспериментов. Результат: F1 на наборе экспертных вопросов вырос с 0,636 до 0,908, медианное время ответа сократилось с 22 до 10 секунд.

RAG (Retrieval-Augmented Generation) — подход, при котором LLM не генерирует ответ из «общих знаний», а получает на вход релевантные фрагменты документации. База знаний заранее нарезается на чанки, каждый превращается в вектор (embedding) и сохраняется в векторной БД. При поступлении вопроса система ищет похожие чанки и передаёт их в промпт модели. Качество итогового ответа напрямую зависит от того, насколько точно retrieval нашёл нужные фрагменты.

Один из ключевых инсайтов команды — разные форматы для разных этапов пайплайна. Исходный HTML хелпдеска конвертируется в Markdown, из которого затем получают plain text. Для embedding-модели лучше сработал именно plain text: символы вроде ** и # оказались шумом, который снижал качество поиска по Recall@10 на синтетическом dev-сете. LLM, напротив, получает Markdown — он сохраняет структуру заголовков, списков и таблиц, которую модель использует при формировании ответа.

Гибридный поиск объединяет dense-поиск (по векторным эмбеддингам) и sparse-поиск (полнотекстовый, по ключевым словам), а результаты объединяются через RRF (Reciprocal Rank Fusion). Такой подход компенсирует слабые стороны каждого метода в отдельности: семантический поиск хорошо улавливает смысл, но может пропустить точные термины; полнотекстовый — наоборот. После гибридного поиска кандидаты передаются реранкеру — отдельной модели, которая пересортировывает их по релевантности и отсекает лишнее перед передачей в LLM.

Архитектура small-to-big позволяет индексировать маленькие чанки для точного поиска, но передавать в LLM более широкий контекст — родительский фрагмент или целую секцию документа. Это решает классическую дилемму RAG: маленькие чанки точнее находятся, но могут не содержать достаточно контекста для ответа.

Разработчики подчёркивают: большинство гиперпараметров — размеры чанков, веса гибридного поиска, пороги реранкера — нельзя вычислить из общих принципов. Нужны eval-стенды и прогоны на реальных датасетах. Один retrieval-эксперимент на ~600 вопросах занимает десятки минут даже при распараллеливании в 5 потоков, полный end-to-end eval с агентом — 2–3 часа. Прирост в 2–3 процентных пункта Recall@10 команда считает хорошим результатом: за каждым таким приростом стоят дополнительные 10–20 правильно найденных и десяток правильно отброшенных документов.