Эскалация по уверенности: как оптимизировать расходы на LLM

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

Здесь на сцену выходит стратегия, известная как эскалация на основе порога уверенности (confidence-based escalation). Этот подход позволяет модели самой оценить качество своего ответа. Если модель уверена в результате, запрос остается на дешевом «легком» движке. Если же уверенность низка, запрос автоматически перенаправляется на более мощную модель для уточнения. Это создает интеллектуальный буфер между слепой экономией и расточительством.

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

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

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

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

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

02Шаг 1: Получение числового поля уверенности через структурированный вывод

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

Правильный подход — заставить модель вернуть поле уверенности как часть структурированного вывода (structured outputs). Вы передаете параметр response_format типа json_schema, который требует наличия двух полей: самого ответа и числового поля уверенности в диапазоне от 0 до 1.

{
  "model": "openai/gpt-5.6-luna",
  "messages": [
    {"role": "user", "content": "..."}
  ],
  "provider": {
    "require_parameters": true
  },
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "answer_with_confidence",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "answer": {
            "type": "string"
          },
          "confidence": {
            "type": "number",
            "description": "How likely the answer is correct, from 0 (a guess) to 1 (certain)."
          }
        },
        "required": ["answer", "confidence"],
        "additionalProperties": false
      }
    }
  }
}

Обратите внимание на несколько важных технических деталей. Во-первых, диапазон от 0 до 1 указывается в описании поля (description), а не через жесткие ограничения minimum и maximum. Это связано с тем, что некоторые провайдеры (например, Anthropic) в документации к структурированному выводу указывают, что числовые ограничения могут не поддерживаться, и использование описания обеспечивает совместимость с разными провайдерами.

Во-вторых, флаг strict: true просит провайдеров, имеющих нативную поддержку строгого режима, точно соблюдать схему. Однако enforcement (принудительное соблюдение) варьируется. Некоторые провайдеры могут трактовать схему как сильную подсказку, а не как гарантию. Поэтому всегда валидируйте распарсенный JSON перед тем, как принимать решение о маршрутизации.

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

03Шаг 2: Установка начального порога на основе ваших данных об ошибках

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

Сгруппируйте результаты по диапазонам оценок (score bands) и посмотрите, как меняется частота ошибок. Порог следует устанавливать там, где кривая ошибок начинает резко расти.

Рассмотрим рабочий пример. Предположим, вы запустили 200 запросов и получили следующую картину:

• 0.95 – 1.00: 41% запросов, ошибка 1%.
• 0.85 – 0.94: 27% запросов, ошибка 4%.
• 0.70 – 0.84: 18% запросов, ошибка 11%.
• 0.50 – 0.69: 9% запросов, ошибка 34%.
• Ниже 0.50: 5% запросов, ошибка 61%.

Как видно, ошибка резко возрастает ниже отметки 0.70. Следовательно, 0.7 становится кандидатом на роль порога. Установка порога на 0.7 означает, что 14% запросов (те, что ниже 0.7) будут эскалированы на более сильную модель, а остальные 86% будут обработаны дешево. В этом примере общая ошибка дешевой модели составляет около 10%. Эскалация нижних 14% запросов снижает ошибку на оставшихся ответах до примерно 4%, ценой второго вызова модели для одного из семи запросов.

04Шаг 3: Тонкая настройка порога: точность, стоимость и задержка

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

Точность. Повышение порога (например, с 0.7 до 0.85) означает, что больше запросов будут отправляться на второй вызов. Это снижает количество ошибок, которые доходят до пользователя. В нашем примере повышение порога до 0.85 увеличивает долю эскалированных запросов с 14% до 32%, но снижает ошибку на «оставленных» ответах с 4% до 2%.

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

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

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

05Шаг 4: Маршрутизация низких оценок в коде

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

Существует два основных паттерна реализации:

1. Повторная попытка в той же функции (Retry in the same function). Вы оборачиваете вызов в одну функцию. Сначала отправляете запрос на дешевую модель, читаете уверенность. Если она ниже порога, вы сразу же отправляете тот же запрос на сильную модель и возвращаете этот ответ. Этот подход прост в реализации: политика эскалации живет в одном месте. Если вы измените порог или целевую модель, вы меняете это в одном месте.
2. Отдельный первый проход (Run a separate first pass). Вызов дешевой модели рассматривается как первый проход. Вы логируете ответ и оценку, а затем вызываете сильную модель только при необходимости. Этот подход требует больше кода, но он предоставляет богатые данные для логирования: вы видите, как часто происходит эскалация и насколько хорошо оценки коррелируют с реальными ошибками. Это критически важно для Шага 5.

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

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

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

С первого дня логгируйте три ключевые метрики:

• Распределение оценок (Score distribution): Это позволит вам повторно провести калибровку из Шага 2, если распределение сдвинется.
• Коэффициент эскалации (Escalation rate): Сколько процентов запросов уходит на дорогую модель. Резкие скачки могут указывать на проблемы с качеством дешевой модели или на изменение характера трафика.
• Частота ошибок на не-эскалированных ответах: Это главная метрика успеха. Она показывает, насколько хорошо порог выполняет свою работу, отсеивая плохие ответы.

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

07Типичные ошибки при внедрении

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

• Трактовка самоотчета как калиброванной вероятности. Как уже говорилось, 0.9 не означает 90% шанс правильности. Опора на абсолютные числа без проверки на собственном трафике ведет к неверным решениям. Всегда используйте ранжирование и анализ ошибок по бандам.
• Игнорирование изменения трафика. Порог, настроенный на тестовой выборке, может не работать в продакшене, если реальные запросы сложнее или проще. Непрерывный мониторинг необходим.
• Отсутствие логирования. Без данных о том, как часто происходит эскалация и какова реальная ошибка, вы слепы. Вы не сможете понять, работает ли система, пока не начнете собирать метрики.

08Что это значит на практике

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

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

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

09Заключение

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

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

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

Что такое оценка уверенности в AI?
Это число (обычно от 0 до 1), которое модель сообщает вместе с ответом, чтобы сигнализировать о своей уверенности. Это самоотчет, а не калиброванная вероятность, поэтому 0.9 не означает 90% шанс правильности. На что можно положиться, так это на порядок сортировки. На пакет ваших запросов проверьте, ошибаются ли ответы с низкой оценкой чаще, чем с высокой, прежде чем маршрутизировать на основе оценки.

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

Источник: OpenRouter ↗