Hugging Face publicó un artículo en el que describe los modelos de decisión y las herramientas que ha añadido a su alrededor. El objetivo es contar con una interfaz común que cualquier modelo de este tipo pueda implementar, sea cual sea su arquitectura.
Qué hace un modelo de decisión
Un modelo de decisión recibe un estado, que puede ser una cadena de texto o un objeto JSON estructurado. Recibe también una o varias preguntas con nombre, cada una con un conjunto cerrado de respuestas permitidas. Devuelve una decisión tipada junto con probabilidades, y no genera texto por el camino. La respuesta de ejemplo del artículo indica cero tokens de salida.
Hay tres tipos de pregunta:
- Choice elige una opción, por ejemplo qué equipo debe atender un ticket, y devuelve una probabilidad para cada opción.
- Score valora algo en una escala ordenada, como urgencia baja, media o alta, y devuelve el valor esperado del nivel.
- Noul, nombre que viene de Bernoulli, responde una pregunta de sí/no con una única probabilidad, por ejemplo si el cliente está pidiendo un reembolso.
Las respuestas de Choice y Score incluyen además un valor de confianza que indica lo concentradas que están las probabilidades.
El ejemplo que recorre el artículo es un mensaje de soporte sobre un cobro duplicado. Una sola petición puede preguntar a la vez por el departamento, la urgencia y la intención de reembolso. El departamento vuelve como facturación con una probabilidad cercana a uno.
En qué se diferencia de lo que ya se usa
El artículo compara los modelos de decisión con dos enfoques anteriores. Un clasificador convencional tiene las etiquetas fijadas dentro del modelo, de modo que añadir una categoría exige reentrenar. La clasificación zero-shot recibe las etiquetas al hacer la petición, pero atiende un solo tipo de pregunta. Hugging Face aclara que los modelos de decisión no inventaron las etiquetas en tiempo de ejecución ni la salida probabilística. Lo que aportan es una única interfaz que cubre a la vez opciones, puntuaciones ordenadas y preguntas de sí/no.
El texto también enumera los puntos débiles de pedirle un JSON a un LLM. La salida puede no respetar el esquema, la decodificación restringida sigue añadiendo cómputo y generar una respuesta completa supone trabajo extra cuando la aplicación solo necesita elegir una opción.
Qué se ha lanzado
- Transformers incorpora un pipeline de decisión, una clase AutoModelForDecision y una clase DecisionConfig. También puede servir en local un endpoint /v1/systemone.
- llama.cpp sirve modelos de decisión en formato GGUF con la misma API /v1/systemone.
- El Hub cuenta con una etiqueta para modelos de decisión. Los modelos listados usan arquitecturas base distintas, desde codificadores al estilo ModernBERT hasta otros generativos más grandes.
- Entrenamiento: los modelos de decisión se pueden ajustar con la API Trainer. El artículo muestra un ejemplo deliberadamente pequeño que enruta solicitudes de soporte con una pérdida de entropía cruzada sobre las opciones.
El artículo añade que los modelos de lenguaje autorregresivos compatibles también pueden ejecutarse a través de la interfaz de decisión. Transformers construye los prompts, lee los logits de las etiquetas de respuesta y aplica softmax sin generar texto, de modo que la interfaz puede probarse sin entrenar un modelo nuevo.
Salvedades
Hugging Face describe los modelos de decisión como un terreno joven y cambiante, y el artículo no incluye ninguna comparación de rendimiento con el uso de LLM mediante prompts. Los ejemplos usan modelos publicados bajo los nombres autotrust y ggml-org. La precisión con sus propios tickets sigue sin comprobarse hasta que la mida usted mismo.