Medir antes de fiarse

Demasiadas funciones con LLM se aprueban por sensaciones. Alguien prueba unos cuantos prompts en una reunión, las respuestas parecen brillantes y la función sale a producción. Después falla en silencio en un caso que nadie probó, delante de un cliente, y nadie sabe decir con qué frecuencia ocurre.

El remedio no es ingenioso. Decide cómo vas a medir la función antes de elegir el modelo, y trata esa medición como parte del producto.

Etiqueta antes de mirar

Empieza por un conjunto de referencia: unas decenas de casos reales del flujo de trabajo, etiquetados a mano por alguien que conoce el tema. Escribe sobre la marcha una guía de etiquetado breve y apunta cada caso dudoso: ahí tropezará también el modelo.

Dos reglas importan más que el tamaño. Etiqueta cada caso antes de ver ninguna respuesta del modelo, o acabarás corrigiéndolo con sus propias respuestas. Y repite una muestra una semana después, o pásasela a otra persona, para saber cuánto coinciden los humanos. Si dos expertos discrepan, la nota del modelo en esos casos dice muy poco.

Cada cifra, con su intervalo

Con conjuntos pequeños, los márgenes son amplios, y no pasa nada si lo dices. Imagina que un modelo acierta cuatro de cada cinco casos en un conjunto de cuarenta. Lo honesto es decir que su acierto real está, más o menos, entre dos de cada tres y nueve de cada diez. Ese rango es el resultado. Un porcentaje suelto lo esconde.

Los intervalos también hacen que elegir modelo sea aburrido, que es lo que quieres. Mi regla: el modelo más pequeño cuyo intervalo se solape con el del mejor, y después comparar coste y latencia. Fija la versión fechada del modelo y no el alias, pon fecha a los precios y repite la evaluación cada trimestre, porque los alias y los precios cambian.

Que el modelo no haga las cuentas

En Licita, un proyecto de investigación independiente sobre contratación pública, los modelos de lenguaje tienen una tarea muy acotada: leer lo que resuelven los tribunales y estructurarlo con un esquema estricto. Cada cita que devuelven se comprueba contra el texto exacto que recibieron. Si no coincide, se marca y nunca se muestra como prueba.

Cada número que ve el lector lo calcula código normal y probado, con su fuente y la fecha de los datos al lado. Si el intervalo de una cifra incluye el cero, el informe no muestra ninguna cifra. Un número que puede salir con cualquier signo es peor que ninguno. Una tarea así de acotada se puede medir, y hace realista usar un modelo pequeño.

Prueba la opción barata, y tu propio sistema

Antes de gastar nada en una API, probé un modelo de pesos abiertos en GPU gratuitas en la nube, con el mismo prompt y esquema. Las respuestas eran válidas y las citas, en su mayoría, correctas. Aun así, fallaba en lo único que importaba: qué decidió el tribunal sobre cada motivo. Esa prueba no costó nada, y es la razón de que la evaluación llegara antes de escalar nada.

Tu propio sistema también necesita evaluaciones. Al contrastar la cifra principal de Licita encontré dos errores míos: algunos lotes se medían contra el presupuesto de toda su licitación, y algunas adjudicaciones se contaban dos veces porque los archivos se solapaban. Hoy ambos son controles obligatorios que impiden poner en uso una versión defectuosa.

Si vas a lanzar una función con un LLM, empieza por aquí:

• Reúne unas decenas de casos reales y etiquétalos antes de que los vea ningún modelo.
• Escribe qué significa “correcto”, incluidos los casos dudosos.
• Da cada métrica con su intervalo, y ninguna por debajo de una muestra mínima.
• Que el código calcule cada número sobre el que alguien vaya a actuar.
• Fija versiones y precios con fecha, y repite la evaluación cuando cambien.

Las sensaciones valen para una demo. Lo que un cliente va a usar se mide antes.