
10. Evaluación y testing de LLMs
1 · QUÉ ES — PARA PROFANOS
En un examen clásico hay una respuesta correcta. Con un LLM, no. Dos respuestas distintas
pueden ser las dos buenas — y una respuesta puede sonar maravillosa y estar mal al mismo tiempo.
Por eso evaluar un sistema de IA es el problema más incómodo del sector: nadie sabe qué medir,
así que casi nadie mide, y la confianza sustituye a la medición.
La metáfora del examen sin plantilla: imagina corregir mil exámenes de redacción sin una
plantilla de respuestas. O te inventas una plantilla (y corriges mal), o pones a otro redactor a
corregir (y añades otro posible error), o buscas algo objetivo que comparar — dos respuestas
del mismo alumno a la misma pregunta, la cita exacta del libro, el dato que tenía que aparecer.
Las tres cosas que se pueden medir, de verdad:
1. ¿Encontró lo que debía? — ¿el documento correcto está entre los que recuperó?
2. ¿Dijo lo que debía? — ¿la respuesta se apoya en el documento, y la cita existe?
3. ¿Cambió sin avisar? — ¿responde igual hoy que ayer a la misma pregunta?
Y la pregunta del banco, que es la que importa: si mañana un regulador pregunta "¿cómo sabéis
que esto funciona?", ¿la respuesta es una métrica o una sensación? La JD lo pide literal:
"diseñar mecanismos de evaluación de respuestas, calidad, precisión y comportamiento".
El método serio tiene tres piezas:, Pieza, Qué es,, Conjunto dorado, 200-1.000 preguntas reales con su respuesta correcta etiquetada — la plantilla,, Métricas, recall@k, precisión de cita, faithfulness, tasa de abstención correcta,, Harness de evaluación, el sistema que pasa el conjunto dorado, guarda resultados y compara versiones, Y un atajo muy popular, con un defecto conocido: el LLM-as-judge — poner un modelo a
puntuar a otro. Es barato y rápido, y produce un número que parece una métrica. El defecto: el
juez puede alucinar la nota. Un número que produce un sistema falible sobre otro sistema falible
no es una medición — es una opinión con decimales.
Lo que un equipo maduro hace además: evaluación en el pipeline de despliegue (ningún cambio
pasa sin pasar los evals), monitorización en producción (deriva, regresiones), y red teaming —
ataques deliberados para ver qué rompe el sistema antes de que lo haga un usuario.
- Evaluación de agentes, no de respuestas: la métrica deja de ser "¿respondió bien?" y pasa a
ser "¿completó la tarea, cuánto costó, cuántos pasos dio?". Los agentes se evalúan como
empleados: éxito de tarea y coste por tarea.
- Jueces con debate: dos modelos discuten la calidad de una respuesta y un tercero decide. Mejor
que un juez único; aún es opinión, pero más cara y menos sesgada.
- Datos sintéticos para el conjunto dorado: generar preguntas difíciles automáticamente a partir
del corpus. Multiplica el examen sin coste de etiquetado manual.
- Evaluación continua como compliance: con la AI Act y DORA, la evaluación deja de ser opcional.
El registro de evaluaciones empieza a ser evidencia regulatoria. Un sistema sin histórico de
evaluaciones es, para un auditor, un sistema sin pruebas.
Una batería de evaluación corriendo en producción desde el 12 de agosto, cada seis horas, sobre
seis agentes.
Las cuatro pruebas:, Prueba, Qué comprueba, Cómo puntúa,, Identidad, que el agente sabe quién es, inventarse el creador resta 3,, Dominio, que conoce su materia, 1,2 por concepto, penalización por confusión,, Ecosistema, que conoce al equipo, agente inventado resta 3,, Estabilidad, que responde igual dos veces, solape calculado por fórmula, no por un LLM, La decisión central — y la respuesta a la crítica del LLM-as-judge: la estabilidad no la
juzga un modelo: la calcula una fórmula. Determinista, barata, y no puede alucinar. Y la hemos
delimitado con honestidad: mide deriva, no corrección. Dos respuestas igual de erróneas y
estables puntúan alto — lo decimos nosotros antes de que lo pregunten.
El caso real que lo demuestra todo — extraído del registro, no de la memoria:
La lección convertida en regla: una prueba que no puede ejecutarse no cuenta ni como aprobada
ni como suspendida — se marca no concluyente. Si el 401 se hubiera contado como "el agente
falló", habríamos tomado decisiones sobre los modelos cuando el problema estaba en la credencial.
Confundir un fallo de tubería con un fallo de modelo es el error más caro de la evaluación.
Y la calibración que evita el autoengaño: los modelos baratos se miden contra un ancla de
pago. Sin referencia, la puntuación es decorativa. Un ciclo semanal propone pruebas nuevas, las
valida en staging, y una prueba solo entra en producción si el ancla de referencia la pasa
completa — promoción versionada, con restauración automática si el ciclo queda incompleto.
> "Diseñar mecanismos de evaluación de respuestas, calidad, precisión y comportamiento de las
> soluciones de IA." · "Evaluación y testing de aplicaciones basadas en LLM." · "Evaluación y
> monitorización de soluciones de IA" (governance).
"¿Cómo sabes que el sistema funciona?" (la respuesta de 45 segundos)
> "Cuatro pruebas cada seis horas sobre seis agentes, desde agosto: 419 ejecuciones guardadas.
> Miro si el agente sabe quién es, si conoce su dominio, si conoce al equipo, y si responde igual a
> la misma pregunta dos veces. La última no la juzga otro modelo: la calcula una fórmula, así que
> el juez no puede equivocarse inventando. Y lo más útil no es la nota: es que detecta cambios. En
> tres meses ha cazado 18 caídas fuertes y 70 fallos técnicos que sin registro se habrían confundido
> con mal rendimiento. Un medidor que nunca baja la nota no sirve: el mío pasó de 6,18 a 5,98."
"¿Usas un LLM para evaluar a otro LLM?"
> "No para la métrica que importa. Un LLM juzgando a otro produce un número que parece medición y
> es opinión — el juez puede alucinar la nota. Mi prueba de estabilidad la calcula una fórmula de
> solape entre dos respuestas: determinista, barata y sin alucinaciones. Y tengo clara su
> limitación: mide deriva, no corrección. Para corrección hace falta el conjunto dorado — que es
> exactamente lo siguiente que construiría."
"Dame un fallo real que tu sistema haya detectado."
> "33 veces, un 401. La clave del proveedor había rotado y el test seguía usando la vieja. La
> batería lo registró cada vez, con la respuesta cruda guardada. Sin ese registro habría concluido
> que los modelos empeoraron, cuando el problema era una credencial. De ahí saqué una regla: una
> prueba que no puede ejecutarse se marca no concluyente — nunca se cuenta como suspenso del
> modelo."
"¿Cómo evitas que el sistema se degrade sin que lo notes?"
> "Con la evaluación continua: seis horas de intervalo máximo, histórico completo, y umbrales de
> regresión. Cuando un agente baja más de dos puntos entre rondas, se ve esa misma noche. Lo que
> falta — y lo digo antes de que lo preguntes — es el freno automático: hoy la decisión de parar la
> tomo yo. El gate que bloquee un despliegue por debajo de umbral es lo siguiente que construiría."