Published in: agentes de ia

LLM as Judge: evaluación de agentes IA con frameworks 2026

Author Diego Parada

Published on: 14 de junio de 2026

Llevas semanas construyendo un agente de IA que combina retrieval, razonamiento y tool calling. Ahora mismo funciona bien en tus demos. Pero, ¿cómo sabes que seguirá funcionando la semana que viene, cuando cambies el modelo base o amplíes el knowledge base? Ahí está el problema central de la evaluación en producción: los benchmarks tradicionales de exactitud , accuracy sobre conjuntos etiquetados estáticos, no capturan la naturaleza generativa de los LLMs, donde la misma respuesta correcta puede expresarse de mil formas distintas.

Este artículo cubre en profundidad el patrón LLM as Judge: qué es, cómo implementarlo y qué frameworks usar para evaluar agentes de IA para empresas en producción. Verás código ejecutable con Ragas, DeepEval y un juez manual con la API de OpenAI. Si llevas agentes en producción o estás a punto de hacerlo, aquí encontrarás las herramientas para saber, con evidencia, si tu sistema funciona.

Este post va dirigido a AI engineers y CTOs que ya tienen experiencia con LLMs en producción. No es una introducción a la IA generativa; asume que conoces conceptos como RAG, function calling y pipeline de inferencia. Si estás empezando con agentes, primero lee la guía de IA agéntica del mismo cluster.

¿Por qué los benchmarks tradicionales no funcionan con LLMs?

Los benchmarks clásicos como MMLU, HellaSwag, HumanEva están construidos sobre un principio sencillo: compara la salida del modelo con una respuesta de referencia etiquetada por humanos. Si la respuesta del modelo coincide exactamente, suma un punto. Este enfoque funciona bien en tareas discretas y cerradas: clasificación, multiple choice, extracción de entidades con un formato predefinido.

El problema aparece en cuanto el dominio de salida es abierto. Un agente de IA que resume un ticket de soporte y propone una solución puede generar decenas de respuestas igualmente válidas que no coinciden léxicamente con la referencia. Las métricas de solapamiento como BLEU o ROUGE, heredadas del NLP clásico de traducción automática, penalizan sinonimia, reordenamientos y expansiones correctas. En la práctica, un modelo con ROUGE-L de 0.4 puede ser perfectamente útil para el usuario final, mientras que otro con ROUGE-L de 0.7 puede estar alucinando hechos.

Hay además un problema de escala. Construir un golden dataset anotado por humanos para cada nueva tarea o cada nueva versión del sistema es costoso y lento. Un agente de ventas que usa agentes de IA en producción recibe miles de interacciones al día. Revisar manualmente el 1% de ellas ya representa decenas de horas-persona semanales. La evaluación humana sigue siendo el gold standard, pero no es operable como pipeline continuo.

La tercera limitación es la especificidad de dominio. Los benchmarks públicos están diseñados para comparar modelos entre sí en tareas genéricas. Pero en producción lo que importa es si tu agente concreto, con tu sistema prompt concreto, sobre los documentos de tu cliente concreto, responde correctamente las preguntas reales de tus usuarios reales. Ningún benchmark público captura eso. Necesitas infraestructura de evaluación propia.

El paper de Zheng et al. (2023), Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv:2306.05685), documentó este problema sistemáticamente: los modelos grandes pueden actuar como jueces de calidad con una correlación de 80%+ con evaluaciones humanas en tareas de conversación abierta, lo que abre la puerta a pipelines de evaluación automatizados y escalables.

LLM as Judge: el patrón explicado

LLM as Judge es un patrón de evaluación en el que un modelo de lenguaje  el «juez»  recibe como entrada la pregunta original del usuario, la respuesta generada por el sistema bajo evaluación, y opcionalmente el contexto de referencia, y produce una puntuación o un veredicto de calidad. El juez aplica una rubric explícita definida en el system prompt: evalúa fidelidad factual, relevancia, coherencia, completitud u otras dimensiones según el caso de uso.

La arquitectura típica tiene tres componentes:

• Sistema evaluado: el agente o pipeline RAG que genera respuestas.
• Juez LLM: un modelo diferente (habitualmente más grande o más robusto) que recibe un prompt de evaluación con la rubric.
• Orquestador de evaluación: el framework que conecta ambos, agrega métricas y genera reportes.

Hay dos modalidades principales. En la evaluación absoluta, el juez puntúa la respuesta en una escala (por ejemplo, 1-5) según cada dimensión de la rubric, sin compararla con ninguna otra. Es adecuada para pipelines de regresión donde quieres detectar si una nueva versión del sistema ha degradado en alguna métrica. En la evaluación pairwise, el juez recibe dos respuestas —generadas por dos versiones del sistema o dos modelos distintos— y decide cuál es mejor. El pairwise tiene más señal discriminativa para comparar alternativas, pero introduce sesgos de posición (el juez tiende a preferir la primera o la segunda respuesta dependiendo del orden de presentación).

Un aspecto crítico que suele pasarse por alto: el juez LLM no debe ser el mismo modelo que genera las respuestas. Si usas GPT-4o como backbone de tu agente y GPT-4o como juez, introduces un sesgo sistemático hacia el estilo de respuesta de ese modelo. La práctica recomendada es usar un juez de familia distinta: si el agente usa modelos OpenAI, evalúa con Claude; si usa Claude, evalúa con GPT-4o o Gemini.

El code block siguiente muestra un juez manual construido directamente sobre la API de OpenAI. Sin frameworks intermedios, para entender el mecanismo en crudo:

import openai
import json

client = openai.OpenAI()

JUDGE_SYSTEM_PROMPT = """Eres un evaluador experto de sistemas RAG y agentes de IA.
Evalúa la respuesta del asistente según estos criterios:

1. Faithfulness (0-5): ¿La respuesta se basa exclusivamente en el contexto proporcionado?
   0 = contiene información inventada, 5 = completamente fiel al contexto.
2. Relevance (0-5): ¿La respuesta aborda directamente la pregunta del usuario?
   0 = completamente irrelevante, 5 = perfectamente relevante.
3. Completeness (0-5): ¿La respuesta cubre todos los aspectos de la pregunta?
   0 = respuesta fragmentaria, 5 = respuesta completa.

Devuelve un JSON con la estructura:
{"faithfulness": int, "relevance": int, "completeness": int, "reasoning": str}
"""

def llm_judge(question: str, context: str, answer: str) -> dict:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": JUDGE_SYSTEM_PROMPT},
            {"role": "user", "content": f"""
**Pregunta del usuario**: {question}

**Contexto recuperado**:
{context}

**Respuesta del asistente**:
{answer}
"""}
        ],
        response_format={"type": "json_object"},
        temperature=0
    )
    return json.loads(response.choices[0].message.content)


# Ejemplo de uso
result = llm_judge(
    question="¿Cuál es el plazo de devolución de productos?",
    context="Los clientes pueden devolver productos en un plazo de 30 días desde la recepción.",
    answer="Puedes devolver cualquier producto en los primeros 30 días tras recibirlo."
)
print(result)
# {"faithfulness": 5, "relevance": 5, "completeness": 4, "reasoning": "..."}

Métricas de evaluación: faithfulness, relevance, hallucination

Las métricas de evaluación para LLMs no son intercambiables. Cada una mide una dimensión distinta del comportamiento del sistema y debe seleccionarse en función del tipo de fallo que quieres detectar.

Faithfulness: ¿el modelo se inventa información?

Faithfulness (o fidelidad) mide si cada afirmación factual de la respuesta puede trazarse hasta el contexto de referencia proporcionado al modelo. Es la métrica más crítica en sistemas RAG, donde el agente dispone de documentos específicos y no debería razonar desde conocimiento paramétrico. Un hallucination ocurre exactamente cuando el modelo genera una afirmación que no está soportada por el contexto: inventa una cifra, confunde dos entidades, o extrapola más allá de lo que dice el documento. La faithfulness se calcula habitualmente como la proporción de afirmaciones verificadas sobre el total de afirmaciones generadas. Un score de 0.95 significa que 19 de cada 20 afirmaciones son verificables en el contexto; el 5% restante son alucinaciones potenciales que requieren revisión humana antes de llegar al usuario.

Answer relevance: ¿la respuesta aborda la pregunta real?

Answer relevance evalúa si la respuesta generada responde directamente a la pregunta del usuario. Es posible tener faithfulness perfecta todas las afirmaciones son correctas y están en el contexto pero relevance baja si el modelo responde a una pregunta distinta de la que se formuló. Esto ocurre frecuentemente en sistemas con contexto largo: el retriever trae el documento correcto, pero el LLM se centra en un fragmento tangencial y genera una respuesta técnicamente verdadera pero inútil para el usuario. La answer relevance se calcula invirtiendo el proceso: el juez genera N preguntas posibles a partir de la respuesta y mide si la pregunta original está entre las que la respuesta respondería bien (similitud semántica usando embeddings).

Context precision y context recall

Context precision (también llamada precision@K) mide qué proporción de los K fragmentos recuperados por el retriever son realmente relevantes para la pregunta. Si tu retriever trae 5 fragmentos y solo 2 son pertinentes, la precision@5 es 0.4. Context recall mide el complementario: de todos los fragmentos relevantes que existen en el knowledge base, qué porcentaje recuperó el retriever. Un sistema puede tener alta precision casi todo lo que recupera es útilpero baja recall si hay información crítica que nunca llega al LLM. El balance entre ambas métricas define la configuración óptima del retriever: número de fragmentos K, similarity threshold y estrategia de chunking.

Evaluar un RAG: precision@K, recall, context relevance

Evaluar un pipeline RAG requiere separar los fallos en dos componentes independientes: fallos del retriever y fallos del LLM. Un error en la respuesta final puede venir de que el retriever no trajo el fragmento correcto (problema de recall), de que trajo fragmentos irrelevantes que confundieron al LLM (problema de precision), o de que el LLM alucinó a pesar de tener el contexto correcto (problema de faithfulness). Sin esta separación, no sabes qué parte del sistema está fallando y cualquier optimización es a ciegas.

El framework de evaluación RAG más citado en la literatura define tres métricas compuestas calculables sin ground truth manual (usando el propio LLM como juez):

• Context precision: proporción de fragmentos recuperados que son relevantes para la pregunta.
• Context recall: proporción de información necesaria para responder que está cubierta por los fragmentos recuperados.
• Answer correctness: similitud semántica entre la respuesta generada y la respuesta de referencia (cuando existe un golden dataset).

Para construir un golden dataset mínimo viable, la práctica habitual en producción es tomar una muestra de 50-200 interacciones reales del agente, anotarlas manualmente con la respuesta correcta, y usar ese conjunto como benchmark de regresión. No necesitas anotar miles de ejemplos desde el principio; con 100 ejemplos bien elegidos que cubran los casos de uso principales tienes suficiente señal para detectar regresiones significativas entre versiones. Un agente implementado como agente de IA para empresas debería tener este golden dataset construido antes de pasar a producción real.

El parámetro K en precision@K es una decisión de diseño que afecta el trade-off entre cobertura y precisión. Con K=3 el retriever trae menos ruido pero puede perder información crítica en preguntas complejas. Con K=10 la cobertura mejora pero el context window se llena y el LLM tiene más probabilidades de desorientarse. La evaluación sistemática con diferentes valores de K sobre tu golden dataset es la única forma de tomar esta decisión con datos, no con intuición. Los agentes basados en retrieval augmented generation típicamente optimizan K en el rango 3-7 para casos de uso empresariales.

Frameworks: Ragas, DeepEval, Promptfoo, LangSmith

El ecosistema de frameworks de evaluación de LLMs ha madurado significativamente en 2024-2025. Estos son los cuatro más utilizados en producción por AI engineers:

Ragas (docs.ragas.io) es el framework de referencia para evaluar RAG. Su diferencial es que calcula las métricas de faithfulness y relevance usando el propio LLM como juez, sin necesitar ground truth manualmente anotado. Esto lo hace especialmente útil al inicio del proyecto, cuando aún no tienes golden dataset.

DeepEval (docs.confident-ai.com) adopta un enfoque de test suite orientado a pytest. Cada métrica es un «test case» que pasa o falla según un threshold. Esto permite integrar la evaluación en el pipeline de CI/CD: si la faithfulness cae por debajo de 0.85 en el test suite de regresión, el deploy se bloquea automáticamente.

Promptfoo (promptfoo.dev/docs) brilla en la comparación de prompts y modelos. Si quieres testear si cambiar el system prompt de tu agente mejora o empeora las respuestas, Promptfoo ejecuta los dos prompts sobre el mismo conjunto de test cases y presenta una comparativa visual. Es especialmente útil durante la fase de prompt engineering.

LangSmith (docs.smith.langchain.com/evaluation) ofrece la integración más profunda si ya usas el stack LangChain/LangGraph, con trazabilidad end-to-end y evaluadores custom en Python. La plataforma permite combinar evaluación automática con feedback humano en la misma interfaz.

Implementación práctica con Ragas (código)

A continuación, la implementación completa de un pipeline de evaluación con Ragas. El ejemplo evalúa un agente RAG sobre un conjunto de preguntas de prueba, calculando faithfulness y answer relevance con GPT-4o como juez:

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from datasets import Dataset

# Configurar el juez LLM (usa un modelo diferente al del agente si es posible)
judge_llm = LangchainLLMWrapper(ChatOpenAI(model="gpt-4o", temperature=0))
judge_embeddings = OpenAIEmbeddings(model="text-embedding-3-large")

# Dataset de evaluación: 
# - question: la pregunta del usuario
# - answer: la respuesta generada por tu agente
# - contexts: lista de fragmentos recuperados por el retriever
# - ground_truth: respuesta correcta (solo necesaria para context_recall y answer_correctness)

eval_dataset = Dataset.from_dict({
    "question": [
        "¿Cuál es el plazo de garantía del producto X?",
        "¿Cómo se procesa una devolución?",
        "¿Qué documentación necesito para hacer una reclamación?"
    ],
    "answer": [
        "El producto X tiene una garantía de 2 años según la normativa europea.",
        "Para procesar una devolución, debes contactar con soporte en 72 horas.",
        "Necesitas el ticket de compra, el formulario de reclamación y el DNI."
    ],
    "contexts": [
        ["La garantía estándar es de 2 años conforme al Real Decreto Legislativo 1/2007."],
        ["Las devoluciones deben solicitarse en las primeras 72 horas. Contacta con soporte@empresa.com."],
        ["Para reclamaciones necesitas: ticket de compra (obligatorio), formulario descargable en web, DNI o NIE."]
    ],
    "ground_truth": [
        "El producto X tiene garantía de 2 años.",
        "Contactar con soporte en 72 horas desde la recepción.",
        "Ticket de compra, formulario de reclamación y DNI."
    ]
})

# Ejecutar evaluación
result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
    llm=judge_llm,
    embeddings=judge_embeddings
)

print(result)
# {'faithfulness': 0.97, 'answer_relevancy': 0.92, 
#  'context_precision': 1.0, 'context_recall': 0.89}

# Exportar a DataFrame para análisis por item
df = result.to_pandas()
print(df[["question", "faithfulness", "answer_relevancy"]].to_string())

La clave práctica aquí es el parámetro contexts: no basta con pasar la respuesta final del agente, necesitas exponer los fragmentos que tu retriever efectivamente recuperó. Si tu arquitectura RAG está implementada con context engineering avanzado —con gestión explícita del context window— estos fragmentos ya están disponibles en el pipeline. Consulta la guía de context engineering para más detalle sobre cómo instrumentar el retriever para exponer esta información.

El tercer code block muestra cómo usar DeepEval con estructura de test suite pytest, lo que permite integrar la evaluación en CI/CD:

import pytest
from deepeval import assert_test
from deepeval.metrics import (
    FaithfulnessMetric,
    AnswerRelevancyMetric,
    HallucinationMetric
)
from deepeval.test_case import LLMTestCase

# Umbrales de calidad mínima aceptable
FAITHFULNESS_THRESHOLD = 0.85
RELEVANCY_THRESHOLD = 0.80
HALLUCINATION_THRESHOLD = 0.15  # Menor es mejor

faithfulness_metric = FaithfulnessMetric(
    threshold=FAITHFULNESS_THRESHOLD,
    model="gpt-4o",
    include_reason=True
)

relevancy_metric = AnswerRelevancyMetric(
    threshold=RELEVANCY_THRESHOLD,
    model="gpt-4o"
)

hallucination_metric = HallucinationMetric(
    threshold=HALLUCINATION_THRESHOLD,
    model="gpt-4o"
)

@pytest.mark.parametrize("test_input", [
    {
        "input": "¿Cuál es el horario de atención al cliente?",
        "actual_output": "El horario de atención es de lunes a viernes de 9h a 18h.",
        "retrieval_context": ["Atención al cliente: L-V 9:00-18:00. Sábados no disponible."],
    },
    {
        "input": "¿Aceptáis pagos en criptomoneda?",
        "actual_output": "Actualmente no aceptamos pagos en criptomoneda.",
        "retrieval_context": ["Métodos de pago aceptados: tarjeta Visa, Mastercard, PayPal, transferencia bancaria."],
    },
])
def test_agent_quality(test_input):
    test_case = LLMTestCase(
        input=test_input["input"],
        actual_output=test_input["actual_output"],
        retrieval_context=test_input["retrieval_context"]
    )
    assert_test(test_case, [faithfulness_metric, relevancy_metric, hallucination_metric])

# Ejecutar con: pytest test_agent.py -v
# Un fallo bloquea el pipeline de CI/CD

Best practices: pairwise vs absolute, sesgo del juez

La evaluación con LLM as Judge introduce sesgos sistemáticos que hay que conocer y mitigar antes de confiar en los resultados. El paper de Zheng et al. identificó tres sesgos principales:

Position bias: en evaluaciones pairwise, el juez tiende a preferir la respuesta que aparece en primera posición. La magnitud del sesgo varía por modelo, pero puede llegar al 15-20% en algunos LLMs. La mitigación estándar es ejecutar cada comparación pairwise dos veces, invirtiendo el orden de las respuestas, y solo declarar un ganador si ambas ejecuciones concuerdan. Si discrepan, se contabiliza como empate.

Verbosity bias: los jueces LLM tienden a puntuar mejor las respuestas más largas, incluso cuando la respuesta más corta es factualmente correcta y más concisa. Para mitigarlo, la rubric debe incluir explícitamente un criterio de concisión y el prompt del juez debe advertir sobre este sesgo: «Una respuesta corta y precisa es preferible a una larga y vaga».

Self-enhancement bias: un modelo usado como juez de sus propias respuestas tiende a sobreval uar sus outputs. Por eso es crítico usar un juez de familia distinta al modelo evaluado. Para agentes de IA construidos sobre GPT-4o, usar Claude 3.5 Sonnet como juez (o viceversa) reduce este sesgo significativamente.

Sobre cuándo usar pairwise vs absolute:

• Pairwise: cuando comparas dos versiones del sistema (A/B testing de prompts, comparativa de modelos, cambio de retriever). Más señal discriminativa pero más caro (el doble de llamadas al juez).
• Absolute: cuando monitoreas un sistema estable en producción para detectar degradaciones. Más eficiente y permite tracking temporal de métricas.

El cuarto code block muestra la implementación pairwise con inversión de orden para neutralizar position bias:

import openai
import json
from enum import Enum

client = openai.OpenAI()

class Winner(str, Enum):
    A = "A"
    B = "B"
    TIE = "TIE"

PAIRWISE_SYSTEM = """Evalúa cuál de las dos respuestas es mejor para la pregunta dada.
Criterios: precisión factual, relevancia, concisión, completitud.
Una respuesta corta y precisa es preferible a una larga y vaga.
Devuelve JSON: {"winner": "A" | "B" | "TIE", "reasoning": str}
"""

def judge_pair(question: str, context: str, response_a: str, response_b: str) -> dict:
    def single_judge(ra, rb):
        resp = client.chat.completions.create(
            model="gpt-4o",
            messages=[
                {"role": "system", "content": PAIRWISE_SYSTEM},
                {"role": "user", "content": f"""
**Pregunta**: {question}
**Contexto**: {context}
**Respuesta A**: {ra}
**Respuesta B**: {rb}
"""}
            ],
            response_format={"type": "json_object"},
            temperature=0
        )
        return json.loads(resp.choices[0].message.content)

    # Ejecutar en orden normal e invertido para neutralizar position bias
    result_normal = single_judge(response_a, response_b)
    result_inverted = single_judge(response_b, response_a)

    # Normalizar resultado invertido
    if result_inverted["winner"] == "A":
        result_inverted["winner"] = "B"
    elif result_inverted["winner"] == "B":
        result_inverted["winner"] = "A"

    # Solo declarar ganador si ambas ejecuciones coinciden
    if result_normal["winner"] == result_inverted["winner"]:
        return {"winner": result_normal["winner"], "confidence": "high"}
    else:
        return {"winner": Winner.TIE, "confidence": "low", "note": "Position bias detected"}


# Ejemplo: comparar respuesta de v1 vs v2 del agente
resultado = judge_pair(
    question="¿Cuánto tarda el envío estándar?",
    context="Envío estándar: 3-5 días laborables. Express: 24h con cargo adicional.",
    response_a="El envío estándar tarda entre 3 y 5 días laborables.",
    response_b="Normalmente el envío llega en 3-5 días hábiles, aunque puede variar según la zona geográfica y la disponibilidad del transportista en cada momento del año."
)
print(resultado)
# {"winner": "A", "confidence": "high"} — A es más concisa y fiel al contexto

Una best practice adicional para producción: calibra tu juez. Antes de desplegar el pipeline automático, toma una muestra de 50-100 evaluaciones, evalúalas manualmente, y compara el resultado del juez con el humano. Si la correlación (Cohen’s kappa o Spearman) es inferior a 0.7, la rubric necesita ajustes. Un juez mal calibrado puede darte falsa confianza en la calidad del sistema. En proyectos de agentes de IA para empresas que desarrollamos en Baigency, esta calibración inicial es parte del proceso de puesta en producción.

Preguntas frecuentes sobre LLM as Judge

¿Cuántas preguntas necesito en el golden dataset para que la evaluación sea fiable?

Para detectar regresiones estadísticamente significativas (p < 0.05) con un efecto mínimo detectable del 5% en una métrica como faithfulness, necesitas aproximadamente 200 ejemplos si esperas que la métrica base esté alrededor de 0.90. Con 50-100 ejemplos puedes detectar degradaciones grandes (>15%), que suelen ser las que importan en producción. La recomendación práctica es empezar con 50 casos bien elegidos que cubran los escenarios críticos, y crecer el dataset de forma incremental añadiendo casos donde el sistema falla.

¿Qué modelo debo usar como juez?

La elección del juez depende de dos factores: el modelo del agente y el presupuesto. El principio fundamental es no usar el mismo modelo como agente y como juez (self-enhancement bias). Si tu agente usa GPT-4o, usa Claude 3.5 Sonnet o Gemini 1.5 Pro como juez. Si usas Claude, usa GPT-4o. En cuanto al coste, los jueces de calidad (GPT-4o, Claude 3.5 Sonnet) cuestan entre 5x y 20x más que modelos pequeños como GPT-4o mini, pero la correlación con evaluación humana es significativamente mayor. Para evaluación de producción a escala, considera usar un modelo small como pre-filtro y el modelo grande solo para casos borderline.

¿Ragas requiere siempre un golden dataset con ground truth?

No. Las métricas de faithfulness y answer relevancy de Ragas no requieren ground truth: las calcula usando el propio LLM como juez a partir de la pregunta, el contexto recuperado y la respuesta generada. Esto permite arrancar la evaluación desde el primer día, antes de tener datos etiquetados. Las métricas que sí requieren ground truth son answer correctness (similitud con la respuesta correcta) y context recall (qué proporción de la información necesaria recuperó el retriever). Para estas, necesitas al menos 50-100 pares pregunta-respuesta correcta anotados manualmente.

¿Cómo integro la evaluación en un pipeline de CI/CD?

DeepEval es el framework más adecuado para esto, ya que expone su API como tests de pytest. El workflow típico es: (1) construir un test suite con los casos críticos del golden dataset, (2) definir thresholds de calidad mínima por métrica (por ejemplo, faithfulness > 0.85), (3) ejecutar pytest en el pipeline de CI tras cada cambio en el sistema prompt, la configuración del retriever o el modelo base, y (4) bloquear el merge si alguna métrica cae por debajo del threshold. Este enfoque convierte la evaluación de calidad en un gate de producción igual que los tests unitarios.

¿Cuál es la diferencia entre hallucination y faithfulness?

Son dos caras de la misma moneda pero miden perspectivas distintas. Faithfulness es una métrica de precisión: qué proporción de las afirmaciones de la respuesta están soportadas por el contexto. Hallucination es habitualmente la métrica complementaria: qué proporción de afirmaciones NO están soportadas. En frameworks como DeepEval, la HallucinationMetric detecta afirmaciones en la respuesta que contradicen o no aparecen en el contexto de referencia, y devuelve un score de 0 a 1 donde 0 significa sin alucinaciones. La diferencia práctica es que faithfulness penaliza solo las afirmaciones inventadas, mientras que hallucination también captura contradicciones explícitas con el contexto.

¿Puedo usar LLM as Judge para evaluar agentes con tool calling, no solo RAG?

Sí, aunque requiere adaptar la rubric. En agentes con tool calling la evaluación tiene dos capas: (1) evaluación de la decisión de herramienta —¿el agente llamó a la herramienta correcta con los parámetros correctos?— y (2) evaluación de la respuesta final al usuario tras integrar el resultado de la herramienta. Para la primera capa, el juez recibe el historial de llamadas a herramientas y evalúa si la secuencia de tool calls es la óptima para resolver la tarea. Para la segunda, se aplica la evaluación estándar de faithfulness y relevance. Los agentes construidos con LangGraph o con arquitecturas agénticas multi-step requieren esta evaluación en dos capas para cubrir todos los puntos de fallo.

Conclusión

LLM as Judge no es una solución perfecta el juez tiene sesgos, costes y limitaciones propias pero es hoy la única forma práctica de escalar la evaluación de agentes en producción sin depender exclusivamente de revisión humana. La combinación de un juez bien calibrado, un golden dataset curado y un framework como Ragas o DeepEval da a los equipos de AI engineering la infraestructura para iterar con confianza: saber si una nueva versión del sistema es mejor o peor antes de exponerla a usuarios reales.

El stack que hemos cubierto evaluación con Ragas para RAG, DeepEval para test suites en CI/CD, pairwise con inversión de orden para A/B testing  es el mismo que se aplica en los agentes de IA para empresas que construimos en Baigency. Si estás desarrollando un agente y necesitas diseñar la infraestructura de evaluación desde cero, o si tienes un sistema en producción sin cobertura de evals, podemos ayudarte a definir las métricas correctas para tu caso de uso.

El siguiente paso natural tras establecer evals es la observabilidad continua: trazabilidad de cada interacción, alertas cuando las métricas caen y dashboards de calidad en tiempo real. Eso es territorio de plataformas como LangSmith integradas con agentes orquestados en LangGraph.