Эскалируем сомнительные ответы — AI Gateway

Что делает обновление

AI Gateway добавил возможность эскалации решения на запасную модель при низкой уверенности ответа основной модели. Под «уверенностью» в этом контексте понимаются сигналы, которые модель возвращает для вопросов типов Choice (выбор) и Score (оценка). Для логического (Boolean) ответа условие проверяется как диапазон вероятностей.

Настроить поведение можно, добавив один условный объект в providerOptions.gateway.models. Если объект отсутствует, существующее поведение запросов не меняется. Обычные падения по явным именам моделей, которые вы уже указываете в models, продолжают ловить прямые ошибки — новые условия не ломают текущие настройки запасных моделей.

Как настроить: синтаксис и пример

Чтобы включить эскалацию, в теле запроса решения (decision) укажите модель решения и добавьте в providerOptions.gateway.models объект с полем when. В примере исходника показан вызов experimental_decide и запись вида:

model: gateway.decisionModel('typesafe-ai/jev'), state: '…', questions: { intent: { type: 'choice', instructions: 'Which team should handle this?', criteria: { billing: 'Charges and refunds', technical: 'Bugs and outages' } } }, providerOptions: { gateway: { models: [ { model: 'openai/gpt-6-astra', when: { question: 'intent', confidenceBelow: 0.6 } } ] } }

Важные детали: ключ when указывает, для какого вопроса применять условие (здесь 'intent'), а confidenceBelow задаёт порог (в примере 0.6). Если опустить поле question, условие проверится для всех вопросов соответствующего типа — то есть { confidenceBelow: 0.6 } сработает, когда любой ответ типа Choice или Score вернёт уверенность ниже 0.6.

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

Практические последствия и сценарии использования

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

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

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

Ограничения

Функция Decision fallbacks пока в бета‑стадии: она помечена как beta в документации Vercel. Это означает, что интерфейс и поведение могут измениться, а поддержка и гарантия стабильности ограничены.

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

Условия охватывают ответы типов Choice и Score; для Boolean‑вопросов проверка базируется на диапазоне вероятностей, а не на одном пороге confidenceBelow. Если нужен иной критерий, его придётся реализовать с учётом этих ограничений.

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