Marco de evaluación de LLM: cómo construirlo (y las herramientas para ejecutarlo)

Si su equipo cambia un prompt, sustituye un modelo o vuelve a fragmentar una base de conocimiento, alguien tiene que decidir si ese cambio puede salir a producción. Sin un marco de evaluación de LLM, esa decisión depende de unas cuantas comprobaciones manuales y de la opinión de quien haya revisado las respuestas por última vez, algo que aguanta en una demo y se rompe con la primera actualización del modelo.

En resumen: defina qué significa «bueno» para cada caso de uso, reúna de 50 a 200 ejemplos reales con el comportamiento esperado, puntúelos con una combinación de comprobaciones por código, jueces LLM calibrados y revisión humana, y bloquee cualquier versión que caiga por debajo de los umbrales acordados. Una primera versión funcional suele llevar de una a dos semanas de trabajo de un ingeniero. A partir de ahí, el coste recurrente son sobre todo las llamadas a la API del modelo juez y unas pocas horas de revisión humana al mes. Esta guía recorre los seis pasos y después compara ocho herramientas que los ejecutan. Si prefiere que le construyamos y gestionemos el marco, eso es lo que cubren nuestros servicios de evaluación de LLM.

Qué es un marco de evaluación de LLM

Un marco de evaluación de LLM es el proceso repetible que utiliza un equipo para demostrar que una funcionalidad basada en LLM es lo bastante buena para salir a producción: los objetivos de calidad, un golden dataset (conjunto de datos de referencia), las métricas, los evaluadores que las puntúan, los umbrales de aprobación y una periodicidad para ejecutarlo todo. Librerías como DeepEval y Ragas son las herramientas que ejecutan ese proceso.

La palabra «framework» se usa para dos cosas distintas, y confundirlas es la razón por la que muchos equipos acaban con una herramienta instalada y sin estrategia de evaluación. Su marco es el conjunto de decisiones: qué comportamientos importan, cómo se miden y qué puntuación bloquea una versión. Una librería de framework es código que ejecuta esas decisiones por usted, con implementaciones de métricas, ejecutores de pruebas y paneles. Puede cambiar de librería más adelante y conservar todas y cada una de esas decisiones.

Las pruebas individuales dentro del marco suelen llamarse LLM evals. Una eval puede comprobar que un bot de soporte nunca promete un importe de reembolso concreto; otra puntúa si un resumen se mantiene fiel al documento de origen.

Componentes principales de un marco de evaluación de LLM

Todo marco que funciona tiene las mismas seis partes, sea cual sea la herramienta que lo ejecute. Los objetivos y los datasets definen qué se prueba, las métricas y los evaluadores definen cómo se puntúa cada respuesta, y los umbrales y la periodicidad de ejecución deciden qué ocurre con la puntuación. Si falta una, el resto pierde gran parte de su valor: una métrica bien elegida sin umbral produce un número sobre el que nadie actúa, y un umbral que solo se comprueba antes del lanzamiento no detecta ninguna de las regresiones posteriores. La tabla muestra las seis partes para un asistente de atención al cliente.

Los evaluadores merecen un análisis más detallado, porque ahí se concentran la mayor parte del coste y la mayoría de los problemas de confianza:

• Las comprobaciones por código (regex, validación de esquema, coincidencia exacta, «¿ha llamado a la función correcta?») son baratas, deterministas y de alcance limitado. Úselas para todo lo que tenga una única respuesta correcta.
• LLM-as-a-judge puntúa a escala cualidades subjetivas como la faithfulness (fidelidad a la fuente), la utilidad o el tono. Cuesta una llamada a la API por puntuación y solo es tan fiable como su calibración.
• Los revisores humanos son el punto de referencia. Son demasiado lentos para puntuar cada ejecución, así que su función principal es etiquetar el conjunto de calibración y revisar los casos en los que los evaluadores automáticos no coinciden.

Cómo construir un marco de evaluación de LLM en 6 pasos

Estos seis pasos le llevan de «revisamos las respuestas a ojo» a un marco que decide qué versiones pueden salir. El orden importa: las métricas elegidas antes de definir los casos de uso tienden a medir lo que la herramienta pone fácil.

Paso 1: definir casos de uso y niveles de riesgo

Enumere cada tarea distinta que realiza el LLM en su producto. Un asistente de soporte puede responder preguntas sobre políticas, resumir un ticket para un agente y redactar una respuesta, y cada una de esas tareas falla de forma distinta. Después, asigne a cada caso de uso un nivel de riesgo, porque el nivel determina cuánto esfuerzo de evaluación merece.

Para cada caso de uso, escriba dos listas breves: lo que una buena respuesta debe hacer y lo que nunca debe hacer. Esas listas se convierten en sus objetivos de evaluación.

Paso 2: construir un golden dataset

Un golden dataset es un conjunto versionado de entradas con el comportamiento esperado para cada una. Es el activo más valioso del marco, porque todas las métricas y herramientas que añada después se ejecutan sobre él.

Buenas fuentes, más o menos por orden de valor:

• Logs de producción y tickets de soporte anonimizados, que muestran lo que preguntan realmente los usuarios
• Casos escritos por expertos en la materia para situaciones poco frecuentes pero costosas
• Casos adversariales y casos límite: intentos de prompt injection, preguntas fuera de alcance, peticiones ambiguas, otros idiomas
• Ejemplos sintéticos generados por un LLM para cubrir huecos, cada uno revisado por una persona antes de entrar en el conjunto

Empiece con entre 50 y 100 ejemplos por caso de uso de alto riesgo y amplíelo a partir de ahí. Cada registro debe incluir la entrada, el contexto recuperado si lo hay (en la generación aumentada por recuperación, o RAG), la respuesta esperada o una rúbrica de evaluación, y etiquetas como intención, idioma y dificultad. Las etiquetas son las que le permiten ver después los resultados por segmento. Guarde el dataset en el control de versiones junto a sus prompts, para que cada resultado de evaluación pueda rastrearse hasta la versión exacta del dataset que lo produjo.

Paso 3: elegir las métricas

Asigne a cada objetivo de evaluación definido en el paso de casos de uso una métrica que lo mida. La mayoría de los productos necesitan de tres a cinco métricas por caso de uso, extraídas de estos grupos:

• Corrección y anclaje en las fuentes: faithfulness, hallucination rate (tasa de alucinaciones), answer relevancy (relevancia de la respuesta) y, en RAG, context precision (precisión del contexto) y context recall (exhaustividad del contexto)
• Éxito de la tarea: task completion (finalización de la tarea) y, en agentes, tool-call correctness (corrección de las llamadas a herramientas)
• Seguridad: toxicidad, fuga de datos personales, rechazos correctos, resistencia a prompt injection
• Formato: validez del esquema, límites de longitud, presencia de los campos obligatorios
• Operativas: latencia y coste por respuesta, monitorizados junto a la calidad para que se vea un prompt «mejor» que triplica el coste

Nuestro desglose de métricas de evaluación de LLM explica cómo se calcula cada una y en qué casos puede inducir a error.

Los agentes necesitan una capa adicional. Una respuesta final correcta puede ocultar un mal camino hasta ella: la herramienta equivocada llamada en primer lugar, un bucle de reintentos, una acción de escritura que nunca debería haberse ejecutado. Puntúe la trayectoria además del resultado; nuestra guía de métricas de evaluación de agentes de IA lo explica paso a paso.

Cómo definimos las métricas para Granola. En Granola, un bloc de notas con IA que convierte el audio de las reuniones y las notas en bruto en resúmenes estructurados, evaluamos las respuestas del LLM en cuanto a precisión factual, alucinaciones y capacidad de mantener el contexto adecuado en conversaciones complejas de varios turnos. Como las notas generadas cambian en cada ejecución, las comprobaciones de coincidencia exacta no servían para puntuarlas, así que usamos LLMs dentro de nuestros scripts de automatización para verificar los resúmenes, con DeepEval entre las herramientas, y ejecutamos la suite en CI. La configuración completa se describe en nuestro caso de estudio sobre automatización de pruebas para Granola.

Paso 4: elegir evaluadores y calibrar los jueces

Utilice una comprobación determinista siempre que exista. Recurra a un juez LLM solo para las cualidades que el código no puede puntuar, y no confíe en ningún juez hasta que se haya calibrado frente a personas.

Una rutina de calibración práctica:

1. Tome de 50 a 100 respuestas de su golden dataset y pida a dos personas que las etiqueten de forma independiente según la rúbrica.
2. Resuelva los casos en los que las dos personas no coinciden. Si discrepan a menudo, la rúbrica es ambigua, así que corríjala antes de involucrar a un modelo.
3. Ejecute el juez LLM sobre las mismas respuestas y mida con qué frecuencia coincide con las etiquetas humanas.
4. Ajuste el prompt del juez (criterios más claros, ejemplos resueltos, una escala más reducida) hasta que el nivel de acuerdo sea aceptable para ese nivel de riesgo.
5. Vuelva a calibrar siempre que cambie el modelo juez, la rúbrica o el dominio del producto.

Algunos hábitos hacen que los jueces sean más fiables. Un aprobado/suspenso binario o una escala de tres puntos es más fácil de calibrar que una puntuación sobre diez. Pedir al juez que escriba su razonamiento antes del veredicto mejora la consistencia. Fije la versión del modelo juez para que las puntuaciones sigan siendo comparables con el tiempo y, cuando sea posible, utilice una familia de modelos distinta de la que se evalúa, ya que los modelos tienden a valorar favorablemente su propio estilo. En las comparaciones por pares, ejecute cada par en ambos órdenes para neutralizar el sesgo de posición.

Paso 5: integrar las evaluaciones en CI y fijar criterios de bloqueo

Una evaluación que alguien tiene que acordarse de ejecutar acabará por no ejecutarse. Inclúyala en el pipeline:

• En cada pull request que modifique un prompt, la configuración del modelo, la configuración de recuperación o la definición de una herramienta, ejecute un subconjunto rápido del golden dataset que termine en minutos.
• Cada noche o antes de cada versión, ejecute el dataset completo con todas las métricas.

Después, decida qué bloquea un merge. Los criterios de bloqueo estrictos (hard gates) son comprobaciones de tolerancia cero: fallos de esquema, fallos de seguridad, una llamada a herramienta de alto riesgo realizada sin confirmación. Los criterios flexibles (soft gates) comparan las métricas de calidad con la línea base actual de producción y fallan cuando cualquier segmento cae más de un margen acordado. Comparar con una línea base funciona mejor que fijar objetivos absolutos, porque la salida de un LLM varía de una ejecución a otra. Reduzca ese ruido fijando la temperatura cuando el producto lo permita, o muestreando cada caso varias veces y puntuando la media.

Esta es la base de las pruebas de regresión de LLM: cada cambio se evalúa frente a la última versión que se sabe correcta, segmento a segmento.

Presupueste las llamadas al juez. Una ejecución completa de 200 casos con tres métricas evaluadas por juez supone 600 llamadas al juez, así que una suite nocturna más las ejecuciones en pull requests suman bastante a lo largo de un mes. Las comprobaciones por código no cuestan nada, otro motivo para usarlas primero.

Paso 6: monitorizar producción y devolver los fallos al dataset

La evaluación previa al lanzamiento solo cubre las entradas que usted ha previsto, así que la monitorización en producción tiene que detectar el resto. Registre la traza de cada llamada al LLM (entrada, contexto recuperado, llamadas a herramientas, respuesta, latencia, coste), ejecute sus jueces sobre una muestra del tráfico real y vigile las señales de los usuarios, como las valoraciones negativas, las escalaciones a una persona y las sesiones abandonadas.

Una vez a la semana, haga un triaje de los fallos. Cada fallo real que revele un patrón nuevo se convierte en un nuevo caso del golden dataset, de modo que la siguiente versión se prueba contra él automáticamente. Mantener este ciclo de forma continua, con responsables, periodicidad y alertas de deriva, es la práctica conocida como EvalOps.

Mejores marcos y herramientas de evaluación de LLM

Una vez definidos los seis pasos, una herramienta los ejecuta. El mercado se divide entre librerías de código abierto que usted mismo ejecuta y plataformas gestionadas que añaden trazas, paneles y colas de revisión. Muchos equipos acaban con una de cada: una librería para las pruebas en CI y una plataforma para las trazas de producción.

Si su producto es principalmente un pipeline de recuperación, nuestra comparativa de herramientas de evaluación de RAG profundiza más que esta guía general en la puntuación específica de la recuperación.

Cómo elegir el marco de evaluación de LLM adecuado para su equipo

Parta de tres restricciones: su stack, el tamaño de su equipo y adónde pueden ir sus datos. El stack determina cuánto trabajo de integración necesita una herramienta, ya que una librería que encaje con su lenguaje y su runner de CI puede estar bloqueando pull requests en cuestión de días. El tamaño del equipo determina si una plataforma alojada sale rentable, y la residencia de los datos suele descartar opciones antes de comparar ninguna funcionalidad.

Según el tamaño del equipo. A uno o dos ingenieros les funciona mejor una única librería de código abierto en CI y una hoja de cálculo con etiquetas humanas; en esta fase, una plataforma añade sobre todo trabajo de configuración. Los equipos de entre cinco y veinte personas, aproximadamente, suelen añadir una plataforma de trazas cuando el tráfico de producción es significativo, porque muestrear el tráfico real a mano deja de escalar. Las organizaciones más grandes o reguladas necesitan control de acceso basado en roles, registros de auditoría y, a menudo, autoalojamiento, lo que las lleva hacia planes Enterprise o hacia soluciones de código abierto autoalojadas.

Según la residencia de los datos. Si los prompts o las respuestas contienen datos personales, financieros o de salud, averigüe pronto si las trazas pueden salir de su infraestructura. Langfuse y Phoenix se pueden autoalojar en sus planes gratuitos; LangSmith, Braintrust y la plataforma Confident AI solo ofrecen autoalojamiento en los planes Enterprise. Los modelos juez también cuentan: un juez LLM envía cada respuesta puntuada a su proveedor, así que un panel autoalojado no basta por sí solo para mantener los datos en casa.

Cuándo no necesita una plataforma. Si tiene una sola funcionalidad basada en LLM, un tráfico moderado y un equipo que ya trabaja en CI, una librería más un golden dataset en git cubren la mayor parte de lo que aportaría una plataforma. Añada una plataforma cuando el muestreo en producción, las colas de revisión o el acceso de perfiles no técnicos se conviertan en necesidades reales.

La elección de herramienta también es más fácil de revertir de lo que parece, siempre que el golden dataset, las rúbricas y los umbrales vivan en su repositorio en un formato sencillo. Todo eso se traslada a cualquier herramienta; los paneles y las trazas almacenadas, normalmente no.

Errores habituales en la evaluación de LLM

1. Evaluar una sola vez. Una evaluación hecha la semana del lanzamiento solo cubre la versión lanzada, y la siguiente edición del prompt, la próxima actualización del modelo por parte del proveedor o los documentos que se añadieron el mes pasado a la base de conocimiento pueden deshacer el resultado. Una evaluación que no está en CI ni muestrea producción se queda obsoleta en pocas semanas.

2. Confiar en un juez sin calibrar. Un juez LLM produce puntuaciones seguras y aparentemente coherentes tanto si coinciden con el criterio humano como si no. Sin la rutina de calibración descrita en el paso de los jueces, un equipo puede pasarse meses optimizando un prompt hacia un número que no refleja lo que viven los usuarios.

3. Dejar que las medias oculten segmentos que fallan. Supongamos que la faithfulness global es de 0,92. Esa media puede incluir un segmento en español con 0,70 o un segmento de preguntas sobre reembolsos que falla una de cada cinco veces. Etiquete su golden dataset, informe de cada métrica por segmento y bloquee en función del peor segmento además de la media.

4. Sin ciclo de retroalimentación desde producción. Si los fallos reales nunca vuelven al golden dataset, el dataset se va alejando poco a poco de lo que preguntan los usuarios. La suite de pruebas sigue pasando mientras aumentan las quejas. Un triaje semanal que convierta los fallos de producción en nuevos casos de prueba es la solución más barata de esta lista.

5. Probar solo el camino feliz. Un dataset construido con preguntas limpias y bien formuladas pasa por alto lo que rompe las funcionalidades basadas en LLM en la práctica: peticiones ambiguas, preguntas fuera de alcance, prompt injection, entradas muy largas y usuarios que cambian de idioma a mitad de conversación. Procure que al menos una quinta parte de cada dataset de alto riesgo sean casos límite y adversariales.

Cómo construye y gestiona QAwerk la evaluación de LLM

La mayoría de los equipos acuden a nosotros en uno de estos dos momentos: antes de lanzar su primera funcionalidad basada en LLM, o después de que un cambio de modelo o de prompt haya provocado ya una regresión visible. Empezamos en el punto en que esté el proyecto. En un producto existente, el primer paso suele ser una auditoría de lo que el equipo ya mide, seguida de un golden dataset construido a partir del tráfico real y de los casos de uso de alto riesgo.

A partir de ahí, nuestros ingenieros de QA ponen en marcha las seis partes descritas anteriormente:

• Casos de uso clasificados por nivel de riesgo y objetivos de evaluación por escrito, acordados con su product owner
• Un golden dataset versionado con etiquetas por segmento y casos adversariales
• Métricas y evaluadores adaptados a cada objetivo, con jueces LLM calibrados frente a etiquetas humanas
• Ejecuciones de evaluación integradas en su pipeline de CI, con criterios de bloqueo estrictos y flexibles
• Muestreo en producción y un triaje semanal de fallos que mantiene el dataset al día

Trabajamos como una extensión de su equipo: usamos su repositorio, su CI y las herramientas que usted haya elegido, de modo que no hay que migrar nada cuando nos retiramos. En productos con mucha recuperación, la misma configuración se amplía a pruebas de RAG específicas del recuperador, la fragmentación y el anclaje en las fuentes.

Si quiere que le construyamos y gestionemos un marco de evaluación, nuestros ingenieros de QA pueden configurar su golden dataset, sus métricas, los jueces calibrados y los criterios de bloqueo en CI, y mantenerlos actualizados a medida que cambie su producto. Cuéntenos cómo es su producto basado en LLM y le indicaremos por dónde empezar.

Preguntas frecuentes

Mira cómo construimos y mantuvimos más de 1.100 casos de prueba para Granola, un bloc de notas de IA, y automatizamos el 76% de su suite de regresión

Por favor ingrese su correo electrónico comercial no es un correo electrónico comercial

Obtener Caso de Estudio