Оценка федерации моделей для дрейфа маршрутизатора и неверной маршрутизации

Почему оценки моделей не замечают провалы маршрутизатора

Маршрутизатор может испортить хорошую систему, даже если каждая модель выглядит сильной «на бумаге». Если он отправит спор по выставлению счета в быстрый дешёвый путь вместо модели, способной разобраться в нюансах политики, ответ может звучать прилично и при этом быть неверным. Пользователям всё равно, какой компонент ошибся — они видят плохой ответ.

Именно поэтому средние оценки моделей могут вводить команду в заблуждение. Дашборд может показывать качество ответов на уровне 92%, в то время как небольшая часть запросов маршрутизируется неправильно и причиняет реальный вред. Эти промахи часто попадают в те случаи, которые люди запоминают: возвраты, юридические формулировки, вопросы безопасности и срочные обращения в поддержку. Один неправильный маршрут из двадцати может навредить больше, чем небольшое падение общей точности модели.

Логика отката только усугубляет ситуацию. Команды часто рассматривают fallback как страховку, но он может менять поведение сильнее, чем замена модели. Если маршрутизатор таймаутит, отправляет запрос в резервную модель, а та даёт более короткий, менее внимательный ответ, проблема не в основной модели — проблема в пути, по которому пошёл запрос.

Возьмём простой пример сообщения в поддержку: "Мой счёт неверен, нужно исправить до продления." Если маршрутизатор воспримет это как общую FAQ-задачу, система может вернуть шаблонную статью по биллингу. Если он уловит срочность и риск по аккаунту, дело отправится к более сильной модели или в очередь к человеку. Один и тот же пользователь, тот же пул моделей — совсем разный результат.

Команды часто обвиняют модель, потому что её легче измерить. Они сравнивают Модель A и Модель B, оценивают ответы и на этом останавливаются. Но маршрутизатор нуждается в собственных тестах. Он решает, какие промпты требуют дополнительной заботы, какие — скорости, а какие тихо попадают не в ту полосу.

Несколько признаков показывают проблему: жалобы концентрируются вокруг определённых типов запросов; трафик на fallback растёт после небольшой правки конфигурации; оценки моделей остаются стабильными, а удовлетворённость пользователей падает; или ручной разбор показывает, что правильные ответы приходят из неверного маршрута. Если вы оцениваете только финальный ответ, дрейф маршрутизатора может прятаться неделями.

Что на самом деле решает маршрутизатор

Маршрутизатор делает больше, чем просто выбирает модель. Он читает запрос и ограничения вокруг него. Он сортирует задачу, проверяет риск, учитывает бюджет и взвешивает время отклика. Многие команды также учитывают уровень клиента, доступ к инструментам, язык или то, может ли ответ инициировать какое-то действие.

В большинстве систем решение состоит из нескольких слоёв. Маршрутизатор может выбрать модель, путь промпта и правило отката. Рутина может идти к быстрой модели с коротким системным промптом. Чувствительный запрос — к более сильной модели с жёсткими инструкциями, дополнительными проверками или правилом, блокирующим ответ при низкой уверенности.

Он также решает, что делать при сбое первого пути. Если модель таймаутит, маршрутизатор может попробовать ещё раз. Если ответ кажется слабым, он может отправить запрос к лучшей модели. Если запрос рискованный или вывод инструмента противоречит промпту, поток может остановиться и передаться человеку. Это меняет опыт пользователя так же сильно, как и качество модели.

Небольшие изменения порогов могут перенаправить намного больше трафика, чем команды ожидают. Снизьте порог уверенности — и тысячи рутинных запросов останутся на дешёвом пути вместо эскалации. Сократите таймаут — и больше запросов пропустят повторы и быстро упадут. Повышение балла риска по вопросам аккаунта — и большая доля тикетов поддержки может внезапно переместиться в дорогой путь.

Именно поэтому оценка должна проверять логику принятия решений, а не только модели по отдельности. Когда маршрутизатор меняется, стоимость, скорость и характер ошибок могут измениться, даже если «сырые» метрики моделей не тронулись. Пользователь чувствует маршрут, а не бенчмарк.

Определяйте ожидаемые результаты до создания кейсов

Тестовый кейс без чёткого ожидаемого результата мало что даёт. Надо решить, как должен поступить маршрутизатор, прежде чем запускать тесты.

Начните с типа запроса, а не с модели. Пользователь просит возврат, сообщает о проблеме безопасности или хочет короткий фактический ответ. Для каждого типа должен быть один ожидаемый маршрут. Если несколько маршрутов допустимы, зафиксируйте это заранее. Иначе команды начнут спорить по результатам, и слабые решения проскользнут.

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

Третий пункт важнее, чем кажется. Иногда маршрутизатор выбирает «не ту» модель, но пользователь всё равно получает правильный ответ вовремя — вы можете решить, что это проходит. В других ситуациях неправильный маршрут должен провалить тест даже если текст выглядит хорошо.

Запросы, требующие инструментов, — самый очевидный пример. Если маршрутизатор отправляет такой запрос в обычную чат-модель, и ответ звучит уверенно, но пропускает проверку аккаунта, это промах. Пользователь просил конкретную операцию, а система лишь угадала.

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

Держите правила прохода простыми: "Правильный маршрут или одобренный откат, правильный ответ, меньше 5 секунд, без нарушения политики" — гораздо лучше, чем "в целом нормально." Чёткие правила делают регрессии очевидными и не дают команде объяснять промахи после релиза.

Создавайте кейсы, которые ставят маршрутизатор перед трудным выбором

Большинство маршрутизаторов выглядят умными, когда каждый промпт однозначно указывает на одну модель. Они падают в серой зоне: запросы, которые почти простые, почти сложные или недостаточно полные, чтобы понять путь.

Хорошая оценка включает как чистые кейсы, так и неудобные. Лёгкие запросы подтверждают, что система ещё справляется с базой. Пограничные — показывают, может ли маршрутизатор отличить "достаточно для дешёвого пути" от "отправить на более сильный путь, пока не превратится в плохой ответ."

Грязные входы ещё важнее. Реальные пользователи пропускают поля, вставляют битый текст, смешивают задачи в одном сообщении или просят одно, подразумевая другое. Если ваш набор тестов использует только аккуратные промпты, проверки маршрутизации пропустят случаи, которые вызывают худшие ошибки в продакшене.

Пример из поддержки наглядно это показывает. Сравните "Сбросьте мой пароль" и "Могу войти на вебе, но не на iPhone после смены почты, и ещё проблема с биллингом." Оба — запросы в поддержку, но они не должны идти по одному пути. Первый короткий и рутинный. Второй содержит состояние аккаунта, контекст платформы и вторую проблему, спрятанную в том же сообщении.

Особенно полезны почти дубликаты, потому что они выявляют тихие регрессии. Измените одну деталь — и маршрут должен поменяться. Запрос про "статус возврата" может пройти через дешёвый классификатор, в то время как "статус возврата по платеже после оспоренного продления" может требовать более сильной модели или рабочего процесса с жёсткими проверками. Если после обновления маршрутизатора оба кейса попадают в одно и то же место, вы узнали что-то важное.

Используйте реальные логи, когда сможете. Старые инциденты, записи поддержки и промпты, которые вызвали доработки, лучше выдуманных примеров — они несут ту небрежность, которую люди действительно присылают. Сохраняйте формулировку грубой. Не приводите её в такой порядок, что тест станет легче, чем продакшен.

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

Если маршрутизатор никогда не сталкивается с близкими решениями при тестировании, вы на самом деле не тестируете маршрутизатор. Вы просто проверяете, что очевидные запросы по-прежнему очевидны.

Метрики, которые ловят тихие регрессии

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

Первое исправление простое: разделите одну метрику на две. Качество ответа скажет, получил ли пользователь что-то полезное. Точность маршрута скажет, выбрал ли маршрутизатор модель, инструмент или путь отката, который вы ожидали. Эти числа должны идти рядом, а не смешиваться в одном показателе.

Если вы оцениваете только финальный ответ, вы пропускаете распространённый режим отказа: неправильный путь всё ещё даёт приличный ответ. Запрос по биллингу может попасть к общей модели вместо рабочего процесса с проверками аккаунта. Текст выглядит нормально, но маршрут изменился, шаги безопасности не сработали, и следующий пограничный случай может провалиться.

Практическая табличка обычно отслеживает точность маршрута по типам кейсов, качество ответа по типам, долю откатов и повторов, стоимость на кейс, задержку по кейсу и долю трафика по направлениям во времени.

Долю откатов и повторов стоит уделять отдельное внимание. Если эти числа растут по одному типу запроса, маршрутизатор часто потерял уверенность после правки промпта, изменения порога или нового правила. Общий процент прохождения может остаться стабильным, но система тратит больше токенов и добавляет две-три секунды.

Сравнивайте одни и те же фиксированные тестовые кейсы между версиями. Для каждого кейса отслеживайте оценку ответа, выбранный маршрут, общую стоимость и общую задержку. Если версия B отвечает так же, как версия A, но отправляет на 30% больше кейсов в дорогую модель, это регрессия. Если она добавляет повтор запроса до достижения того же финального ответа, это тоже регрессия.

Сдвиги в доле маршрутов помогают поймать широкий дрейф. После правки промпта или правила одна модель может внезапно начать обслуживать намного больше трафика. Иногда это и было целью. Часто — случайность. Устанавливайте ожидаемые диапазоны для каждой цели и оповещайте, когда релиз выталкивает трафик за их пределы.

Один из лучших алертов — и один из самых тихих: "ответ прошёл, маршрут изменился." Смотрите такие случаи в первую очередь. Они часто раскрывают ошибки, которые в тестах выглядят дешёвыми, а в продакшене становятся дорогими.

Проводите оценку по этапам

Полные системные тесты могут скрывать дрейф маршрутизатора, потому что сильная модель всё ещё может дать приличный ответ, даже если запрос ушёл неправильным путём. Поэтому поэтапная оценка работает лучше.

Начните с замороженной базы. Заблокируйте промпты, правила маршрутизатора, пороги и версии моделей для первого прогона. Если вы всё время меняете настройку при создании набора тестов, вы никогда не получите чистую точку отсчёта.

Затем протестируйте сам маршрутизатор. Пропустите через него те же входы, которые планируете использовать позже, но оценивайте только решение о маршруте. Это покажет, выбрал ли он ожидаемую модель, допустимую группу моделей или полностью неверный путь.

После этого прогоните те же кейсы через полную систему. Теперь можно сравнивать два слоя одновременно: выбор маршрута и финальный ответ. Если ответ ухудшился при том, что маршрут остался правильным, проблема, вероятно, в промпте, использовании инструментов или поведении модели. Если сначала поменялся маршрут — вы нашли проблему маршрутизации.

Простая последовательность работает хорошо:

• Запустите замороженную базу и сохраните все результаты.
• Протестируйте решения о маршруте отдельно на наборе кейсов.
• Прогоните полную систему с теми же кейсами.
• Измените одну переменную и прогоните снова.
• Сравнивайте каждый результат с базой, а не только с последним прогоном.

Меняйте по одной вещи за раз. Если вы обновляете правило маршрутизации, меняете модель и правите промпты в одном релизе, вы потеряете причину регрессии. Маленькие изолированные изменения кажутся медленными, но экономят часы ложной отладки.

Когда кейсы падают, сначала читайте трассировки, прежде чем править набор. Команды слишком быстро переписывают кейс и в итоге скрывают реальную ошибку. Сохраняйте оригинал, если он явно не неверен. Просматривайте запрос, решение маршрутизатора, вывод модели, стоимость и задержку вместе.

Это последнее важно. Храните выбор маршрута, финальный ответ, стоимость и задержку в одной записи для каждого прогона. Маршрут, который даёт правильный ответ, но удваивает стоимость или добавляет две секунды, уже дрейфует в неправильном направлении.

Простой пример триажа в поддержке

Представьте SaaS-инбокс поддержки с одним маршрутизатором перед тремя путями. Рутинные вопросы по биллингу идут в быструю дешёвую модель. Сообщения с угрозами возврата средств, язык чарджбэка или юридическое давление идут на более сильный защищённый путь. Всё неясное — к человеческому обзору.

Звучит просто, пока клиент не напишет как живой человек. Люди смешивают запросы, эмоции и угрозы в одном тексте. Маршрутизатор, который ловит только первую намеренность, в среднем будет выглядеть нормально и всё же провалится на самых важных сообщениях.

Вот четыре кейса, которые стоит тестировать:

• "Меня списали два раза. Можете исправить?" — должен идти в стандартный путь по биллингу.
• "Верните деньги сегодня или я обращусь в банк и к юристу" — должен пойти на защищённый путь.
• "Отмените мой план. Если этот платёж останется, я подам чарджбэк" — должен считаться высоким риском, даже если начинается как обычная отмена.
• "Мне нужно закрыть аккаунт. Дополнительная плата неприемлема, и я могу пожаловаться, если никто не ответит" — не должен получать случайный ответ по биллингу.

Третий пример — место, где многие маршрутизаторы ломаются. Они видят сначала "отмените план", отправляют в дешёвую модель и пропускают угрозу чарджбэка далее по тексту. Если вы оцениваете только качество ответа, такой промах может проскочить, потому что дешёвый путь всё ещё даст вежливый ответ.

Хороший тест проверяет маршрут, метку риска и финальный ответ. Если система откатывается после таймаута или ограничения скорости, она должна оставаться на защищённом пути или передать дело человеку. Нельзя превращать рискованное сообщение в "Конечно, помогу отменить" и игнорировать угрозу.

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

Ошибки, которые скрывают регрессии

Маршрутизатор может ухудшиться, пока дашборд остаётся спокойным. Команды видят, что набор тестов проходит неделю за неделей, и думают, что система стабильна. Часто набор просто перестал задавать трудные вопросы.

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

Другая ошибка — оценивать только финальный ответ. В маршрутизации LLM путь важен так же, как и результат. Если маршрутизатор отправляет простой запрос по возврату в самую большую модель, клиент может получить хороший ответ, но вы платите больше и ждёте дольше. Если рисковый вопрос политики попал в лёгкую модель и восстановился только после повторов, финальный текст может выглядеть приемлемо, но исходный маршрут был неверен.

Команды тоже скрывают регрессии, когда удаляют спорные кейсы после переписывания промпта, что меняет ожидаемую метку. Эти кейсы часто самые полезные, потому что показывают хрупкие правила и размытые границы между моделями. Сохраняйте их, проверяйте вручную и записывайте, почему каждый маршрут должен побеждать. Если метка действительно изменилась, зафиксируйте причину вместо удаления кейса.

Чистые входы создают ещё одно ложное чувство безопасности. Реальные пользователи отправляют сообщения с опечатками, вставляют логи, пишут полупредложения, смешивают запросы и копируют цепочки писем. Маршрутизатор, который выглядит умным на отшлифованном тексте, может быстро развалиться на грязном входе. Если ваш набор не включает шум, он пропустит реальные ошибки.

Ошибки с низкой частотой тоже заслуживают ручного разбора. Редкая неверная маршрутизация может привести к юридической жалобе, проблеме безопасности или недовольству корпоративного клиента. Один такой случай может важнее сотен правильных FAQ-ответов.

Здоровее тестовый набор использует свежие продакшен-кейсы, шумные входы, которые похожи на реальные пользовательские сообщения, метки маршрутов с заметками вместо голых «прошёл/не прошёл», и ручной разбор редких, но дорогостоящих ошибок.

Если набор тестов никогда вас не удивляет — меньше ему доверяйте.

Быстрые проверки перед каждым релизом

Не полагайтесь только на полный прогон бенчмарка. Перед каждым релизом прогоняйте небольшой набор рискованных кейсов, которые обычно ломаются первыми. Выбирайте кейсы с близкими границами намерений, смешанными языками, расплывчатыми промптами и запросами, которые склонны попадать в неправильную модель при дрейфе маршрутизатора.

Затем смотрите долю маршрутов, а не только процент прохождения. Разбейте трафик по намерению, языку и уровню клиента и сравните новую сборку с последней стабильной. Если вопросы по биллингу внезапно переходят к более медленной модели, или испанские запросы чаще попадают на путь отката, это важно, даже если суммарное качество ответов выглядит неплохо.

Откаты и повторы требуют отдельной проверки. Небольшой рост может сигнализировать о повреждении промпта, плохих порогах или сломанной передаче между моделями задолго до жалоб пользователей. Команды часто пропускают это, потому что финальный ответ всё равно приходит, но через два лишних шага и с дополнительными затратами.

Числа — не всё. Просмотрите небольшой набор провалов вручную перед релизом. 10–20 кейсов часто достаточно, чтобы заметить паттерны вроде вежливых отказов, неверного выбора языка или маршрутизатора, отправляющего простые задачи самой дорогой модели.

Установите правило отката заранее. Держите его простым: откатывайте, если доля трафика по важному намерению выходит за допустимый диапазон; если доля откатов или повторов превышает порог; или если ручной разбор выявляет повторяющиеся неверные маршруты в одной группе кейсов.

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

Следующие шаги для более безопасного маршрутизатора

Маршрутизаторы обычно становятся рискованными небольшими, тихими шагами. Одна правка промпта, одна более дешевая модель или одно новое правило отката могут отправить запросы по неправильному пути. Поэтому оценка должна оставаться близко к реальным решениям маршрутизатора, а не только к карточкам с оценками моделей.

Запишите реальные маршруты, которые может пройти ваш запрос: ответить сразу, задать уточняющий вопрос, отправить к более сильной модели, отправить к более дешёвой модели, передать человеку или отказать. Затем соберите двадцать трудных кейсов, которые находятся на границе. Хорошие кейсы намеренно грязные: расплывчатые запросы, недостающий контекст, пограничные вопросы безопасности и задачи, которые на первый взгляд кажутся дешёвыми, но становятся дорогими после ещё одного шага.

Используйте продакшен-ошибки как ресурс. Каждый раз, когда пользователь жалуется на плохую передачу, заморозьте этот пример и добавьте его в набор. Если тикет поддержки ушёл в неправильный маршрут, или безобидный вопрос был заблокирован — сохраните кейс. Набор тестов, собранный из реальных провалов, обычно быстрее ловит проблемы маршрутизации, чем аккуратный бенчмарк.

Каждый раз, когда команда меняет что-то, что может сместить трафик, проверяйте трассировки маршрутизатора. Это включает замену модели, правки промптов маршрутизатора, изменения политики, ценовые правила, лимиты расходов, логику откатов и поведение таймаутов. Не останавливайтесь на финальном ответе. Проверьте, почему маршрутизатор выбрал путь, какую модель он подобрал, были ли повторы, сколько это заняло и что на самом деле увидел пользователь.

Если нужна внешняя проверка, Oleg Sotnikov at oleg.is делает Fractional CTO и AI advisory для стартапов и небольших команд. Второй взгляд помогает, когда вы меняете маршрутизацию моделей, сокращаете расходы или добавляете AI-воркфлоу в существующий продукт.

Практичный первый рубеж прост: одна карта маршрутов, двадцать трудных кейсов и правило, что каждая плохая передача становится постоянным тестом.