Trazar solicitudes, prompts, modelos, herramientas y costes

Una ejecución de IA atraviesa múltiples componentes. Sin correlación, una regresión se convierte en una discusión:

«¿Cambió el modelo, el prompt, el índice o la herramienta?»

Una traza debe permitir reconstruir el recorrido sin almacenar más información sensible de la necesaria.

Diseña el árbol de ejecución

Ejemplo:

request
├─ auth
├─ context_builder
├─ retrieval
│  ├─ vector_search
│  └─ rerank
├─ model_call
├─ tool_call
├─ validation
└─ response

Para cada span registra:

• inicio;
• duración;
• status;
• versión;
• error;
• IDs correlacionables.

Versiona comportamiento

Incluye referencias a:

• app_version;
• prompt_version;
• model;
• provider;
• tool_catalog_version;
• index_version;
• dataset/policy version;
• feature flags.

No dependas solo del commit.

GenAI semantic conventions

OpenTelemetry mantiene semantic conventions para operaciones GenAI. Su objetivo es dar nombres y atributos consistentes a telemetría de modelos y herramientas.

Puedes registrar:

• modelo;
• operación;
• input/output token counts;
• finish reason;
• tool identifiers;
• response ID;
• latencia.

No necesitas usar exactamente OpenTelemetry, pero un estándar reduce formatos propietarios.

Contenido: opt-in y minimizado

La observabilidad de IA invita a guardar prompts y respuestas porque ayudan a depurar.

Eso crea riesgo.

Por defecto prioriza:

• IDs;
• hashes;
• tamaños;
• categorías;
• referencias;
• versiones.

Si guardas contenido:

• justifica finalidad;
• limita acceso;
• redacta secretos;
• aplica retención;
• separa entornos.

OpenTelemetry documenta captura de contenido GenAI como una capacidad que debe activarse de forma explícita, no como requisito universal.

Trazar herramientas

Registra:

• tool;
• argumentos normalizados o hash;
• autorización;
• aprobación;
• resultado;
• efecto confirmado;
• retry;
• error.

Para herramientas sensibles, no guardes secretos.

Trazar RAG

Incluye:

• query ID;
• filtros;
• top-k;
• document IDs;
• chunk IDs;
• scores;
• index version;
• reranker version.

Esto permite separar «el modelo ignoró la evidencia» de «la evidencia no llegó».

Costes

Registra:

• tokens;
• precio efectivo de la versión;
• retries;
• tool cost;
• retrieval;
• review.

Como los precios cambian, conserva el coste calculado en el momento o la tabla de precios versionada que usaste.

No recalcules historia con precios actuales sin indicarlo.

Correlaciona feedback

El feedback debe poder apuntar a:

• response_id;
• trace_id;
• version.

Sin copiar toda la respuesta al sistema de feedback.

Sampling

No necesitas trazas detalladas de todo.

Puedes:

• 100 % errores;
• 100 % high-risk;
• muestra del resto.

Ajusta a coste y privacidad.

Ejemplo

Una caída de groundedness aparece después de un deploy.

La traza muestra:

• modelo igual;
• prompt igual;
• index_version nueva;
• top-k con fuentes distintas.

La investigación empieza por el índice, no por cambiar el prompt.

Diseña cardinalidad

No conviertas user_input en una etiqueta de métrica: puede crear cardinalidad extrema y datos sensibles.

Usa:

• task_type;
• tenant_tier;
• model;
• status.

Para IDs de alta cardinalidad utiliza trazas/logs, no labels agregadas.

IDs de correlación

Propaga:

trace_id
request_id
run_id
job_id

Una petición puede crear un job asíncrono; conserva el vínculo.

Async

Una traza puede cruzar:

• HTTP;
• cola;
• worker;
• webhook.

Propaga contexto o referencia explícita.

No asumas que todo ocurre en un proceso.

Privacidad de telemetry

Clasifica atributos:

PUBLIC version.

INTERNAL tenant ID pseudonimizado.

SENSITIVE prompt.

SECRET API key — prohibido.

Define controles por clase.

Retención diferenciada

Puedes conservar:

• métricas 12 meses;
• traces 30 días;
• contenido debug 24 h.

El ejemplo no es una recomendación universal.

La retención debe responder al uso.

Errores del proveedor

Captura:

• status;
• error_code;
• retry_after si existe;
• request_id.

No necesitas registrar mensajes internos completos.

Modelo efectivo

Si existe routing, registra el modelo que realmente respondió, no solo el modelo solicitado.

Esto ayuda en fallbacks.

Sampling tail-based

Puedes conservar más traces cuando:

• error;
• slow;
• high cost;
• security flag.

Así aumentas detalle donde aporta valor.

Calidad de observabilidad

Prueba que:

• trace se completa;
• IDs correlacionan;
• secretos no aparecen.

Observabilidad también necesita tests.

Herramienta de investigación

Prepara consultas:

• «todas las respuestas de v17 con groundedness baja»;
• «tool X con p95 alto»;
• «tenant Y tras deploy».

Si tu sistema no puede contestarlas, revisa el modelo de telemetría.

Ejercicio

Diseña un schema de trace con:

• request;
• versions;
• spans;
• tools;
• retrieval;
• usage;
• cost;
• feedback link.

Marca cada campo: always / sampled / prohibited.

Antes de continuar

Antes de avanzar, comprueba que cuentas con trazas que convierten cada ejecución en evidencia investigable. La siguiente lección agregará esas ejecuciones para detectar degradación y decidir cuándo alertar.