Evaluar IA significa medir si un modelo, sistema o producto cumple un objetivo bajo condiciones concretas. Un benchmark público responde una pregunta limitada. No demuestra por sí solo que la aplicación sea fiable, rápida, segura o útil para sus usuarios.
La primera decisión de una evaluación no es qué métrica usar. Es qué objeto se está evaluando.
OBJETO DE EVALUACIÓN
La misma respuesta puede fallar en capas distintas
Antes de elegir una métrica, fija el límite del sistema que quieres medir. Cada capa añade comportamiento y nuevos modos de fallo.
1
Modelo aisladoCapacidad base bajo una entrada controlada.
MIDEcalidad de salida
PUEDE FALLARconocimiento · razonamiento · formato
+
2
Modelo + promptEl comportamiento ya depende de instrucciones, contexto y formato.
AÑADEseguimiento de instrucciones
NUEVOS FALLOSambigüedad · contexto · sensibilidad al prompt
+
3
RAG + toolsRecuperación, selección de acciones, argumentos y estado entran en la evaluación.
Una evaluación robusta combina señales complementarias. Cada capa reduce un tipo de incertidumbre; ninguna puntuación resume por sí sola el sistema completo.
1Contratos deterministas
¿Cumple lo verificable?
schematestsestado
2Datos de referencia
¿Funciona en tu dominio?
casos realessegmentosregresiones
3Benchmarks externos
¿Dónde se sitúa la capacidad general?
comparaciónestándar
4Juez + humanos
¿La calidad abierta cumple la rúbrica?
calibraciónacuerdo
5Adversarial + seguridad
¿Qué ocurre fuera del camino feliz?
ataqueslímitesrecuperación
6Métricas online
¿Crea valor con usuarios reales?
éxitolatenciacoste
DECISIÓN
Modelo / prompt / sistema / productoLa métrica útil es la que cambia una decisión concreta sobre esa capa.
Ninguna capa sustituye a las demás. La clave es conectar cada métrica con una decisión de producto.
“Calidad” es demasiado amplio. Una evaluación necesita un contrato observable.
Para un extractor de datos:
campos obligatorios
formatos válidos
precisión y cobertura
tratamiento de ausencias
coste de un falso positivo
Para un agente con tools:
selección de la acción
argumentos correctos
orden de operaciones
idempotencia
estado final
mensaje que recibe el usuario
Para un asistente de voz:
comprensión de intención
entidades
tiempo hasta primer audio
interrupciones
éxito de tarea
cierre duplicado
La métrica debe reflejar el fallo que importa. Optimizar similitud textual cuando el problema real es ejecutar dos veces una transferencia sería medir la superficie equivocada.
Un promedio oculta dónde falla el sistema. El conjunto debe etiquetar dimensiones relevantes:
intención o tipo de tarea
dificultad
idioma y mercado
longitud y ruido
presencia de ambigüedad
necesidad de conocimiento externo
uso de tools
impacto del error
población o segmento afectado
Después se calcula rendimiento por segmento, no solo una cifra global.
Una taxonomía permite responder preguntas accionables: “¿el nuevo modelo mejora consultas largas, pero empeora nombres propios en español?” Eso ayuda a decidir. “Subió dos puntos” no.
El conjunto de datos de referencia (golden set) contiene ejemplos reales o diseñados para representar el dominio. Cada caso necesita:
entrada
contexto relevante
resultado esperado o rúbrica
etiquetas de segmento
severidad del fallo
procedencia y fecha
COBERTURA → CASOS → REGRESIONES
Un dataset de referencia útil representa fallos, no solo ejemplos
La taxonomía define qué dimensiones importan; el conjunto de referencia convierte esas dimensiones en casos reproducibles; los incidentes reales vuelven como regresiones permanentes.
01TAXONOMÍA
Define los ejes del riesgo
No empieces por acumular ejemplos. Decide primero qué variaciones debe soportar el sistema.
TAREAconsultaextraccióntool
CONTEXTOambiguoruidomercado
RIESGObajoaltoirreversible
→
02COBERTURA
Haz visibles los huecos
Ejemplo ilustrativo de una auditoría: cada celda pregunta si existe al menos un caso útil para esa combinación.
cubiertohueco
normal
ambiguo
ruido
alto impacto
consulta
●
●
●
○
extracción
●
●
○
●
tool
●
○
●
○
voz
●
●
○
●
La matriz no es una puntuación. Sirve para detectar segmentos sin evidencia antes de comparar versiones.
→
03CASO REPRODUCIBLE
Cada fila necesita un contrato
ENTRADAqué recibe el sistema
CONTEXTOevidencia disponible
ESPERADO / RÚBRICAqué cuenta como éxito
SEGMENTOSqué dimensión representa
SEVERIDADqué cuesta fallar
PROCEDENCIA + FECHAde dónde viene y cuándo aplica
INCIDENTE REALalgo falla en producción
→
REGRESIÓNse reproduce como caso
→
VERSIÓN N+1el fallo ya no se olvida
SEGMENTAreporta por grupos relevantes; el promedio global puede ocultar una regresión
VERSIONAconserva casos estables para comparar y añade fallos nuevos como regresiones
TRAZAentrada, criterio, etiquetas, severidad y procedencia deben viajar con cada caso
Debe versionarse como código. Cuando aparece un incidente, se añade un caso de regresión. Cuando cambia el producto, se actualiza la distribución y se conserva un subconjunto estable para comparar versiones.
El tamaño por sí solo no garantiza cobertura. Prioriza casos representativos y fallos críticos, y amplía el conjunto donde la incertidumbre o el riesgo lo exijan.
Un benchmark ofrece estandarización y comparación. MMLU, por ejemplo, mide respuestas de elección múltiple en numerosos dominios académicos.1 HELM propuso una evaluación más amplia y transparente mediante escenarios, métricas y documentación de limitaciones.2
Antes de usar una puntuación, pregunta:
¿la tarea se parece a la aplicación?
¿el formato favorece una capacidad concreta?
¿las respuestas son inequívocas?
¿el modelo pudo ver los datos durante el entrenamiento?
¿la métrica captura severidad o solo acierto medio?
¿hay intervalos de confianza y tamaño suficiente?
Un benchmark puede medir conocimiento académico y no decir casi nada sobre tool calling, conversación, latencia o fiabilidad operacional. El explorador de fiabilidad de benchmarks permite comprobar de forma interactiva resolución estadística, saturación, sensibilidad a ítems inválidos o potencialmente expuestos y fragilidad del ranking ante cambios de composición.
Los benchmarks públicos pueden aparecer en corpus de entrenamiento o inspirar datos muy parecidos. Cuando los laboratorios optimizan repetidamente contra una prueba estática, la puntuación deja de ser una estimación limpia de generalización.
La contaminación puede ser exacta o semántica. Detectarla es difícil si los datos de entrenamiento no son públicos.
TEST PÚBLICO → EXPOSICIÓN → PUNTUACIÓN → EVIDENCIA NUEVA
Un benchmark pierde fuerza como prueba cuando entra en el ciclo de optimización
La puntuación sigue siendo observable, pero puede mezclar capacidad con exposición al test o adaptación repetida al mismo objetivo. La defensa no es ignorar benchmarks: es renovar y separar la evidencia.
01
TEST PÚBLICO
Casos fijos y comparables
Permiten comparar versiones bajo el mismo contrato, pero su contenido puede acabar siendo conocido por el ciclo de desarrollo.
casosrespuestasleaderboard
→
02
EXPOSICIÓN
El test toca entrenamiento o tuning
Puede aparecer exacto o de forma semánticamente parecida en datos, prompts, selección de modelos o iteraciones de producto.
train datapromptingmodel selection
→
03
PUNTUACIÓN
El score ya no identifica una sola causa
Una mejora puede reflejar generalización, familiaridad con el test o adaptación al criterio. Sin evidencia adicional, esas causas no se separan.
SCORE ↑¿capacidad, exposición o ambas?
→
04
EVIDENCIA NUEVA
Renueva lo que el sistema no pudo optimizar
casos privados o posterioresrotación / evaluación dinámicadeduplicación + análisis de memorizaciónverificación ejecutable cuando existe
CONTAMINACIÓNel test entra en los datos o señales que forman el sistema
test→exposición directa / semántica→ventaja en la evaluación
La coincidencia exacta es solo un caso. Detectar contaminación semántica es más difícil, especialmente sin acceso al corpus de entrenamiento.
SATURACIÓN / SOBREOPTIMIZACIÓNel test se convierte en objetivo repetido del ciclo de desarrollo
benchmark estable→iteraciones contra el mismo score→menor información sobre casos nuevos
No exige copiar el test en entrenamiento. Reutilizar una prueba estática como objetivo de selección puede reducir su valor como evidencia independiente.
PÚBLICO ≠ LIMPIOque un benchmark sea estándar no demuestra que siga siendo independiente del entrenamiento
SCORE ≠ GENERALIZACIÓNla puntuación necesita contexto sobre exposición, fecha, protocolo y distribución
RENUEVA + VERIFICAcombina casos nuevos o privados con señales ejecutables y análisis de contaminación cuando sea posible
LiveCodeBench diseñó una evaluación de código que se actualiza con problemas recientes y usa ejecución para comprobar las soluciones.4 El principio es más general: cuando sea posible, una prueba viva y verificable resiste mejor la optimización superficial.
Una métrica determinista suele ser más barata, reproducible y auditable. La evaluación generativa debería reservarse para dimensiones que realmente requieren juicio.
SEÑAL → VERIFICADOR → DECISIÓN
Comprueba el fallo donde existe la verdad
Antes de pedir a otro modelo que juzgue una salida, pregunta si el éxito ya puede observarse directamente en la estructura, la ejecución o el estado. Solo lo que no admite un criterio determinista necesita una rúbrica.
Los humanos pueden valorar corrección, utilidad, tono, claridad o preferencia. Para que esa señal sea fiable hay que diseñar el protocolo: qué dimensión se juzga, qué ejemplos anclan la rúbrica, qué información se oculta al evaluador, dónde se duplica anotación y cómo se tratan los desacuerdos.
Una evaluación humana fiable necesita un protocolo, no solo votos
El objetivo es convertir juicios humanos en una señal auditable: definir qué se juzga, reducir pistas irrelevantes, observar el desacuerdo y conservarlo por dimensión y segmento.
01
RÚBRICA
Define la dimensión antes de mirar respuestas
correcciónutilidadclaridadtono
ejemplo +ejemplo −
Separar criterios evita que una impresión global esconda qué propiedad ganó o falló.
→
02
ASIGNACIÓN CIEGA
Mismo caso, identidad oculta y orden aleatorio
prompt + contexto
Amodelo oculto
Bmodelo oculto
El cegado reduce pistas de identidad y posición; no convierte un criterio subjetivo en verdad objetiva.
→
03
JUICIOS INDEPENDIENTES
Solapa una muestra entre evaluadores
EVALUADOR 1Apreferencia / rúbrica
EVALUADOR 2Bpreferencia / rúbrica
La doble anotación en un subconjunto permite medir acuerdo sin exigir duplicar cada caso.
→
04
DESACUERDO
El conflicto es información sobre el protocolo
criterio ambiguoerror de anotaciónpreferencia legítimamente plural
↺adjudica casos críticos y mejora rúbrica / ejemplos
→
05
EVIDENCIA
Reporta algo más útil que una media
DIMENSIÓNcorrección · utilidad…
SEGMENTOidioma · tarea · riesgo…
ACUERDOen la muestra solapada
ADJUDICACIÓNqué casos y por qué
COMPARACIÓN PAREADAReduce la carga de asignar una escala absoluta, pero solo mide la preferencia definida por la tarea
RESPUESTA Acontenido
A mejorempateB mejor
RESPUESTA Bcontenido
Chatbot Arena usa batallas anónimas y aleatorizadas para recoger preferencias pareadas. Ese diseño es útil para preferencia; no sustituye una fuente externa de verdad cuando la corrección puede verificarse.
CEGADO ≠ OBJETIVIDADocultar identidad y aleatorizar el orden reduce sesgos de presentación, no elimina la subjetividad del criterio
ACUERDO ≠ VERDADel acuerdo sirve para diagnosticar el protocolo; un criterio mal definido o un sesgo compartido puede producir consenso
PREFERENCIA ≠ CORRECCIÓNsi existe una comprobación externa, ejecútala; la fluidez o el estilo no deben sustituir evidencia factual
La preferencia tampoco equivale a verdad. Un texto más fluido puede ganar frente a otro más correcto. Cuando existe una comprobación externa, conviene usarla y reservar el juicio humano para las dimensiones que realmente lo necesitan.
Un modelo juez puede escalar evaluaciones abiertas.3 Recibe la entrada, las respuestas y una rúbrica, y produce una puntuación o comparación.
Es útil para:
filtrar regresiones
comparar muchas variantes
evaluar formato y cobertura
priorizar muestras para revisión humana
Sus riesgos incluyen:
sesgo por posición
preferencia por respuestas largas
afinidad con su propia familia
sensibilidad al prompt
errores compartidos con el modelo evaluado
Un juez necesita calibración. Se compara con un conjunto anotado por humanos, se mide acuerdo por segmento y se revisan los desacuerdos importantes. Para decisiones de alto impacto, no debería operar como autoridad única.
JUEZ AUTOMÁTICO → CALIBRACIÓN → GATE
Un LLM juez escala una rúbrica; no sustituye su validación
Antes de usarlo en volumen, compáralo con decisiones humanas sobre los mismos casos, localiza en qué segmentos discrepa y separa automatización de autoridad.
01REFERENCIA HUMANA
Mismos casos, rúbrica explícita
entradarespuesta A/Brúbricadecisión humana
La muestra de calibración fija qué significa acertar antes de medir al juez.
Una respuesta incorrecta puede venir de un documento no recuperado, un ranking malo, evidencia insuficiente, una inferencia errónea o una cita que no respalda la afirmación. Sin esa descomposición, la solución propuesta será una conjetura.
Evalúa éxito de tarea, pasos innecesarios, acciones prohibidas, reintentos, duplicados, estado final y recuperación ante errores. La trayectoria explica si el fallo está en la decisión, la ejecución o el mensaje final.
Las evals offline permiten reproducibilidad y comparación rápida. Las métricas online muestran qué ocurre con usuarios reales.
OFFLINE → HIPÓTESIS MEDIBLE → ONLINE → DECISIÓN DE PRODUCTO
Una eval offline no es el resultado del usuario
Offline te da repetibilidad y diagnóstico. Online comprueba si esas señales se traducen en comportamiento real. La conexión útil es explícita: cada proxy offline debe tener una métrica online asociada, guardrails y un criterio de rollback.
Una diferencia pequeña puede ser ruido muestral. Si comparas dos versiones sobre los mismos casos, conserva el emparejamiento por ejemplo y analiza la diferencia por caso antes de agregar. El intervalo debe acompañar al efecto estimado.
MISMO TEST → DIFERENCIAS PAREADAS → INCERTIDUMBRE → DECISIÓN
Un punto estimado no es una conclusión
Compara las versiones sobre los mismos casos, conserva la diferencia por ejemplo y reporta el efecto junto con su incertidumbre. Después separa una diferencia detectable de una diferencia que realmente compensa en producto.
1 · EMPAREJA POR CASOLa unidad útil es la diferencia del mismo ejemplo
CASOBASE ACANDIDATA BΔᵢ
i₁m₁(A)m₁(B)m₁(B) − m₁(A)
i₂m₂(A)m₂(B)m₂(B) − m₂(A)
…………
2 · AGREGA LAS DIFERENCIAS
Δᵢ = mᵢ(B) − mᵢ(A)
Δ̄ = (1/n) Σᵢ Δᵢ
El intervalo se calcula sobre la estimación que responde a tu diseño. Si A y B ven los mismos casos, no rompas ese emparejamiento al comparar.
3 · LEE MAGNITUD + INCERTIDUMBRETres resultados conceptualmente distintos
favorece A0 · sin diferenciafavorece B
ANo resuelto por la muestra
El intervalo compatible con los datos todavía cruza 0.
BDiferencia estimada, impacto pequeño
El intervalo queda a un lado de 0, pero el efecto sigue dentro del umbral práctico definido para el producto.
CDiferencia compatible con valor práctico
El efecto y su intervalo superan el umbral de mejora que justifica coste, latencia o riesgo adicional.
0±δprácticointervaloGeometría ilustrativa · no representa resultados medidos.
MUESTREO DE CASOS¿Qué habría pasado con otra muestra del dominio?
El número de casos y la cobertura por segmento determinan cuánto sabes sobre la población objetivo.
GENERACIÓN ESTOCÁSTICA¿Qué cambia si repites el mismo caso?
xᵢ→ejecución 1ejecución 2ejecución k
Si la aleatoriedad forma parte del producto, mide también la variabilidad entre ejecuciones; no la confundas con cambiar de casos.
DISEÑOmismos casos → comparación pareada; conserva Δᵢ antes de agregar
REPORTEefecto + intervalo + n + segmentos + variabilidad entre ejecuciones cuando aplique
DECISIÓNla evidencia estadística no sustituye el umbral de valor práctico del producto
En sistemas estocásticos, separa la incertidumbre debida a qué casos has muestreado de la variabilidad entre ejecuciones del mismo caso cuando esa aleatoriedad forme parte del producto. La decisión final debe combinar magnitud, incertidumbre y coste, latencia o riesgo; una diferencia estadísticamente detectable no implica por sí sola valor práctico.
Las evals offline reducen incertidumbre antes de exponer usuarios. Producción revela fallos de producto que vuelven al conjunto de evaluación como regresiones reproducibles.
OFFLINEcomparar en condiciones reproducibles
ONLINEobservar comportamiento real con exposición limitada
1SEÑAL
Incidente o necesidad
Convierte una observación en un caso reproducible.
entrada realcriterioseveridad
→
2BASELINE
Mide el sistema actual
Ejecuta la referencia antes de cambiar nada.
mismos casossegmentoscoste
→
3CAMBIO
Modelo / prompt / sistema
Formula una hipótesis y mide el delta por segmento.
variabilidadcomparaciónrevisión humana
↓
4ROLLOUT
Rollout limitado
Expón la variante con guardrails explícitos y rollback.
guardrailsrollbackcohorte
←
5PRODUCCIÓN
Observa el producto
Las métricas online muestran lo que las evals offline no pueden ver por sí solas.
éxitolatenciaincidentes
←
6REGRESIÓN
Fallo nuevo → caso permanente
Lo aprendido vuelve al conjunto de evaluación y se versiona.
reproducirversionarno olvidar
↑
↺VUELVE A SEÑAL
CIERRA EL BUCLEEl historial de fallos se convierte en tests de regresión: la siguiente versión empieza con más conocimiento que la anterior.
La evaluación no es una fase al final. Es el bucle que permite cambiar el sistema sin perder conocimiento sobre sus fallos.5
No existe uno universal. Usa benchmarks para capacidades generales y un conjunto propio para la tarea, idioma, datos, latencia y riesgo del producto.
¿Cuántos ejemplos necesita un conjunto de datos de referencia?¶
Depende de la diversidad y del tamaño de la mejora que se quiere detectar. Empieza con casos representativos y fallos críticos, mide cobertura por segmento y amplía donde la incertidumbre sea alta.
¿Se puede evaluar una respuesta abierta automáticamente?¶
Sí, mediante reglas parciales, referencias, ejecución o un juez. La automatización debe calibrarse y combinarse con revisión humana para dimensiones subjetivas o de alto impacto.
¿Una puntuación de benchmark predice la experiencia del usuario?¶
Solo si la tarea, distribución y métrica se parecen al producto. En muchos sistemas, la latencia, la recuperación, las tools y la interfaz explican más valor que una diferencia pequeña entre modelos base.
OpenAI, GPT-4 Research — OpenAI Evals, 2023. OpenAI describe Evals as a development tool for identifying shortcomings, preventing regressions and tracking performance across model versions. ↩