При построении чат-бота поддержки на больших языковых моделях (LLM) часто выбирают прямой путь: вопрос пользователя → поиск в базе знаний → запрос к LLM → ответ. На демо этот подход работает, но в реальной эксплуатации начинаются проблемы: модель ошибается на пограничных формулировках, путает похожие продукты, галлюцинирует и тратит деньги на каждый запрос, включая приветствия.
Архитектор системы «Финлоджик. Контур Поддержки» (FinlogiQ ИИ Support) применил обратный принцип: вопрос должен доходить до LLM в последнюю очередь. Сначала задачу решают жёсткие, полностью контролируемые слои с заранее заданной логикой. Для этого введена доменная модель ContactReason — строгий объект, описывающий конкретный класс проблем. Внутри каждой причины заданы многоуровневые маркеры (фразовые маски, числовые теги, существительные, глаголы) с разными весами: фразовая маска даёт 10 баллов, код ошибки — 5, существительные — 2, глаголы — 1. Минимальный порог прохождения — 5 баллов. Если система не видит явного лидера или разрыв между причинами мал, она не угадывает, а передаёт управление дальше.
| Тип маркера | Вес |
|---|---|
| phrase_mask | 10 |
| numeric_tag | 5 |
| noun | 2 |
| verb | 1 |
| global_min_score | 5 |
Конвейер включает пять уровней. L0 — глобальная эскалация: угрозы, юридические претензии, требования переключить на оператора уходят сразу, без анализа LLM. L1 — скоринг по маркерам, где работает собственный движок сопоставления. Если текст слишком зашумлён (приветствия, эмоции, опечатки), подключается LLM только для нормализации, после чего очищенный запрос повторно проходит через L1. Затем следуют локальные правила причины (L1.1–L1.5): повышенные пороги, обязательные маркеры (ИНН, номер договора), сценарии перевода на специалиста. На L2 поиск ответа идёт строго по приоритету: сначала прямые совпадения с заранее заготовленными шаблонами (ExampleQA, совпадение ≥0.7) — мгновенный ответ без вызова LLM, нулевая стоимость; затем типовые жалобы (Complaint) и, наконец, обращение к LLM.
На уровне L0 система сразу эскалирует угрозы и юридические претензии, не тратя ресурсы LLM.
Результат — система использует LLM только там, где это необходимо, экономя ресурсы и повышая предсказуемость. Гибридная архитектура с жёсткой бизнес-логикой на нижних уровнях оказалась стабильнее чистого RAG, особенно при росте объёмов обращений. Это решение может быть полезно командам, которые строят промышленные чат-боты поддержки и ищут баланс между качеством ответов и затратами.
