Почему маршрутизация выглядит как рычаг управления затратами
Маршрутизацию моделей обычно вводят как инструмент контроля расходов. Идея проста: большая frontier-модель обрабатывает сложные случаи, меньшая open-weight модель — рутинные, а классификатор направляет каждый запрос на более дешёвый уровень, если запрос кажется простым. Поскольку open-weight модели улучшились в широком диапазоне рутинной работы, совокупный счёт падает, и демо по-прежнему проходит. Видимая победа — это расходы. Невидимая цена — отказы на хвосте.
Режим отказа структурный, а не случайный. Роутер — это политика, которая отображает запрос на модель. Если политика оптимизируется по прокси-метрике, такой как стоимость за токен, она научится направлять больше трафика на более дешёвую модель. Это правильное поведение для прокси-метрики и неправильное для продукта, когда дешёвая модель лишь приблизительно корректна на классе задач, который прокси-метрика не различает. Агрегированные бенчмарки это скрывают, потому что усредняют по классам задач. Бенчмарк маршрутизации, сообщающий одну оценку, может улучшаться, в то время как конкретный класс задач регрессирует ниже порога, значимого для пользователей.
По чему нужно оценивать роутер
Роутер — это компонент на критическом пути, и ему нужна та же дисциплина оценки, что и любому другому компоненту, способному незаметно менять поведение. Прежде чем политику маршрутизации можно будет выпустить, требуются три вещи.
Замороженный набор задач с критериями прохождения для каждой задачи. Набор — это совокупность репрезентативных задач, каждая с явным условием прохождения. Условия прохождения должны быть для каждой задачи, а не для всего набора. Набор, сообщающий одно число, провоцирует роутер обменять небольшой проигрыш на многих задачах на большой выигрыш на нескольких. Критерии по задачам делают этот обмен видимым. Набор версионируется как код: когда задача добавляется, удаляется или её критерии меняются, версия меняется, и изменения маршрутизации сравниваются с той же версией.
Модель стоимости, включающая повторные попытки, эскалации и проверку человеком. Стоимость инференса — наименьшая часть истинной стоимости решения о маршрутизации. Дешёвая модель, которая часто ошибается, вызывает повторную попытку, эскалацию к большей модели или проверку человеком. Каждое из этого имеет стоимость, и каждое — следствие решения о маршрутизации. Модель стоимости, учитывающая только инференс, будет систематически предпочитать дешёвую модель, даже когда сквозная стоимость выше. Модель должна относить повторные попытки и эскалации обратно к решению о маршрутизации, которое их вызвало, чтобы политика оценивалась по полному пути.
Регрессионный шлюз, блокирующий изменение маршрутизации, когда любой класс задач падает ниже порога. Шлюз — это механизм принуждения. Он сравнивает кандидатную политику с текущей на замороженном наборе и отказывается продвигать кандидата, если любой класс задач падает ниже своего порога, даже если агрегат улучшается. Шлюз превращает маршрутизацию из эксперимента по стоимости в инженерное изменение с историей отката.
Конкретный механизм для шлюза — парное сравнение. Для каждой задачи в наборе запустите и текущую, и кандидатную политику, зафиксируйте результат и вычислите долю прохождений по классам. Кандидат продвигается только если каждый класс на пороге или выше и агрегат не хуже. Это дороже, чем один агрегированный прогон, но это единственный способ поймать регрессию, скрывающуюся внутри среднего.
Заметки по проектированию
Маршрутизируйте по признакам задачи, а не только по длине промпта. Длина промпта — слабый прокси для сложности. Короткий промпт может быть сложной задачей на рассуждение; длинный промпт может быть рутинным извлечением. Лучшие признаки включают тип задачи, наличие требований к структурированному выводу, число вызовов инструментов, которые, вероятно, потребуются траектории, и собственные сигналы уверенности модели. Набор признаков — часть интерф
Позвольте роутеру эскалировать в середине траектории, когда сигналы уверенности ухудшаются. Единственное решение в начале траектории хрупко. Модель может начать уверенно, а затем выдавать токены с низкой уверенностью, повторные самокоррекции или вызовы инструментов, возвращающие ошибки. Роутер должен иметь возможность эскалировать к более сильной модели в середине траектории, когда эти сигналы пересекают порог. Это разница между статическим классификатором и контуром управления. Контур управления стоит дороже на запрос, но восстанавливает задачи, которые статическая политика провалила бы.
Логируйте решение о маршрутизации вместе с результатом. Каждый запрос должен фиксировать, какая модель выбрана, какие признаки определили выбор, произошла ли эскалация и каков был итоговый результат. Без этого лога политику нельзя аудировать, а регрессии нельзя атрибутировать. Лог также является обучающими данными для следующей версии роутера.
Компромиссы
Более тонкая гранулярность маршрутизации стоит латентности и сложности. Роутер, который проверяет много признаков и может эскалировать в середине траектории, добавляет латентность каждому запросу и сложность системе. Более грубая маршрутизация быстрее и проще, но менее точна. Правильная гранулярность зависит от стоимости неверного решения о маршрутизации относительно стоимости латентности.
Пути эскалации нуждаются в собственном бюджете, иначе они становятся поведением по умолчанию. Если эскалация бесплатна, роутер будет эскалировать всё, и более дешёвый уровень станет декоративным. Путь эскалации нуждается в бюджете и пороге, и их нужно настраивать на том же замороженном наборе. Иначе роутер схлопывается к самой сильной модели, и слой маршрутизации становится чистым оверхедом.
Роутер без eval-оснастки — неизмеренная зависимость на критическом пути. Это честный компромисс в центре эссе. Маршрутизация может снизить стоимость и улучшить результаты, но только если она измеряется по результатам. Роутер, оптимизированный по стоимости за токен и не оцениваемый по задачам, — это зависимость, которая может отказать тихо, а тихий отказ на критическом пути хуже более высокого счёта. Оснастка для оценки — не опциональный оверхед; это то, что делает оптимизацию безопасной.
Практический вывод: маршрутизацию следует строить evaluation-first. Определите набор задач, критерии прохождения по задачам, полную модель стоимости и регрессионный шлюз до настройки политики. Затем оптимизируйте. Порядок важен, потому что целевая функция определяет, чему учится роутер. Оптимизируйте сначала стоимость — и роутер научится быть дешёвым. Оптимизируйте результаты при ограничении по стоимости — и роутер научится быть полезным.