Por qué las pruebas de IA generativa rompen la aserción de siempre
Si afirmas que la respuesta es igual a una cadena fija, la prueba falla en la segunda ejecución por motivos que nada tienen que ver con tu producto. Si lo relajas a una subcadena, pasa con salidas sutilmente erróneas. Ninguna de las dos sirve, y oscilar entre ambas es lo que lleva a los equipos a concluir que las funciones generativas no se pueden probar.
Qué afirmar en su lugar
| Propiedades | JSON válido, campos obligatorios presentes, dentro de la longitud permitida, cita una fuente que existe. Comprobable y estable entre ejecuciones. |
| Negativas | Rechaza lo que debe rechazar, y lo hace de forma consistente. Suele ser la comprobación más valiosa de la suite. |
| Fundamentación | Cada afirmación se puede rastrear hasta algo del contexto proporcionado. Detecta invenciones sin juzgar el estilo. |
Tasas, no resultados
Una sola ejecución no te dice nada. Ejecuta la misma entrada muchas veces y registra con qué frecuencia se cumple la propiedad. Tu unidad de medida es una tasa, y tu señal es un cambio en esa tasa, no un fallo aislado.
Esto también cambia lo que significa una regresión. La pregunta nunca es «¿es perfecto?», sino «¿este cambio lo empeoró respecto a la semana pasada?».
Cómo elegir las propiedades que vas a afirmar
Lo difícil no es la mecánica, sino decidir qué comprobar cuando no puedes comprobar la respuesta. Un buen punto de partida es preguntarte qué haría inservible la salida, en lugar de qué la haría buena.
«Inservible» es concreto: una salida mal formada que quien la invoca no puede parsear, una cita a algo que no existe, una negativa que debería haber sido una respuesta, una respuesta que debería haber sido una negativa, contenido que supera un límite más adelante en el flujo. Cada uno de esos casos es binario y comprobable, y cada uno corresponde a un incidente real, no a una opinión sobre la calidad.
«Bueno», en cambio, es un juicio que varía de un revisor a otro y que no vale la pena codificar como barrera. Hazle seguimiento si quieres, con revisión humana sobre una muestra, y mantenlo fuera del pipeline, donde generará discusiones en lugar de decisiones.
La parte que se prueba de la forma habitual
La mayor parte de un producto con una función generativa es software determinista corriente: autenticación, almacenamiento, limitación de peticiones, la interfaz alrededor de la función. Todo eso debe probarse de forma convencional, y tratar el producto entero como no determinista porque una parte lo es te hace perder mucha cobertura barata.
Traza el límite de forma explícita. Dentro, propiedades y tasas. Fuera, aserciones normales contra la aplicación en ejecución.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Si prefieres no instalar nada, el panel hace lo mismo. Todo lo demás que puede hacer la línea de comandos está en el repositorio del CLI.
Hay dos rutas, y la elección depende en realidad de quién sea el dueño del pipeline. Conectar la GitHub App desde el panel no requiere ningún cambio en tu repositorio, porque reacciona al despliegue que tu build ya emite. Añadir un paso de GitHub Actions coloca la comprobación en el repositorio, donde se revisa igual que el resto del build.
Qué cubre TestSprite alrededor de la función
La mayoría determinista del producto, que en casi todos los equipos es con diferencia la parte más grande. La autenticación, el almacenamiento, la limitación de peticiones, la interfaz alrededor de la función y cada flujo que un usuario recorre de verdad son software corriente y se prueban de forma convencional. Auto-Authentication mantiene vivas las sesiones durante toda la ejecución, Dynamic Variables traslada valores entre llamadas, Dependency Chains deduce el orden de ejecución y Auto-Cleanup elimina exactamente lo que creó la ejecución.
La cobertura se genera a partir de tu producto y se refina en lenguaje natural, y se ejecuta contra la aplicación desplegada en cada cambio, de modo que las partes del sistema que se pueden comprobar con exactitud se comprueban con exactitud.
La función generativa en sí necesita propiedades y tasas, es decir, un arnés de pruebas aparte con su propia noción de «aprobado». Trazar ese límite de forma explícita es lo que evita que un equipo aplique métodos estadísticos a código determinista o que renuncie por completo a las aserciones porque las coincidencias exactas no paraban de fallar.
¿Podemos usar una IA para calificar la salida?
Es habitual y funciona, con una salvedad: el evaluador tiene sus propios modos de fallo y necesita su propia calibración. Contrástalo con el juicio humano sobre una muestra antes de confiar en él.
¿Cuántas ejecuciones hacen falta para que una tasa sea significativa?
Las suficientes para que el número deje de moverse cuando añades más. Empieza por decenas en lugar de cientos y observa si se estabiliza.
¿Las pruebas generativas deberían bloquear un merge?
Una caída grande en una tasa de negativas, sí. Una variación pequeña en la calidad, no, o el pipeline se convierte en ruido.
¿Y el costo?
Las ejecuciones repetidas cuestan dinero. Toma muestras en lugar de ejecutar el conjunto completo en cada cambio, y ejecuta el conjunto completo de forma programada.
¿Probar prompts es lo mismo?
Está relacionado. Los cambios en los prompts son la causa más habitual de los cambios en las tasas, lo que es un buen argumento para tratar los prompts como artefactos versionados.
Propiedades y tasas, no igualdad.
Las pruebas de IA generativa sustituyen las aserciones exactas por propiedades, negativas y fundamentación, medidas como tasas a lo largo de muchas ejecuciones. Prueba de la forma habitual la mayoría determinista del producto y traza el límite de forma explícita.