Evaluation Datasets
Casos que hacen posible juzgar
Un Evaluation Dataset reúne ejemplos, tareas o casos y la información necesaria para juzgar el comportamiento de un sistema AI frente a un propósito definido. Puede contener inputs, contexto, propiedades esperadas, referencias, rúbricas, metadata, configuración de entorno, permisos y resultados de herramientas. No es simplemente una colección de prompts ni exige que cada registro tenga una única respuesta correcta.
El dataset materializa parte de la pregunta de evaluación. Si se quiere conocer si una aplicación responde con evidencia vigente, cada caso necesita condiciones que hagan visible la fuente, la fecha y el criterio de groundedness. Si se quiere evaluar un agente de coding, puede necesitar una revisión inicial, un encargo, restricciones, dependencias, tests y un estado final esperado. Un caso sin el contexto que determina su juicio puede producir un score preciso pero poco interpretable.
Evaluation Dataset y Training Dataset
Training Dataset se utiliza para ajustar o entrenar el comportamiento de un modelo. Evaluation Dataset se utiliza para medirlo o juzgarlo. La separación ayuda a reducir la posibilidad de que el sistema memorice casos o que las decisiones de diseño se adapten demasiado a las respuestas esperadas. No es una ley universal que jamás exista solapamiento: una organización puede reutilizar datos bajo controles y propósitos distintos, pero debe reconocer cómo eso limita la conclusión.
La contaminación puede ocurrir cuando el modelo vio ejemplos durante entrenamiento, cuando el prompt o workflow se ajustó repetidamente a un conjunto conocido o cuando el grader fue diseñado para favorecer sus respuestas. El problema no es solo secreto de labels: si el sistema se optimiza directamente para una suite, un score mayor puede indicar familiaridad con esa suite y no una mejora general.
La procedencia debe registrar origen, uso previsto y transformaciones. Un caso sintético generado para entrenamiento no se convierte en evidencia independiente por copiarse a la evaluación. Una fuente pública no es automáticamente desconocida para el modelo. La evaluación necesita explicar qué se sabe sobre exposición y qué incertidumbre permanece.
Desarrollo, validación y held-out evaluation
Los nombres development set, validation set, test set y evaluation set varían entre comunidades. En general, un conjunto de desarrollo o validación guía iteración, selección y ajuste. Un conjunto held-out se reserva para aportar evidencia más fuerte contra sobreajuste a los casos conocidos. La frontera útil no es una nomenclatura rígida, sino declarar qué datos influyeron decisiones y cuáles permanecieron fuera.
Una única partición tampoco resuelve toda contaminación. Si se revisa el held-out repetidamente y se cambian prompts por cada fallo, deja de comportarse como evidencia independiente. Puede ser necesario rotar casos, mantener un conjunto privado o usar una política de acceso limitada. El objetivo es preservar una diferencia entre material que guía el diseño y material que prueba una decisión.
Un conjunto de evaluación puede necesitar versiones con roles diferentes: smoke cases para feedback rápido, desarrollo para iterar, regresión para cambios recurrentes y un conjunto reservado para decisiones importantes. No existe una cantidad universal de particiones ni una obligación de llamar test a una de ellas. La organización debe documentar cómo se usó cada versión.
Representatividad sin promesas absolutas
La selección debe reflejar las tareas y condiciones relevantes para el uso. Puede incluir idiomas, usuarios, dominios, dificultad, frecuencia, rutas de herramientas, tipos de contexto, subpoblaciones, riesgo y restricciones de latencia o costo. La representatividad perfecta es normalmente imposible; una colección grande puede seguir omitiendo precisamente el caso que importa.
Una distribución promedio puede esconder una subpoblación pequeña con fallos graves. Por eso conviene conservar estratos o etiquetas que permitan desagregar resultados: idioma, producto, región, severidad, permiso, longitud, fuente, tipo de pregunta o clase de operación. La evaluación no debe permitir que muchos casos fáciles compensen silenciosamente un fallo de una categoría crítica.
La representatividad tampoco significa copiar todo el tráfico. Production Logs pueden tener sesgo de selección, datos sensibles, interacciones truncadas y casos ya filtrados por el sistema. Convertirlos en ejemplos requiere definir el objetivo, proteger la información, conservar el contexto relevante y evitar tratar la frecuencia observada como la distribución ideal. Los datos reales son una fuente posible, no un oráculo neutral.
Curación y fuentes de casos
Los casos pueden provenir de ejemplos reales desidentificados, expertos, usuarios, generación sintética, fallos históricos, incidentes, edge cases o combinaciones. Ninguna fuente es superior para todo criterio. Los casos de producción aportan realismo; los expertos pueden expresar requisitos difíciles; los sintéticos pueden ampliar cobertura; los fallos históricos recuerdan riesgos que una muestra promedio oculta.
Los casos sintéticos pueden amplificar errores, estilo o supuestos del generador. Si un modelo crea el input, la referencia y el grader, existe riesgo de que todo el circuito comparta el mismo sesgo. La curación debe revisar plausibilidad, diversidad y relación con el propósito. Un caso artificial útil no necesita fingir ser producción: debe dejar claro qué propiedad fue diseñado para probar.
Un golden set es una expresión práctica para un conjunto curado y considerado confiable por un equipo. No es un estándar universal ni una garantía de verdad. Puede contener juicios expertos, referencias revisadas y casos críticos, pero sus labels, criterios y cobertura siguen necesitando mantenimiento. «Golden» describe confianza editorial local, no infalibilidad.
Casos difíciles y de alto impacto
Un dataset compuesto solo por casos promedio puede producir un resultado tranquilizador y perder debilidades importantes. Conviene añadir casos de borde, ambigüedad, entradas adversariales, conflictos de fuentes, permisos insuficientes, contenido incompleto, tool failures, latencia, recuperación vacía y tareas que requieren abstenerse. La dificultad debe corresponder al riesgo y al objetivo, no convertirse en una colección arbitraria de trucos.
Los fallos históricos pueden convertirse en casos de evaluación o regresión cuando la propiedad que falló es reproducible y relevante. Un incidente real no siempre se traduce limpiamente en un prompt estático: puede depender de estado, timing, usuario, servicio externo o secuencia de herramientas. En ese caso el caso debe conservar el entorno o describir qué parte de la conducta puede aislarse, sin afirmar que una simplificación reproduce todo el incidente.
También conviene incluir casos positivos y negativos. Probar solo rechazos puede hacer que un sistema bloquee demasiado; probar solo ejemplos aceptables puede ocultar permisos o policy failures. Una suite útil distingue respuestas correctas, abstenciones apropiadas, errores recuperables y acciones que deben detenerse.
Metadata y contrato del caso
La metadata hace posible segmentar e interpretar resultados. Puede describir idioma, dominio, dificultad, fuente, versión, riesgo, tipo de tarea, referencia, permisos, herramientas disponibles, fecha y motivo de inclusión. No todo campo es obligatorio para todo dataset. Agregar etiquetas que nadie usa crea una apariencia de precisión y aumenta mantenimiento.
Cada caso debería expresar un contrato suficiente para su evaluación: input, condiciones, criterio, referencia o rúbrica, y cualquier efecto observable. En tareas con varias respuestas válidas, la referencia puede ser un conjunto de propiedades o una regla. En tareas de ejecución, el estado del entorno y las acciones permitidas pueden ser parte del oráculo. La ausencia de una respuesta textual no significa ausencia de criterio.
La metadata también debe evitar filtrar la respuesta al sistema evaluado. Incluir la label correcta en el prompt o mezclar instrucciones del grader con el contexto de la tarea puede invalidar el caso. La separación entre contenido que recibe el sistema y contenido que utiliza el evaluador debe ser deliberada.
La selección de casos puede combinar muestreo de uso frecuente con selección intencional de riesgos. El primero ayuda a observar el trabajo habitual; el segundo asegura que una operación rara o una excepción importante no desaparezca por su baja frecuencia. Si se combinan ambos, los resultados deben conservar la procedencia de cada grupo: un porcentaje agregado puede no representar una distribución natural y aun ser útil para un gate que pondera explícitamente los casos críticos.
Versionado y mantenimiento
Las conclusiones dependen de la versión del dataset. Añadir casos, quitar duplicados, corregir labels, cambiar una rúbrica, actualizar una fuente o modificar el entorno puede cambiar el significado de una comparación. El dataset debe conservar una identidad de versión o un registro equivalente y explicar cambios relevantes.
No es necesario congelarlo para siempre. Una suite que nunca incorpora fallos nuevos deja de representar el sistema; una suite que cambia todos sus casos en cada ejecución pierde comparabilidad. La evolución puede separar una versión histórica para comparar, una versión activa para desarrollo y una reserva para decisiones. La elección depende del propósito y debe quedar registrada.
Cambiar una referencia porque el sistema falló no es una corrección editorial neutral. Puede ser correcto si la referencia anterior era errónea y se documenta; puede ser sobreajuste si solo elimina un caso incómodo. Las revisiones de labels y rúbricas deben conservar motivo, autoría, evidencia y fecha suficiente para interpretar la serie de resultados.
La deduplicación también requiere cuidado. Dos ejemplos con redacción distinta pueden probar la misma propiedad y dar una falsa impresión de cobertura; dos ejemplos parecidos pueden diferir en una excepción decisiva. Deduplicar por similitud superficial puede quitar justamente la variación que importa. La revisión debe preguntar qué capacidad o riesgo cubre cada caso, no solo si las cadenas de texto parecen repetidas.
Leakage y contaminación
La leakage puede ocurrir si inputs, respuestas, instrucciones, rubrics o casos equivalentes fueron vistos por el modelo o por el equipo de diseño de una manera que elimina independencia. También puede aparecer cuando el workflow se ajusta específicamente al dataset o cuando el grader se sobreajusta a una distribución estrecha.
No toda similitud es contaminación. Un concepto general aprendido durante entrenamiento no invalida automáticamente una evaluación. La preocupación es si la exposición permite responder el caso sin demostrar la capacidad que se quería medir. La conclusión debe describir qué se sabe, qué se sospecha y qué controles se aplicaron, en vez de afirmar independencia perfecta sin evidencia.
Las medidas posibles incluyen casos reservados, acceso restringido, generación de variantes, rotación, comparación con casos nuevos, revisión de procedencia y separación de quienes diseñan el sistema y quienes mantienen la evidencia. Ninguna medida elimina todos los riesgos. El propósito es mejorar la fuerza de la inferencia, no prometer un dataset incorruptible.
Relación con otros objetos
Un Evaluation Dataset alimenta AI Evaluation, Automated Graders, Human Evaluation y Regression Testing, pero no es equivalente a ninguno. El dataset contiene casos y condiciones; el grader aplica un juicio; las personas pueden aportar labels; la regresión utiliza casos para detectar deterioro tras un cambio. Un mismo artefacto puede cumplir varios roles si el equipo conserva esas responsabilidades explícitas.
Un dataset de evaluación tampoco es una métrica. Tener mil casos no explica qué se considera éxito ni cómo se agregan resultados. Tampoco es un benchmark por sí solo: un benchmark añade un protocolo o comparación reutilizable. Ni es un log de observabilidad: el log describe eventos, mientras el dataset organiza evidencia para una pregunta de calidad.
Fuentes y alcance
Fuentes consultadas: OpenAI Evals, Anthropic, Demystifying evals for AI agents, y NIST AI Risk Management Framework. Se utilizan como referencias de evaluación y riesgo; este canonical no prescribe un formato de archivo, una herramienta de dataset ni una política universal de particiones.