Una batería de casos que protege tu IA en cada cambio

Cambias una frase del prompt para arreglar un caso que se quejó un cliente. Lo pruebas, funciona, lo subes. Tres semanas después descubres que ese cambio rompió otros seis casos que nadie volvió a mirar. Nadie se enteró porque los sistemas de IA no se rompen con un error: siguen respondiendo, solo que peor.

Contra eso solo hay una defensa, y es la misma que en cualquier software serio: un conjunto de casos con la respuesta correcta anotada que se ejecuta entero ante cada cambio. La diferencia es que aquí la respuesta correcta no es un valor exacto, y eso desanima a mucha gente antes de empezar. No debería.

Qué casos escribir

El error más común es llenar la batería de casos fáciles, los que el sistema ya hace bien. Quedan bonitos en el informe y no protegen de nada. Una batería útil se construye con cinco tipos:

• Los del día a día. Los diez o quince escenarios que representan el 80% del uso real. Si uno de estos se rompe, es un incendio.
• Los límite. Preguntas incompletas, ambiguas, con dos intenciones a la vez, o formuladas como habla la gente y no como escribe la documentación.
• Los que deben fallar. Casos donde la respuesta correcta es no responder: fuera de alcance, sin datos suficientes, o pidiendo algo que el sistema no debe hacer. Se evalúa la abstención, y casi nadie la evalúa.
• Los adversariales. Escritos para romperlo: negaciones ("no tengo fiebre" convertido en fiebre), inyecciones de instrucciones, contradicciones entre lo que el usuario dijo antes y después.
• Los que ya fallaron. Cada vez que alguien reporta un problema, ese caso entra en la batería antes de arreglarlo. Así no vuelve nunca.

Esa última regla es la que hace que la batería crezca sola y en la dirección correcta. La nuestra llegó a casi 300 casos clínicos sin que nadie se sentara a inventarlos: los fue trayendo la realidad.

Cómo se puntúa cuando no hay respuesta exacta

Aquí está el nudo. No puedes comparar la salida palabra por palabra, porque el modelo dirá lo mismo de otra forma. Lo que sí puedes es evaluar propiedades verificables, que en la práctica cubren casi todo:

• Contiene o no contiene. ¿Aparece el concepto clave? ¿Aparece algo que no debería aparecer nunca?
• Decisión estructurada. Si tu sistema clasifica, prioriza o extrae campos, compara el campo, no el texto. Es la parte más fácil y la más valiosa.
• Fuente citada. ¿La afirmación se apoya en un fragmento que se recuperó de verdad? Esto caza alucinaciones sin necesidad de juzgar el estilo.
• Abstención correcta. ¿Se calló cuando debía callarse? Binario y muy revelador.
• Un modelo como juez, con cuidado. Para lo cualitativo puedes usar otro modelo que puntúe, pero solo si antes has comprobado que ese juez coincide con humanos en una muestra. Si no, has añadido una segunda cosa que no mides.

Mi regla práctica: si un caso solo se puede evaluar con opinión, probablemente esté mal formulado. Reescríbelo hasta que tenga una propiedad comprobable.

El error que la vuelve inútil

Este me pasó a mí y me costó semanas de falsa tranquilidad. Teníamos una batería de casos que pasaba en verde mientras el sistema fallaba en producción. ¿Por qué? Porque la batería alimentaba al razonador con datos ya limpios, saltándose la parte que de verdad se equivocaba: la extracción de la conversación real.

Si tu evaluación entra por un punto intermedio, estás validando la mitad limpia y dejando fuera precisamente la mitad sucia. Entra por donde entra el usuario, aunque sea más lento y más incómodo de montar.

Cuándo ejecutarla

Tres momentos, y ninguno es opcional:

1. Antes de subir cualquier cambio de prompt, de modelo, de recuperación o de reglas. Sin excepciones, porque las excepciones son justo donde entra el fallo.
2. Al cambiar de versión de modelo, aunque sea una actualización menor del proveedor. El comportamiento se mueve y no te avisan.
3. Periódicamente en producción, si el sistema depende de datos que cambian. Lo que era correcto en marzo puede no serlo en agosto.

Y una condición para que esto sobreviva: tiene que ser un comando. Si ejecutar la batería requiere media hora de preparativos, se dejará de ejecutar en cuanto haya prisa, que es exactamente cuando más falta hace.

Lo que te llevas

Más allá de evitar regresiones, una batería cambia las conversaciones del equipo. Se deja de discutir si el sistema "va mejor" por impresiones y se empieza a hablar de números concretos: de 287 casos pasaban 271 y ahora pasan 279, y estos cuatro nuevos fallos vienen de tal cambio.

También cambia lo que puedes prometer a un cliente. Decir "tenemos una batería de casi 300 casos que se ejecuta ante cada cambio" es una afirmación verificable. Decir "funciona muy bien" no lo es.