Ловушка одной модели
Каждый крупный поставщик ИИ хочет, чтобы вы верили: его флагманская модель — правильный ответ на любой вопрос. Это убеждение коммерчески удобно ему и технически ложно для вас.
Модель, блистающая в юридическом рассуждении с длинным контекстом, не годится для подписи из десяти слов. Модель с передовым зрением избыточна — и, вероятно, слишком дорога — для пакетной задачи, переформатирующей структурированный JSON. Модель, цена которой оптимизирована под пропускную способность, может оказаться худшим выбором, когда ответ нужен за две секунды.
Когда вы строите на одной модели, вы выбираете не лучший инструмент. Вы выбираете лучший доступный инструмент внутри искусственного ограничения. Со временем это ограничение накапливается: вы переплачиваете за простые задачи, недотягиваете на сложных, а когда у этого поставщика сбой или рост цен, весь ваш продукт встаёт.
Возможности, а не имена
Полезная абстракция — не «какая модель», а «какие возможности нужны этому запросу». У этого вопроса есть точный ответ.
Сообщению чата с приложенным снимком экрана нужно зрение. Шагу процесса, вызывающему внешний API, нужны инструменты. Помощнику по коду, который должен проверять собственный вывод, нужно выполнение кода. Ночному конвейеру обобщения, которому не нужна скорость, подойдут пакетные цены; встроенному в продукт помощнику, которого ждёт человек, — нет.
Когда вы сперва перечисляете требования к возможностям, выбор модели становится задачей фильтрации и сортировки. Имея требуемый набор — скажем, текст, зрение и структурированный вывод, — вы находите все модели, поддерживающие все три, и затем сортируете их по качеству и цене для текущего контекста запроса. Эта сортировка может меняться от запроса к запросу в зависимости от того, что человек делает и как обстоят дела с его средствами.
Именно это и делает конвейер маршрутизации ToRun. Режим (Чат, Код, Изображение, Исследование и другие) отображается на набор возможностей. Набор фильтрует каталог моделей. Ранжирование по цене и качеству выбирает победителя. В итоге вы можете использовать DeepSeek для структурированного извлечения в больших объёмах, Claude или модели класса GPT-4 для тонкого рассуждения, Google Gemini для работы с документами и длинным контекстом и специализированную модель изображений для генерации — всё с одной продуктовой поверхности, не написав логики распределения.
Резерв — не приятное дополнение
Сбои поставщиков — не редкие крайние случаи. Они происходят по всей отрасли несколько раз в месяц. Если ваш продукт зависит от одного поставщика и его API деградирует, ваш продукт деградирует вместе с ним.
Цепочка резерва — операционный минимум: когда основная модель возвращает временную ошибку по запросу, платформа повторяет его на следующей лучшей пригодной модели. Это предполагает, что слой маршрутизации уже знает, какие модели пригодны, — а это ровно то, что даёт маршрутизация по возможностям.
У резерва есть и менее очевидная польза: он делает ваше биллинговое поведение предсказуемым. Если модель первого выбора временно превысила лимит использования, уход на следующую пригодную модель удерживает стоимость в диапазоне, не показывая человеку ошибку.
Практический вывод
Оценивая ИИ-платформы, задайте два вопроса: как она выбирает модель для каждого запроса и что происходит, когда эта модель недоступна или оказывается слишком дорогой?
Если ответ на любой из них — «она всегда берёт модель X», это архитектурный запашок. Модели, доступные сегодня, не будут лучшими моделями через полгода. Появляются новые поставщики. Цены сдвигаются. Границы возможностей меняются. Архитектура, трактующая выбор модели как задачу маршрутизации, а не как решение конфигурации, стареет лучше, обходится со временем дешевле и изящнее деградирует под нагрузкой.
Одна модель — точка отсчёта. Слой маршрутизации — настоящий фундамент.