En la mayoría de los proyectos de IA llega un momento en que alguien dice: «Tiene muy buena pinta, pongámoslo en producción». Normalmente ese juicio se basa en una docena de ejemplos escogidos a mano y probados en una reunión. Luego el sistema se enfrenta al tráfico real y empiezan las preguntas. ¿Por qué se inventó una fecha de entrega? ¿Por qué empeoró después de cambiar el prompt? ¿Es mejor o peor que el mes pasado?
Ninguna de estas preguntas tiene respuesta sin evaluaciones, o evals: un conjunto fijo de casos de prueba con respuestas correctas conocidas, que se ejecuta automáticamente cada vez que algo cambia. Las evaluaciones son para los sistemas de IA lo que las pruebas automatizadas son para el software. Nadie pondría en marcha un servicio de pagos sin pruebas; un sistema de IA que lee facturas o responde a clientes merece la misma disciplina.
Partir del trabajo, no del modelo
Un conjunto de evaluación útil sale del proceso al que da soporte el sistema, no de benchmarks genéricos. Las clasificaciones públicas dicen cómo le va a un modelo con preguntas de examen. No dicen nada sobre si extrae la fecha de vencimiento correcta de las facturas de sus proveedores.
Por eso empezamos reuniendo casos reales, anonimizados cuando hace falta:
- Casos típicos, en la proporción en que se dan de verdad. Si el 70 % de los pedidos entrantes son reposiciones sencillas, el 70 % del conjunto también debe serlo.
- Casos difíciles que conocen los expertos: el proveedor que pone el total en la página dos, el cliente que escribe en tres idiomas.
- Casos en los que la respuesta correcta es «no lo sé»: datos que faltan, preguntas fuera de alcance, documentos contradictorios. Un sistema que siempre responde es más peligroso que uno que a veces se abstiene.
- Casos adversos: entradas que intentan que el sistema se comporte mal, como un correo que contiene instrucciones para la IA.
Cincuenta casos bien elegidos valen más que quinientos al azar. El conjunto crece con el tiempo: cada error detectado en producción se convierte en un nuevo caso de prueba, para que el mismo fallo no pueda volver sin que nadie lo note.
Medir lo que le importa al negocio
«Precisión» suena sencillo, pero esconde decisiones. Para un agente que procesa facturas, un importe equivocado es mucho peor que un número de pedido que falta. Para un asistente de conocimiento, una respuesta sin fuente puede ser aceptable en preguntas frecuentes internas, pero no en cuestiones de cumplimiento normativo.
Acordamos las métricas con las personas responsables del proceso, normalmente:
- Exactitud por campo o por respuesta, ponderada según lo que cuesta un error.
- Fundamentación: ¿cada afirmación está respaldada por una fuente que el sistema recuperó de verdad?
- Calidad de la abstención: ¿el sistema se abstiene cuando debe, y solo entonces?
- Latencia y coste por caso, porque una respuesta correcta que tarda un minuto o cuesta un franco puede hacer fracasar igualmente el caso de negocio.
Cada métrica recibe un umbral que debe cumplirse antes de la puesta en producción. El umbral se fija por escrito antes de conocer los resultados, para que nadie sienta la tentación de mover la portería.
Automatizar la evaluación y luego evaluar al evaluador
Algunas respuestas se pueden comprobar de forma mecánica: un importe extraído coincide o no coincide. Las respuestas en texto libre son más difíciles. Aquí un segundo modelo puede actuar como evaluador y comparar la respuesta con una referencia y unos criterios. Funciona bien, pero solo si el propio evaluador está validado: pedimos a personas que puntúen una muestra, comparamos y solo confiamos en el evaluador automático allí donde coincide con ellas.
Las evaluaciones nunca terminan
La puesta en producción no es el final de la evaluación. Los proveedores actualizan sus modelos, los documentos cambian y los usuarios encuentran nuevas formas de preguntar. Tres hábitos evitan que la calidad se degrade:
- Ejecutar el conjunto completo en cada cambio: un prompt nuevo, una nueva versión del modelo, un nuevo ajuste de recuperación. Si una puntuación baja, el cambio no se publica.
- Tomar muestras del tráfico de producción para revisarlas periódicamente a mano, con los datos personales enmascarados.
- Vigilar las señales de alarma: más abstenciones, más correcciones humanas, respuestas más largas, más coste.
Qué significa esto en la práctica
Antes de poner en producción un piloto, usted debería poder ver un informe breve: el conjunto de evaluación, las métricas acordadas, los umbrales y los resultados, con ejemplos de dónde falla el sistema. Si un proveedor no puede enseñárselo, la respuesta honesta a «¿está listo?» es «todavía no lo sabemos».
Ese informe es también la mejor herramienta para la siguiente decisión. Muestra qué errores quedan, cuánto costarían y si la forma más barata de corregirlos es más trabajo, otro modelo o un paso de supervisión humana.