¿Cuánto contexto necesita un modelo para decidir?

Esta semana estuve probando JEV y terminé con una pregunta que no se resuelve agregando más campos a una solicitud: ¿cuánta información necesita un modelo generalista para tomar una decisión específica?

La pregunta siguiente es igual de importante: si consigo darle suficiente contexto, ¿qué utilidad tiene frente a entrenar un clasificador propio? La respuesta cambia mucho cuando todavía no hay un conjunto de casos etiquetados ni infraestructura para mantener ese clasificador.

Qué es JEV

JEV es el modelo de TypeSafe para decisiones estructuradas. La empresa lo presenta como un System One Model: recibe un estado y preguntas sobre ese estado, y devuelve respuestas con tipos definidos. Puede elegir entre opciones, asignar una puntuación o producir un valor acotado, según la pregunta. No estoy usando "modelo de decisiones" como una categoría técnica universal; me sirve para describir el trabajo que le pido.

Un gran modelo de lenguaje (LLM) genera texto token por token. Puede ayudar a razonar sobre un caso y también se le puede pedir que entregue una clasificación en un formato fijo. JEV parte de otra interfaz: las opciones y criterios de decisión están definidos antes de llamarlo, y preguntas independientes sobre el mismo estado pueden resolverse en paralelo. Esa diferencia importa cuando el resultado alimentará un flujo de trabajo: una etiqueta o una puntuación se puede usar directamente, mientras una explicación en prosa exige decidir qué parte constituye la respuesta.

Eso no demuestra que JEV sea más acertado que un LLM ni que un formato estructurado capture todo lo importante. La comparación interesante es qué información necesitan ambos para acertar, cuánto cuesta obtener la respuesta y cómo se comportan ante casos ambiguos. Una respuesta limpia puede ocultar una mala decisión; una respuesta extensa puede sonar convincente sin resolver la tarea.

Un ejemplo fuera de mi experimento

Pensemos en un caso hipotético de soporte: llega el mensaje "No puedo entrar". Le pedimos a JEV que decida si es urgente y a qué equipo debería enviarse. El mensaje por sí solo no dice si falló una cuenta, si el servicio está caído para todos o si hay una fecha límite. Tampoco explica cómo se define "urgente" en esa operación.

Podría agregar el alcance del incidente, el momento en que empezó, señales del sistema y las reglas para escalarlo. Algunas de esas piezas probablemente cambiarían la decisión por buenas razones. Otras serían ruido. Una nota que afirmara "esto es crítico" sin evidencia, por ejemplo, podría inclinar la respuesta sin aportar un hecho nuevo.

En JEV, parte de la información vive en el estado y parte en la pregunta y sus criterios. Varias preguntas independientes pueden evaluar un mismo estado en una sola solicitud. La siguiente animación compara una salida JSON generada token por token con cuatro preguntas independientes: urgencia, equipo, alcance y evidencia suficiente para iniciar el diagnóstico. Puedes alternar entre el mensaje aislado y un estado con alcance y señales técnicas, manteniendo los criterios fijos. Los resultados y probabilidades son inventados para explicar la interfaz: no son respuestas obtenidas de modelos y las barras no miden tiempos ni precisión.

{
  "urgency": "high",
  "team": "engineering",
  "scope": "service",
  "evidence": "sufficient"
}

La interfaz permite obtener respuestas estructuradas. Todavía hay que comprobar si la información disponible permite responder bien. Si dos preguntas dependen entre sí —por ejemplo, elegir un equipo solo después de confirmar que existe una incidencia general—, habría que expresar esa dependencia en el flujo de trabajo. El paralelismo no la resuelve por sí mismo.

Encontrar el contexto que sí importa

No buscaría el mayor estado posible, sino un contexto suficiente: información que cambie la respuesta de una forma explicable y datos cuya ausencia obligue a abstenerse o enviar el caso a revisión. "Más contexto" no es sinónimo de "mejor decisión" cuando se mezclan hechos, supuestos y conclusiones ajenas.

Para averiguar qué ayuda, tomaría una colección fija de casos con una referencia independiente. Haría variantes controladas: primero solo el mensaje, después el alcance, luego señales técnicas y, finalmente, los criterios de escalamiento. Registraría tanto las respuestas corregidas como las que empeoran. También retiraría campos para ver si algo aparentemente esencial en realidad no influye o si el modelo se apoyó en un dato irrelevante.

También distinguiría el estado del caso de los criterios de la pregunta. El primero debería contener observaciones verificables: a cuántas personas afecta, desde cuándo ocurre, qué servicios fallan. Los segundos dicen qué significa "urgente" y qué opciones de enrutamiento existen. Si cambio ambos a la vez y mejora el resultado, no sabré cuál fue la causa. Y si las reglas cambian entre casos, acabaré midiendo mi manera de redactarlas en vez de la capacidad del modelo.

Hay un límite práctico. Para algunos casos, ni la descripción ni las señales disponibles permiten una decisión responsable. En ese punto, el diseño debe ofrecer "información insuficiente" o una ruta de revisión, y evaluar cuántos casos deja pendientes. Obligar a elegir una clase siempre puede elevar la tasa aparente de respuestas completas mientras reduce la utilidad real.

Ese ejercicio separa dos preguntas que suelen confundirse: si el modelo entiende la tarea como pretendíamos y si sus respuestas coinciden con decisiones que podemos defender. Una salida plausible o una confianza alta no responde la segunda por sí sola.

La ventaja aparece antes de tener un dataset

Un clasificador especializado sería una alternativa interesante si ya tuviera suficientes ejemplos etiquetados, una definición estable de las clases y la capacidad de entrenarlo, evaluarlo y mantenerlo. Podría ajustar el modelo al dominio y medir su desempeño sobre casos que no vio durante el entrenamiento.

Pero muchas veces lo que falta son precisamente esas etiquetas y esa infraestructura. JEV permite ensayar una decisión sin entrenar un modelo distinto para cada pregunta. Puede ayudar a descubrir qué criterios están mal definidos, qué información falta y cuáles casos deberían pasar por revisión humana. En tareas nuevas o de bajo volumen, eso puede valer más que comenzar por un pipeline de entrenamiento.

La alternativa tampoco tiene por qué ser permanente. Podría empezar con JEV para explorar la tarea, guardar decisiones y correcciones con cuidado, y volver a evaluar un clasificador específico cuando existan suficientes casos representativos. Esos registros no se convierten automáticamente en etiquetas fiables: requieren criterios compartidos, revisión de desacuerdos y una muestra de prueba que no se use para ajustar el sistema.

Tampoco convierte la falta de evidencia en conocimiento. Un modelo generalista puede fallar ante reglas particulares o información que nunca recibió. Un clasificador propio también fallaría con etiquetas inconsistentes o entradas incompletas. La elección no depende solo del nombre del modelo, sino del problema, los datos disponibles y el costo de equivocarse.

Cómo sabría si funciona

Compararía una regla sencilla como línea base, JEV con una definición estable del estado y las preguntas, y un clasificador propio si llego a reunir datos suficientes. Usaría los mismos casos de prueba, separados antes de ajustar cualquiera de las opciones.

Miraría errores por clase, falsos positivos y negativos según sus consecuencias, estabilidad frente a cambios irrelevantes, desempeño con información incompleta, tiempo de respuesta y costo total. Si uso la confianza de JEV para decidir qué casos revisar, tendría que comprobar con ejemplos etiquetados si ese umbral identifica de verdad los errores.

La paradoja de Jevons como pregunta

TypeSafe explica que llamó JEV al modelo por William Stanley Jevons. En The Coal Question, Jevons observó que usar el carbón con mayor eficiencia podía ampliar sus usos y aumentar su consumo total. Esa es la intuición detrás de la llamada paradoja de Jevons: cuando una actividad se abarata, la demanda adicional puede compensar el ahorro por unidad. No es una ley que se cumpla siempre ni estoy afirmando que ya haya ocurrido con JEV.

La conexión con los modelos de decisiones me parece útil. Si el costo y el tiempo por decisión bajan lo suficiente, podríamos dejar de automatizar solo las tareas de mayor volumen y empezar a consultar un modelo en cada paso pequeño: priorizar un ticket, decidir si pedir un dato, elegir un siguiente responsable. Una decisión más barata podría significar muchas más decisiones. El ahorro por consulta y el costo total del sistema contarían historias distintas.

Eso plantea otra evaluación, además de la precisión: ¿cuántas consultas nuevas aparecen cuando eliminamos la fricción?, ¿cuántas terminan en una acción útil?, ¿cuánto trabajo de revisión generan?, ¿qué recursos consume el flujo completo? La paradoja sirve para hacer esas preguntas. Las respuestas necesitan datos del uso real, no una analogía económica.

La pregunta correcta

Me recuerda a una escena de la película Yo, robot: el detective Spooner interroga la proyección del doctor Lanning, que le advierte que sus respuestas son limitadas y debe hacer las preguntas correctas. Cuando por fin formula una que abre una pista, escucha: "Esa, detective, es la pregunta correcta".

En mi caso, la pregunta correcta todavía no es "¿qué respondió JEV?". Es "¿qué evidencia necesito para saber que respondió bien y cuándo vale la pena entrenar algo específico?"