Resumen — Los modelos mentales y las herramientas que funcionan para el desarrollo de software tradicional no sirven para los modelos de lenguaje. Los resultados son probabilísticos, la calidad es multidimensional, los modelos cambian sin necesidad de un despliegue y lo que estás probando puede fallar silenciosamente de formas que ninguna aserción detectará. La evaluación de LLM es una disciplina distinta, no una extensión de la que ya conoces.
Por qué los instintos de desarrollo de software fallan al evaluar LLMs
Cuando los equipos de ingeniería necesitan evaluar un LLM por primera vez, recurren a lo que ya conocen: escribir casos de prueba, verificar que el resultado coincida con un valor esperado y ejecutar pruebas en cada PR. Parece correcto; es así como funciona la calidad en el resto de la pila tecnológica.
Aquí no funciona. No porque el instinto sea erróneo, sino porque los modelos de lenguaje tienen propiedades que invalidan todos los supuestos sobre los que se construyeron esas herramientas.
La brecha no está en las herramientas, sino en el modelo mental.
Supuesto 1: misma entrada, misma salida
Todo enfoque de pruebas tradicional depende del determinismo. Ante la misma entrada y el mismo código, la salida es la misma. Eso es lo que hace que las aserciones funcionen.
Los modelos de lenguaje no son deterministas. Una temperatura > 0 significa que el mismo prompt produce resultados diferentes en cada llamada. Incluso con temperatura 0, cambios menores en la implementación entre versiones del modelo pueden alterar los resultados. El código no cambia, pero el resultado sí.
Esto significa que las aserciones de coincidencia exacta —la forma más común de prueba unitaria— son estructuralmente incorrectas para evaluar la calidad de los resultados de un LLM. Fallarán con respuestas válidas y pasarán con respuestas inválidas, dependiendo de los tokens específicos que el modelo haya generado por azar.
El reemplazo no es una mejor aserción, sino un método de evaluación diferente: puntuación basada en rúbricas, comparación con referencias o el uso de un LLM como juez; cada uno diseñado para operar sobre un rango de resultados válidos en lugar de una única cadena esperada.
Supuesto 2: el éxito/fallo cubre la calidad
Una prueba unitaria devuelve verde o rojo. Ese binario es útil precisamente porque el comportamiento que se prueba es binario: la función devuelve el valor correcto o no lo hace.
La calidad de los resultados de un LLM no es binaria. Una respuesta puede ser mayormente correcta pero contener un error factual en la tercera oración. Puede responder a la pregunta citando algo que no estaba en el contexto recuperado. Puede ser técnicamente precisa pero tan verbosa que los usuarios dejan de leer a la mitad. Ninguno de estos casos es detectado por una comprobación de éxito/fallo. Ninguno aparece como un fallo en las pruebas. Todos ellos degradan el producto.
Medir la calidad de un LLM requiere una puntuación graduada en múltiples dimensiones —precisión, fidelidad, relevancia, seguridad—, cada una con su propia métrica y su propia tasa de error aceptable. Un resultado único de verde/rojo simplifica demasiado la información necesaria para diagnosticar qué es lo que realmente falla.
Supuesto 3: tú controlas lo que cambia
En el software tradicional, el sistema cambia cuando realizas un despliegue. Tu conjunto de pruebas es un registro del comportamiento esperado y falla cuando un despliegue rompe algo. La relación es clara: cambio en el código → posible fallo en las pruebas.
Los modelos de lenguaje rompen esta relación de dos maneras.
Primero, los proveedores de modelos actualizan los pesos subyacentes sin cambiar el identificador de la API. OpenAI actualizó los pesos de GPT-4 Turbo varias veces sin cambiar la cadena de versión del modelo, algo documentado en foros de desarrolladores a posteriori. Tus prompts no cambiaron. Tu código no cambió. El comportamiento del modelo sí. Ninguna suite de CI detecta esto.
En segundo lugar, la distribución de entrada cambia a medida que nuevos usuarios descubren el producto. El modelo que funcionó bien en su conjunto de pruebas interno puede tener un rendimiento deficiente con la larga cola de consultas que envían los usuarios reales, no porque algo haya cambiado en el sistema, sino porque el sistema nunca se probó con esas entradas. El software tradicional no tiene este problema: `add(2, 3)` no empieza a devolver valores incorrectos porque nuevos usuarios hayan empezado a utilizarlo.
Es por esto que la evaluación de LLM cuenta con una capa de monitoreo en producción que no tiene equivalente en las pruebas de software: calificar continuamente el tráfico real muestreado, observando desviaciones que no se correlacionan con ninguna implementación realizada.
Suposición 4: la cobertura de pruebas es alcanzable
Un conjunto de pruebas de software puede, en principio, cubrir cada ruta de código. Las herramientas de cobertura miden exactamente qué tan cerca está de lograrlo. Una cobertura de ramas del 100% es un objetivo real y alcanzable.
Para los modelos de lenguaje, el espacio de entrada es prácticamente infinito. No se pueden enumerar las consultas que enviarán los usuarios. No se puede escribir una prueba para cada modo de fallo antes de que ocurra. El estándar de "suficiente cobertura" no es un porcentaje, sino si su conjunto de evaluación contiene suficientes ejemplos de los modos de fallo que importan para su aplicación.
Esto cambia fundamentalmente la cuestión de la creación de conjuntos de datos. No se trata de intentar cubrir todo el espacio, sino de cubrir los modos de fallo, específicamente aquellos que ya han ocurrido o que tienen más probabilidades de ocurrir. El conjunto de datos correcto proviene de un análisis ascendente de fallos reales, no de una enumeración descendente de posibles entradas.
Suposición 5: el equipo de desarrollo define la calidad
En el software, el equipo de ingeniería define cómo es el comportamiento correcto. La especificación está en el código. Cuando una prueba falla, el ingeniero puede decirle cuál era el valor esperado y por qué.
Para la evaluación de LLM, los criterios de calidad requieren experiencia en el dominio para definirse. Lo que hace que una respuesta de atención al cliente sea correcta es una cuestión de atención al cliente, algo que requiere conocimiento del producto, la política y las expectativas del usuario. Lo que hace que un resumen de un documento legal sea fiel es una cuestión legal. El equipo de ingeniería puede construir la infraestructura de evaluación, pero generalmente no puede redactar la rúbrica.
Es por esto que los conjuntos de datos de referencia más efectivos se construyen con un experto en el dominio realizando la calificación inicial; no un comité, ni una anotación subcontratada, sino la persona que es dueña del producto y entiende qué es lo que se considera bueno. Esa sesión de calificación es donde los criterios de calidad se definen en la práctica, no en un documento de especificaciones.
Lo que esto significa en la práctica
El objetivo no es dejar de hacer pruebas de software. Las pruebas unitarias que verifican el esquema de salida, la pertenencia a etiquetas y la longitud de la respuesta siguen siendo útiles: son rápidas, económicas y detectan errores evidentes. El objetivo es dejar de confundir esas pruebas con la evaluación de calidad.
La evaluación de LLM se sitúa por encima de las pruebas de software, no en su lugar. Se encarga de la capa a la que las aserciones no pueden llegar: ¿la salida realmente hace lo que la aplicación necesita que haga, a través de la distribución de entradas reales y a lo largo del tiempo?
Para conocer el marco de evaluación completo (trazas, conjuntos de datos de referencia, calibración de jueces, regresión en CI y monitoreo en producción), consulte Evaluación de LLM: Guía para profesionales.
