Проще говоря, model router отвечает на вопрос: какая модель сейчас даст лучший баланс качества, цены, скорости, контекстного окна и безопасности. Это особенно важно в агентных системах, где рядом живут классификация, извлечение данных, генерация текста, анализ документов, tool calling, RAG и финальная проверка ответа.
Маршрутизация может быть простой: если задача короткая - model A, если документ длинный - model B. А может быть сложной: учитывать тип задачи, язык, размер контекста, лимит стоимости, риск, наличие персональных данных, требуемый формат JSON, confidence предыдущего шага и доступность провайдера.
Model routing отличается от обычного выбора модели тем, что решение принимается автоматически или полуавтоматически на уровне приложения. Пользователь не выбирает модель вручную каждый раз: система сама решает, куда отправить запрос, и пишет это в логи.
Главный риск model routing - скрытая деградация качества. Если router слишком агрессивно отправляет сложные задачи в дешевую модель, пользователь получает уверенные, но слабые ответы. Поэтому нужны evals, мониторинг стоимости, traces, fallback-правила и понятные guardrails.
Примеры
- Система отправляет короткую классификацию обращения в дешевую модель, а сложный договор на анализ рисков - в Claude Fable 5 или другую сильную модель.
- AI-агент сначала просит быструю модель определить тип документа: счет, договор, RFP или регламент. Затем router выбирает специализированный промпт и модель для анализа.
- Если основной провайдер недоступен, model router переключает запрос на резервную модель и помечает в логе fallback_used = true.
- Запрос с персональными данными уходит в корпоративную модель, а публичный маркетинговый черновик - в облачную модель с меньшей стоимостью.
- Для JSON-ответов router выбирает модель, которая лучше держит structured output, а для короткого summary использует более дешевый вариант.
Где используется
- снижение стоимости LLM-запросов
- выбор сильной модели для сложных задач
- fallback при ошибке провайдера
- маршрутизация чувствительных данных
- разделение задач классификации и анализа
- выбор модели по длине контекста
- выбор модели для structured output
- AI-агенты с несколькими моделями
- A/B-тестирование моделей
- мониторинг качества и стоимости ответов
Связанные термины
Частые вопросы
Зачем нужен model routing?
Чтобы не использовать одну дорогую или сильную модель для всех задач. Простые запросы можно обрабатывать быстрее и дешевле, а сложные, рискованные или длинные отдавать более сильной модели.
Чем model routing отличается от fallback?
Fallback - это частный случай маршрутизации: переключение на другую модель при ошибке, лимите или недоступности. Model routing шире: он выбирает модель по типу задачи, контексту, риску, стоимости и качеству.
Какие признаки учитывать при выборе модели?
Тип задачи, длину контекста, нужный формат ответа, чувствительность данных, стоимость, latency, доступность провайдера, требуемое качество reasoning и confidence предыдущих шагов.
Можно ли сделать routing только правилами?
Да, для старта лучше правил: тип документа, размер текста, риск, язык и стоимость. Позже можно добавить evals, статистику качества и отдельную модель-классификатор для выбора маршрута.
Как понять, что router работает плохо?
Смотрите traces, cost monitoring, жалобы пользователей, долю fallback, ошибки JSON, снижение качества на сложных задачах и случаи, где дешевую модель выбрали для рискованного запроса.
