En Hombres de Negro II, el agente J visita a K en una oficina de correos aparentemente normal. Abre una máquina clasificadora de correo y descubre a un alienígena dentro, ordenando las cartas a toda velocidad.
Es una escena ridícula, pero también nos da una forma muy útil de pensar en la IA.
Entre recibir algo y hacer algo con ello, 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 sobre facturación, un reporte de error, la foto de un producto y una solicitud para agendar una demo. Cada uno requiere un manejo distinto. Sin embargo, terminamos pidiéndole al mismo modelo de lenguaje grande que inspeccione todo y decida qué hacer después. No es 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 la detección de fraudes en su servicio Onramp. Cada uno se enfoca en una tarea definida, 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 exactamente la cantidad de procesamiento que necesita. Después tenemos que medir si el clasificador acierta lo suficiente 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 servir para 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 localmente 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 que decidir con qué tipo de información estamos tratando.
Esas decisiones están por 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 sería así:
Mensaje → solicitud de documento de facturación → verificación de cuenta → recuperación de factura.
Un modelo de lenguaje aún 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”.
Enviar eso con total confianza a un único flujo de facturación solo generaría más trabajo. Hay varios problemas que 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 fiable”.
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 que cuesta 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 modificar. 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 pequeño modelo preentrenado llamado encoder (codificador).
Convierte un mensaje en una lista de números que representan aspectos de su significado. Los desarrolladores llaman a esa representación embedding.
“¿Dónde está mi factura?” y “Necesito una copia de mi recibo” usan palabras distintas. Pero sus representaciones numéricas pueden ser lo bastante parecidas para que el sistema reconozca que son el mismo tipo de solicitud.
Una capa de clasificación usa esas representaciones para puntuar las categorías que el desarrollador ha definido.
Hemos implementado 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 sigue teniendo que definir qué significan las categorías y conectarlas con acciones útiles. El clasificador no puede inventarse 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 puede seguir siendo una mala coincidencia. Dos categorías pueden estar casi empatadas. Una solicitud desconocida puede parecerse a algo familiar.
Nuestras puntuaciones locales actuales no son probabilidades calibradas. Una puntuación de 0.92 no significa automáticamente “92 % de probabilidad de ser correcta”.
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 alrededor 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 de los modelos generativos.
La primera configuración enviaba todas las solicitudes a un modelo Qwen2.5 7B corriendo localmente para su clasificación.
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 aumentaron de 535 a 642.
- La precisión general subió del 69.5 % al 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 que el 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 demuestran ahorros reales para el cliente.
Más adelante, un experimento independiente 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 métricas distintas:
- Cobertura: manejó el 95.6 % de las solicitudes localmente.
- Precisión de aceptación: acertó en el 99.0 % de las decisiones que aceptó.
Ambas deben ir juntas 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. Acertó más del 94 % de las veces.
Reconocer lo que el sistema no sabe sigue siendo parte del trabajo.
La velocidad exige 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 incluía tokenización, embedding y puntuación.
Excluía la descarga y el arranque del modelo. 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 en una laptop común.
Jev encaja en esta conversación porque ya aborda una clase similar de decisiones.
TypeSafe documenta Jev como un modelo para juicios acotados, que incluye elegir entre opciones dadas y enrutar solicitudes hacia código normal, modelos especializados o humanos. \Documentación de enrutamiento por intención 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 con fiabilidad.
La arquitectura hacia la que trabajamos es sencilla:
Solicitud entrante → clasificación local → las solicitudes conocidas siguen un camino definido; las inciertas pasan a Jev, a otro modelo o a revisión humana.
Sin Jev, esa 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 mencionados 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.
Hemos empezado a extender el mismo enfoque a las imágenes.
Imagina un negocio que recibe un ticket de compra, la captura de pantalla de un error y la fotografía de un producto. Cada uno necesita un camino de procesamiento distinto.
El ticket podría ir a extracción de recibos. La captura podría entrar a un flujo de soporte. La foto del 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 generar 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 clasificar la etiqueta nutricional y el código de barras de una botella como un ticket de compra.
Se nota el problema. Ambos pueden contener texto denso, números y diseños rectangulares. Necesitamos ejemplos que le enseñen al sistema el límite exacto que le importa a nuestra aplicación.
Esa muestra es demasiado reducida para afirmar algo válido en producción. Las etiquetas venían del dataset y no fueron validadas de forma independiente, y no había ejemplos nuevos de tickets 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 sobre el M4 Max. El navegador primero necesita unos 85 MiB de recursos del modelo, además de 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é pasa después.
Un desarrollador define categorías, proporciona ejemplos representativos, conecta los destinos y elige qué debe ocurrir cuando la clasificación es dudosa.
El primer despliegue debería observar el flujo de trabajo actual sin alterar su resultado. Así podemos comparar las decisiones propuestas con los resultados verificados antes de dejar 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 define las reglas de aceptación. Una prueba protegida verifica el resultado congelado.
En cuanto un error de prueba influye en el siguiente modelo, ese ejemplo se convierte en datos de desarrollo. La próxima evaluación necesitará una prueba nueva.
El pequeño alienígena de la clasificadora de correo ayuda a la gente a visualizar 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 tras contabilizar esos errores.
Es hora de escalar y ponerle esteroides a este modelo local.
