Creá un conjunto de evaluación antes de lanzar una función con IA

Un conjunto de evaluación de IA debe partir de las decisiones que la función necesita resolver bien, incluso cuándo debe abstenerse de responder. Una colección de prompts vistosos no alcanza. Cada caso necesita un comportamiento esperado, la evidencia disponible y una regla para decidir si el resultado es aceptable.

Hacelo antes de que ajustar instrucciones se vuelva la actividad principal. De lo contrario, el equipo puede pasar semanas mejorando ejemplos sin acordar qué permitiría lanzar el producto.

Escribí los casos como acuerdos de producto

Un caso útil contiene solicitud, contexto autorizado, resultado esperado, conductas prohibidas, idioma y gravedad de la falla. Guardá la versión de las fuentes utilizadas. Así, un cambio posterior de contenido no convierte una respuesta anterior en un supuesto error del modelo.

En una función de consulta, separá encontrar evidencia de responder con ella. La documentación de evaluación de Amazon Bedrock distingue pruebas de recuperación, respuestas generadas y evaluación humana. Esa separación sirve aunque el producto use otra plataforma.

La respuesta esperada no tiene que ser una frase exacta. Especificá hechos obligatorios, omisiones aceptables y afirmaciones sin respaldo que causan una falla. Eso permite una redacción natural sin convertir la corrección en una preferencia personal.

Buscá los casos difíciles a propósito

Reuní ejemplos del flujo real, con autorización y sin datos sensibles innecesarios. Agregá casos construidos para fallas poco frecuentes pero graves. Conservá su origen: un caso sintético no demuestra con qué frecuencia ocurre esa situación en producción.

Incluí preguntas cortas sin contexto, fuentes contradictorias, información ausente e intentos de cruzar permisos. Para usuarios de Costa Rica y Estados Unidos, evaluá español e inglés por separado. Traducir una pregunta puede conservar el vocabulario sin representar cómo la gente nombra un proceso de trabajo.

Mantené un conjunto para desarrollo y otro reservado para decidir el lanzamiento. Ajustar el prompt repetidamente contra todos los casos disponibles convierte la evaluación en un ejercicio de memoria. Cuando una falla real pase a las pruebas de regresión, registrá por qué se agregó.

Ejemplo hipotético: un asistente de soporte

Un equipo propone 60 casos hipotéticos: 30 consultas habituales, 15 solicitudes ambiguas, 10 preguntas sin fuente disponible y 5 intentos de acceso indebido. Las cantidades ilustran una planificación; no son un tamaño de muestra recomendado ni prueban cobertura estadística.

El asistente resuelve 54 de forma aceptable. El 90% parece alentador, pero una de las fallas revela contenido restringido. Si el criterio de lanzamiento prohíbe esa exposición, el promedio no autoriza publicar.

Tipo de caso	Criterio de aceptación ilustrativo
Consulta con respaldo	Los hechos exigidos coinciden con las fuentes citadas
Información ausente	Explica qué falta sin inventar
Solicitud ambigua	Pide la distinción necesaria
Acceso indebido	El contenido restringido no llega al modelo

Repetí los casos variables y compará versiones con las mismas entradas. Una ejecución exitosa dice poco sobre una función cuyo resultado puede cambiar entre intentos.

Asigná revisión y criterios de lanzamiento

Usá verificaciones deterministas para campos estructurados y acciones prohibidas. La corrección del negocio requiere una persona que conozca el proceso. Si otro modelo califica respuestas, contrastá periódicamente sus notas con decisiones humanas: también puede tener puntos ciegos.

Empezá con casos que realmente cambiarían la decisión de lanzar y asigná un responsable a cada expectativa discutida. Llevá ese material a la planificación de software a la medida. Cuando alguien proponga cambiar el prompt, podrán comprobar qué casos resuelve y cuáles rompe.