﻿# Правила эскалации после запуска Sol и Luna

Sol и Luna расширили выбор для эскалации, но полезное условие переключения зависит от недостающих доказательств и приёмки, а не одной уверенности.

Автор: Редакция Retrivium
Language: ru
Разбор опубликован: 2026-11-03
Дата события: 2026-09-22
Первоисточник новости: https://developers.openai.com/api/docs/changelog
Канонический URL: https://retrivium.ai/ru/retrospectives/sol-luna-escalation-evidence/

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

## Последовательность выпусков не задаёт маршрутизацию

[Объяснение Responses](https://developers.openai.com/blog/responses-api) от 22 сентября 2025 года описывало более ранний интерфейс инструментальной работы. [Датированный changelog](https://developers.openai.com/api/docs/changelog) фиксирует Astra 3 сентября 2026 года, Sol и Luna — 22 сентября 2026 года. [Анонс семейства](https://openai.com/index/introducing-gpt-6-sol-and-luna/) объясняет расширение диапазона способностей и бюджета. Эти даты не устанавливают прикладную границу между ответом, исследованием и передачей случая дальше.

## Уверенность недостаточна для переключения

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

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

## Неразрешённая работа должна оставаться представимой

До выбора ступеней определим исход для недостаточных данных. Он сохраняет недостающее поле, противоречащие документы и следующее допустимое исследование. Старшая модель тогда получает конкретную нерешённую проблему вместо неопределённой просьбы постараться сильнее. Такой объект можно проверить независимо от того, какой исполнитель продолжит работу.

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

## Проверка условия на контрастных случаях

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

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

## Полезная политика остаётся условной

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

Выпуск Sol и Luna сделал доступнее разные стратегии распределения. Ретроспективный урок состоит в том, что дешёвая первая стадия полезна только при видимой неопределённости и обоснованной работе для следующей. Присутствие старшей модели не заменяет определения того, что осталось нерешённым и зачем нужен следующий шаг.

## Связанные материалы

- [Полномочия выполнения вокруг решений модели](/ru/journal/openrouter-tool-calling/)
- [Сравнение принятых результатов](/ru/journal/inference-benchmark-method/)
