Human Evaluation

Juicio humano estructurado

Human Evaluation es el uso sistemático de juicio humano para evaluar el comportamiento de un sistema AI frente a criterios explícitos y casos definidos. No es simplemente que una persona mire una respuesta: necesita una tarea, una muestra, una rúbrica o criterio, instrucciones suficientes, un proceso de registro y una interpretación de acuerdo, desacuerdo e incertidumbre.

Las personas pueden juzgar correctness, relevance, groundedness, utilidad, claridad, seguridad, preferencia o adecuación a una tarea. Algunas propiedades requieren conocimiento de dominio; otras dependen de experiencia de usuario o preferencia. La elección de evaluadores debe seguir el criterio que se quiere medir, no una idea universal de que experto siempre es mejor.

Human Evaluation puede aportar labels para un dataset, calibrar un Automated Grader, revisar casos inciertos, comparar respuestas o examinar fallos que una métrica no captura. Su valor no elimina variación humana, sesgos, fatiga ni necesidad de documentar condiciones.

Human Evaluation y Human in the Loop

Human in the Loop describe intervención humana dentro de un workflow operativo: aclarar, aprobar, corregir, revisar, escalar o decidir cómo continuar. Human Evaluation juzga calidad o comportamiento para producir evidencia de evaluación. Una misma persona podría participar en ambos contextos, pero la finalidad y el momento son diferentes.

Una persona que califica una respuesta no autoriza automáticamente una acción. Una persona que aprueba una transferencia no está necesariamente produciendo un label de calidad. Confundir ambos puede convertir una evaluación en una approval boundary o tratar una autorización como evidencia de que el sistema respondió bien.

Human review es un término más amplio: puede referir a aprobación, quality assurance, code review, moderación, operaciones o evaluación. Human Evaluation requiere criterios explícitos para juzgar ejemplos o ejecuciones. No toda revisión humana es evaluación, aunque sus observaciones puedan alimentar una suite.

Diseñar una rúbrica

Una rúbrica expresa qué dimensiones se juzgan, qué escala se utiliza, qué ejemplos anclan los niveles y cómo tratar ambigüedad o información faltante. Puede ser binaria, ordinal o descriptiva. Una rúbrica clara reduce interpretaciones divergentes, pero no elimina subjetividad ni convierte una propiedad abierta en una medida completamente objetiva.

Una rúbrica útil separa dimensiones que podrían confundirse. Una respuesta puede ser clara pero incorrecta, relevante pero no grounded, segura pero inútil para la tarea, o cumplir un schema y omitir una condición de negocio. Pedir una impresión global puede ser apropiado para una decisión de preferencia, pero no debe ocultar qué criterio produjo el juicio.

Las instrucciones deben declarar qué contexto puede usar el evaluador, qué significa «no se puede determinar», cómo puntuar respuestas parcialmente correctas y qué hacer cuando la referencia es incompleta o contradictoria. Los ejemplos ayudan a calibrar, pero pueden sesgar si se presentan como reglas exhaustivas. La rúbrica debe versionarse junto con el dataset y la configuración del sistema.

Casos y contexto

El evaluador necesita suficiente información para juzgar, pero no necesariamente todo el contexto interno del sistema. Mostrar una traza completa puede revelar señales que el usuario no tendría o influir artificialmente en la calificación. Ocultar evidencia relevante produce el problema opuesto. La exposición debe corresponder al criterio y documentarse.

Los casos deberían conservar input, respuesta, contexto permitido, referencia o propiedades esperadas y metadata relevante. Para tareas con herramientas puede ser necesario mostrar llamadas, resultados, estado final o intentos de acciones. Para una preferencia de estilo puede bastar una interacción resumida. No existe una cantidad universal de contexto: depende de la pregunta.

El orden y la presentación pueden afectar el juicio. En comparaciones pairwise, alternar qué respuesta aparece primero ayuda a investigar position bias. Etiquetar una salida como «del modelo nuevo» puede influir una preferencia que se quería medir como ciega. El diseño debe decidir qué información es parte del caso y qué información es una variable que se quiere ocultar.

Acuerdo entre evaluadores

Cuando varias personas juzgan los mismos casos, el acuerdo y desacuerdo aportan evidencia sobre consistencia y ambigüedad. Un desacuerdo persistente puede indicar una rúbrica incompleta, un caso mal definido, criterios en conflicto o una diferencia legítima de perspectiva. No debe convertirse automáticamente en un error de la minoría.

La mayoría puede ser útil para una decisión operativa, pero no es verdad universal. Un grupo puede compartir el mismo malentendido o carecer del conocimiento necesario. Conviene conservar distribución de labels, comentarios, abstenciones y casos con desacuerdo, en vez de guardar solo el resultado agregado. Una decisión puede necesitar adjudicación o una rúbrica revisada.

Las métricas de acuerdo deben interpretarse según escala, prevalencia y propósito. Un acuerdo alto puede ocurrir porque casi todos los casos son fáciles; un acuerdo bajo puede reflejar una propiedad genuinamente subjetiva. El número no sustituye revisar ejemplos concretos ni explica por sí solo si un grader es válido.

Cuando el desacuerdo afecta una decisión importante, una adjudicación puede pedir una segunda lectura, reunir evidencia adicional o revisar la rúbrica. La adjudicación no debe borrar el label original: conservar ambas decisiones permite analizar qué cambió y si el problema estaba en el caso o en las instrucciones. Si la disputa no puede resolverse sin inventar una regla, marcar el caso como indeterminado puede ser más honesto que forzar consenso.

Expertos y no expertos

Expertise es necesaria cuando el criterio depende de una disciplina, una política, un riesgo o una consecuencia que una persona general no puede interpretar. Los usuarios o evaluadores no expertos pueden aportar mejor señal sobre claridad, utilidad, comprensión o preferencia de una experiencia. La composición correcta depende de la pregunta.

Un experto puede sobrevalorar una solución técnicamente sofisticada que una persona usuaria no entiende. Un usuario puede preferir una respuesta convincente pero aceptar un error de dominio. Componer grupos o evaluar dimensiones separadas puede hacer visibles esas diferencias. No se debe convertir una sola población en representante automática de todos los consumidores.

La selección debe considerar idioma, contexto cultural, accesibilidad y experiencia con el tipo de tarea. Traducir una rúbrica o un caso puede cambiar su dificultad o significado. Las conclusiones deben declarar qué población evaluó y qué generalización queda fuera.

Sesgos, fatiga y seguridad del evaluador

Human judgment puede sufrir anchoring, primacy, position bias, halo effect, preference differences, rubric misunderstanding, fatiga, prisa y conocimiento incompleto del contexto. La longitud o fluidez de una respuesta puede influir aunque el criterio sea correctness. Estos riesgos no invalidan toda evaluación humana; orientan su diseño y análisis.

La carga de trabajo afecta atención y consistencia. Dividir lotes, insertar pausas, limitar longitud de sesiones, mezclar casos y revisar una muestra puede ayudar. La remuneración, la privacidad, la exposición a contenido sensible y la posibilidad de retirar un caso también forman parte de un proceso responsable. La evaluación no debe tratar el tiempo o bienestar de las personas como un recurso infinito.

El anonimato puede reducir algunos sesgos, pero no garantiza neutralidad. Ocultar la identidad del modelo no oculta necesariamente estilo, errores o idioma. Mostrar referencias puede ayudar al juicio o inducir conformidad. Cada protección tiene trade-offs que deben explicarse respecto del criterio.

El tratamiento de datos merece una frontera explícita. Casos reales pueden incluir información personal, secretos, conversaciones privadas o contenido sensible. Minimizar, desidentificar, controlar acceso y limitar retención protege a evaluadores y usuarios, pero una transformación puede quitar el contexto que el juicio necesitaba. La documentación debe registrar qué se mostró, bajo qué autorización y qué limitaciones introduce la preparación.

Escala y muestreo

Human Evaluation es costosa en tiempo y coordinación. No toda interacción necesita una revisión humana completa. Se puede muestrear, seleccionar casos de alto riesgo, revisar desacuerdos entre graders o utilizar humanos para calibrar una automatización. El plan debe declarar qué población queda fuera y qué afirmaciones no pueden sostenerse sobre ella.

Una muestra convenience puede ser rápida y sesgada. Muestrear solo respuestas que ya fueron marcadas por un filtro mide el filtro además del sistema. Muestrear por riesgo o estrato puede aumentar información sobre subgrupos raros, pero hace que el agregado no represente frecuencia natural. La ponderación y la decisión deben conservar la diferencia entre cobertura y distribución.

La automatización puede ayudar a priorizar, pero un score de un grader no debe seleccionar silenciosamente solo casos que confirma. Los humanos pueden revisar casos inciertos, extremos y una muestra aleatoria de control para estimar qué se escapa. La combinación debe documentar cómo se eligieron y cómo se interpretan los casos.

Comparación y preferencia

Una evaluación pairwise pregunta cuál de dos respuestas satisface mejor un criterio o una preferencia. Puede ser más fácil que puntuar una escala absoluta, pero solo produce una relación local y puede ser sensible al orden. Un ranking de muchas respuestas puede incorporar inconsistencias o depender de comparaciones transitivas que no se sostienen.

Una preferencia no equivale automáticamente a correctness. Personas pueden preferir una respuesta más breve, más segura o más amable aunque sea menos completa. Si la decisión necesita verdad o grounding, la rúbrica debe separar esas dimensiones o combinar preferencia con una comprobación apropiada.

Human Evaluation y Automated Graders

Human Evaluation puede calibrar un Automated Grader, aportar referencias, adjudicar casos y descubrir que una métrica observa la propiedad equivocada. Un grader puede escalar cobertura y consistencia, pero no es universalmente mejor ni reemplaza juicio humano en toda tarea. La comparación debe examinar agreement, errores por subgrupo, costo y tipo de decisión.

Un desacuerdo entre humano y grader no demuestra inmediatamente cuál está bien. Puede revelar una rúbrica ambigua, contexto distinto, un error del grader o un juicio humano defectuoso. El caso debe investigarse contra el criterio y la evidencia, no resolverse por autoridad del mecanismo.

Human Evaluation y Approval

Evaluation judgment no es authorization. Una persona puede calificar una respuesta como correcta y aun no tener autoridad para permitir una operación. Puede aprobar una acción por una política y no afirmar que el modelo produjo la mejor explicación. Agent Permissions and Approval Boundaries conserva la responsabilidad de permisos y fronteras de aprobación.

La evaluación puede revelar que una approval UX confunde revisar calidad con autorizar efectos. Separar botones, criterios y registros ayuda a saber qué decidió la persona. Un label de evaluación no debe cambiar privilegios como efecto lateral salvo que exista una política explícita que lo defina.

Fuentes y alcance

Fuentes consultadas: NIST AI Risk Management Framework, OpenAI Evals, y Anthropic, Demystifying evals for AI agents. Este canonical trata metodología de juicio humano; no prescribe un panel, una plataforma de crowdsourcing ni una política laboral universal.