МОДЕЛИ И МОДАЛЬНОСТИ

Как Sol и Luna изменили экономику распределения задач

Первоисточник события: GPT-6 Sol и Luna расширяют семейство GPT-6 ↗

В этом разборе
РЕТРОСПЕКТИВНЫЙ ВЫВОД

Политике распределения нужны одновременно тип задачи, условие приёмки и путь эскалации.

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

Последовательность создала задачу выбора портфеля

Объяснение Responses от 22 сентября 2025 года задаёт более ранний интерфейс выполнения. Astra появилась в changelog от 3 сентября 2026 года, а Sol и Luna последовали 22 сентября 2026 года. Анонс семейства связывал расширение с разным масштабом работы и бюджетом. Эта хронология обосновывает вопрос о портфеле, но не задаёт готовую политику маршрутизации.

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

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

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

Стоимость модели является одним слагаемым

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

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

Проверка границы между соседними задачами

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

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

Выпуск изменил поверхность выбора

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

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

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

← Все ретроспективы