Cómo crear un conjunto de evaluación por escenarios para un sistema de IA empresarial

Un conjunto de evaluación útil empieza por un flujo de trabajo acotado, no por una colección de preguntas ingeniosas. Hay que fijar qué versión del sistema se prueba, quién puede usarla, qué información y herramientas tiene disponibles y qué decisión respaldarán los resultados. Después se representan las tareas habituales y se agregan de forma deliberada los bordes importantes, las fallas verificadas y las conductas prohibidas. Así, una cifra agregada no oculta que el sistema resolvió pedidos sencillos pero falló precisamente donde debía pedir evidencia, abstenerse o respetar una autorización.

¿Qué debe cubrir un conjunto de evaluación basado en escenarios?

Debe cubrir el trabajo corriente en relación con el uso esperado y, además, condiciones poco frecuentes que puedan cambiar la decisión o sus consecuencias. Primero delimitá una versión del sistema y un flujo: actores permitidos, entradas, conocimiento, herramientas y acciones disponibles. Recién entonces armá un mapa de familias de tareas y variaciones relevantes con registros autorizados, consultas de soporte, investigación con usuarios, incidentes y recorridos con especialistas del dominio. Si la evidencia operativa es incompleta o todavía no existe, registrá esa incertidumbre en vez de presentar una distribución hipotética como observada.

Una síntesis práctica organiza la cobertura en cuatro familias. No es una taxonomía universal ni exige cantidades iguales. El trabajo representativo sigue, con cautela, la mezcla observada; las otras familias se incorporan intencionalmente para que la frecuencia no excluya una condición rara pero decisiva. Conviene fijar también los segmentos que se informarán, las conductas que activan una barrera y el uso previsto del resultado antes de generar salidas. Probar ambos lados de cada límite evita premiar tanto la acción indiscriminada como el rechazo automático.

En un asistente interno para solicitudes de compra, por ejemplo, los casos ordinarios pueden incluir un pedido completo y coherente. Los bordes abarcan documentos faltantes, identificadores de proveedor en conflicto, evidencia insuficiente o una política que no se puede recuperar. Las familias dirigidas incluyen instrucciones incrustadas en una cotización, pedidos de saltear una aprobación y reproducciones minimizadas de fallas confirmadas. Las reglas son ilustrativas: cada organización debe definir quién autoriza, qué datos pueden reutilizarse y qué acciones están vedadas.

¿Cómo se debe registrar cada escenario de evaluación?

Cada escenario debe ser un registro reproducible que permita a otra persona reconstruir la situación, reconocer alternativas válidas y detectar un resultado prohibido. Asignale un identificador estable, responsable, historial de versiones, familia de cobertura, familia de tarea, etiquetas de segmento, consecuencia, procedencia, constancia de autorización y conjunto previsto. La procedencia puede indicar que el caso nació de un incidente o de material sintético sin exponer contenido confidencial. La identidad estable permite corregir una etiqueta o retirar un caso sin reescribir silenciosamente la evidencia anterior.

• Configuración: actor y objetivo, estado inicial del flujo, solicitud, archivos, historial relevante, instrucciones y condiciones del entorno.
• Recursos disponibles: conocimiento autorizado, permisos, herramientas y resultados que el sistema verá durante la prueba.
• Expectativas: hechos o cambios requeridos, caminos alternativos aceptables y situaciones que exigen aclarar, abstenerse, rechazar o escalar.
• Controles: salidas, divulgaciones, llamadas a herramientas y cambios de estado prohibidos, separados de los criterios generales de calidad.
• Operación: evaluador, rúbrica, barreras, solución de referencia si corresponde, cantidad de intentos predefinida, agregación, versiones y vía de arbitraje.

Una solución de referencia conocida sirve para demostrar que un caso acotado se puede resolver y para revisar el evaluador; no debe convertirse automáticamente en la única redacción aceptada. Esto importa en tareas abiertas, donde varias explicaciones o trayectorias pueden ser correctas. Si el sistema es no determinista o realiza varios pasos, definí antes de observar salidas cuántos intentos requiere el caso y cómo se agregan. Guardá además las versiones del modelo, instrucciones, corpus de recuperación, herramientas, permisos, política y arnés, porque cualquiera de ellas puede cambiar el resultado.

Un buen caso no solo plantea una dificultad: reconstruye trabajo acotado y vuelve inspeccionables el éxito, la variación aceptable y la conducta prohibida.

¿Cómo puntuar cada escenario sin premiar la conducta equivocada?

Usá el método más estrecho que pueda distinguir válidamente el éxito del fracaso. Un control determinista corresponde cuando el resultado tiene un valor, esquema, cálculo, argumento de herramienta, estado de registro o acción prohibida que pueda verificarse objetivamente. Aun así, un control preciso puede estar incompleto o aceptar un atajo no deseado, por lo que conviene comprobar que el caso sea resoluble e inspeccionar las fallas. Cuando importan el resultado y las restricciones materiales, exigir una trayectoria incidental o una frase exacta vuelve la evaluación innecesariamente frágil.

• Usá hechos o una solución de referencia cuando el resultado esté acotado pero admita distintas formulaciones o rutas.
• Aplicá dimensiones separadas y anclas observables para cualidades abiertas como utilidad, integridad o fundamentación.
• Calibrá cualquier evaluador basado en modelos contra juicios humanos pertinentes; coincidencia en los casos de desarrollo no prueba validez general.
• Reservá el juicio experto para interpretaciones que los controles automáticos no puedan resolver válidamente y mantené las decisiones reguladas en roles autorizados.

El crédito parcial puede mostrar qué componentes útiles completó el sistema, pero no debe compensar una divulgación o acción expresamente prohibida. Tratá esa conducta como una barrera separada, definida antes de comparar candidatos por responsables de producto y riesgo con autoridad sobre la consecuencia. Fijá también la versión de la rúbrica, los segmentos, la lógica de barreras, la agregación de intentos y la regla de decisión. Si después cambian, registrá una nueva versión. OpenAI informó, además, que el evaluador automatizado de GDPval no alcanzaba para sustituir a sus evaluadores ocupacionales experimentados; ese resultado aconseja calibrar, no generalizar.

¿Cómo lograr que los revisores apliquen los criterios de manera consistente?

Los revisores necesitan una guía breve, observable y calibrada antes de puntuar casos reales. Presentales el propósito del flujo, el actor, la evidencia disponible, la conducta permitida, el límite del producto y la versión de la rúbrica antes de mostrar una salida. Para cada nivel de puntuación, describí señales que puedan observarse y aportá ejemplos positivos, negativos y fronterizos. Incluí una opción de evidencia insuficiente o no evaluable: obligar a puntuar un caso defectuoso introduce una certeza que el material no permite.

• Ejecutá casos de calibración antes de la revisión y repetilos si cambian la rúbrica, la política, las tareas o el grupo revisor.
• Ocultá la identidad del sistema y alterná el orden de las salidas cuando sea práctico y la comparación lo justifique.
• Recogé puntuaciones y fundamentos independientes antes de la discusión para no borrar el desacuerdo inicial.
• Investigá si una diferencia señala un caso defectuoso, un umbral ambiguo, contexto faltante, pluralidad legítima o una decisión pendiente.
• Nombrá a quien arbitra y conservá etiquetas, fundamentos, versiones y resoluciones para futuras revisiones y recalibraciones.

El desacuerdo no es únicamente ruido: puede mostrar que la rúbrica mezcla dimensiones, que falta evidencia o que el producto todavía no decidió qué alternativa aceptar. No fuerces consenso si varias respuestas son legítimas. Separá la corrección técnica de un caso de una decisión de política o producto que requiere otro responsable. Revisar trazas y calificaciones también ayuda a identificar si falló el sistema, el evaluador o el entorno. GDPval demuestra que la revisión experta en etapas, la comparación ciega y las rúbricas detalladas son viables, pero no establece un protocolo universal.

¿Cómo mantener útil el conjunto durante el desarrollo y la liberación?

Mantené un conjunto visible para iterar y una prueba protegida para obtener evidencia distinta en la liberación. El primero puede ejecutarse repetidamente mientras se ajustan instrucciones, recuperación, herramientas, políticas y flujo; por eso sus resultados describen desarrollo, no una estimación independiente. Asigná la pertenencia de cada caso al registrarlo y antes de que sus salidas influyan en la selección. La prueba protegida debe usarse con moderación, y sus casos, respuestas, rúbricas y resultados no deberían orientar la iteración cotidiana.

La separación nominal no alcanza. Buscá duplicados exactos y cercanos, registros fuente compartidos, paráfrasis y casos hermanos creados desde la misma plantilla. Registrá quién o qué accedió al contenido, las referencias, las rúbricas y los resultados. Una falla que ya sirvió para diagnosticar o corregir pertenece al material de desarrollo o regresión. La prueba protegida puede cubrir la misma clase de falla solo mediante un caso independiente y no duplicado. Si un caso protegido modifica materialmente el sistema, trasladalo y agregá un reemplazo versionado.

• Registrá responsable, procedencia, autorización, conjunto, exposición, versiones, última revisión y motivo de cada cambio o retiro.
• Incorporá fallas verificadas después de minimizar datos sensibles y confirmar cuál era la conducta esperada.
• Revisá la cobertura cuando cambien usuarios, flujo, política, conocimiento, modelo, instrucciones, herramientas, permisos o entorno.
• Informá resultados por familia de tarea, familia de cobertura, segmento, consecuencia y barrera, además de cualquier resumen.
• Auditá referencias vencidas, etiquetas erróneas, casos ambiguos, estados inalcanzables y evaluadores que rechacen alternativas válidas.

No hay un porcentaje de división, intervalo de renovación ni cantidad de casos que sirva para todos los sistemas. El tamaño depende de la decisión de liberación, la variabilidad del flujo, los segmentos relevantes, las consecuencias, la confiabilidad del método de evaluación y la evidencia autorizada disponible. El conjunto es evidencia para decidir, no un certificado. Una aprobación fuera de producción no demuestra por sí sola valor comercial, seguridad, equidad, cumplimiento ni preparación operativa; combiná sus resultados con monitoreo, investigación con usuarios, revisión de incidentes y las funciones calificadas que correspondan al material o la decisión.