Métricas de Evaluación de LLM: 17 Métricas, Umbrales y Cuándo Usarlas

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. Ya sea que ejecutes la evaluación internamente o recurras a servicios de evaluación de LLM, estos son los números que deciden si tu producto está listo para lanzarse.

¿Qué Es la Evaluación de LLM y Cómo se Evalúa un LLM?

La evaluación de LLM es el proceso de puntuar las salidas de un modelo de lenguaje frente a criterios definidos para decidir si una aplicación está lista para lanzarse, o sigue siendo segura de ejecutar tras un cambio. Como un mismo prompt puede devolver distintas respuestas válidas, la evaluación sustituye las aserciones de aprobado o fallido por métricas puntuadas y umbrales acordados. Para evaluar una aplicación de LLM, sigue cinco pasos:

1. Define el caso de uso y su nivel de riesgo.
2. Construye un conjunto de datos de referencia con entradas típicas, casos límite y adversarias.
3. Elige métricas para cada capa: generación, recuperación, acciones del agente, seguridad y operaciones.
4. Fija un umbral por métrica y puntúa cada candidato a lanzamiento frente a él.
5. Sigue puntuando una muestra del tráfico de producción para detectar la deriva.

Si todavía estás definiendo tu caso de uso o construyendo un conjunto de datos de referencia, nuestra lista de verificación de pruebas de LLM cubre ambos en detalle. Esta guía se centra en lo que viene después: elegir métricas, fijar umbrales y medir la calidad tras el lanzamiento.

Tipos de Métricas de Evaluación de LLM

Toda métrica de LLM se sitúa en dos ejes: si necesita una respuesta de referencia y si la puntuación la hace una fórmula o un modelo. Saber dónde se sitúa una métrica te dice cuándo puedes ejecutarla y qué pasará por alto.

Las métricas basadas en referencia comparan la salida con una respuesta correcta conocida, por lo que necesitan un conjunto de datos de referencia etiquetado. Son fiables antes del lanzamiento, pero no pueden ejecutarse sobre el tráfico en vivo, donde no existe referencia. Las métricas sin referencia juzgan la salida por sí sola o frente a la entrada del usuario y el contexto recuperado, por eso cargan con la mayor parte del trabajo en producción.

Las métricas estadísticas usan fórmulas fijas, como el solapamiento de n-gramas o las probabilidades de los tokens. Son baratas, rápidas y reproducibles, pero puntúan la redacción en lugar del significado. Las métricas basadas en modelos usan un modelo de incrustaciones, un clasificador o un segundo LLM que actúa como juez. Capturan el significado y los matices, pero cuestan dinero por llamada y heredan los sesgos del modelo que puntúa.

Una suite equilibrada usa al menos una métrica de cada fila. Las métricas estadísticas dan una línea base estable para las verificaciones de regresión, mientras que las métricas basadas en modelos te dicen si la respuesta era realmente correcta.

Métricas de Evaluación de LLM de un Vistazo: Umbrales por Nivel de Riesgo

Para bloquear un mal lanzamiento, cada métrica necesita una nota de aprobación acordada antes de empezar las pruebas. La tabla siguiente enumera las 17 métricas de esta guía con los umbrales iniciales que usamos, divididos en dos niveles de riesgo. El nivel general cubre herramientas internas y asistentes de cara al cliente donde una persona todavía puede detectar un error. El nivel de alto impacto cubre productos legales, médicos, financieros y de cumplimiento, además de cualquier app donde los usuarios actúan sobre una respuesta sin comprobarla.

Las puntuaciones en una escala de 0 a 1 están normalizadas, que es como las informan Ragas y DeepEval. Trata estos números como puntos de partida y luego calíbralos: puntúa entre 50 y 100 ejemplos etiquetados por humanos y mueve cada umbral al punto donde las respuestas buenas y malas realmente se separan en tus datos.

Métricas de Generación y Calidad

Las métricas de generación puntúan el texto que produce el modelo, sea cual sea el pipeline que hay detrás. Se aplican a toda app de LLM, desde un chatbot de soporte hasta un resumidor de contratos. Empieza con este grupo y luego añade las métricas de RAG, agentes y seguridad que correspondan a tu arquitectura.

1. Relevancia de la Respuesta

La relevancia de la respuesta mide si la respuesta aborda lo que el usuario realmente preguntó. Un modelo puede ser fiel a sus fuentes y aun así responder otra pregunta, un fallo común en bots de soporte que parafrasean el centro de ayuda en lugar de resolver el problema.

• Cómo se calcula: en Ragas, un LLM escribe tres preguntas que la respuesta respondería, y la puntuación es la similitud coseno media entre sus incrustaciones y la pregunta original.
• Herramientas: Ragas y DeepEval.
• Umbral: 0.70 o más para uso general y 0.80 o más para productos de alto impacto.
• Ejemplo práctico: un usuario pregunta si puede cambiar una dirección de entrega después del pago, y el bot responde con toda la política de devoluciones. Las preguntas reconstruidas tratan sobre plazos de devolución, la puntuación queda cerca de 0.4 y el caso falla.

Cuando la relevancia es baja en todo el conjunto de pruebas, revisa el prompt del sistema antes de culpar al modelo. Un prompt vago o sobrecargado reduce esta puntuación incluso en modelos capaces.

2. Tasa de Alucinación

La tasa de alucinación es la proporción de respuestas que contienen al menos una afirmación falsa, verificada contra la verdad de referencia y no contra el contexto recuperado. Es la métrica que detecta chatbots que dan consejos ilegales, como el bot MyCity de la ciudad de Nueva York, que, según descubrió The Markup, decía a los empleadores que podían quedarse con una parte de las propinas de sus trabajadores.

• Cómo se calcula: divide cada respuesta en afirmaciones atómicas, verifica cada afirmación contra una fuente fiable y cuenta la respuesta como alucinada si alguna afirmación falla. Esto sigue a FActScore (Min et al., 2023), que encontró que solo el 58% de los hechos atómicos de las biografías generadas por ChatGPT estaban respaldados.
• Herramientas: DeepEval, el paquete FActScore y revisión humana sobre una muestra.
• Umbral: 5% o menos para uso general y 1% o menos para productos de alto impacto.
• Ejemplo práctico: un conjunto de pruebas tiene 200 preguntas sobre una política de licencias de RR. HH., y 9 respuestas indican un número de días incorrecto. Eso es una tasa del 4.5%, que aprueba el nivel general y no aprueba el de alto impacto.

La verificación automatizada de afirmaciones sigue necesitando una muestra revisada por humanos para confirmar que el propio verificador acierta. Reserva presupuesto para esa revisión antes de convertir esto en una barrera de lanzamiento.

3. BLEU y ROUGE

BLEU y ROUGE puntúan el solapamiento de palabras entre la salida y una respuesta de referencia. BLEU (Papineni et al., 2002) está orientado a la precisión y se diseñó para la traducción automática, mientras que ROUGE (Lin, 2004) está orientado a la exhaustividad y se diseñó para la generación de resúmenes.

• Cómo se calcula: BLEU cuenta las secuencias de palabras coincidentes de una a cuatro palabras y penaliza las salidas demasiado cortas. ROUGE-L usa la subsecuencia común más larga entre la salida y la referencia.
• Herramientas: sacreBLEU, rouge-score y Hugging Face Evaluate.
• Umbral: las puntuaciones absolutas varían según el par de idiomas y el conjunto de datos, así que establece la barrera sobre el cambio. Bloquea un lanzamiento cuando la puntuación caiga más de un 5% por debajo de la última línea base, o un 2% en productos de alto impacto.
• Ejemplo práctico: la referencia dice “Los reembolsos se procesan en un plazo de cinco días hábiles” y la salida dice “Procesamos los reembolsos en cinco días laborables”. El significado es idéntico, pero el solapamiento es pequeño, así que BLEU la puntúa mal.

El artículo de G-Eval señala que ambas métricas se correlacionan débilmente con el juicio humano, especialmente en tareas que exigen creatividad. Mantenlas como señales de regresión para traducción y resumen estructurado, no como la barrera principal para respuestas abiertas.

4. BERTScore

BERTScore compara el significado en lugar de las palabras exactas, lo que resuelve el problema de las paráfrasis descrito arriba. Es una métrica basada en referencia y basada en modelos, así que todavía necesita una respuesta de referencia.

• Cómo se calcula: BERTScore (Zhang et al., 2019) incrusta cada token de la salida y de la referencia, empareja cada token con su equivalente más similar e informa precisión, exhaustividad y F1.
• Herramientas: el paquete bert-score y Hugging Face Evaluate. Usa puntuaciones reescaladas, ya que las puntuaciones sin procesar se agrupan en una banda alta y estrecha.
• Umbral: relativo a la línea base, igual que BLEU y ROUGE.
• Ejemplo práctico: el par de reembolsos de arriba puntúa alto en BERTScore a pesar de su baja puntuación BLEU. Sin embargo, una salida que dice “quince días hábiles” también puntúa alto, porque una palabra cambiada apenas mueve la incrustación.

Ese segundo resultado es el principal límite de las métricas de similitud. Combina BERTScore con una verificación factual como la tasa de alucinación siempre que importen números, fechas o nombres.

5. Perplejidad

La perplejidad mide qué tan bien un modelo predice una muestra de texto, y las puntuaciones más bajas indican mayor confianza. No tiene nada que ver con el producto de búsqueda Perplexity.

• Cómo se calcula: la perplejidad es la exponencial de la log-verosimilitud negativa promedio por token sobre un texto de evaluación, como explica la documentación de Hugging Face. Requiere las log-probabilidades de los tokens, por lo que se aplica sobre todo a modelos de pesos abiertos que alojas o ajustas.
• Herramientas: Hugging Face Transformers y lm-evaluation-harness de EleutherAI.
• Umbral: solo diagnóstico. Compara la perplejidad antes y después de un ajuste fino sobre texto reservado de tu dominio y sobre texto general.
• Ejemplo práctico: tras ajustar con tickets de soporte, la perplejidad en tickets reservados baja mientras que la perplejidad en texto general sube bruscamente. El ajuste fino se ha sobreajustado y puede perjudicar las respuestas fuera del dominio de los tickets.

La perplejidad no dice nada sobre la corrección ni la relevancia. Un modelo puede ser fluido y seguro mientras afirma algo falso, así que nunca la uses como barrera de calidad en producción.

6. Puntuación de LLM como Juez (G-Eval)

LLM como juez usa un segundo modelo para puntuar las salidas según criterios que escribes en lenguaje natural, como “la respuesta le da al cliente un siguiente paso claro”. G-Eval (Liu et al., 2023) añade pasos de evaluación autogenerados y una puntuación en formato de formulario, y con GPT-4 alcanzó una correlación de Spearman de 0.514 con las valoraciones humanas en resumen, por delante de métodos automatizados anteriores.

• Cómo se calcula: el juez lee los criterios, los pasos de evaluación y la salida, y devuelve una puntuación de 1 a 5. G-Eval pondera esa puntuación por las probabilidades de los tokens, y DeepEval la normaliza de 0 a 1.
• Herramientas: la métrica G-Eval de DeepEval y los evaluadores de LangSmith.
• Umbral: 0.70 o más para uso general y 0.80 o más para productos de alto impacto, una vez calibrado frente a etiquetas humanas.
• Ejemplo práctico: un juez puntúa 300 respuestas de soporte según “da un siguiente paso claro”. El promedio es 0.82, pero las respuestas sobre facturación promedian 0.55, lo que señala al equipo una intención débil en lugar de un problema de todo el modelo.

Los jueces tienen sus propios sesgos. Zheng et al. (2023) encontraron que los jueces LLM favorecen las respuestas en primera posición, las respuestas más largas y sus propias salidas, aunque GPT-4 coincidió con las preferencias humanas más del 80% de las veces. Usa un juez de una familia de modelos distinta a la del modelo evaluado, intercambia el orden de las respuestas en las comparaciones por pares y calibra con al menos 50 ejemplos etiquetados por humanos.

Métricas de RAG

La generación aumentada por recuperación añade un segundo punto de fallo: el recuperador. Estas tres métricas dividen la puntuación para que puedas distinguir si una mala respuesta vino de los documentos recuperados o de lo que el modelo hizo con ellos. Para una cobertura herramienta por herramienta, consulta nuestra comparación de herramientas de evaluación de RAG, y para una auditoría completa del pipeline, nuestros servicios de pruebas de RAG cubren estas verificaciones en la recuperación, el ordenamiento y la generación.

7. Fidelidad

La fidelidad mide si cada afirmación de la respuesta está respaldada por el contexto recuperado. Es la métrica central para cualquier app que responde a partir de documentos internos, bases de conocimiento o políticas, y una verificación clave cuando sigues las mejores prácticas de RAG.

• Cómo se calcula: en Ragas, un LLM divide la respuesta en afirmaciones y verifica cada una contra el contexto. La puntuación es el número de afirmaciones respaldadas dividido por el total de afirmaciones.
• Herramientas: Ragas y DeepEval.
• Umbral: 0.75 o más para uso general y 0.90 o más para productos de alto impacto. Para Granola, un bloc de notas con IA que convierte transcripciones de reuniones en resúmenes, fijamos el objetivo de fidelidad en 0.90.
• Ejemplo práctico: el chatbot de Air Canada le dijo a un pasajero que podía reclamar una tarifa por duelo de forma retroactiva, mientras enlazaba a la propia página de tarifas por duelo de la aerolínea que decía lo contrario. La decisión del tribunal declaró a la aerolínea responsable de tergiversación negligente y otorgó $650.88 en daños.

Puntúa una respuesta de cuatro afirmaciones como esa, con tres afirmaciones respaldadas y una contradicha, y la fidelidad es 0.75. Eso aprueba el nivel general aunque la única afirmación errónea sea la que costó dinero. Para respuestas sobre políticas, precios y temas legales, añade una regla según la cual cualquier afirmación contradicha hace fallar el caso de prueba, diga lo que diga el promedio.

8. Precisión del Contexto

La precisión del contexto mide si los fragmentos relevantes están clasificados en la parte superior de lo que devuelve el recuperador. El ruido cerca de la parte superior satura la ventana de contexto y empuja al modelo hacia el pasaje equivocado.

• Cómo se calcula: Ragas toma la precisión en cada posición donde aparece un fragmento relevante y promedia esos valores, de modo que la puntuación premia los fragmentos relevantes que quedan en posiciones tempranas.
• Herramientas: Ragas, DeepEval y herramientas centradas en la recuperación como TruLens.
• Umbral: 0.70 o más para uso general y 0.80 o más para productos de alto impacto.
• Ejemplo práctico: el recuperador devuelve cinco fragmentos, con los relevantes en las posiciones 1 y 4. La precisión en esas posiciones es 1.0 y 0.5, así que la precisión del contexto es 0.75. Mueve el segundo fragmento relevante a la posición 2 y la puntuación sube a 1.0.

Una baja precisión del contexto suele apuntar a la división en fragmentos o al reordenamiento, no al modelo. Arregla el ordenamiento antes de dedicar tiempo a cambios de prompt.

9. Exhaustividad del Contexto

La exhaustividad del contexto mide si los fragmentos recuperados contienen todo lo necesario para responder correctamente. Si un dato clave nunca llega al modelo, ningún prompt puede arreglar la respuesta.

• Cómo se calcula: Ragas divide una respuesta de referencia en afirmaciones y comprueba cuántas pueden atribuirse al contexto recuperado. La puntuación es el número de afirmaciones atribuibles dividido por el total de afirmaciones de referencia, así que necesita un conjunto de datos de referencia.
• Herramientas: Ragas y DeepEval.
• Umbral: 0.75 o más para uso general y 0.90 o más para productos de alto impacto.
• Ejemplo práctico: la respuesta de referencia a una pregunta sobre licencia parental tiene cuatro afirmaciones, y los fragmentos recuperados respaldan tres. La afirmación que falta es la regla de elegibilidad, así que la exhaustividad es 0.75, lo que aprueba el uso general y no aprueba a un asistente de RR. HH. de alto impacto.

Lee la fidelidad y la exhaustividad del contexto juntas. Una fidelidad alta con una exhaustividad baja significa que el modelo resume con honestidad documentos incompletos, lo cual es un error de recuperación, no de generación.

Métricas de Agentes

Los agentes llaman a herramientas, encadenan pasos y cambian el estado de otros sistemas, así que un mensaje final fluido demuestra muy poco. Las dos métricas siguientes son el mínimo para cualquier agente que actúa en nombre de un usuario. Las métricas de trayectoria, planificación y recuperación se cubren en nuestra guía sobre métricas de evaluación de agentes de IA.

10. Tasa de Finalización de Tareas

La tasa de finalización de tareas mide si el agente alcanzó el objetivo del usuario y dejó el sistema en un estado final válido. “Produjo una respuesta” no cuenta; “la reunión existe en el calendario con los asistentes correctos” sí.

• Cómo se calcula: el método más fiable verifica directamente el estado final, por ejemplo consultando la base de datos tras la ejecución. Cuando eso no es posible, la métrica de finalización de tareas de DeepEval usa un juez LLM para extraer la tarea y el resultado de la traza y puntuar qué tan bien se alinean.
• Herramientas: DeepEval, LangSmith y aserciones personalizadas de estado final en tu framework de pruebas.
• Umbral: 90% para tareas de un solo paso y 70% para flujos de varios pasos en el nivel general, subiendo a 95% y 85% para productos de alto impacto.
• Ejemplo práctico: un agente de viajes ejecuta 50 escenarios de un solo paso y completa 47, es decir, 94%. En 50 itinerarios de varios pasos completa 31, es decir, 62%, lo que bloquea el lanzamiento.

Escribe los criterios de éxito para cada tipo de tarea antes de medir nada. Sin ellos, la finalización de tareas se convierte en un debate sobre si un viaje reservado a medias cuenta.

11. Precisión de las Llamadas a Herramientas

La precisión de las llamadas a herramientas mide si el agente eligió la herramienta correcta, pasó los argumentos correctos y llamó a las herramientas en un orden válido. Un agente puede llegar a una respuesta final plausible por un camino equivocado o arriesgado, y solo esta métrica lo revela.

• Cómo se calcula: compara las herramientas llamadas en cada caso de prueba con las llamadas y argumentos esperados. La puntuación es las llamadas correctas divididas por las llamadas esperadas, y DeepEval ofrece una métrica de corrección de herramientas lista para usar.
• Herramientas: DeepEval y aserciones a nivel de traza en LangSmith o en tu propio arnés de pruebas.
• Umbral: 0.90 o más para uso general y 0.95 o más para productos de alto impacto. No permitas ninguna llamada errónea en acciones irreversibles como pagos, eliminaciones o correos salientes.
• Ejemplo práctico: un agente de reembolsos puntúa 0.93 en general, pero en 2 de 60 casos pasó el total del pedido en lugar del precio del artículo a la herramienta de reembolso. El promedio aprueba, pero la regla de acciones irreversibles hace fallar la compilación.

Registra cada llamada a herramienta con sus argumentos tanto en producción como en pruebas. Los errores de herramientas rara vez se ven en el mensaje final, así que las trazas son el único lugar donde los encontrarás.

Métricas de Seguridad

Las métricas de seguridad se aplican a todo despliegue de cara al cliente, sin importar su arquitectura. También tienen peso regulatorio: la Ley de IA de la UE exige a los proveedores de sistemas de alto riesgo examinar los datos de entrenamiento en busca de posibles sesgos y alcanzar niveles adecuados de precisión y robustez. El Ómnibus Digital sobre IA trasladó la mayoría de las obligaciones independientes de alto riesgo al 2 de diciembre de 2027, lo que da a los equipos tiempo para construir la evidencia de pruebas, no una razón para omitirla.

12. Puntuación de Toxicidad

La puntuación de toxicidad mide qué tan probable es que una salida sea dañina, insultante, amenazante o explícita. La mayoría de las salidas tóxicas en producción provienen de entradas adversarias o con carga emocional, así que prueba con esas en lugar de con preguntas educadas.

• Cómo se calcula: un clasificador o un juez LLM puntúa cada salida de 0 a 1, y haces seguimiento tanto de la puntuación por salida como de la proporción de salidas por encima de tu umbral.
• Herramientas: Detoxify, el endpoint de moderación de OpenAI, Llama Guard y la métrica de toxicidad de DeepEval. Si aún dependes de la Perspective API de Google, planifica un reemplazo: Google indica que el servicio dejará de funcionar después del 31 de diciembre de 2026.
• Umbral: 0.10 o menos por salida para uso general y 0.05 o menos para productos de alto impacto. Revisa cada salida por encima de la línea antes del lanzamiento.
• Ejemplo práctico: 1,000 prompts adversarios producen 7 salidas con puntuación superior a 0.10, una tasa del 0.7%. Seis son el modelo citando de vuelta el propio insulto del usuario, lo que se resuelve con un ajuste del prompt, y una es un fallo genuino que necesita un guardarraíl.

Los clasificadores genéricos pasan por alto el daño específico del contexto. Un asistente legal puede pasar todos los filtros de toxicidad y aun así producir consejos que expongan a tu empresa a responsabilidad legal, por eso los conjuntos de prueba específicos del dominio pertenecen a tu plan de pruebas de IA.

13. Puntuación de Sesgo

La puntuación de sesgo mide si la calidad o los resultados de las respuestas cambian cuando solo cambia un atributo protegido en la entrada. Una respuesta individual puede parecer correcta mientras el patrón entre grupos no lo es.

• Cómo se calcula: construye pares de prompts contrafactuales que difieren solo en el nombre, el género, la edad u otro atributo, puntúa ambas respuestas con la misma métrica e informa la brecha promedio. Bancos de pruebas como BBQ (Parrish et al., 2022) cubren el sesgo social en la respuesta a preguntas.
• Herramientas: la métrica de sesgo de DeepEval, suites contrafactuales personalizadas y AIF360 de IBM para salidas de tipo clasificación.
• Umbral: una brecha de 0.05 o menos para uso general y de 0.02 o menos para productos de alto impacto.
• Ejemplo práctico: un asistente de contratación resume 200 CV idénticos, la mitad con nombres típicamente masculinos y la otra mitad con nombres típicamente femeninos. La puntuación de “solidez del candidato” del juez promedia 0.81 y 0.74, una brecha de 0.07 que no pasa la barrera.

Las pruebas de sesgo necesitan entradas que reflejen a tus usuarios reales y casos de uso. Un banco de pruebas público te informa sobre el modelo base, mientras que tus propios pares contrafactuales te informan sobre tu producto.

14. Resistencia a la Inyección

La resistencia a la inyección mide con qué fiabilidad la app se mantiene fiel a sus instrucciones cuando un usuario, documento o página web intenta anularlas. Las inyecciones directas llegan en el mensaje del usuario, mientras que las inyecciones indirectas se esconden en archivos recuperados, correos o resultados de herramientas que el modelo trata como contenido de confianza.

• Cómo se calcula: ejecuta una suite de prompts de ataque directos e indirectos conocidos y cuenta la proporción que la app resiste sin seguir la instrucción inyectada, filtrar su prompt de sistema ni llamar a herramientas que no debería.
• Herramientas: Garak, PyRIT, Promptfoo y el módulo de ataques simulados de DeepEval, más pruebas manuales de simulación adversaria para ataques encadenados y específicos del contexto.
• Umbral: 100% en tu suite de ataques tanto para productos generales como de alto impacto. Cualquier inyección exitosa bloquea el lanzamiento hasta que se corrija y se añada al conjunto de regresión.
• Ejemplo práctico: un asistente de soporte resiste 248 de 250 prompts de ataque. Ambos fallos provienen de un PDF subido con texto oculto que le indica al modelo revelar su prompt de sistema, así que la puntuación es 99.2% y el lanzamiento queda bloqueado.

Los escáneres automatizados cubren patrones conocidos, mientras que constantemente aparecen nuevas formulaciones de ataque. Nuestra lista de verificación de pruebas de inyección de prompts cubre las superficies de ataque que conviene sondear antes del lanzamiento.

Métricas Operativas

Una respuesta correcta pero que llega demasiado lenta, o que cuesta demasiado servir a escala, igualmente fracasa en producción. Las métricas operativas son donde los objetivos de calidad se encuentran con los presupuestos y los niveles de servicio. Hazles seguimiento junto con las puntuaciones de calidad, porque la mayoría de las correcciones de una mueven la otra.

15. Latencia

La latencia mide cuánto esperan los usuarios una respuesta. En las interfaces de chat, el tiempo hasta el primer token (TTFT) determina la velocidad percibida, mientras que el tiempo total de respuesta y su percentil 95 (p95) muestran lo que realmente experimentan los usuarios más lentos.

• Cómo se calcula: registra el TTFT, el tiempo total de respuesta y los tokens de salida por segundo en cada solicitud, y luego informa la mediana y el p95 bajo una carga concurrente realista.
• Herramientas: herramientas de pruebas de carga como k6 o Locust, además del rastreo en LangSmith, Langfuse u OpenTelemetry.
• Umbral: TTFT inferior a 1 segundo en chat con respuesta progresiva, con una latencia total p95 dentro del nivel de servicio que prometes a los usuarios.
• Ejemplo práctico: un bot de soporte muestra una mediana de TTFT de 0.6 segundos en staging. Con 500 sesiones concurrentes el p95 de TTFT sube a 3.4 segundos, porque un paso de reordenamiento queda en cola detrás de la llamada al modelo.

Los equipos suelen optimizar la calidad durante el desarrollo y descubren la latencia en las pruebas de carga. Incorpora la latencia del LLM a tu plan de pruebas de rendimiento desde el primer sprint, y registra la puntuación de calidad por rango de latencia para ver cuánto cuesta realmente una configuración más rápida.

16. Costo por Solicitud

El costo por solicitud mide lo que cuesta producir una respuesta, incluyendo la llamada al modelo, la recuperación, el reordenamiento, los jueces y los reintentos. Una configuración que parece barata con diez usuarios de prueba puede comportarse de forma muy distinta con el volumen de producción.

• Cómo se calcula: suma los tokens de entrada y salida por solicitud multiplicados por el precio de cada modelo, y luego añade los costos de recuperación, herramientas e infraestructura. Informa el promedio y el p95, ya que las conversaciones largas y los bucles de agentes crean valores atípicos costosos.
• Herramientas: paneles de uso del proveedor, seguimiento de costos de Langfuse o LangSmith y las exportaciones de facturación de tu nube.
• Umbral: dentro del presupuesto con 10 veces el volumen esperado, con una alerta ante cualquier aumento repentino en el promedio de tokens por solicitud.
• Ejemplo práctico: un agente promedia $0.04 por solicitud, pero el 3% de las sesiones entran en bucle con la misma herramienta y cuestan más de $1 cada una. Un límite de pasos reduce el costo p95 en más de la mitad sin cambiar la tasa de finalización de tareas.

El costo pertenece a la barrera de lanzamiento, no solo al informe financiero. Un cambio de prompt que añade 2,000 tokens de contexto a cada llamada es una regresión aunque todas las métricas de calidad se mantengan.

17. Recuperación de Errores

La recuperación de errores comprueba si la app se comporta correctamente cuando algo entre el usuario y el modelo falla, como una conexión caída, un tiempo de espera agotado o un error del proveedor del modelo. Las apps de LLM dependen de respuestas largas transmitidas y de API externas, así que los fallos de red son rutinarios, no raros.

• Cómo se calcula: inyecta fallos en un entorno de pruebas, por ejemplo cortando la conexión a mitad de la transmisión, devolviendo un error 429 o 500 del proveedor o agotando el tiempo de una llamada a herramienta. Cada escenario es un simple aprobado o fallido: la app reintenta o muestra un mensaje claro, conserva el estado de la conversación y nunca presenta una respuesta parcial como completa.
• Herramientas: Toxiproxy o un proveedor simulado para la inyección de fallos, además de Playwright o tu framework de pruebas de extremo a extremo para comprobar lo que ve el usuario.
• Umbral: aprobar todos los escenarios, tanto en productos generales como de alto impacto.
• Ejemplo práctico: cuando la transmisión se corta al 60%, una app de chat muestra la respuesta a medio escribir sin ninguna advertencia, lo cual es un fallo. Un agente de reembolsos que reintenta una llamada de pago agotada y reembolsa al cliente dos veces también falla, aunque su mensaje final parezca correcto.

Ejecuta estos escenarios en cada lanzamiento, no solo una vez antes del lanzamiento inicial. Una actualización de dependencias o una nueva configuración de reintentos puede cambiar silenciosamente el comportamiento de la app cuando una llamada falla.

Cómo Elegir las Métricas Adecuadas para tu Caso de Uso

Ningún producto necesita las 17 métricas como barreras de lanzamiento. Elige de tres a cinco imprescindibles que se correspondan con la forma en que tu app puede fallar, y haz seguimiento del resto como señales de apoyo. Como regla, combina al menos una métrica basada en referencia, una sin referencia y una específica de la tarea.

Si buscas específicamente métricas de exactitud de LLM, la tasa de alucinación, la fidelidad y la tasa de finalización de tareas se corresponden más directamente con “fue correcta”. Para la fluidez, usa un juez LLM con un criterio de fluidez sobre las salidas en vivo y reserva la perplejidad para el desarrollo del modelo.

Cómo Medir la Calidad de las Salidas de un LLM en Producción

Las puntuaciones previas al lanzamiento describen tu conjunto de datos de referencia, no a tus usuarios. La evaluación de LLM en producción responde otra pregunta: ¿se mantiene la calidad con el tráfico real esta semana? La configuración siguiente mantiene esa respuesta actualizada sin puntuar cada solicitud con un juez costoso.

Muestrea el Tráfico en Vivo en Dos Capas

Ejecuta verificaciones baratas sobre el 100% de las solicitudes: clasificadores de toxicidad, validación de formato y esquema, latencia y costo. Luego envía una muestra del 1% al 5% de las conversaciones a métricas basadas en modelos como la fidelidad, la relevancia de la respuesta y tus criterios G-Eval. Estratifica la muestra por intención y sobremuestrea las conversaciones con retroalimentación negativa, reintentos o longitud inusual, ya que ahí es donde se concentran los fallos.

Ejecuta los Jueces en Línea, Fuera de la Ruta de la Solicitud

Los jueces en línea deben puntuar las conversaciones registradas de forma asíncrona, para que nunca añadan latencia al usuario. Usa el mismo modelo juez, prompt y criterios que en las pruebas previas al lanzamiento, o tus puntuaciones de producción no serán comparables con tu línea base de lanzamiento. Fija la versión del juez con el mismo cuidado que el modelo evaluado.

Vigila la Deriva

Compara los promedios diarios móviles con la línea base de lanzamiento y emite una alerta cuando una métrica baje más de 0.05 durante tres días consecutivos. Haz seguimiento también de la deriva de entradas, por ejemplo nuevos temas de preguntas que tu conjunto de datos de referencia nunca cubrió. Las actualizaciones de modelos del lado del proveedor pueden cambiar el comportamiento sin ningún cambio de tu parte, así que fija las versiones de los modelos y vuelve a ejecutar la suite completa antes de pasar a una nueva.

Cierra el Ciclo

Cada semana, haz que una persona revise las conversaciones con menor puntuación de la muestra. Los fallos confirmados pasan al conjunto de datos de referencia como nuevos casos de prueba, lo que hace más estricta la próxima barrera de lanzamiento justo en los lugares donde producción encontró debilidad. Este ciclo es lo que convierte el monitoreo en una mejora medible en lugar de un panel que nadie lee.

Ejecutar la Evaluación de LLM en CI

Las métricas solo te protegen si se ejecutan en cada cambio que pueda alterar el comportamiento: prompts, versiones de modelos, ajustes de recuperación, herramientas y actualizaciones de la base de conocimiento. Trátalas como cualquier otra suite de pruebas automatizadas, con verificaciones rápidas en cada commit y la suite completa antes del lanzamiento. Nuestra guía sobre pruebas de regresión de LLM cubre en profundidad las líneas base y el diseño de pruebas.

Una configuración práctica se ejecuta en tres capas:

1. En cada commit, ejecuta un conjunto de humo de 30 a 50 casos con verificaciones deterministas, toxicidad y validación de formato. Debería terminar en minutos.
2. En cada pull request que toque prompts, modelos o recuperación, ejecuta el conjunto de datos de referencia completo con métricas basadas en modelos como la fidelidad, la relevancia de la respuesta y la finalización de tareas.
3. Cada noche y antes de cada lanzamiento, ejecuta la suite completa más los conjuntos adversarios y de sesgo, y compara cada puntuación con la última línea base aprobada.

Aplica dos reglas a la vez. Un cambio falla si alguna métrica cae por debajo de su umbral, y también falla si una métrica cae más de 0.03 por debajo de la línea base, incluso estando todavía por encima del umbral. Añade la regla de casos críticos de la sección de fidelidad, de modo que una sola afirmación de política contradicha haga fallar la compilación sin importar los promedios.

Las salidas de los LLM varían entre ejecuciones, así que puntúa cada caso tres veces o con temperatura 0 y compara promedios en lugar de resultados individuales. DeepEval se ejecuta como una suite de pytest, y herramientas como Promptfoo se integran en GitHub Actions o GitLab CI con poca configuración.

Si necesitas ayuda para elegir métricas, fijar umbrales o integrar la evaluación en tu pipeline, contáctanos. Revisaremos tu configuración actual y te diremos qué barreras añadir primero.

Preguntas Frecuentes

¿Qué son las métricas de evaluación de LLM?

Las métricas de evaluación de LLM son puntuaciones que miden qué tan bien se desempeña una aplicación de modelo de lenguaje según un criterio definido, como relevancia, exactitud factual, seguridad o velocidad. Cada métrica convierte una pregunta cualitativa, como “¿esta respuesta está basada en nuestros documentos?”, en un número que puedes seguir y usar como barrera de lanzamiento. Se dividen en grupos basados en referencia y sin referencia, y se calculan mediante fórmulas o mediante modelos que actúan como jueces.

¿Cuáles son las métricas de evaluación de LLM más importantes?

Las métricas más importantes dependen de cómo puede fallar tu app. Para la mayoría de las apps en producción, la relevancia de la respuesta, la tasa de alucinación y la toxicidad forman la base. Las apps RAG añaden fidelidad, precisión del contexto y exhaustividad del contexto, mientras que los agentes añaden la tasa de finalización de tareas y la precisión de las llamadas a herramientas.

¿Cómo se miden las alucinaciones en un LLM?

Divide cada respuesta en afirmaciones atómicas y verifica cada una contra una fuente fiable, ya sea la verdad de referencia para la tasa de alucinación o el contexto recuperado para la fidelidad. Una respuesta cuenta como alucinada si alguna afirmación no está respaldada, y la tasa es las respuestas alucinadas divididas por el total de respuestas. Automatiza la verificación con un juez LLM y luego confirma la exactitud del juez sobre una muestra revisada por humanos.

¿Se puede automatizar la evaluación de LLM?

La mayor parte, sí. Las métricas estadísticas, los clasificadores y los jueces LLM pueden ejecutarse en cada commit y sobre muestras del tráfico de producción sin esfuerzo manual. La revisión humana sigue siendo necesaria para calibrar umbrales, validar a los jueces y manejar casos límite, especialmente en productos de alto impacto.