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

Un buen conjunto de evaluación no empieza con una carpeta de prompts ingeniosos, sino con una parte acotada del trabajo que pueda reconstruirse y juzgarse. Imagine un asistente interno que recibe una solicitud de compra aparentemente completa, encuentra identificadores de proveedor contradictorios, no logra consultar la política vigente y además detecta instrucciones dirigidas al sistema dentro de una cotización. Una muestra de solicitudes sencillas puede producir una calificación brillante sin revelar si el asistente inventa una regla, oculta la falta de evidencia o rebasa la aprobación humana. La evaluación debe hacer inspeccionables esas decisiones antes de que los resultados influyan en el criterio.

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

Debe cubrir el trabajo esperado en proporción razonable a la evidencia disponible y, por separado, las condiciones poco frecuentes cuya omisión sería importante. Primero delimite la versión del sistema, los actores permitidos, las entradas, el conocimiento, las herramientas y la decisión que se evaluará. Después trace las familias de tareas y las variaciones pertinentes mediante registros autorizados, casos de soporte, investigación con usuarios, incidentes y recorridos con especialistas. Si el sistema aún no opera o la observación está incompleta, marque la mezcla como hipótesis; no convierta una estimación débil en precisión aparente.

En el asistente de solicitudes de compra, la cobertura ordinaria incluiría paquetes completos y consistentes. Las variaciones dirigidas abarcarían documentos faltantes, montos o proveedores contradictorios, evidencia insuficiente, recuperación de políticas no disponible e instrucciones incrustadas en una cotización. También habría intentos de aprobar el gasto o evadir la revisión humana, además de reproducciones minimizadas de fallas confirmadas. Estas reglas son ilustrativas y específicas de cada organización. Defina antes de ejecutar el sistema los segmentos que reportará, las barreras de conducta prohibida y el uso que tendrán los resultados.

¿Cómo debe registrarse cada escenario de evaluación?

Cada escenario debe ser un expediente reproducible que permita a otra persona reconstruir la situación, reconocer resultados válidos y detectar lo que nunca debe ocurrir. Asigne un identificador estable, responsable, historial de cambios, familia de cobertura, tarea, etiquetas de segmento, consecuencia, procedencia, autorización y división prevista. Describa al actor y su objetivo, el estado inicial, la solicitud, los archivos, el historial pertinente, el conocimiento autorizado, los permisos, las herramientas, sus resultados y las instrucciones exactas recibidas por la versión evaluada.

• Resultado requerido: hechos que deben aparecer, estado que debe alcanzarse o siguiente paso que debe identificarse.
• Variación aceptable: redacciones, rutas o respuestas alternativas que satisfacen el objetivo sin imponer una frase ideal.
• Salida prudente: condiciones que exigen pedir aclaración, abstenerse, rechazar la acción o escalarla.
• Resultado prohibido: divulgaciones, acciones, llamadas a herramientas o cambios de estado que hacen fallar una barrera.
• Operación de la prueba: calificador, rúbrica, solución de referencia, número de intentos cuando sea pertinente y regla de agregación predefinida.

Registre también las versiones del modelo, prompt, corpus de recuperación, política, herramientas, permisos y arnés de evaluación. En sistemas no deterministas o de varios pasos, fije los intentos y la forma de agregarlos antes de mirar las salidas. Una solución de referencia comprobada puede demostrar que el caso es resoluble y descubrir un calificador defectuoso, pero no debe excluir caminos legítimos. Conserve las cualificaciones de los revisores, la ruta de adjudicación, los desacuerdos pendientes y la razón para actualizar o retirar el caso.

Un caso útil no sólo plantea una pregunta difícil: reconstruye trabajo acotado y vuelve inspeccionables el éxito, la variación aceptable y la conducta prohibida.

ModelFold Editorial Team

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

Elija el método más estrecho que pueda distinguir válidamente el éxito del fracaso y mantenga las acciones prohibidas fuera del promedio de calidad. Use comprobaciones deterministas para esquemas, cálculos, argumentos de herramientas, estados verificables y acciones bloqueadas. Cuando varias formulaciones o rutas sean legítimas, compare hechos obligatorios o el estado final con una referencia. Reserve las rúbricas con anclas observables para cualidades realmente abiertas, y recurra a especialistas autorizados cuando la interpretación del dominio no pueda resolverse de manera válida mediante comprobaciones automáticas.

• Compruebe que cada regla automática sea completa y que un resultado correcto no pueda aprovechar un atajo accidental.
• Separe dimensiones como utilidad, integridad, fundamento y claridad, con ejemplos observables para cada nivel.
• Calibre los calificadores basados en modelos contra juicios humanos pertinentes y vuelva a calibrarlos cuando cambie el contexto.
• Conceda crédito parcial sólo a componentes significativos y muestre cuál falló, sin compensar acciones o divulgaciones prohibidas.

Calificar el resultado suele ser menos frágil que exigir una sola secuencia, aunque ciertos flujos sí requieren permisos, herramientas u órdenes específicos. OpenAI reportó que el calificador automatizado de GDPval no era suficientemente confiable para sustituir a especialistas ocupacionales experimentados; esto ilustra por qué la concordancia en ejemplos de desarrollo no basta para declarar válido un calificador. Fije la versión de la rúbrica, las barreras, los segmentos, la agregación de intentos y la regla de decisión antes de comparar candidatos. Cualquier ajuste posterior debe producir una nueva versión de la evaluación.

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

La consistencia mejora con una guía breve que presente el contexto antes de la salida y convierta cada criterio en observaciones concretas. Explique el propósito del flujo, el papel del usuario, la evidencia disponible, la conducta permitida, el límite del producto y la versión de la rúbrica. Incluya ejemplos positivos, negativos y fronterizos, además de una opción de evidencia insuficiente o imposibilidad de calificar cuando el expediente esté defectuoso. Ejecute casos de calibración antes de la revisión real y repítalos si cambian las tareas, la política, la rúbrica o el grupo revisor.

• Oculte la identidad del sistema y alterne el orden de las salidas cuando sea práctico en comparaciones.
• Capture primero calificaciones y razones independientes; permita la discusión sólo después de conservarlas.
• Investigue si la discrepancia procede del caso, la ancla, el contexto, una alternativa legítima o una decisión pendiente.
• Nombre a una persona responsable de adjudicar sin convertir automáticamente toda diferencia en consenso.
• Conserve etiquetas, razones, versiones de la rúbrica y resultados de la adjudicación para revisiones posteriores.

El desacuerdo es evidencia diagnóstica, no simple ruido. Puede revelar una instrucción ambigua, un umbral imposible de observar, contexto faltante o varias soluciones igualmente válidas. Revisar la traza y la calificación ayuda además a distinguir una falla del sistema de un caso, entorno o calificador defectuoso. GDPval demuestra que la revisión especializada en varias etapas, la comparación ciega y las rúbricas detalladas pueden aplicarse en una evaluación profesional, pero no establece un protocolo universal. Cada equipo debe adaptar la guía a la consecuencia y al tipo de juicio requerido.

¿Cómo conservar la utilidad del conjunto durante el desarrollo y el lanzamiento?

Mantenga un conjunto visible para desarrollar y otro protegido para aportar evidencia distinta en comparaciones finales o decisiones de lanzamiento. El primero puede ejecutarse repetidamente mientras se ajustan prompts, recuperación, herramientas, políticas y flujo; por eso sus resultados describen progreso de desarrollo, no una estimación independiente. Asigne la división cuando el caso ingrese al registro y antes de inspeccionar salidas para decidir su ubicación. Utilice el conjunto protegido con moderación y evite que sus casos, respuestas, rúbricas o resultados orienten la iteración cotidiana.

• Busque duplicados exactos, coincidencias cercanas, registros fuente compartidos, paráfrasis y escenarios hermanos producidos por la misma plantilla.
• Controle el acceso al contenido de los casos, las respuestas de referencia, las rúbricas y los resultados protegidos.
• Coloque las fallas que ya orientaron el diagnóstico o la corrección en desarrollo o regresión.
• Cubra la misma clase de falla en la prueba protegida sólo con casos independientes que no hayan guiado el cambio.
• Si un caso protegido influye materialmente en una modificación, reclasifíquelo y cree un reemplazo versionado.

El registro del conjunto debe conservar responsable, procedencia, autorización, división, exposición, versiones, historial de revisión, motivo del cambio y motivo de retiro. Añada fallas operativas sólo después de confirmar el comportamiento esperado, minimizar información sensible y contar con autorización aplicable; los registros de producción no son automáticamente completos, representativos ni reutilizables. Reevalúe la cobertura cuando cambien el flujo, las personas usuarias, la política, el conocimiento, el modelo, los prompts, las herramientas, los permisos o el entorno. No existe una cantidad universal de casos, una proporción fija entre conjuntos ni un calendario válido para todos.

Reporte resultados por familia de tarea, familia de cobertura, segmento, consecuencia y barrera, además de cualquier resumen general. Una aprobación fuera de línea es sólo una fuente de evidencia: no demuestra por sí sola valor empresarial, seguridad, equidad, cumplimiento ni preparación para producción. Los responsables de producto y riesgo deben definir de antemano las barreras y el uso de los resultados; especialistas de dominio deben validar el realismo y los resultados esperados. Cuando intervengan decisiones legales, médicas, financieras, laborales, de seguridad, privacidad u otras reguladas, mantenga el juicio en personas debidamente cualificadas y autorizadas, y complemente la prueba con monitoreo, investigación con usuarios e incidentes.