La evaluación de 06-03 responde a "¿puedo desplegar esto?" con casos que tú elegiste. Esta lección responde a la pregunta siguiente: ¿qué está pasando ahora mismo en producción, con las preguntas que nadie eligió? Un sistema con LLM falla de formas que el software clásico no conoce: no lanza excepciones cuando alucina, no devuelve un 500 cuando responde con desgana, y puede duplicar su coste sin que nada "se rompa". En 05-02 sembramos trazas.py::registrar_paso() anunciando que germinaría aquí; toca cumplirlo: definir qué registrar en cada petición, estructurar los logs para que sean explotables, destilar métricas y paneles que cuenten la salud del sistema de un vistazo, montar alertas que digan qué hacer (no solo que algo pasa), y cerrar el círculo con el feedback de los usuarios alimentando el conjunto de evaluación. Es la diferencia entre operar DocuBot y rezar por DocuBot.

1. De las trazas del agente a la observabilidad del sistema
2. Qué registrar en cada petición
3. Logs estructurados: JSON por línea con logging
4. Qué NO loguear
5. Métricas agregadas y paneles
6. Alertas accionables: síntoma, causa probable, acción
7. El feedback de los usuarios: el ciclo de mejora continua
8. El ecosistema de herramientas, por categorías

registrar_paso() nació en 05-02 con una misión modesta: apuntar cada iteración del bucle agéntico (qué pensó, qué herramienta llamó, qué obtuvo) para poder depurar. Eso es una traza: la biografía de una petición. La observabilidad completa añade dos pisos:

• Logs: eventos individuales estructurados, consultables ("enséñame todas las peticiones de ayer con confianza < 0.3").
• Métricas: agregados numéricos en el tiempo ("tasa de fallback por hora", "coste acumulado del día").

La distinción práctica: las trazas explican una petición; las métricas vigilan todas; los logs son la materia prima de ambas. En una aplicación con LLM hay además una peculiaridad: buena parte de los "fallos" son degradaciones silenciosas (respuestas peores, costes mayores, más "no lo sé") que solo se ven en los agregados. Por eso un sistema que solo tiene trazas de depuración está ciego en producción.

El diseño empieza por el evento central: una línea por petición completa (además de las líneas por paso del agente que ya emite trazas.py). Campos, agrupados por lo que permiten responder:

Fíjate en la economía del diseño: casi todo esto ya existía. estimar_coste() y medir_llamada() vienen de 03-04, la confianza del contrato de 02-03, las similitudes de recuperar() de 04-04, las herramientas y confirmaciones de 05-02, la seudonimización de 06-02. La observabilidad no inventa datos; recolecta con disciplina los que el sistema ya produce.

Un log de texto libre ("Usuario preguntó por facturación, fue bien") no se puede consultar ni agregar. El estándar de facto es una línea = un objeto JSON (JSON Lines): lo lee un humano con grep, lo ingiere cualquier plataforma de logs, y lo agrega un script de veinte líneas.

Implementación con el módulo logging de la biblioteca estándar:

Y su integración en el punto de salida de docubot.py::responder (versión abreviada):

Una línea resultante (formateada aquí para leerla; en el fichero va en una sola línea):

Detalles didácticos del código: el Formatter personalizado es el único punto donde se decide el formato (cambiarlo no toca el resto del código); los campos van por extra para no concatenar strings; ensure_ascii=False mantiene legibles los acentos; y id_peticion es la clave que une esta línea con las trazas por paso de registrar_paso() (que ahora también lo incluye) y con el feedback del usuario que llegará minutos después.

Los logs son un tratamiento de datos más (lo vimos en 06-02: entran en el perímetro del GDPR y de los ejercicios de derechos). Reglas para DocuBot:

• Ni la pregunta ni la respuesta en crudo en el log de producción. Contienen lo que el usuario escribió — potencialmente datos personales sin redactar. Opciones intermedias, de menos a más exposición: solo metadatos (lo mostrado arriba); texto redactado con redactar() (06-02) y retención corta; texto completo únicamente en entornos de desarrollo con datos ficticios. Si el negocio necesita revisar conversaciones reales, que sea una decisión explícita con legal, con acceso restringido y caducidad — no un default del logger.
• Identidades reales: siempre el seudónimo de sesión/usuario, con la tabla de correspondencia protegida aparte.
• Claves de API y secretos: jamás. Cuidado con los volcados alegres de objetos de configuración o de excepciones que arrastran headers.
• Prompts completos del sistema: prompts.py está versionado en git; con prompt_version en el log basta. Loguear el prompt entero en cada petición es ruido, coste y exposición de propiedad intelectual.
• Y la regla general: loguea referencias y medidas, no contenidos. {"id": "doc_fact_03#2", "sim": 0.71} en lugar del texto del chunk: el id permite recuperar el contenido si hace falta investigar, sin duplicarlo por el sistema de logs.

Sobre los logs se calculan los agregados. Estos son los indicadores con mejor relación señal/esfuerzo para DocuBot, y lo que cada uno cuenta:

Un panel razonable para DocuBot son estas 8 series con comparación contra la semana anterior. La regla de oro al diseñarlo: cada gráfico debe tener un dueño de la pregunta "¿y si esto cambia, qué hago?" — un panel que nadie sabe interpretar es decoración.

Una alerta que solo dice "algo va mal" genera fatiga y acaba silenciada. Una alerta accionable lleva incorporado el diagnóstico diferencial — exactamente el formato de la tabla de diagnóstico de 04-05, ahora extendida a todo el sistema:

Dos principios al configurar umbrales: alerta sobre tendencias y ratios (tasa que se duplica) más que sobre valores absolutos con ruido; y cada alerta disparada debe terminar o en una acción o en un ajuste del umbral — las alertas que se ignoran tres veces se eliminan o se arreglan.

Todas las señales anteriores son indirectas. La directa es preguntar: un 👍/👎 al pie de cada respuesta (opcionalmente con comentario en el 👎). Barato de implementar — un endpoint que adjunta el veredicto al id_peticion — y valiosísimo si se explota bien:

El uso ingenuo es calcular "% de pulgares arriba" y ponerlo en el panel (útil, con sesgos: vota una minoría, y los descontentos votan más). El uso potente es cerrar el círculo con 06-03:

1. Cada 👎 se une, vía id_peticion, con su log completo: pregunta (redactada), chunks, similitudes, versiones, respuesta.
2. Revisión periódica de los 👎: ¿recuperación mala? ¿respuesta infiel? ¿hueco de documentación? La tabla de síntomas de arriba, aplicada caso a caso.
3. Los fallos reales representativos se convierten en casos nuevos del conjunto de evaluación de 06-03, con su resultado esperado anotado.
4. La siguiente iteración de prompt/chunking se valida ya contra ellos: ese modo de fallo no vuelve sin que el runner lo detecte.

Este bucle es la respuesta madura a una pregunta que ronda el curso desde 02-04: "¿de dónde salen los buenos casos de evaluación?". Al principio, de tu imaginación y de preguntas recopiladas; en régimen permanente, de los fallos reales de producción. La observabilidad no es solo vigilancia: es la cantera del conjunto de evaluación.

Todo lo anterior está construido con la biblioteca estándar a propósito: entender el mecanismo antes que adoptar la plataforma (la misma filosofía del bucle agéntico a mano de 05-03). En un sistema en crecimiento, evalúa por categorías:

• Plataformas de observabilidad específicas de LLM (comerciales y open source): capturan automáticamente trazas de llamadas/agentes con prompts, tokens y costes; ofrecen visualización de conversaciones, evaluaciones integradas y anotación de datasets. Aportan mucho de 06-03 + 06-04 empaquetado; a cambio, tus prompts y datos pasan por otra plataforma más — el análisis de 06-02 aplica también a ellas.
• Observabilidad generalista + OpenTelemetry: el estándar abierto de trazas/métricas/logs del mundo cloud. Existen convenciones semánticas para IA generativa, de modo que las llamadas al LLM aparecen como spans en el mismo sistema donde ya observas el resto de tu plataforma. Atractivo si tu organización ya opera este stack: DocuBot deja de ser una isla.
• Agregadores de logs clásicos: si ya tienes uno, tus JSON Lines entran tal cual; paneles y alertas de esta lección se montan encima sin nada específico de IA.

Criterio de elección honesto: el valor diferencial de las plataformas LLM está en la visualización de trazas de agentes y en integrar evaluación y anotación; si tus logs estructurados ya responden a tus preguntas, no corras a añadir infraestructura. Lo importante — qué registrar, qué no, qué mirar y qué hacer al respecto — es lo que has diseñado en esta lección, y es portable a cualquier herramienta.

• Loguearlo todo "por si acaso". Prompts completos y conversaciones en crudo son coste, ruido y un problema de privacidad (06-02). Referencias y medidas, no contenidos; y retención definida.
• Observabilidad de software clásico sin señales de LLM. Uptime y errores HTTP no ven alucinaciones, degradación de confianza ni huecos de documentación. Las métricas específicas (frase anti-alucinación, confianza, confirmaciones rechazadas) son las que detectan los fallos silenciosos.
• Logs sin versiones. Si cada línea no lleva prompt_version/chunking_version/modelo, no podrás responder a la única pregunta que importa tras un despliegue: "¿esto empezó con el cambio?".
• Mirar la latencia media. La media esconde la cola; el usuario del p95 es el que abandona. Percentiles siempre (los calculabas ya con medir_llamada() en 03-04).
• Alertas sin acción asociada. Cada alerta debe nacer con su fila de la tabla síntoma→causa→acción. Si al dispararse nadie sabe qué hacer, no es una alerta: es ruido programado.
• Recoger feedback y no explotarlo. El % de pulgares en un panel es la parte pequeña; el valor está en convertir los 👎 en casos del conjunto de 06-03. Feedback sin ciclo es un buzón de sugerencias sin fondo.
• Confundir monitorización con evaluación. Los paneles te dicen que algo empeoró; el runner de 06-03 te dice si tu arreglo lo corrige sin romper otra cosa. Son las dos mitades del mismo músculo: producción alimenta el conjunto; el conjunto protege producción.

Es lunes. El panel de DocuBot muestra, respecto a la semana pasada: tasa de frase_sin_info estable (11%), confianza media estable, coste diario +40%, latencia p95 +35%, TTFT estable, tasa de caché exacta caída del 30% al 8%, volumen de peticiones +5%. El viernes no se desplegó ninguna versión nueva. ¿Cuál es tu hipótesis principal, qué campos de los logs la confirmarían y qué mirarías primero?

Añade a log_peticion la información del human-in-the-loop: un campo confirmacion que valga null si la petición no propuso acciones, "aceptada" o "rechazada" si las propuso. Escribe además la consulta conceptual (en pseudocódigo o Python sobre las líneas JSON) que calcula la tasa semanal de rechazo, y explica con qué alerta de la tabla se conecta.

Un usuario vota 👎 en una respuesta sobre la categoría permisos con el comentario "me dijo que los invitados pueden editar tareas, y no es verdad". El log muestra: confianza: 0.82, dos chunks recuperados con similitudes 0.58 y 0.47, frase_sin_info: false. Describe el diagnóstico paso a paso (qué mirarías y en qué orden) y redacta el caso de evaluación resultante para el conjunto de 06-03.

Ejercicio 1:

La pieza clave es la caída de la caché exacta (30% → 8%) con volumen casi plano y sin despliegue: cada petición que antes salía gratis de CacheRespuestas ahora va al modelo — eso explica simultáneamente el coste (+40%) y el p95 (+35%: las respuestas cacheadas eran instantáneas y bajaban el percentil), con TTFT estable (el proveedor está bien; simplemente hay más llamadas reales). Hipótesis principal: cambió el patrón de las preguntas — preguntas nuevas que no están en caché. ¿Por qué en lunes? Un candidato típico: Nubelia lanzó algo el fin de semana y llegan preguntas inéditas. Confirmación en los logs: distribución de cache (miss disparado), volumen por categoria (¿una categoría creció?), y muestreo de las preguntas nuevas (redactadas). Nota fina: frase_sin_info estable sugiere que la wiki sí cubre los temas nuevos — si además subiera, la hipótesis del lanzamiento sin documentar ganaría fuerza. Primera acción: mirar la distribución de caché por categoría; si es un tema nuevo legítimo, el coste extra es demanda real (y la caché se recalentará sola en días).

Ejercicio 2:

En responder, al registrar:

Consulta sobre los JSON Lines:

Detalle importante: el denominador son las peticiones con propuesta (confirmacion is not None), no todas — por eso el campo distingue null de los otros dos valores. Se conecta con la alerta "tasa de confirmaciones rechazadas 5% → 30%": rechazo alto = el agente propone mal (prompt/descripciones de herramienta degradados) o, en el peor caso, contenido hostil empujando acciones — lo que remite a las trazas por paso y a las defensas de 06-01.

Ejercicio 3:

Diagnóstico ordenado: (1) Con id_peticion, recuperar la traza completa y los ids de los chunks (0.58 y 0.47 — el segundo roza el UMBRAL_RELEVANCIA=0.45: recuperación mediocre). (2) Leer los chunks por su id: ¿alguno afirma que los invitados pueden editar tareas? Dos ramas: si ningún chunk lo dice → respuesta infiel (alucinación con confianza 0.82: el perfil peligroso), problema de generación; si un chunk desactualizado lo dice → el problema es de contenido/ingesta, no del modelo — corregir el documento y reingerir (04-03). (3) Según la rama: rama infidelidad → caso para el runner con juez de fidelidad; rama documento → arreglo editorial + verificación. Caso de evaluación (rama infidelidad):

Con esto, la próxima variación de prompt o chunking se valida también contra el fallo real: el ciclo de mejora continua, cerrado.

Las trazas sembradas en 05-02 han germinado en un sistema nervioso completo: cada petición deja una línea JSON con su identidad seudonimizada (la lección de 06-02 aplicada a los propios logs), sus versiones de prompt/chunking/modelo (sin ellas ningún análisis post-despliegue es posible), sus chunks y similitudes, sus herramientas y confirmaciones, sus tokens, coste y percentiles de latencia, y las señales de calidad que el sistema ya emitía gratis — la confianza del contrato y la frase anti-alucinación, cuya tasa resulta ser el mejor termómetro de los huecos de la documentación. Encima de los logs, ocho métricas con dueño y una tabla de alertas que no gritan "algo va mal" sino "esto es lo que probablemente pasa y esto es lo primero que debes mirar". Y el cierre del círculo: los pulgares abajo de usuarios reales se convierten, vía id_peticion, en casos nuevos del conjunto de 06-03 — producción alimenta la evaluación, la evaluación protege producción. Con esto, el casco está completo: DocuBot resiste manipulación (06-01), respeta los datos (06-02), se evalúa antes de cambiar (06-03) y se vigila mientras opera (06-04). Solo queda una cosa, y es la más satisfactoria: juntar todas las piezas construidas a lo largo de seis módulos, mirar la arquitectura completa de una vez, recorrer una petición real de punta a punta y pasar la checklist final de producción. La próxima lección es el proyecto final — DocuBot, entero.