2026-06-10 · Actualizado 2026-07-22

[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Evaluación de agentes AI en producción: de registros de ejecución a conjuntos de pruebas

Un chatbot te proporciona una única respuesta para que la evalúes. Un agente, en cambio, te entrega todo un árbol de decisiones: planes, tool calls, intentos de reintentar y el momento exacto en el que decidió haber finalizado su proceso.

Esa diferencia exige un método de evaluación distinto. Una respuesta final puede parecer correcta incluso cuando el agente omitió una herramienta necesaria, realizó una llamada 17 veces, interpretó mal un resultado o siguió un camino que la política de producción prohíbe. La calificación basada únicamente en la respuesta oculta esos fallos.

TL;DR: La evaluación de agentes requiere tres capas: métricas de resultado, métricas de trayectoria y métricas de componentes. Se debe estructurar siguiendo este ciclo: rastreo -> etiquetado -> clustering -> eliminación de duplicados -> versiónado de dataset -> verificación en el flujo de integración continua -> monitoreo en tiempo real. Para determinar el orden de las herramientas, los argumentos, los bucles y las invariantes, se deben emplear comprobaciones deterministas. Solo se deben utilizar jueces de tipo LLM cuando la verificación dependa de la interpretación; dichos jueces deben diseñarse mediante Razonamiento Guiado por Esquemas (SGR) y calibrarse con etiquetas proporcionadas por humanos antes de poder confiar en ellos.

Por qué las evaluaciones de agentes son diferentes

Las evaluaciones tradicionales de LLM suelen ponderar una única pareja entrada-salida: relevancia, fidelidad, corrección, seguridad y, en ocasiones, estilo. Los agentes incorporan mecanismos de planificación, tool calls, intentos repetidos y verificaciones de terminación, lo que hace que cada paso sea un nuevo punto potencial de fallo.

Utiliza un agente de reembolso. La transcripción puede finalizar correctamente aunque la traza sea incorrecta:

lookup_order -> issue_refund -> final_answer

La evaluación de salida ha superado la prueba. La evaluación de trayectoria debería fallar porque verify_identity Nunca se ejecutó anteriormente. issue_refund. Para los agentes que utilizan herramientas, las pruebas de evaluación basadas únicamente en respuestas son pruebas de smoke: detectan fallos totales pero pasan por alto todo lo demás.

Existe un segundo problema: los errores se acumulan. Si un flujo de trabajo consta de 20 pasos obligatorios, cada uno de los cuales se ejecuta de forma independiente y todos tienen la misma fiabilidad del 95 %, su tasa de éxito integral ronda el 36 %:

Por lo tanto, el agente puede parecer funcional en pruebas aisladas y, aun así, fallar en la mayoría de las ejecuciones completas. La causa del fallo suele estar en algún punto intermedio, y para identificarla se necesita visibilidad a nivel de componentes, no volver a analizar la respuesta.

Dos equipos de investigación han cuantificado este valor.

tau-bench El escenario asigna al agente tareas de servicio al cliente tanto en el ámbito aéreo como en el minorista. El agente interactúa con un usuario simulado, realiza llamadas a APIs y debe cumplir estrictamente con la política del dominio. Tras la conversación, el evaluador comprueba si la base de datos ha alcanzado el estado objetivo indicado en las anotaciones; incluso una transcripción verosímil que contenga filas incorrectas resultará rechazada.

Bajo esa evaluación, incluso GPT-4o logró superar menos de la mitad de las tareas. El artículo también presentó pass^k: ejecutar la misma tarea k ¡ cuenta las veces y solo registra un paso si el agente tiene éxito en todos ellos! k Se ejecuta.

Los puntajes de retail que parecían aceptables en un primer intento cayeron por debajo del 25% en k = 8El mismo agente se enfrentó a la misma tarea ocho veces y produjo resultados en su mayoría diferentes. Una evaluación realizada en una sola ejecución no puede revelar dicha inconsistencia.

MAST Analiza las causas por las cuales los agentes fallan. Los autores anotaron más de 1.600 trazas de ejecución provenientes de 7 tecnologías multi-agent frameworks populares y clasificaron estos fallos en 14 patrones recurrentes. Dicha taxonomía incluye definiciones vagas de roles (diseño del sistema), casos en los que un agente ignora lo reportado por otro (desalineación entre agentes), así como la declaración de éxito sin verificar el resultado (falta de verificación). Estos fallos están relacionados con prompts, la lógica de orquestación y la ausencia de comprobaciones en harness. Un modelo base más potente no puede llevar a cabo una fase de verificación que nunca se ha implementado, por lo que el objetivo de evaluación debe incluir el harness asociado al modelo.

La brecha de adopción

La encuesta de LangChain indica que muchos de los encuestados ya disponen de los recursos necesarios para realizar evaluaciones más precisas: el 89 % señaló contar con algún tipo de capacidad de observabilidad, mientras que el 52,4 % ejecutó pruebas fuera de línea y el 37,3 % las realizó en línea.

Lo mismo Estado de la ingeniería de agentes

Eso deja a los equipos en una situación incómoda: pueden inspeccionar un ejecución fallida con posterioridad, pero aun así lanzar dos veces el mismo error.

Cada fallo de producción diagnosticado debe dejar como rastro una anotación, una etiqueta, una fila dataset y un valor de puntuación. Los fallos recurrentes deben incluirse en el conjunto de pruebas de regresión.

Selección de métricas por modo de fallo

La métrica adecuada depende del modo de fallo, y no de framework. La división útil contempla tres ámbitos:

1. Las evaluaciones de resultado indican si la tarea se completó con éxito.
2. Las evaluaciones de trayectoria determinan si el camino seguido fue válido, eficiente y conforme a la política establecida.
3. Las evaluaciones de componentes señalan qué herramienta, recuperador de información, subagente o paso de toma de decisiones falló.

Cada ámbito puede ejecutarse offline en casos fijos y reproducibles antes del lanzamiento, o online en trazas de producción muestreadas una vez generada la respuesta. La sección de directrices que aparece a continuación explica en detalle esta distinción. Las evaluaciones offline pueden requerir datos de referencia denominados goldens. Por su parte, las evaluaciones online deben priorizar el uso de invariantes, distribuciones y comprobaciones asíncronas que no interfieran con la ruta de solicitud.

Comencemos con las métricas deterministas. Son económicas, rápidas y no presentan deriva.

Correctitud en las llamadas a herramientas

La corrección de herramientas compara las herramientas llamadas con las herramientas esperadas. Elija la nivel de rigor de forma deliberada:

• Coincidencia exacta: la secuencia debe coincidir al cien por cien. Úsese este caso cuando el orden es un criterio obligatorio, por ejemplo lookup_order -> verify_identity -> issue_refund.
• Coincidencia en orden secuencial: las herramientas requeridas deben aparecer en el orden relativo correcto, pero se permiten llamadas adicionales inocuas.
• Coincidencia sin restricción de orden: las herramientas requeridas deben estar presentes, pero su orden puede variar.

Un pequeño puntuador local es suficiente para comenzar:

from collections import Counter


def tool_correctness(called: list[str], expected: list[str], mode: str = "in_order") -> float:
    if not expected:
        return 1.0
    if mode == "exact":
        return float(called == expected)
    if mode == "any_order":
        matched = sum((Counter(called) & Counter(expected)).values())
        return matched / len(expected)

    rows = [[0] * (len(expected) + 1) for _ in range(len(called) + 1)]
    for i, tool in enumerate(called):
        for j, wanted in enumerate(expected):
            if tool == wanted:
                rows[i + 1][j + 1] = rows[i][j] + 1
            else:
                rows[i + 1][j + 1] = max(rows[i][j + 1], rows[i + 1][j])
    return rows[-1][-1] / len(expected)


called = ["lookup_order", "check_refund_policy", "issue_refund"]
expected = ["lookup_order", "verify_identity", "issue_refund"]

print(round(tool_correctness(called, expected, "exact"), 3))     # 0.0
print(round(tool_correctness(called, expected, "in_order"), 3))  # 0.667

El in_order El score corresponde al recuerdo de la secuencia común más larga: representa qué fracción de la secuencia requerida ha sobrevivido manteniendo el orden correcto. Cabe señalar qué elementos este indicador ignora. Las llamadas innecesarias no lo reducen, por lo que un agente puede obtener una puntuación de 1.0 aun realizando el doble de llamadas de las necesarias. Cuando las llamadas adicionales implican costes económicos o modifican el estado del sistema, es necesario seguir monitorizando también la precisión (el número de llamadas acertadas entre el total realizado) y analizar ambos valores conjuntamente. El recuerdo permite detectar los pasos faltantes, mientras que la precisión identifica aquellos desvíos en el proceso.

La métrica de corrección de herramientas de DeepEval expone los mismos controles a través de should_consider_ordering y should_exact_match.

Correctitud de los argumentos

Llamar a la herramienta adecuada con argumentos incorrectos suele ser peor que utilizar la herramienta equivocada, ya que la traza lógica parece normal.

En los casos sencillos, se valida JSON schema y los valores exactos. En los casos semánticos, se almacenan los argumentos esperados y se evalúan las diferencias:

{
    "trace_id": "tr_2417",
    "input": "Reschedule order A-100 for next Friday.",
    "expected_tools": ["lookup_order", "reschedule_delivery"],
    "expected_arguments": {
        "reschedule_delivery": {
            "order_id": "A-100",
            "date": "2026-06-19"
        }
    }
}

Una métrica de nombre-herramienta no puede detectar 2026-06-17 donde la política lo exige 2026-06-19. El dataset también debe almacenar los argumentos.

La puntuación asociada a ese dataset es parameter-match: la fracción de los valores esperados (tool, key, value) Triplica la cantidad de respuestas correctas del agente.

def argument_correctness(called_args: dict, expected_args: dict) -> float:
    total = matched = 0
    for tool, params in expected_args.items():
        for key, want in params.items():
            total += 1
            if called_args.get(tool, {}).get(key) == want:
                matched += 1
    return matched / total if total else 1.0

La igualdad estricta es adecuada para IDs, enums y fechas. No es apropiada para texto libre y números flotantes, donde == Marca una respuesta correcta como incorrecta. Evalúa esos campos según sus propios criterios: una coincidencia de cadenas normalizada, un análisis de fechas y una tolerancia numérica. La métrica se mantiene igual; solo cambia el comparador específico para cada campo.

Eficiencia, bucles y puntos muertos

Un agente que finaliza la tarea tras cinco intentos redundantes de tool calls sigue presentando problemas de planificación y su ejecución resulta más costosa.

Señales económicas con las que deberías empezar:

• Tasa de llamadas redundantes: aparición de tool calls idéntico con los mismos argumentos repetidos más de dos veces.
• Anomalías en la forma del rastro: aumentos bruscos en la profundidad, el número de llamadas a herramientas, el recuento de tokens, la latencia o el costo.
• Convergencia del camino: grado de cercanía que presenta la ejecución al camino válido más corto conocido para la tarea.
• Corrección de terminación: si el agente se detuvo prematuramente, continuó trabajando tras lograr el éxito o declaró éxito sin realizar el cambio de estado requerido.
• Cumplimiento del plan: si el agente escribe un plan antes de actuar, hay que comprobar si el rastro lo sigue. Tanto un buen plan que es ignorado como uno malo que se sigue al pie de la letra fallan, por razones opuestas; la diferencia entre el plan y el rastro indica cuál de los dos ocurre.

Ejecuta estos pasos antes de someter el código a revisión por un experto siempre que sea posible. Un detector de bucles se encuentra unas pocas líneas más arriba en el rastro de ejecución; no requiere el uso de ningún modelo.

Finalización de tareas y evaluación de resultados

En términos de flujo completo, la pregunta es: «¿El usuario recibió lo que solicitó?»

Dos patrones son los que funcionan mejor:

• Evaluación de la finalización de tareas sin referencia: se extrae el objetivo a partir de la entrada y se determina si el rastro generado junto con la respuesta final lo cumplen. Este enfoque funciona de forma online, ya que el tráfico real rara vez cuenta con respuestas de referencia “golden”.
• Calificación del estado del entorno: se comparan las filas de la base de datos, archivos, tickets, reservas o registros finales con un estado de objetivo anotado. Este método es más robusto que la coincidencia de transcripciones, ya que los agentes pueden encontrar rutas válidas que no se hayan especificado explícitamente.

La segunda opción es la más adecuada cuando se puede implementar. El estado final corresponde al contrato. La transcripción solo sirve como evidencia.

Existen dos consideraciones importantes que deben tenerse en cuenta, ambas relacionadas con el benchmark, método que popularizó la evaluación basada en el estado. Tau-Bench puede asignar una puntuación de aprobación a un agente que no realiza ninguna acción en ciertas tareas sin efecto, ya que el estado inicial ya cumplía con el objetivo. Además, Anthropic informó sobre un caso de ejecución de Opus 4.5 en el que dicho sistema “falló” en una tarea de reserva mediante Tau2-Bench, al encontrar una laguna en la política que, en realidad, resultaba en un mejor resultado para el usuario. Aunque la evaluación basada en el estado supera al método de coincidencia de transcripciones, el estado objetivo sigue siendo una anotación, y las anotaciones pueden contener errores. Es necesario auditar aquellos casos que aprueban con demasiada facilidad, y no solo aquellos que fallan.

El volante de rueda dentada entre el seguimiento de trazas y la evaluación

Antes de plantear casos de evaluación adicionales, es necesario abordar primero los fallos en la producción de minas.

El bucle:

1. Capturar el rastro completo.
2. Etiquetar qué componente falló.
3. Agrupar los fallos similares.
4. Conservar un ejemplo representativo por clúster.
5. Versionar el dataset.
6. Ejecutarlo en entornos de integración continua.
7. Mantener la puntuación de los trazas de producción muestreadas de forma en tiempo real.

El repositorio complementario trace2evals implementa el bucle completo para un agente de soporte defectuoso. Captura los segmentos de GenAI OpenTelemetry, detecta fallos mediante reglas deterministas, elimina duplicados de los casos en una versión estandarizada de dataset y vuelve a ejecutar cada versión en los entornos de CI. La configuración predeterminada basada en scripts no requiere la clave API, por lo que make demo Reproduce el proceso de forma offline.

Fallas en la minería con análisis de errores

Hamel Husain y Shreya Shankar explican un flujo de trabajo de análisis de errores destinado precisamente a este paso; el enfoque de Hamel guía de campo Lo analiza paso a paso. Los dos primeros pasos toman su nombre de la investigación cualitativa, pero el método es sencillo: leer los registros, tomar notas y nombrar los patrones.

1. Codificación abierta: leer de 30 a 50 trazas reales y redactar notas libres sobre los errores que se produjeron.
2. Codificación axial: agrupar esas notas en 5 o 6 categorías de fallo con nombre específico.
3. Etiquetar todo según la taxonomía establecida.
4. Crear métricas para los grupos más grandes.

No comiences con etiquetas como reasoning_issue o tool_problem. Son demasiado vagos como para probarlos. Utilice etiquetas como missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429, o bien stopped_before_database_update. Una etiqueta que indica con precisión qué debe verificar la prueba de regresión.

Elimina las duplicadas antes de promocionarlas

El bucle de minería de trazas presenta un problema: la inclusión permanente de todas las trazas defectuosas. Esto genera un dataset de gran tamaño, alto costo y alcance limitado. Dicho resultado transmite copias casi idénticas de los datos de marzo, al tiempo que omite la nueva manifestación del mismo error en junio.

Primero, agrupa los datos. Selecciona un único ID dorado representativo por cada clúster. Almacena los IDs de seguimiento relacionados en los metadatos para que un revisor pueda examinar las pruebas de producción posteriormente.

Si un clúster con fallos vuelve a aparecer tras una corrección, significa que el caso de regresión no se ha generalizado. Es necesario volver a formar el clúster y ampliar el conjunto de ejemplos de referencia en lugar de añadir solo 15 ejemplos adicionales.

Versionar el dataset

Realiza la versión de datasets de la misma forma que haces con la versión y el código de prompts. Cada vez que se produzca algún cambio relevante (en el modelo, prompt, tool schema, el juicio de prompt, o en el comportamiento de la aplicación), es necesario ejecutar la misma versión de dataset antes y después de dicho cambio.

La puerta de control de integración debe fijar:

• dataset de la versión
• versión de la aplicación
• prompt de la versión
• modelo de evaluación
• evaluar prompt
• versión del código del evaluador

Si se realiza alguna de esas operaciones, la comparación antes/después se vuelve poco clara. A goldens-v3.json El archivo en Git funciona bien a pequeña escala. Las capturas nativas de las herramientas en Langfuse, Phoenix, Braintrust o LangSmith resultan útiles una vez que dataset pasa a ser un entorno colaborativo.

Puerta de control CI

Si una métrica fallida no conduce a una compilación fallida, el conjunto de pruebas de evaluación no es más que un panel de control del que nadie hace uso.

La prueba debe ejecutar nuevamente al agente actual con la entrada de referencia. No debería limitarse a reproducir el rastro anterior que falló:

@pytest.mark.parametrize("golden", GOLDENS, ids=[item["id"] for item in GOLDENS])
def test_agent_regression(golden: dict) -> None:
    answer, fresh_trace = run_agent_and_capture_trace(golden["input"])

    refired = set(flag_failures(fresh_trace)) & set(golden["failure_modes"])
    assert not refired, f"failure mode regressed: {sorted(refired)}"

    assert tool_correctness(
        called=[call["name"] for call in fresh_trace["tool_calls"]],
        expected=golden["expected_tools"],
        mode=golden.get("tool_match", "in_order"),
    ) >= golden.get("tool_threshold", 1.0)

Es fácil cometer un error al distinguir entre estos conceptos. La función del dataset es detectar que la próxima versión del agente repita un fallo anterior, y no archivar el fallo en sí.

Calibre el juez antes de confiar en él

LLM-como-juez resulta útil. También es fácil engañarse a sí mismo con él.

G-Eval Solicita a un jurado que redacte pasos de rúbrica explícitos antes de realizar la puntuación. A continuación, suma cada nivel de calificación ponderado según su probabilidad de aparición ($\text{score} = \sum_i p(s_i)\,s_i$). Este protocolo permitió registrar con mayor precisión las calificaciones humanas que las métricas automáticas anteriores que reemplazó.

El paso ponderado por probabilidad requiere los valores de logprobs calculados por el sistema de evaluación, los cuales algunos modelos alojados no exponen. No obstante, el resultado final sigue permitiendo utilizar una ruta de criterios explícitos en lugar de una puntuación simple.

MT-Bench Se observó que GPT-4 coincidía con las preferencias humanas con una frecuencia similar a la con la que los propios humanos se ponen de acuerdo entre sí, lo que facilitó el uso de LLM para evaluar lo que se considera estándar en la industria. Estudios posteriores revelaron sesgos relacionados con la posición, la longitud del texto y las preferencias personales. Además, las puntuaciones otorgadas por el evaluador pueden variar cuando cambia el prompt o la versión del modelo.

JudgeBench Se crearon pares de respuestas en los que una de las respuestas resultaba objetivamente incorrecta según conocimientos verificables, razonamiento lógico, cálculos matemáticos y código. GPT-4o obtuvo un 50,9 % en ese conjunto de pruebas, mientras que el juez más competente alcanzó aproximadamente un 64 %. Las respuestas correctas pero emitidas con confianza siguen representando un caso difícil para los sistemas de evaluación basados en modelos.

Trata al juez como un instrumento de medición: calíbralo con etiquetas humanas antes de que evalúe cualquier cosa, y vuelve a verificarlo cada vez que el modelo del juez o prompt sufra cambios.

Cuando sea necesario un árbitro, estructura el veredicto de forma adecuada. Razonamiento guiado por esquema (SGR) define la ruta de razonamiento del juez como un esquema Pydantic. Structured Outputs o constrained decoding, lo que exige campos tales como evidence, passed_criteria, failed_criteria, failure_mode, y score.

Coloque los campos de evidencia antes de la puntuación. A continuación, el evaluador aplica las mismas fases predefinidas de la rúbrica, en el mismo orden de campos, en cada ejecución y con todos los modelos compatibles. Un revisor puede inspeccionar los campos nombrados en lugar de analizar un párrafo completo. El sistema de integración continua puede realizar comparaciones diferenciales entre objetos JSON estables, mientras que el conjunto de calibración indica qué fase de la rúbrica presentó discrepancias con la etiqueta asignada por el humano.

También puede modificar la curva de costes. Considere un modelo más económico como candidato, pero no como sustituto automático. Ejécutelo con el mismo conjunto de calibración etiquetado por humanos. Compare su grado de concordancia, tasa de falsos positivos y tasa de falsos negativos con las del modelo principal. Úselo únicamente en casos rutinarios si supera los umbrales establecidos por su conjunto de aplicaciones. Reserve el modelo principal para situaciones de desacuerdo, casos de alto riesgo o ejecuciones de calibración.

Lista de verificación estándar de higiene para jueces:

1. Preferir siempre un resultado binario de aprobado/rechazado cuando sea posible. Las escalas de cinco puntos fomentan una apariencia falsa de precisión.
2. Etiquetar manualmente entre 30 y 50 trayectorias antes de elaborar la rúbrica final.
3. Evaluar la concordancia entre los jueces y los humanos mediante el coeficiente de kappa de Cohen (que corrige la concordancia por azar, por lo que un juez que siempre otorga “aprobado” obtiene una puntuación cercana a cero) o simplemente mediante las métricas TPR/TNR.
4. Descomponer los criterios generales. Preguntas como “¿Verificó el agente la identidad antes del reembolso tool call?” son más útiles que “¿Fue buena la trayectoria?”.
5. Emitar el veredicto a través de un esquema SGR que incluya pruebas, los criterios incumplidos, el modo de fallo y la puntuación obtenida.
6. Utilizar, siempre que sea posible, un juez perteneciente a una familia de modelos distinta a la del generador.
7. Aleatorizar el orden de las comparaciones entre pares y calcular el promedio en ambas direcciones.
8. Sancionar la inclusión en la rúbrica de respuestas de longitud no permitida. Una respuesta más larga no implica necesariamente que sea mejor.
9. Fijar de forma estable el modelo del juez, prompt, dataset, el esquema y la versión de la aplicación.
10. Volver a calibrar los parámetros tras cualquier cambio en el modelo, prompt, la herramienta, la política o el esquema.

Para obtener puntuaciones de alto valor, utilice un jurado reducido en lugar de un único evaluador principal. PoLL Se probó un grupo formado por varios jueces menores provenientes de familias de modelos distintas, y se combinaron sus veredictos. A lo largo de seis datasets, este panel logró reproducir con mayor precisión los juicios humanos que un único juez basado en GPT-4. Además, evitó el sesgo de preferencia propia propio de los jueces individuales y tuvo un costo siete veces menor. Mantenga la revisión humana para las decisiones que afecten a cuestiones financieras, de acceso, de seguridad o de cumplimiento normativo.

Si un juez coincide con los humanos en un valor de kappa de 0,55 en tu tarea, no lo utilices para bloquear despliegues; úsalo para ordenar las colas de revisión. Si el valor se acerca a 0,75 y el costo por error es moderado, resulta mucho más sencillo justificar la implementación de una puerta de control de integración continua.

Las reglas de seguridad bloquean las evaluaciones en línea directas, mientras que las evaluaciones posteriores se realizan de forma remota.

La gente las confunde porque ambas generan puntuaciones. La diferencia radica en su ubicación: de forma incrustada en la ruta de la solicitud, antes de la publicación, o después de la respuesta.

Guardrails se ejecutan de forma en línea. Son rápidos, deterministas y visibles para el usuario. Un guardrail puede bloquear un tool call, censurar datos PII, rechazar prompt injection o forzar una repetición antes de que la respuesta salga de su sistema. Un falso positivo constituye un error en producción.

Evaluaciones offline se ejecutan antes del lanzamiento. Son reproducibles. Ellas sirven como filtro para prompts, modelos, herramientas, recuperadores y políticas, verificándolos contra un dataset fijo.

Evaluaciones en tiempo real se ejecutan después de la respuesta, generalmente sobre tráfico muestreado. Pueden utilizar evaluadores LLM más lentos, ya que no forman parte del camino de latencia. Su función es detectar desviaciones, identificar nuevos grupos de fallos y proporcionar los datos al siguiente proceso dataset fuera de línea.

Si se equivoca en la colocación, perjudica de todas formas:

• Un juez en la ruta de solicitud añade latencia y una nueva fuente de volatilidad.
• Una medida de seguridad relegada al procesamiento asíncrono permite que las infracciones de políticas lleguen hasta los usuarios.

En los sistemas de alto volumen, se debe evaluar una muestra pequeña con un modelo de mayor precisión y una muestra más amplia con clasificadores de menor costo. Se deben generar alertas basadas en clústeres y rangos de confianza, y no en una única estimación afectada por ruido.

Opciones de herramientas

Ninguna herramienta individual gestiona todo el ciclo completo. Las soluciones más robustas emplean dos componentes: un almacén de trazas y un ejecutor de CI/evaluación.

Las notas sobre los compromisos técnicos describen de dónde proviene el costo, no cuál es en sí. Las páginas de precios pueden cambiar, y los proveedores contabilizan elementos diferentes: trazas, observaciones, intervalos, puntuaciones, usuarios, tasa de retención o datos procesados. Revise los precios en tiempo real antes de tomar una decisión.

Atajos de toma de decisiones:

• Necesita rastreo autohospedado con portabilidad OTel: comience con Phoenix o Langfuse.
• Necesita una puerta de control CI basada en código: comience con DeepEval.
• Ya está comprometido con LangGraph: LangSmith resulta práctico.
• Desea revisión gestionada de regresiones en PR: Braintrust es insuperable.
• Los casos de seguridad y equipos de ataque ético son prioritarios: Promptfoo es la herramienta más adecuada.
• Investigación en seguridad o trabajo controlado con benchmark: Inspect AI es la opción más adecuada.

La elección de la herramienta es secundaria. Si los fallos en producción no se convierten en casos de prueba,, en la mayoría de los casos solo estás pagando por el almacenamiento de trazas.

Lista de verificación práctica para la implementación

Construya la evidencia pipeline antes de ampliar la pila de métricas. Comience decidiendo de dónde provendrán los ejemplos.

1. Recopile primero los registros históricos. Si el agente ya existe, obtenga las trazas, los tickets de soporte, los informes de errores, las sesiones con valoración negativa, las transcripciones de pruebas de calidad manuales y las notas de uso interno antes de modificar la implementación. Si el agente aún no existe, registre cada prototipo y cada ejecución de prueba manual desde el primer día.

2. Instrumentar la forma del trazado. Capturar mensajes, tool calls, argumentos, salidas de herramientas, errores, conteos de tokens, latencia, costo, retroalimentación del usuario, versión de la aplicación, versión de prompt, versión del modelo, versión de tool schema, y el estado final del entorno. Utilizar OpenTelemetry Convenciones de GenAI O bien utiliza segmentos al estilo de OpenInference si buscas portabilidad. Aplica Langfuse, LangSmith, Phoenix o Braintrust si deseas contar con una interfaz gráfica para el seguimiento del proceso y un flujo de trabajo basado en dataset de forma inmediata.

3. Convierta los fallos reales en casos de ejemplo. Lea las trazas antes de resumirlas mediante un modelo. Para cada fallo útil, guarde la entrada, el ID de la traza de origen, el estado esperado, las invariantes de la herramienta esperadas, el modo de fallo, la gravedad y la nota del revisor. Langfuse puede vincular los elementos dataset con las trazas de producción; LangSmith puede generar datasets a partir de ejecuciones rastreadas. Mantenga el enlace de origen para que el caso siga siendo auditable.

4. Si no existe historial, se deben generar casos de arranque en frío. Se debe solicitar a un LLM que elabore tareas a partir de los requisitos del producto, las políticas, tool schemas, las máquinas de estado y las macros de soporte. Estas tareas deben abarcar escenarios óptimos así como fallos como permisos incorrectos, ausencia de verificaciones de identidad, tool results desactualizados, fechas ambiguas, intentos de reintentado tras alcanzar los límites de frecuencia y resultados contradictorios de las herramientas.

5. No confíe en los casos sintéticos hasta que un humano los revise. Los ejemplos sintéticos son útiles para la cobertura, no para la veracidad. Marquelos con source: synthetic Y se requiere que un revisor apruebe el resultado esperado. Cuando sea posible, ejecute una ruta de referencia conocida y funcional, y utilice diferentes familias de modelos para generar el caso de prueba y evaluar el resultado.

6. Construya un dataset pequeño y equilibrado. Debe incluir casos de éxito, fallos, rechazos, casos límite, casos con interacciones largas, casos sensibles a las políticas definidas, así como rutas alternativas válidas. No se debe crear la “transcripción original exacta” como referencia ideal; en su lugar, dicha referencia debe codificar el resultado esperado, las invariantes permitidas y los modos de fallo correspondientes.

7. Añada primero las comprobaciones deterministas. El orden obligatorio de las herramientas es el siguiente: la política de orden, los argumentos necesarios, la validación del esquema, las diferencias entre estados finales, los límites de bucle, los topes de tokens y latencia, y las invariantes específicas de la tarea deben ejecutarse antes que cualquier otro componente de evaluación.

8. Añada un juez con forma de SGR. Úselo únicamente en la parte que requiera interpretación. Calíbrelo utilizando etiquetas proporcionadas por humanos. Si no es capaz de distinguir entre ejemplos buenos y malos en el conjunto de calibración, modifique primero las reglas de evaluación antes de integrarlo en los procesos de integración continua.

9. Conectar el bucle. Ejecutar el conjunto de pruebas pequeño en entorno offline dentro del proceso CI, ejecutar el conjunto más amplio antes del lanzamiento, evaluar el tráfico de producción muestreado en línea, y volver a introducir en el entorno offline los clústeres de fallos recurrentes detectados en línea dataset.

Tu primera suite de evaluación tendrá errores de forma bastante predecible. Úsala igualmente. Una suite que se ejecuta a diario es más fácil de corregir que un documento de diseño perfecto que nunca impida la aceptación de una solicitud de integración defectuosa.

Referencias

• repositorio de demostración complementario de trace2evals
• LangChain: Estado actual de la ingeniería de agentes
• Anthropic: Desmitificando las evaluaciones para agentes AI
• Hamel Husain - Una guía práctica para mejorar rápidamente los productos AI
• OpenTelemetry convenciones semánticas para la generativa AI sistemas
• Correctitud de la herramienta DeepEval
• Completación de tareas DeepEval
• Razonamiento guiado por esquema en vLLM: Structured Outputs mediante xgrammar y Pydantic
• Langfuse datasets y control de versiones
• LangSmith: crear y gestionar datasets de forma programática
• Braintrust: realizar una evaluación de forma sistemática
• Phoenix LLM realiza la evaluación
• Integración con GitHub Actions de Promptfoo
• tau-bench: Una Benchmark para la interacción herramienta-agente-usUARIO en dominios del mundo real
• ¿Por qué fallan los sistemas Multi-Agent LLM?
• G-Eval: Evaluación de NLG mediante GPT-4 con una mejor alineación con los criterios humanos
• Evaluación de LLM como juez mediante MT-Bench y Chatbot Arena
• Sustituir jueces por jurados: evaluación de las generaciones LLM mediante un panel de modelos diversos
• JudgeBench: Un Benchmark para evaluar jueces basados en LLM
• Sesgo de auto-preferencia en LLM como juez