Cómo preparar casos de prueba sintéticos

Define el propósito del conjunto

Un caso sintético es un ejemplo construido deliberadamente. Permite controlar la entrada, conocer la salida esperada y compartir una reproducción sin incluir datos de clientes. Su valor depende de la pregunta que pone a prueba. Cambiar nombres en cien mensajes casi idénticos no produce necesariamente cien desafíos diferentes.

Puedes empezar con quince casos sintéticos descargables, cinco por tarea. Cada caso indica su tarea, procedencia y resultado esperado. No son conversaciones observadas, resultados de usuarios ni un benchmark ejecutado. Son semillas para comprobar que un futuro ejecutor y su rúbrica funcionan.

Anota también lo que el conjunto no cubre: adjuntos, idiomas distintos del español, volumen real, permisos heterogéneos o fallos de infraestructura, por ejemplo. La ausencia de esos casos limita la conclusión incluso si todas las semillas se resolvieran bien.

Construye una matriz de comportamientos

Empieza por familias que correspondan a decisiones del proceso. Para cada una, escribe una entrada, el comportamiento esperado y el error que revelaría un fallo. Usa tanto casos que deben resolverse como casos donde el comportamiento correcto es abstenerse.

Para campañas, siembra errores de un requisito cada vez y después combinaciones. Incluye piezas sin fallos para observar falsas alarmas. Para procedimientos, utiliza preguntas respondibles, otras fuera del corpus y documentos que se contradigan. No obligues a que toda entrada produzca una respuesta afirmativa.

Escribe la salida esperada antes de ejecutar

Un resultado esperado puede tener varios niveles: campos exactos, propiedades obligatorias y una rúbrica de significado. JSON Schema ayuda a definir la estructura, pero una comprobación semántica necesita criterios adicionales. «Respuesta buena» es demasiado impreciso para que dos revisores decidan de forma comparable.

Ejemplo sintético del diseño de un caso:

{
  "id": "SYN-PROC-003",
  "family": "sin_evidencia",
  "input": "¿Cuál es el presupuesto autorizado para viajes?",
  "corpus": "El documento solo explica cómo solicitar acceso al CRM.",
  "expected": {
    "abstained": true,
    "reason": "El corpus no contiene la política solicitada"
  }
}

La abstención no debe inventar una cifra ni enlazar un documento inexistente. Si varias formulaciones son aceptables, describe sus propiedades en lugar de exigir una cadena literal. Revisa las etiquetas esperadas: una etiqueta errónea puede penalizar una salida correcta o premiar un comportamiento indeseable.

Separa desarrollo, evaluación y revisión

Mantén un conjunto de desarrollo para ajustar el flujo, otro reservado para evaluar y un historial de casos problemáticos. No expongas todos los casos al proceso de ajuste y presentes después el porcentaje como una medida independiente. La documentación de evaluaciones de Anthropic ofrece contexto sobre diseño de tareas y verificadores; la partición concreta depende del experimento.

Si el conjunto es tan pequeño que no permite separar bien, dilo y úsalo como prueba de funcionamiento del protocolo. Puedes construir nuevas variantes después de congelar la configuración para buscar errores no utilizados durante el ajuste. Evita afirmar representatividad estadística a partir de esta selección deliberada.

Una persona debe revisar los casos antes de medir, especialmente los ambiguos y adversos. Conserva desacuerdos y razones de cambio. Si corriges una etiqueta tras una ejecución, identifica la nueva versión del corpus y qué resultados necesitan recalcularse.

Conserva procedencia y versiones

Guarda un ID estable por caso, fecha de creación, autoría del conjunto, propósito y estado de revisión. El archivo descargable distingue expected de resultados: no incluye una columna que aparente haber sido medida. Una ejecución futura debe escribir sus observaciones en otro artefacto vinculado por ID.

Calcula una huella del archivo exacto utilizado y conserva la versión del prompt, modelo, esquema y ejecutor. La documentación del proyecto propone SHA-256 para enlazar corpus y registro de ejecución. Si cambia una coma relevante del contenido, la huella permite reconocer que no se usó el mismo archivo.

Trata cualquier instrucción dentro del mensaje o documento como parte del caso. No ejecutes su contenido, no lo conviertas en un comando y no permitas que determine rutas de escritura o herramientas. El caso adverso comprueba precisamente si esa separación se mantiene.

Qué podrás concluir después de ejecutar

Cuenta aciertos, fallos, abstenciones y correcciones por familia, mostrando denominadores. No conviertas las repeticiones de un caso en nuevas solicitudes independientes. Si un patrón falla, añade una reproducción mínima que permita investigar por qué y conserva también un caso cercano que funcione.

Un conjunto sintético puede demostrar que una versión concreta falla ante una entrada concreta. Que no se observe un fallo no prueba que el flujo sea fiable en todas las circunstancias. El siguiente paso será ampliar cobertura con ejemplos autorizados y saneados del proceso objetivo, revisar la rúbrica y repetir la comparación. Estos ejemplos te permiten preparar esa primera comparación.