En Hombres de Negro II, el agente J visita a K en una oficina de correos aparentemente común. Abre una máquina clasificadora de correo y revela que adentro hay un alienígena ordenando las cartas a toda velocidad.
Es una escena ridícula, pero también nos da una forma útil de pensar sobre la IA.
Entre recibir algo y hacer algo con eso, suele haber una decisión más pequeña que tomar: ¿dónde corresponde esto?
Si aciertas esa decisión desde el principio, el resto del sistema puede seguir el camino adecuado.
He estado pensando en ese pequeño alienígena mientras desarrollo software de IA.
Una aplicación recibe una pregunta de facturación, un reporte de error, una foto de producto y una solicitud para agendar una demo. Cada una requiere un manejo distinto. Sin embargo, podemos terminar pidiéndole al mismo modelo de lenguaje grande que revise todo y decida qué sigue. Nada eficiente ni rentable.
Por eso creo que los modelos especializados van a tener un papel mucho más importante en el futuro de la IA. Por ejemplo: Jev está diseñado para decisiones estructuradas sobre las que el software pueda actuar. Coinbase adaptó Qwen3.5-9B específicamente para detectar fraudes en su servicio Onramp. Cada uno se enfoca en un trabajo definido, con resultados que se pueden medir.
https://x.com/brian_armstrong/status/2109412046244913643
Estoy construyendo la capa de clasificación
Las solicitudes conocidas pueden ir directo a un flujo de trabajo definido. Las que necesitan más razonamiento pasan a otro modelo. Las ambiguas se marcan para aclararlas o revisarlas.
El ahorro potencial viene de darle a cada solicitud solo la cantidad de procesamiento que necesita. Después tenemos que medir si el clasificador acierta suficientes decisiones como para justificar su existencia.
Nuestro punto de partida fue CludeMem. Intentábamos decidir qué debía recordar una IA, qué debía recuperar y qué estaba consumiendo tokens innecesariamente. Una preferencia permanente, una instrucción temporal y una pregunta sin resolver merecen tratos distintos. Antes de tomar esas decisiones, necesitábamos clasificar la información.
De ahí nació la idea de una capa de clasificación más amplia. Ese mismo paso podría ayudar a ordenar una solicitud de soporte, enrutar un documento o elegir qué especialista debe encargarse de una tarea.
GIF
A medida que surjan más modelos especializados, las aplicaciones tendrán que decidir qué entradas merecen su atención. Esa es la parte que estamos construyendo: clasificar lo que llega, manejar los casos conocidos de forma local y pasar los más difíciles al modelo o proceso de revisión adecuado.
Presentamos Clude Cat (Cat por categorización 😉)
Antes de guardar un recuerdo, recuperar un documento, llamar a una herramienta o generar una respuesta, casi siempre hay una decisión sobre qué tipo de información estamos manejando.
Esas decisiones están en todas partes.
Imagina que alguien le escribe a una empresa de software:
“¿Dónde puedo descargar mi factura?”
Un agente de IA podría leer el mensaje, revisar sus herramientas, considerar la intención del cliente y decidir buscar una factura.
Un flujo de trabajo más directo se vería así:
Mensaje → solicitud de documento de facturación → verificación de cuenta → recuperación de factura.
Un modelo de lenguaje igual podría redactar la respuesta. La decisión inicial de enrutamiento podría manejarse de forma local.
Ahora cambiemos el mensaje:
“Me cobraron dos veces, mi cuenta está bloqueada y quiero cancelar”.
Mandar eso con total confianza a un único flujo de facturación solo generaría más trabajo. Hay varios problemas por resolver, y la respuesta correcta podría requerir aclaraciones o intervención humana.
El clasificador necesita permiso para decir: “No puedo ubicar esto de forma confiable”.
Esa es una parte esencial del producto. Un sistema que envía solicitudes al destino equivocado con total seguridad puede borrar su ventaja de velocidad por todo el trabajo necesario para corregir sus errores.
Para el cliente, el beneficio esperado es menos espera y menos repeticiones.
Para el desarrollador, es una decisión explícita que puede inspeccionar, probar y cambiar. Puede ver la categoría seleccionada, la versión del modelo, el tiempo de procesamiento y si el sistema decidió no tomar una decisión.
Por debajo, la implementación de texto empieza con un modelo preentrenado pequeño llamado encoder.
Convierte un mensaje en una lista de números que representan aspectos de su significado. Los desarrolladores llaman embedding a esa representación.
“¿Dónde está mi factura?” y “Necesito una copia de mi recibo” usan palabras distintas. Sus representaciones numéricas aún pueden ser lo bastante similares para que el sistema reconozca el mismo tipo de solicitud.
Una capa de clasificación usa esas representaciones para puntuar las categorías que definió el desarrollador.
Implementamos dos enfoques. Uno compara el mensaje entrante con ejemplos de cada categoría. El otro aprende los límites entre categorías a partir de ejemplos etiquetados.
En el enfoque ajustado (fitted), mantenemos el encoder fijo y entrenamos una capa de decisión más pequeña encima. No necesitamos entrenar un nuevo modelo base para cada aplicación.
El desarrollador igual tiene que definir qué significan las categorías y conectarlas con acciones útiles. El clasificador no puede inventar los departamentos de la empresa, la política de reembolsos ni los permisos de las cuentas.
También necesita una política de aceptación.
La categoría con mayor puntuación podría seguir siendo una mala coincidencia. Dos categorías podrían estar casi empatadas. Una solicitud desconocida podría parecerse a algo familiar.
Nuestras puntuaciones locales actuales no son probabilidades calibradas. Un puntaje de 0.92 no significa automáticamente “92 % de probabilidad de estar correcto”.
Tenemos que probar qué pasa cuando esas puntuaciones controlan las decisiones.
Por eso, la salida distingue entre una categoría aceptada, una solicitud que necesita revisión y un fallo técnico. Los tiempos de espera, las cancelaciones y los errores del modelo también requieren un manejo predecible.
Esa es la ingeniería detrás del clasificador. Determina si otra aplicación puede usar el resultado de forma segura y consistente.
Hicimos un experimento con 770 solicitudes bancarias para ver si este enfoque podía reducir el trabajo del modelo generativo.
La primera configuración enviaba cada solicitud a un modelo Qwen2.5 7B corriendo localmente para clasificarla.
La segunda usaba primero nuestro clasificador local y enviaba a Qwen solo las solicitudes no resueltas.
Los resultados fueron:
- Las llamadas a Qwen bajaron de 770 a 227.
- Las clasificaciones correctas subieron de 535 a 642.
- La precisión en todas las entradas pasó de 69.5 % a 83.4 %.
- La suma de los tiempos de consulta medidos bajó de 299.7 segundos a 87.7 segundos.
La etapa local evitó 543 llamadas a Qwen, una reducción del 70.5 %.
El caché se mantuvo activado, y el enfoque directo se ejecutó antes del combinado. Las cifras de tiempo excluyen la configuración y los calentamientos. Medimos la clasificación, sin generar respuestas finales para el cliente ni pagarle a un proveedor de modelos.
Esos números describen esta configuración. No establecen una ventaja sobre todos los LLM ni prueban ahorros para el cliente.
Un experimento posterior y separado probó un clasificador local ajustado con 24 intenciones de viajes y entorno laboral.
De 720 solicitudes, aceptó 688 de forma local. De esas, 681 fueron correctas y siete incorrectas. Dejó 32 para revisión.
Eso nos da dos mediciones distintas:
- Cobertura: manejó el 95.6 % de las solicitudes de forma local.
- Precisión de aceptación: acertó en el 99.0 % de las decisiones que aceptó.
Ambas deben estar en el resultado. Un clasificador podría lograr una precisión impresionante aceptando solo un puñado de solicitudes fáciles.
También probamos 100,000 entradas desconocidas que deberían quedar fuera de sus categorías soportadas. Fue preciso más del 94 % de las veces.
Reconocer lo que el sistema no sabe sigue siendo parte del trabajo.
La velocidad requiere el mismo cuidado. En una prueba separada con CPU caliente, el clasificador bancario completo tardó aproximadamente 1.8 milisegundos por solicitud en la mediana, usando un M4 Max. Eso incluyó tokenización, embedding y puntuación.
Excluyó la descarga del modelo y su arranque. Es una medición de clasificación, no el tiempo necesario para resolver la solicitud completa del usuario. Tampoco garantiza el mismo rendimiento en un teléfono o una laptop común.
Jev entra en esta conversación porque ya aborda una clase similar de decisiones.
TypeSafe documenta a Jev como un modelo para juicios acotados, incluyendo elegir entre opciones dadas y enrutar solicitudes hacia código normal, modelos especializados o humanos. \Documentación de enrutamiento de intenciones de Jev\
El rol que le veo a Jev es ser una vía de escalamiento opcional para las solicitudes que el clasificador local no puede resolver de forma confiable.
La arquitectura hacia la que trabajamos es sencilla:
Solicitud entrante → clasificación local → las solicitudes conocidas toman un camino definido; las inciertas pasan a Jev, a otro modelo o a revisión humana.
Sin Jev, la misma etapa de clasificación local puede devolver las solicitudes no resueltas al LLM existente de la aplicación, al paso de aclaración o al proceso de revisión.
El desarrollador controla las categorías, los umbrales de aceptación y el plan de respaldo. Puede introducir el clasificador local en un flujo de trabajo existente y medir qué decisiones puede asumir.
Hoy, la integración con Jev opera en modo sombra, comparando decisiones en cinco temas amplios sin cambiar el comportamiento de la aplicación. El siguiente paso es probar si el escalamiento selectivo mejora el flujo de trabajo completo. Los resultados de Qwen de arriba no son un benchmark de Jev.
Eso es lo que necesitamos medir: menos llamadas innecesarias a modelos, manejo más rápido de las solicitudes conocidas y un camino explícito para los casos que requieren más atención.
Empezamos a extender el mismo enfoque a las imágenes.
Imagina un negocio que recibe un recibo, una captura de pantalla de un error y una fotografía de producto. Cada una necesita un camino de procesamiento distinto.
Un recibo podría ir a extracción de recibos. Una captura de pantalla podría entrar a un flujo de soporte. Una foto de producto podría entrar a un flujo de catálogo. Una imagen dudosa podría ir a revisión.
El clasificador elige el destino. Leer el total de la compra, diagnosticar el error e identificar los detalles del producto siguen siendo tareas separadas.
Nuestra implementación experimental de imágenes usa un encoder CLIP preentrenado para producir una representación numérica de la imagen.
Un candidato de investigación ajustado clasificó correctamente 19 de 20 fotografías de productos alimenticios en una pequeña prueba de diagnóstico. También envió a revisión las 30 imágenes de hojas de frijol.
El error fue que el panel nutricional y el código de barras de una botella se clasificaron como un recibo.
Ya ves el problema. Ambos pueden contener texto denso, números y diseños rectangulares. Necesitamos ejemplos que le enseñen al sistema el límite que realmente le importa a nuestra aplicación.
Esa muestra es demasiado estrecha para afirmar algo de producción. Las etiquetas venían del dataset en lugar de ser evaluadas de forma independiente, y no había ejemplos nuevos de recibos ni capturas de pantalla en la prueba. La demo pública usa una línea base separada, así que el resultado del candidato ajustado no debe atribuírsele.
El procesamiento de imágenes también fue más pesado que la clasificación de texto. El procesamiento mediano en caliente tomó aproximadamente 36 milisegundos en Node y 197 milisegundos en Chromium con el M4 Max. El navegador primero necesita unos 85 MiB de recursos del modelo, más su entorno de ejecución.
La ejecución local también tiene costos. El tamaño de descarga, la memoria, el tiempo de arranque y el rendimiento del dispositivo deben incluirse en la evaluación.
El producto que tengo en mente encaja en una aplicación existente, donde decide qué sucede después.
Un desarrollador define categorías, proporciona ejemplos representativos, conecta los destinos y elige qué debe pasar cuando la clasificación es incierta.
El primer despliegue debería observar el flujo de trabajo actual sin cambiar su resultado. Luego podemos comparar las decisiones propuestas con los resultados verificados antes de permitir que el clasificador controle el enrutamiento.
Necesitamos inspeccionar los errores aceptados con tanto cuidado como las solicitudes rechazadas. De lo contrario, una decisión equivocada pero tomada con confianza puede desaparecer detrás de una puntuación tranquilizadora.
El entrenamiento, la calibración y las pruebas también necesitan datos separados. El entrenamiento enseña las categorías. La calibración elige las reglas de aceptación. Una prueba protegida verifica el resultado congelado.
Cuando un error de prueba influye en el siguiente modelo, ese ejemplo se convierte en datos de desarrollo. La próxima evaluación necesita una prueba nueva.
El pequeño alienígena en la clasificadora de correo le da a la gente una forma de imaginar el trabajo. Construir una versión útil implica descubrir exactamente qué entradas puede manejar, cuándo debe pedir ayuda y cuánto cuestan sus errores.
El siguiente paso es un flujo de trabajo representativo con etiquetas independientes y un registro de cada resultado. Necesitamos medir cuántas solicitudes toman la ruta local, cuántas llegan a otro modelo, cuántas salen mal y si la aplicación completa se vuelve más rápida o más barata después de considerar esos errores.
Es hora de escalar y ponerle esteroides a este modelo local.
