Почему RAG не работает: сначала почините поиск

Компании внедряют RAG, получают неточные ответы и винят языковую модель. В большинстве случаев модель ни при чём. Виноват поиск: данные собраны плохо, индекс один вместо двух, маршрутизация запросов отсутствует. Ниже разбираем, где именно теряется качество и как собрать рабочую схему по внутренним базам за один спринт.

Где на самом деле ломается RAG

RAG состоит из двух частей: сначала система ищет нужные документы, потом модель формулирует ответ по найденному. Если на этапе поиска подобраны не те фрагменты, модель честно перескажет мусор. Замена модели на более дорогую тут не помогает, потому что чинить надо не генерацию, а извлечение.

Типичная ошибка: команда строит только семантический поиск по эмбеддингам и игнорирует точное совпадение. В результате запросы про номера договоров, артикулы, ID клиентов и суммы работают плохо, ведь смысловая близость для точных идентификаторов бесполезна. Для бизнеса это означает неверные ответы там, где цена ошибки самая высокая: в цифрах, документах и юридических деталях.

Какой стек мы используем и почему

Мы собираем поиск на проверенном наборе компонентов, каждый из которых закрывает свою задачу.

• FastAPI как сервис API: быстрый старт и понятные эндпоинты для вашей команды.
• OpenSearch для BM25 и фильтров: точный поиск по словам и отсечение лишнего по правам доступа и контексту.
• Эмбеддинги для смыслового поиска: подключаем там, где формулировки расходятся со словами в документах.
• PostgreSQL для метаданных и связей: соединяем найденное с фактами из ваших систем.
• Airflow для конвейеров загрузки данных: повторяемый и контролируемый процесс вместо ручных выгрузок.
• Redis для кэша и Langfuse для трассировки в продакшене: ниже задержки и видно, что происходит на каждом шаге.

Этот набор быстро доходит до рабочего состояния и остаётся стабильным под нагрузкой. Для бизнеса это короткий срок до первого результата и предсказуемая эксплуатация.

Как мы строим это за один спринт

Работа разбита на шесть шагов, и каждый даёт измеримый результат.

• Готовая инфраструктура. Docker поднят, проверки здоровья зелёные, документация доступна. Команда обращается к эндпоинтам уже в первые минуты.
• Загрузка из ваших источников. Берём один внутренний источник для старта: CRM, ERP, склад, Confluence, SharePoint или S3. Airflow извлекает, чистит и приводит данные к единой схеме документа.
• Двойная индексация. BM25 для точных совпадений, фрагменты с эмбеддингами для смысла. Гибрид даёт полноту охвата без выдуманных ответов.
• Простая и надёжная логика поиска. Если вопрос про числа или идентификаторы, работают SQL и BM25. Если формулировка размытая, включается гибрид. К каждому запросу добавляются фильтры по контексту пользователя.
• Ответы со ссылками на источники. Модель формулирует ответ только после поиска, показывает ссылки и сами фрагменты. Никаких ответов без подтверждения.
• Защита в продакшене. Кэшируем частые запросы, трассируем каждый шаг, фиксируем промахи и еженедельно добавляем недостающие документы.

Что это даёт вашей компании

Результат складывается из трёх измеримых вещей. Ниже задержка на типовых вопросах, потому что частые запросы обслуживаются из кэша и точного индекса. Меньше неверных ответов, потому что в спорных случаях первым отрабатывает BM25, а не смысловое угадывание. Понятная схема, по которой к тому же конвейеру подключается любая следующая внутренняя база без переписывания всего заново.

Чтобы запустить это у себя, держите в голове короткий чек-лист. Одна схема документа: заголовок, тело, источник, отметки времени, область доступа. Один конвейер загрузки на систему, маленький и тестируемый. Один гибридный индекс на предметную область с одинаковым размером фрагментов. Одно правило маршрутизации: сначала BM25, гибрид при необходимости. Одна политика кэша с временем жизни по бизнес-ценности. Один цикл проверки: добавлять пропущенные документы, обновлять синонимы, переобучать эмбеддинги только когда метрики перестают расти.

Итог

RAG не работает не из-за слабой модели, а из-за слабого поиска. Сначала наведите порядок в данных и индексах, разделите точные и смысловые запросы, добавьте фильтры по доступу и трассировку. Тогда система начинает отвечать точно и предсказуемо, а подключение каждой следующей базы превращается в управляемую задачу.

Если вы хотите проверить, где в вашей инфраструктуре теряется качество поиска и данных, запишитесь на бесплатный технический аудит инфраструктуры: https://myod.it/contacts. Посмотрим ваши источники и подскажем, с чего начать.