Microsoft-Decision-1: El modelo de Microsoft que responde con un número en lugar de una oración

Microsoft-Decision-1 tiene una línea en su tarjeta de modelo que ningún otro modelo de Microsoft ha incluido nunca: no diseñado para la generación de texto. El modelo se puso a disposición general en Microsoft Foundry el 8 de octubre de 2026, y es una reducción deliberada del propósito de un modelo de lenguaje. Le das una situación y una pregunta con una lista fija de respuestas —sí/no, un conjunto de opción múltiple, una escala de valoración, una rúbrica— y devuelve una probabilidad calibrada para cada opción. Sin prosa. Sin explicación. Sin campo de justificación. La salida son números JSON y nada más. Está construido sobre el modelo de pesos abiertos Qwen3.5-9B, entrenado posteriormente por Microsoft, y Microsoft dice que volverá a basar el modelo en otras arquitecturas base más adelante, mencionando MAI y otros modelos de socios.

Ese es un producto más extraño de lo que parece a primera vista. La posición competitiva de Microsoft en 2026 se apoya en modelos de chat de vanguardia y en Copilot, y Microsoft-Decision-1 es lo opuesto a ambos: un evaluador de tamaño medio y propósito único cuya única tarea es decirle a una aplicación cuál de tus propias opciones es más probable que sea correcta, y con cuánta confianza. La pregunta interesante no es si es bueno escribiendo —es explícitamente malo en eso y no lo intenta—, sino si una distribución de probabilidad sobre opciones es una primitiva más útil para las cargas de trabajo que las empresas ejecutan realmente que otro modelo de propósito general con un modo JSON.

Qué hace, exactamente

El contrato es una llamada de entrada y una distribución de salida. Microsoft enumera los formatos de preguntas compatibles como sí/no, opción múltiple, calificación, clasificación y basados en rúbricas. Cada opción recibe una puntuación. El modelo se ejecuta en una única invocación sobre entradas de hasta 32K tokens —32.768 es la ventana de contexto indicada— y el límite práctico es la entrada más el conjunto de opciones, no un presupuesto de generación, porque no hay generación.

Los casos de uso publicados son los que un equipo de plataforma reconocería de inmediato:

• Evaluación de resultados de IA — califica una respuesta generada con base en una rúbrica proporcionada, o decide si está fundamentada en la evidencia que se le dio.

• Clasificación y enrutamiento — clasificar una solicitud, evaluar la relevancia, priorizar una cola, elegir una rama del flujo de trabajo.

• Barreras de seguridad del agente — evalúa una llamada a herramienta o acción del agente propuesta antes de que la aplicación integradora permita que se ejecute.

• Filtrado de seguridad de contenido — marca el contenido según los umbrales que define la aplicación, en lugar de una política fija del proveedor.

• Búsqueda y relevancia del documento — juzgar si un documento recuperado responde a una pregunta proporcionada.

• Automatización basada en la confianza — acepta automáticamente los resultados de alta confianza y escala el resto a una persona.

La opción de abstenerse es el detalle que vale la pena notar. Microsoft admite explícitamente opciones como «no se puede determinar» cuando la evidencia proporcionada es insuficiente, que es la diferencia entre un evaluador calibrado y uno que solo se muestra seguro. Y como las puntuaciones vuelven como números, el umbral de escalado es una decisión tuya: tú estableces dónde 0.7 envía algo a una persona y 0.95 no.

Lo que no hará

Microsoft es inusualmente explícita sobre las exclusiones, y estas importan más que la lista de características para cualquiera que esté dimensionando esto para un pipeline real. Microsoft-Decision-1 no está diseñado para la generación de texto, la respuesta a preguntas abiertas, la conversación, la traducción o el resumen. No está pensado para tareas sin una pregunta cerrada y un conjunto definido de opciones de respuesta, ni para tareas que requieran conocimientos ausentes en la entrada. Es solo texto: no admite imágenes, audio ni video de entrada, ni los produce de salida. No proporciona explicaciones ni justificaciones.

Lee esos elementos en conjunto y aparece un límite en el que es fácil tropezar. Esto no es un chatbot al que puedas pedirle que también clasifique cosas, ni es un resumidor al que puedas añadirle una puntuación. Es una función de puntuación con un presupuesto de tokens. El propio planteamiento del equipo —que no debería ser el único responsable de tomar decisiones automatizadas en decisiones trascendentales sobre personas, y que no debería ser la única base para decisiones relacionadas con crédito, empleo, vivienda, seguros, educación, atención sanitaria, derechos legales «u otros ámbitos igualmente trascendentales»— apunta en la misma dirección. Está diseñado para situarse junto a una decisión, no para ser esa decisión.

La situación del benchmark es la historia que nadie quiere publicar.

No hay cifras. La página del catálogo de Microsoft Foundry para Microsoft-Decision-1 tiene una pestaña Benchmarks, y está vacía de cifras. Lo que contiene en su lugar es un párrafo de metodología y una afirmación cualitativa: el modelo fue "evaluado con benchmarks de decisión públicos y de la comunidad, y con conjuntos de prueba internos reservados que no se usaron en el entrenamiento"; Microsoft informa de que "rinde a la par de los modelos de decisión líderes y por delante de otros modelos de decisión abiertos evaluados con la misma metodología", y que las métricas utilizadas fueron la precisión, el error de calibración, la exhaustividad de seguridad, las tasas de falsos positivos y la consistencia de equidad, variando el orden de las opciones y aplicando pruebas estadísticas pareadas.

Eso es una descripción metodológica seria adjunta a cero resultados publicados. Significa que toda afirmación sobre el rendimiento de Microsoft-Decision-1 hoy es reportada por el proveedor y no ha sido reproducida, y la postura honesta para cualquiera que lo evalúe es que la calibración —la única propiedad que hace que una probabilidad sea útil en absoluto— no está verificada fuera de Microsoft. La empresa sí indica dónde cree que el modelo es más fuerte y más débil, lo cual es más útil que una puntuación de titular: más fuerte en razonamiento, aplicación de reglas y robustez al formato de los prompts; competitivo en clasificación, recuperación, equidad, uso de herramientas y la mayoría de las tareas multilingües; más débil en tareas especializadas de conocimiento de dominio.

Vale la pena leer las limitaciones autoinformadas antes de la lista de características. Las puntuaciones pueden cambiar según la formulación y el orden de las opciones, y una pregunta mal planteada sigue devolviendo una puntuación. La calibración es más sólida en tipos de tareas familiares. Puede basarse en conocimientos desactualizados y no ofrece explicaciones. En cuanto a la cobertura multilingüe: se enumeran 25 idiomas admitidos, entre ellos japonés, coreano, árabe, vietnamita, tailandés, turco, hindi, bengalí, suajili, hebreo, persa y ucraniano, pero Microsoft afirma que la cobertura, la calidad y la calibración "pueden variar según el idioma", y enumera los idiomas distintos del inglés —especialmente los de menores recursos— como un área de bajo rendimiento. El Qwen3.5-9B subyacente admite más de 200 idiomas; el modelo post-entrenado admite una cuarta parte de eso.

Cómo conseguirlo y cuánto cuesta

Microsoft-Decision-1 se distribuye como una API hospedada en Microsoft Foundry dentro del portafolio "Direct from Azure". Los pesos del modelo no se distribuyen: no se trata de un lanzamiento de pesos abiertos y no existe un repositorio de Hugging Face para descargarlo. Cualquier aplicación que pueda emitir solicitudes HTTPS puede integrarse mediante los puntos de conexión de Foundry y la autenticación estándar de Azure. El listado de implementación muestra opciones sin servidor y de punto de conexión unificado con rendimiento aprovisionado de pago por uso o reservado, SKU estándar, con la inferencia por lotes deshabilitada, y la divulgación sobre el entrenamiento informa que el conjunto de datos de entrenamiento se utilizó por primera vez en septiembre de 2026 y que la recopilación sigue en curso.

El precio no se publica en la página del modelo. El campo de precios del catálogo enlaza a la página de precios del modelo de Microsoft en lugar de mostrar una tarifa de entrada y salida, por lo que el costo por token de una llamada a Decision-1 es algo que hay que consultar en la superficie de precios de Azure o leer en una factura. Eso es una laguna real para cualquiera que intente modelar el costo por decisión a escala, y vale la pena decirlo con claridad en lugar de estimarlo. Dos cosas conviene saber cuando se le pone precio: el 0% del costo corresponde a tokens de salida, porque no hay ninguno, y la inferencia por lotes está desactivada, así que no se puede amortizar una ejecución de puntuación masiva a través del canal por lotes como se haría con un modelo generativo.

Donde encaja OrcaRouter en todo esto es en el otro lado de la llamada. No alojamos Microsoft-Decision-1, y no está en nuestro catálogo: un modelo que devuelve probabilidades en lugar de texto no es un modelo al que se dirijan las finalizaciones de chat. Lo que sí ofrecemos es la mitad del patrón que sí genera: los modelos que escriben la rúbrica, redactan las respuestas candidatas o producen la llamada a herramientas que Decision-1 luego puntúa. Esos viven detrás de una única clave compatible con OpenAI con más de 200 modelos, a precio de lista del proveedor transferido con 0 % de margen, así que una rebaja de precio de un proveedor en un modelo juez está activa de nuestro lado el mismo día. Si estás construyendo un bucle de evaluación en el que un modelo escribe y otro puntúa, la llamada de puntuación va a Microsoft y la llamada de generación puede ir a cualquier parte, incluso a través del DSL de enrutamiento, que compone varios modelos en una sola llamada cuando quieres un panel en lugar de un único juez.

Por qué un puntuador es una apuesta distinta a un chatbot mejor

El patrón que Microsoft está vendiendo aquí ya existe en abierto. Intern-Decision-4B de InternLM, d1-3B de Liquid AI, Laya de Convai Innovations y la familia Kev de Jared Palmer todos devuelven distribuciones calibradas sobre opciones proporcionadas sin generar texto, y la mayoría de ellos son pesos Apache-2.0 que puedes ejecutar en tu propio hardware gratis. La entrada de Microsoft se diferencia en tres aspectos que no dependen de benchmarks: es una API gestionada con autenticación, facturación y gobernanza de Azure integradas, por lo que encaja en una ruta de adquisición empresarial que una descarga de Hugging Face no; su base es un modelo de 9B, más grande que la mayoría de ese campo; y viene con una evaluación de IA Responsable y una metodología de evaluación documentada, que a menudo es el requisito real de aprobación para un despliegue regulado.

Lo que no trae es un número. Frente a competidores abiertos que publican puntuaciones de Brier y error de calibración esperado —las dos cifras que te dicen si un 0,8 significa 0,8—, Microsoft ha publicado una metodología y ningún resultado. Hasta que existan pruebas independientes de calibración, la forma defendible de usar Microsoft-Decision-1 es la que recomienda su propia documentación: validar con datos representativos de tu caso de uso, fijar los umbrales a partir del coste de tus errores, incluir siempre una opción de abstención, aleatorizar el orden de las opciones cuando el orden pueda sesgar la respuesta y mantener a una persona en el circuito para cualquier cosa de consecuencias importantes. Ese es un buen consejo para cualquier sistema de puntuación. Es un consejo especialmente bueno para uno cuya calibración nadie fuera de la empresa ha medido.