Cómo medir y mejorar la calidad de las respuestas de tu LLM: métricas, pruebas y ajustes que funcionan

Lanzaste tu aplicación basada en un LLM y los usuarios se quejan de que las respuestas «a veces fallan». El problema, el modelo responde algo técnicamente correcto pero inútil, demasiado largo o fuera de contexto. Sin métricas concretas, estás volando a ciegas y cada ajuste es una apuesta. Aquí vas a aprender a medir lo que realmente importa y a actuar sobre ello.

Por qué la evaluación de LLMs es más difícil de lo que parece

Un modelo de clasificación tiene accuracy, F1 y AUC. Un LLM genera texto libre, y el texto libre es ambiguo por naturaleza. La misma respuesta puede ser perfecta para un usuario y confusa para otro. Aun así, hay dimensiones medibles y patrones de fallo predecibles. El error más común es evaluar solo con la intuición del equipo de producto, que introduce sesgo y no escala. Necesitas un framework de evaluación sistemático antes de tocar un solo parámetro del modelo.

Las métricas que sí funcionan

Divide las métricas en dos categorías: automáticas y humanas. Las automáticas son rápidas y repetibles; las humanas son costosas pero irreemplazables para calibrar las automáticas.

• Faithfulness (fidelidad): la respuesta contradice los documentos de contexto o los datos de entrada. Crítica en RAG. Puedes medirla con un LLM-as-judge que compare la respuesta contra el contexto original.
• Answer Relevance: la respuesta responde a lo que se preguntó, no a lo que el modelo asume que se preguntó. Se mide generando preguntas inversas desde la respuesta y comparando con la pregunta original.
• Groundedness / Hallucination rate: porcentaje de afirmaciones en la respuesta que no tienen soporte en el contexto. Herramientas como RAGAS o TruLens automatizan esto.
• Latencia y tokens consumidos: una respuesta perfecta que tarda 12 segundos destruye la experiencia. Monitoriza p50, p90 y p99 de latencia junto con el coste por consulta.
• Task completion rate: métrica de negocio, el porcentaje de conversaciones en las que el usuario logró lo que quería sin reformular la pregunta más de una vez.

Cómo implementar un pipeline de evaluación automatizado

El patrón más efectivo combina un conjunto de pruebas estáticas (golden dataset) con evaluación continua en producción.

Paso 1. Construye tu golden dataset. Recopila entre 50 y 200 pares pregunta-respuesta ideal validados por expertos del dominio. No uses el propio modelo para generarlos, introduce sesgo directo. Incluye casos límite: preguntas ambiguas, preguntas fuera de dominio y preguntas con trampa.

Paso 2. Automatiza la evaluación con un LLM-judge. Usa un modelo distinto al que estás evaluando (si evalúas GPT-4o, usa Claude como juez, y viceversa). Un prompt de evaluación básico funciona así:

SYSTEM: Eres un evaluador experto. Puntúa la siguiente respuesta del 1 al 5
en cada dimensión: relevancia, fidelidad al contexto y claridad.
Devuelve un JSON con la puntuación y una justificación de máximo 30 palabras.

USER:
Pregunta del usuario: {question}
Contexto disponible: {context}
Respuesta del modelo: {answer}

Paso 3. Integra la evaluación en tu CI/CD. Cada vez que cambies el system prompt, el modelo o los parámetros de retrieval, lanza el pipeline automáticamente. Con Python y la librería ragas puedes hacerlo en pocas líneas:

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy

result = evaluate(
    dataset=golden_dataset,
    metrics=[faithfulness, answer_relevancy]
)
print(result.to_pandas())

Paso 4. Monitoriza producción con trazas. Herramientas como LangSmith, Langfuse o Helicone registran cada llamada al modelo con sus inputs, outputs y latencia. Configura alertas cuando el score de faithfulness baje del umbral que hayas definido (por ejemplo, 0.75 sobre 1.0).

Ajustes concretos cuando las métricas fallan

Una vez tienes datos, el diagnóstico dicta la solución. No hay receta universal, pero hay patrones claros.

• Faithfulness baja: el modelo ignora el contexto recuperado. Revisa el system prompt para reforzar la instrucción de ceñirse al contexto. Si el problema persiste, el retrieval devuelve chunks irrelevantes, ajusta el tamaño de chunk o el umbral de similaridad.
• Answer relevance baja: el modelo divaga. Añade al prompt una instrucción explícita del tipo Responde únicamente a la pregunta formulada. No añadas información que no haya sido solicitada. También puedes bajar la temperatura a 0.3–0.5.
• Alucinaciones frecuentes en un dominio específico: el fine-tuning o el few-shot prompting con ejemplos del dominio suele ser más efectivo que seguir ajustando el system prompt genérico.
• Latencia alta: evalúa streaming para mejorar la percepción del usuario, reduce el número de tokens en el contexto con compresión de prompt (LLMLingua es una buena opción open source), o migra consultas sencillas a un modelo más pequeño y rápido.

El siguiente paso que no puedes saltarte

Medir una sola vez no sirve. La calidad de un LLM en producción se degrada con el tiempo conforme cambian los datos, los usuarios y el modelo base. Define una cadencia de evaluación, mínimo semanal para aplicaciones críticas, y trata los scores de calidad igual que tratas las métricas de disponibilidad del sistema. Si no está en tu dashboard, no existe. Empieza hoy con un golden dataset de 50 ejemplos y un juez automatizado. En dos semanas tendrás más información accionable sobre tu modelo que en los últimos seis meses de feedback subjetivo.