Por qué tantas llamadas a un LLM son en realidad una clasificación
Buena parte del tráfico de LLM en producción devuelve una sola palabra. Escalar este ticket o no. Spam o no spam. Cuál de seis handlers recibe este evento. Para conseguir esa palabra, mandas el prompt entero a un modelo de propósito general, esperas mientras decodifica una respuesta token a token, y sacas un objeto JSON del resultado. Pagas el precio y la latencia de generar texto, y lo que vuelve es una decisión que cabe en un enum.
“System One model” es el nombre que TypeSafe AI le da a un modelo construido para esa segunda forma: toma un estado más un conjunto de preguntas tipadas y devuelve una respuesta a cada una en un único paso, sin generar texto. El término toma prestada la distinción de Daniel Kahneman entre el pensamiento rápido y automático de “Sistema 1” y el razonamiento lento y deliberado de “Sistema 2”. Jev, la implementación de TypeSafe, es el ejemplo concreto aquí. La etiqueta pertenece al proveedor, pero la idea de fondo es más vieja: si la salida está limitada a un conjunto conocido de respuestas, el modelo puede elegir una en vez de escribirla. La pregunta para tu sistema es si esa forma coincide con un cuello de botella real.
Por qué un modelo System One puede saltarse el decoding token a token
Un LLM generativo produce una salida que no ha visto antes. Cada token depende de todos los anteriores, así que el modelo predice uno, lo añade a la entrada, y predice el siguiente. Esa dependencia es la razón de que generar texto sea lento. El token 40 no puede empezar hasta que existe el token 39.
Un modelo de este tipo elimina la dependencia fijando el espacio de salida antes de la llamada. No le pides que escriba una respuesta. Para cada pregunta le das un menú (elige una de estas etiquetas, ubica esto en una escala del 1 al 10, responde sí o no), y el modelo puntúa cada opción de cada menú en un único paso forward paralelo. No hay ninguna secuencia que decodificar, porque cada respuesta posible ya se conoce de antemano.
Ese es todo el truco, y también es el límite. Fijar la salida es lo que permite saltarse la autorregresión, y todo lo que queda fuera de esa salida fija desaparece: no obtienes texto libre ni un razonamiento escrito que puedas inspeccionar. La propia documentación de Jev dice que el modelo rinde mal en aritmética, conteo y comparación de fechas, que necesitan cómputo en varios pasos en vez de elegir entre opciones. Si la tarea necesita que el modelo produzca algo en vez de seleccionar algo, usa otra herramienta.
Qué le envías a un modelo System One y qué te devuelve
Cada llamada tiene dos partes. El estado es lo que el modelo necesita mirar: un correo, un ticket de soporte, un frame de un juego, una fila de datos de tu aplicación. Las preguntas son tipadas y acotadas, usando los tres tipos de arriba. Para cada pregunta te devuelve la respuesta elegida más una distribución de probabilidad sobre las alternativas.
Construye alrededor de esa distribución. “Escalar” con 0.52 y “escalar” con 0.98 tienen la misma etiqueta y significan cosas muy distintas. La segunda la puedes actuar automáticamente. La primera pertenece a un camino más lento y cuidadoso, ya sea una persona o una llamada completa a un LLM.
Puedes conseguir una señal parecida de un modelo generativo leyendo las log-probabilities de los tokens de una respuesta acotada, si tu proveedor las expone. La diferencia es que un modelo System One devuelve la distribución como la respuesta en sí misma, para cada pregunta, sin plomería extra.
Cuándo usar un modelo System One en un pipeline de LLM
El patrón que funciona es filtrar, no reemplazar. Un modelo tipado rápido decide si hace falta que ocurra siquiera la llamada generativa cara.
- Enrutamiento. Clasifica la petición antes de elegir qué modelo o handler la procesa, en vez de pedirle a un modelo general que clasifique y responda en la misma llamada. Un pipeline de RAG puede usar esta misma puerta para decidir si una pregunta necesita retrieval en primer lugar.
- Moderación y triaje. Puntúa contenido por spam o urgencia antes de que llegue a una persona o a un modelo más caro, así el camino caro solo corre sobre lo que lo necesita.
- Guardrails. Después de generar, comprueba la respuesta contra restricciones tipadas (¿contiene un patrón de datos concreto?, ¿cae en una categoría prohibida?) como un paso barato y separado, en vez de meter la comprobación dentro del prompt de generación.
- Bucles de control en tiempo real. Un game loop o el controlador de un robot que necesita una decisión cada frame no puede esperar a una generación. Un modelo de un único paso cabe dentro de ese bucle. Un modelo token a token, estructuralmente, no.
Las cosas se rompen cuando tratas la respuesta del modelo rápido como verdad absoluta. Manda las respuestas de baja confianza por el camino lento, y fija el umbral a partir de tus propios datos etiquetados, no de un número redondo que sonaba bien. Una distribución plana con una etiqueta encima sigue siendo una suposición.
Alternativas: salida estructurada y clasificadores afinados
Los equipos venían resolviendo este problema antes de que la categoría tuviera nombre, de dos formas principales.
Salida estructurada sobre un LLM de propósito general. Las principales APIs de LLM pueden restringir la generación a un JSON schema o a un enum, lo que te da la misma garantía de respuesta tipada sin adoptar un tipo de modelo nuevo. El decoding sigue siendo autorregresivo, pero cuando la respuesta es un único valor de enum la parte generada son solo unos pocos tokens. La mayor parte de la latencia y el coste va en procesar el prompt, y un modelo System One también tiene que hacer eso. TypeSafe posiciona a Jev como más rápido y más barato que este enfoque. Cuánto de eso se sostiene para tus llamadas depende de la longitud de tu prompt y de cuántas preguntas hagas por llamada, así que es un número para medir, no para asumir. La salida estructurada tampoco necesita infraestructura nueva si ya llamas a ese proveedor.
Un clasificador pequeño afinado. Para una sola decisión estable, como esta escalada concreta o este filtro de spam concreto, un clasificador entrenado con tus propios datos etiquetados suele ser más rápido y más barato que cualquier modelo de propósito general, tipado o no. El coste es que necesitas datos etiquetados y una tanda de reentrenamiento cada vez que la tarea cambia. La ventaja de un modelo System One sobre él es la amplitud: un solo modelo responde muchas preguntas tipadas distintas sobre distintos tipos de estado, sin una tanda de entrenamiento por decisión.
La elección correcta depende de cuántas decisiones distintas tienes y cuánto tráfico reciben. Si tienes una sola decisión estable y de alto volumen, usa un clasificador dedicado. Si tienes varias decisiones relacionadas pero distintas a lo largo de un pipeline, ese es el caso para el que está pensada la forma System One. Si no estás haciendo miles de estas llamadas por minuto, empieza con salida estructurada en el modelo que ya usas.
Cómo encontrar las llamadas a un LLM que en realidad son decisiones
Repasa lo que ya le mandas a un LLM de propósito general y marca cada llamada cuya salida útil entera podría ser un valor de enum o un número. Esos son tus candidatos. Mueve dos de ellos a salida estructurada en un modelo que ya uses, ya sea una API alojada o un modelo local corriendo bajo Ollama, que acepta un JSON schema en su parámetro format. Mide latencia y coste por llamada contra la versión actual.
Sea lo que sea que cambies, sigue mandando un pequeño porcentaje del tráfico filtrado por el camino viejo también y compara las respuestas. Si la salida estructurada ya encaja en tu presupuesto de latencia y coincide con el camino viejo, párate ahí. Evalúa un modelo System One dedicado como Jev solo si no encaja, y usa esa misma muestra en paralelo para juzgarlo.