Una demostración de IA generativa impresiona en minutos. Se escribe un prompt, la respuesta parece buena y la sala asiente. El problema empieza cuando ese mismo sistema pasa a responder a miles de preguntas reales, de usuarios reales, sobre casos que nadie probó. Ahí la pregunta cambia de "¿parece buena?" a "¿cómo sé que es buena, de forma consistente y medible?".
Evaluar un sistema de IA generativa es distinto de evaluar software tradicional. No hay un único resultado "correcto": la misma pregunta admite varias respuestas aceptables y muchas respuestas erróneas con aire convincente. Además, el comportamiento cambia cuando se altera el prompt, la base de conocimiento o la versión del modelo. Sin un proceso de evaluación, cada cambio es un salto a ciegas.
Este artículo propone una forma práctica de evaluar estos sistemas — del primer prototipo a producción — sin caer en el exceso de las métricas académicas ni en la ingenuidad de confiar en la primera demostración. La idea central es simple: definir qué es el éxito, medir de forma repetible y mirar la calidad, el coste y el riesgo en conjunto.
Qué significa "evaluar" un sistema de IA generativa
Evaluar no es dar una nota subjetiva a una respuesta aislada. Es medir, de forma repetible, si el sistema cumple el objetivo para el que fue construido, a lo largo de muchos casos representativos. Un asistente de atención al cliente, un generador de resúmenes y un copiloto de código tienen objetivos distintos y, por eso, criterios de evaluación distintos.
Conviene separar tres capas que a menudo se confunden. La primera es el modelo en sí, por ejemplo un LLM. La segunda es el sistema a su alrededor: prompts, recuperación de contexto mediante RAG, reglas, filtros y herramientas. La tercera es la experiencia del usuario final. Una respuesta puede ser técnicamente correcta y aun así fallar por ser demasiado larga, llegar tarde o no citar la fuente. Evaluar bien obliga a mirar las tres.
Definir la tarea y los criterios de éxito antes que las métricas
El error más común es elegir métricas antes de definir qué se quiere. El orden correcto es el inverso: primero se describe la tarea con precisión, luego qué cuenta como buena respuesta, y solo al final se elige cómo medir.
Vale la pena escribir, en lenguaje sencillo, tres cosas: qué debe hacer el sistema, qué no debe hacer nunca y qué es una respuesta suficientemente buena. En un asistente interno de recursos humanos, por ejemplo, una buena respuesta cita la política correcta, no inventa cifras y deriva a una persona cuando el caso es sensible. Estos criterios se convierten después en la base de las pruebas.
Construir un conjunto de evaluación representativo
No se evalúa un sistema con tres preguntas escogidas a dedo. Se necesita un conjunto de casos — a veces llamado golden set — que represente el uso real: preguntas frecuentes, casos difíciles, peticiones ambiguas y situaciones que el sistema debe rechazar. Cincuenta a doscientos casos bien elegidos valen más que miles generados al azar.
Algunos principios ayudan a montar este conjunto:
- Cobertura: incluir los temas e intenciones más comunes, pero también los raros y arriesgados.
- Casos negativos: preguntas fuera de ámbito, para verificar si el sistema rechaza o deriva en vez de inventar.
- Respuestas de referencia: siempre que sea posible, una respuesta ideal o los hechos que la respuesta debe contener.
- Actualización: revisar el conjunto cuando aparecen nuevos tipos de pregunta en producción.
Métricas que tienen sentido: calidad, fidelidad y seguridad
No existe una métrica única. Conviene combinar algunas, según la tarea. Para tareas con respuesta bien definida — clasificar, extraer, responder a hechos — se miden cosas como exactitud, cobertura y precisión. Para texto libre, las métricas automáticas de solapamiento de palabras dicen poco sobre la calidad real; hay que evaluar fidelidad al contexto, relevancia y claridad.
Tres dimensiones suelen ser decisivas: la calidad (¿es la respuesta correcta, completa y útil?), la fidelidad (¿se apoya la respuesta en las fuentes proporcionadas o inventa?) y la seguridad (¿evita la respuesta contenido peligroso, fugas de datos y un tono inadecuado?). Medir solo la primera e ignorar las otras dos es como validar un coche por su velocidad sin mirar los frenos.
Evaluación automática, humana y el modelo como juez
Hay tres formas de puntuar respuestas, y el buen criterio está en combinarlas. La evaluación humana es la más fiable para los matices, pero es lenta y cara. La evaluación automática por reglas funciona cuando hay una respuesta verificable: un número, un código, un hecho. Y está el enfoque de usar un modelo para evaluar a otro, el llamado LLM as a judge.
Usar un LLM como juez es atractivo porque es rápido y barato, pero exige cuidado. El juez puede tener los mismos sesgos que el modelo evaluado, favorecer respuestas largas o ser sensible al orden de las opciones. La práctica sana es calibrar al juez contra un conjunto evaluado por personas y usarlo para el triaje, no como veredicto final en decisiones críticas.
Alucinaciones y fidelidad a la fuente
La alucinación — cuando el modelo afirma algo falso con confianza — es el riesgo que más socava la confianza de los usuarios. En sistemas con RAG, la pregunta clave no es solo "¿es correcta la respuesta?", sino "¿está la respuesta apoyada en los documentos recuperados?". Una respuesta acertada por casualidad, sin apoyo en las fuentes, es un problema a la espera de ocurrir.
Para medir esto, se comprueba si cada afirmación relevante de la respuesta se encuentra en el contexto proporcionado. Puede hacerse con revisión humana en muestras y con verificaciones automáticas que comparan la respuesta con las fuentes. Cuando la tasa de afirmaciones no respaldadas sube, el problema suele estar en la recuperación — documentos erróneos o insuficientes — y no en el modelo.
Coste, latencia y robustez: evaluar más allá de la calidad
Un sistema excelente que cuesta demasiado o tarda demasiado nunca llega a producción. La evaluación seria mide también el coste por respuesta (número de tokens y llamadas), la latencia (tiempo hasta la primera palabra y tiempo total) y la robustez (qué ocurre con preguntas mal escritas, muy largas o en varios idiomas).
También conviene probar la estabilidad: la misma pregunta hecha varias veces debe dar respuestas coherentes. Una variación enorme entre ejecuciones es señal de que el sistema es frágil y difícil de controlar. Estas medidas no son detalles técnicos; son lo que separa un prototipo de un producto.
Errores comunes al evaluar IA generativa
Algunos patrones se repiten en muchos equipos. El primero es evaluar solo con ejemplos fáciles y concluir que funciona siempre. El segundo es confiar en una métrica automática de texto como si fuera verdad absoluta. El tercero es probar una vez, aprobar y no volver a medir — cuando basta un cambio de versión del modelo para que todo cambie.
Está además el error de mezclar el conjunto de evaluación con los ejemplos usados para afinar prompts: si el sistema estudió para el examen, los resultados engañan. Y, por último, el error de mirar solo la media e ignorar los peores casos — a menudo es una respuesta mala, en un momento sensible, la que destruye la confianza de un cliente.
Minicaso: un asistente interno en una empresa de servicios
Una empresa de servicios financieros construyó un asistente para responder a preguntas de empleados sobre políticas internas, con RAG sobre sus documentos. En la demostración, todo parecía perfecto. Antes de abrirlo a toda la empresa, el equipo preparó un conjunto de 120 preguntas reales, con respuestas de referencia aprobadas por el área de cumplimiento.
La primera evaluación fue reveladora: el 82% de las respuestas eran correctas, pero el 15% contenía afirmaciones no respaldadas por los documentos, y el tiempo medio de respuesta era de nueve segundos. Al investigar, el equipo comprendió que el problema estaba en la recuperación, que traía documentos desactualizados. Mejoró la indexación y añadió una instrucción para que el sistema rechazara cuando no encontrara base. En una segunda ronda, las afirmaciones no respaldadas bajaron al 4% y la latencia a cuatro segundos. Solo entonces avanzó — y mantuvo la evaluación en marcha semanalmente para detectar regresiones.
En la práctica
Evaluar un sistema de IA generativa no es un examen único, es un hábito. Empieza por definir qué es el éxito, monta un conjunto de casos representativo, mide calidad, fidelidad y seguridad en conjunto y no te olvides del coste y de la latencia. Usa evaluación humana donde importa y automatiza el resto para poder repetir la medición en cada cambio.
La recompensa es doble: menos sorpresas desagradables en producción y una base objetiva para decidir. En IA generativa, la diferencia entre un juguete impresionante y un producto de confianza no está en el modelo — está en la disciplina con la que lo evaluamos.
