Классификация и routing
Дальше начинаются прикладные задачи, и первая - самая частая: разложить вход по классам и направить дальше. Router не отвечает на вопрос, он выбирает следующий контракт. Чем меньше пересекаются категории и чем яснее последствия ошибки, тем надёжнее маршрутизация.
Правильный router - это узкий prompt: ровно один маршрут, закрытый список, явные последствия.
# Цель
Выбери ровно один маршрут для следующего шага.
# Маршруты
- faq: общий вопрос, не требующий account data
- account_read: нужен статус или факт конкретного аккаунта
- refund_preview: пользователь хочет оценить возможность возврата
- technical: требуется диагностика продукта
- human: конфликт политики, угроза, юридическое обещание или неизвестный класс
# Правила
- Классифицируй намерение, а не отдельные ключевые слова.
- Если не хватает одного факта для выбора двух маршрутов, верни clarify.
- Не вызывай downstream action и не отвечай пользователю.
# Output
{ route, reason_code, missing_field, normalized_language }Качество маршрутизации почти целиком определяется границами категорий. Перед запуском стоит задать себе четыре вопроса.
- Можно ли применить два класса сразу? Если да - нужен multi-label или другой уровень абстракции.
- Есть ли категория unknown или human? Без неё модель вынуждена угадывать ближайший маршрут.
- Что случится при ошибке? Дорогие классы требуют подтверждения или вторичной проверки.
- Нужна ли вообще модель? SKU, enum и точные команды дешевле и надёжнее маршрутизировать обычным кодом.
И у routing есть приятный побочный эффект - он разводит инструкции по разным контрактам.
Routing разделяет prompts. Anthropic приводит поддержку как естественный пример: FAQ, refund и technical получают разные downstream-процессы, prompts и tools. Это уменьшает взаимное влияние инструкций.