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

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

Кратко (Tl;dr)

Используйте статические правила для узких, легко распознаваемых FAQ, классификацию на основе триажа для стабильных категорий, выраженных разными формулировками, и проверку ответов, когда дешевая модель должна первой попытаться дать ответ.
Сохраняйте проверки на соответствие политике поддержки в своем приложении. Наши резервные модели (fallbacks) обрабатывают ошибки запросов. Успешный, но неверный ответ требует отдельного решения об эскалации в вашем коде.
Сравнивайте подход «сначала дешевые» с подходами «только дешевые» и «только мощные» по показателям принятия ответов, общей стоимости (включая отброшенные попытки), уровню эскалации и задержке полного цикла.
Добавляйте эскалацию только там, где ваша оценка показывает, что она исправляет ошибки. Эскалация, которая заменяет уже приемлемый дешевый ответ, увеличивает стоимость и задержку, не улучшая результат.

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

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

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

Три паттерна маршрутизации

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

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

Что находится в ведении вашего приложения, а что обрабатывает OpenRouter

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

Если вы хотите, чтобы мы выбрали начальную модель, наш Auto Router, выбираемый параметром "model": "openrouter/auto", классифицирует каждый промпт по типу задачи и выбирает модель из тех, на которые пользователи OpenRouter тратят средства для данного типа задач. Упорядоченный список резервных моделей, передаваемый как массив models, повторяет запрос на следующей модели после ошибки, такой как ограничение частоты запросов (rate limit), простой провайдера или отказ модерации контента. Проверки на соответствие политике поддержки остаются вашей ответственностью.

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

Следующий поток показывает это разделение ответственности.

Пример потока поддержки на OpenRouter

Шаг 1: Определите результат перед выбором модели

HarborDesk — вымышленный SaaS-продукт с фиксированным FAQ. Его бот может объяснять политики и рекомендовать поддержку, но не может проверять аккаунты или вносить изменения. Приемлемый цикл — это ответ на вопрос, просьба об уточнении или рекомендация обратиться к человеку.

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

Шаг 2: Проверяйте сгенерированные ответы перед эскалацией

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

Рассмотрим клиента, который спрашивает, как отменить подписку и запросить возврат средств. Согласно политике HarborDesk, владельцы отменяют подписку в разделе «Настройки > Биллинг», а сотрудники отдела биллинга рассматривают запросы на возврат.

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

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

Шаг 3: Настройте резервное копирование при ошибках и записывайте стоимость запроса

Этот фрагмент кода отправляет один запрос с упорядоченным списком резервных моделей. Установите запросы и задайте OPENROUTER_API_KEY перед запуском. Короткий вымышленный FAQ предоставляет контекст для примера.

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

Две проверки ошибок существуют, потому что мы можем вернуть HTTP 200, когда модель начала обрабатывать запрос, но произошел сбой при создании вывода. Объект ошибки появляется на верхнем уровне тела ответа или внутри choices[0] с параметром finish_reason, установленным в значение error, если существует частичный контент. Справочник ошибок и отладки описывает оба формата. Относитесь к обоим как к сбоям, а не выводите частичный результат в качестве ответа.

Фрагмент выводит невалидированного кандидата для проверки. Поле usage.cost — это сумма в кредитах, которую мы списали за запрос, а model — это модель, которая создала ответ, что важно при срабатывании резервного механизма. Логируйте оба значения для каждого запроса. Когда ваше приложение выполняет эскалацию, суммируйте оба вызова, включая отброшенный черновик дешевой модели. Если ответ приходит без значения стоимости, записывайте стоимость как неизвестную, а не как ноль, пока не сверите ее со своей страницей активности. Кулинарная книга учета использования описывает объект usage.

Измеряйте уровень эскалации и стоимость одного решенного тикета

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

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

Отслеживайте эти показатели для каждой политики маршрутизации.

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

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

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

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

Заключение

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

Часто задаваемые вопросы

Можно ли избежать создания пользовательской службы маршрутизации?

Вы можете оставить маршрутизацию внутри вашего приложения поддержки. Используйте Auto Router, если хотите, чтобы мы выбрали начальную модель, и используйте массив models fallback, чтобы мы повторили попытку с другой моделью после ошибки запроса. Специфические для поддержки проверки принятия, например, соответствует ли ответ вашей политике отмены, по-прежнему должны выполняться в вашем приложении. Храните идентификаторы моделей в конфигурации, а ваши промпты и данные для оценки — в переносимом виде, чтобы вы могли сменить модели позже.

Может ли дешевая модель проконсультироваться с более мощной моделью в процессе генерации?

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

Какую модель для сортировки часто задаваемых вопросов выбрать?

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