Microsoft-Decision-1 está disponível no Foundry. A aba Benchmarks dele está vazia.

A coisa mais interessante sobre o lançamento da Microsoft desta semana não é o que Microsoft-Decision-1pode fazer. É o que a Microsoft escolheu não divulgar sobre ele. O modelo está ativo: entrou em disponibilidade geral no Microsoft Foundry em 8 de outubro de 2026, dois dias antes de isto ser escrito. É um modelo de pontuação de decisões — você fornece a ele um estado e uma pergunta com um conjunto fixo de respostas, e ele retorna uma probabilidade calibrada por resposta — pós-treinado pela Microsoft no modelo de pesos abertos Qwen3.5-9B, executando uma passagem por até 32.768 tokens e emitindo zero tokens de saída porque nunca gera absolutamente nada. A página do catálogo tem uma aba Benchmarks. Ela contém um parágrafo de metodologia e nenhum número.

Essa lacuna é a história, e é uma história mais útil do que outro item do tipo “a Microsoft lança um modelo”. Toda pergunta séria sobre um sistema de pontuação é uma pergunta de calibração — um 0,8 retornado significa 0,8 — e um lançamento que chega sem uma única pontuação de Brier ou valor de erro de calibração esperado deixa o único número que importa a cargo de quem o adotar. O que segue é o que a página do Foundry de fato documenta, o que ela omite de forma flagrante, e o que uma equipe de avaliação pode fazer a respeito nesta semana.

O que foi lançado, precisamente

Microsoft-Decision-1 é uma API hospedada. O contrato é: uma chamada entra, uma distribuição sai, sem qualquer loop de decodificação em nenhum ponto do caminho: a solicitação contém o material a ser avaliado mais uma pergunta com um conjunto limitado de respostas, e a resposta contém uma probabilidade para cada opção. A Microsoft lista os formatos de pergunta compatíveis como sim/não, múltipla escolha, avaliação, classificação e com base em rubrica, tudo dentro de uma única invocação de até 32K tokens. É somente texto — sem entrada de imagem, áudio ou vídeo, e nada além de números na saída.

As exclusões são declaradas com a mesma clareza que as funcionalidades, e vale a pena lê-las antes de tudo: não foi concebido para geração de texto, resposta a perguntas abertas, conversação, tradução ou sumarização, e não se destina a tarefas que exijam conhecimento ausente da entrada. Não produz justificações. Os casos de uso publicados são todos situações em que uma equipa de plataforma já tem uma decisão rotulada a tomar — avaliar uma resposta gerada com base numa rubrica, julgar a relevância da recuperação, fazer a triagem de uma fila, condicionar uma chamada de ferramenta de agente proposta, filtrar conteúdo com base em limiares definidos pela aplicação em vez de uma política fixa do fornecedor, e aceitar automaticamente resultados de alta confiança enquanto se escalam os restantes.

Dois detalhes operacionais se destacam na listagem de implantação. O primeiro é que a Microsoft oferece suporte explícito a uma opção de abstenção, como "não é possível dizer", quando as evidências fornecidas são insuficientes — essa é a diferença entre um pontuador calibrado e um que é apenas confiante, e é o que faz a limiarização funcionar. O segundo é que a inferência em lote está desativada. Você não pode amortizar uma grande execução de pontuação pelo canal de lote como faria com um modelo generativo, então a latência por chamada é a latência do seu pipeline, e não um problema de uma tarefa offline.

A distribuição é exclusiva do Foundry, no portfólio "Direct from Azure" como uma implantação sem servidor ou de ponto de extremidade unificado em SKU padrão — pagamento conforme o uso ou taxa de transferência provisionada reservada. Os pesos não são distribuídos. Não há repositório no Hugging Face, nem download, nem caminho de ajuste fino, nem opção de auto-hospedagem. Os aplicativos se integram via HTTPS com autenticação padrão do Azure. A divulgação de treinamento informa que o conjunto de dados foi usado pela primeira vez em setembro de 2026 com coleta em andamento, o que é a menor distância possível entre os dados de treinamento e uma data de GA e é normal para um pós-treino sobre uma base lançada por outra pessoa.

A aba de benchmarks, citada na íntegra

Aqui está a totalidade do que a Microsoft publicou sobre o desempenho do modelo. A avaliação usou "benchmarks de decisão públicos e da comunidade e conjuntos de teste internos reservados não usados no treinamento". As métricas foram acurácia, erro de calibração, recall de segurança, taxas de falsos positivos e consistência de equidade. A ordem das opções foi variada. Foram aplicados testes estatísticos pareados. A alegação é qualitativa: o Microsoft-Decision-1 "tem desempenho equivalente ao dos principais modelos de decisão e superior ao de outros modelos de decisão abertos avaliados com a mesma metodologia".

Trata-se de um desenho de avaliação competente descrito sem resultado. Não é uma acusação apontar isso — um parágrafo de metodologia sem tabela é uma escolha específica e verificável, e é uma escolha diferente da que o resto desta pequena categoria fez. Os modelos de decisão abertos com os quais a Microsoft está implicitamente se comparando publicam seus números: a família Intern-Decision da InternLM imprime valores de Brier e de erro de calibração esperado em seus cartões de modelo, o Jev da TypeSafe publica ambos, e a linha d1 da Liquid AI traz tabelas de acurácia junto com seus pesos. A Microsoft é a maior empresa deste grupo e a única que pede para que se confie nela.

A empresa de fato diz onde acredita que o modelo é forte e fraco, o que é mais acionável do que uma pontuação de manchete. Mais fortes: raciocínio, aplicação de regras e robustez à formatação de prompts. Competitivos: classificação, recuperação, equidade, uso de ferramentas e a maioria das tarefas multilíngues. Mais fracos: conhecimento especializado de domínio. As limitações auto-relatadas são francas da mesma forma — as pontuações podem variar com a formulação e a ordem das opções, uma pergunta mal formulada ainda retorna uma pontuação, a calibração é mais forte em tipos de tarefas familiares, e não há explicações para auditar quando uma resposta parece errada.

A cobertura de idiomas traz o mesmo tipo de ressalva. 25 idiomas são listados como suportados, abrangendo japonês, coreano, árabe, vietnamita, tailandês, turco, hindi, bengali, suaíli, hebraico, persa e ucraniano, entre outros, com o aviso explícito de que a cobertura, a qualidade e a calibração "podem variar conforme o idioma" e de que o não inglês, particularmente os idiomas de baixos recursos, é uma área de desempenho insuficiente. A base do Qwen3.5-9B suporta bem mais de 200 idiomas. O pós-treinamento manteve cerca de um quarto disso, e o quarto é onde a calibração foi ajustada.

Também não há preço na página

O campo de preços do catálogo não apresenta uma tarifa. Remete para a própria superfície de preços de modelos da Microsoft, pelo que o custo por decisão é algo que se lê no Azure ou numa fatura, e não no cartão do modelo. Para quem modela o custo por decisão em volume, esta é uma lacuna real, e vale a pena afirmá-lo com clareza em vez de o estimar. Da arquitetura decorrem duas coisas que vale a pena levar para essa estimativa: 0% do custo de uma chamada corresponde a tokens de saída, porque não existem, e o conjunto de opções faz parte da entrada, pelo que uma pergunta com sessenta e duas opções descritivas custa mais por chamada do que uma pergunta de sim/não — está a pagar pelos critérios de avaliação que escreveu, não pela resposta.

Por que este formato de lançamento é a parte interessante

Um scorer de decisão é uma aposta de que aquilo de que as empresas primitivas realmente precisam não é um escritor melhor, mas um juiz mais barato e mais confiável. Essa aposta só compensa se a probabilidade for confiável, porque tudo o que está a jusante de um scorer é um limiar: 0,7 escala para uma pessoa, 0,95 aceita automaticamente, e o custo de errar essa linha é pago em decisões automatizadas ruins, e não em tokens. Um fornecedor que entrega o scorer sem a tabela de calibração está pedindo que cada cliente a derive novamente com os próprios dados.

A própria documentação da Microsoft recomenda exatamente isso, o que suaviza a crítica e aguça a conclusão prática ao mesmo tempo. Valide com dados representativos do seu caso de uso. Defina limiares a partir do custo dos seus erros, em vez de um valor padrão. Sempre inclua uma opção de abstenção. Aleatorize a ordem das opções quando a ordenação puder enviesar a resposta. Mantenha um humano no circuito para qualquer coisa com consequências. Esse é um conselho sólido para qualquer pontuador. É o único conselho disponível para este.

Vou experimentar esta semana sem me comprometer.

A avaliação mais barata é escolher uma decisão que você já toma à mão, montar duzentos casos rotulados com os conjuntos de respostas que sua aplicação realmente forneceria e executá-los em uma implantação do Foundry. Calcule o erro de calibração esperado na saída e você saberá mais sobre o Microsoft-Decision-1 do que qualquer coisa que a Microsoft tenha publicado a respeito, porque você o terá medido na sua distribuição em vez de em um conjunto de teste interno mantido à parte. Isso é uma tarde de trabalho e aposenta toda a questão do benchmark.

O lugar onde o OrcaRouter se encaixa é na outra metade de um ciclo de pontuação, e é a metade que gera. Não alojamos o Microsoft-Decision-1 e ele não está no nosso catálogo — um modelo que devolve probabilidades em vez de texto não é algo para o qual se encaminhem completions de chat, e nada aqui deve ser lido como uma alegação de disponibilidade. O que está por detrás da nossa única chave compatível com OpenAI é o conjunto de mais de 200 modelos que faz a escrita: o modelo que elabora a rubrica, os dois que produzem respostas candidatas, aquele que emite a chamada de ferramenta que o Decision-1 depois pontua antes de ser executada. O preço de tabela do fornecedor é repassado com 0% de margem, por isso um corte de preço do lado do gerador entra em vigor no nosso no mesmo dia, e o failover automático mantém viva a etapa de geração quando um único fornecedor se degrada — o que importa mais num pipeline que pontua tudo o que vê do que num que responde a um utilizador ocasionalmente. Se preferir não escolher um único juiz, a DSL de encaminhamento compõe vários modelos numa única chamada, e a fusão de modelos reporta a concordância entre eles como um campo com pontuação em vez de como texto que tem de ler.

O que mudaria este artigo é uma tabela. Publique os escores de Brier e a ECE, ou deixe uma execução independente entrar em um ranking, e a avaliação acima passa a ser uma confirmação em vez da única evidência existente. Até lá, a descrição precisa do Microsoft-Decision-1 é restrita: os pesos são reais, o contrato está documentado melhor do que a maioria dos lançamentos hospedados consegue, a opção de abstenção é prevista desde o projeto, em vez de ser acrescentada de última hora, e a afirmação de desempenho é uma frase — bem escrita, sem nenhum número atrelado a ela.

Conclusão

A Microsoft-Decision-1 atingiu disponibilidade geral no Microsoft Foundry em 8 de outubro de 2026 como um pontuador de decisão apenas de texto, de 32.768 tokens, construído sobre o Qwen3.5-9B, retornando probabilidades calibradas sobre seus próprios conjuntos de opções com zero tokens de saída e nenhum peso para baixar. Seus pontos fortes são um contrato limpo de passagem única, um caminho de abstenção projetado de origem e autenticação, cobrança e governança do Azure vinculadas; seu ponto fraco é que ninguém fora da Microsoft tem um número publicado sobre quão bem calibrado ele é, inclusive a Microsoft. Trate o lançamento como uma API que está se tornando disponível, não como uma capacidade que está sendo estabelecida, e submeta seus próprios casos rotulados a ele antes que qualquer coisa a jusante dependa de um limiar.