Las 10 principales métricas de evaluación de LLM que debe comprender antes de su lanzamiento

Implementar un modelo de aprendizaje automático (LLM) sin una estrategia de evaluación adecuada es un riesgo que la mayoría de los equipos no perciben. El 67 % de las organizaciones a nivel mundial ya utilizan LLM en producción, pero la mayoría aún se basa en métricas de evaluación diseñadas para la traducción automática de 2018 o, directamente, omite la evaluación estructurada. El resultado es predecible: fallos que acaparan titulares, chatbots que ofrecen consejos ilegales y actualizaciones de modelos que provocan errores silenciosos que nadie nota hasta que los usuarios empiezan a abandonar la plataforma.

Este artículo aborda las métricas de evaluación de LLM que realmente importan. Analizaremos qué mide cada una, cuándo usarla, qué puntuación buscar y los detalles que la mayoría de los equipos pasan por alto. Si está pensando en contratar un equipo de control de calidad especializado o cualquier otro tipo de servicio de pruebas para evaluar sus herramientas basadas en LLM, sin duda necesita conocer esta información.

Las 10 métricas de evaluación de LLM más importantes

Antes de profundizar, hay algo que debes saber: las métricas adecuadas para la evaluación de un LLM dependen de en cuál de los tres contextos te encuentres:

• Evaluación del modelo base
  Seleccionar o ajustar un modelo LLM y evaluar su capacidad operativa.
• Evaluación de pipelines RAG
  Combinar un modelo de lógica descriptiva con un sistema de recuperación y evaluar la cadena completa, no solo el modelo.
• Evaluación de agentes
  Un LLM realiza acciones, utiliza herramientas y toma decisiones en varios pasos, lo que requiere métricas de evaluación específicas para los agentes LLM que la mayoría de los puntos de referencia LLM estándar no cubren.

Ten en cuenta el contexto mientras lees. Las métricas que aparecen a continuación se corresponden con las tres, y la tabla resumen muestra a qué se aplica cada una.

Fidelidad

La fidelidad mide si la salida del modelo contradice el material de origen que se le proporcionó. Si su modelo LLM responde basándose en documentos recuperados, una respuesta fiel solo incluye afirmaciones directamente respaldadas por dichos documentos. Cualquier afirmación que vaya más allá de la fuente es una mera suposición.

Esta métrica de evaluación es fundamental a la hora de implementar las mejores prácticas de RAG y desarrollar un flujo de trabajo. Es imprescindible si su producto responde preguntas basadas en documentos internos, bases de conocimiento o datos externos. El objetivo es obtener una puntuación superior a 0,8 en una escala normalizada de 0 a 1, medida mediante marcos de trabajo como Ragas o DeepEval. Si la puntuación es inferior a 0,7, es probable que exista un problema de detección de alucinaciones en LLM a gran escala.

Relevancia de la respuesta

La métrica de relevancia de la respuesta es esencial para los bots de atención al cliente, las herramientas internas de preguntas y respuestas, los asistentes de documentación y cualquier interfaz donde los usuarios formulen preguntas directas y esperen respuestas directas. Mide si la respuesta aborda realmente la pregunta del usuario. Un modelo puede ser completamente fiel a su material de origen y aun así dar una respuesta que se desvíe del tema o responda a una pregunta diferente a la formulada. Al evaluar, busque puntuaciones de 1 o más, ya que cualquier valor inferior a 0,75 suele indicar que el modelo está parafraseando el contexto en lugar de responder al usuario.

Precisión contextual y recuperación contextual

En las métricas de evaluación de LLM, estas son dos caras de la misma moneda, y se encuentran en la capa de recuperación de su canalización RAG, no en la capa de generación.

La precisión del contexto indica qué parte de la información recuperada fue realmente útil para responder a la pregunta. Una alta precisión significa que el sistema de recuperación no incluye información irrelevante.

La recuperación de contexto indica cuánta información necesaria para responder a la pregunta estaba presente en los fragmentos recuperados. Si el nivel de recuperación es alto, el sistema de recuperación no omite contenido crucial.

Debe tener en cuenta estas métricas de evaluación LLM siempre que depure un sistema RAG que arroje puntuaciones bajas de fidelidad o relevancia. A menudo, el modelo funciona correctamente y el problema reside en la etapa anterior del recuperador.

Tasa de alucinaciones

Esta es una de las principales métricas de evaluación de LLM que mide el porcentaje de resultados que contienen afirmaciones incorrectas. A diferencia de la fidelidad, que compara el resultado con un contexto recuperado, la tasa de alucinaciones mide la precisión fáctica en comparación con la verdad fundamental, lo que dificulta su automatización, pero la hace más relevante para casos de uso de alto riesgo.

Esta es una métrica de evaluación crucial para el desarrollo de soluciones de IA en aplicaciones legales, médicas, financieras o de cumplimiento normativo, donde un error de hecho puede tener consecuencias reales. Además, es esencial para cualquier producto en el que los usuarios probablemente actúen basándose en los resultados del modelo sin verificarlos.

Para la mayoría de las métricas de evaluación de LLM en producción, el objetivo es una tasa de alucinaciones inferior al 5 %. Si se trata de un ámbito de alto riesgo, ese umbral debería estar más cerca del 1 %.

AZUL y ROJO

Algunas métricas de rendimiento de LLM basadas en referencias comparan la salida de un modelo con una respuesta correcta conocida. Estas son:

• BLEU (Bilingual Evaluation Understudy)
  Mide la superposición de n-gramas entre el texto generado y el texto de referencia, centrándose en la precisión. Fue diseñado originalmente para la traducción automática.
• ROUGE (Recall-Oriented Understudy for Gisting Evaluation)
  Se centra en la capacidad de recordar y se utiliza habitualmente para evaluar la calidad de los resúmenes.

Es necesario utilizar estas métricas al crear flujos de trabajo de traducción, tareas de resumen estructurado y herramientas de generación de documentos, donde se cuenta con un resultado correcto definido. Un BLEU superior a 0,4 suele ser aceptable para la traducción. Por otro lado, un ROUGE-L superior a 0,5 constituye una base razonable para el resumen.

Sin embargo, nunca se deben usar BLEU ni ROUGE como métricas independientes para evaluar la comprensión lectora en aplicaciones abiertas. Un estudio publicado en 2024 confirmó que ambas métricas son malos predictores del rendimiento real en tareas de conversación o razonamiento. Penalizan las paráfrasis válidas y no detectan la equivalencia semántica. Son útiles como herramientas, pero no como indicador principal.

Perplejidad

Esta métrica de evaluación de LLM no guarda relación con Perplexity AI. Mide la confianza con la que el modelo predice el siguiente token en una secuencia. Una menor perplejidad indica que el modelo tiene mayor certeza sobre sus resultados. Es un indicador de fluidez y coherencia a nivel de modelado del lenguaje.

Es necesario evaluar la perplejidad del modelo durante la evaluación inicial y el ajuste fino. Esto resulta útil para comparar versiones del modelo o medir el impacto de una ejecución de entrenamiento en la fluidez de la salida.

Puntuación de toxicidad y sesgo

La puntuación de toxicidad mide la frecuencia con la que un modelo produce contenido dañino, ofensivo o discriminatorio. Esta métrica de evaluación permite identificar resultados que incluyen insultos, amenazas o material explícito. Por otro lado, las puntuaciones de sesgo revelan patrones en los que el modelo trata sistemáticamente a los grupos de manera diferente.

Debes implementar estas métricas de evaluación LLM en cada despliegue orientado al cliente, sin excepción. Más allá de la experiencia del usuario, la Ley de IA de la UE, vigente desde 2024, exige que los sistemas de IA de alto riesgo demuestren haber realizado pruebas de precisión y seguridad en función de las características protegidas. Esto es ahora un requisito de cumplimiento, no una verificación de calidad opcional.

Para evaluar esto en su producto, puede usar la API Perspective de Google (para toxicidad) y conjuntos de evaluación LLM personalizados adaptados a su dominio específico. Sin embargo, tenga en cuenta que los clasificadores de toxicidad genéricos a menudo pasan por alto daños sutiles y específicos del contexto. Un generador de documentos legales podría producir contenido que pase los filtros de toxicidad estándar, pero que aun así exponga a su organización a responsabilidades legales. Los conjuntos de evaluación específicos del dominio son importantes en este caso, así que asegúrese de tenerlo en cuenta con un plan de pruebas de IA personalizado.

Tasa de finalización de tareas

La tasa de finalización de tareas se utiliza para determinar si el LLM realmente logra el objetivo asignado. Esta es la métrica de evaluación más importante para los agentes LLM y la que la mayoría de los equipos mide al final, si es que la miden. Para un sistema basado en agentes, la tasa de finalización de tareas plantea la siguiente pregunta: ¿El agente terminó el trabajo? No se trata de si produjo una respuesta, sino de si logró el objetivo, utilizó las herramientas adecuadas y alcanzó un estado final válido.

Cualquier sistema en el que el LLM realice acciones en lugar de simplemente generar texto debe evaluarse según este parámetro. Los sistemas de reservas, los agentes de generación de código, la automatización de flujos de trabajo y las canalizaciones de análisis de datos son algunos de los principales ejemplos donde una alta tasa de finalización de tareas es un requisito indispensable. Dependiendo en gran medida de la complejidad de la tarea, se recomienda alcanzar un 90 % o más para tareas sencillas de un solo paso. Para flujos de trabajo de agentes de varios pasos, un 70 % suele considerarse un buen resultado, y cualquier valor inferior al 50 % indica que el agente necesita ser revisado antes de su lanzamiento.

Tenga en cuenta que la tasa de finalización de tareas es prácticamente imposible de medir sin un marco de evaluación LLM adecuado. Por lo tanto, es necesario definir criterios de éxito para cada tipo de tarea antes de comenzar a medir. Si su equipo aún no ha redactado dichos criterios, ese es el primer paso a seguir.

Compromiso entre latencia y calidad

Este es algo diferente en cuanto a las métricas de evaluación de LLM. No se trata de una sola métrica, sino de la relación entre dos factores: el tiempo de respuesta del modelo y la calidad de dicha respuesta. En producción, estas dos dimensiones se encuentran en constante tensión. Un modelo más lento, pero más potente, podría generar mejores resultados, pero frustraría a los usuarios que esperan respuestas en menos de dos segundos.

Cada implementación en producción requiere definir umbrales de latencia aceptables junto con umbrales de calidad. Saber cómo evaluar el rendimiento de LLM de forma aislada ofrece una visión incompleta de si el modelo está realmente listo para su lanzamiento.

Qué rastrear:

• Tiempo hasta el primer token (para interfaces de transmisión)
• Latencia de respuesta total (para procesamiento por lotes o sin transmisión continua)
• Puntuación de calidad en cada intervalo de latencia

Los equipos suelen optimizar la calidad durante el desarrollo y descubren problemas de latencia en las pruebas de carga. Si utiliza pruebas de rendimiento como parte de su proceso de control de calidad, asegúrese de incluir la latencia de LLM en el plan de pruebas desde el principio, y no como una consideración posterior.

Puntuación del LLM como juez (G-Eval)

En este caso, se utiliza un modelo de lenguaje natural secundario para evaluar los resultados del modelo de IA según un conjunto de criterios de lenguaje natural. G-Eval, presentado en la investigación de Liu et al. (2023), es una de las implementaciones más utilizadas de este enfoque. En lugar de basarse en la superposición de n-gramas o en comprobaciones basadas en reglas, un modelo de evaluación lee el resultado y lo califica según dimensiones como la coherencia, la relevancia y la finalización de la tarea.

Debe tener en cuenta esta métrica de evaluación LLM con tareas abiertas donde no hay una única respuesta correcta, generación de formularios extensos, tareas de razonamiento y cualquier caso en el que necesite una señal de calidad escalable similar a la humana sin tener que pagar a anotadores humanos en cada ejecución de evaluación.

La ventaja de la evaluación con LLM como juez radica en que usted controla los criterios de puntuación. Sin embargo, no olvide que los jueces de LLM tienen sus propios sesgos. Las estrategias para mitigar esto incluyen usar un modelo diferente como juez, usar varios jueces y promediar las puntuaciones, y calibrar al juez con anotaciones humanas en un conjunto de muestra.

Cómo elegir las métricas adecuadas para su caso de uso

No todas las métricas son aplicables a todos los productos. Sin embargo, existe una regla que se aplica a todas ellas: siempre es recomendable combinar al menos una métrica basada en referencias con una métrica independiente y una métrica específica para la tarea. Una sola métrica nunca es suficiente, y usar más de cinco sin un propósito claro genera confusión.

Métricas clave para el retorno de la inversión en la plataforma de evaluación de LLM

Crear un proceso de evaluación para un LLM requiere tiempo y dinero por adelantado, pero no crearlo cuesta aún más. A continuación, se explica cómo plantear el argumento del retorno de la inversión:

• Costo de un solo incidente de alucinación en la producción: El caso de la alucinación del chatbot de Air Canada resultó en un fallo judicial que obligó a la aerolínea a respetar un precio que el bot nunca debió haber ofrecido. Los costos reputacionales y legales de ese incidente superaron con creces cualquier inversión en infraestructura de evaluación de LLM.
• Costo de una mala selección de modelos: Solo el 5 % de los programas de IA genómica logran una rápida aceleración de los ingresos. Uno de los modos de fallo más frecuentes es que los equipos seleccionen o ajusten un modelo sin un proceso de evaluación LLM estructurado para medir la calidad de los resultados del LLM y verificar que realmente funcione para su caso de uso.
• Costo de no realizar pruebas de regresión: Cada actualización del modelo introduce la posibilidad de regresión. Sin métricas de evaluación de LLM monitoreadas a lo largo del tiempo, no se cuenta con un sistema de alerta temprana. Por lo tanto, integrar las pruebas de regresión en el proceso de control de calidad es fundamental.

Los equipos que implementan flujos de evaluación LLM estructurados reportan consistentemente menores tasas de defectos y ciclos de iteración más rápidos, ya que pueden actualizar los modelos de forma segura sin temor a regresiones silenciosas. Los servicios de pruebas de IA de QAwerk se basan precisamente en este enfoque. Contáctenos hoy y desarrollemos un plan a medida para sus objetivos comerciales.

Descubre cómo ayudamos a esta aplicación con inteligencia artificial a expandirse a nivel nacional

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

Obtener PDF