Unsloth convierte Qwen3.5-4B en un clasificador de 10 intenciones con una sola T4

Un modelo de lenguaje de gran tamaño no siempre tiene que conversar. En muchos productos se espera de él un resultado más práctico: determinar la intención de un cliente, elegir la siguiente herramienta o decidir si un mensaje debe seguir adelante. Un LLM convencional puede generar una explicación aunque el sistema solo necesite una respuesta breve, por ejemplo, «consulta de saldo» con una puntuación de confianza.

Machine Learning Mastery mostró cómo construir un clasificador de este tipo a partir del modelo abierto Qwen3.5-4B. La solución combina Unsloth, LoRA de 4 bits y el conjunto de datos CLINC150. La demostración se ejecuta en Google Colab sobre una Tesla T4 con 14,6 GB de VRAM y limita la tarea a diez intenciones. No se trata de un modelo industrial listo para usar, sino de un punto de partida claro para desarrolladores que quieran sustituir una cadena de prompts por un mecanismo de selección independiente.

El modelo elige en lugar de redactar

Imaginemos el mensaje: «Muéstrame el saldo de mi cuenta de ahorro». Un modelo generativo puede escribir instrucciones, preguntar de qué banco se trata o empezar a razonar. Un clasificador debe hacer algo distinto: seleccionar la intención balance de un conjunto predefinido y devolver una puntuación de confianza.

En Unsloth, FastDecisionModel se encarga de esta tarea. Al modelo de lenguaje base se le añade una cabeza especializada que puntúa las opciones permitidas. En vez de generar tokens de forma secuencial, el sistema compara decisiones fijas. Admite la selección de una opción, respuestas de sí o no y puntuaciones sobre una escala ordenada.

Este formato es adecuado para el enrutamiento de solicitudes, la moderación, la detección de sentimiento y los escenarios con agentes. Por ejemplo, se puede colocar un modelo pequeño delante del LLM principal para decidir adónde enviar una solicitud: al buscador, a la base de conocimiento, al servicio de pagos o a una persona. La salida está limitada por un esquema, por lo que resulta más fácil validarla y transferirla al siguiente componente.

Cómo está organizado el entrenamiento

El autor carga Qwen3.5-4B en modo de 4 bits y conecta adaptadores LoRA de rango 16. La mayor parte de los parámetros originales permanece congelada, mientras que el entrenamiento modifica los adaptadores compactos y la cabeza de toma de decisiones. El checkpointing de gradientes reduce aún más el consumo de memoria.

Los datos también deben reorganizarse. Cada registro contiene tres partes: el texto del usuario, una descripción de las decisiones disponibles y la opción correcta. En el ejemplo con CLINC150 se seleccionan al azar 10 de las 150 intenciones, entre ellas fecha, hora, indicaciones de ruta, sustitución de ingredientes y arranque de un automóvil con una batería externa. Después solo se conservan los ejemplos relacionados con esas intenciones.

La lista de opciones es precisamente lo que permite controlar la tarea: el desarrollador define de antemano qué acciones puede realizar el sistema. Pero esto también tiene un coste. Cuantas más opciones haya, más larga será la entrada y más exigente será la fase de entrenamiento. Diez clases en una T4 todavía no demuestran que la misma configuración pueda gestionar sin cambios las 150 categorías o mensajes reales de clientes.

Dónde termina la demostración

El fragmento disponible no incluye la precisión final, una matriz de confusión ni una comparación con un clasificador convencional. Por tanto, no se puede afirmar que Qwen3.5-4B ya supere a modelos más baratos. Tampoco se muestra la calidad del reconocimiento de solicitudes ajenas al conjunto admitido, aunque CLINC150 contiene ejemplos separados de este tipo de consultas.

Para un entorno de producción, la confianza del modelo por sí sola no basta. Hay que calibrarla con un conjunto de validación reservado, elegir un umbral de rechazo y analizar los errores entre intenciones similares. Si dos acciones solo difieren en un detalle—por ejemplo, «congelar la tarjeta» y «cancelar la tarjeta»—, el coste de una decisión incorrecta puede ser mayor que la latencia añadida por una pregunta aclaratoria.

La conclusión práctica es sencilla: FastDecisionModel resulta interesante como forma de convertir un LLM abierto en un enrutador estrictamente limitado. Conviene comenzar con un conjunto pequeño de acciones fáciles de distinguir, una clase obligatoria de «no lo sé» y un registro de errores. Después se puede comparar la solución con un clasificador BERT compacto, reglas y llamadas a un modelo de mayor tamaño. Lo importante aquí no es la espectacularidad de la arquitectura, sino la proporción de decisiones correctas con una latencia y un coste aceptables.