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

Un buen conjunto de evaluación empieza por recrear trabajo real, no por acumular prompts vistosos. Si un asistente de compras recibe una solicitud plausible con identificadores de proveedor contradictorios, una política que no puede recuperar y una cotización que intenta darle instrucciones, el caso debe permitir comprobar qué información usa, qué acción evita y cuándo pide ayuda. Para obtener evidencia útil, el equipo tiene que acotar el flujo, fijar las reglas antes de mirar resultados y conservar cada escenario como una prueba reproducible.

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

El conjunto debe cubrir el trabajo habitual en relación con las condiciones observadas y, además, incluir de forma deliberada límites importantes, fallas confirmadas y conductas prohibidas. Primero hay que definir una versión del sistema, un flujo concreto, sus actores permitidos, las entradas, el conocimiento y las herramientas disponibles, y la decisión que respaldarán los resultados. Evaluar un “asistente general” sin esos límites vuelve ambiguos tanto el éxito como la responsabilidad por una falla.

El mapa puede construirse con registros autorizados, casos de soporte, investigación con usuarios, incidentes y recorridos guiados por especialistas del proceso. Esas fuentes no son automáticamente completas ni representativas: cuando faltan registros o el sistema todavía no tiene tráfico, conviene marcar la mezcla de trabajo como hipótesis. Los datos operativos deben reutilizarse solo con la autorización aplicable, minimización de información sensible y revisión de etiquetas, mientras que los casos sintéticos necesitan validación del dominio.

En un asistente interno para solicitudes de compra, los casos ordinarios podrían cubrir paquetes completos y coherentes. Los límites relevantes incluirían documentos faltantes, importes o proveedores contradictorios, evidencia insuficiente y políticas inaccesibles. También harían falta intentos de saltear una aprobación, instrucciones incrustadas en una cotización y reproducciones minimizadas de fallas verificadas. Las reglas son ilustrativas: cada organización debe definir qué puede consultar el asistente, qué puede redactar y qué decisiones permanecen fuera de su alcance.

¿Cómo se registra un escenario para que sea reproducible?

Cada escenario debe registrarse como una ficha versionada que permita a otra persona reconstruir el estado inicial, saber qué evidencia estaba disponible y aplicar el mismo criterio de evaluación. La ficha necesita una identidad estable, responsable, familia de cobertura, tarea, segmentos, consecuencia, procedencia, autorización y pertenencia al conjunto de desarrollo o a la prueba protegida. También debe conservar el historial de cambios, porque modificar silenciosamente un archivo, una etiqueta o una rúbrica invalida comparaciones anteriores.

• Configuración: actor y objetivo, estado del flujo, solicitud, archivos, historial pertinente, instrucciones y condiciones del entorno.
• Recursos disponibles: conocimiento autorizado, permisos, herramientas, resultados devueltos y cualquier falla o demora relevante.
• Expectativas: hechos o cambios de estado requeridos, alternativas aceptables y situaciones que exigen aclarar, abstenerse, rechazar o escalar.
• Prohibiciones: respuestas, divulgaciones, llamadas a herramientas, decisiones y modificaciones de estado que no pueden ocurrir.
• Operación: evaluador, rúbrica, compuertas, solución de referencia cuando corresponda, versiones técnicas, ensayos predefinidos y ruta de arbitraje.

La respuesta esperada no debería reducir una tarea abierta a una frase ideal. Si varias formulaciones o recorridos producen el resultado correcto, hay que registrar los hechos obligatorios, el estado final y las alternativas aceptables. Una solución conocida sirve para demostrar que el caso puede resolverse y para detectar un evaluador defectuoso, no para rechazar toda variación. Cuando la aleatoriedad o los pasos sucesivos importan, la cantidad de ensayos y la regla de agregación se fijan antes de inspeccionar salidas.

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

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

Cada escenario debe usar el método más acotado que pueda distinguir válidamente el éxito de la falla. Los controles determinísticos funcionan para respuestas objetivas, esquemas, cálculos, argumentos de herramientas, estados de registros y acciones prohibidas, siempre que el control sea completo y el caso tenga solución. Una prueba precisa también puede estar equivocada: conviene verificarla con una ejecución conocida e inspeccionar si admite atajos que satisfacen la métrica sin completar el trabajo.

• Usá hechos o soluciones de referencia cuando la evidencia y el resultado estén acotados, pero existan varias redacciones o rutas válidas.
• Aplicá rúbricas por dimensión, con anclas observables, para cualidades abiertas como utilidad, integridad, fundamentación o claridad.
• Calibrá los evaluadores basados en modelos contra juicios humanos pertinentes; la coincidencia en casos de desarrollo no demuestra validez general.
• Reservá el juicio de especialistas autorizados para interpretaciones del dominio o consecuencias que los controles automáticos no puedan resolver válidamente.

El crédito parcial puede mostrar qué componentes de una tarea funcionaron, pero una divulgación prohibida o una acción sin permiso debe quedar fuera del promedio. La recomendación es tratarla como una compuerta no compensable, definida de antemano por responsables autorizados del producto y del riesgo. También deben fijarse antes de comparar salidas la versión de la rúbrica, los segmentos, la agregación de ensayos y la regla de decisión; cualquier cambio posterior inaugura otra versión de la evaluación.

¿Cómo logran los revisores aplicar criterios consistentes?

Los revisores aplican criterios con mayor consistencia cuando reciben el contexto de la tarea, anclas observables y práctica de calibración antes de calificar casos reales. La guía debe explicar el propósito del flujo, quién actúa, qué evidencia podía consultar el sistema, cuáles eran sus permisos y qué versión de la rúbrica corresponde. Cada nivel de puntuación necesita ejemplos positivos, negativos y fronterizos, además de una opción de “no se puede evaluar” para casos incompletos o defectuosos.

1. Ejecutá casos de calibración y repetilos si cambian la política, la mezcla de tareas, la rúbrica o el grupo revisor.
2. Ocultá la identidad del sistema y alterná el orden de las respuestas cuando una comparación pueda verse influida por esas señales.
3. Pedí puntuaciones y fundamentos independientes antes de abrir la discusión entre revisores.
4. Investigá el desacuerdo como señal de contexto faltante, umbral ambiguo, caso defectuoso, pluralidad legítima o decisión pendiente.
5. Nombrá a una persona responsable del arbitraje y conservá etiquetas, fundamentos, versiones y resoluciones.

El objetivo del arbitraje no es fabricar unanimidad. Si dos respuestas satisfacen legítimamente el caso, la ficha o la rúbrica debe reconocer esa pluralidad; si falta una definición del producto, el desacuerdo debe escalarse a quien pueda tomarla. Revisar las trazas, los resultados de herramientas y las notas ayuda a separar un error del sistema de una tarea imposible, un entorno roto o un evaluador mal configurado. Ese registro también permite recalibrar revisores automatizados y humanos más adelante.

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

El conjunto sigue siendo útil si separa la evidencia visible para iterar de una prueba de lanzamiento protegida y controla toda exposición. Los casos de desarrollo pueden ejecutarse con frecuencia para ajustar prompts, recuperación, herramientas, políticas y pasos del flujo; justamente porque el equipo aprende de ellos, sus resultados son evidencia de desarrollo. La prueba protegida se asigna antes de la ejecución rutinaria, se usa con moderación y no debe revelar casos, respuestas, rúbricas ni resultados para orientar cambios.

• Detectá duplicados exactos y cercanos, registros fuente compartidos, paráfrasis y casos hermanos derivados de la misma plantilla.
• Registrá quién o qué accedió al contenido de los casos, las referencias, las rúbricas y los resultados.
• Mové a regresión toda prueba protegida que haya influido materialmente en un diagnóstico o una mejora.
• Reemplazá los casos expuestos mediante una nueva versión independiente en lugar de seguir presentándolos como evidencia reservada.
• Revisá la cobertura cuando cambien usuarios, flujo, política, conocimiento, modelo, prompts, herramientas, permisos o entorno operativo.

Una falla confirmada que ya orientó la corrección pertenece al conjunto de desarrollo o regresión. La prueba protegida puede cubrir la misma clase de falla mediante otro caso creado de manera independiente, sin duplicar el registro ni la plantilla que guio el cambio. No existe un porcentaje universal para dividir los conjuntos ni una cantidad fija de casos: la composición depende de la decisión de lanzamiento, la variabilidad del flujo, los segmentos relevantes, la confiabilidad de la calificación y la evidencia autorizada disponible.

El registro maestro debería guardar responsable, procedencia, autorización, conjunto, exposición, versiones, revisión, motivo del cambio y retiro. Los resultados se informan por tarea, familia de cobertura, segmento, consecuencia y compuerta, no solamente como un promedio. Aprobar una evaluación fuera de línea aporta evidencia, pero no certifica valor de negocio, seguridad, equidad, cumplimiento ni preparación productiva. Hace falta combinarla con monitoreo, investigación con usuarios, revisión de incidentes y participación de las funciones autorizadas cuando el caso involucra decisiones reguladas o información gobernada.