Savian: el dato estaba en un panel y quien lo necesitaba, en una furgoneta

La primera versión hacía lo que parece obvio cuando se tiene un modelo de lenguaje delante. Recibía la pregunta en castellano, escribía con ella una consulta SQL y la ejecutaba. SQL es el lenguaje con el que se le piden datos a una base de datos.

Funcionaba. En una demostración funcionaba muy bien, que es precisamente el problema de dejarle escribir la consulta.

¿Por qué retirar algo que funciona? Por dos motivos distintos que conviene separar, porque uno se ve enseguida y el otro no.

El primero es de seguridad. Un modelo al que se le deja escribir la consulta puede escribir cualquiera que el lenguaje permita. Lo único que se lo impide es una frase en sus instrucciones. Una instrucción a un modelo de lenguaje es una petición y no una garantía. Se atiende casi siempre. Ese «casi» es toda la diferencia cuando al otro lado hay datos de varias empresas.

El segundo es más aburrido y lo vimos antes que el primero. Cometía fallos. Consultas que se ejecutaban sin error y devolvían una cifra que no era la que se había preguntado, que es la peor clase de fallo porque nadie lo ve.

De ahí sale la regla que ordena todo lo que construimos desde entonces. El juicio vive en el código, la interpretación del lenguaje vive en el modelo y el conocimiento vive en los datos. El modelo hace lo que sabe hacer, que es entender lo que le piden. El código hace lo que exige garantías, que es tocar los datos.

No fue lo único que hubo que sacar de ahí. Los centros de trabajo y las fincas tienen nombres largos que nadie teclea igual dos veces, así que el agente corrige lo que la persona escribe y lo empareja con el nombre real. Esa corrección existe para que nadie tenga que acordarse de una denominación exacta.

Al principio ese emparejamiento también lo hacía el modelo. Le dábamos la lista de centros de trabajo y fincas a los que esa persona tiene acceso y le pedíamos que dijera cuál de ellos era el que quería decir.

Fallaba mucho. Y cuando no fallaba del todo hacía algo peor, emparejaba con el más parecido de la lista, que no siempre es el correcto. Un nombre que se parece no es un nombre que coincide. El modelo no distingue bien entre esas dos cosas.

Hoy esa comparación la hace un algoritmo de emparejamiento aproximado, lo que en inglés se llama fuzzy matching. Mide cuánto se parecen dos textos y devuelve una puntuación, así que se puede exigir un mínimo y descartar lo que no llega. El acierto subió en cuanto dejó de ser una opinión.

La forma del arreglo es la misma que en la consulta. Una tarea que parecía de lenguaje resultó ser de comparación. Y comparar es de las cosas que un código hace igual todas las veces.

Hoy el modelo no escribe ninguna consulta. Lee la pregunta y devuelve un formulario de campos fijos que definimos de antemano: el periodo, el ámbito, los filtros, la métrica y las agrupaciones. Nada más.

El código recibe ese formulario, comprueba que cada campo trae un valor permitido y construye él la consulta, con los valores pasados como parámetros y los nombres de columna sacados de una lista cerrada. Ningún identificador se arma con texto que haya escrito el modelo.

Y de ahí sale la garantía. Un formulario de cinco campos conocidos se puede comprobar entero antes de ejecutar nada. Una consulta escrita en texto libre, no.

El agente responde a los responsables de varias empresas del mismo grupo, cada uno sobre las suyas, así que la separación entre unas y otras es la garantía que sostiene el sistema entero. La separación se impone en cuatro sitios. El modelo no es ninguno de los cuatro.

La información que el modelo puede leer mientras responde contiene solo las empresas de quien pregunta, así que las demás no existen para él y no puede filtrar lo que nunca tuvo.

La corrección de nombres que acabamos de contar busca solo dentro de esas mismas empresas. Quien escribe un nombre a medias o con una letra bailada acaba en el centro que quería, si ese centro es suyo. Si no lo es, no llega a ninguna parte.

Después, el código valida la petición contra una lista cerrada de valores permitidos antes de construir nada. Y la consulta final lleva un filtro incondicional que, si la lista de permisos llegara vacía, la resuelve en una condición que no encaja con ninguna fila. Cuando algo falla, el sistema se cierra en vez de abrirse.

Hay preguntas que el sistema no contesta a propósito. Las columnas con las horas trabajadas, los retrasos y las ausencias de personas concretas existen en la base de datos y sencillamente no se le exponen al agente.

La negativa no vive en una frase de sus instrucciones, vive en lo que el sistema puede alcanzar. No es que decida no contestar, es que no tiene con qué.

Con las manos ocupadas y el móvil en el bolsillo, escribir tampoco es siempre cómodo. La manera natural de preguntar en el campo es mandar una nota de voz, así que el agente las entiende.

Detrás de una nota de voz trabajan tres modelos y cada uno hace una sola cosa. El primero transcribe el audio a texto. El segundo lee ese texto, entiende qué se está preguntando y compone la respuesta, con el mismo reparto de siempre, porque los datos los sigue trayendo el código. El tercero convierte la respuesta en voz.

Es la misma idea que sostiene el resto del sistema, repartir el trabajo en piezas que hacen una cosa cada una y se pueden comprobar por separado.

Esa cadena nos enseñó algo que no aparece en ninguna demostración. El modelo que compone la respuesta tiene que escribir las cifras y las fechas en letra, porque el que las va a leer en voz alta lee lo que está escrito.

¿Y qué pasa si no lo hace? Que un texto que dice «12.539 kilos» no suena a doce mil quinientos treinta y nueve kilos cuando lo lee un sintetizador. Escrito con letras, sí. Lo mismo pasa con las fechas, que dichas y escritas no se parecen en nada.

Parece un detalle de acabado y decide si el sistema se usa o se abandona. Una respuesta que suena rara no se cuestiona, se deja de escuchar.

La medida más útil de este sistema compara dos cosas que deberían coincidir siempre: la herramienta que la conversación pedía usar y la que el modelo usó de verdad. Cuando la herramienta pedida y la usada no coinciden, casi siempre significa que respondió de memoria en lugar de consultar, que es el fallo que ningún error de sistema delata.

Los huecos también se clasifican, uno a uno. Una pregunta que queda fuera de lo que el agente cubre, una que sí cubre pero para la que no hay datos y una que no ha entendido son tres problemas distintos, con tres arreglos distintos y tres dueños distintos. Contarlas juntas es no resolver ninguna.

La consulta que antes esperaba a la oficina hoy se hace desde donde esté quien pregunta, con el móvil, escrita o hablada. La respuesta llega en segundos. El panel sigue ahí para quien lo quiera. Lo que ha cambiado es que ya no hace falta llegar hasta él.

Lo siguiente que está en camino son las alertas automáticas, del tipo «avísame cuando pase esto», para que el sistema deje de esperar la pregunta y sea él quien avise.