Все мечтают об умном помощнике: «Включи свет», «Закажи пиццу», «Напомни о встрече». Но как его научить понимать и действовать?
Самый очевидный сегодня путь — взять большую языковую модель (LLM, типа GPT) и промтом описать механизм: «Выдели намерение и данные из запроса, сформируй вызов API». Звучит логично.
Но тут мы упираемся в проблемы:
- LLM может "галлюцинировать" — выдумать параметры или намерение.
- Что делать, если данных не хватает? Спрашивать пользователя? А если запрос сложный и нужно выделить сразу 3 параметра (дату, время и место), а не один? Заставить LLM делать это стабильно — задача на прочный промтинг.
- Дорого и медленно. Для работы с 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 принимает решение по чётким правилам:
- Уверенность в намерении < 70%? →
FALLBACK_LLM(отправляем в большую модель). - Не хватает обязательных параметров? →
ASK_CLARIFICATION(уточняем у пользователя). - Уверенность в параметре < 60%? →
ASK_CLARIFICATION. - Всё ок? →
EXECUTE(выполняем действие).
Пример:
- «Забронируй столик» → Не хватает даты → «Уточняю: на когда?».
- «Что поесть?» → Низкая уверенность в намерении → Передано в LLM для общего разговора.
- «Закажи пиццу Маргарита на завтра в 20:00» → Всё извлечено, уверенность высокая → Действие выполнено.
Итог: Когда что использовать?
- Fast Router (E5 + BILSTM+ CRF): Для чётких команд с известными параметрами. Скорость, дёшево, надёжно.
- Большая LLM (GPT, Opus и т.д.): Для творческих задач, сложных рассуждений, открытых диалогов. Дорого, медленно, но гибко.
Золотая середина — гибридная система: Быстрый и точный Router обрабатывает 80% типовых запросов (включи, закажи, напомни). А сложные или неясные 20% — аккуратно передаёт большой LLM. Так мы получаем и скорость, и интеллект.
Эта архитектура — не устаревшая классика, а разумный инженерный выбор, позволяющий создавать отзывчивых и экономичных ассистентов без суперкомпьютеров.