Большие языковые модели на резерве: тихий fallback меняет ответ, а код не замечает

Почему резервная модель не равна резервному серверу?

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

С большими языковыми моделями эта прозрачность становится ловушкой. Автор исходного разбора показывает: две модели могут поддерживать одинаковую JSON-схему (формат обмена данными), одинаковый размер контекста, одинаковую температуру (параметр «креативности» ответа) и при этом решать конкретную задачу на разном уровне. Техническая совместимость совпадает, качество выполнения нет.

Пример: как тихий fallback меняет бизнес-логику

Возьмём сервис, который анализирует договор и оценивает риск.

Основная модель вернула:

{
  "risk_level": "high",
  "reasons": [
    "Unlimited liability",
    "Automatic renewal without notice"
  ]
}

Шлюз переключился на дешёвую резервную модель, и она вернула:

{
  "risk_level": "medium",
  "reasons": [
    "Automatic renewal clause"
  ]
}

Формат идентичен. HTTP-статус 200 (успех). Но код ниже по цепочке проверяет: если уровень риска «high», отправить документ на ручную проверку юристу. Резервная модель занизила оценку, ручная проверка не запустилась, и пользователь получил результат, который выглядит как полноценный анализ, но по факту неполон.

Инфраструктурное решение о переключении молча изменило бизнес-поведение, и вызывающий код об этом не узнал.

Что понадобится

• Доступ хотя бы к двум большим языковым моделям: основной и резервной (подойдут API OpenAI, Anthropic, а из доступных в РФ: YandexGPT, GigaChat).
• Код или конфигурация шлюза (gateway), через который приложение отправляет запросы к моделям.
• Набор тестовых задач с эталонными ответами для каждой задачи, на которой работает ваш сервис.
• Около часа на первичную разметку профилей качества и настройку маршрутов.

Пошаговая инструкция

1. Определите задачи, которые решает ваш сервис. Не «модель A лучше модели B вообще», а конкретно: классификация обращений, извлечение фактов из текста, оценка юридического риска, генерация черновика. Каждая задача получает свой идентификатор.

2. Присвойте каждой задаче минимально допустимый профиль качества. Профиль качества (quality profile) описывает не модель вообще, а модель в контексте конкретной задачи. Пример уровней:

QualityFast     = "fast"       // допустима просадка, скорость важнее
QualityStandard = "standard"   // базовый уровень, ошибки редки
QualityHigh     = "high"       // критичная задача, замена недопустима

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

Model A   ClassifyTicket: high    ExtractFacts: standard   GenerateDraft: high
Model B   ClassifyTicket: high    ExtractFacts: high       GenerateDraft: standard

Универсального порядка «модель A лучше модели B» обычно просто нет: одна лучше в одном, вторая в другом.

1. Опишите fallback внутри маршрута, а не глобально. Глобальная конфигурация вида «primary: model-a, fallback: model-b» опасна, потому что не отвечает на вопросы: для каких задач, при каких данных, с каким допустимым ухудшением. Каждый маршрут (route) должен содержать:
2. основную модель,

3. список резервных моделей с указанием максимально допустимой деградации.

4. Выберите политику fallback для каждого маршрута. Три режима:

equivalent_only   — переключение только на модель с таким же профилем качества
allow_degraded    — допустима просадка (подходит для простой классификации)
disabled          — fallback запрещён, лучше вернуть ошибку

Для классификации писем «allow_degraded» может быть нормой. Для оценки финансового риска подойдёт «equivalent_only» или «disabled».

1. Настройте честный ответ при деградации. Если задача критична и ни одна резервная модель не дотягивает до минимального профиля, верните явный HTTP 503 с сообщением «analysis temporarily unavailable» вместо тихого переключения. Ложный успех хуже явной ошибки: пользователь воспримет заниженный результат как полноценный анализ.

Что делать с этим прямо сейчас, по ролям

Разработчику. Проверьте, есть ли в вашем шлюзе глобальный fallback без разбивки по задачам. Если да, составьте таблицу «задача, минимальный профиль, политика» и внесите её в конфигурацию маршрутов. Начните с двух-трёх самых критичных задач.

Автору на Дзене, который использует нейросети для контента. Если вы переключаетесь между моделями (например, YandexGPT и GigaChat), помните: ответ на один и тот же промпт (prompt, текстовый запрос к модели) может отличаться не только стилем, но и фактической полнотой. Заведите эталонный промпт и проверяйте новую модель на нём перед тем, как доверить ей рабочие задачи.

Предпринимателю, который заказывает ИИ-интеграцию. Спросите у команды разработки: «Что произойдёт, если основная модель ляжет? Куда уйдёт запрос и проверяли ли вы качество ответов резервной модели на наших задачах?» Если ответ «переключится автоматически, всё будет работать» без таблицы профилей, это повод насторожиться.

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