LLM + RAG → DMN: детерминированная маршрутизация обращений

Суть одной фразой

LLM понимает текст обращения — DMN принимает финальное решение. Это намеренная граница: модель не решает, кому отдать задачу — она лишь извлекает параметры. Итоговый маршрут определяет детерминированный движок по версионируемым таблицам.

Контекст и проблема

E-commerce с логистикой: клиенты пишут в чат, на почту, через форму на сайте — статус заказа, возврат, брак, ошибка сборки, вопрос по доставке. Всё в свободной форме, всё в один канал.

До автоматизации оператор первой линии вручную:

читал обращение и определял категорию;
вспоминал или искал в регламенте, кто отвечает за этот тип;
переключал задачу нужному отделу с нужным приоритетом.

Что шло не так:

Задержка в очереди — обращение лежит, пока оператор до него добирается.
Ошибки маршрутизации — субъективность, усталость, новый сотрудник без опыта. Задача «гуляет» между отделами.
Хрупкая логика — правила рассредоточены по регламентам, головам и коду. Аналитик хочет добавить новый тип обращения — идёт к разработчику, ждёт релиза.
Нет масштабируемости — рост потока = больше операторов первой линии.

Кто страдает: клиент ждёт ответа, оператор занят рутиной, аналитик не может самостоятельно менять правила, разработчик получает задачи на «перекидку if-else».

Решение: шестиэтапный пайплайн

Идея — убрать человека из петли сортировки, оставив его на контроле исключений.

Приём обращения — веб-форма, чат или почта. Запрос попадает в очередь обработки (n8n-оркестратор).
RAG: поиск релевантных регламентов — векторное хранилище с правилами маршрутизации и базой знаний. По тексту обращения извлекаются нужные фрагменты. Модель опирается на актуальные регламенты компании, а не на обобщённые паттерны из предобучения.
LLM: классификация и извлечение параметров — модель получает текст обращения + фрагменты из RAG и возвращает строгий JSON:
```
{
  "type": "return",
  "object": "order",
  "urgency": "high",
  "has_attachments": true,
  "confidence": 0.91
}
```
Ключевое поле — confidence: оценка собственной уверенности модели в классификации.
Валидация схемы — JSON проверяется через Pydantic до передачи в DMN. LLM не может «проскользнуть» с невалидным ответом.
DMN-движок: финальное решение — Camunda получает параметры и прогоняет их через таблицу правил. На выходе: исполнитель, приоритет, SLA. Таблица хранится в XML-файле с версионированием — аналитик редактирует её без разработчика и без релиза.
Fallback при низкой уверенности — если confidence < threshold или параметры неоднозначны, задача уходит на эскалацию оператору с контекстом (что понял LLM, почему не уверен). Не авторут с ошибкой — управляемое исключение.

Ключевые архитектурные решения

Почему LLM не принимает итоговое решение?

Это намеренная граница между вероятностным и детерминированным слоями.

LLM — стохастическая функция: при одинаковом вводе возможен разный вывод, «галлюцинации» по краевым кейсам, объяснение постфактум. Для маршрутизации заявок это недопустимо: клиент не должен получить разный SLA при одинаковом обращении.

DMN — детерминированный движок: одинаковый ввод → одинаковый вывод, каждое решение трассируется до конкретного правила в таблице, правила читаются людьми без знания кода.

Итог: AI отвечает за понимание текста — задача, где нужна семантика. DMN отвечает за применение правил — задача, где нужна предсказуемость и аудируемость.

Почему RAG, а не обучение/fine-tuning?

Регламенты меняются: новый тип обращений, новый отдел, смена SLA. Fine-tuning под актуальные правила — дорого и медленно. RAG позволяет обновить базу знаний без переобучения модели: аналитик загружает новый регламент, векторное хранилище переиндексируется.

Почему версионирование DMN-таблиц?

При инциденте («почему задача ушла в отдел X, а не Y?») нужно воспроизвести решение. С версионированием известно, какая версия таблицы действовала в момент маршрутизации — можно прогнать те же параметры и получить тот же результат. Это критично для разборов и аудита.

Почему n8n для оркестрации?

Рассматривались Airflow (избыточен для такого потока) и кастомный Python (нет визуального представления для нетехнической команды). n8n даёт граф пайплайна, который можно показать аналитику или операционному менеджеру без объяснения кода.

До и после

Параметр	До	После
Маршрутизация	Оператор вручную	Автоматически, DMN по правилам
Время до распределения	Очередь оператора	Секунды после поступления
Ошибки маршрутизации	Субъективность, усталость	Детерминировано, воспроизводимо
Изменение правил	Разработчик + релиз	Аналитик редактирует DMN-таблицу
Неоднозначные кейсы	Ошибочный авторут	Управляемая эскалация с контекстом
Аудируемость	Нет следа решений	Каждое решение трассируется до правила
Масштаб	Рост потока = рост штата первой линии	Горизонтальное масштабирование без изменений

Стек

LLM (основной): Claude API (Sonnet) — классификация и извлечение параметров из свободного текста.
LLM (альтернатива): YandexGPT / GigaChat — для требований локализации данных по 152-ФЗ.
Embeddings + RAG: векторное хранилище с регламентами и базой знаний по типам обращений.
DMN-движок: Camunda (open source) — исполнение таблиц маршрутизации.
Валидация: Python + Pydantic — строгая проверка JSON от LLM перед передачей в DMN.
Оркестрация: n8n — визуальный граф пайплайна, приём запросов, запись в целевую систему.
Бэкенд: Python + FastAPI — обёртка LLM-вызовов, RAG-пайплайн, интеграция с Camunda.

Результат

Детерминированность: каждое решение о маршруте воспроизводимо. Нет субъективности первой линии — только правила в таблице.

Аудируемость: при разборе инцидента известно: какой тип определил LLM, с какой уверенностью, какое правило DMN сработало, какой версии таблица.

Автономия аналитика: изменение правил маршрутизации — задача для аналитика, не для разработчика. Откат версии таблицы — без релиза.

Безопасный fallback: система не угадывает при неопределённости — управляемо эскалирует оператору с объяснением, почему автоматика не справилась.

Масштабируемость: архитектура рассчитана на горизонтальное масштабирование без изменений ядра — пилот на 1–3k запросов в месяц, промышленный контур при тех же компонентах.