Testing con IA: el problema del determinismo

Actualizado: 2026-05-03

Probar sistemas que contienen modelos de lenguaje rompe el axioma fundamental sobre el que se construyó toda la disciplina del testing automatizado: ante la misma entrada, el sistema produce la misma salida. Los modelos generativos, por su propia naturaleza, no garantizan esa propiedad ni con temperatura cero; hay variación entre versiones, entre proveedores, entre hardware y a veces simplemente entre ejecuciones sucesivas. Después de más de un año integrando modelos de lenguaje en productos con usuarios reales, este artículo recoge un conjunto de estrategias que funcionan y otro que no.

Puntos clave

• El testing tradicional con asertos exactos se rompe con modelos de lenguaje: la misma llamada puede devolver frases ligeramente distintas sin que nada haya cambiado en tu código.
• La estrategia de tres capas funciona: código determinista alrededor del modelo (tests unitarios clásicos), instantáneas tolerantes por similitud semántica, y evaluaciones con juez LLM para casos críticos.
• El cinturón de evaluaciones offline no mide calidad absoluta sino deriva: lo que detecta problemas es que la puntuación baje de repente, no que sea un número concreto.
• Los casos de evaluación deben ser adversarios, no representativos: un cinturón que replica el uso promedio da puntuaciones altas y estables que no detectan nada.
• Ningún cinturón de pruebas sustituye a observar usuarios reales usando el producto.

Por qué los tests clásicos se rompen

El testing tradicional se apoya en asertos exactos: el resultado de esta función debe ser esta cadena, este número, esta estructura. Con un modelo de lenguaje, la misma llamada puede devolver frases ligeramente distintas, orden de ítems cambiado, énfasis diferente en la argumentación. Si escribes un aserto exacto contra la salida, el test fallará al día siguiente sin que nada haya cambiado en tu código. La reacción natural es bajar la barrera: comprobar solo que la respuesta contiene una palabra clave, o que supera una longitud mínima. El problema es que esos asertos son tan laxos que dejan pasar regresiones graves sin detectarlas.

El segundo muro es que los modelos evolucionan debajo de ti. Si tu producto depende de un proveedor externo, el modelo que llamas hoy no es estrictamente el mismo que llamarás dentro de tres meses, aunque el nombre no cambie. Proveedores como OpenAI y Anthropic actualizan modelos con regularidad. Un cinturón de pruebas que funcionaba perfectamente puede empezar a fallar sin que hayas tocado el código. Eso, en ingeniería clásica, sería inaceptable; en sistemas con IA es el estado normal.

El tercer problema es la dependencia externa. Cada ejecución de test consume tokens, cuesta dinero, tiene latencia de red y puede fallar por cuotas o caídas del proveedor. Un cinturón de 500 tests puede tardar 15 minutos y costar varios euros por ejecución, lo que hace inviable lanzarlo en cada envío a la integración continua. Esto obliga a segregar pruebas rápidas deterministas de pruebas lentas estocásticas, con disciplina operativa distinta.

La estrategia de tres capas

La solución que ha funcionado y que está cristalizando en el sector es una arquitectura de pruebas con tres capas bien diferenciadas, cada una con objetivos y costes distintos.

Capa 1: el código alrededor del modelo

La primera capa es el código alrededor del modelo, que debe ser completamente determinista y probado con asertos clásicos. Toda la lógica de composición de avisos, parseo de respuestas, manejo de errores, normalización de formatos y decisión de cuándo llamar al modelo pertenece aquí. Esta capa puede y debe tener cobertura alta de pruebas unitarias rápidas que no tocan el modelo real, usando respuestas grabadas o fijas. En los proyectos analizados, esta capa concentra entre el 70 y el 80 por ciento de los tests y corre en menos de diez segundos.

Capa 2: instantáneas tolerantes

La segunda capa es la de pruebas de instantáneas tolerantes. Se captura la salida real del modelo en una ejecución de referencia, se guarda como instantánea, y las ejecuciones posteriores comparan contra ella no palabra por palabra, sino con una métrica de similitud semántica. Si la salida actual se parece en más de un 90 por ciento a la instantánea por embeddings de frase, pasa. Si se aleja mucho, el test falla y un humano decide si la diferencia es una mejora o una regresión.

Capa 3: evaluación con juez automatizado

La tercera capa es la evaluación con juez automatizado, popularmente llamada LLM como juez. Un modelo distinto del que produce la respuesta evalúa si la respuesta cumple criterios específicos: es coherente con el contexto, responde a la pregunta del usuario, no contiene alucinaciones detectables, mantiene el tono pedido. Esta capa es la más potente pero también la más cara y la más lenta. Suele reservarse para un conjunto curado de casos críticos y ejecutarse antes de despliegues importantes.

Evaluaciones offline: lo que realmente captura regresiones

La pieza que une las tres capas es el cinturón de evaluaciones offline. Se construye con un conjunto de casos de uso representativos de tu producto, cada uno con su entrada, una salida esperada o un conjunto de criterios de aceptación, y se lanza cada vez que cambias el aviso, el modelo o la temperatura. Los resultados se agregan en una puntuación global y se comparan contra la ejecución anterior.

Lo importante es que el cinturón no mide calidad absoluta sino deriva. Un producto puede funcionar perfectamente aunque su cinturón saque un 78 por ciento de puntuación; lo que detecta problemas es que de pronto baje a 65. Por eso conviene:

• Invertir en casos diversos que cubran los escenarios donde sabes que tu sistema puede fallar: entradas ambiguas, contenido sensible, idiomas secundarios, formatos esquina.
• Versionar el cinturón como código: cada cambio en los casos debe justificarse y revisarse como cualquier otro cambio.

Un hallazgo que cuesta aprender es que los casos de evaluación deben ser adversarios, no representativos. Un cinturón que replica el uso promedio da puntuaciones altas y estables que no detectan nada. Un cinturón construido con los casos donde el producto tiene más probabilidades de fallar, las entradas más raras, los límites del dominio, los intentos de abuso, es el que realmente avisa cuando algo cambia.

Integración continua: la jerarquía de ciclo

La disciplina operativa que ha acabado siendo más útil distingue tres ciclos de pruebas por frecuencia y coste:

• Ciclo por envío: ejecuta solo la primera capa, rápida y determinista, en cada envío a la integración. Tarda segundos y se lanza en cada cambio.
• Ciclo nocturno: ejecuta la segunda capa sobre un subconjunto estable de casos, con coste acotado, y avisa al día siguiente si hay deriva.
• Ciclo semanal: ejecuta la tercera capa completa, con juez automatizado, sobre el cinturón entero; es el que captura las regresiones más sutiles y el que justifica que se haga antes de un despliegue importante.

Esta separación tiene consecuencias culturales. La aceptación de que no todas las regresiones se detectan en el momento del cambio, sino en el ciclo siguiente, obliga a diseñar despliegues con ventanas de rollback fáciles y con observabilidad en producción que captura lo que las pruebas no. Esto conecta con lo que describimos en observabilidad de agentes de IA: el cinturón de pruebas y la monitorización en producción son capas complementarias, no sustitutivas.

Cómo pensar la decisión

El testing con IA requiere abandonar la nostalgia del aserto exacto y aceptar un modelo probabilístico de calidad. Los sistemas que integran modelos de lenguaje no se pueden garantizar con la precisión de los sistemas deterministas clásicos. Lo que se puede garantizar es que no hay deriva inaceptable, que los casos críticos siguen funcionando, y que hay mecanismos de monitorización y rollback para capturar lo que las pruebas pasan por alto.

La consecuencia práctica es que los equipos que quieran integrar IA con seriedad deben invertir proporcionalmente más en evaluaciones y observabilidad que en cobertura clásica. Un producto con modelo de lenguaje necesita menos pruebas unitarias en el sentido tradicional y más pruebas de evaluación semántica, menos asertos exactos y más métricas continuas. No es menos disciplina; es disciplina distinta.

Conclusión

Ningún cinturón de pruebas sustituye a observar usuarios reales usando el producto. Los cinturones atrapan regresiones conocidas; los usuarios encuentran las desconocidas. La detección de problemas en producción, con registros de conversaciones y encuestas de satisfacción, debe ser pieza central de la estrategia.