Цепочка моделей или одна сильная модель: где что лучше

В чем здесь выбор

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

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

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

Обычно выбор сводится к четырем вопросам:

• Можно ли решить задачу одним хорошим запросом без промежуточной логики?
• Нужны ли разные шаги с разными правилами качества?
• Терпимы ли для пользователя лишние 1-3 секунды?
• Дает ли дробление заметную экономию по объему и цене?

Поэтому спор между цепочкой и одной сильной моделью редко решают по вкусу команды. Его решают по метрикам. Если одна модель отвечает за 4 секунды и попадает в цель в 92% случаев, а цепочка отвечает за 7 секунд и дает 93%, выигрыш сомнительный. Но если цепочка убирает половину дорогих вызовов и держит качество, смысл уже есть.

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

Когда одна сильная модель выигрывает

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

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

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

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

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

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

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

Когда цепочка из дешевых шагов окупается

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

Хороший пример - короткие запросы, где сначала нужно понять класс обращения, вытащить 2-3 поля и вернуть строгий ответ в JSON. Для такой работы часто хватает дешевой модели. Она быстро отвечает yes/no, ставит тег, определяет язык сообщения или решает, хватает ли данных для следующего шага.

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

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

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

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

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

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

Как собрать пайплайн без лишней задержки

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

Сначала отделите дешевое от дорогого

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

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

Полезное правило простое: один шаг - один понятный выход. Лучше, когда каждый узел отдает что-то очень простое - метку категории, yes/no, короткое поле вроде номера заказа, оценку уверенности или флаг "нужен дорогой разбор".

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

Мерьте по живому потоку, а не по красивым примерам

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

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

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

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

Сценарий: разбор обращений в поддержку

Интернет-магазин получает 10 000 обращений в месяц. Половина из них проста: "Где мой заказ?", "Как вернуть товар?", "Почему не проходит оплата?" Если отправлять все такие сообщения в одну дорогую модель, команда быстро увидит лишние расходы и не самую приятную задержку.

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

Как выглядит такой поток

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

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

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

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

Где сравнение дает честный ответ

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

На практике картина часто такая: 60-70% обращений закрываются шаблоном быстрее и дешевле, 20-30% требуют короткого ответа средней сложности, а 5-10% лучше сразу отдавать сильной модели.

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

Где цепочка только мешает

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

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

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

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

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

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

Как считать цену и задержку честно

У цепочки почти всегда лучше выглядит цена отдельного шага. Но команда платит не за вызов сам по себе, а за полезный ответ. Если из 100 запросов 30 дошли до дорогой модели, 10 потребовали ретрай, а 7 ушли на ручной разбор, смотреть только на цену первого этапа бессмысленно.

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

Удобно вести одну таблицу по всему пайплайну. В ней обычно достаточно пяти показателей:

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

Длина контекста часто съедает ожидаемую экономию. Первый шаг может быть дешевым, но после него второй получает уже не 800 токенов, а 4000 из-за длинной сводки, истории или служебных полей. Поэтому токены надо мерить на каждом переходе, а не только по финальному ответу.

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

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

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

Быстрый чек-лист перед запуском

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

Проверьте пять вещей:

• Есть ли четкое правило эскалации? Не "если ответ слабый", а конкретный сигнал: низкая уверенность классификатора, длинный документ, спорный тон, запрос с персональными данными, выход за лимит по фактам.
• Понимаете ли вы цену ошибки в роутинге? Если дешевая модель отправила сложный запрос не туда, сколько это стоит: потерянный лид, повторное обращение, ручная проверка, штраф по SLA.
• Меряете ли вы задержку по шагам, а не только общее время? Часто проблема не в генерации, а в лишнем препроцессинге, повторной валидации или втором запросе, который почти ничего не меняет.
• Пытались ли вы убрать один вызов? Если после удаления шага качество почти не падает, этот шаг лишний.
• Умеет ли первый шаг падать безопасно? Если классификатор не уверен или ловит таймаут, поток не должен ломаться. Он должен отправить запрос дальше по запасному сценарию.

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

На практике лишний шаг часто съедает 300-700 мс. Для чат-подсказок это заметно сразу. Для ночной пакетной обработки это может быть нормально. Все решает контекст.

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

Не спорьте о схеме на уровне мнений. Возьмите 2-3 живых сценария, где LLM уже приносит пользу бизнесу: разбор входящих обращений, поиск ответа по базе знаний, подготовка черновика для оператора. Для каждого сценария соберите один и тот же набор примеров, чтобы сравнение было честным.

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

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

Если команда хочет быстро сравнить провайдеров и модели, нет смысла переписывать интеграцию под каждый тест. Например, AI Router дает один OpenAI-совместимый endpoint, через который можно менять модель и провайдера без изменений в SDK, коде и промптах. Для пилота это удобно: сегодня вы проверяете одну схему, завтра другую, а обвязка остается той же.

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

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