Evaluación de agentes de IA con LangWatch: de las impresiones a las puntuaciones

Lanzaste un agente de IA. Atiende solicitudes de clientes, enruta tickets y quizá hasta redacta respuestas. En staging se veía muy bien. En producción, el panorama se vuelve menos claro. Un usuario reporta una respuesta incorrecta. Otro dice que el tono no fue el adecuado. ¿La respuesta de tu equipo? «Parecía funcionar bien cuando lo probamos».

Esta es la trampa de la evaluación basada en impresiones, y la mayoría de los equipos que trabajan con LLMs cae en ella. La solución es la evaluación sistemática: ejecutar el agente con entradas seleccionadas, puntuar sus resultados con criterios medibles y dar seguimiento a esas puntuaciones a lo largo del tiempo. LangWatch es una plataforma creada específicamente para esto.

Este artículo explica cómo funcionan las evaluaciones de LangWatch a través de una aplicación ficticia —TravelBot, un asistente de reservas de viajes impulsado por IA— y por qué importa cada capa del stack de evaluación.

El problema: los agentes de IA no son funciones deterministas

Las pruebas de software tradicionales se basan en el determinismo: dada una entrada X, se espera una salida Y. Los agentes de IA rompen este contrato. El mismo prompt puede producir resultados diferentes entre ejecuciones, modelos o incluso configuraciones de temperatura. Un agente de soporte podría responder correctamente «¿Cómo cancelo mi reserva?» diez veces y luego alucinar una política de reembolso en la undécima.

Investigaciones de Stanford y MIT sugieren que la evaluación sistemática reduce las fallas en producción hasta en un 60%, mientras acelera los ciclos de despliegue. Sin embargo, según encuestas recientes de la industria, solo el 52% de los equipos realiza evaluaciones offline y apenas el 37% evalúa en producción. La calidad sigue siendo el principal obstáculo para desplegar agentes.

La pregunta deja de ser «¿pasa esta prueba?» y pasa a ser «¿qué tan bueno es, en promedio, a través de muchos ejemplos?».

Conoce TravelBot: nuestra aplicación de ejemplo

TravelBot es un asistente de IA basado en Python que ayuda a los usuarios a reservar vuelos, hoteles y autos de alquiler. Tiene varios agentes especializados:

• BookingAgent — procesa solicitudes de reserva
• SupportAgent — gestiona cancelaciones, cambios y quejas
• RecommendationAgent — sugiere destinos según las preferencias
• PolicyAgent — responde preguntas sobre políticas de reembolso, reglas de equipaje, etc.

Cada agente recibe una entrada estructurada (perfil del usuario, historial de reservas, solicitud actual), llama a herramientas externas (API de búsqueda de vuelos, disponibilidad de hoteles, pasarela de pago) y devuelve una respuesta estructurada con las acciones realizadas y los elementos pendientes de seguimiento.

El código ya tiene dos capas de pruebas:

Lo que falta es medir la calidad por lotes mediante puntuaciones: ejecutar el agente con decenas o cientos de ejemplos y producir puntuaciones numéricas que puedas seguir a través de cambios en los prompts, actualizaciones de modelos y refactorizaciones de código.

La pirámide de pruebas para aplicaciones de IA

La pirámide de pruebas para agentes de IA adapta la pirámide clásica de pruebas de software a sistemas no deterministas:

         ╱  Scenario Tests  ╲           Few, expensive (real LLM calls)
        ╱    Multi-turn +     ╲         Binary pass/fail via judge agent
       ╱     judge agents      ╲
      ╱─────────────────────────╲
     ╱   Batch Evaluations       ╲     Many examples, scored numerically
    ╱    (LangWatch experiments)  ╲    Track quality over time
   ╱───────────────────────────────╲
  ╱         Unit Tests              ╲  Fast, deterministic, no LLM calls
 ╱          No API costs             ╲
╱━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╲

Las pruebas de escenarios están en la cima: son realistas, pero costosas y producen resultados binarios (pasa o falla). Las pruebas unitarias forman la base: son rápidas, económicas y deterministas. Las evaluaciones por lotes ocupan el nivel intermedio: hacen llamadas reales a LLMs, como las pruebas de escenarios, pero puntúan numéricamente los resultados de muchos ejemplos, lo que te da una línea de tendencia de calidad en lugar de un único veredicto.

Esta capa intermedia es donde LangWatch destaca.

Cómo funcionan las evaluaciones de LangWatch

LangWatch proporciona cuatro herramientas de evaluación interconectadas:

1. Datasets — tus entradas de prueba seleccionadas

Un dataset es una colección de entradas con salidas esperadas opcionales. Para TravelBot, un buen dataset de evaluación cubre casos límite relevantes:

LangWatch permite importar datasets desde CSV, generarlos sintéticamente a partir de documentos y alimentarlos continuamente con trazas de producción (interacciones reales de usuarios que marcas para incluirlas).

2. Evaluadores — cómo puntuar los resultados

Los evaluadores son funciones que toman la salida de un agente y producen una puntuación. LangWatch ofrece varias categorías:

Evaluadores integrados para patrones comunes:

• ragas/answer_relevancy — ¿la respuesta es relevante para la pregunta?
• ragas/faithfulness — ¿la respuesta se apega al contexto proporcionado?
• Coincidencia exacta, puntuación BLEU y puntuación ROUGE para comparar con el texto esperado

Evaluadores LLM-as-Judge que usan un LLM para puntuar la salida de otro LLM:

• Booleano (pasa/falla) — «¿El agente identificó correctamente la intención del usuario?»
• Puntuación (valor numérico de 0–1) — «¿Qué tan útil fue esta respuesta en una escala?»
• Categoría — «Clasifica esta respuesta como: correcta, parcialmente correcta o incorrecta»

Evaluadores personalizados para lógica específica de un dominio. Aquí es donde la evaluación de salidas estructuradas destaca. Para TravelBot, un evaluador personalizado podría verse así:

def evaluate_booking_correctness(output_json: str, expected: dict) -> float:
    """Score 0-1 based on booking field accuracy."""
    actual = json.loads(output_json)

    fields = ["destination", "departure_date", "return_date", "passengers"]
    correct = sum(1 for f in fields if actual.get(f) == expected.get(f))

    return correct / len(fields)

Esto es fundamental para agentes que producen salidas estructuradas (modelos Pydantic, esquemas JSON) en lugar de texto libre. Los evaluadores genéricos de similitud de texto como BLEU no funcionan bien con datos estructurados: necesitas comparaciones a nivel de campo.

3. Experimentos — cómo unir todas las piezas

Un experimento ejecuta tu agente con un dataset, puntúa cada salida con uno o más evaluadores y registra los resultados. Este es el patrón básico con el SDK de Python de LangWatch:

import langwatch
import pandas as pd

dataset = pd.DataFrame({
    "input": [
        '{"request": "Book a flight to Tokyo", "user_id": "u123"}',
        '{"request": "Cancel booking BK-456", "user_id": "u789"}',
    ],
    "expected_destination": ["Tokyo", None],
    "expected_action": ["book_flight", "cancel_booking"],
})

experiment = langwatch.experiment.init("support-agent-v2")

for index, row in experiment.loop(dataset.iterrows()):
    response = await support_agent.run(row["input"])
    output = response.model_dump_json()

    experiment.log(
        "action_correctness",
        index=index,
        score=1.0 if response.action == row["expected_action"] else 0.0,
    )

    experiment.evaluate(
        "ragas/answer_relevancy",
        index=index,
        data={"input": row["input"], "output": output},
        settings={"model": "openai/gpt-4o-mini"},
    )

La diferencia clave frente a las pruebas de escenarios: obtienes puntuaciones continuas (0.87 de relevancia, 0.93 de corrección de acciones) en lugar de un resultado binario de pasa/falla. Cuando cambias un prompt o sustituyes un modelo, puedes comparar las puntuaciones entre ejecuciones para detectar regresiones.

4. Monitores — observabilidad en producción

Una vez que tu agente está en producción, los monitores puntúan continuamente el tráfico en vivo:

User Request → Agent Response → LangWatch Trace → Monitor → Score → Dashboard

Los monitores se ejecutan de forma asíncrona después de enviar la respuesta, por lo que no agregan latencia a la experiencia del usuario. Alimentan dashboards y activan alertas cuando la calidad cae por debajo de los umbrales. Esto cierra el ciclo: la evaluación no termina con el despliegue, sino que continúa durante toda la vida útil del agente.

Patrón: evaluar la decisión, no la integración

Un error común es intentar evaluarlo todo a la vez: tanto la toma de decisiones del LLM como las llamadas a APIs externas. En TravelBot, no quieres que la evaluación falle porque la API de búsqueda de vuelos no está disponible. Quieres saber si el agente decidió correctamente: ¿eligió la herramienta adecuada, con los parámetros correctos y por la razón correcta?

What Evaluations Should Test
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Input              LLM Decision           Tool Call         External API
(User request) ►  (Which action?    ►   (search_flights)  ► (Amadeus API)
                   Which params?         (book_hotel)        (Stripe API)
                   Ask for more info?)

                ◄── EVALUATION BOUNDARY ──►
                    Evaluations test        Unit/integration
                    this side               tests cover this side

Simula tus herramientas externas durante la evaluación. Prueba el razonamiento del agente de forma aislada. Es el mismo principio de la pirámide de pruebas tradicional: evaluar cada capa de manera independiente.

Patrón: puntuar salidas estructuradas

Cuando los agentes devuelven datos estructurados (JSON, modelos Pydantic) en lugar de texto libre, los evaluadores genéricos se quedan cortos. Necesitas evaluadores que entiendan tu esquema.

Para la respuesta de reserva de TravelBot:

class BookingResponse(BaseModel):
    action: str            # "book_flight", "cancel", "modify"
    destination: str | None
    dates: DateRange | None
    passengers: int
    follow_ups: list[str]  # items requiring human attention

Una evaluación integral cubre varias dimensiones:

Patrón: comparar modelos y prompts

Una de las fortalezas de LangWatch es ejecutar el mismo dataset con distintas configuraciones y comparar los resultados lado a lado. Para TravelBot, podrías comparar:

• Modelo A (GPT-4o) vs. Modelo B (Claude Sonnet) con las mismas 50 solicitudes de reserva
• Prompt v1 (instrucciones detalladas) vs. Prompt v2 (instrucciones concisas) en cuanto a la corrección de las acciones
• Con guardrails vs. sin guardrails en las puntuaciones de seguridad

El dashboard de experimentos muestra distribuciones de puntuaciones, desgloses por ejemplo y comparaciones estadísticas. Esto transforma la selección de modelos y la ingeniería de prompts: dejan de depender de conjeturas y se convierten en decisiones basadas en datos.

Consideraciones de costo y escalabilidad

Cada ejecución de una evaluación hace llamadas a LLMs tanto para el agente bajo prueba como para el evaluador. Con varios agentes y datasets grandes, los costos se acumulan rápidamente.

Estrategias prácticas:

• Usa un modelo más económico para emitir los juicios de evaluación. Si tu agente funciona con GPT-4o, usa GPT-4o-mini o Claude Haiku para el evaluador LLM-as-Judge.
• Ejecuta evaluaciones de forma selectiva. Evalúa solo los agentes cuyos prompts o código cambiaron en un PR determinado.
• Guarda en caché las respuestas del agente. Cuando iteres sobre la lógica del evaluador, reutiliza las salidas en caché en lugar de volver a ejecutar el agente.
• Empieza con poco. Comienza con 20–50 filas en el dataset que cubran casos límite críticos. Amplíalo a medida que identifiques brechas mediante el monitoreo en producción.

Cuándo usar cada tipo de prueba

Las tres capas de pruebas cumplen propósitos diferentes. Elegir la adecuada depende de lo que quieras averiguar:

El patrón que más valor aporta: usa monitores en producción para encontrar fallas, agrega esos casos a tu dataset de evaluación y verifica si tus correcciones realmente mejoran las puntuaciones.

Cómo empezar

Si estás creando agentes de IA y aún no cuentas con evaluaciones por lotes, esta es una forma práctica de comenzar:

Fase 1: Base

• Instala langwatch y configura tu clave de API
• Crea un solo experimento para tu agente más crítico
• Comienza con 20 entradas seleccionadas que cubran casos límite conocidos
• Usa un evaluador integrado y uno personalizado

Fase 2: Cobertura

• Amplía los datasets con trazas de producción (fallas reales)
• Agrega experimentos para los agentes restantes
• Integra las evaluaciones en CI: haz que los PRs fallen si las puntuaciones caen por debajo del umbral
• Crea evaluadores personalizados para campos de salidas estructuradas

Fase 3: Ciclo de producción

• Habilita el trazado de LangWatch en producción
• Configura monitores con alertas
• Alimenta automáticamente los datasets con trazas de baja puntuación
• Da seguimiento a las tendencias de calidad entre despliegues

La idea clave es que la evaluación no es una actividad de una sola vez. Es un ciclo continuo: medir, identificar brechas, corregir y volver a medir. La combinación de experimentos, evaluadores, datasets y monitores de LangWatch proporciona la infraestructura para ese ciclo.

Fuentes

1. Documentación de LangWatch — Descripción general de evaluaciones: Conceptos fundamentales sobre experimentos, evaluadores, datasets y monitores. langwatch.ai/docs/evaluations/overview

2. LangWatch — Experimentos mediante el SDK: Referencia del SDK de Python para ejecutar experimentos por lotes de forma programática. langwatch.ai/docs/evaluations/experiments/sdk

3. LangWatch — Evaluación de extracción de datos estructurados: Guía para evaluar agentes que producen salidas estructuradas como JSON y modelos Pydantic. docs.langwatch.ai/use-cases/structured-outputs

4. LangWatch — Descripción general de evaluación online: Cómo funcionan los monitores para dar seguimiento a la calidad en producción. docs.langwatch.ai/llm-evaluation/real-time-evaluation

5. LangWatch — Lista de evaluadores: Catálogo completo de evaluadores integrados, incluidos RAGAS, LLM-as-Judge y evaluadores personalizados. langwatch.ai/docs/evaluations/evaluators/list

6. Adaline — La guía completa de evaluación de LLMs y agentes de IA en 2026: Panorama integral de estrategias de evaluación a nivel de prompt, RAG y agentes. adaline.ai/blog/complete-guide-llm-ai-agent-evaluation-2026

7. Orchestrator.dev — Evaluación de IA: herramientas, técnicas y mejores prácticas para 2026: Investigación que muestra que la evaluación sistemática reduce las fallas en producción hasta en un 60%. orchestrator.dev/blog/2026-02-18-ai-evaluation-guide-2026

8. Derek C. Ashmore — La pirámide de pruebas para agentes de IA: Un framework práctico que adapta la pirámide de pruebas a sistemas de IA no deterministas. medium.com/@derekcashmore/the-ai-agent-testing-pyramid

9. Kevin Tan — Cómo probar agentes de IA antes de que causen fallas en producción: Datos de la industria que muestran que solo el 52% de los equipos realiza evaluaciones offline y el 37% evalúa en producción. blog.jztan.com/testing-ai-agents-in-production

10. Zylos Research — Pruebas y evaluación de agentes de IA: la guía completa de 2026: El framework CLASSic (costo, latencia, exactitud, estabilidad, seguridad) para la evaluación de agentes. zylos.ai/research/2026-01-12-ai-agent-testing-evaluation