Фраза «Какую модель нам выбрать?» раньше звучала как вопрос об API. Во всё большем числе организаций это скорее вопрос закупок, инженерии производительности и архитектуры.
Эта перемена стала следствием простого развития событий: теперь существует множество моделей, предлагаемых множеством провайдеров, причём они существенно различаются по сильным сторонам, ценам, характеристикам задержки, вариантам развёртывания и договорным условиям. Объявленное Stripe соглашение о приобретении OpenRouter служит полезным сигналом. Единый API OpenRouter охватывает более 400 моделей от более чем 80 провайдеров, а критерии маршрутизации включают сложность задачи, цену, скорость, надёжность, задержку, пропускную способность и специфичные для провайдера расходы.
Возникающая роль не обязательно предполагает новую должность. Она может находиться на стыке инженерии AI-платформ, архитектуры, закупок, эксплуатации инференса или разработки продуктов. Но её ответственность становится понятной: решать, какая модель должна выполнять какую работу, при каких ограничениях, с каким вариантом резервирования и на основании каких данных.
Маршрутизация — это политическое решение, замаскированное под инфраструктуру
Наивный маршрутизатор спрашивает: «Какая модель дешевле всего?» Полезный маршрутизатор задаёт более конкретный вопрос: «Какова самая дешёвая модель, которая соответствует требованиям этого запроса по качеству, задержке, надёжности, конфиденциальности и эксплуатации?»
Эти требования зависят от задачи. Классификатор обращений в службу поддержки может нуждаться в предсказуемом структурированном выводе и низкой задержке. Сложная задача программирования может оправдывать использование более медленной, но более мощной модели. Конвейер суммаризации большого объёма данных может отдавать предпочтение меньшей модели, особенно если после тестирования её качество оказывается достаточным. Регулируемый процесс может требовать определённого региона, политики хранения данных или соглашения с конкретным провайдером независимо от цены токенов.
Именно поэтому маршрутизация должна обсуждаться на архитектурных проверках, а не только в коде приложения. Маршрут определяет нечто большее, чем счёт. Он может влиять на размещение данных, подверженность сбоям, наблюдаемость, согласованность ответов, поведение при использовании инструментов и объём необходимой последующей проверки человеком.
Четыре дисциплины, лежащие в основе серьёзной функции маршрутизации
1. Закупки: сравнивайте весь сервис, а не только указанную цену токенов
Цены на модели легко сравнить неправильно. Токены ввода и вывода могут иметь разные тарифы. Кэшированный ввод, пакетная обработка, приоритетное обслуживание и запросы с большим контекстом могут изменить расчёт. Номинальная цена провайдера также мало что говорит о повторах запросов, ограничениях частоты, поддержке, минимальных обязательствах, исходящем трафике или инженерных затратах на переход.
Ответственный за маршрутизацию должен вести реестр моделей и провайдеров с такими полями, как:
- тарифы на ввод, вывод, кэшированные данные и пакетную обработку;
- ограничения на контекст и вывод;
- задокументированные ограничения частоты и наблюдаемая пропускная способность;
- распределения задержки, а не только средняя задержка;
- доступность и поведение при тайм-ауте;
- условия использования данных, хранения, размещения и договора;
- поддерживаемые возможности, включая вызовы инструментов, структурированный вывод, работу с изображениями и потоковую передачу;
- варианты резервирования и миграции.
В результате это скорее спецификация состава технологий, чем список названий моделей. Её следует пересматривать при изменении цен, политик, версий моделей или объёмов бизнеса.
2. Инженерия производительности: измеряйте задачу, а не позицию в рейтинге
Общие бенчмарки могут помочь с первоначальной ориентацией, но решения о маршрутизации требуют тестов, специфичных для рабочей нагрузки. Модель, хорошо показывающая себя в общедоступном бенчмарке программирования, может оказаться не лучшим выбором для внутренних репозиториев организации, её соглашений об именовании, схем инструментов или средств контроля безопасности.
Составьте репрезентативный набор для оценки на основе реальных запросов, удалив конфиденциальные материалы или установив для них контроль доступа. Разметьте важные результаты: фактическую корректность, допустимый JSON, успешный выбор инструмента, успешное прохождение тестов кода, поведение при отказе, необходимость эскалации и приемлемый стиль. Затем фиксируйте стоимость, время до получения первого токена, общую задержку, долю тайм-аутов, долю повторных запросов и длину ответа.
Не сводите результат слишком рано к одной оценке. Взвешенная оценка может скрыть серьёзный режим отказа. Например, модель с превосходным средним качеством, но частыми некорректными вызовами инструментов может быть непригодна для автоматизированного процесса. Более медленная модель может быть экономически предпочтительнее, если её ответы сокращают дорогостоящую проверку человеком.
Используйте процесс «чемпион — претендент»: сохраняйте текущий утверждённый маршрут, проверяйте альтернативы на том же наборе данных и переводите претендента в основной маршрут только после того, как он преодолеет явно заданные пороги качества и эксплуатационных показателей. Заявления провайдеров следует рассматривать как исходные данные для плана тестирования, а не как доказательство того, что модель будет работать аналогично в вашей среде.
3. Архитектура: возможность заменять модель
Маршрутизация становится дорогостоящей, когда допущения, связанные с конкретными моделями, проникают во всё приложение. Устойчивая архитектура отделяет бизнес-задачу от вызова провайдера.
Определите внутренний контракт возможностей. Он может предусматривать, что операция «классификация» возвращает фиксированную схему, поля уверенности или отказа от ответа, идентификатор модели и идентификатор трассировки. Для операции «черновой ответ» можно задать ограничения на тон, требования к цитированию и максимальный допустимый бюджет задержки. Затем адаптеры провайдеров преобразуют этот контракт в вызовы отдельных API.
Версионируйте промпты, схемы, определения инструментов, правила безопасности и политики маршрутизации. Записывайте, какой снимок модели и какой провайдер обслужили каждый запрос. Сохраняйте достаточно информации для воспроизведения решения, не удерживая без необходимости конфиденциальное содержимое пользователя.
Продуманно проектируйте резервные варианты. Резервным вариантом может быть другой провайдер, меньшая модель, рабочий процесс с постановкой в очередь или путь, предусматривающий проверку человеком. Он не должен незаметно менять смысл задачи. Если структурированный вывод обязателен, резервный вариант должен поддерживать тот же контракт или запускать контролируемую эскалацию.
4. Управление: определяйте, когда не следует маршрутизировать автоматически
Некоторые запросы не следует отправлять ни самой дешёвой доступной модели, ни вообще какой-либо внешней модели. Политика маршрутизации должна содержать правила исключения для конфиденциальных данных, решений с серьёзными последствиями, неподдерживаемых языков, необычно длинного контекста или действий, требующих этапа утверждения человеком.
Командам также следует различать техническую доступность модели и её одобрение для конкретного применения. Требования закупок и законодательства могут различаться для разных подразделений. Модель может отлично показать себя в ходе оценки и при этом оказаться непригодной для рабочего процесса, условия обработки данных в котором не соответствуют требованиям организации.
Практическая таблица маршрутизации
Начальная политика может быть простой и однозначной:
| Класс задачи | Основная цель | Возможный маршрут | Условие эскалации |
|---|---|---|---|
| Извлечение данных в больших объёмах | Корректная схема и низкая стоимость единицы обработки | Малая или средняя модель со строгой проверкой выходных данных | Ошибка схемы или низкая уверенность |
| Сложный анализ | Качество и работа с доказательствами | Более мощная модель с большим бюджетом задержки | Отсутствующие доказательства, неоднозначность или срабатывание правила политики |
| Интерактивная помощь | Быстрое воспринимаемое реагирование | Модель с низкой задержкой, за которой при необходимости следует доработка | Низкая уверенность или запрос пользователя на подробный ответ |
| Чувствительный рабочий процесс | Утверждённая обработка данных и возможность аудита | Поставщик, одобренный условиями договора, или контролируемое развёртывание | Неодобренные данные, действие или юрисдикция |
Точная таблица будет различаться в зависимости от организации. Важно, чтобы правила маршрутизации были понятны специалистам по продукту, безопасности, финансам и разработке, а не спрятаны в условном операторе.
Что это означает для тех, кто строит карьеру
Самые сильные кандидаты для такой работы будут сочетать несколько видов компетентности. Они будут достаточно разбираться в машинном обучении, чтобы рассуждать о возможностях и деградации; достаточно хорошо знать системную инженерию, чтобы управлять задержками, повторными попытками, ограничениями частоты запросов и сценариями отказа; достаточно разбираться в финансах, чтобы моделировать совокупную стоимость; а также обладать достаточными знаниями в области закупок и управления, чтобы оценивать обязательства и ограничения поставщиков.
Им также будет комфортно составлять записи о принятых решениях. Полезная запись объясняет, почему был выбран определённый маршрут, какие свидетельства это подтверждают, какие риски сохраняются и какое событие должно стать поводом для повторной оценки. Это ценнее, чем заучивание последних названий моделей, поскольку названия моделей и цены будут постоянно меняться.
Небольшой проект для портфолио может продемонстрировать этот навык без необходимости создавать крупную производственную систему. Возьмите одну рабочую нагрузку, создайте обезличенный набор для оценки, подключите трёх поставщиков моделей или локальные модели через общий интерфейс и сравните качество, валидность схемы, перцентили задержки, частоту сбоев и расчётную ежемесячную стоимость при нескольких объёмах использования. Добавьте правила политики для чувствительных входных данных и резервный маршрут. Опубликуйте методику тестирования и ограничения.
Точно определите, что доказывает проект. Он не доказывает, что одна модель универсально лучше всех. Он доказывает, что вы умеете превратить неоднозначную задачу выбора модели в измеримую операционную политику.
Карьерный сигнал
Маршрутизация моделей приобретает стратегическое значение, поскольку интеллект больше не является одной фиксированной зависимостью. Это портфель сервисов с разными компромиссами и меняющейся экономикой. Команды, которые относятся к этому портфелю как к взаимозаменяемой инфраструктуре, могут снизить затраты, но одновременно создать скрытые проблемы с качеством, соблюдением требований и надёжностью. Команды, которые воспринимают его как постоянную привязку к одной модели, могут упустить лучшие варианты.
Возникающая дисциплина находится между этими крайностями: она достаточно абстрактна, чтобы менять поставщиков, достаточно конкретна, чтобы сохранять качество выполнения задач, и достаточно основана на данных, чтобы обосновывать выбор. В этом и заключается карьерная возможность в области маршрутизации моделей — не разово выбрать API, а построить систему принятия решений, которая продолжает делать правильный выбор.
Tom Whitfield — ответственный редактор AI Career Brief, освещающий навыки, роли и разумные карьерные шаги для работы в эпоху ИИ.
