El equipo había estado tres semanas construyendo un agente de soporte técnico. Funcionaba bien en local. Lo lanzaron a producción un lunes por la mañana.
El viernes tenían una factura de $1.200 en tokens, tres tickets de clientes con respuestas completamente inventadas y ninguna pista de en qué paso del flujo había empezado a fallar todo.
El agente había estado corriendo. Respondiendo. Consumiendo. Pero nadie podía ver qué estaba pasando dentro.
Ese es el problema que resuelve la observabilidad en LLMs — el conjunto de técnicas que permite registrar, medir y analizar cada paso de un agente de IA en producción: los prompts enviados, las herramientas invocadas, los tokens consumidos y los errores producidos. Si estás construyendo cualquier cosa con IA en producción, necesitas entenderla antes de que te pase lo mismo.
El problema real: los LLMs son cajas negras que facturan
Con una API REST tradicional tienes un contrato claro: envías una petición, recibes una respuesta, mides el tiempo, logueas el error. La traza es determinista.
Con un LLM, el contrato se rompe. Puedes enviar el mismo prompt dos veces y recibir respuestas distintas. Un agente puede invocar herramientas en un orden diferente al esperado. El modelo puede alucinarse con un dato en el paso 3 de 7 y tú solo ves el resultado final — correcto en formato, incorrecto en contenido.
Sin observabilidad, estás volando a ciegas. Y en producción, volar a ciegas con un LLM significa costos impredecibles, degradación silenciosa de calidad y bugs que no aparecen en ningún test.
Los tres pilares de la observabilidad en LLMs
La observabilidad clásica tiene tres dimensiones. En el mundo de los LLMs, cada una significa algo distinto.
Trazas (Traces)
Una traza registra el camino completo de una ejecución: qué prompt se envió, qué herramientas se llamaron, en qué orden, con qué inputs y qué outputs. En un agente con múltiples pasos, una traza te muestra el árbol completo de decisiones — no solo el resultado final.
Es la diferencia entre saber que tu agente “falló” y saber exactamente en qué llamada a qué herramienta empezó a descarrilarse.
Métricas
Latencia por llamada, costo en tokens (input + output), tasa de éxito de herramientas, número de reintentos. Estas métricas agregadas te dicen si tu sistema está degradándose con el tiempo o si hay un prompt específico que consume diez veces más tokens que los demás.
Logs estructurados
No los logs de consola que escribes para depurar en local. Logs que capturen el contexto completo de cada ejecución: qué usuario lanzó la petición, qué versión del prompt se usó, qué modelo, qué temperatura. Logs que puedas consultar después cuando alguien reporte un comportamiento extraño hace 48 horas.
Herramientas de observabilidad LLM en 2026
Cinco herramientas que cualquier developer que construye con IA debería conocer:
| Herramienta | Tipo | Self-hosted | Stack ideal | Plan gratuito |
|---|---|---|---|---|
| Langfuse | SDK + plataforma | ✅ Sí | Cualquier API | 50k obs/mes |
| LangSmith | Plataforma | ❌ No | LangChain | Sí (limitado) |
| Helicone | Proxy | ❌ No | Multi-proveedor | Sí |
| Arize Phoenix | Análisis offline | ✅ Sí | Evaluación por lotes | Open source |
| OpenTelemetry GenAI | Estándar | ✅ Sí | Stacks OTEL existentes | Open source |
Langfuse — El estándar open source. Puedes autohospedarlo o usar su cloud. Tiene SDK para TypeScript, Python e integración nativa con LangChain, Vercel AI SDK y llamadas directas a la API de Anthropic u OpenAI. Es la opción que recomiendo si quieres control total sobre tus datos.
LangSmith — El producto de LangChain. Excelente si ya usas LangChain en tu stack, pero te ata al ecosistema. Para proyectos con llamadas directas a la API, Langfuse gana en flexibilidad.
Helicone — Proxy que se pone delante de cualquier llamada a la mayoría de proveedores LLM (OpenAI, Anthropic, Azure, LiteLLM y otros). Configuración en dos minutos, observabilidad inmediata. Ideal para proyectos donde no puedes tocar el código de integración o quieres monitoreo rápido sin instrumentación.
Arize Phoenix — Enfocado en evaluación y análisis offline. Útil cuando quieres analizar lotes de ejecuciones para detectar problemas de calidad sistemáticos, no solo monitoreo en tiempo real.
Semantic conventions for generative AI systems (OTel GenAI) — El estándar OTEL para IA lleva trazas de LLMs al stack de observabilidad que ya tienes (Grafana, Datadog, Honeycomb). Si tu empresa ya tiene infraestructura OTEL, esta es la forma de integrar los LLMs sin añadir otra herramienta.
Implementación real con TypeScript y Langfuse
Suficiente teoría. Esto es cómo lo implementas en un proyecto TypeScript.
Primero, instala el SDK (versión actual: langfuse@3.x):
npm install langfuse
Inicializa el cliente una sola vez en tu aplicación — en un módulo singleton si usas NestJS, en un archivo de configuración si es un script:
import Langfuse from "langfuse";
export const langfuse = new Langfuse({
publicKey: process.env.LANGFUSE_PUBLIC_KEY!,
secretKey: process.env.LANGFUSE_SECRET_KEY!,
baseUrl: "https://cloud.langfuse.com", // o tu instancia autohospedada
});
Ahora instrumenta una llamada a Claude. El patrón es siempre el mismo: creas una traza, creas una generación dentro de esa traza, ejecutas la llamada y registras el resultado:
import Anthropic from "@anthropic-ai/sdk";
import { langfuse } from "./langfuse-client";
const client = new Anthropic();
async function generateSupportResponse(
userMessage: string,
userId: string
): Promise<string> {
// Abre la traza — representa toda la operación de negocio
const trace = langfuse.trace({
name: "support-response",
userId,
metadata: { channel: "web" },
});
// Crea una generación — representa una sola llamada al LLM
const generation = trace.generation({
name: "claude-response",
model: "claude-sonnet-4-6",
input: [{ role: "user", content: userMessage }],
});
try {
const response = await client.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 1024,
messages: [{ role: "user", content: userMessage }],
});
const outputText =
response.content[0].type === "text" ? response.content[0].text : "";
// Registra la respuesta y el uso de tokens
generation.end({
output: outputText,
usage: {
input: response.usage.input_tokens,
output: response.usage.output_tokens,
},
});
return outputText;
} catch (error) {
// Registra errores también — son datos cruciales
generation.end({
level: "ERROR",
statusMessage: error instanceof Error ? error.message : "Unknown error",
});
throw error;
} finally {
// Vacía el buffer antes de cerrar el proceso
await langfuse.shutdownAsync();
}
}
Para un agente con múltiples pasos — por ejemplo, uno que busca en una base de datos antes de responder — anidas spans dentro de la traza:
async function agentWithToolCall(query: string, userId: string) {
const trace = langfuse.trace({
name: "agent-with-tools",
userId,
input: { query },
});
// Span para la búsqueda en base de datos
const searchSpan = trace.span({
name: "database-search",
input: { query },
});
const searchResults = await searchDatabase(query);
searchSpan.end({
output: { resultCount: searchResults.length },
});
// Generación con los resultados como contexto
const generation = trace.generation({
name: "synthesis",
model: "claude-sonnet-4-6",
input: buildPromptWithContext(query, searchResults),
});
const response = await callClaude(query, searchResults);
generation.end({ output: response });
trace.update({ output: { response } });
await langfuse.shutdownAsync();
return response;
}
Con esto, cada ejecución queda registrada en Langfuse con su árbol completo de spans. Puedes ver exactamente cuánto tardó la búsqueda, cuántos tokens consumió la síntesis y qué prompt produjo esa respuesta que el cliente reportó como incorrecta.
Es exactamente este tipo de arquitectura observable la que construimos en el curso Construye con IA — desde el primer agente hasta el sistema completo en producción, con trazabilidad desde el día uno.
Los errores que aparecen cuando no tienes observabilidad
Estos son los tres problemas que he visto repetirse en proyectos sin observabilidad — y que solo se detectan cuando ya han causado daño:
Alucinaciones no detectadas. El agente responde con confianza. El formato es correcto. El dato está mal. Sin trazas, nunca sabes en qué paso del flujo el modelo inventó algo. Con trazas, identificas el prompt exacto que produce el problema y lo corriges.
Latencias ocultas. El endpoint responde en 8 segundos. No sabes si el problema está en la llamada al LLM, en la búsqueda vectorial o en el postprocesado. Las métricas por span te dicen exactamente dónde está el cuello de botella.
Costos fuera de control. Un prompt mal diseñado puede consumir 10x más tokens que uno equivalente. Sin métricas de uso por operación, solo ves la factura de fin de mes. Con observabilidad, detectas el problema en el primer día de producción.
Por dónde empezar si ya tienes un proyecto en marcha
No tienes que instrumentar todo de golpe. El orden que funciona:
- Añade Langfuse o Helicone a la llamada al LLM más crítica de tu sistema.
- Registra siempre: modelo, versión del prompt, userId, tokens usados.
- Cuando detectes un comportamiento inesperado, usa las trazas para reproducirlo.
- Una vez que el patrón funciona, extiéndelo al resto de llamadas.
La observabilidad no es una feature opcional que añades al final. Es la infraestructura que te permite iterar sobre tus prompts con datos reales — no con intuición.
Si quieres construir sistemas con IA desde cero con buenas prácticas de producción integradas desde el principio, en Dominicode Labs tenemos proyectos y recursos donde trabajamos exactamente esto junto a otros developers hispanohablantes.
FAQ — Preguntas frecuentes sobre LLM Observability
¿Qué diferencia hay entre observabilidad en LLMs y logging tradicional?
El logging tradicional captura eventos discretos: errores, requests, respuestas. La observabilidad en LLMs captura el flujo completo de razonamiento de un agente: qué herramientas invocó, en qué orden, con qué contexto, y cómo cada paso influyó en el resultado final. La diferencia es la misma que entre saber que tu avión aterrizó tarde y saber exactamente en qué tramo de la ruta perdió tiempo.
¿Necesito observabilidad si solo uso un LLM para tareas sencillas como resúmenes de texto?
Si está en producción y lo usa más de un usuario, sí. Incluso para tareas aparentemente sencillas, la observabilidad te da visibilidad sobre costos (¿cuánto estoy gastando por resumen?), calidad (¿hay inputs que producen respuestas malas consistentemente?) y latencia (¿hay prompts que tardan 5x más que otros?). El esfuerzo de instrumentar una sola llamada es de menos de 20 líneas de código.
¿Langfuse es mejor que LangSmith?
Depende de tu stack. Si usas LangChain, LangSmith es la integración más natural. Si haces llamadas directas a la API de Anthropic u OpenAI, o usas el Vercel AI SDK, Langfuse tiene mejor soporte, es open source y puedes autohospedarlo. Para proyectos donde los datos son sensibles y no quieres enviarlos a un tercero, Langfuse self-hosted es la única opción razonable.
¿Cómo gestiono la observabilidad en un agente con múltiples LLMs y herramientas?
Usando el modelo de trazas jerárquicas: una traza por operación de negocio, spans para cada herramienta o paso intermedio, y generaciones para cada llamada al LLM. Langfuse, LangSmith y Arize Phoenix soportan este modelo de forma nativa. La clave es diseñar las trazas pensando en qué preguntas querrás responder cuando algo falle — no en lo que es fácil de capturar.
¿Cuánto cuesta implementar observabilidad con Langfuse?
Langfuse Cloud tiene un plan gratuito generoso (50.000 observaciones al mes en la fecha de publicación de este post). Para proyectos con volumen alto, puedes autohospedarlo en tu propia infraestructura con Docker — el costo es solo el del servidor. LangSmith y Helicone tienen también niveles gratuitos, pero con menos control sobre los datos.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
