AI Evaluation Fundamentals

Medir comportamiento para un propósito

AI Evaluation es la práctica de medir y juzgar sistemáticamente el comportamiento de un sistema AI frente a un propósito, un conjunto de casos y criterios explícitos. Una evaluación necesita identificar qué se observa, qué ejemplos o tareas representan el uso, qué cuenta como resultado aceptable, cómo se obtiene el juicio y cómo se interpretan sus límites para tomar una decisión.

Preguntar si un modelo «es bueno» no define una evaluación suficiente. La respuesta depende del objeto, la tarea, los usuarios, las condiciones, el riesgo y la evidencia que se considere válida. Un sistema puede producir buenas respuestas abiertas y fallar al extraer campos; puede resolver ejemplos preparados y fallar con cambios de distribución; puede tener alta calidad textual y no respetar permisos. La evaluación vuelve esas preguntas concretas y revisables.

La guía de evaluación de agentes de Anthropic describe la necesidad de tareas, criterios y graders para evaluar sistemas agentic. Es una referencia práctica, no una taxonomía universal ni una garantía de que un benchmark represente cualquier producto AI.

El objeto de evaluación

Antes de elegir una métrica hay que declarar qué se está evaluando. Puede ser un modelo, una instrucción, una configuración de prompting, un sistema de recuperación, una aplicación AI, un workflow, un agente, una integración con herramientas o un producto end-to-end. El mismo modelo puede comportarse de forma diferente cuando cambian contexto, retrieval, memoria, routing, guardrails, herramientas, interfaz o lógica de negocio.

Model Evaluation intenta aislar capacidades o comportamiento del modelo bajo condiciones controladas, cuando esa separación es posible. System Evaluation incluye los componentes que convierten una capacidad en una experiencia: datos, prompts, herramientas, permisos, recuperación, código y decisiones de negocio. Un resultado alto en un benchmark del modelo no autoriza a inferir calidad del sistema completo.

El alcance también define qué causas pueden atribuirse. Si una aplicación recupera evidencia incorrecta, una respuesta mala no es necesariamente una limitación del modelo. Si un tool devuelve estado parcial, no basta con evaluar el texto final. Registrar versión, configuración, contexto, herramientas y entorno permite interpretar el resultado sin convertir toda diferencia en un juicio sobre un único componente.

Evaluation, Verification y Testing

Generated Code Verification pregunta si un cambio concreto satisface los requisitos y restricciones de una tarea situada, mediante evidencia pertinente. Evaluation pregunta cómo se comporta un sistema entre ejemplos, tareas o ejecuciones y qué conclusiones se pueden generalizar. Una suite de evaluación puede incluir cambios de código, pero no reemplaza verificar el patch que se va a entregar.

Testing puede usar assertions deterministas contra un comportamiento especificado. AI Evaluation puede incluir esas assertions y también resultados graduados, varias respuestas aceptables, rúbricas, preferencias humanas o resultados de ejecución. No es correcto fijar la frontera absoluta «test = determinista, eval = probabilístico»: un test AI puede ser probabilístico por sus entradas, y una evaluación puede tener una condición exacta como un schema válido o un exit code.

La diferencia principal es la pregunta y la interpretación. Un test puede decir que una propiedad se sostuvo en un caso. Una evaluación reúne casos y criterios para juzgar una capacidad, comparar configuraciones, descubrir una regresión o decidir si el sistema es adecuado para un uso. Pasar una evaluación no demuestra que todos los casos futuros pasen; pasar un test no demuestra calidad general.

Evaluation y benchmark

Un benchmark es un conjunto o protocolo estandarizado o reutilizable que permite comparar sistemas bajo condiciones declaradas. Evaluation es el proceso más amplio de definir propósito, seleccionar casos, aplicar criterios, medir, analizar y decidir. Un benchmark puede formar parte de una evaluación, pero ejecutar un benchmark sin comprender su distribución ni su relación con el producto produce evidencia limitada.

Un score alto en benchmark no establece calidad de producción, corrección para todo uso, seguridad, confiabilidad, costo eficiente ni calidad del sistema completo. El resultado depende del dataset, la versión, el prompt, el grader, la contaminación posible y la correspondencia con el trabajo real. Un benchmark sirve como señal contextual; no es una certificación universal.

Criterios de evaluación

Los criterios deben seguir el uso previsto. Pueden incluir correctness, relevance, groundedness, cobertura, seguridad o política, uso de herramientas, éxito de tarea, formato, latencia o costo cuando forman parte de la decisión. No existe un conjunto universal de métricas que sea correcto para una respuesta creativa, una extracción estructurada, una operación con efectos y un agente de coding.

Para una tarea con una respuesta exacta puede bastar una comparación estructural. Para una respuesta abierta puede necesitarse una rúbrica que distinga hechos, evidencia, completitud y claridad. Para un workflow con herramientas importa también qué acciones se intentaron, qué permisos se respetaron, qué estado quedó en el entorno y si la terminación fue apropiada. La métrica debe observar la propiedad que la decisión necesita, no la señal que sea más fácil de recolectar.

Conviene distinguir éxito de tarea, calidad de salida y consecuencias. Una respuesta puede ser relevante pero no autorizada; un agente puede alcanzar el estado correcto por un camino que excede permisos; una latencia baja puede ocultar que se omitió evidencia. Los criterios pueden combinar gates críticos con puntuaciones graduales, siempre que quede claro qué condición bloquea y qué trade-off se está comparando.

Casos, ejemplos y distribución

Una evaluación necesita ejemplos, tareas o interacciones que representen la pregunta. Cada caso debería conservar suficiente contexto para saber qué se pidió, qué información estaba disponible, qué herramientas podían utilizarse y qué resultado se esperaba. La diversidad pertinente puede incluir usuarios, idiomas, dificultad, subpoblaciones, riesgos, casos límite y variación de entorno.

La representatividad perfecta es normalmente imposible. Lo importante es declarar qué distribución se intenta aproximar y qué queda fuera. Un promedio puede mejorar mientras falla una subpoblación pequeña pero crítica. Un conjunto de casos frecuentes puede ocultar una operación rara e irreversible. La evaluación debe hacer visibles esos huecos en vez de presentar una cifra agregada como descripción completa.

Las referencias pueden ser respuestas exactas, propiedades esperadas, estados de entorno, reglas, rúbricas o juicios expertos. No toda tarea tiene una única respuesta correcta. Cuando existen múltiples soluciones válidas, el evaluador debe describir las condiciones que las hacen aceptables y evitar comparar contra una redacción particular como si fuera verdad única.

Dataset de evaluación y ciclo de trabajo

Un Evaluation Dataset reúne ejemplos, tareas o casos junto con la información necesaria para juzgarlos. Puede contener entradas, contexto, propiedades esperadas, referencias, rúbricas, metadata, configuración de entorno y resultados de herramientas. No es simplemente un archivo de prompts ni necesita que cada registro tenga una respuesta exacta. La separación entre dataset de entrenamiento, desarrollo y evaluación ayuda a reducir sobreajuste y contaminación, aunque los nombres y particiones varíen entre ecosistemas.

Una práctica de evaluación suele recorrer un ciclo: definir la decisión, delimitar el objeto, construir o seleccionar casos, ejecutar el sistema, aplicar graders, analizar resultados, investigar fallos y decidir una acción. La acción puede ser comparar configuraciones, modificar el sistema, ampliar la muestra, introducir un caso de regresión o no cambiar nada porque la evidencia no alcanza. La evaluación no termina en emitir un score: también necesita conservar la interpretación y las condiciones bajo las que la decisión es válida.

Los production logs pueden aportar casos reales, pero no son automáticamente un dataset de evaluación. Pueden carecer de referencias, contener información sensible, sobrerrepresentar usuarios o reflejar decisiones ya afectadas por el sistema. Convertir una interacción en un caso evaluable requiere definir qué se juzga, proteger datos y conservar el contexto relevante. Un conjunto construido con datos reales puede ser valioso sin ser una muestra neutral de todo el uso.

Agregación e interpretación

El resultado puede expresarse por ejemplo, pass/fail, tasa, promedio, distribución, percentil, ranking o intervalo de incertidumbre cuando corresponda. La agregación resume evidencia, pero no elimina los casos que la componen. Un promedio alto puede convivir con fallos críticos; una tasa puede cambiar por composición de la muestra; un ranking puede ser inestable ante diferencias pequeñas.

Es útil conservar resultados desagregados por tarea, idioma, versión, riesgo, subgrupo y tipo de fallo. También importa distinguir ausencia de evidencia de evidencia de ausencia: pocos casos sin fallos no demuestran que un fallo no ocurra. El tamaño y la selección de la muestra, la variación entre ejecuciones y la calidad del grader limitan qué puede afirmarse.

Una decisión necesita un umbral o una comparación contextual. Puede requerir cero fallos de una clase crítica, un mínimo de éxito, una mejora relativa, una distribución aceptable o revisión adicional. No se prescribe un porcentaje universal. El umbral pertenece al propósito y al riesgo de la aplicación, no al nombre «AI evaluation».

Offline Evaluation

Offline Evaluation ocurre sobre ejemplos, tareas, snapshots, replay o entornos controlados fuera de la decisión directa de tráfico live. Permite repetir casos, comparar configuraciones con menor riesgo, detectar regresiones antes de publicar y analizar fallos con condiciones más estables. Puede usar un dataset versionado, un corpus congelado, un simulador o tareas ejecutadas en un entorno preparado.

Offline no significa automáticamente pequeño, determinista ni irrelevante. Puede incluir ejecuciones de herramientas, varias muestras, graders humanos o modelos y ambientes complejos. Su limitación es que el conjunto puede quedar obsoleto, no representar la diversidad real, omitir condiciones operativas o favorecer configuraciones ajustadas específicamente a esos casos. La repetibilidad ayuda a comparar, pero no convierte el snapshot en producción.

Una evaluación offline puede revelar que una configuración empeoró sobre casos conocidos. Todavía hace falta preguntar si esos casos son relevantes para el uso y si el cambio afecta una población no observada. El resultado es evidencia para una decisión, no una prueba de que el sistema se comportará igual fuera del entorno preparado.

Online Evaluation

Online Evaluation examina comportamiento usando tráfico, interacciones o condiciones live o production-like. Puede incluir experimentos A/B, shadow evaluation, muestreo y revisión de interacciones, feedback de usuarios, métricas de calidad o comparaciones entre rutas. No se define únicamente como A/B testing: una revisión de una muestra en un entorno real también puede aportar evaluación online.

La ventaja es observar distribución, contexto y efectos que un dataset preparado puede perder. Las limitaciones incluyen ruido, cambios simultáneos, costo, dificultad de atribución, privacidad, consentimiento, riesgo para usuarios y posibilidad de afectar estado real. Una métrica operacional no se convierte en score de calidad solo por estar disponible; necesita criterio y una relación explicada con la tarea.

Offline y online no son jerarquías. Offline favorece control, comparación y seguridad experimental; online aporta realismo y diversidad. Un programa sólido puede combinar ambos: usar offline para filtrar y comparar, online para observar condiciones reales, y devolver fallos relevantes al conjunto controlado. Online Evaluation tampoco autoriza materializar Monitoring, Evaluation in Production, Drift o MLOps como canonicals aquí; esos conceptos conservan sus futuros alcances.

No determinismo y costo

Non-Determinism recuerda que repetir una solicitud no necesariamente repite contexto, estado, versión, retrieval, scheduling o resultado. Una diferencia entre dos ejecuciones no demuestra por sí sola una regresión, y una ejecución igual no demuestra estabilidad futura. Según la tarea, puede ser útil repetir muestras, observar tasas, informar distribución o fijar condiciones; no existe una obligación universal de ejecutar cada caso varias veces.

La evaluación también tiene costo: llamadas del modelo, llamadas de graders, tiempo humano, ejecución de herramientas, ambientes y almacenamiento de evidencia. Incluir costo o latencia es apropiado cuando forma parte de la decisión, pero no se convierte aquí en una teoría de AI Economics. Reducir costo puede cambiar cobertura o confiabilidad; mejorar un score aislado puede aumentar latencia o revisión necesaria.

Evaluator validity

Un grader o protocolo mide lo que su diseño captura. La validez depende de criterios, casos, referencias, muestreo, calidad del juicio, agregación e interpretación. «Eval passed» significa que se satisfizo el procedimiento y umbral definidos bajo esas condiciones; no significa que el sistema sea universalmente bueno, seguro o correcto.

La evaluación del evaluador puede incluir análisis de errores, comparación con juicios confiables, consistencia entre ejecuciones y revisión de casos donde el score contradice una conclusión experta. Acordar con otro grader imperfecto no demuestra verdad. Un número preciso generado por una métrica mal alineada sigue siendo evidencia débil.

La instrumentación debe conservar procedencia suficiente: versión de sistema y datos, configuración, criterios, grader, ejecución y resultado. Observabilidad puede aportar señales para investigar, pero Evaluation no es Monitoring ni Observability. Agent Evaluation reutiliza estos fundamentos para juzgar sistemas agentes, y agrega contexto, instrucciones, harness, herramientas y entorno como parte del objeto.

La comparación entre versiones necesita controlar qué más cambió. Si se actualizan modelo, prompt, retrieval y grader a la vez, una mejora o caída agregada no identifica la causa. A veces una comparación conjunta es la decisión que interesa; en ese caso debe declararse como cambio de sistema, no como evidencia aislada sobre el modelo. Mantener versiones de casos, criterios y evaluadores permite reconstruir por qué dos scores no son directamente comparables.

Distinciones que deben permanecer visibles

• Evaluation mide comportamiento frente a criterios; Verification reúne evidencia para aceptar un cambio concreto.
• Evaluation y Testing pueden compartir assertions, pero tienen preguntas y agregación distintas.
• Benchmark es un protocolo o conjunto reutilizable; Evaluation incluye propósito, interpretación y decisión.
• Monitoring sigue señales operativas; Evaluation juzga calidad o comportamiento frente a criterios.
• Observability aporta evidencia para entender; una telemetría no es automáticamente un quality score.
• Model Evaluation no sustituye System Evaluation.
• Offline y Online son modos contextuales, no alternativas universalmente superiores.
• Evaluation Dataset no es Training Dataset ni Production Logs.
• Automated Grader juzga automáticamente; LLM-as-Judge es una de sus formas, no el conjunto entero.
• Human Evaluation aporta juicio estructurado; Human in the Loop interviene en un workflow operativo.
• Evaluation judgment no es Approval ni autorización.
• Regression Testing puede reutilizar datasets y criterios, pero su propósito es detectar degradación tras cambios.
• Agent Evaluation extiende el objeto a sistemas agentes; no se reduce a un benchmark del modelo.

Fuentes y alcance

Fuentes consultadas: OpenAI Evals, Anthropic, Demystifying evals for AI agents, Google Cloud, Generative AI evaluation overview, y NIST AI Risk Management Framework. Se utilizan como referencias de prácticas y riesgos, no como una taxonomía vendor-specific ni una lista universal de métricas.