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

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

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

Кратко

• Маршрутизация на основе уверенности направляет каждый запрос на основе оценки, которую модель дает своему собственному ответу, поэтому дешевая модель обрабатывает запросы, в которых она уверена, а более мощная модель видит только те, в которых она не уверена.
• Принудительно задавайте оценку с помощью структурированных выходных данных. JSON-схема, требующая числового поля уверенности, дает вам одинаковый сигнал от каждой модели, вместо того чтобы пытаться угадать его по уклончивым словам в обычном тексте.
• Используйте ранжирование, а не абсолютное число. Значение 0,85 не является откалиброванной 85-процентной вероятностью правильности. Проверьте на своем трафике, что ответы с более низкой оценкой оказываются неверными чаще, чем ответы с более высокой, и выполняйте маршрутизацию на основе этого порядка.
• Установите пороговое значение на основе собственных данных. Пропустите репрезентативный трафик через дешевую модель, посмотрите уровень ошибок для каждого диапазона оценок и установите отсечку там, где уровень ошибок начинает расти.
• Относитесь к пороговому значению как к настройке, которую нужно периодически пересматривать. Регистрируйте распределение оценок, уровень эскалации и уровень ошибок для неэскалированных ответов, а также проводите повторную настройку при изменении ваших моделей или трафика.

Что такое оценка уверенности и чем она не является

Оценка — это самоотчет. Модель создает ее так же, как и остальную часть своего ответа, поэтому она несет в себе ту же неопределенность. Две одинаковые оценки не гарантируют одинаковую вероятность правильности. Значение 0,85 для одного промпта не взаимозаменяемо со значением 0,85 для другого промпта или от другой модели, и это число не является откалиброванной вероятностью.

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

Этап 1: Получение числового поля уверенности с помощью структурированных выходных данных

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

Вместо этого заставьте модель возвращать поле уверенности как часть ответа, проверенного по схеме, используя структурированные выходные данные. Вы передаете response_format типа json_schema и требуете как ответ, так и числовую уверенность от 0 до 1:

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

Схема указывает диапазон от 0 до 1 в описании поля, а не с помощью ключевых слов minimum и maximum. Документация Anthropic по структурированным выходным данным указывает, что числовые ограничения, такие как минимум и максимум, не поддерживаются, поэтому вариант с описанием — это то, что работает у разных провайдеров. strict: true просит провайдеров, у которых есть встроенный строгий режим, соблюдать схему в точности. Принудительное соблюдение варьируется в зависимости от провайдера, и некоторые рассматривают схему как сильную подсказку, а не как гарантию, поэтому проверяйте распарсенный JSON перед тем, как выполнять маршрутизацию на его основе.

Две проверки, прежде чем полагаться на это. Во-первых, поддержка структурированного вывода устанавливается для каждой конечной точки провайдера, а не для каждой модели, и одна и та же модель может обслуживаться провайдерами, которые поддерживают и не поддерживают ее. Отфильтруйте страницу моделей до моделей хотя бы с одной поддерживающей конечной точкой и проверьте параметр structured_outputs в разделе «Провайдеры» на странице модели. Во-вторых, установите require_parameters: true в настройках вашего провайдера, чтобы мы направляли запрос только на те конечные точки, которые поддерживают каждый параметр в нем. Без этого флага response_format является мягким предпочтением. Мы направляем запросы на поддерживающие конечные точки, когда у модели они есть, но если ни одна из конечных точек модели не поддерживает его, мы все равно отправляем запрос, а параметр игнорируется.

Этап 2: Установка начального порогового значения на основе ваших собственных уровней ошибок

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

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

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

Уровень ошибок резко возрастает ниже 0,70, поэтому 0,7 является кандидатом на отсечку. Порог 0,7 эскалирует два диапазона под ним (14 процентов запросов) и позволяет остальным 86 процентам разрешаться на дешевой модели.

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

Этап 3: Настройка порогового значения с учетом точности, стоимости и задержки

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

Точность. Более высокий порог отправляет больше пограничных ответов на второй вызов, поэтому ошибок становится меньше. В приведенном примере перемещение отсечки с 0,7 до 0,85 также эскалирует диапазон от 0,70 до 0,84, который имел уровень ошибок 11 процентов. Эскалация возрастает с 14 до 32 процентов запросов, а уровень ошибок в оставленных ответах падает примерно с 4 до 2 процентов.

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

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

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

Шаг 4: Маршрутизация запросов с низкой уверенностью в вашем коде

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

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

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

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

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

Шаг 5: Мониторинг и повторная настройка в продакшене

Порог, который подходил при запуске, может перестать подходить. Записывайте три вещи с первого дня.

• Распределение оценок, чтобы вы могли повторно запустить калибровку из Шага 2 по мере изменения моделей или трафика.
• Уровень эскалации с течением времени.
• Уровень ошибок в неэскалированных ответах — это число, которое говорит вам, выполняет ли пороговое значение свою задачу.

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

Распространенные ошибки

Отношение к самооценке модели как к калиброванной вероятности. Метод работает на ранжировании, а не на буквальной вероятности. Отсортируйте пакет ответов по оценке, и неверные ответы сгруппируются в нижней части, но 0.9 не означает, что ответ верен в 90 процентах случаев. Устанавливайте порог на основе упражнения по определению уровня ошибок по диапазонам из Шага 2, а не на основе «сырого» числа.

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

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

Заключение

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

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

Что такое порог уверенности?

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

Что такое оценка уверенности в ИИ?

Оценка уверенности — это число, обычно от 0 до 1, которое модель сообщает вместе со своим ответом, чтобы показать, насколько она уверена. Это самооценка, а не калиброванная вероятность, поэтому 0.9 не означает 90-процентную вероятность правильности. То, что вы можете измерить и на что можете положиться, — это ранжирование. На пакете ваших собственных запросов проверьте, что ответы с более низкой оценкой оказываются неверными чаще, чем ответы с более высокой оценкой, прежде чем настраивать маршрутизацию по этой оценке.

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

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

Как автоматически эскалировать запрос с небольшой модели на передовую модель?

Настройте небольшую модель на возврат числового поля уверенности (confidence) с помощью структурированного вывода, а затем используйте ваш код для маршрутизации на основе этого значения. Если оценка ниже установленного вами порога, отправьте тот же запрос передовой модели — либо внутри той же функции, либо в качестве явного второго вызова. Резервные модели (fallbacks) в OpenRouter — это отдельная функция. Они переключают вызов на другую модель при возникновении ошибок, таких как простой провайдера или превышение лимитов запросов, а не при низком уровне уверенности, поэтому разделяйте эти два механизма.

Ссылки

• Структурированные выводы для response_format с типом json_schema, поддержкой на уровне эндпоинтов и строгим режимом (strict mode).
• Маршрутизация провайдеров для require_parameters и предпочтительный параметр по умолчанию для response_format.
• Резервные модели для массива models и ошибки, которые их активируют.
• Структурированные выводы Anthropic для ключевых слов JSON Schema, которые не поддерживаются строгим режимом Anthropic.
• Модели с поддержкой структурированного вывода и каталог моделей для актуальных идентификаторов (slugs) моделей.
• Цены для текущих тарифов каждой модели.