Hugging Face presenta los modelos de decisión, una familia de modelos que no escriben una respuesta, sino que evalúan opciones predefinidas y devuelven una distribución de probabilidades sobre esas opciones. La empresa busca definir una interfaz común para estos modelos, sin imponer una arquitectura única.
Los grandes modelos de lenguaje (LLM), que producen su respuesta token por token, es decir, fragmento de texto por fragmento de texto, son muy eficaces para redactar, programar o razonar. Pero no todos los problemas requieren generar texto. Tomemos un sistema de soporte al cliente que recibe el siguiente mensaje: «Me han cobrado dos veces mi suscripción. Necesito un reembolso hoy». Debe determinar qué equipo debe procesar la solicitud, su grado de urgencia y si el cliente solicita un reembolso.
Se puede pedir a un LLM que devuelva estas respuestas en formato de objeto JSON. Este enfoque ya está extendido para la clasificación y el enrutamiento, pero presenta varias limitaciones. No se garantiza que el modelo respete el esquema solicitado: puede producir un JSON no válido, añadir claves inesperadas o responder fuera de las opciones permitidas. Las bibliotecas de decodificación restringida, como Outlines y XGrammar, reducen este riesgo limitando los tokens permitidos en cada paso, pero añaden trabajo adicional. Finalmente, cuando la aplicación solo debe elegir entre respuestas conocidas, la generación completa de texto puede ser superflua.
Una interfaz basada en probabilidades
Un modelo de decisión recibe un estado, es decir, la información a evaluar, y una lista de preguntas. Devuelve decisiones acompañadas de probabilidades. La fuente distingue tres tipos de preguntas. El tipo choice selecciona una opción entre varias. El tipo score evalúa algo en una escala ordenada. El tipo noul responde a una pregunta sí/no de forma probabilística.
En el ejemplo presentado, el modelo autotrust/GEV-26B-Decide asigna a la pregunta de servicio las siguientes probabilidades: Facturación 0,998, Soporte técnico 0,001 y Ventas 0,001. Para la urgencia, los niveles bajo, medio y alto reciben respectivamente 0,10, 0,26 y 0,72. La puntuación devuelta corresponde a la esperanza de esta distribución, es decir, 1,7, y no a un nivel elegido a medio camino. Para la pregunta «¿El cliente solicita un reembolso?», el modelo devuelve directamente la probabilidad de una respuesta positiva, aquí 0,92.
La noción de confianza, calculada para las preguntas de tipo choice y score, resume la concentración de estas probabilidades. El concepto no es completamente nuevo: la empresa TypeSafe AI había presentado Jev, calificado como modelo «System One». El término «modelo de decisión» fue finalmente adoptado por la comunidad, ya que describe el rol computacional del modelo sin remitirse a una teoría particular de la cognición.
Un ecosistema en construcción
El nuevo formato ya es compatible con varias herramientas. La biblioteca Transformers ofrece un DecisionPipeline, una clase AutoModelForDecision y una clase DecisionConfig, así como un punto de acceso /v1/systemone después del lanzamiento de un servidor local. El motor de inferencia llama.cpp también acepta estos modelos a través de la misma API. La fuente cita el modelo ggml-org/Kev-4B-GGUF, servido en el puerto 9931. El Hub ofrece una etiqueta dedicada, decision-model, ya que estos modelos no comparten necesariamente la misma arquitectura: algunos se basan en codificadores como ModernBERT, otros en modelos generativos más grandes.
Una vez resuelta la inferencia, la fuente aborda el entrenamiento. Un ejemplo de demostración afina el modelo autotrust/JEV-9B para enrutar solicitudes de soporte, utilizando la API Trainer. El soporte de entrenamiento nativo en TRL es objeto de una solicitud de fusión, la PR n°8040, aún abierta en el momento de redactar el artículo. Por otra parte, Unsloth ofrece una receta para transformar un LLM generativo, como Qwen, en un modelo de decisión, gracias a LoRA y a una cabeza de puntuación.
