Herramientas de evaluación para aplicaciones de LLM: conjuntos de datos, puntuación y umbrales de regresión

Enviar una función de LLM es la parte fácil; demostrar que sigue dando buenas respuestas es donde la mayoría de los equipos se detienen. Un sistema de evaluación cierra esa brecha: ejecuta un conjunto fijo de tareas en un modelo, califica cada respuesta y convierte las observaciones como “parece bien” en números que se pueden comparar entre diferentes versiones. Al final de esta guía sabrá de qué consta un sistema de este tipo, por qué la salida de los LLM lo necesita más que el código ordinario y cómo se integra en el proceso de lanzamiento como una barrera de regresión.

El término suena exótico, pero la idea es familiar. Si ha escrito pruebas unitarias, validado un pipeline de datos o establecido controles de calidad de datos antes de actualizar un panel de control, ya comprende su esencia.

La pregunta a la que se enfrenta eventualmente toda función de IA

Imagínese un asistente interno que responde preguntas de negocio. Un interesado pregunta qué clientes generaron más ingresos en el segundo trimestre, y la respuesta parece creíble. Otro pregunta por qué disminuyeron los ingresos en Alemania, y esa respuesta también suena convincente.

Dos respuestas persuasivas prueban muy poco. Lo que realmente necesita saber es si el asistente acierta en los miles de preguntas diferentes que la gente escribirá a diario, incluidas las incómodas que nadie pensó durante la demostración. La verificación manual no es escalable para eso, y no indica en absoluto cuando algo cambia silenciosamente.

Este es el obstáculo al que se enfrentan muchos proyectos de IA: desarrollar la aplicación lleva semanas, mientras que demostrar que funciona de manera fiable puede tomar mucho más tiempo. Un marco de pruebas es la herramienta que hace que dicha demostración sea sistemática.

Qué hace realmente un marco de pruebas

Un marco de evaluación es una estructura que proporciona a un modelo un conjunto predefinido de preguntas o tareas, recopila las respuestas, las califica según reglas establecidas y presenta los resultados. Se puede considerar como un control de calidad automático del comportamiento del modelo, o como un examinador que aplica el mismo examen a todos los candidatos y lo califica de la misma manera.

El flujo es lineal: las entradas de prueba se envían al marco, este llama al modelo, se evalúan las respuestas y la evaluación se convierte en calificaciones e informes:

Test Questions
      │
      ▼
   Harness
      │
      ▼
 AI Model
      │
      ▼
Generated Answers
      │
      ▼
 Evaluation
      │
      ▼
   Scores &
    Reports

Dado que cada paso es automático, se puede volver a ejecutar todo el examen siempre que haya algún cambio: la pregunta, la versión del modelo, la configuración de recuperación o la temperatura.

Por qué un examen estandarizado hace que las comparaciones sean justas

Considere cómo un equipo sensato contrata a un analista de datos. Con tres candidatos, no hablaría con cada uno sobre lo que se le ocurra y luego decidiría por intuición. Les daría a todos el mismo desafío en SQL, el mismo caso de negocio y el mismo problema analítico, para luego comparar los resultados.

La selección de modelos funciona de la misma manera. Los candidatos se convierten en GPT, Claude y Gemini; las preguntas de la entrevista pasan a ser preguntas de negocio, problemas de programación, tareas de resumen y tareas de generación de SQL. Una comparación solo tiene sentido cuando cada modelo realiza el mismo examen en condiciones idénticas. De lo contrario, está midiendo la diferencia entre las preguntas, no entre los modelos.

Por qué los LLM necesitan esto más que el código tradicional

La mayoría de los softwares convencionales son deterministas. Una expresión como esta:

2 + 2

tiene exactamente un resultado aceptable:

4

Cualquier otra cosa es un error, y una afirmación de igualdad es todo lo que necesita la prueba.

Los modelos de lenguaje no funcionan de esa manera. Pida a dos modelos que expliquen qué es un almacén de datos. Uno podría describirlo como un almacenamiento central de datos históricos integrados; el otro podría llamarlo un sistema que reúne datos de muchas fuentes para su análisis. Ambos están correctos, pero las descripciones no comparten casi nada. Incluso el mismo modelo puede expresar las cosas de forma diferente en cada ejecución.

Por lo tanto, la tarea pasa de verificar una salida exacta a juzgar la calidad: ¿es la respuesta correcta, relevante y completa, incluso cuando su redacción es nueva? Ese cambio representa la diferencia fundamental entre probar software y evaluar inteligencia artificial, y es por eso que existe un framework especial en lugar de una simple biblioteca de afirmaciones.

Los cuatro componentes de un framework

La mayoría de los harnesses, ya sean hechos en casa o comprados listos, se ensamblan con las mismas cuatro piezas.

Conjunto de datos de prueba

El conjunto de datos es como el examen: una colección de instrucciones, preguntas o tareas que representan lo que el sistema debe manejar. Un ejemplo breve y variado:

Write a SQL query to find duplicate customers.

Summarize this article in one paragraph.

Classify this customer support ticket.

Un harness nunca puede ser mejor que sus casos de prueba. Un conjunto de datos útil abarca las solicitudes comunes, los casos difíciles conocidos y los modos de fallo que ya se han observado en producción. Muchos equipos lo mantienen bajo control de versiones y añaden un caso cada vez que un usuario informa una respuesta incorrecta, de la misma manera en que se crea una prueba de regresión para cada corrección de error. Para saber por qué las respuestas esperadas también necesitan versionado, consulte el fijado de versiones de conjuntos de datos en suites de evaluación de LLM.

Modelo bajo prueba

Este es el sistema que se está analizando: GPT, Claude, Gemini, Llama, Mistral o su aplicación completa desarrollada con uno de ellos. Una ventaja clave del diseño es que el conjunto de datos se escribe una sola vez y se reutiliza para cada modelo que desee probar.

En la práctica, “el modelo” suele ser más que el modelo en sí. Puede tratarse de la plantilla de prompt, del paso de recuperación y del procesamiento posterior juntos, que es exactamente lo que experimentan los usuarios; por lo tanto, suele ser lo que debe probarse.

Lógica de evaluación

Una vez que llega una respuesta, algo debe calificarla. A veces eso es sencillo. La respuesta esperada es:

Paris

El modelo devuelve:

Paris

y el veredicto es:

Pass

Ese tipo de coincidencia exacta o normalizada funciona para respuestas factuales cortas, etiquetas de clasificación y salida estructurada. La mayoría de las aplicaciones reales necesitan criterios más detallados, como:

• Exactitud
• Relevancia
• Completitud
• Tasa de alucinaciones
• Tono
• Seguridad
• Fidelidad al material de origen

Muchos de estos aspectos no pueden verificarse mediante comparación de cadenas de texto, por lo que los sistemas modernos utilizan cada vez más un segundo modelo como evaluador, enfoque conocido como LLM-as-a-judge. Aunque es poderoso, introduce su propia fuente de errores, por lo que el evaluador necesita ser calibrado con etiquetas humanas; este artículo explica en detalle cómo crear una evaluación con un evaluador en quien se pueda confiar.

Informes

Finalmente, las puntuaciones individuales se agrupan en métricas y paneles de control. Un resumen simplificado podría verse así:

Model      Accuracy
GPT         92%
Claude      90%
Gemini      87%

Las cifras aquí son ilustrativas, no constituyen un punto de referencia. Lo importante son las decisiones que tal informe permite tomar:

• Qué modelo desplegar
• Si una nueva versión es mejor que la actual
• Si un cambio en el prompt realmente ha mejorado los resultados
• Si una versión es segura para producción

Regresiones: el fallo que está diseñado para detectar un harness

La razón más importante para invertir en un harness es evitar las regresiones. Supongamos que su asistente obtiene actualmente una puntuación de:

Accuracy = 92%

Alguien modifica el prompt para que las respuestas sean más amigables. Algunas verificaciones manuales parecen estar bien, por lo que se implementa el cambio. Tres días después aumentan los tickets de soporte, y cuando finalmente alguien investiga, la precisión ha disminuido a:

84%

Sin un sistema de gestión, los primeros en darse cuenta son los clientes. Con uno, el mismo cambio en las instrucciones se prueba con todo el conjunto de datos antes del despliegue, y la disminución en los resultados se manifiesta como una verificación fallida. Esto es el equivalente directo de un conjunto de pruebas de regresión en el desarrollo convencional. Trate las instrucciones, las versiones del modelo y los parámetros de recuperación como cambios de código que deben superar dichas pruebas.

Una precaución práctica: dado que la salida de los LLM varía entre ejecuciones, pequeñas diferencias en las puntuaciones pueden ser ruido. Ejecutar cada caso más de una vez o establecer un umbral de tolerancia antes de considerar algo como una regresión evita que las alarmas se activen inútilmente.

Dónde encaja la evaluación en el ciclo de vida del suministro de IA

Los principiantes suelen pensar que la ingeniería de IA se reduce principalmente a escribir instrucciones. Los sistemas en producción requieren un ciclo de vida completo, que en un equipo experimentado se estructura más o menos así:

Build
   ↓
Test
   ↓
Evaluate
   ↓
Compare
   ↓
Deploy
   ↓
Monitor

El sistema gestiona las etapas de prueba, evaluación y comparación. Si se omiten, las decisiones de despliegue se basan en impresiones en lugar de evidencias. El monitoreo después del lanzamiento introduce nuevos casos de fallo en el conjunto de datos, lo que mantiene el ciclo cerrado.

Un escenario práctico: un asistente de datos de ventas en Databricks

Para hacerlo más concreto desde la perspectiva de la ingeniería de datos, imagine un asistente desarrollado en Databricks que responde preguntas sobre datos de ventas. Los usuarios hacen consultas como:

What were total sales in Q1?

Who are our top customers?

Which regions experienced growth last year?

Antes de lanzar una nueva versión del modelo, el equipo reúne unas cuantascientas preguntas representativas. El sistema las ejecuta automáticamente y verifica:

• La calidad del SQL generado
• La precisión de las respuestas finales
• La consistencia entre ejecuciones
• La latencia
• Las alucinaciones

La nueva versión solo se promociona si su rendimiento es al menos igual al de la que está actualmente en producción. En efecto, esto constituye un CI/CD para una aplicación de IA: la ejecución de evaluación es una etapa del pipeline, y la puntuación sirve como filtro.

Un mismo framework, muchos modelos

¿Puede el mismo framework evaluar a GPT, Claude y Gemini simultáneamente? Sí, y comparar modelos es una de sus principales funciones. La clave está en mantener la lógica de evaluación independiente de cualquier proveedor específico, de modo que los modelos se conecten a través de una interfaz común:

Harness
   ├── GPT
   ├── Claude
   ├── Gemini
   └── Llama

Cada modelo recibe las mismas preguntas y es evaluado según las mismas reglas, lo que permite una comparación justa para su caso de uso concreto en lugar de un ranking genérico. Los resultados también son específicos de sus datos: el modelo que lidera en pruebas públicas no siempre es el que responde mejor a las preguntas de su equipo.

Herramientas que probablemente conocerá

Rara vez es necesario crear todo desde cero. Las opciones más utilizadas incluyen:

• OpenAI Evals
• DeepEval
• LangSmith
• MLflow Evaluation
• Promptfoo
• RAGAS, enfocado en evaluar pipelines RAG

Sus características e integraciones difieren, y cambian con rapidez, por lo que es necesario consultar la documentación actual al elegir. Comparten un mismo objetivo: medir la calidad antes de que sus usuarios lo hagan por usted.

Por qué los ingenieros de datos tienen una ventaja inicial

Los ingenieros de datos suelen pensar que la ingeniería de IA es una disciplina completamente separada. La superposición entre ambas es mayor de lo que parece. Los años dedicados a asegurarse de que los datos defectuosos nunca lleguen a un panel de control (definiendo expectativas, realizando verificaciones en cada carga y bloqueando su uso cuando fallan) son exactamente los hábitos que necesita la evaluación de IA. Lo que se prueba ha pasado de ser una tabla a las respuestas de un modelo; la disciplina ingenieril sigue siendo la misma.

Puntos clave

• Elegir el modelo más inteligente importa menos que poder medir cómo se comporta su sistema; la evaluación es lo que diferencia una demostración de un producto real.
• Un sistema de evaluación consta de cuatro partes: un conjunto de datos de prueba, el modelo que se está probando, la lógica de evaluación y la generación de informes. El conjunto de datos establece los límites para todo lo demás.

La salida de los LLM no puede verificarse únicamente mediante una igualdad exacta, por lo que la puntuación suele combinar verificaciones deterministas con criterios de calificación, a veces utilizando un modelo como juez.

Ejecutar el framework en cada cambio de prompt, modelo o configuración y bloquear las versiones que tengan una puntuación por debajo del umbral actual.

Mantener la independencia del proveedor de evaluación permite comparar los modelos de manera justa con los propios datos.

Un resumen útil en una sola línea: un framework de este tipo es el marco para pruebas unitarias, control de calidad y pruebas de regresión en aplicaciones basadas en LLM. Ningún equipo serio lanza software sin pruebas, y una función basada en LLM merece el mismo trato antes de llegar a producción.

Lecturas relacionadas

• Reverse Prompting: Convertir una buena sesión de LLM en un prompt reutilizable — Aprenda cómo extraer un prompt de uso único a partir de una conversación exitosa de múltiples turnos con un LLM, y cómo la inversión de prompts permite recuperarlos cuando solo se dispone de las salidas.
• Cambiar modelos de LLM de forma segura: Etiquetas humanas, métricas por paso y ajustes de esfuerzo — Cómo migrar un pipeline de LLM de múltiples pasos a modelos más recientes sin enfrentarse a regresiones imprevistas: datos reales proporcionados por humanos, métricas por paso, prompts obsoletos y medición del esfuerzo de razonamiento.