Cambiaste una frase del prompt para arreglar un caso que se quejaba un usuario. Anda. Tres días después te enterás de que otros dos casos, que antes salían bien, ahora salen mal. Sin una forma de medir, cada ajuste en un sistema con IA es una apuesta, y la sensación de que "parece mejor" se parece mucho a la de que "me acuerdo de que funcionaba".
La buena noticia es que evaluar no requiere una infraestructura enorme. Requiere disciplina y un archivo con ejemplos.
Un conjunto de casos que se parezca a la realidad
El punto de partida es una colección de entradas representativas con la salida esperada, o al menos con una descripción de lo que se espera. Las mejores fuentes son las consultas reales de tus usuarios (con los recaudos de privacidad que correspondan) y los reclamos que ya tuviste. Cada falla que te reportan es un caso nuevo para el conjunto.
Algunas pautas para armarlo:
- Incluí lo cotidiano y lo incómodo: entradas cortas, larguísimas, con errores de tipeo, en otro idioma, vacías, ambiguas.
- Sumá casos donde la respuesta correcta es negarse o decir que no hay información suficiente.
- Empezá con treinta o cincuenta casos bien elegidos. Es preferible un conjunto chico que realmente usás a uno enorme que nadie mantiene.
- Guardalo en el repositorio, en un formato simple como JSON o CSV, para que cambie con el código.
Definir qué es una buena respuesta
Antes de medir hay que ponerse de acuerdo en el criterio, y ahí aparecen las discusiones útiles. En una tarea de extracción de datos la respuesta es correcta o no. En un resumen o en un texto de atención al cliente intervienen varias dimensiones: que sea fiel a la fuente, que tenga el tono adecuado, que no invente, que respete el largo pedido.
Conviene escribir esos criterios como una lista corta y verificable. "Menciona el número de pedido", "no promete reembolsos", "responde en menos de cien palabras". Algunos se chequean con código, sin intervención humana. Otros necesitan un juicio.
def cumple(respuesta, caso):
if len(respuesta.split()) > 100:
return False
if caso["numero_pedido"] not in respuesta:
return False
return "reembolso" not in respuesta.lower()
Reglas así son baratas, rápidas y no discuten. Cubren una parte del problema, no todo.
Revisión humana y modelos como evaluadores
Para lo que el código no alcanza, lo más confiable sigue siendo que una persona lea una muestra. No hace falta revisar todo cada vez: elegí un puñado al azar en cada cambio importante y mirá cómo viene. Anotar el motivo de cada falla suele enseñar más que el puntaje.
También se puede usar otro modelo para calificar las respuestas según una rúbrica. Es tentador por la velocidad, y funciona razonablemente como filtro, pero tiene sesgos conocidos: tiende a preferir respuestas largas, puede favorecer el estilo de modelos parecidos al suyo y a veces es indulgente con errores sutiles. Antes de confiar en él, comparalo contra tu propia revisión en una tanda de casos y fijate cuánto coinciden. Si no coincide, ajustá la rúbrica o no lo uses para decidir.
Métricas simples y regresiones
No necesitás nada sofisticado. Porcentaje de casos que pasan los chequeos automáticos, cantidad de respuestas con formato inválido, tasa de negativas correctas, tiempo de respuesta. Lo valioso es la comparación entre una corrida y la anterior, no el número aislado.
Eso es lo que permite detectar regresiones. Cada vez que cambia algo, corrés el conjunto completo y mirás qué casos pasaron de bien a mal. Cambios que dispararían la corrida:
- Una modificación del prompt, por mínima que parezca.
- Un cambio de modelo o de versión del modelo, incluso si el proveedor dice que es equivalente.
- Un cambio en cómo recuperás o armás el contexto.
- Un ajuste de parámetros como la temperatura.
Como las respuestas varían de una ejecución a otra, no te alarmes por un caso aislado que falla una vez. Repetí las corridas o mirá la tendencia sobre el conjunto entero.
Después del lanzamiento
La evaluación previa no cubre lo que los usuarios van a hacer de verdad. En producción conviene registrar entradas y salidas (respetando la privacidad), ofrecer un botón simple para marcar una respuesta como mala y revisar periódicamente una muestra. Los casos que aparezcan vuelven al conjunto de pruebas y el ciclo se cierra.
Con esto, la conversación sobre si algo mejoró pasa de la opinión al dato. Y cuando un cliente pregunta cómo sabés que tu sistema funciona, tenés algo concreto para mostrarle.