Microsoft-Decision-1 уже доступна на Foundry. Вкладка с бенчмарками пуста.

Самое интересное в выпуске Microsoft на этой неделе — не то, что Microsoft-Decision-1 умеет. А то, что Microsoft решила об этом не публиковать. Модель запущена: она стала общедоступной в Microsoft Foundry 8 октября 2026 года, за два дня до написания этого текста. Это модель оценки решений — вы даёте ей состояние и вопрос с фиксированным набором ответов, и она возвращает калиброванную вероятность для каждого ответа — дообученная Microsoft на модели с открытыми весами Qwen3.5-9B, выполняющая один проход по последовательности длиной до 32 768 токенов и выдающая ноль выходных токенов, потому что она вообще ничего не генерирует. На странице каталога есть вкладка Benchmarks. Она содержит абзац о методологии и ни одной цифры.

Этот пробел и есть главное, и он полезнее, чем ещё один материал в духе «Microsoft выпускает модель». Каждый серьёзный вопрос о скоринговой модели — это вопрос калибровки: означает ли возвращённое значение 0,8 именно 0,8, — а запуск, который выходит без единого значения Brier score или показателя ожидаемой ошибки калибровки, оставляет единственное важное число на измерение тем, кто его внедрит. Далее — то, что страница Foundry на самом деле документирует, что она демонстративно опускает, и что команда оценки может с этим сделать на этой неделе.

Что именно было выпущено

Microsoft-Decision-1 — это размещённый API. Контракт таков: один вызов на входе, одно распределение на выходе, и нигде на этом пути нет цикла декодирования: запрос содержит материал, подлежащий оценке, а также вопрос с ограниченным набором ответов, а ответ содержит вероятность для каждого варианта. Microsoft перечисляет поддерживаемые формы вопросов: да/нет, множественный выбор, оценка, классификация и на основе рубрик — и всё это в рамках одного вызова объёмом до 32K токенов. Он работает только с текстом — без ввода изображений, аудио или видео, а на выходе только числа.

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

Из списка развёртывания выделяются две операционные детали. Первая — Microsoft явно поддерживает вариант воздержания от ответа, например «cannot tell», когда предоставленных доказательств недостаточно; это разница между калиброванным оценщиком и просто уверенным, и именно это обеспечивает работу порогового отсечения. Вторая — пакетный инференс отключён. Нельзя амортизировать большой прогон скоринга через пакетный канал так, как это делается с генеративной моделью, поэтому задержка на вызов — это задержка вашего конвейера, а не проблема офлайн-задания.

Распространение только через Foundry, в портфеле «Direct from Azure» как бессерверное развертывание или развертывание с унифицированной конечной точкой на стандартном SKU — оплата по мере использования или зарезервированная подготовленная пропускная способность. Веса не распространяются. Нет репозитория Hugging Face, нет возможности скачать, нет возможности дообучения и нет варианта самостоятельного хостинга. Приложения интегрируются по HTTPS со стандартной аутентификацией Azure. В раскрытии информации об обучении указано, что набор данных впервые был использован в сентябре 2026 г. при продолжающемся сборе, что представляет собой минимально возможный разрыв между обучающими данными и датой GA и является нормой для пост-тренировки на чужой выпущенной базовой модели.

Вкладка бенчмарков, процитированная полностью

Вот всё, что Microsoft опубликовала о том, насколько хорошо работает модель. В оценке использовались «публичные и общественные бенчмарки для принятия решений и отложенные внутренние тестовые наборы, не использовавшиеся при обучении». Метриками были точность, ошибка калибровки, полнота по безопасности, частота ложноположительных срабатываний и согласованность по справедливости. Порядок вариантов варьировался. Применялись парные статистические тесты. Утверждение носит качественный характер: Microsoft-Decision-1 «показывает результаты на уровне ведущих моделей принятия решений и опережает другие открытые модели принятия решений, оценённые по той же методологии».

Это грамотный дизайн оценки, описанный без результата. Указать на это — не обвинение: абзац о методологии без таблицы — это конкретный, проверяемый выбор, и это иной выбор, нежели тот, который сделали остальные в этой небольшой категории. Открытые модели принятия решений, с которыми Microsoft неявно сравнивает себя, публикуют свои показатели: семейство Intern-Decision от InternLM публикует значения Brier и ожидаемой ошибки калибровки на своих карточках моделей, Jev от TypeSafe публикует и то и другое, а линейка d1 от Liquid AI выпускает таблицы точности вместе со своими весами. Microsoft — крупнейшая компания в этой группе и единственная, кто просит верить ей на слово.

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

Охват языков несёт такую же оговорку. 25 языков указаны как поддерживаемые — среди прочих японский, корейский, арабский, вьетнамский, тайский, турецкий, хинди, бенгальский, суахили, иврит, персидский и украинский, — с явным предупреждением, что охват, качество и калибровка «могут различаться в зависимости от языка» и что неанглийские, особенно низкоресурсные языки, — это область недостаточной эффективности. Базовая модель Qwen3.5-9B поддерживает более 200 языков. После дообучения осталась примерно четверть из них, и именно на этой четверти проводилась калибровка.

На странице тоже нет цены

Поле цены в каталоге не отображает тариф. Оно ведёт ссылкой на собственную страницу цен Microsoft для моделей, так что стоимость одного решения вы узнаёте из Azure или из счёта, а не из карточки модели. Для тех, кто моделирует стоимость одного решения при больших объёмах, это настоящий пробел, и об этом стоит сказать прямо, а не оценивать наугад. Из архитектуры действительно следуют две вещи, которые стоит учесть в этой оценке: 0 % стоимости вызова составляют выходные токены, потому что их нет, а набор вариантов входит в состав входных данных, поэтому вопрос с 62 описательными вариантами стоит дороже за вызов, чем да/нет — вы платите за написанную вами рубрику, а не за ответ.

Почему именно такая форма релиза — это самое интересное

Оценщик решений — это ставка на то, что примитивным предприятиям на самом деле нужен не лучший автор, а более дешёвый и надёжный судья. Эта ставка окупается только в том случае, если вероятность заслуживает доверия, потому что всё, что идёт после оценщика, — это порог: 0,7 означает эскалацию к человеку, 0,95 — автоматическое принятие, а цена ошибки на этой границе выражается в плохих автоматических решениях, а не в токенах. Поставщик, который выпускает оценщик без таблицы калибровки, просит каждого клиента заново вывести её на собственных данных.

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

Пробую это на этой неделе, без обязательств

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

Место OrcaRouter — в другой половине цикла оценки, и это та половина, которая генерирует. Мы не размещаем Microsoft-Decision-1, и его нет в нашем каталоге: модель, возвращающая вероятности вместо текста, — это не то, куда направляют запросы chat completions, и ничто здесь не следует воспринимать как заявление о доступности. За одним нашим ключом, совместимым с OpenAI, стоит пул из более чем 200 моделей, который и занимается написанием: модель, составляющая рубрику, две, выдающие варианты ответов, и та, что формирует вызов инструмента Decision-1, а затем оценивает его перед запуском. Прайс-лист провайдера передаётся без наценки — 0%, так что снижение цены на стороне генератора в тот же день действует и у нас, а автоматическое переключение при сбое поддерживает работоспособность звена генерации, когда один провайдер деградирует, — и это важнее в конвейере, который оценивает всё, что видит, чем в том, который лишь изредка отвечает пользователю. Если вы предпочитаете не выбирать одного судью, DSL маршрутизации объединяет несколько моделей в один вызов, а слияние моделей сообщает об их согласии как об оценённом поле, а не как о тексте, который нужно читать.

Что изменило бы эту статью, так это таблица. Опубликуйте показатели Бриера и ECE или позвольте независимому прогону попасть в таблицу лидеров — и приведённая выше оценка станет подтверждением, а не единственным существующим доказательством. До тех пор точное описание Microsoft-Decision-1 остаётся узким: веса реальны, контракт задокументирован лучше, чем это удаётся большинству хостируемых релизов, возможность воздержаться предусмотрена с самого начала, а не прикручена сбоку, а заявление о производительности — это одно предложение, хорошо написанное и не привязанное ни к каким числам.

Итог

Microsoft-Decision-1 стал общедоступным в Microsoft Foundry 8 октября 2026 года как ориентированный только на текст оценщик решений на 32 768 токенов, построенный на Qwen3.5-9B, который возвращает калиброванные вероятности по вашим собственным наборам вариантов при нулевом количестве выходных токенов и без весов для скачивания. Его сильные стороны — чистый контракт с одним проходом, встроенный путь отказа от ответа и привязанные аутентификация, выставление счетов и управление Azure; его слабость в том, что ни у кого за пределами Microsoft нет опубликованного числа, показывающего, насколько хорошо он калиброван, включая саму Microsoft. Относитесь к запуску как к появлению доступного API, а не как к установленной возможности, и прогоните через него свои собственные размеченные случаи, прежде чем что-либо ниже по потоку начнёт зависеть от порогового значения.