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

Un conjunto útil parte de un flujo de negocio acotado y lo convierte en situaciones reproducibles, no en una carpeta de prompts vistosos. Si un asistente de solicitudes de compra recibe un formulario plausible, un identificador de proveedor contradictorio, una política inaccesible y una cotización con instrucciones dirigidas al sistema, la evaluación debe mostrar qué evidencia tenía disponible, qué podía hacer, qué debía evitar y cómo se juzgará el resultado. Sin esa estructura, un promedio atractivo puede esconder la falla que define la decisión de lanzamiento.

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

Debe cubrir el trabajo representativo y, en forma deliberada, los bordes importantes, las fallas conocidas y las conductas prohibidas. El punto de partida es una sola versión del sistema, un flujo acotado, sus actores autorizados, entradas, conocimiento, herramientas y la decisión que la evidencia ayudará a tomar. Evaluar un “asistente general” sin límites impide saber qué población de tareas representa el resultado y cuáles son sus consecuencias.

Construya el mapa desde evidencia autorizada: registros del flujo, casos de soporte, investigación con usuarios, incidentes y recorridos con especialistas del dominio. Separe familias de tareas y variaciones pertinentes, como ambigüedad, documentos ausentes, permisos, idioma, resultados de herramientas o evidencia contradictoria. Si los registros son incompletos o el sistema aún no opera, marque la mezcla ordinaria como incierta o hipotética; no invente precisión ni suponga que los datos de producción son representativos.

En el asistente de compras ilustrativo, el trabajo habitual incluye solicitudes completas y consistentes. Los bordes abarcan documentos faltantes, montos o proveedores contradictorios, hechos ausentes y recuperación de políticas no disponible. Las fallas conocidas se incorporan como reproducciones minimizadas. Las conductas prohibidas incluyen aprobar gastos, inventar reglas, revelar información confidencial o seguir instrucciones incrustadas en una cotización. Estas reglas son solo un ejemplo: cada organización debe fijar sus propios límites y responsables.

Defina antes de generar o inspeccionar salidas qué segmentos se informarán, qué conducta activa una barrera y qué decisión apoyará cada resultado. El trabajo ordinario puede muestrearse en relación con su frecuencia observada, pero los casos raros y de alta consecuencia requieren inclusión deliberada. Esta combinación de cuatro familias es una síntesis editorial adaptable, no una taxonomía universal ni una fórmula que obligue a repartir los casos por igual.

¿Cómo se registra cada escenario para poder reproducirlo?

Cada escenario debe ser un expediente capaz de recrear el estado inicial, la evidencia disponible, las acciones permitidas y la forma de juzgar el resultado. Déle una identidad estable y registre responsable, versión, historial, familia de cobertura, familia de tarea, etiquetas de segmento, consecuencia, procedencia, autorización y pertenencia al conjunto de desarrollo o a la prueba protegida. Así, un cambio posterior no borra qué se evaluó realmente.

• Configuración: actor y objetivo, estado del flujo, solicitud, archivos, historial pertinente, instrucciones y condiciones ambientales.
• Capacidades disponibles: conocimiento autorizado, permisos, herramientas, resultados de herramientas y límites del sistema durante la prueba.
• Expectativas: hechos o cambios de estado requeridos, alternativas aceptables y condiciones que exigen aclarar, abstenerse, rechazar o escalar.
• Prohibiciones: salidas, divulgaciones, llamadas a herramientas, acciones o cambios de estado que nunca deben ocurrir en ese caso.
• Operación: evaluador, rúbrica, barreras, referencia, ensayos predefinidos, regla de agregación, versiones y vía de arbitraje.

No reduzca una tarea abierta a una frase ideal. Una solución de referencia puede demostrar que el caso es resoluble y ayudar a verificar los controles, pero debe describir hechos, evidencias o estados requeridos sin invalidar otras rutas correctas. Cuando exista variabilidad entre ejecuciones, defina antes de mirar las respuestas cuántos ensayos necesita la decisión y cómo se agregarán; no hay un número universal que sirva para todos los sistemas.

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

Para el ejemplo de compras, el expediente podría contener el rol del solicitante, la carpeta recibida, el registro autorizado, la versión de la política y el resultado exacto de su recuperación. También separaría la nota aceptable de cualquier aprobación, invención o divulgación vetada. Los campos propuestos combinan prácticas respaldadas por las fuentes en una síntesis editorial; deben ajustarse a la complejidad, la gobernanza de datos y los controles de acceso de cada organización.

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

Use el método más acotado que distinga válidamente entre éxito y falla, y mantenga las acciones prohibidas fuera del puntaje compensable. Un control determinístico sirve para respuestas objetivas, esquemas, cálculos, argumentos de herramientas, estados de registros o acciones vetadas. Sin embargo, su precisión técnica no garantiza validez: hay que comprobar que el caso sea resoluble, que el control esté completo y que no premie atajos.

• Controles determinísticos para resultados, formatos, estados o prohibiciones verificables de manera objetiva.
• Hechos o soluciones de referencia cuando el resultado está acotado, pero admite varias redacciones o trayectorias válidas.
• Rúbricas por dimensiones con anclas observables para cualidades abiertas como utilidad, completitud, fundamentación o claridad.
• Juicio de especialistas calificados cuando la interpretación de dominio o las consecuencias no pueden resolverse válidamente con automatización.

La evaluación orientada al resultado suele evitar la fragilidad de exigir una trayectoria incidental. Puede otorgar crédito parcial a componentes significativos, siempre que muestre qué componente falló. En cambio, una divulgación prohibida o una acción sin autorización debe activar la barrera definida previamente por los responsables de producto y riesgo, aunque la respuesta sea clara y obtenga buena calidad en otras dimensiones. Esa lógica es una recomendación editorial, no un umbral universal.

Si se usa otro modelo para calificar respuestas abiertas, escriba una rúbrica estructurada y calíbrela contra juicios humanos pertinentes al contexto. La coincidencia en ejemplos visibles de desarrollo no vuelve objetivo al evaluador ni prueba que generalice. En GDPval, OpenAI informó que su evaluador automatizado no era suficientemente confiable para reemplazar a evaluadores ocupacionales experimentados; ese resultado aconseja cautela, pero no determina el desempeño de todos los evaluadores en cualquier tarea.

Congele la versión de la rúbrica, las barreras, los segmentos, la agregación de ensayos y la regla de decisión antes de comparar candidatos. Si el equipo modifica un criterio después de ver resultados, debe registrar una nueva versión y volver a evaluar de forma comparable. En decisiones reguladas o de alta consecuencia, la interpretación y la autoridad final deben permanecer en personas debidamente calificadas y autorizadas.

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

La consistencia mejora cuando los revisores reciben el mismo contexto, observan anclas concretas y se calibran antes de puntuar casos reales. Antes de mostrar una salida, entregue 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. Defina qué se observa en cada nivel e incluya ejemplos positivos, negativos y limítrofes, además de una opción para declarar evidencia insuficiente o un caso imposible de puntuar.

1. Ejecute casos de calibración antes de la revisión y repítalos cuando cambien la mezcla de tareas, la política, la rúbrica o el grupo revisor.
2. Oculte la identidad del sistema y alterne el orden de las salidas cuando sea práctico y la comparación pueda verse afectada por expectativas.
3. Recoja notas y fundamentos independientes antes de discutirlos, para que la conversación no borre la señal original.
4. Clasifique el desacuerdo: caso defectuoso, umbral ambiguo, contexto ausente, pluralidad legítima o decisión de producto todavía pendiente.
5. Nombre a quien arbitra y conserve etiquetas, fundamentos, versión de rúbrica, correcciones y resultado del arbitraje.

No convierta todo desacuerdo en una votación ni fuerce consenso. Dos respuestas pueden ser aceptables si el caso admite alternativas, mientras que una diferencia persistente puede mostrar que falta una definición de producto. Revise también las trazas y los resultados del evaluador cuando existan: esa inspección ayuda a separar una falla real del sistema de un caso irresoluble, una rúbrica defectuosa o un entorno inestable. El procedimiento completo es una síntesis adaptable, no un protocolo obligatorio.

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

Manténgalo útil separando los casos visibles de desarrollo de una prueba de lanzamiento protegida y registrando versiones, exposiciones y cambios. El conjunto de desarrollo puede ejecutarse repetidamente para ajustar prompts, recuperación, herramientas, políticas y el flujo. Precisamente porque el equipo conoce esos casos y optimiza contra ellos, sus resultados son evidencia de desarrollo, no una estimación independiente del desempeño de lanzamiento.

Asigne cada caso a un conjunto cuando ingrese al registro y antes de usar sus salidas para seleccionar cambios. Reserve la prueba protegida para comparaciones finales o decisiones de lanzamiento y evite que sus casos, respuestas, rúbricas o resultados orienten la iteración. La separación debe considerar duplicados exactos y cercanos, registros de origen compartidos, paráfrasis y escenarios hermanos producidos desde la misma plantilla; cambiar palabras no crea necesariamente evidencia independiente.

• Registrar responsable, procedencia, autorización, conjunto, exposición, versiones, revisiones, motivo del cambio y motivo de retiro.
• Mover a desarrollo o regresión todo caso protegido que haya influido materialmente en un diagnóstico o una corrección.
• Reponerlo con un caso versionado, independiente y no duplicado que pruebe la misma clase de falla sin revelar la instancia anterior.
• Incorporar fallas verificadas solo después de minimizar datos sensibles, confirmar el comportamiento esperado y conservar la procedencia permitida.
• Revisar cobertura cuando cambien el flujo, usuarios, política, conocimiento, modelo, prompts, herramientas, permisos o entorno operacional.

Informe resultados por familia de tarea, familia de cobertura, segmento, consecuencia y barrera, además de cualquier resumen general. No existe una cantidad universal de casos, un porcentaje de división ni un intervalo fijo de renovación: la composición depende de la decisión, la variabilidad del flujo, las consecuencias, la confiabilidad de la evaluación y la evidencia autorizada disponible. Un registro versionado permite explicar esos cambios sin presentar una colección alterada como si fuera la misma prueba.

Trate el conjunto como evidencia para decidir, no como un certificado. Aprobar una evaluación fuera de producción no demuestra por sí solo valor empresarial, seguridad, equidad, cumplimiento o preparación operacional. Los responsables de producto y riesgo deben fijar barreras y usos antes de ver resultados; especialistas del dominio deben validar realismo y resultados esperados. Cuando haya datos o juicios regulados, deben participar las funciones autorizadas correspondientes, y la evaluación debe complementarse con monitoreo, investigación con usuarios y revisión de incidentes.