Маршрутизация задач для AI-моделей до того, как начнётся разрастание моделей

Почему команды теряют контроль слишком рано

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

Разработчик использует Claude для одной задачи по коду, потому что вчера он хорошо справился. Продакт-менеджер открывает GPT для похожей работы, потому что так быстрее. Кто-то ещё пробует open model, чтобы сэкономить. Каждое решение по отдельности выглядит разумным, но команда перестаёт работать по одному общему подходу.

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

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

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

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

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

Сначала разберите работу, потом выбирайте модель

Многие команды начинают не с того места. Они пробуют Claude неделю, потом GPT, потом добавляют open model, потому что она выглядит дешевле. Так хаос появляется очень быстро.

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

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

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

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

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

Небольшая продуктовая команда может разобрать это за одну встречу. Product перечисляет повторяющиеся задачи. Engineering отмечает технические риски. Ops добавляет вопросы соответствия требованиям или влияния на клиентов. Обычно уже это короткое упражнение показывает, где одна общая AI-логика потом развалится.

Настройте простые правила маршрутизации

Большинству команд нужно меньше правил маршрутизации, чем они думают.

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

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

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

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

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

Это не самая эффектная работа. Но именно она останавливает разрастание моделей до того, как оно станет дорогим и трудным для исправления.

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

Маршрутизация ломается, когда команда не может ответить на четыре простых вопроса: что мы попросили, какая модель ответила, кто трогал результат и почему он прошёл или не прошёл?

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

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

Логи успеха важны, но логи ошибок обычно учат большему. Если GPT написал код, который потребовал серьёзных правок, отметьте почему. Если open model не уложилась во время, а затем Claude обработал повторную попытку, тоже зафиксируйте это. Через месяц такие заметки покажут, какие маршруты действительно работают, а какие только выглядят дешёвыми на бумаге.

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

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

Одна частая ошибка — вести только отметку «прошло/не прошло». Это выглядит аккуратно, но скрывает реальную цену. Модель может «пройти», потому что инженер потратил 20 минут на исправление ответа перед одобрением. Когда команда начинает фиксировать правки и причины отказа, слабые маршруты становятся очевидны очень быстро.

Пропишите правила отката до того, как появятся ошибки

Сбои моделей — это нормально. Тихие сбои опаснее всего.

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

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

Несколько правил закрывают большинство случаев:

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

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

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

Запускайте по одному направлению за раз

Команды теряют контроль, когда запускают AI сразу в пяти местах.

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

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

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

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

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

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

Как это выглядит на небольшой команде

Команда SaaS из шести человек может держать маршрутизацию максимально простой.

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

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

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

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

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

Это не выглядит эффектно. Зато всё понятно, недорого и легко проверяется. Для небольшой команды это часто лучший выбор.

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

Разрастание моделей редко начинается с одного плохого решения. Обычно оно растёт из серии «быстрых тестов», которые никто потом не убирает.

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

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

Дрейф промптов делает проблему менее заметной. Один человек правит промпт в чате. Другой копирует старую версию в общий документ. Третий вставляет обе версии в workflow-инструмент. Теперь команда думает, что сравнивает модели, а на деле сравнивает разные инструкции. Когда качество падает, никто не понимает, что изменилось.

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

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

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

Проверки перед тем, как добавлять ещё одну модель

Прежде чем подключать новую модель, проведите короткую проверку.

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

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

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

Часто именно здесь полезна помощь со стороны. Fractional CTO может заметить слабые передачи, пропущенные шаги проверки и пробелы в логировании, к которым внутренняя команда уже привыкла.

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

Что делать дальше

Выберите один рабочий процесс, который уже еженедельно съедает время, и разберите его вручную. Запишите, какие задачи идут в Claude, GPT или open model, кто проверяет результат, что логируется и когда система должна остановиться и позвать человека. Если маршрутизация расплывчата уже в первый день, стек очень быстро станет грязным.

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

На этой неделе достаточно простого плана:

• Выпишите 3–5 направлений задач, которые команда использует чаще всего.
• Определите поля логов, которые люди действительно будут заполнять.
• Задайте одно правило отката для низкой уверенности, одно — для неудачных вызовов и одно — для чувствительных данных.
• Прогоните процесс на реальных данных несколько дней.
• Разберите каждую ошибку до того, как добавлять ещё одну модель.

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

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

Если вашей команде нужна внешняя помощь, Oleg Sotnikov делится таким практичным опытом через oleg.is как Fractional CTO и startup advisor. Его фокус — непафосная часть, которая экономит команде силы потом: понятные правила маршрутизации, аудит-след, которым реально пользуются, и пути отката, которые держат расходы и ошибки под контролем.