Как научить ассистента ДЕЛАТЬ, а не просто болтать? (Спойлер: не только LLM)

Все мечтают об умном помощнике: «Включи свет», «Закажи пиццу», «Напомни о встрече». Но как его научить понимать и действовать?

Самый очевидный сегодня путь — взять большую языковую модель (LLM, типа GPT) и промтом описать механизм: «Выдели намерение и данные из запроса, сформируй вызов API». Звучит логично.

Но тут мы упираемся в проблемы:

1. LLM может "галлюцинировать" — выдумать параметры или намерение.
2. Что делать, если данных не хватает? Спрашивать пользователя? А если запрос сложный и нужно выделить сразу 3 параметра (дату, время и место), а не один? Заставить LLM делать это стабильно — задача на прочный промтинг.
3. Дорого и медленно. Для работы с LLM нужны мощные GPU (те самые H100), что недоступно обычным разработчикам или стартапам.

Такие модели, как Opus, справятся.Но они к сожелению доступны не всем.
«А чо делать тооо…….»

Выход есть! И придумали его не вчера, а в далёком 2017 году это DIET-подобная архитектура! Она до сих пор бьёт LLM по скорости и стабильности в 100+ раз! Погнали разбираться.

# Fast Router Architecture Deep Dive: Как это работает под капотом

Полная архитектура системы

Пользовательский запрос
         ↓
  [Токенизация SentencePiece]
         ↓
┌─────────────────────────────────────┐
│      E5-Large Encoder (frozen)      │
│    (многоязычный, 560M параметров)  │
│  Вход: текст → Выход: 1024-мерные   │
│     эмбеддинги каждого токена       │
└───────────────────┬─────────────────┘
                    │
       ┌────────────┴────────────┐
       │                         │
       ↓                         ↓
┌─────────────────┐    ┌──────────────────┐

│   Intent Head   │    │    Slot Head     │
│  (MLP-классификатор) │  (BiLSTM + CRF)   │
│                 │    │                  │
│ [CLS]-эмбеддинг │    │ Токенные эмбеддинги│
│    (1024)       │    │     (N × 1024)   │
│       ↓         │    │        ↓         │
│  Linear(1024,256)│    │  BiLSTM(1024,256) │
│  ReLU + Dropout │    │  → 2 слоя    │
│       ↓         │    │        ↓         │

│  Linear(256, #intents)│    │  Linear(256, #slot_labels)│

│       ↓         │    │        ↓         │
│    Softmax      │    │      CRF Layer   │
│       ↓         │    │   (матрица переходов,│
│  Intent + Confidence││   Viterbi декодинг) │
└─────────────────┘    └──────────────────┘
       │                         │
       └──────────┬──────────────┘
                  ↓
         ┌─────────────────┐
         │   Rule-Based    │
         │    Validator    │
         │ (жёсткая логика)│
         └─────────┬───────┘
                   ↓
    ┌─────────────────────────────┐
    │ Действие: EXECUTE /         │
    │ ASK_CLARIFICATION /         │
    │ FALLBACK_LLM                │
    └─────────────────────────────┘

Ключевые компоненты:

• Embedder (E5-Large): Переводит текст в вектор (понимает суть).
• Intent Head: Определяет намерение («забронировать», «заказать»).
• Slot Head + CRF: Извлекает параметры («завтра», «19:00», «пицца Маргарита»).
• Validator: Принимает решение: выполнить, уточнить или передать сложный запрос в LLM.

Почему это быстрее и дешевле LLM?
Обучены только две маленькие «головы» (Intent и Slot), а основа (E5) — заморожена. Итоговый размер модели для инференса — мизерный. Выигрыш в скорости: 15ms против 2-5 секунд у LLM. В 100-300 раз!

Intent Head: Как понимаем, чего хочет пользователь

Архитектура Intent Head:

[CLS]-эмбеддинг (1024 измерений) 
    ↓
Полносвязный слой (1024 → 256) + ReLU + Dropout(0.3)
    ↓
Полносвязный слой (256 → количество_интентов)
    ↓
Softmax (преобразование в вероятности)
    ↓
Намерение + Достоверность

Пример работы:

Вход: "Забронируй столик на завтра"

Выход Softmax:
  calendar.booking:   0.92  ← Победитель
  calendar.reminder:  0.05
  email.send:         0.02
  chitchat:           0.01

Сердце системы: Извлечение параметров (Slot Filling) с помощью CRF

Самая крутая часть — Slot Head. Её задача — разметить каждое слово в предложении. Например:

«Напомни о встрече завтра в 19:00»

Слова «встрече», «завтра», «19:00» — это параметры (слоты). Простая нейросеть могла бы допустить ошибку: пометить «встрече» как начало слота (B-topic), а «завтра» — как независимый слот (B-date). Но она не знает, что после «B-topic» редко сразу идёт «B-date».

На помощь приходит CRF (Conditional Random Field). Это слой, который учит правила переходов между метками. Он знает, что последовательность B-topic → I-topic (продолжение темы) — очень вероятна, а B-topic → B-date — маловероятна. Это как грамматика для разметки текста.

Результат: Точность извлечения сложных, многословных параметров (типа «Александр Сергеевич» или «эту субботу») взлетает с ~70% до ~95%. CRF гарантирует, что слоты будут извлечены целыми и непротиворечивыми.

Правила вместо догадок: Валидатор

После извлечения намерения и параметров Rule-Based Validator принимает решение по чётким правилам:

1. Уверенность в намерении < 70%? → FALLBACK_LLM (отправляем в большую модель).
2. Не хватает обязательных параметров? → ASK_CLARIFICATION (уточняем у пользователя).
3. Уверенность в параметре < 60%? → ASK_CLARIFICATION.
4. Всё ок? → EXECUTE (выполняем действие).

Пример:

• «Забронируй столик» → Не хватает даты → «Уточняю: на когда?».
• «Что поесть?» → Низкая уверенность в намерении → Передано в LLM для общего разговора.
• «Закажи пиццу Маргарита на завтра в 20:00» → Всё извлечено, уверенность высокая → Действие выполнено.
• 
  

Итог: Когда что использовать?

• Fast Router (E5 + BILSTM+ CRF): Для чётких команд с известными параметрами. Скорость, дёшево, надёжно.
• Большая LLM (GPT, Opus и т.д.): Для творческих задач, сложных рассуждений, открытых диалогов. Дорого, медленно, но гибко.

Золотая середина — гибридная система: Быстрый и точный Router обрабатывает 80% типовых запросов (включи, закажи, напомни). А сложные или неясные 20% — аккуратно передаёт большой LLM. Так мы получаем и скорость, и интеллект.

Эта архитектура — не устаревшая классика, а разумный инженерный выбор, позволяющий создавать отзывчивых и экономичных ассистентов без суперкомпьютеров.