Проблема «бесполезной генерации»
Стандартные туториалы по RAG (Retrieval-Augmented Generation) ориентированы на хаотичные корпуса: PDF-сканы, контракты, документы с плохим OCR. В таких случаях система тратит ресурсы на извлечение смысла. Однако в корпоративной поддержке 80% запросов — это вариации 15–20 базовых вопросов (например, «Как отменить полис?» или «Какой мой франшиза?»).
Запуск таких вопросов через векторную базу данных и LLM — это выбрасывание денег. Ответ уже написан и хранится на диске. Использование RAG в этом случае не просто избыточно, оно часто возвращает менее точные результаты, чем простой lookup, из-за потери семантической структуры при эмбеддинге.
Архитектурный сдвиг: от парсинга к кэшированию
Когда вы сами проектируете корпус (FAQ), архитектура RAG инвертируется. Вместо сложного парсинга документов, ключевым этапом становится классификация намерения пользователя через сравнение с кэшем канонических вопросов. Система должна определить один из трех сценариев до вызова LLM:
- Direct Match (Прямое совпадение): Вопрос пользователя семантически идентичен каноническому. Ответ возвращается мгновенно, без вызова LLM. Затраты: 0 токенов, < 10 мс.
- Adjacent Match (Смежное совпадение): Вопрос близок, но требует адаптации. Используются few-shot примеры (топ-3 похожих Q-A пары) для генерации ответа. Затраты: 1 эмбеддинг + 1 вызов LLM.
- Miss (Пропуск): Вопрос вне зоны покрытия FAQ. Запрос логируется для редакции. Затраты: только эмбеддинг.
Техническая реализация и метрики
Авторы предлагают использовать пороговые значения косинусного сходства для маршрутизации. Ниже приведена логика распределения нагрузки в зависимости от порога сходства:
| Тип совпадения | Порог сходства (Threshold) | Действие системы | Стоимость (Cost) |
|---|---|---|---|
| Direct (Прямой) | ≥ 0.92 | Возврат канонического ответа из базы | Мгновенно, 0 токенов LLM |
| Adjacent (Смежный) | 0.78 – 0.92 | Генерация через Few-Shot Prompting (k=3) | 1 вызов LLM, < 1000 токенов |
| Miss (Пропуск) | < 0.78 | Логирование запроса, возврат fallback-сообщения | Минимально (только эмбеддинг) |
Почему это важно для бизнеса
Главная ценность подхода «FAQ as RAG» — не в улучшении качества ответов, а в экономии и масштабируемости. Прямые совпадения (Direct Match) устраняют задержку (latency) и стоимость генерации для подавляющего большинства запросов. Это превращает RAG из системы «генерации знаний» в систему «умного кэширования».
Кроме того, такой подход выносит ответственность за качество контента на этап создания FAQ (upstream). Если ответ неверен, проблема решается редактированием текста, а не тонкой настройкой модели. Это создает четкий цикл обратной связи: промахи (Miss) становятся задачами для команды поддержки, а не багами алгоритма.
Источник: Towards Data Science ↗