Evaluar una aplicación con modelos de lenguaje es construir un sistema de medición propio, porque los benchmarks públicos comparan modelos en tareas generales y no responden si tu sistema resuelve tu tarea. La documentación de Anthropic resume el diseño en tres principios: ser específico de la tarea, automatizar cuando se pueda y priorizar el volumen sobre la calidad de cada caso. Los métodos de calificación van de lo más barato a lo más flexible: coincidencia exacta, similitud semántica, solapamiento de texto y modelo juez. Y el paso que suele faltar: si usás un modelo como juez, hay que validar su concordancia con personas, porque sin eso el puntaje es un número con apariencia de medición.
Ver índice de contenidos
De qué se trata esta guía
Conviene marcar el límite en la primera sección, porque el portal tiene otra guía cercana y hacen cosas distintas.
| Pregunta | Dónde se responde |
|---|---|
| ¿Cómo se prueba algo que no tiene una única respuesta correcta? ¿Qué es el problema del oráculo? ¿Cómo se arma un conjunto de casos desde cero y cómo se prueba el sesgo? | Testing de aplicaciones con inteligencia artificial |
| ¿Con qué método califico cada caso? ¿Puedo confiar en un modelo que hace de juez? ¿Qué mido en un RAG o en un agente? ¿Qué sigo midiendo cuando ya está en producción? | Esta guía |
Dicho de otra forma: la otra guía es la mirada de calidad sobre sistemas no deterministas; esta es la ingeniería del instrumento de medición y la desconfianza saludable hacia sus resultados.
Por qué los benchmarks no alcanzan
Existen marcos de evaluación pública serios. HELM —Holistic Evaluation of Language Models— se describe como «un marco de Python de código abierto creado por el Centro de Investigación en Modelos Fundacionales de Stanford para la evaluación holística, reproducible y transparente de modelos fundacionales». Lo valioso de su enfoque es que mide más allá de la exactitud: incorpora eficiencia, sesgo y toxicidad, entre otras dimensiones. Es una referencia útil y conviene conocerla.
Pero no responde tu pregunta. Un benchmark público contesta «qué modelo es mejor en promedio en tareas generales», y lo que necesitás saber es «este sistema, con mi prompt, mis documentos y mis usuarios, hace bien la tarea». Tres razones concretas por las que la brecha no se cierra sola:
- Tu tarea no está en el benchmark. Clasificar reclamos de tus clientes con tu taxonomía interna no se parece a responder preguntas de examen.
- Contaminación. Los conjuntos públicos circulan por internet, así que pueden haber entrado en los datos de entrenamiento. Un puntaje alto puede ser memoria y no capacidad.
- Distribución distinta. Tus entradas reales tienen faltas de ortografía, jerga interna, adjuntos raros y pedidos ambiguos. Los benchmarks están limpios.
Qué hacer con los benchmarks, entonces
Usarlos para preseleccionar: reducir de veinte modelos candidatos a tres. La decisión final se toma con una evaluación propia sobre tu tarea. Y un detalle de actualidad que vale al citar cualquier herramienta de este campo: el propio HELM entró en modo mantenimiento en junio de 2026, lo que dice bastante sobre la velocidad a la que envejecen las referencias de evaluación.
Los tres principios de diseño
La documentación de Anthropic sobre evaluaciones empíricas resume el diseño en tres principios, y los tres van contra la intuición de quien viene del testing tradicional:
- Ser específico de la tarea«Diseñá evaluaciones que reflejen la distribución de tu tarea del mundo real. ¡No te olvides de incluir los casos límite!» Entre esos casos límite menciona datos de entrada irrelevantes, entradas demasiado largas, entradas pobres o dañinas, y casos ambiguos donde ni las personas llegan a un consenso.
- Automatizar cuando se pueda«Estructurá las preguntas para permitir calificación automática»: opción múltiple, coincidencia de cadenas, calificación por código o por otro modelo.
- Priorizar el volumen sobre la calidad«Más preguntas con calificación automática de señal algo menor es mejor que menos preguntas con evaluaciones hechas a mano de alta calidad.»
El tercero es el que más resistencia genera y el que más importa. La razón es estadística: con diez casos, que uno cambie de resultado mueve el puntaje diez puntos, y no hay manera de distinguir una mejora real del ruido del muestreo. Con doscientos casos calificados automáticamente, un cambio de dos puntos empieza a significar algo. La tentación de curar veinte casos perfectos produce un instrumento que no puede detectar lo que vino a detectar.
Los cuatro métodos de calificación
Ordenados de más barato a más flexible. La regla es usar el más barato que sirva para el criterio que estás midiendo:
| Método | Cuándo usarlo | Su límite |
|---|---|---|
| Coincidencia exacta | Respuestas categóricas y sin ambigüedad: clasificación, extracción de un campo, una etiqueta | Falla ante cualquier variación de forma: «Positivo.» no es «positivo» |
| Similitud semántica | Consistencia: preguntas parecidas deberían dar respuestas parecidas. Tolera paráfrasis y errores de tipeo | Dice si se parecen, no si son correctas |
| Solapamiento de texto | Relevancia y coherencia en generación, sobre todo en resumen, comparando con una referencia | Un buen resumen con otras palabras puntúa bajo |
| Modelo juez | Criterios subjetivos que requieren juicio: tono, empatía, si se apoya en las fuentes, si respeta una política | Cuesta más, tarda más y hay que validarlo |
Del cuarto método, la documentación describe tres formas de pedirle el veredicto, y la elección cambia mucho la utilidad del resultado: una escala tipo Likert de 1 a 5 para algo como el tono de una respuesta; una clasificación binaria para criterios de cumplir o no cumplir —por ejemplo, si una respuesta preservó datos sensibles—; y una escala ordinal para grados, como cuánto aprovechó el historial de la conversación.
La recomendación práctica: para criterios que se pueden expresar como sí o no, usar clasificación binaria. Las escalas de 1 a 5 dan una ilusión de precisión —¿qué distingue un 3 de un 4?— y agregan variabilidad justo donde se necesita estabilidad.
Validar al juez
Este es el paso que casi todos saltean y el que decide si el sistema de medición vale algo. Si un modelo califica tus salidas, ese modelo es un instrumento y los instrumentos se calibran.
Empecemos por la precaución que la propia documentación marca como buena práctica: «generalmente es mejor práctica usar un modelo distinto para evaluar que el modelo usado para generar la salida evaluada». El motivo es intuitivo: un modelo tiende a considerar razonable lo que él mismo produciría.
Y después, la validación propiamente dicha, que es un procedimiento de tres pasos:
- Dos personas califican una muestraCien casos, la misma rúbrica, sin verse entre ellas.
- Medir la concordancia entre las personasSi no coinciden, el problema es la rúbrica: es ambigua. Arreglar eso antes de mirar al modelo.
- Medir la concordancia del juez con las personasSi las personas coinciden y el juez se aparta, hay que corregir su prompt o su rúbrica.
El paso dos es el que produce el hallazgo más útil de todo el ejercicio: buena parte de las veces, el desacuerdo entre personas revela que nadie tenía claro qué se estaba midiendo. Eso no es un problema de evaluación, es un problema de definición del producto, y aparece acá porque es el primer lugar donde se hace visible.
Un juez puede verse afectado por el orden en que se le presentan dos respuestas a comparar, y por la extensión: las respuestas más largas y elaboradas suelen puntuar mejor aunque no sean más correctas. Las dos cosas se pueden comprobar de forma barata: alternar el orden y ver si el veredicto cambia, y revisar si el puntaje correlaciona con la cantidad de palabras.
Qué medir según la tarea
Preguntar «¿está bien la respuesta?» no es medible. Lo que se mide depende de la tarea, y para las cuatro más comunes:
| Tarea | Qué medir | Con qué método |
|---|---|---|
| Clasificación o extracción | Exactitud por clase, no global; y la matriz de confusión, que muestra qué se confunde con qué | Coincidencia exacta |
| Resumen | Fidelidad al original y, sobre todo, ausencia de datos agregados que no estaban | Solapamiento de texto más juez binario |
| Sistema RAG | Recuperación —¿llegó el fragmento correcto?— y fundamentación —¿la respuesta se apoya en él?—, por separado | Recuperación por código; fundamentación con juez binario |
| Agente | Tareas completadas, cantidad de pasos usados y acciones no autorizadas intentadas | Verificación del estado final por código |
Dos observaciones sobre esa tabla. La exactitud global engaña en clasificación con clases desbalanceadas: un clasificador que nunca detecta la clase rara puede tener 97 % de exactitud y ser inútil justo para lo que se necesitaba. Y en agentes, la métrica que suele faltar es la última: cuántas veces intentó una acción que no le correspondía. Ese número no mide calidad, mide seguridad, y conviene tenerlo desde el primer día.
Del puntaje al portón
Una evaluación que se corre a mano cuando alguien se acuerda no protege de nada. El valor aparece cuando se convierte en portón de regresión: conjunto fijo, criterio fijo, umbral acordado de antemano.
# El portón es el umbral, no la opinión del modelo
evaluacion:
conjunto: casos/v3/ # fijo y versionado con el código
umbrales:
clasificacion_por_clase: ">= 0.90" # por clase, no global
fundamentacion: ">= 0.95" # juez binario ya validado
acciones_no_autorizadas: "== 0" # sin tolerancia
bloquea: true # comparar número contra umbral: determinista
# Lo que NO bloquea: pedirle a un modelo que opine si el cambio está bien.
# Eso va como comentario, porque puede responder distinto ante lo mismo.La distinción es fina y decisiva. Comparar un puntaje contra un umbral es determinista —mismo conjunto, mismo criterio, resultado reproducible— y por eso puede bloquear. En cambio, dejar que un modelo decida con criterio libre si el cambio pasa introduce un control que puede cambiar de opinión sin que cambie el código, y eso enseña al equipo a reintentar sin leer.
Medir en producción
El conjunto de evaluación mide lo que anticipaste. Producción trae lo que no. Tres cosas conviene tener andando desde el primer día:
- Trazas con muestreo. Guardar entrada, contexto recuperado, salida y modelo usado, para una fracción de las interacciones. Sin la traza completa no se puede diagnosticar un caso, y sin diagnóstico no hay caso nuevo para el conjunto.
- Un circuito de anotación. Revisar una muestra cada semana y clasificar las fallas. Cada falla clasificada es un caso que se suma al conjunto de evaluación: así es como el instrumento mejora en lugar de envejecer.
- Costo y latencia como métricas de calidad. Una respuesta perfecta que tarda cuarenta segundos o cuesta diez veces más falló en un sentido que importa. Van al lado del puntaje, no en otro tablero.
Y una advertencia sobre las trazas: guardar entradas y salidas es guardar datos de las personas, a veces sensibles. Vale decidir qué se registra, por cuánto tiempo y quién puede verlo antes de encender el registro completo.
Errores frecuentes
- Probar veinte casos a mano y declarar que funciona. Es una anécdota, y no detecta una regresión.
- Confiar en un puntaje de juez sin validarlo. Sin concordancia medida con personas, es un número con apariencia de medición.
- Usar el mismo modelo para generar y para juzgar. Tiende a aprobar lo que él mismo habría escrito.
- Mirar la exactitud global. Con clases desbalanceadas esconde exactamente el error que importaba.
- Usar escalas de 1 a 5 para todo. Si el criterio es cumplir o no cumplir, binario es más estable.
- No versionar el conjunto de casos. Si cambia el conjunto y el puntaje, no se sabe qué mejoró.
- Medir solo antes de salir. La distribución de entradas cambia; el conjunto de ayer mide el problema de ayer.
- Ignorar costo y latencia. Son parte de si la aplicación sirve, no un detalle de infraestructura.
Preguntas frecuentes
¿Por qué no me sirve el puntaje de un benchmark público?
Porque mide otra cosa. Un benchmark público compara modelos entre sí en tareas generales y estandarizadas, y eso responde «cuál modelo es mejor en promedio», no «este sistema resuelve mi tarea». Hay además dos problemas técnicos: la contaminación, porque los conjuntos públicos pueden haber entrado en los datos de entrenamiento, y la diferencia de distribución, porque tus entradas reales no se parecen a las del benchmark. Sirven para preseleccionar candidatos; la decisión se toma con una evaluación propia.
¿Cuántos casos necesita una evaluación para servir?
Más de los que la intuición sugiere, y la recomendación de la documentación de Anthropic es explícita al respecto: «priorizá el volumen sobre la calidad», porque «más preguntas con calificación automática de señal algo menor es mejor que menos preguntas con evaluaciones hechas a mano de alta calidad». La razón es estadística: con diez casos, un cambio en el resultado de uno mueve el puntaje diez puntos y no se distingue una mejora real del ruido. Un par de centenares de casos calificados automáticamente da mejor señal que veinte revisados con cuidado.
¿Qué es un modelo juez y cuándo conviene?
Es usar un modelo de lenguaje para calificar la salida de otro según una rúbrica. Conviene cuando el criterio es subjetivo y no hay respuesta única: tono, empatía, si una respuesta se apoya en las fuentes provistas, si respeta una política. No conviene cuando existe una respuesta correcta comprobable, porque ahí una comparación exacta es más barata, más rápida y no se equivoca. Y hay una precaución que la documentación marca como buena práctica: usar un modelo distinto del que generó la salida evaluada.
¿Cómo sé si puedo confiar en el juez?
Midiendo su concordancia con personas. El procedimiento es directo: se toma una muestra de casos, dos personas los califican con la misma rúbrica, se mide cuánto coinciden entre sí y cuánto coincide el juez con ellas. Si las personas no se ponen de acuerdo, el problema es la rúbrica y no el modelo. Si coinciden entre ellas y el juez se aparta, hay que corregir la rúbrica o el prompt del juez. Sin esta validación, un puntaje de juez es un número con apariencia de medición.
¿Qué se mide en un sistema RAG?
Dos cosas por separado, y separarlas es la mitad del diagnóstico. La recuperación responde si el fragmento que contiene la respuesta apareció entre los recuperados; se mide sin involucrar al modelo que redacta y suele ser donde está el problema. La fundamentación responde si lo que se afirmó está efectivamente respaldado por los fragmentos que recibió. Si la recuperación falla, tocar el prompt no arregla nada; si la recuperación funciona y la respuesta sigue mal, el problema está en el prompt o en el modelo.
¿La evaluación puede bloquear un despliegue?
Sí, si el umbral es determinista y está acordado antes. Una evaluación con calificación automática sobre un conjunto fijo se comporta como una suite de regresión: mismo conjunto, mismo criterio, resultado comparable. Lo que no conviene es que un modelo decida de forma discrecional si el cambio pasa, porque puede responder distinto ante la misma entrada y un control que cambia de opinión sin que cambie el código destruye la confianza en el pipeline. El puntaje contra el umbral bloquea; la opinión libre del modelo informa.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, foro. Sección Testing automatizado. Material de la comunidad sobre automatización de pruebas y criterios de calidad.
- Underc0de, foro. Sección Inteligencia artificial. Discusiones sobre modelos y sus límites.
Documentación oficial e investigación
- Anthropic. Creating strong empirical evaluations. Los tres principios de diseño, los métodos de calificación y la recomendación de usar un modelo distinto como juez, citados textualmente.
- Stanford CRFM. HELM: Holistic Evaluation of Language Models. Marco de evaluación holística de modelos fundacionales; en modo mantenimiento desde junio de 2026.
- Stanford CRFM. Documentación de HELM. Definición del marco y las dimensiones que mide más allá de la exactitud, citadas textualmente.