flowchart TD
t["Traza: consulta del usuario"] --> s1["Recuperación"]
t --> s2["Llamada al modelo"]
s2 --> s3["Herramienta: consultar expediente"]
s3 --> s4["Llamada al modelo"]
s4 --> s5["Respuesta"]
classDef contexto fill:#d5e6f5,stroke:#3d7cb0,stroke-width:1.5px,color:#12354e
classDef modelo fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
classDef herramienta fill:#fae3c8,stroke:#bf7f28,stroke-width:1.5px,color:#573809
class t,s1 contexto
class s2,s4,s5 modelo
class s3 herramienta
19 Observabilidad y coste
Un sistema generativo falla de una manera particularmente incómoda: no lanza excepciones. Devuelve una respuesta correcta en forma y equivocada en contenido, con código 200 y en el tiempo esperado. Los paneles de siempre (errores, latencia, disponibilidad) seguirán en verde mientras el sistema dice barbaridades.
De ahí que aquí la observabilidad no sea una buena práctica de operaciones. Es el único mecanismo que tenemos para enterarnos de algo.
19.1 La unidad de observación es la traza
Una petición a un agente no es una llamada, es un árbol: la petición del usuario, la recuperación de documentos, tres llamadas al modelo, dos ejecuciones de herramienta y la respuesta final. Cualquier registro que no conserve esa estructura es inútil para depurar.
Lo que hay que registrar en cada tramo, y aquí la lista es corta y no negociable:
- El contexto exacto que se envió, no la plantilla. Sin esto, depurar es imposible: el 90% de los comportamientos raros se explican al ver lo que de verdad le llegó al modelo.
- La respuesta completa, incluidas las peticiones de herramienta.
- Modelo y versión exactos, además de temperatura y demás parámetros.
- Tokens de entrada, de salida, en caché y de razonamiento, por separado. Es la base del coste.
- Latencia por tramo y, en interacciones de chat, tiempo hasta el primer token.
- Versión del prompt, para poder atribuir cambios de comportamiento.
- Identificadores de usuario, sesión y aplicación, para poder agrupar y para poder atribuir gasto.
19.2 OpenTelemetry, y por qué importa
La buena noticia es que esto no hay que inventarlo. OpenTelemetry tiene convenciones semánticas para IA generativa que fijan cómo se nombran estos atributos: tramos de llamada al modelo, de invocación de agente, de herramienta y de consulta a un índice vectorial, con nombres de atributo comunes para modelo, tokens y coste.
Siguen marcadas como experimentales y les faltan cosas (la evaluación de calidad, por ejemplo, no la cubren), pero son el punto de acuerdo de la industria y eso las hace valiosas por una razón muy pragmática: emitir trazas en un formato estándar es lo que os permite cambiar de herramienta de análisis sin reinstrumentar.
En un mercado donde las plataformas de observabilidad de IA aparecen y se consolidan cada trimestre, esa es la propiedad que hay que exigir. La pregunta al evaluar cualquier producto de esta categoría es la misma: ¿ingiere OpenTelemetry y me deja exportar mis datos? Si la respuesta a cualquiera de las dos partes es no, es un secuestro de datos con interfaz bonita.
AdvertenciaLas trazas contienen todo
Una traza guarda el prompt completo, y el prompt completo contiene los documentos recuperados y lo que escribió el usuario. Es decir: vuestro sistema de observabilidad hereda la clasificación del dato más sensible que pase por el sistema.
Eso tiene consecuencias que conviene resolver antes de instrumentar y no después: enmascarar datos personales antes de almacenar, política de retención explícita, control de acceso al visor de trazas y, si el producto es SaaS, la misma revisión de proveedor que se le hizo al modelo. Es un despiste habitual: se cuida mucho por dónde pasa el dato hacia el modelo y se envía copia íntegra a una herramienta de terceros sin pensarlo.
19.3 El coste como métrica de primera
Con las trazas bien puestas, el coste deja de ser una factura mensual y se convierte en una dimensión más: por usuario, por caso de uso, por conversación, por tarea resuelta.
Las tres cifras que conviene tener en un panel desde el primer día:
| Métrica | Por qué esta |
|---|---|
| Coste por tarea resuelta | Es la que se compara con el valor. El coste por llamada no dice nada. |
| Tokens por tarea, desglosados | Entrada, salida, caché y razonamiento. Señala dónde optimizar. |
| Tasa de acierto de caché | Suele haber ahorro fácil aquí y nadie lo mira. |
Y un aviso sobre la primera: en un agente, el coste por tarea tiene una cola muy larga. La mediana puede ser aceptable mientras el percentil 99 es cien veces mayor, porque son las tareas donde el bucle se atascó. Vigilar la media es engañarse; hay que mirar la distribución y ponerle un tope duro.
NotaFinOps para IA, en una nota
El sector ha ido consolidando prácticas de control de gasto en IA con nombre propio, pero lo que hay debajo cabe en cuatro puntos:
- Atribuir: cada llamada etiquetada con equipo, aplicación y caso de uso. Sin etiquetas no hay conversación posible sobre coste.
- Presupuestar por caso de uso, no globalmente, con alertas antes del tope y no después.
- Enrutar por dificultad, que es la palanca que más ahorra.
- Comparar contra valor, no contra el mes anterior. Un caso de uso que cuesta el doble y ahorra diez veces más en horas es un éxito.
La razón por la que esto aparece en un manual técnico es que las decisiones que disparan el coste son técnicas: cuántas vueltas da el bucle, cuánto contexto se arrastra, qué modelo se eligió por defecto. Quien puede arreglarlo es quien escribe el código.
19.4 Del registro a la mejora
Instrumentar por instrumentar no sirve. El bucle que cierra el sistema es este:
- Las trazas de producción revelan fallos y patrones de uso reales.
- Esos casos se incorporan al conjunto de evaluación.
- Los cambios se validan contra ese conjunto antes de desplegar.
- Vuelta a empezar, con un conjunto cada vez más representativo.
Sin el paso 2, la observabilidad es un archivo de incidentes que nadie consulta. Con él, cada fallo en producción mejora el sistema de forma permanente, que es lo más parecido a una ventaja acumulativa que se puede construir en este terreno: los modelos los tiene todo el mundo, vuestro conjunto de evaluación no.
19.5 El cuaderno
Instrumenta el agente de la secretaría con OpenTelemetry y las convenciones semánticas de IA generativa, sin levantar ninguna plataforma: los tramos se recogen en memoria y se miran ahí mismo. Esa decisión es la tesis del capítulo hecha código, porque cambiar a un exportador de verdad no toca ni una línea de la instrumentación.
Lo que sale es el árbol de la primera figura, generado en lugar de dibujado, y con él tres cosas que solo se ven al medir. Que la ejecución de la herramienta tarda milisegundos y el resto es el modelo, así que optimizar aquella sería tirar el tiempo. Que el coste no lo decide la consulta sino cuántas vueltas dio el bucle, y que como cada vuelta arrastra lo anterior, el crecimiento no es lineal. El cuaderno proyecta esa curva y a la vez enseña que su propia proyección exagera, porque el prompt de sistema y las definiciones de herramientas son un coste fijo que no crece con las vueltas. Y que en la traza acaba guardado el expediente completo del alumno, con su nota y su identificador, lo cual convierte al visor de trazas en un sitio donde vive información personal.
Termina extrayendo casos de evaluación de las propias trazas, con el campo de la respuesta esperada vacío a propósito: una traza dice lo que pasó, no si estuvo bien.
Con el sistema medido y vigilado, queda la parte que decide si puede existir: seguridad y normativa.