Lo que la ficha no anota

Hace años que construyo los sistemas que operan empresas chicas. Antes de eso estuve del otro lado del mostrador, y de ahí me quedó una corazonada que vengo arrastrando: gran parte de lo que una persona resuelve en un día de taller no requiere razonar demasiado. Requiere reconocer una situación ya vista y elegir.

¿Este trabajo es de chapa o de mecánica? ¿Este presupuesto va a terminar en trabajo? ¿Este mensaje lo puede contestar el sistema, o necesito agarrar yo el teléfono?

Son preguntas cerradas, con respuestas conocidas de antemano. Las llamo decisiones tipadas: la respuesta es elegir entre opciones fijas —sí o no, chapa o mecánica— en lugar de redactar texto libre. Son las más aburridas y las más frecuentes del día.

Si la corazonada es cierta, entonces a una pyme no le falta inteligencia: le falta que lo que hace quede anotado de una manera que una máquina pueda leer. Y si el problema es ése, no hace falta un modelo gigante ni caro. Alcanza con uno chico corriendo en una laptop, siempre que sepa cuánto sabe.

Eso quise poner a prueba. Con datos nuestros, de producción, no con un conjunto de prueba bajado de internet. Y con una regla que me impuse desde el principio: si el resultado salía negativo, se publicaba igual.

El modelo no escribe: elige

Conviene aclarar qué entrené, porque no es lo que la mayoría imagina cuando se habla de IA.

Un modelo de lenguaje normal contesta generando texto, palabra por palabra. Para decirte “sí” tiene que escribir “sí”, y en el camino puede escribir cualquier otra cosa. Este no genera nada. Lee el estado y las opciones de una sola pasada y devuelve una probabilidad para cada opción. No puede inventar una respuesta fuera de la lista porque no tiene con qué escribirla.

Es lo que se llama un modelo de Sistema 1, por la distinción de Kahneman: la respuesta inmediata, la que uno da sin deliberar. El modelo que razona paso a paso, escribiendo su propio razonamiento, sería el Sistema 2. Acá no hay deliberación: hay reconocimiento. Por eso tarda 50 milisegundos en vez de segundos.

Lo que lo separa de un clasificador cualquiera es cómo se entrena. Aprende con reglas de puntuación que lo castigan por estar seguro cuando no corresponde, no solo por errar. Eso es lo que hace que un 0,8 signifique de verdad “acierto ocho de cada diez veces” y no sea un número decorativo. Es la diferencia entre algo que sugiere y algo que puede actuar solo por debajo de un umbral que uno fija.

Esa es la pieza que venimos mirando hace meses para poner delante de un empleado de IA: la que decide, antes de que el modelo caro abra la boca, si este mensaje es urgente, de qué se trata, y si lo tiene que atender una persona.

22.098 decisiones que ya ocurrieron

Nadie las etiquetó. Cada respuesta correcta es algo que efectivamente pasó y quedó registrado: el presupuesto se convirtió en trabajo o se murió, el mensaje se contestó o no, el repuesto se pidió o estaba en el estante.

Seis preguntas, de las cuatro etapas por las que pasa cualquier trabajo: recepción, presupuesto, ejecución y seguimiento. Los datos vienen de Woms y Avora —los sistemas que operan hoy en talleres, chapa y pintura, comercios y gastronomía— más el historial de un empleado de IA que atiende a un cliente real.

Todo anonimizado en la extracción. Los resultados valen para este conjunto de clientes y no para “las pymes uruguayas”: en dos de las seis preguntas, un solo negocio aporta la mitad de los casos. Y una regla estricta: el estado que ve el modelo no puede contener la respuesta. Si la pregunta es si hay que pedir el repuesto, no va el proveedor ni el número de seguimiento. Volveré sobre esto, porque es exactamente donde me equivoqué.

Contra qué se compara, antes de entrenar nada

Un número solo no dice nada. Un modelo que acierta el 90% puede ser excelente o inútil, según contra qué se lo mida. Por eso puse tres varas antes de tocar el modelo.

La primera es la clase mayoritaria: contestar siempre lo más frecuente. Si el 94% de los mensajes se contestan, decir siempre “se va a contestar” acierta el 94% sin saber nada. Cualquier modelo tiene que superar eso para justificar su existencia.

La segunda son reglas por palabras clave, una lista hecha a mano: si el texto dice “masilla” o “paragolpe”, es chapa. Lo que cualquiera programaría en una tarde, sin inteligencia artificial de por medio.

La tercera es un modelo grande genérico. Le hice las mismas preguntas a Claude Haiku, 200 casos de cada una. Si un modelo de propósito general ya las resuelve, entrenar uno propio no tiene sentido. Costó 23 centavos de dólar.

La tercera vara dio el primer resultado interesante, y no por donde yo esperaba. Haiku le ganó a la clase mayoritaria en dos de seis preguntas. Pero en las más desbalanceadas se desplomó: en “¿este presupuesto avanza?” sacó 0,270 contra 0,890 de la vara más tonta. Y el modo en que perdió es lo que vale: mientras la precisión se hundía, la detección de los casos raros se le disparaba a 0,909. No estaba confundido. Estaba contestando “sí” demasiado seguido.

Un presupuesto de taller uruguayo se convierte en trabajo el 89% de las veces. Ese número no está en ningún texto de internet. Está en la base de datos del taller.

Dos preguntas no medían una decisión: medían el formulario

Acá el experimento se dio vuelta. Antes de mirar ningún resultado del modelo, se me ocurrió correr una prueba tonta: para cada pregunta, buscar la regla más boba posible usando un solo campo de la ficha. No el texto: el campo.

Aparecieron dos preguntas pegadas al techo.

• En “¿hay que pedir este repuesto?”, una regla sobre el campo tipo_ficha acierta 0,979, contra una vara de 0,500.
• En “¿este mensaje necesita una persona?”, alcanza con mirar si el campo rondas_previas existe: 0,864, contra una vara de 0,601.

Las dos fugas tienen exactamente la misma forma, y por eso dejaron de ser un error mío para convertirse en el hallazgo del experimento: lo que delata la respuesta es que un campo exista o no exista, no lo que dice.

Una fuga de datos es cuando la respuesta está escondida en la pregunta sin que uno se dé cuenta. El modelo la encuentra, acierta casi siempre, y uno cree que aprendió el oficio cuando en realidad encontró un atajo.

En chapa y pintura siempre hay que pedir repuestos, y esas fichas siempre traen cargado el campo operacion. En mecánica casi nunca, y ese campo viene vacío. La pregunta “¿hay que pedir este repuesto?” era, sin que yo lo viera, la pregunta “¿esta ficha es de chapa?”. En las 492 fichas de chapa del conjunto de prueba hubo que pedir el repuesto en el 100,0% de los casos. Ni una excepción en 492. En las 518 de mecánica, el 3,7%.

La segunda fuga es más incómoda, y lo es sobre todo por dónde pega: decidir si un mensaje necesita una persona es exactamente la función para la que yo quería este modelo. Es el portero que decide qué escala y qué no. Cuando una persona toma el control de una conversación, esa conversación nunca llega a registrar cuántas rondas hubo: el campo queda vacío. Con el campo cargado, la respuesta es “lo cierra el asistente” en 232 de 232 casos. Con el campo vacío, el 77,5% necesitan una persona. La causa y el efecto están al revés, y el modelo aprendió eso, no a leer al cliente.

El rastro que deja el sistema no codifica la decisión del negocio. Codifica por qué rama del formulario pasó el caso.

Las dos preguntas se descartan. El benchmark válido queda en cuatro, y una de ellas la resuelve una lista de palabras. Quedan tres preguntas realmente abiertas de las seis con las que empecé.

Hay una ironía acá que todavía me da vueltas. Yo iba a medir la falta de legibilidad de una pyme entrenando un modelo. Terminé mostrándola antes de entrenar nada, con una prueba que corre en segundos.

El modelo aprendió el atajo con precisión decimal

Igual entrené. Dos pasadas completas sobre los datos, 38 minutos en mi laptop. El resultado en las dos preguntas con fuga es casi gracioso: donde la regla boba sacaba 0,981, el modelo entrenado sacó 0,981. Donde la regla boba sacaba 0,886, el modelo sacó 0,881. No aprendió el oficio. Aprendió el atajo, con el mismo decimal, y nada más que el atajo.

Sobre las cuatro preguntas legítimas, el panorama es mucho más duro.

• Tipo de trabajo, chapa o mecánica: 0,960 contra una vara de 0,670. Es la única que pasa. Pero una lista de palabras del oficio saca 0,970, más que el modelo.
• Qué mensaje se escapa sin respuesta: 0,935 contra una vara de 0,941. Empata, y detecta solo el 40,9% de los que efectivamente se escapan.
• Si el trabajo lo paga una compañía de seguros: 0,386 contra 0,702. Se hunde.
• Si el presupuesto avanza: 0,322 contra 0,894. Se hunde del todo.

Y acá aparece el resultado que menos esperaba. La calibración —que era mi riesgo principal cuando diseñé esto— salió bien. La calibración mide si el modelo sabe cuánto sabe: que cuando dice “estoy 80% seguro”, acierte cerca del 80% de las veces. Es la diferencia entre una sugerencia y algo que puede actuar solo bajo un umbral. Donde el modelo acierta, queda bastante por debajo del límite que me había puesto como exigencia. Y responde en 50 milisegundos.

El problema no es que el modelo no sepa cuánto sabe, ni que salga caro preguntarle. El problema es que no sabe.

Lo que casi arruina la corrida no fue la potencia

Una de las cosas que quería demostrar era la más chica de todas: que esto corre en una laptop, sin alquilar una placa de video. Corre. Pero me costó una noche entender por qué no corría.

El entrenamiento arrancaba a 2,1 segundos por paso y se iba degradando hasta más de 20, sin dar un solo error. Nada se rompía; simplemente se volvía cada vez más lento. Cuando fui a mirar la memoria, el proceso usaba 19 GB en una máquina de 16, con 12,7 GB de disco haciendo de memoria prestada y 84 MB libres.

La causa: yo le daba al modelo lotes de texto de largo variable. Cada largo distinto hace que la placa reserve un bloque de memoria nuevo, y los va guardando todos por si vuelven a aparecer. Al fijar el largo siempre en el mismo número, la memoria dejó de crecer y el paso bajó a 1,5 segundos.

Lo dejo escrito porque es el tipo de detalle que en una placa alquilada de 40 GB no se nota nunca. En una laptop, decide si el experimento existe o no.

El experimento entero costó 23 centavos de dólar y 38 minutos de entrenamiento. Cero placas alquiladas.

Se registra el resultado, no la decisión

La hipótesis con la que arranqué queda refutada en su forma fuerte. Pero la refutación no dice “estas decisiones son demasiado complejas para una máquina”. Dice algo bastante más específico y bastante más accionable.

Las dos preguntas que el modelo resolvió fueron las dos donde la ficha guardaba un atajo estructural. Las otras cuatro dependen de contexto que en ningún lado quedó escrito: quién es el cliente, qué se habló por teléfono, si el tipo vino él a pedir el presupuesto o si se lo ofrecimos nosotros, cómo viene el mes.

El sistema guarda el resultado de la decisión. No guarda el estado sobre el que se decidió. Y eso no se arregla con un modelo mejor ni con más datos del mismo tipo.

Hay un dato que apareció de costado y que, para mí, es el más contundente de todo el experimento. Quise armar una pregunta sobre demoras: ¿esta orden se va a atrasar? Hay 18.587 fichas con fecha estimada de entrega cargada. De ellas, 18.576 cerraron después de esa fecha. El 99,94%. No hay nada que predecir ahí: la promesa que se le hace al cliente no se registra de una forma que permita saber si se cumplió.

Lo que me llevo

Empecé queriendo saber si una máquina chica podía tomar las decisiones del día. Termino sabiendo otra cosa, más importante, que no estaba buscando: buena parte de lo que creí tener registrado no es una decisión. Es la huella de un formulario.

Hay una lectura cómoda de todo esto —“los modelos chicos no alcanzan”— que sería falsa. El modelo calibra bien, contesta en 50 milisegundos y costó 23 centavos. Cuando hay señal, la encuentra. El asunto es que en cuatro de seis preguntas no había señal que encontrar, porque nadie la anotó nunca.

Eso me cambia el orden de trabajo. Antes de poner un modelo delante de cualquier cosa, hay que arreglar qué se escribe en el momento en que alguien decide. No es glamoroso: son tres campos más en una pantalla y seis meses de paciencia. Pero es lo que separa un sistema que se puede automatizar de uno que solo se puede mirar.

Y me deja una regla que voy a aplicar a todo lo que venga: si un resultado me sorprende para bien, el primer sospechoso soy yo.