Obtener una respuesta del modelo de IA no significa todavía que el sistema funcione correctamente. En el caso del software clásico, a menudo podemos comprobar de forma inequívoca si una función devolvió el resultado esperado. En los sistemas de IA, la respuesta puede ser fluida, lógica y convincente, y aun así contener errores.
Por eso, junto con el desarrollo de la IA surge un nuevo problema de ingeniería: ¿cómo medir sistemáticamente la calidad de un sistema cuyas respuestas no siempre son idénticas?
Ese es precisamente el ámbito de la evaluación de IA, es decir, la evaluación de sistemas de inteligencia artificial.
Y es mucho más amplio que comprobar si un chatbot «responde bien».
Probar software clásico y probar IA no es lo mismo
Imaginemos una función sencilla en una aplicación.
El usuario escribe: 2 + 2
El sistema debería devolver: 4
Si devuelve 5, tenemos un error inequívoco.
Podemos preparar una prueba: expect(calculate("2 + 2")).toBe(4)
y cada vez obtendremos un resultado claro: la prueba pasa o no pasa.
En los sistemas de IA la situación es distinta.
El usuario puede preguntar: «Escribe una respuesta breve para un cliente que pregunta por la fecha de entrega del pedido.»
El sistema puede generar varias respuestas distintas. Todas pueden ser correctas desde el punto de vista lingüístico. Todas pueden sonar profesionales. Sin embargo, una puede contener una fecha incorrecta, otra puede ser demasiado larga, una tercera puede omitir información importante y una cuarta puede ser perfecta.
Por eso no basta con comprobar si la respuesta se generó técnicamente.
Hay que comprobar si cumple criterios de calidad definidos.
Primer problema: una buena respuesta no siempre es verdadera
Esta es una de las características más distintivas de la IA generativa.
El modelo puede generar una respuesta que suena muy convincente, pero que no está respaldada por los datos de origen.
En el caso de un sistema que usa RAG, el problema es aún más interesante. El sistema puede recibir una pregunta, buscar varios fragmentos de documentación y después generar una respuesta.
Entonces hay que comprobar al menos tres cosas:
- ¿Se encontraron las informaciones correctas? ¿El mecanismo de búsqueda recuperó fragmentos realmente relacionados con la pregunta?
- ¿La respuesta utiliza la información encontrada? ¿El modelo no añadió algo que no estaba en las fuentes?
- ¿La respuesta responde realmente a la pregunta? Porque se puede tener una búsqueda que funcione correctamente, pero una mala respuesta final.
Precisamente por eso la evaluación de RAG separa, entre otros, aspectos como la relevancia del contexto recuperado, la completitud de la búsqueda, la corrección de la respuesta y su coherencia con las fuentes.
Es un cambio importante en la forma de pensar sobre las pruebas.
Ya no probamos solo: pregunta → respuesta
sino toda la cadena: pregunta → búsqueda → contexto → modelo → respuesta
Se puede tener un buen modelo y un mal sistema de IA
Esta es otra cosa que es fácil olvidar.
Una empresa puede elegir un modelo de lenguaje muy bueno y, aun así, crear un producto de IA deficiente.
¿Por qué? Porque la calidad del sistema final no depende solo del modelo.
También importan:
- la calidad de los datos,
- la forma de preparar el contexto,
- el prompt,
- la forma de buscar información,
- los parámetros del modelo,
- las herramientas disponibles para la IA,
- la lógica de la aplicación,
- la memoria,
- la forma de gestionar errores,
- las protecciones,
- la forma de evaluar las respuestas.
Eso significa que la pregunta: «¿Qué modelo es el mejor?»
a menudo es menos útil que: «¿Qué modelo funciona mejor en nuestro caso de uso concreto?»
Un modelo que sobresale generando contenido de marketing no tiene por qué ser la mejor solución para clasificar documentos, analizar datos o gestionar procesos empresariales.
Por eso, la comparación de modelos debería realizarse en tareas reales que el sistema debe ejecutar.
Primero hay que crear un conjunto de pruebas propio
No se puede evaluar de forma razonable un sistema de IA si no sabemos qué esperamos de él.
Por eso uno de los elementos más importantes de la evaluación es preparar un dataset de prueba, es decir, un conjunto de casos reales o representativos.
Por ejemplo, una empresa construye una IA para el departamento de atención al cliente.
En lugar de comprobar manualmente una respuesta después de cada cambio en el prompt, se pueden preparar varios cientos de casos:
- preguntas sencillas,
- preguntas ambiguas,
- preguntas que contienen supuestos incorrectos,
- preguntas que requieren buscar un documento,
- preguntas sobre excepciones,
- preguntas sobre reclamaciones,
- preguntas que requieren una negativa,
- preguntas que contienen datos que la IA no debería revelar.
Cada cambio del sistema puede ejecutarse después sobre el mismo conjunto.
Y precisamente aquí la IA empieza a parecerse al software clásico.
Ya no probamos una sola respuesta. Probamos el comportamiento del sistema en todo el conjunto de casos.
También se puede probar el prompt
A menudo se trata el prompt como un texto que alguien escribió una vez y dejó en producción.
En realidad, puede ser un elemento de la lógica de la aplicación.
Cambiar una sola frase puede provocar:
- mejora de la respuesta en un escenario,
- empeoramiento de la respuesta en otro,
- mayor tendencia a negarse,
- mayor número de alucinaciones,
- respuestas más largas,
- mayor coste,
- mayor consumo de tokens.
Por eso el prompt debería tratarse de forma parecida al código.
Si cambiamos el prompt, conviene saber:
- ¿qué mejoró?
- ¿qué empeoró?
- ¿apareció una regresión?
Precisamente por eso cada vez cobra más importancia la evaluación automática, y no la valoración manual de unas pocas respuestas de ejemplo.
La IA puede superar una prueba y aun así ser un mal producto
Supongamos que hemos preparado 100 casos de prueba.
El sistema respondió correctamente en 95. El resultado parece excelente. Pero, ¿qué pasa si las cinco respuestas incorrectas se refieren a situaciones críticas?
Si el chatbot responde preguntas sobre el horario de apertura, cinco errores pueden ser un problema.
Si la IA ayuda a un empleado a analizar documentos financieros, médicos o legales, la importancia de esos errores puede ser completamente distinta.
Por eso la media por sí sola no basta.
También necesitamos ponderar los casos.
Podemos considerar que:
- una pregunta normal tiene un peso de 1,
- un error importante tiene un peso de 5,
- Un error de seguridad tiene un peso de 10,
- la revelación de información confidencial tiene un peso de 100.
Entonces el sistema no obtiene un «95 por ciento». Obtenemos una imagen mucho más útil del riesgo.
No todo se puede medir con un solo número
Ese es uno de los problemas más importantes de la evaluación de IA.
Podemos tener varias métricas:
- Accuracy - ¿la respuesta es correcta?
- Relevance - ¿responde a la pregunta?
- Faithfulness / groundedness - ¿se basa en las fuentes proporcionadas?
- Context precision - ¿los fragmentos recuperados son relevantes?
- Context recall - ¿el sistema encontró la información necesaria?
- Safety - ¿no realiza acciones no deseadas?
- Latency - ¿cuánto tiempo espera el usuario?
- Cost - ¿cuánto cuesta realizar la tarea?
RAG puede tener una calidad de respuesta muy buena, pero al mismo tiempo consumir una enorme cantidad de contexto y generar un coste inaceptable.
Otro sistema puede ser muy barato y rápido, pero cometer demasiados errores.
Por lo tanto, no existe un único número universal que determine si una IA es «buena». La calidad debe definirse en el contexto de una aplicación concreta.
¿Y qué pasa con evaluar la IA mediante otra IA?
Aquí aparece otro mecanismo interesante.
Una de las formas de automatizar la evaluación es utilizar un modelo como juez, es decir, LLM-as-a-judge.
Por ejemplo:
El modelo A genera una respuesta.
El modelo B recibe la pregunta, la respuesta y unos criterios determinados.
Luego evalúa:
- corrección,
- cumplimiento de la instrucción,
- completitud,
- estilo,
- seguridad.
Las herramientas modernas de evaluación también permiten combinar este tipo de valoración con comparaciones clásicas de texto, scripts propios o evaluadores basados en reglas concretas.
Esto aumenta enormemente la escala de las pruebas. Pero no significa que el ser humano deje de ser necesario. El modelo evaluador también puede equivocarse. Por eso, en sistemas de mayor importancia para el negocio conviene combinar evaluaciones automáticas con una revisión experta periódica.
El mayor problema: la regresión
Imaginemos un sistema que funciona muy bien. El equipo cambia el modelo por uno más nuevo. La nueva versión es más rápida y más barata. Así que parece que todo va en la dirección correcta.
Sin embargo, después de la implementación resulta que:
- las respuestas son menos precisas,
- el modelo rechaza responder con más frecuencia,
- utiliza peor la documentación,
- interpreta las instrucciones de otra manera,
- en algunos escenarios empieza a proporcionar información incorrecta.
Eso es precisamente AI regression.
En el software clásico conocemos la regresión desde hace años. En IA también debemos detectarla, pero el problema es más difícil, porque el comportamiento del sistema puede cambiar sin un «error» clásico. Por eso, cada cambio importante debe compararse con la versión anterior.
Modelo.
Prompt.
Embedding.
Retriever.
Documentación.
Lógica del agente.
Parámetros.
Cada uno de estos elementos puede influir en el resultado.
No basta con evaluar al agente por su respuesta final
Aún más difícil se vuelve en el caso de los agentes de IA.
Un chatbot clásico puede realizar una sola tarea: pregunta → respuesta.
Un agente puede funcionar de forma totalmente distinta: objetivo → plan → herramienta → resultado → siguiente paso → decisión → acción → respuesta.
Si el agente no ha alcanzado el objetivo, queremos saber no solo que ha perdido.
Queremos saber: ¿dónde cometió el error?
- ¿Entendió mal la tarea?
- ¿Eligió la herramienta incorrecta?
- ¿Pasó un parámetro incorrecto?
- ¿Obtuvo los datos equivocados?
- ¿Tomó una mala decisión después de recibir el resultado?
- ¿Realizó demasiados pasos?
- ¿Se detuvo demasiado pronto?
En la investigación sobre la evaluación de agentes, cada vez se analiza más no solo el resultado final, sino también el desarrollo de la acción, el uso de herramientas, la planificación, la memoria, la fiabilidad y la seguridad.
Eso significa que el futuro de las pruebas de IA estará en gran medida relacionado con el análisis de trace'ów, es decir, el recorrido completo de funcionamiento del sistema.
La IA necesita algo parecido a CI/CD
Si la IA es parte del producto, no se puede probar solo antes del primer despliegue.
El sistema cambiará.
Cambiará el modelo.
Cambiará el prompt.
Cambiará la base de conocimiento.
Cambiará la forma de búsqueda.
Cambiará la configuración.
Por eso, la evaluación debería incorporarse al proceso de desarrollo.
El esquema puede ser el siguiente: cambio → pruebas → evaluación → comparación con la versión anterior → decisión de despliegue
Si la nueva versión mejora la calidad en un área, pero supera el umbral de errores establecido en otra, el despliegue puede detenerse.
Es una filosofía muy parecida a la del CI/CD clásico, pero los criterios son distintos.
En el caso de las aplicaciones de IA podemos comprobar al mismo tiempo la calidad de la respuesta, la corrección, la seguridad, el coste y la latencia. Ya están surgiendo soluciones de investigación que combinan la evaluación con la observabilidad y las puertas de calidad en el proceso de despliegue de sistemas LLM/RAG.
¿Se puede entonces probar la IA igual que el software clásico?
Sí, pero solo en parte.
El enfoque clásico sigue siendo necesario.
Probamos:
- API,
- integraciones,
- permisos,
- validación de datos,
- errores,
- timeouts,
- seguridad,
- rendimiento,
- lógica de la aplicación.
Pero no podemos quedarnos ahí.
Se añade una segunda capa: evaluación del comportamiento de la IA.
- ¿La respuesta es correcta?
- ¿Es coherente con las fuentes?
- ¿El modelo sigue las instrucciones?
- ¿El sistema se comporta correctamente en situaciones inesperadas?
- ¿El agente elige las herramientas adecuadas?
- ¿La nueva versión no ha empeorado la calidad?
- ¿El coste de funcionamiento sigue siendo aceptable?
- ¿El usuario recibe realmente valor?
Eso ya no es una prueba unitaria clásica.
La mejor prueba de IA no siempre es una prueba de laboratorio
Hay otro elemento muy importante.
El sistema puede obtener excelentes resultados en un conjunto de pruebas preparado, y aun así tener problemas en el mundo real. Por eso vale la pena observar también las interacciones reales. No para que cada usuario sea un tester. Se trata de que el sistema pueda mejorarse continuamente a partir de casos reales:
- dónde los usuarios corrigen a la IA,
- dónde piden que se repita la respuesta,
- dónde interrumpen la conversación,
- dónde escalan el asunto a una persona,
- dónde el agente no alcanza el objetivo,
- dónde aparecen preguntas inusuales.
De esta manera se crea un bucle continuo de evaluación: usuario → acción de la IA → resultado → análisis → nuevo caso de prueba → siguiente versión del sistema
Es un modelo de desarrollo completamente distinto al de un simple «implementamos IA y funciona».
La IA no debería evaluarse con la pregunta «¿funciona?».
Eso es demasiado poco.
Mejores preguntas son:
- ¿Con qué frecuencia funciona correctamente?
- ¿En qué situaciones se equivoca?
- ¿Qué tan graves son esos errores?
- ¿La nueva versión es mejor que la anterior?
- ¿El sistema es lo suficientemente seguro?
- ¿Las respuestas se basan en los datos correctos?
- ¿Cuánto cuesta lograr un resultado concreto?
Solo este conjunto de preguntas permite hablar de un sistema de IA maduro.
El cambio más importante en la forma de pensar
Durante años, en el desarrollo de software regía una regla simple: el código debe funcionar.
En los sistemas de IA hay que ampliarla: el sistema debe funcionar bien, de forma predecible y medible.
Es una diferencia enorme. Porque la IA no es una función que siempre devuelve el mismo resultado. Es un sistema probabilístico cuyo comportamiento depende del modelo, los datos, el contexto, las instrucciones y toda la arquitectura que lo rodea.
Por eso, una implementación profesional de IA no termina en el momento en que el modelo empieza a responder.
Entonces es cuando surge la pregunta: ¿cómo sabemos que podemos confiar en él?
Y precisamente a esa pregunta debería responder una evaluación bien diseñada.
En el futuro, probar sistemas de IA probablemente se convertirá en un elemento del proceso de desarrollo tan natural como las pruebas unitarias, las pruebas de integración o la monitorización. No porque la IA sea «peligrosa por definición». Simplemente porque un sistema cuyo resultado no siempre es determinista requiere otra forma de medir la calidad.
Y cuanto más pasa la IA de generar texto a gestionar procesos reales, usar datos, RAG y realizar acciones mediante agentes, más importante se vuelve no solo la pregunta «¿la IA puede hacerlo?», sino también: «¿podemos demostrar que lo hace lo suficientemente bien?»
