Ручное управление роутером моделей в дни странных сбоев

Что идет не так в странные дни

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

Но потом наступает странный день. Запрос тот же, а ответ почему-то меняется.

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

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

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

Операторам нужен для таких моментов один ручной рычаг, а не десять настроек. Один понятный override.

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

Что должен делать override

В плохой день роутеру нужна маленькая аварийная панель, а не лабиринт настроек. Один оператор должен суметь быстро закрепить трафик за одним провайдером, если обычная смесь начинает странно себя вести. Действие должно срабатывать быстро, а охват — быть понятным: весь трафик, один workflow, один tenant или один регион.

Такая же панель должна позволять оператору на время блокировать один класс задач. Если summarization начинает ломаться необычным образом, остановите summarization. Если coding tasks начинают возвращать битый результат, остановите этот класс и оставьте более безопасные задачи работать дальше. Здесь важны короткие сроки действия. Большинство блокировок должно завершаться само через 15, 30 или 60 минут, если никто не продлит их.

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

Хороший override заметен сразу по нескольким простым признакам. Все дежурные должны видеть его на панели. Одно действие должно его отменять. Система должна логировать, кто изменил настройку, когда это произошло и почему. Охват должен быть достаточно узким, чтобы можно было затронуть одного провайдера, один класс задач или одного tenant, не трогая остальную систему.

Если оператор закрепил провайдера, все дежурные должны увидеть это сразу. Скрытые override создают второй инцидент, потому что люди отлаживают не ту проблему. Яркий статус-баннер, время начала, время окончания и короткое поле с причиной обычно вполне достаточны.

Отмена важна не меньше, чем контроль. Командам не нужен deploy, правка конфигурации или тикет, чтобы отменить аварийное действие. Одного клика или одной команды достаточно.

Логи — та часть, которую люди часто пропускают и потом жалеют об этом. Ведите простой audit trail: кто сделал изменение, какой был охват, какая была причина и чем все закончилось. Oleg Sotnikov часто подталкивает команды к такому типу управления в системах с ИИ: несколько переключателей, понятная ответственность и никакого загадочного состояния, когда production начинает чудить.

Когда закреплять одного провайдера

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

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

Здесь важен паттерн, а не один странный результат. Закрепление имеет смысл, когда один провайдер по-прежнему проходит проверку, а другие начинают проваливать базовые проверки; когда число повторных попыток растет, потому что ответы уходят в таймаут или приходят в неверном формате; когда ревьюеры видят скачки тона, которые собьют с толку клиентов; или когда очередь растет, потому что роутер продолжает выбирать слабые варианты.

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

Всегда задавайте время окончания. Закрепление без лимита по времени превращается в скрытую настройку по умолчанию, а потом создает новые проблемы. Выберите короткое окно, которое соответствует инциденту, например 30 минут, 2 часа или одну смену. Когда таймер закончится, перепроверьте метрики и решите снова.

Записывайте изменение в момент, когда его вносите. Отметьте, кто закрепил провайдера, когда это произошло, какого провайдера выбрали, какой task он покрывает и почему понадобилось изменение. Короткой записи вроде «Закрепили provider A для ответов поддержки после проблем с JSON и тоном у provider B» достаточно, чтобы следующий оператор мог спокойно принять решение.

Когда блокировать класс задач

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

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

Здесь override и оправдывает себя. Не нужно выключать всю систему. Вы убираете трафик с падающей полосы и оставляете все остальное двигаться дальше.

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

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

Сообщайте support и ops точно, что увидят пользователи. Не отправляйте расплывчатый alert. Скажите: «Сводки по тикетам сейчас некорректны, поэтому агентам нужно читать всю переписку» или «Извлечение данных из счетов поставлено на паузу, поэтому загрузки обработаются позже». Понятная формулировка снижает путаницу и не дает командам гадать.

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

Как операторы используют это пошагово

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

Начните с данных из живого трафика, а затем сделайте самое маленькое изменение, которое защитит пользователей.

1. Ищите повторяющийся паттерн. Alerts могут показывать рост ошибок, обращения в поддержку — один и тот же плохой ответ, а выборочные логи — что один провайдер ломается на одинаковом типе запроса. Абсолютная уверенность не нужна. Нужны достаточные доказательства, что это реальный паттерн.
2. Прогоните несколько свежих тестов. Используйте недавние промпты, максимально похожие на проблемные запросы. Если та же проблема появляется снова, отметьте, что именно сломалось: неверный формат, таймаут, отказ, небезопасный ответ или скачок стоимости. Свежие тесты не дают вам действовать по устаревшим данным.
3. Выберите более безопасный override. Закрепляйте одного провайдера, когда задача должна продолжать работать и другой провайдер справляется с ней достаточно хорошо. Блокируйте класс задач, когда сама задача стала рискованной, слишком ненадежной или слишком дорогой при любом доступном выборе. Если одно действие затронет меньше пользователей, выбирайте его.
4. Включите override с временем проверки. Держите охват узким, если можете: один класс задач, одна группа клиентов или один регион. Запишите, кто изменил настройку, почему он это сделал и когда команда вернется к проверке. Для первой проверки часто достаточно 30 или 60 минут.
5. Внимательно смотрите на первые результаты. Проверьте уровень ошибок, задержку, стоимость и новые тикеты. Если симптомы быстро уменьшаются, держите override до времени проверки. Если ничего не улучшается, быстро меняйте курс, а не ждите, пока будет еще больше ущерба.

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

Простой пример из команды поддержки

В 13:10 команда поддержки замечает странные черновики ответов. Модель, которая обычно обрабатывает первые ответы, начинает менять имена клиентов в тексте. «Jon» становится «John», «Marta» превращается в «Maria», а в одном названии компании пропадает слово. Ответы при этом звучат вежливо, из-за чего ошибку легко пропустить и опасно отправить.

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

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

Позже появляется вторая проблема — в сводках документов. Роутер начинает возвращать summary со сломанными заголовками, отсутствующими отступами у bullet points и кусками скопированного текста. Эти сводки идут во внутренние заметки, так что команда может прожить без них несколько часов. Оператор использует ту же панель override и блокирует этот класс задач, пока форматирование не исправится.

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

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

Вот как это выглядит на практике. Никакого большого сброса, никакого долгого простоя — просто один человек вносит узкое изменение, когда маршрутизация начинает вести себя странно.

Ошибки, которые наносят еще больший вред

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

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

Другая проблема — когда два человека меняют одно и то же правило одновременно. Получается rule flapping. Один оператор закрепляет провайдера, другой снимает закрепление, третий добавляет блокировку — и уже никто не понимает, какое состояние сейчас активно. Назначьте одного владельца инцидента для изменений в роутере. Система должна показывать, кто держит управление, записывать каждое изменение и делать текущее правило очевидным на главной панели.

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

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

Хорошим override нужны скучные, но надежные меры защиты: одно видимое место для изменения правил маршрутизации, один оператор, который управляет инцидентом, автоистечение для временных блокировок, короткая проверка стоимости, задержки и соответствия формату, а также audit log, где видно, кто и что изменил.

Команды с lean operations обычно стараются держать такие управления простыми и такими, о которых нельзя забыть. Это правильный подход. В странные дни самый безопасный override — тот, который можно быстро найти, понять и так же быстро отменить.

Быстрая проверка до и после переключения

Быстрый override может остановить ущерб, но поспешное переключение может его разнести. До того как кто-то щелкнет правило, потратьте несколько минут на проверку того, что именно сломано и что еще работает.

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

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

Короткая проверка до переключения помогает:

• Назвать задачу, которая ломается, и одну задачу, которая все еще работает.
• Сохранить один недавний хороший результат и один плохой результат для сравнения.
• Решить, получают ли пользователи неверные ответы, медленные ответы или и то и другое.
• Записать, кто отвечает за изменение, когда будет повторная проверка и что запускает rollback.

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

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

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

Небольшие команды справляются с этим лучше всего, когда один человек владеет override, а рядом с правилом лежит одна короткая заметка об откате. Oleg часто работает с lean AI operations, и здесь эта привычка особенно важна: щелкнуть переключатель — это только половина дела. Вторая половина — быстро проверить результат и так же аккуратно все отменить, если исправление не попало в цель.

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

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

Хорошее правило простое и скучное. Оно говорит, что увидела команда, что именно она изменила, кто может это одобрить и когда это убрать. Например: если один провайдер начинает возвращать плохой JSON для извлечения счетов, закрепите запасного провайдера для этой задачи на два часа, а потом снова проверьте уровень ошибок.

Держите каждое правило маленьким. Определите триггер, точное действие, кто может внести изменение, когда правило истекает и что нужно проверить перед rollback.

Так вы превращаете устную практику в повторяемую привычку. А еще это делает ручные override гораздо менее рискованными, потому что люди не гадают под давлением.

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

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

Иногда помогает внешний взгляд. Oleg Sotnikov через oleg.is консультирует стартапы и небольшие команды по multi-model routing, fallback rules, инфраструктуре и AI-first workflow. Если роутер продолжает удивлять команду, короткая консультация может найти пробелы в управлении еще до следующего плохого дня.

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