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 preguntas ingeniosas, sino con un flujo de trabajo acotado y una decisión concreta. Pensemos en un asistente interno que recibe una solicitud de compra aparentemente correcta, detecta identificadores de proveedor contradictorios, no puede recuperar la política vigente y encuentra instrucciones dirigidas a la IA dentro de un presupuesto adjunto. Un puñado de ejemplos pulidos difícilmente revelará si el sistema resuelve bien esa combinación sin exceder sus permisos.

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

Debe cubrir el trabajo habitual en relación con las condiciones observadas y, además, incorporar de forma deliberada límites importantes, fallos conocidos y conductas prohibidas. Esta combinación evita que la frecuencia sea el único criterio de selección. Es una síntesis editorial adaptable, no una taxonomía impuesta por una sola fuente, y tampoco presupone que las cuatro familias deban contener el mismo número de casos.

Antes de recopilar ejemplos, fija una versión del sistema, un único flujo, los actores y entradas permitidos, el conocimiento y las herramientas disponibles y la decisión que respaldará la evaluación. Después, dibuja las familias de tareas y las variaciones relevantes mediante registros autorizados, incidencias, consultas de soporte, investigación con usuarios y recorridos con especialistas del dominio. Si la evidencia operativa es incompleta o todavía no existe, señala la incertidumbre en vez de inventar una distribución precisa.

En el asistente de solicitudes de compra, el mapa podría incluir expedientes completos, documentos ausentes, importes o identificadores contradictorios, hechos que no aparecen en las pruebas autorizadas, intentos de saltarse la aprobación humana, instrucciones incrustadas en un presupuesto y una recuperación de política no disponible o incoherente. Estas reglas son meramente ilustrativas y dependen de cada organización. Los segmentos, las puertas de conducta prohibida y el uso previsto del resultado deben quedar definidos antes de inspeccionar las respuestas.

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

Cada escenario debe registrarse como una ficha reproducible que permita a otra persona reconstruir la situación, reconocer resultados válidos y detectar cualquier acción prohibida. La ficha ha de identificar el caso, su responsable, historial, familia de cobertura, tarea, segmentos, consecuencia, procedencia, autorización y pertenencia al conjunto de desarrollo o a la prueba protegida. Esta estructura es un modelo editorial que debe ajustarse al sistema y a su gobierno de datos.

• Preparación: actor y objetivo, estado inicial, solicitud, archivos, historial pertinente, condiciones ambientales e instrucciones del sistema.
• Recursos: conocimiento autorizado, permisos, herramientas disponibles y resultados concretos que devolverán durante la prueba.
• Expectativas: hechos o cambios necesarios, alternativas aceptables y situaciones que exigen aclarar, abstenerse, rechazar o escalar.
• Control: salidas, divulgaciones, llamadas y cambios de estado prohibidos; evaluador, rúbrica, puertas, referencia y versiones técnicas y normativas.

No reduzcas una tarea abierta a una redacción ideal. Una solución de referencia puede demostrar que el caso es resoluble y ayudar a comprobar el evaluador, pero no debe invalidar otros recorridos correctos. Si la variabilidad del sistema o su ejecución en varios pasos puede alterar el resultado, declara previamente cuántos intentos se harán y cómo se agregarán. Registra también la cualificación de los revisores, la vía de arbitraje y las versiones del modelo, instrucciones, corpus, herramientas, política y banco de pruebas.

Un caso útil no plantea solo una pregunta difícil: recrea un trabajo acotado y hace inspeccionables el éxito, la variación aceptable y la conducta prohibida.

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

La puntuación debe emplear el método más estrecho que distinga válidamente éxito y fracaso. Comprueba de forma determinista respuestas objetivas, esquemas, cálculos, argumentos de herramientas, estados y acciones vetadas. Recurre a hechos o soluciones de referencia cuando el resultado esté acotado pero admita varias formulaciones. Reserva las rúbricas por dimensiones para cualidades realmente abiertas y el juicio experto para interpretaciones que una comprobación automática no pueda resolver de manera válida.

• Comprobación determinista: precisa para resultados observables, pero también debe revisarse por si es incompleta o admite atajos.
• Referencia acotada: enumera hechos o estados necesarios sin imponer una única redacción o ruta.
• Rúbrica anclada: separa dimensiones y describe señales observables para cada nivel de calidad.
• Juicio experto: aporta interpretación del dominio y mantiene las decisiones reguladas en manos cualificadas y autorizadas.

El crédito parcial puede mostrar qué componentes funcionaron, pero una divulgación o acción expresamente prohibida debe permanecer fuera de cualquier promedio compensable. Los responsables autorizados de producto y riesgo han de definir esa puerta y su consecuencia antes de comparar candidatos. También deben congelarse la versión de la rúbrica, los segmentos, la agregación de intentos y la regla de decisión. Un evaluador basado en modelos no se vuelve suficiente por coincidir con ejemplos de desarrollo: en GDPval, OpenAI concluyó que el suyo no sustituía a profesionales experimentados.

¿Cómo conseguir que los revisores apliquen los criterios con coherencia?

Los revisores necesitan una guía breve que presente el propósito del flujo, el actor, las pruebas disponibles, la conducta permitida, el límite del producto y la versión de la rúbrica antes de mostrarles una salida. Cada punto de la escala debe apoyarse en señales observables, con ejemplos positivos, negativos y fronterizos. Añade una opción de «pruebas insuficientes» o «no evaluable» para impedir que un caso defectuoso se convierta artificialmente en un fallo del sistema.

1. Calibrar con casos comunes antes de revisar resultados reales.
2. Repetir la calibración cuando cambien la tarea, la política, la rúbrica o el grupo revisor.
3. Ocultar la identidad del sistema y variar el orden de las respuestas cuando sea viable.
4. Recoger puntuaciones y motivos independientes antes de abrir la discusión.
5. Asignar una persona responsable del arbitraje y conservar tanto el desacuerdo como su resolución.

El desacuerdo no es ruido que deba eliminarse a cualquier precio. Puede descubrir un umbral ambiguo, contexto ausente, un caso imposible, varias respuestas legítimas o una decisión de producto aún pendiente. La revisión de notas, trazas y razonamientos ayuda a separar esos problemas de un fallo real del sistema. Conserva las etiquetas originales, las justificaciones, la versión de la rúbrica y el resultado del arbitraje para revisar decisiones posteriores y recalibrar evaluadores automatizados sin reescribir el historial.

¿Cómo mantener útil el conjunto durante el desarrollo y el lanzamiento?

El conjunto debe separar los casos visibles de desarrollo de una prueba de lanzamiento protegida y gestionar ambos mediante versiones, control de exposición y un registro común. El primer grupo puede ejecutarse repetidamente para mejorar instrucciones, recuperación, herramientas, políticas y el propio flujo. Precisamente porque el equipo conoce esos casos y optimiza contra ellos, sus resultados describen el desarrollo, no una estimación independiente del lanzamiento.

Asigna cada caso a un grupo cuando entra en el registro, antes de su ejecución rutinaria o de inspeccionar respuestas para tomar decisiones de selección. Utiliza la prueba protegida con moderación para comparaciones finales y evita que sus casos exactos, respuestas, rúbricas o resultados orienten la iteración. No existe un porcentaje universal: la composición depende de la decisión, la variabilidad del flujo, los segmentos relevantes, las consecuencias y las pruebas autorizadas disponibles.

Busca duplicados exactos y aproximados, registros de origen compartidos, paráfrasis y escenarios hermanos creados con una misma plantilla. Un fallo confirmado que ya sirvió para diagnosticar o corregir el sistema pertenece al conjunto de desarrollo o regresión. La prueba protegida puede examinar la misma clase de problema mediante un caso creado de forma independiente y no duplicado. Si un caso protegido influye materialmente en un cambio, reclasifícalo y añade un sustituto versionado.

• Registrar responsable, procedencia, autorización, reparto, exposición, versiones, historial de revisión y motivos de cambio o retirada.
• Añadir fallos verificados solo después de minimizar material sensible y confirmar el comportamiento esperado.
• Revisar la cobertura cuando cambien usuarios, flujo, política, conocimiento, modelo, instrucciones, herramientas, permisos o entorno.
• Informar por tarea, familia de cobertura, segmento, consecuencia y puerta, además de cualquier resumen agregado.

Trata el conjunto como evidencia para una decisión, no como un certificado. Un aprobado sin conexión no demuestra por sí solo valor empresarial, seguridad, equidad, cumplimiento ni preparación para producción. Los especialistas del dominio deben validar el realismo y los resultados esperados; privacidad, seguridad, asesoría jurídica, cumplimiento y otras funciones cualificadas deben intervenir cuando sus materias estén implicadas. Mantén las decisiones legales, médicas, financieras, laborales y demás juicios regulados en manos autorizadas, y combina la evaluación con seguimiento, investigación de usuarios e incidentes.