Langfuse on lo0 — Blog Técnico

Evals: la capa después del tracing que decide si tu LLM rinde o sólo parece rendir

Wed, 20 May 2026 00:12:00 +0200

TL;DR

Tracing te dice qué ha pasado dentro de tu aplicación LLM: qué prompts entraron, qué tokens salieron, qué tools se llamaron. Evals te dice si eso está bien. Son dos capas distintas: no hay overlap, no hay sustitución, hay continuidad. En 2026 el campo se ha estabilizado alrededor de una arquitectura de dos pisos: un framework ligero estilo pytest (DeepEval, Promptfoo, Ragas) que corre en CI y bloquea el merge si la regresión es seria, y una plataforma de observabilidad (Langfuse, LangSmith, Arize Phoenix, Braintrust) que persiste evaluaciones a largo plazo, permite anotación humana, detecta drift, da dashboard a stakeholders. La técnica dominante es LLM-as-a-judge: un modelo evaluador con una rúbrica determina si la respuesta es buena, 80-90% de acuerdo con humanos a 500-5000x menos coste y, calibrado correctamente, en producción. Para RAG hay las cuatro métricas canónicas de Ragas (faithfulness, answer relevancy, context precision, context recall). Para agentes, trajectory matching, accuracy de selección de tools y pass^k —la métrica recién popularizada por Tau-bench que reveló que muchos agentes con pass^1 alto tienen pass^4 hasta 25 puntos por debajo, es decir, son inconsistentes—. Este artículo recorre los seis ángulos: por qué evaluar LLMs es distinto, las cuatro patas de un sistema de evals, LLM-as-a-judge en serio (G-Eval, position bias, calibración), métricas para RAG y agentes, el panorama de herramientas 2026 con sus diferencias reales, y la receta operativa para tener evals que no sean teatro.

Este artículo abre la serie de capas post-tracing. Viene encadenado del cierre de la serie eBPF de ayer (AgentSight y el nuevo tracing de LLMs), donde quedó apuntado que evals es “el mundo aparte que sigue al tracing”. Es ese mundo.

La analogía: el test suite que tu pipeline de ML siempre quiso

Quien lleve años desarrollando software no encontrará nada raro en la idea de tests automatizados: cada commit dispara una suite que se valida contra outputs esperados, y si algo se rompe, el merge falla. Es lo que separó programar en los 90 de programar en los 2010. Imposible imaginar producción sin esto.

Cuando llegaron los modelos de Machine Learning clásicos, el patrón se preservó parcialmente: tests de entrada/salida determinista, plus métricas de modelo (accuracy, F1, AUC) sobre un dataset de validación. Imperfecto pero funcionaba; los modelos eran determinísticos y las predicciones tenían etiquetas claras.

Con los LLMs, el patrón se rompió. ¿Cómo testeas que la respuesta a “explícame qué es un transformer” es correcta? No hay una sola respuesta correcta, hay una distribución de respuestas razonables. ¿Cómo testeas que un agente eligió la herramienta adecuada para resolver un problema multistep? La función de coste es subjetiva, dependiente del contexto, y a menudo emerge solo cuando el dominio experto lo mira.

Lo que ha pasado en los últimos tres años es la construcción colectiva del equivalente al test suite para LLMs. Aún imperfecto, aún en evolución, pero ya operacionalmente viable. Las piezas existen: datasets curados, evaluadores que escalan (LLM-as-a-judge), frameworks que corren en CI, plataformas que persisten regresión. Lo que cambia respecto a tests tradicionales es que el resultado del eval también es probabilístico: el judge se puede equivocar; medimos su acuerdo con humanos y aceptamos un umbral. Vivimos con la incertidumbre como parte del sistema.

Por qué evaluar LLMs es estructuralmente distinto

Cinco diferencias que cambian todo:

No-determinismo. Mismo input → distinto output según temperature, top_p, seed. Un test que pasaba ayer puede fallar hoy sin haber tocado nada. La solución no es eliminar el no-determinismo (a veces lo quieres); es medir en distribución, no en una muestra única.

No hay golden answer única. Para “resume este artículo en 3 frases”, hay miles de resúmenes válidos. Comparar bit-a-bit con una “respuesta correcta” es absurdo. Evaluamos propiedades de la respuesta (fidelidad, concisión, no contradicción), no igualdad textual.

Métricas clásicas son insuficientes. BLEU, ROUGE, BERTScore funcionaban en traducción automática y resumen extractivo. Para generación abierta correlan muy mal con juicio humano. Es famoso el contraejemplo: una respuesta semánticamente correcta puede tener BLEU bajo porque usa otras palabras; una respuesta incorrecta puede tener BLEU alto porque copia tokens del input. Hace falta otra cosa.

Coste cuadrático del juicio humano. La alternativa obvia —“que personas evalúen cada respuesta”— escala terriblemente. Una app con 100 conversaciones/día genera 3.000/mes; evaluar cada una requiere horas de un humano caro. Para apps con miles o millones de queries, inviable.

Drift en producción. El modelo no cambia; el mundo cambia. Cambia el vocabulario de los usuarios, cambia el contenido de los documentos del RAG, cambia el comportamiento de los modelos cuando vendor los actualiza silenciosamente. Sin eval continuo, la app degrada y nadie se entera hasta que un cliente se queja.

Estos cinco puntos explican toda la arquitectura moderna de evals: necesitamos automatizar el juicio (LLM-as-a-judge), medir propiedades en distribución (no igualdad exacta), persistir resultados a lo largo del tiempo (detección de drift) y mantener un anclaje humano (golden datasets calibrados).

Las cuatro patas de un sistema de evals

Cualquier framework moderno gira sobre cuatro componentes:

1. Datasets

Un dataset de evaluación tiene una forma mínima: lista de entradas + cómo se juzga cada salida. Dos modelos:

Dataset con golden output: para cada entrada, tienes la respuesta correcta (o una lista de aceptables). El evaluador compara generación con golden. Caso típico: NER, clasificación, traducción.
Dataset con criteria: para cada entrada, tienes una rúbrica abstracta (“la respuesta debe ser factual respecto al contexto”, “el tono debe ser profesional”). No hay golden; el evaluador aplica la rúbrica.

Los datasets buenos en producción son mantenidos activamente: empiezas con 20-50 ejemplos curados a mano, los etiquetas con resultados deseados, y vas creciendo el dataset con los casos reales que han causado problemas (regression dataset). Después de un año en producción, debería haber cientos o miles de casos, cada uno respaldado por una incidencia o un patrón observado.

2. Evaluators

Lo que toma generación + criterios y devuelve un score. Cuatro familias:

Determinísticos / heurísticos: regex, longitud, presencia de tokens, validación de JSON schema. Rápidos, baratos, pero solo aplicables a propiedades sintácticas.
Semánticos clásicos: BERTScore, embeddings cosine similarity. Mejor que BLEU para igualdad semántica, pero limitados a “comparar contra golden”.
LLM-as-a-judge: un modelo —típicamente GPT-4, Claude, o un open-source especializado como Prometheus— recibe generación + criterios y devuelve score. El caballo de batalla del campo en 2026.
Humanos: la verdad de referencia. Caro, lento, pero indispensable como anclaje (golden set).

En una pipeline madura, los cuatro coexisten: heurísticos como gate inicial (¿es JSON válido?), semánticos para checks rápidos, LLM-as-judge para la mayoría de evaluación, y humanos en muestreo periódico para calibrar.

3. Runners

Ejecutan dataset × evaluators y producen el cuadro de resultados. Lo que en pytest serían pytest --collect-only + pytest -v. Las cosas que un runner serio tiene que hacer:

Paralelización: cientos de prompts no pueden ejecutarse en serie.
Caché: si re-ejecutas un eval con el mismo prompt y modelo, no pagar dos veces.
Retry y backoff: rate limits de las APIs son la norma.
Trazabilidad: cada run identificado con commit, version del prompt, version del dataset, version del evaluator.
Aggregation: medias, percentiles, breakdown por segmento.

4. Storage y analytics

Un eval que se ejecuta y se imprime en pantalla no sirve. Hay que persistir resultados a lo largo del tiempo para detectar regresión y drift. Aquí entran las plataformas (Langfuse, LangSmith, Phoenix): cada eval-run se guarda con metadata, se puede comparar contra runs anteriores, se generan dashboards.

LLM-as-a-judge: el caballo de batalla

Esta es la técnica que ha hecho factible eval automático a escala. Vale la pena entender bien cómo funciona y qué problemas tiene.

El modelo básico

Le das al judge un prompt estructurado:

You are evaluating the quality of a customer support agent's response.
User question: "How do I cancel my subscription?"
Agent response: "To cancel, log into your account, go to Settings >
Billing, click Cancel. Note that you'll retain access until the end
of your current billing period."
Rubric:
- Accuracy (1-5): Does the response factually answer the question?
- Completeness (1-5): Does it cover all relevant steps?
- Tone (1-5): Is it professional and helpful?
Provide a JSON response with the three scores and a brief justification.

El judge devuelve un JSON. Las tres notas, una justificación corta. Caso resuelto.

Scoring rubric vs pairwise comparison

Dos modelos principales:

Scoring rubric (absoluto): el judge devuelve un número en una escala (típicamente 0-1, 1-5 o 1-10). Sencillo, ortogonal entre evaluaciones. Pero los modelos LLM son malos en escalas absolutas: tienden a apilarse en valores medios (3-4 en escala 1-5) y a no usar los extremos. Las correlaciones con humanos en scoring absoluto suelen rondar el 0.6-0.7.

Pairwise comparison: el judge ve dos respuestas (A y B) y elige cuál es mejor. Los modelos son mucho mejores en pairwise que en absoluto; las correlaciones suben a 0.75-0.85. Razón: es la tarea natural de un modelo de lenguaje (modelar relación entre dos cosas), no asignar números abstractos.

La práctica recomendada: usar pairwise cuando puedas. Para regresión ("¿v4 del prompt mejora sobre v3?"), pairwise es ideal. Para producción ("¿esta respuesta es buena?"), donde no tienes otra contra qué comparar, scoring absoluto con cuidado.

G-Eval: el patrón que más se usa

G-Eval (Liu et al., NAACL 2023) es el patrón de prompting que más correlación con humanos consigue de los métodos públicos. Tiene tres ingredientes:

Auto-CoT: el prompt induce al judge a generar su propia cadena de razonamiento sobre los pasos a evaluar antes de dar nota. No le dices la rúbrica; le pides que la deduzca y aplique.
Form-filling: en lugar de pedir números libres, el judge rellena un formulario estructurado con campos específicos (presencia de elementos, errores detectados).
Probability-weighted scores: en lugar de “qué nota das”, se pide la probabilidad de cada nota y se hace una expectativa ponderada. Mitiga la tendencia a apilarse en valores medios.

G-Eval implementado bien alcanza 0.89 de correlación de Spearman con humanos en datasets de summarization. Es lo que las plataformas serias usan por defecto bajo el capó. Para tu trabajo: no implementes G-Eval a mano; usa la versión de DeepEval o de Phoenix que ya lo trae.

Calibración contra humanos: el paso no negociable

Un judge sin calibrar es teatro. La práctica:

Construye un golden set anotado por humanos (50-200 ejemplos como mínimo).
Corre el judge sobre ese golden set.
Mide el agreement con humanos (Cohen’s kappa, Spearman, o accuracy si la tarea es binaria).
Si el agreement es <85%, el judge no es fiable para esa tarea; itera sobre el prompt o cambia de modelo judge.
Repite cada 60-90 días. Los judges drift en silencio: cambios de versión del modelo, cambios de comportamiento que el vendor hace sin avisar.

El número de referencia que cita la literatura 2026: 85-90% de agreement con humanos es el umbral para considerar el judge productivo. Por encima, automatizas con cobertura humana en muestreo. Por debajo, sigues siendo manual.

Los sesgos del judge: lo que pega tiros en producción

Cinco sesgos identificados que cualquier judge tiene en algún grado:

Position bias: en pairwise, el judge favorece la respuesta que aparece primero (o última, según modelo). Mitigación obligatoria: swap and average — corre cada par dos veces, una en orden A-B y otra en B-A, y promedia. Si los dos órdenes contradicen, ese par es ambiguo, lo marcas como tal.

Length bias: respuestas más largas tienden a recibir mejor nota porque “parecen más completas”. Mitigación: normaliza por longitud o penaliza explícitamente en la rúbrica. Las plataformas modernas detectan esto y lo reportan.

Verbosity bias: similar al length bias pero con jerga técnica: respuestas que suenan más sofisticadas se puntúan mejor, aunque sean menos correctas. Mitigación: usar judges que citen evidencia concreta del input.

Self-preference: si el judge es del mismo proveedor que el modelo evaluado (GPT-4 evaluando GPT-4), tiende a favorecer respuestas del propio proveedor por estilo. Mitigación: cross-judge — usa un judge de un proveedor distinto al modelo bajo prueba.

Shortcut bias (el “Silent Judge” del paper de 2025): los judges aprenden atajos no intencionados; por ejemplo, asociar respuestas que empiezan por “Certainly!” con mayor calidad porque sí. Mitigación: tener una rúbrica explícita y ejemplos calibrados; medir agreement contra golden set humano periódicamente.

Coste y judges open-source

GPT-4 como judge es excelente pero caro. A 5 USD/millón input tokens y 15 USD/millón output, una pipeline que evalúa 50 000 respuestas/día puede costar decenas de miles de USD/mes solo en evals.

La respuesta del campo: judges open-source especializados. Prometheus (KAIST + LG AI) entrena un modelo open-source pequeño específicamente para juzgar con rúbrica, y alcanza 0.897 de correlación de Pearson con humanos en 45 rúbricas — comparable a GPT-4 (0.882) a una fracción del coste.

Otros modelos en la misma línea: JudgeLM, PandaLM, modelos Auto-J. La práctica madura es usar judges open-source para la mayoría del tráfico, GPT-4/Claude para casos críticos (regresión profunda, golden set re-evaluación).

Métricas específicas para RAG

Si tu sistema es Retrieval-Augmented Generation, hay cuatro métricas canónicas que Ragas popularizó y que el resto del ecosistema ha adoptado:

Faithfulness (fidelidad)

¿La respuesta se atiene a los documentos recuperados? Mide alucinación. Se calcula descomponiendo la respuesta en afirmaciones individuales y verificando cuántas están respaldadas por el contexto. Rango 0-1.

Crítico para sistemas donde la respuesta debe ser sourced (legal, médico, financiero). Una respuesta puede sonar bien y aún así inventar; faithfulness lo cazas.

Answer Relevancy (relevancia de la respuesta)

¿La respuesta responde a la pregunta? Independiente de si es factualmente correcta — solo mide on-topic. Se calcula generando varias preguntas inversas a partir de la respuesta y midiendo cuánto se parecen a la pregunta original.

Importante para detectar off-topic drift: respuestas que evaden la pregunta o se desvían.

Context Precision (precisión del contexto)

De los documentos recuperados, ¿cuántos son realmente relevantes? Si tu retrieval devuelve 10 chunks y solo 3 son útiles, la precisión es 0.3. Métrica del retrieval, no del LLM.

Diagnóstico clave: precisión baja indica retrieval ruidoso, probablemente porque el embedding model no captura semántica fina o el chunking es demasiado grande.

Context Recall (recall del contexto)

De los documentos relevantes que existen, ¿cuántos se han recuperado? Requiere golden (saber qué documentos eran los correctos).

Recall bajo indica retrieval limitado: el sistema no encuentra documentos que existían y eran relevantes. Causas: k demasiado bajo, query embedding mal, chunking que rompe contexto necesario.

El cuadrante diagnóstico de RAG

Las cuatro métricas combinadas dan un diagnóstico estructurado:

Faithfulness	Relevancy	Precision	Recall	Diagnóstico
Alto	Alto	Alto	Alto	Sistema sano
Bajo	Alto	Alto	Alto	LLM alucina sobre buen contexto
Alto	Bajo	Alto	Alto	LLM divaga sobre pregunta
Alto	Alto	Bajo	Alto	Retrieval ruidoso (k alto, embeddings malos)
Alto	Alto	Alto	Bajo	Retrieval incompleto (k bajo, chunking malo)
Bajo	Bajo	Bajo	Bajo	Empieza por arreglar retrieval

Ragas mantiene además otras métricas más sofisticadas: noise sensitivity (cómo afecta inyección de ruido), context entities recall (recuperación de entidades específicas), multimodal faithfulness/relevance para RAG sobre imágenes y vídeo.

Métricas específicas para agentes

Los agentes con tool use multi-step rompen el modelo single-turn de RAG. Necesitan métricas que entiendan trayectoria de acciones, no solo respuesta final.

Tool selection accuracy

¿El agente eligió la herramienta correcta? Métrica clásica de classification. Para cada turno donde el agente tenía que decidir entre herramientas, comparas selección con la correcta.

Variantes:

Exact match: la herramienta elegida es la golden.
Top-k: la golden está entre las top-k consideradas (medido por logprobs si están disponibles).

Trajectory matching

Compara la secuencia completa de acciones del agente con una trayectoria golden. Para tareas multistep, una respuesta final correcta puede haberse llegado por un camino tortuoso e ineficiente, o por un camino directo. Trajectory matching captura la diferencia.

Variantes:

Exact trajectory: secuencia idéntica de tool calls (rara vez factible).
Soft trajectory: porcentaje de pasos correctos, permitiendo ramas alternativas válidas.
Trajectory similarity: embedding de la secuencia comparado con embedding de la golden.

Task completion rate

¿El agente terminó la tarea exitosamente? Métrica binaria al final. Crítica para benchmarks como Tau-bench (Sierra), GAIA (Meta + HF), SWE-bench (Princeton).

pass^k: la métrica que cambió las leaderboards

Tradicionalmente los benchmarks reportaban pass^1: ejecutas el agente una vez por tarea, mides cuántas resolvió. El problema de no-determinismo: una ejecución sola es ruido.

pass^k ejecuta cada tarea k veces y mide si el agente la resuelve en las k ejecuciones. Es decir: pass^4 = “el agente resuelve esto consistentemente las 4 veces”. Métrica de fiabilidad, no de capacidad puntual.

El descubrimiento que ha agitado el campo 2026: pass^4 suele estar 15-25 puntos por debajo de pass^1. Es decir, muchos agentes que parecen estado del arte en leaderboards single-run resuelven la tarea solo a veces. Productivamente significa que esos agentes no se pueden poner en producción tal cual — necesitan reintentos, autoconsistencia o human-in-the-loop. Tau-bench fue el primero en formalizar este reporting y otros benchmarks lo están adoptando (Tau²-Bench, ATBench, TRAJECT-Bench).

Benchmarks 2026 importantes

Tau-bench / Tau²-Bench (Sierra): tool-agent-user interaction en dominios empresariales (retail, airline). Reporta pass^k.
GAIA: tareas que requieren razonamiento + tool use + web browsing.
SWE-bench: arreglo de bugs en repos reales de GitHub. El benchmark más exigente para agentes de coding.
ATBench (2026): foco en safety durante la trayectoria, no solo en respuesta final.
TRAJECT-Bench: agentic tool use evaluado a nivel trayectoria con métricas estandarizadas.
Inspect AI evals (UK AI Safety Institute): foco en capability y safety, abierto.

El panorama de herramientas 2026

El campo se ha estabilizado en dos categorías que rara vez compiten directamente:

Categoría A: testing frameworks (gating en CI)

Pensados para correr como tests, bloquear merges, dar feedback rápido al desarrollador.

DeepEval (Apache 2.0). El más popular hoy. Estilo pytest:

from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import GEval, FaithfulnessMetric

def test_rag_response():
 test_case = LLMTestCase(
 input="What's the capital of France?",
 actual_output=my_rag_app("What's the capital of France?"),
 retrieval_context=docs,
 )
 geval_metric = GEval(
 name="Correctness",
 criteria="Determine if the answer is factually correct.",
 evaluation_params=["input", "actual_output"],
 )
 faithfulness = FaithfulnessMetric(threshold=0.7)
 assert_test(test_case, [geval_metric, faithfulness])

Trae 30+ métricas pre-hechas, incluye G-Eval, integra con CI/CD trivial. La librería más completa en cobertura.

Promptfoo (MIT). CLI-first, configuración en YAML. Especializado en red teaming y comparación de modelos:

providers:
 - openai:gpt-4o
 - anthropic:claude-3.5-sonnet
 - openrouter:meta-llama/llama-3.3-70b

prompts:
 - "Summarize: {{text}}"

tests:
 - vars:
 text: "..."
 assert:
 - type: llm-rubric
 value: "Summary is accurate and concise"
 - type: contains
 value: "..."

Corre la misma evaluación contra muchos providers simultáneamente. Fantástico para “qué modelo conviene a esta tarea”. Pioneer en red teaming automatizado: genera ataques de prompt injection y mide robustez.

Ragas (Apache 2.0). Especializado en RAG. Implementa las 4 métricas canónicas más una docena más, lightweight, sin opinionado sobre tu stack:

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

result = evaluate(dataset, metrics=[
 faithfulness, answer_relevancy, context_precision, context_recall
])

Si tu sistema es RAG y solo RAG, Ragas es la apuesta más directa.

Otros relevantes: OpenAI Evals (el clásico, OSS), LangSmith Evals SDK (para usuarios LangChain), Inspect AI (UK AISI, fuerte en safety/capability evals).

Categoría B: plataformas (storage + dashboard + regresión)

Pensadas para persistencia a largo plazo, anotación humana, regresión, dashboards a stakeholders.

Langfuse (MIT, self-host disponible). Cubierta en profundidad ayer. Para evals: ejecuta evaluators en background sobre traces de producción, permite human labeling en UI, integra con datasets y prompt management. Es la opción más completa OSS.

LangSmith (comercial). Si usas LangChain, integración cero-config. Datasets, evaluator SDK, runs comparables side-by-side. UI limpia para stakeholders.

Arize Phoenix (ELv2, OSS). OTel-native, fuerte en RAG por su énfasis en retrieval. Evals built-in con LLM-as-judge configurable.

Braintrust (comercial, OSS lite). El competidor más joven en plataformas; fuerte en datasets y comparativa side-by-side. Adoptado por equipos que vienen de hacer evals “en una hoja de cálculo” porque la UX está pulida.

Tabla comparativa: testing frameworks vs platforms

Herramienta	Tipo	Licencia	Self-host	Especialidad	Idóneo cuando
DeepEval	Framework CI	Apache 2.0	N/A	Maximalismo de métricas	Quieres pytest para LLMs, 30+ métricas listas
Promptfoo	Framework CI	MIT	N/A	Modelo comparison + red teaming	Eliges modelo, atacas prompt
Ragas	Framework CI	Apache 2.0	N/A	RAG end-to-end	Tu sistema es exclusivamente RAG
OpenAI Evals	Framework CI	MIT	N/A	Clásico, simple	Empezando, OpenAI nativo
Inspect AI	Framework CI	MIT	Sí	Safety / capability evals	Evaluación de modelos base, alignment
Langfuse	Platform	MIT	Sí	Suite completa (trace+eval+prompts)	OSS, self-host, equipo iterativo
LangSmith	Platform	Comercial	No	LangChain ecosystem	Tu stack es LangChain
Arize Phoenix	Platform	ELv2 (OSS)	Sí	OTel-native, RAG	Estandarización OTel, RAG profundo
Braintrust	Platform	Comercial + OSS	Limitado	UX pulida, datasets	Stakeholders no-técnicos, side-by-side

La receta operativa: stack de dos pisos

La estructura que más se ve en equipos productivos en 2026:

Piso 1 — Framework de CI

DeepEval o Promptfoo (o Ragas si es RAG estricto) corriendo en cada PR.
Dataset golden versionado en el repo (~100-500 ejemplos curados).
Métricas con threshold: si baja G-Eval medio por debajo de 0.85, el merge falla.
Tiempo objetivo: <2 minutos para no bloquear el flow del desarrollador.

Piso 2 — Plataforma de regresión + drift

Langfuse / LangSmith / Phoenix / Braintrust persistiendo todos los traces de producción.
Evaluators corriendo sobre muestreo de tráfico real (eg 5-10% de las respuestas evaluadas con LLM-as-judge cada hora).
Dashboard semanal con tendencias por segmento, version de prompt, modelo.
Human labeling de los casos que el judge marca como dudosos.

Ciclo del cambio

Pipeline típico de cambiar un prompt:

Developer modifica el prompt en local.
CI corre eval framework contra dataset golden. Si pasa, merge.
El cambio sube a staging; la plataforma persiste evaluaciones de tráfico real durante 24-48h.
Si la regresión sale: rollback automático o flag.
Si pasa la ventana de staging: promoción a producción.
Eval continuo en producción detecta drift en días/semanas si ocurre.

Lo que cierra el bucle: el dataset golden se enriquece con los casos donde el sistema falló en producción. Cada incidente genera 3-5 ejemplos nuevos en el dataset; el dataset crece como entidad viva durante el ciclo de vida de la app.

Ejemplo concreto: pipeline RAG con DeepEval + Langfuse

Receta minimalista:

# CI: deepeval test (corre en cada PR)
# tests/test_rag.py
import pytest
from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric
from deepeval.dataset import EvaluationDataset
from app.rag import answer

dataset = EvaluationDataset()
dataset.add_test_cases_from_json_file(
 file_path="tests/golden_dataset.json",
 input_key_name="question",
 actual_output_key_name="ignore", # se rellena en runtime
 expected_output_key_name="expected_answer",
 context_key_name="ignore",
)

@pytest.mark.parametrize("tc", dataset.test_cases)
def test_rag_quality(tc):
 response, docs = answer(tc.input)
 tc.actual_output = response
 tc.retrieval_context = [d.content for d in docs]
 assert_test(tc, [
 FaithfulnessMetric(threshold=0.8),
 AnswerRelevancyMetric(threshold=0.75),
 ])

# Producción: tracing + eval async con Langfuse
# app/rag.py
from langfuse import observe, get_client
from langfuse.evaluators import faithfulness, answer_relevancy

langfuse = get_client()

@observe(as_type="generation")
def answer(question: str):
 docs = retrieve(question)
 resp = llm.generate(build_prompt(question, docs))
 # eval async en background sobre una muestra
 langfuse.evaluate_async(
 name="faithfulness",
 evaluator=faithfulness,
 input=question,
 output=resp,
 context=docs,
 sample_rate=0.1, # 10% del tráfico
 )
 return resp, docs

Y un dashboard Grafana o Langfuse UI muestra:

Faithfulness p50/p95 por día.
Distribución por namespace o tenant.
Drift respecto al baseline.
Casos peor evaluados para human review.

Cuatro horas de trabajo para tener esto montado en una app que ya tiene Langfuse desplegado. Cero excusas para no hacerlo.

La frontera 2026: lo que el campo aún no ha resuelto

Tres frentes abiertos donde la investigación va activa:

Outcome scoring sigue siendo el problema duro

Ya tenemos el step-level tracing: tool-call accuracy, trajectory analysis, latency per step, input/output por nodo. Te dice cómo se ejecutó el agente.

Lo que no está resuelto es outcome scoring: ¿completó el agente el objetivo en una forma que un experto del dominio aprobaría? Replay del trace no responde esta pregunta. Necesitas a alguien que sepa qué significa “éxito” en el contexto específico — y eso es caro y no escala.

Las propuestas actuales: usar judges fuertes (GPT-4 con CoT) sobre la respuesta final más contexto del trace, dataset de outcomes etiquetados por expertos como golden, ensembles de judges para alta varianza. Ninguna es magia.

Trajectory benchmarks emergentes

ATBench y TRAJECT-Bench representan la nueva ola de benchmarks que evalúan toda la trayectoria del agente, no solo input/output. Detectan safety issues durante la ejecución (usar tools peligrosos, exfiltrar datos en pasos intermedios) que un benchmark de final-answer pierde.

Si tu carga de producción tiene agentes haciendo varios tool calls, moviéndose a benchmarks trajectory-level durante 2026 es la dirección que el campo señala.

Pairwise vs absolute revisited

Hay debate activo. El argumento contra pairwise: no escala bien. Para evaluar N respuestas, pairwise requiere O(N²) comparaciones (todos contra todos) o N log N con torneo, ambos caros. Scoring absoluto es O(N).

La síntesis emergente: pairwise para gold-set y regresión (necesitas la mayor calidad), absolute con G-Eval para producción (escala mejor, asumiendo calibración adecuada). La elección no es ideológica; depende de la fase del pipeline.

Self-consistency y ensemble de judges

Para casos críticos: ejecutar el judge varias veces con temperature > 0 y agregar. Si los N judges coinciden, alta confianza; si discrepan, marca el caso para human review. Mejora robustez a costa de coste.

Variante más avanzada: jury of judges — tres judges distintos (GPT-4, Claude, un open-source) sobre la misma respuesta, agregación por mayoría. Estado del arte en agreement con humanos pero 3x más caro.

Trampas operativas

Golden dataset que envejece

Un golden set sin mantener empieza a divergir de la realidad: nuevos casos de uso aparecen, nuevos failure modes no están representados. Revisa y enriquece el golden cada quincena o mes, idealmente añadiendo los casos donde producción falló.

Judge contaminado

El judge sabe demasiado sobre el dataset (apareció en su entrenamiento). Las notas son artificialmente buenas. Especialmente serio si usas datasets públicos como golden. Mitigación: datasets privados curados internamente, rotación de modelos judge.

Sample size insuficiente

Con 10 ejemplos en el dataset, una métrica que baja de 0.85 a 0.75 puede ser ruido puro. Mínimo 50, ideal 200-500 para que las diferencias sean significativas. Reporta intervalos de confianza, no solo medias.

Costes que se descontrolan

Ejecutar G-Eval con GPT-4 sobre 5 000 respuestas/día son decenas de miles de tokens/día solo de evaluación que se pagan extra. Para escalas medianas, considera judge open-source (Prometheus) o sampling (5-10% del tráfico evaluado, no todo).

Olvidar el segmento

Una métrica media de 0.85 puede esconder que para el segmento “preguntas en alemán” es 0.55 y para “preguntas técnicas largas” es 0.65. Reporta siempre por segmento (idioma, dominio, tenant, tipo de pregunta). El “todo está bien” es sospechoso.

No actualizar la calibración

Los judges drift. Lo que medía 88% de agreement humano hace 3 meses puede haber bajado a 76% sin que nadie se entere. Recalibra cada 60-90 días contra el golden set humano.

Confiar en un eval para reemplazar humanos

Los evals automatizados son complemento del juicio humano, no sustituto total. Para casos de alto stake (legal, médico, financiero) o nuevos releases mayores, muestreo humano sigue siendo necesario. La proporción razonable: 95% automatizado, 5% humano en muestreo estratificado.

Lo que no hemos cubierto (próximos posts)

Guardrails y safety: el siguiente post de la serie. Cómo prevenir que prompts malos lleguen al modelo, en lugar de evaluar respuestas a posteriori.
MCP observability profunda: cómo OpenTelemetry GenAI se extiende a MCP servers para que las tools también sean trace-aware.
eBPF + on-device inference + drift detection: el cierre.

Referencias

Frameworks y plataformas:

DeepEval — Apache 2.0, pytest-style.
Promptfoo — MIT, CLI + YAML, red teaming.
Ragas — Apache 2.0, RAG-specific.
OpenAI Evals — MIT, clásico.
Inspect AI — UK AI Safety Institute.
Langfuse — MIT, self-host, suite completa.
LangSmith — LangChain team.
Arize Phoenix — ELv2, OTel-native.
Braintrust — comercial + OSS lite.

Métodos y papers:

G-Eval (Liu et al., 2023) — el patrón de prompting dominante.
Prometheus (KAIST + LG AI) — judge open-source con 0.897 correlación.
Tau-bench (Sierra, 2024) — tool-agent-user benchmark con pass^k.
ATBench (2026) — trajectory safety benchmark.
TRAJECT-Bench (2026) — trajectory-aware agentic tool use.
Survey on Evaluation of LLM-based Agents — el survey de referencia.

Comparativas 2026:

Cross-references:

Serie eBPF: eBPF de cero a Cilium, Tetragon, Hubble, AgentSight y tracing LLM.
Serie de inferencia: KV cache, vLLM en K8s, PagedAttention, Operators LLM K8s.

AgentSight y el nuevo tracing de LLMs: zero-instrumentation con eBPF frente a Langfuse, LangSmith, Phoenix y compañía

Tue, 19 May 2026 18:00:00 +0200

TL;DR

Observar un agente de LLM en producción en 2026 se divide en dos enfoques con filosofías opuestas. El instrumentado, dominante hasta 2025, vive en herramientas como Langfuse, LangSmith, Arize Phoenix, Helicone, OpenLLMetry/Traceloop o Pydantic Logfire: instalas un SDK, decoras tus llamadas, emites spans con la convención OpenTelemetry GenAI (gen_ai.request.model, gen_ai.usage.input_tokens, etc.) y los exportas a un backend. Profundidad altísima cuando controlas el código; cero visibilidad cuando el agente es un binario opaco que ejecutas sin instrumentar. El zero-instrumentation, que AgentSight ha popularizado en la segunda mitad de 2025, gira la perspectiva 180º: pone hooks eBPF en las uprobes de las bibliotecas SSL/TLS y captura el plaintext de cada petición HTTPS antes del cifrado, sin tocar el código de la app, con menos del 3% de overhead y la garantía de ser tamper-proof (el agente no puede falsificar lo que se ve en el kernel). Combinado con captura BPF de stdio para servidores MCP locales, AgentSight te da observabilidad completa de cualquier agente —incluyendo binarios cerrados como Claude Code, Gemini CLI o Cursor— en un cluster Kubernetes. Las dos familias no son enemigas: la pila de referencia 2026 combina ambas (instrumented para apps propias con LangChain, eBPF para binarios opacos y compliance de tamper-proof) sobre OpenTelemetry GenAI semantic conventions como vocabulario común que el ecosistema está estabilizando este año.

Este es el cuarto y último post de la serie sobre eBPF. Parte 1: eBPF de cero a Cilium. Parte 2: Tetragon: seguridad de runtime. Parte 3: Hubble: observabilidad de red. Aquí cerramos el círculo con la dimensión semántica —qué hace un agente IA, no solo qué red abre o qué syscalls emite—.

La analogía: APM tradicional vs sniffer de red

Quien haya operado aplicaciones empresariales conoce las dos tribus del monitoring. La tribu APM (New Relic, AppDynamics, Datadog APM): instalas un agente o un SDK en cada aplicación, marcas spans, recoges traces con profundidad enorme dentro de cada proceso —líneas de código, queries SQL, métodos de Java—. La tribu wire-level (sniffers de red, herramientas tipo SolarWinds NPM, NetFlow): no toca la aplicación; observa el cable, ve protocolos, latencias, retransmisiones, identifica problemas que la app no sabe que tiene.

Cada una ve cosas distintas y las dos sirven. Quien ha vivido un incidente serio donde APM decía “todo verde” mientras los usuarios sufrían sabe que el wire-level habría detectado el problema (un middlebox saturado, un MTU mal configurado, un timeout de TCP). Quien ha intentado debuggear un memory leak con sniffers sabe que sin APM era imposible.

La observabilidad de agentes LLM en 2026 está exactamente en este punto. El APM-style lleva un par de años montado: Langfuse, LangSmith, Phoenix, OpenLLMetry. Profundidad enorme, requiere instrumentar la app. El wire-level con eBPF acaba de llegar: AgentSight es el primer proyecto que lo lleva a productivo. Profundidad menor en el interior del agente, pero ve cualquier agente sin tocar nada y es tamper-proof. Los dos sirven. La industria está en plena coexistencia.

Por qué observar agentes LLM es distinto

Antes de entrar en herramientas, vale la pena detenerse en qué hace específicos a los agentes LLM como sujetos de observabilidad:

No-determinismo. El mismo input puede producir outputs distintos. Reproducir un incidente requiere capturar exactamente la conversación, el modelo, los parámetros y, idealmente, la seed. Una métrica agregada “latencia p95” se queda corta; lo que necesitas es replay de la traza individual.

Cadena de invocaciones externas. Un agente típico llama LLM → herramientas (tool calling) → MCP servers → otras APIs → vuelta a LLM. Una sesión de chat puede generar decenas de llamadas encadenadas que hay que correlar por trace_id para entender la decisión.

Coste lineal en tokens. Cada llamada se paga en tokens. Sin trazar input/output tokens por petición, no puedes asignar coste a tenant ni equipo, ni detectar bucles que se comen tu presupuesto en una hora.

Riesgo semántico. Prompt injection (un user input que contiene instrucciones para manipular al modelo), jailbreaks, leakage de secretos via tool calls. Es un tipo de problema que no aparece en aplicaciones tradicionales y la observabilidad debe verlo.

Binarios opacos. En 2026, muchos equipos despliegan agentes de terceros —Claude Code, Cursor agent, Aider, Gemini CLI, Codex CLI— como herramientas internas. No son aplicaciones propias; son binarios cerrados que llaman a la API del vendor. Instrumentarlos es imposible. Observarlos requiere otra cosa.

Multi-agent y orquestación. Cada vez más arquitecturas tienen agentes que invocan a otros agentes (planner → executor → critic). La observabilidad debe entender la topología, no solo el span individual.

Con estos cinco puntos en mente, las herramientas que vamos a ver se diferencian principalmente en qué partes del problema cubren bien y qué partes dejan ciegas.

El enfoque instrumentado: cómo funciona

El modelo es directo y conocido:

Tu código llama al LLM o a herramientas usando una librería oficial: openai, anthropic, langchain, llama_index, dspy.
Instalas un SDK del tracer (Langfuse, LangSmith, OpenLLMetry, Logfire) que wrappea o monkey-patcha esas librerías.
Cada llamada emite un span OpenTelemetry con atributos estandarizados: modelo usado, tokens input/output, latencia, parámetros, mensajes, herramienta invocada, resultado.
Los spans se exportan vía OTLP a un backend que los muestra como un árbol de traces.

# Ejemplo típico con OpenLLMetry + cualquier SDK
from traceloop.sdk import Traceloop
from openai import OpenAI

Traceloop.init(app_name="my-agent", api_endpoint="https://otel-collector:4318")

client = OpenAI()
# este call emite automáticamente un span con
# gen_ai.request.model, gen_ai.usage.input_tokens, etc.
resp = client.chat.completions.create(
 model="gpt-4.1",
 messages=[{"role": "user", "content": "..."}]
)

Lo que ves después: un dashboard con cada conversación como un trace, cada llamada como un span, los prompts y completions completos (si optas in), el coste calculado, latencias por span, errores marcados.

OpenTelemetry GenAI semantic conventions: el vocabulario común

La fragmentación del campo se está mitigando con OpenTelemetry GenAI Semantic Conventions. Es el esfuerzo de la CNCF para que todas las herramientas emitan spans con los mismos nombres de atributos:

gen_ai.system — el proveedor (openai, anthropic, vertex_ai, etc.).
gen_ai.request.model — modelo solicitado (gpt-4.1, claude-3-5-sonnet).
gen_ai.response.model — modelo realmente usado (a veces difiere, eg fallbacks).
gen_ai.usage.input_tokens y gen_ai.usage.output_tokens — contadores.
gen_ai.request.temperature, gen_ai.request.top_p, etc. — parámetros.
gen_ai.response.finish_reasons — por qué terminó (stop, length, content_filter).
gen_ai.operation.name — el tipo de operación (chat, embedding, completion).

A principios de 2026, los client spans salieron de experimental a estable. El resto (server spans, multi-agent events) sigue en desarrollo. El significado operacional: si tu SDK emite estos atributos, cualquier backend que entienda OTel GenAI puede consumirlos. Cambiar de Langfuse a Phoenix a Helicone no implica re-instrumentar, solo cambiar el exporter.

La SIG está activamente desarrollando conventions for multi-agent systems: agent teams, tasks, actions, memory, artifact tracking. Esto es lo que falta para que las arquitecturas de agentes complejas tengan vocabulario común. En 2026 está experimental; se espera estabilización a finales de año o principios de 2027.

Herramientas instrumentadas: el panorama 2026

Herramienta	Licencia	Self-host	Foco	Donde brilla
Langfuse	MIT	Sí	LLM observability + evals + prompt mgmt	Mejor balance OSS, suite completa
LangSmith	Comercial	No	LangChain/LangGraph nativo	Si usas LangChain, integración cero-config
Arize Phoenix	ELv2 (OSS)	Sí	OTel-native, RAG fuerte	Vector DBs, retrieval, embeddings
Helicone	Comercial + OSS lite	Sí (lite)	Proxy simple	Setup minutos, OpenAI-only
OpenLLMetry / Traceloop	Apache 2.0	Sí	SDK OTel para LLMs	Vendor-neutral, exporta a cualquier OTel backend
Pydantic Logfire	Comercial	No	App + LLM unificado	Si usas Pydantic AI, integración nativa
Weights & Biases Weave	Comercial	Limitado	Experimentación + producción	Si ya usas W&B para training
Laminar / Braintrust	Comercial	No / Sí	Evals + tracing	Más recientes, foco en evaluación

Deep dive: Langfuse

Merece detenerse en Langfuse porque es, en 2026, la elección por defecto entre las opciones open-source y la que más equipos han adoptado este año. Es proyecto de YC W23, licencia MIT, y lleva un ritmo de release sostenido con cambios arquitectónicos serios entre versiones.

Cuatro pilares declarados: observability (tracing), evaluations, prompt management, playground/datasets. Cada uno por separado tiene productos comerciales completos detrás; Langfuse los integra en una sola plataforma con un solo backend.

El SDK v4: OTEL-native, no un sustituto

El gran cambio operacional reciente es el SDK v4, una capa fina sobre el cliente oficial de OpenTelemetry. La elección es deliberada: en lugar de mantener un cliente propio que se atrase respecto a las primitives OTel, Langfuse usa el SDK estándar y enriquece los spans con atributos y helpers específicos para LLM. La consecuencia: cualquier código que ya esté instrumentado con OpenTelemetry vainilla (@opentelemetry/sdk-node, opentelemetry-sdk en Python) puede exportar a Langfuse sin cambios mayores, y al revés, si mañana quieres migrar de Langfuse a otro backend OTel, los spans son portables.

En Python el decorador idiomático es @observe:

from langfuse import observe, get_client

langfuse = get_client()

@observe()
def buscar_documentos(query: str):
 # cualquier llamada interna también se traza
 return vector_store.similarity_search(query)

@observe(as_type="generation")
def llamar_llm(prompt: str):
 # marcada como "generation" para que aparezca con metadata LLM
 return openai_client.chat.completions.create(...)

@observe()
def pipeline_rag(pregunta: str):
 docs = buscar_documentos(pregunta)
 return llamar_llm(build_prompt(pregunta, docs))

El árbol de llamadas se captura automáticamente: la traza muestra pipeline_rag como root span, con buscar_documentos y llamar_llm como hijos, anidados. Sin escribir un solo with tracer.start_as_current_span(...) a mano.

En TypeScript el equivalente es modular: instalas @langfuse/tracing, @langfuse/otel y @opentelemetry/sdk-node, y puedes usar decoradores TS, context managers o spans manuales —los tres modelos interoperan—. La consecuencia: bibliotecas terceras que emiten spans OTel (openai, @anthropic-ai/sdk, instrumentaciones de Vercel AI SDK) se ven en Langfuse sin trabajo adicional.

Arquitectura self-host: pensada para producción seria

La arquitectura del backend Langfuse tiene dos decisiones explícitas que distinguen su despliegue self-host:

Persistencia primero en S3/Blob Storage. Cuando un evento de tracing entra, se persiste en object storage antes de tocar la base de datos. Solo cuando el procesado posterior confirma OK se inserta en Postgres/Clickhouse. Si la DB cae temporalmente, los eventos no se pierden; quedan en S3 esperando reproceso. Para producción donde perder traces de un incidente equivale a perder evidencia, esto es load-bearing.
Migraciones largas como background jobs. Los upgrades de schema que en otras plataformas implican ventana de downtime, en Langfuse se ejecutan en background mientras la aplicación sigue sirviendo. El downtime de upgrade se reduce drásticamente.

Los modos de despliegue soportados oficialmente:

Docker Compose: para desarrollo y POCs. Un comando, todo arriba.
VM: un único nodo, contenedores, sin orquestación. Para entornos pequeños.
Kubernetes con Helm: el modo recomendado para producción. Chart oficial mantenido. Soporta external Postgres, external Clickhouse, external S3, HPA.

Las dependencias externas en producción típica: Postgres (metadata, prompts, configuración), Clickhouse (eventos de tracing, queries de alta cardinalidad), S3 o blob compatible (eventos pendientes), Redis (cola entre componentes). Sí, son varias piezas; es lo que sostiene la durabilidad y la escala.

Prompt management como ciudadano de primera clase

Lo que diferencia a Langfuse de las plataformas centradas solo en tracing es que los prompts viven en Langfuse, no en el repo de la aplicación o en hojas de cálculo. Cada prompt tiene:

Nombre y versión (v1, v2, v3…). Cambiar el prompt no requiere redeploy de la app: la app pide el prompt al SDK, que lo cachea y refresca cuando hay versión nueva.
Variables tipadas: {{user_input}}, {{context}}. Render con validación.
Tags y labels: por entorno (production, staging), por equipo, por experimento.
Cache cliente y servidor: el SDK cachea localmente con TTL configurable, evita roundtrip a Langfuse en cada llamada.
Linkage con traces: cada trace recoge qué versión exacta de qué prompt se usó. Investigar “esta respuesta salió mal” lleva al prompt versión Y, no a “alguna versión del prompt en algún momento”.

from langfuse import get_client

langfuse = get_client()

prompt = langfuse.get_prompt("rag-system-prompt", version=3)
# o por label: langfuse.get_prompt("rag-system-prompt", label="production")

compiled = prompt.compile(context=docs_text, user_input=question)
# 'compiled' es el string final, listo para mandar al LLM

Para equipos que iteran sobre prompts a diario, esto es lo que evita el caos de “qué versión del prompt está corriendo realmente en producción ahora mismo”.

Evaluations: cuatro modelos de evaluación combinables

Langfuse cubre los cuatro patrones de evaluación de respuestas:

LLM-as-a-judge: configuras un modelo (típicamente GPT-4 o Claude) con una rúbrica y evalúa cada respuesta. Resultado: score numérico (0-1) y justificación. Aplicable a tracing automático (todas las respuestas) o batch (selección de dataset).
User feedback: la app permite al usuario marcar respuesta como buena/mala. El feedback se asocia al trace y al prompt version, lo que permite ver qué versiones tienen peor rate.
Manual labeling: una UI donde labelers humanos puntúan respuestas. Útil para datasets dorados y para evaluar el judge.
Custom evaluators vía API/SDK: evals propios (un test unitario, una métrica de negocio) reportan score vía API. Se integran con CI.

Combinadas, dan regression testing del prompt: cambias de v3 a v4, evalúas el dataset dorado con LLM-as-judge, comparas; si v4 empeora en alguno de los segmentos, el merge falla.

Integraciones

Langfuse no compite con OpenLLMetry, LangChain o LiteLLM: los integra. Las que están testeadas y documentadas:

OpenTelemetry: cualquier instrumentación OTel emite a Langfuse vía OTLP.
LangChain y LangGraph: callback nativo que captura toda la cadena.
LlamaIndex: callback nativo.
OpenAI SDK (Python y TS): wrapper que añade tracing automáticamente.
LiteLLM: integración como callback, lo que cubre 100+ proveedores via LiteLLM.
OpenLLMetry / Traceloop: emiten a Langfuse como cualquier backend OTel.
MLflow: vía exporter OTel desde MLflow a Langfuse.
Vercel AI SDK: instrumentación nativa.

La estrategia es clara: Langfuse es backend, no SDK. Tu equipo elige cómo instrumenta; Langfuse acepta cualquier camino. La consecuencia operativa: cambiar de Langfuse a otro backend OTel mañana es viable.

Cuándo Langfuse no es la respuesta

Para no presentarlo como bala de plata:

Si solo usas LangChain y no tienes recursos para self-host: LangSmith te dará integración más fluida (es el mismo equipo).
Si tu única necesidad es proxy con cost tracking sin evals: Helicone es más simple.
Si quieres una solución vendor commercial integrada: Datadog LLM Observability, New Relic AI Monitoring o Dynatrace AI son alternativas Enterprise con soporte 24/7.
Si tu carga es batch puro de inferencia masiva sin agentes: probablemente no necesitas tracing semántico; Prometheus + Grafana con métricas OTel basta.

Para todo lo demás —apps propias con tracing serio, multi-tenant con cuotas, equipos que iteran prompts a diario, RAG con evaluación continua—, Langfuse es la apuesta segura.

Resumen de elección rápido:

LangChain → LangSmith (cero esfuerzo, instrumentación automática).
Aplicaciones propias multi-framework con OSS → Langfuse (MIT, self-host, completo).
RAG con vector stores → Arize Phoenix (mejor visibilidad de retrieval).
Proxy simple, presupuesto bajo → Helicone.
Vendor neutrality estricta → OpenLLMetry/Traceloop.
Pydantic AI → Logfire (mismo equipo).

Fortalezas y debilidades del modelo instrumentado

Fortalezas:

Profundidad enorme: spans anidados con todo el contexto (chain steps, retrieval, embeddings, tool calls).
Vocabulario semántico: SDK conoce el dominio (LLM, vector store, agent).
Madurez: tres años de evolución, ecosistema rico, dashboards listos.
Evals integradas: las plataformas top combinan tracing con evaluación (judge LLM, datasets, regression).

Debilidades:

Requiere control del código: si no puedes instrumentar, no funciona.
Trust en la app: si la app reporta mal o tiene un bug, la traza también. No es tamper-proof.
Acoplamiento al SDK: cambios de versión de una librería pueden romper la instrumentación.
Cobertura desigual: SDKs de Python están maduros; Go, Rust, JS más jóvenes.

El enfoque zero-instrumentation: AgentSight

AgentSight es el proyecto del grupo eunomia-bpf que abandera el enfoque opuesto. Su paper en arxiv (2508.02736), presentado en el Workshop on Practical Adoption Challenges of ML for Systems, formaliza la propuesta. La premisa es directa:

Instead of instrumenting the agent, observe it at the system boundary.

Y “system boundary” significa el límite del kernel: el último punto antes de que un dato salga del proceso hacia la red o el filesystem. Ahí, con eBPF, se ven las cosas tal como son, sin que la aplicación pueda cooperar para esconderlas.

Arquitectura: tres planos

AgentSight monta tres capas:

Plano 1 — SSL/TLS uprobes. eBPF puede atar programas a funciones de bibliotecas userspace (uprobes). Las funciones objetivo son las de cifrado: SSL_write, SSL_read de OpenSSL/BoringSSL, equivalentes en Rustls. AgentSight les pone hooks que capturan los argumentos: el buffer plaintext que la app pasa para que sea cifrado, justo antes de que TLS lo procese. En la recepción, hace lo simétrico: hook después de SSL_read con el plaintext recién descifrado. Resultado: AgentSight ve el contenido completo de cualquier petición HTTPS que la app haga sin necesidad de man-in-the-middle ni certificados ni descifrar tráfico. El payload es plaintext porque se capturó antes de cifrarse.

Esto funciona porque las uprobes son baratas (~100 ns por invocación) y porque las apps usan bibliotecas de TLS comunes. Las pocas apps que implementan su propio TLS (raras en producción) escapan a este hook; para esas hace falta un kprobe diferente o instrumentación manual.

Plano 2 — Kernel events. Paralelamente, AgentSight observa syscalls relevantes a través de tracepoints: execve (qué procesos arrancan), connect/accept (red), read/write con file descriptors (filesystem y stdio), unlink, clone. Cualquier acción del agente que tenga efecto fuera del proceso pasa por aquí. Esto cubre, entre otros, comandos shell ejecutados por el agente —si un agente Claude Code decide ejecutar rm -rf para “limpiar el proyecto”, el execve se ve aunque la API LLM no lo reporte—.

Plano 3 — Correlation engine. Los dos planos anteriores producen streams de eventos asíncronos. AgentSight tiene un componente en userspace que los correlaciona causalmente cross-process: una petición HTTP saliente con bash -c rm -rf puede ser correlada con la respuesta LLM previa que la sugirió, vía PIDs, tiempos y heurísticas. El paper menciona el uso opcional de un LLM secundario (Anthropic Claude por ejemplo) que analiza la secuencia de eventos y produce alertas semánticas: “el agente respondió con una tool call que no estaba en la whitelist”, “la cadena de reasoning lleva 47 iteraciones sin converger”.

`stdiocap`: capturar stdio de servidores MCP locales

Una pieza específica que merece mención propia es stdiocap, una herramienta BPF separada incluida en el repo. El Model Context Protocol (MCP), popularizado por Anthropic en 2024 y mainstream en 2025-2026, tiene dos modos de transport: HTTP/SSE (red) y stdio (entre el cliente y el server que arranca como subproceso). Los servidores MCP locales —los que corren en la misma máquina y son arrancados por el cliente como hijos vía pipes— comunican por stdin/stdout/stderr con JSON-RPC.

stdiocap engancha read/write/dup sobre los file descriptors de stdin/stdout/stderr de un proceso target y registra todo el tráfico JSON-RPC entre cliente y server MCP. Es la misma idea que la captura SSL pero para stdio: observas la conversación sin que ni el cliente ni el server lo sepan. Caso de uso típico: ver qué tools del MCP server filesystem-mcp ha invocado un agente Claude Code en la última hora, qué argumentos pasó, qué errores recibió. Imposible con instrumentación clásica (los servers MCP suelen ser binarios de terceros).

Garantías: tamper-proof, kernel safety, <3% overhead

Tres propiedades hacen a AgentSight interesante para producción:

Tamper-proof: la observación ocurre en el kernel (uprobes, syscalls). Una aplicación maliciosa o comprometida no puede falsificar lo que se ve. Comparar con instrumentación: si el agente decide no emitir el span de su acción, no aparece en Langfuse. Aquí no tiene elección.
Kernel safety: eBPF verifica formalmente que los programas terminen y respeten bounds checks. No puede crashear el kernel. Igual que en el resto de la serie eBPF.
<3% CPU overhead medido sobre cargas reales de agentes (paper). El número compara favorablemente con instrumentación SDK que típicamente añade 5-10% en aplicaciones intensas.

Lo que detecta out of the box

El paper y la documentación destacan tres clases de detección:

Prompt injection en tiempo real: el correlation engine puede aplicar reglas o un modelo de detección sobre el plaintext capturado por las uprobes SSL. Si el prompt contiene patrones sospechosos —“ignore all previous instructions”, system prompt embebido en un user input, instrucciones para exfiltrar datos—, marca alerta.
Reasoning loops que gastan recursos: agentes que entran en bucles infinitos llamando a herramientas sin progresar. Detectables porque la cadena causal no converge a “respuesta final” y los tokens se acumulan. El correlation engine los marca.
Bottlenecks en multi-agent: cuando varios agentes coordinan, AgentSight ve la matriz de comunicaciones entre todos y puede detectar agentes que se bloquean esperando, deadlocks, fan-out excesivo.

El choque y la coexistencia

Las dos familias parecen competir, pero en realidad ven cosas distintas y se complementan en producción.

Lo que solo el instrumentado ve

Variables internas del agente que no salen al cable: el estado intermedio de un chain LangChain, los valores antes de pasarlos a una herramienta, el cómo se construye un prompt a partir de un template con vars internos.
Spans semánticos profundos: retrieval > embed > vector_search > rerank > format_context > prompt_template > llm. AgentSight ve solo la llamada final al LLM; el camino para construirla es invisible.
Evaluaciones: scoring de respuestas, judge LLMs, regresión de calidad. Esto vive solo en plataformas instrumentadas.

Lo que solo eBPF ve

Binarios opacos: Claude Code, Cursor, Gemini CLI, agentes de terceros. No tienes el código; no puedes instrumentarlos. Solo eBPF los ve.
Acciones a nivel sistema: el agente decide ejecutar git push --force o kubectl delete. La acción se ve en el execve. La instrumentación del agente puede no reportarla (especialmente si fue un comando que el agente generó como output sin pasar por una “tool” explícita).
Tamper-proof audit: para compliance regulatorio (HIPAA, SOC2, NIS2), tener observación que la app no puede burlar tiene valor formal. eBPF lo da.
MCP servers locales con stdio: invisibles para instrumentación clásica salvo que cada server emita sus propios spans (raro).

Lo que ambos ven, complementariamente

Prompts y completions: instrumentado los emite con metadata rica; eBPF los captura del cable. Cross-check perfecto para detectar discrepancias.
Llamadas a APIs externas: APM lo marca; eBPF lo confirma a nivel kernel.
Latencia: APM por span; eBPF mide RTT a nivel TCP y conectividad red.

Matriz de decisión

Caso	Instrumentado	eBPF (AgentSight)
App propia con LangChain	Sí, primero	Opcional
App propia multi-framework	Sí	Opcional
Binario de terceros (Claude Code, Cursor)	No funciona	Sí, único camino
Cumplimiento normativo tamper-proof	Insuficiente	Sí, requerido
Multi-tenant zero-trust	Insuficiente	Sí, requerido
Servidores MCP locales (stdio)	Difícil	Sí, con stdiocap
Evaluación de calidad de respuestas	Sí, requerido	No (fuera de scope)
Profundidad de chain interno	Sí, requerido	No (caja negra para AgentSight)
Reasoning loop detection	Posible con plumbing	Sí, integrado
Prompt injection en tiempo real	Posible (post-procesado)	Sí, en stream

La conclusión natural: para apps propias, instrumentado; para binarios opacos o compliance, eBPF; para todo lo importante, ambos.

Arquitectura de referencia 2026

Cuatro recetas que cubren el grueso de los casos reales:

Setup A — Aplicación propia con LangChain o similar

Necesidades: profundidad, evals, equipo cómodo con SDKs.

Langfuse self-host o LangSmith cloud como backend.
OpenLLMetry SDK o LangSmith SDK instrumentando el código.
OpenTelemetry Collector entre la app y el backend para flexibilidad de routing (a Langfuse + Tempo + Loki por ejemplo).
Hubble para la capa de red en el cluster (latencia inter-pod, drop attribution).

Setup B — Productivizar un binario opaco (Claude Code, Gemini CLI)

Necesidades: observar sin tocar, auditar, controlar coste.

AgentSight desplegado como DaemonSet sobre el cluster (o standalone en el nodo).
Grafana con dashboards alimentados por las métricas de AgentSight.
Exportador OTLP de AgentSight a un backend OTel (Tempo, Jaeger). Los spans usarán las semantic conventions GenAI cuando se estandaricen del todo.
Tetragon opcional para política sobre qué puede ejecutar el agente (Sigkill si intenta rm -rf o similar).

Setup C — Plataforma multi-tenant zero-trust

Necesidades: agentes de distintos clientes corriendo en el mismo cluster, auditoría obligatoria, ninguno confía en el otro.

AgentSight como capa de auditoría tamper-proof. Compliance lo requiere.
Langfuse multi-tenant para los clientes que sí instrumentan.
Tetragon con TracingPolicyNamespaced por tenant (políticas distintas por namespace).
Hubble con flow logs persistentes para forensics.
Cilium NetworkPolicy para aislar tenants entre sí en red.

Setup D — Servidor MCP local en una workstation

Necesidades: ver qué hace un agente con un MCP server stdio.

AgentSight stdiocap apuntando al PID del cliente o del server.
Captura JSON-RPC completo a fichero o a un endpoint OTLP.
Visualización: Grafana o simplemente jq sobre el log.

Caso de uso real: si estás integrando un MCP server propio y quieres ver qué tool calls hace un agente Claude Code o Cursor a tu server, stdiocap es la forma más limpia. No necesitas modificar ni cliente ni server.

Trampas operativas

Datos sensibles en prompts (instrumentado)

Por defecto, Langfuse, LangSmith y similares capturan el contenido completo de prompts y completions. Si tu app procesa PII, secretos, datos médicos, eso va a tu backend de observabilidad. Configurar redacción o content-opt-out antes de pasar a producción es obligado. OTel GenAI tiene flags específicos (OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=false) para evitarlo.

Datos sensibles en prompts (AgentSight)

Mismo problema, peor: AgentSight captura literalmente lo que va al cable, plaintext. Si el agente conversó con api.openai.com con un prompt que contenía datos sensibles, AgentSight tiene ese plaintext. Hay que cifrar o redactar antes de almacenar.

Certificados pinned o TLS no estándar

Algunas apps de seguridad alta hacen certificate pinning o usan implementaciones de TLS no convencionales (Go’s crypto/tls, BoringSSL custom). En esos casos, las uprobes a libssl no las cubren. AgentSight detecta cuándo no puede observar y reporta gap; igual hay que añadir hooks específicos al SDK alternativo.

Volumen de tokens y storage

Una aplicación con tráfico medio puede generar millones de tokens al día. Si los almacenas todos en Langfuse o Phoenix con retención largos, la base de datos crece deprisa. Estrategias: sampling agresivo, retención corta para sesiones normales y larga solo para errores/anomalías, redaction de contenido y guardar solo metadata.

Tracing con sampling y consistencia

Para reducir coste, muchas instalaciones samplean: solo 1 de cada N traces se persiste. Cuidado con el sampling no consistente: un trace puede llevar varios spans en múltiples servicios, y si la decisión de samplear se toma per-span, acabas con traces incompletos. OTel tiene head sampling (en el SDK al principio) que es consistente, y tail sampling (en el collector al final) que permite reglas más finas. Para LLM, el tail sampling es ideal: muestrea todo, descarta solo las traces “normales” y conserva las que tienen errores, latencia alta o cost alto.

Multi-agent y trace propagation

Cuando agente A llama a agente B, hay que propagar el trace context (W3C Trace Context headers) para que se vea como un árbol único. Si no lo haces, ves dos traces inconexos. Las plataformas modernas lo hacen automáticamente con inject/extract, pero si tu transport entre agentes es custom (vía Redis pub/sub, vía DB), tienes que propagar a mano.

Coste de las uprobes en bibliotecas críticas

Hookear libssl añade ~100 ns por invocación. En cargas de tráfico TLS extremo (decenas de miles de conexiones/s por core), eso suma. AgentSight lo mantiene por debajo de 3% en cargas típicas de agentes (que son chatty pero no networking-intensive). Si tu uso fuese sniffing de todo el HTTPS del nodo, podría doler más.

Lo que no hemos cubierto (próxima serie)

Evals: la siguiente capa después de tracing. Phoenix, Langfuse, LangSmith y compañía ofrecen evaluación de respuestas (judge LLM, datasets, regression). Es un mundo aparte.
Guardrails y safety: NeMo Guardrails, Llama Guard, Llama Prompt Guard, evaluadores específicos para prompt injection y jailbreaks.
MCP server observability profunda: cómo OpenTelemetry GenAI conventions están extendiéndose a MCP servers para trace-aware tools.
eBPF + on-device inference: cuando el LLM corre localmente vía vLLM o llama.cpp, las uprobes pueden ver la cola tokens-output ANTES de que vayan al cliente. Territorio nuevo.
Análisis estadístico de flows de agentes: detectar drift, outliers, patrones que indican degradación.

Cerrando la serie eBPF

Esta serie de cuatro artículos ha recorrido eBPF desde el primer principio hasta la frontera 2026:

eBPF de cero a Cilium — qué es eBPF, hooks de networking, cómo Cilium se salta la pila TCP/IP, BGP Control Plane v2.
Tetragon: seguridad de runtime — observabilidad y enforcement de procesos en el kernel.
Hubble: observabilidad de red — flow logs L3-L7 y la frontera con los agentes IA.
Este — AgentSight, tracing de LLMs, instrumentado vs zero-instrumentation.

Si has llegado hasta aquí tienes el mapa para sentarte con un equipo de plataforma, de seguridad o de IA en 2026 y reconocer qué hace cada pieza, qué problema resuelve y por dónde empezar. Toda esa pila —Cilium para CNI y BGP, Tetragon para seguridad de runtime, Hubble para observabilidad de red, AgentSight para agentes IA— compartiendo eBPF como sustrato común, gobernanza Cloud Native y vocabulario OpenTelemetry. Es la arquitectura limpia que la industria pidió hace una década y por fin existe.

Referencias

AgentSight:

AgentSight GitHub (eunomia-bpf) — el proyecto.
AgentSight: System-Level Observability for AI Agents Using eBPF (arxiv 2508.02736) — paper formal.
AgentSight ACM workshop publication.
AgentSight blog post (eunomia.dev) — descripción accesible.

OpenTelemetry GenAI semantic conventions:

Plataformas instrumentadas:

Langfuse — MIT, self-host + cloud.
LangSmith — LangChain team.
Arize Phoenix — OSS, OTel-native.
Helicone — proxy simple.
OpenLLMetry (Traceloop) — Apache 2.0, SDK OTel.
Pydantic Logfire — AI observability.

Comparativas 2026:

Cross-references de la serie:

eBPF de cero a Cilium.
Tetragon: seguridad de runtime.
Hubble: observabilidad de red.
Serie de inferencia LLM: KV cache, vLLM en Kubernetes, PagedAttention, Operators LLM K8s.

Langfuse on lo0 — Blog Técnico

Evals: la capa después del tracing que decide si tu LLM rinde o sólo parece rendir

TL;DR

La analogía: el test suite que tu pipeline de ML siempre quiso

Por qué evaluar LLMs es estructuralmente distinto

Las cuatro patas de un sistema de evals

1. Datasets

2. Evaluators

3. Runners

4. Storage y analytics

LLM-as-a-judge: el caballo de batalla

El modelo básico

Scoring rubric vs pairwise comparison

G-Eval: el patrón que más se usa

Calibración contra humanos: el paso no negociable

Los sesgos del judge: lo que pega tiros en producción

Coste y judges open-source

Métricas específicas para RAG

Faithfulness (fidelidad)

Answer Relevancy (relevancia de la respuesta)

Context Precision (precisión del contexto)

Context Recall (recall del contexto)

El cuadrante diagnóstico de RAG

Métricas específicas para agentes

Tool selection accuracy

Trajectory matching

Task completion rate

pass^k: la métrica que cambió las leaderboards

Benchmarks 2026 importantes

El panorama de herramientas 2026

Categoría A: testing frameworks (gating en CI)

Categoría B: plataformas (storage + dashboard + regresión)

Tabla comparativa: testing frameworks vs platforms

La receta operativa: stack de dos pisos

Piso 1 — Framework de CI

Piso 2 — Plataforma de regresión + drift

Ciclo del cambio

Ejemplo concreto: pipeline RAG con DeepEval + Langfuse

La frontera 2026: lo que el campo aún no ha resuelto

Outcome scoring sigue siendo el problema duro

Trajectory benchmarks emergentes

Pairwise vs absolute revisited

Self-consistency y ensemble de judges

Trampas operativas

Golden dataset que envejece

Judge contaminado

Sample size insuficiente

Costes que se descontrolan

Olvidar el segmento

No actualizar la calibración

Confiar en un eval para reemplazar humanos

Lo que no hemos cubierto (próximos posts)

Referencias

AgentSight y el nuevo tracing de LLMs: zero-instrumentation con eBPF frente a Langfuse, LangSmith, Phoenix y compañía

TL;DR

La analogía: APM tradicional vs sniffer de red

Por qué observar agentes LLM es distinto

El enfoque instrumentado: cómo funciona

OpenTelemetry GenAI semantic conventions: el vocabulario común

Herramientas instrumentadas: el panorama 2026

Deep dive: Langfuse

El SDK v4: OTEL-native, no un sustituto

Arquitectura self-host: pensada para producción seria

Prompt management como ciudadano de primera clase

Evaluations: cuatro modelos de evaluación combinables

Integraciones

Cuándo Langfuse no es la respuesta

Fortalezas y debilidades del modelo instrumentado

El enfoque zero-instrumentation: AgentSight

Arquitectura: tres planos

stdiocap: capturar stdio de servidores MCP locales

Garantías: tamper-proof, kernel safety, <3% overhead

Lo que detecta out of the box

El choque y la coexistencia

Lo que solo el instrumentado ve

Lo que solo eBPF ve

Lo que ambos ven, complementariamente

Matriz de decisión

Arquitectura de referencia 2026

Setup A — Aplicación propia con LangChain o similar

`stdiocap`: capturar stdio de servidores MCP locales