Trazas y sesiones de producción
Observa y califica lo que tu aplicación hace en producción — trazas, sesiones multi-turno y spans.
La sección Observabilidad recibe las interacciones reales de tu aplicación y las deja listas para calificar con tus criterios. Es el mismo motor de evaluación, aplicado a lo que pasó en producción en lugar de a un golden set.
Tiene tres pestañas: Trazas, Sesiones y Revisión.
Enviar trazas
Verica expone un receptor OTLP/HTTP en POST /v1/traces, autenticado con un token de API con permiso de ingesta. Acepta protobuf y JSON, con o sin gzip.
El botón Conectar aplicación arma el snippet por vos: elige el lenguaje, crea (o reutiliza) un token de ingesta, y copia. Hay cinco caminos: TypeScript, Python, Ruby, OTel nativo y n8n.
Si tu aplicación ya emite OTLP, no hace falta ningún SDK — solo apuntar el exportador:
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://ingest.verica.app/v1/traces
OTEL_EXPORTER_OTLP_HEADERS="authorization=Bearer <tu-token>"Los SDKs de Verica están en SDKs; el nodo de n8n, en n8n.
Qué se lee de cada span
Verica sigue la convención semántica GenAI de OpenTelemetry, aceptando tanto los nombres actuales como los heredados:
| Campo en Verica | Atributo OTLP |
|---|---|
| Modelo | gen_ai.request.model, si no gen_ai.response.model |
| Proveedor | gen_ai.provider.name, si no gen_ai.system |
| Sesión | gen_ai.conversation.id, si no gen_ai.thread.id |
| Tokens de entrada | gen_ai.usage.input_tokens / …prompt_tokens |
| Tokens de salida | gen_ai.usage.output_tokens / …completion_tokens |
| Tokens de razonamiento | gen_ai.usage.reasoning_tokens |
| Tokens cacheados | gen_ai.usage.cache_read.input_tokens |
| Entrada | gen_ai.input.messages, si no gen_ai.prompt |
| Salida | gen_ai.output.messages, si no gen_ai.completion |
| Tags | verica.tags |
Los tokens de razonamiento son un subconjunto de los de salida, y los cacheados de los de entrada: son desgloses, no sumas.
Se admiten hasta 20 tags de 120 caracteres cada uno.
De spans a traza
Una traza en Verica es un turno: la llamada al modelo más sus spans de herramientas y recuperación. Se agrupa por el trace_id de OTLP, así que reenviar el mismo lote es idempotente.
Cuando la traza tiene una sola llamada, se proyecta directo. Cuando tiene varias — un agente — Verica hace la "proyección de turno completo":
- La entrada sale de la llamada ancla (la primera).
- La salida, de la última llamada que traiga contenido.
- Los tokens se suman componente a componente en todo el árbol.
- La latencia va del primer inicio al último fin.
- El costo se calcula por llamada y se suma, así que un árbol que mezcla un router barato con un modelo caro queda bien costeado.
El exportador de OpenTelemetry manda los spans a medida que terminan, así que un agente largo llega repartido en varios envíos. Verica los fusiona por trace_id, unifica los spans y vuelve a proyectar.
google-genai para Python, por ejemplo — emiten el contenido como log records en lugar de atributos del span. Verica ingiere trazas, así que esas llegan solo con metadata: modelo, proveedor, tokens y costo sí; texto no. La interfaz lo marca: "Esta traza llegó sin contenido (captura de contenido desactivada en el emisor)."Qué se guarda cifrado
El contenido — entrada, salida y árbol de spans — se cifra en reposo con el mismo esquema que las credenciales, y la aplicación web no tiene la clave: para mostrar una traza se la pide al worker. Antes de guardarse, el contenido pasa por una redacción de datos personales (emails, teléfonos, tarjetas).
En claro queda solo la metadata operativa, para que puedas filtrar y segmentar sin descifrar nada: modelo, proveedor, tokens, costo, latencia, sesión, tags, nombres y cantidad de spans, más previews redactados de unos 160 caracteres que alimentan las listas y la búsqueda.
"El contenido de esta traza está cifrado. Su metadata no está cifrada, para poder filtrar y segmentar."
Explorar
La lista de Trazas muestra Hora · Sesión · Modelo · Entrada · Salida · Trayectoria · Lat. · Costo · Estado, con filtros de búsqueda por contenido, sesión, modelo, tag, estado (Pass / Fail / Sin evaluar) y rango de tiempo.
Al abrir una traza, el panel lateral tiene Resumen, Conversación, Trayectoria (el árbol de spans), Resultado de evaluación y Metadata. ↑/↓ se mueve entre filas y Esc cierra.
Sesiones multi-turno
Las trazas que llegan con un session_id se agrupan solas en Sesiones. La lista muestra Turnos · Última actividad · Último mensaje · Costo.
Cómo se arman
La entrada de un LLM es acumulativa: en el turno 5 mandas los cinco turnos. Guardar la historia completa en cada turno crece al cuadrado, así que Verica guarda el delta: lo nuevo de cada turno, más el sistema una vez, y reensambla por sesión y orden.
Calificar una sesión
Cada criterio decide, con Alcance de sesión, cómo se aplica sobre una conversación:
- Holístico (toda la conversación) — el valor por defecto. El juez ve todo menos la respuesta final como historia, la respuesta final como la respuesta, y todas las llamadas a herramientas de la sesión. Deja un solo veredicto.
- Por turno — se juzga cada turno con respuesta propia, y además se guarda un veredicto agregado de la sesión.
La agregación por turno es pesimista: cualquier turno que falle hace fallar la sesión; si ninguno falla pero alguno quedó sin resolver, la sesión queda sin resolver. Los turnos N/A no participan, y si todos fueron N/A la sesión también.
span_check no se ofrece para sesiones: es de una sola traza.
Si la sesión creció desde la última evaluación, la interfaz lo dice: "Evaluado hasta el turno {k} de {n}".
Calificar trazas
Evaluar selección aplica criterios sobre las trazas elegidas. "Evaluación sin generación: las trazas ya traen su respuesta. Se aplican criterios sobre la salida capturada."
Los criterios de Observabilidad pertenecen al proyecto (no a un eval ni a un dataset) y pueden ligarse a tags, para que un criterio aplique solo al tráfico de cierta integración.
No todos los criterios sirven aquí: los que necesitan un valor esperado del dataset, o que referencian columnas, se marcan como no aplicables. Una traza que llegó solo con metadata únicamente admite span_check.
"Los jueces se ejecutan con tu credencial BYOK."
Evaluación automática
En lugar de calificar a mano, puedes definir qué parte del tráfico entrante se evalúa sola.
Hay tres presets — Todo, Muestra del 10% y 100% de una etiqueta + 10% del resto — y desde ahí se ajustan las reglas. Cada regla combina un tag, una condición opcional (La respuesta o La entrada que contenga…) y un porcentaje; se aplica la primera que coincida, y el resto del tráfico cae en el porcentaje por defecto.
El muestreo es determinístico: la misma traza recibe siempre la misma decisión, aunque se reingiera.
El panel estima el volumen y el gasto antes de guardar: "≈ {n} trazas/día en alcance" y "≈ {usd} por día en jueces", y muestra el consumo del día.
El Límite de gasto por día protege el bolsillo: al alcanzarlo, la política se pausa sola y se reanuda al empezar el día siguiente en UTC. "Pausada: se alcanzó el límite diario de gasto."
Hallazgos
Un criterio del proyecto que falla sobre una traza produce un hallazgo: la cola de revisión de Observabilidad.
Cada hallazgo lleva el criterio, el motivo (la primera frase del razonamiento) y, cuando lo produjo un juez, la cita textual que lo justifica, anclada en la conversación. Los criterios locales como tool_check o span_check no dejan cita, así que sus hallazgos se muestran sin resaltado.
Los estados son Abiertos, Confirmados, Descartados y Resueltos. Vos decides con Confirmar y Descartar, y la decisión queda atribuida a tu nombre. Un hallazgo con decisión humana no se reabre solo; uno que vuelve a pasar en una recalificación se resuelve.
Cuando descartas el mismo tipo de hallazgo varias veces, Verica saca la conclusión obvia: "Parecido a un hallazgo que descartaste {n} veces — quizá convenga editar este criterio."
Puedes activar Avisarme por correo de nuevos hallazgos. Los avisos se agrupan en una ventana de 15 minutos, así que una tormenta de hallazgos llega como un solo correo.
Promover trazas a un dataset
Promover a dataset convierte trazas reales en casos de prueba curados. Es el camino natural: un fallo de producción se vuelve un caso del golden set que evita la regresión.
Se eligen las trazas, el dataset destino (existente o nuevo) y el mapeo. Hay tres campos promovibles:
| Campo de la traza | A dónde va |
|---|---|
| Mensaje del usuario | Una columna del dataset. Los mensajes de sistema quedan fuera. |
| Salida capturada | Una columna del dataset, típicamente la de referencia. |
| Prompt de sistema | El sistema del prompt del dataset (lo habitual), o una columna por fila. |
Hace falta mapear al menos uno. La columna output está reservada — la genera cada ejecución — así que la salida capturada se mapea normalmente a la columna de referencia.
Mandar el sistema al prompt del dataset solo funciona si todas las trazas elegidas comparten un mismo sistema no vacío; Verica lo verifica en el servidor. Si el dataset ya tenía prompt, se reemplaza solo el sistema y las ejecuciones pasadas conservan su versión.
Cada fila promovida guarda un enlace de vuelta a su traza de origen, visible desde la inspección de caso.
Criterios sobre la trayectoria
span_check evalúa el árbol de spans en lugar del texto: cantidad de pasos, duración o errores internos. La configuración completa está en Criterios y graders.
Además, cualquier juez puede interpolar {{ trajectory }} en su consigna para ver un resumen textual del árbol de spans y razonar sobre el recorrido, no solo sobre la respuesta.
Retención
El contenido de las trazas se purga pasado el periodo de retención del plan. La metadata, los veredictos y los razonamientos se conservan. Las trazas fijadas quedan exentas. Ver Planes y límites.
Siguientes pasos
- SDKs — instrumentar tu aplicación.
- n8n — trazar workflows de n8n.
- Criterios y graders — qué criterios aplican a trazas.