Observabilidad y evaluación de resultados

La API responde 200, el worker consume tareas y el modelo genera texto. Aun así, puede citar un documento equivocado o publicar un informe incompleto. La observabilidad explica qué pasó dentro del sistema; la evaluación comprueba si resolvió la necesidad.

Separa ambas. Un timeout es una señal operativa. Una respuesta sin soporte es un fallo de calidad. Una herramienta que accede a otro tenant es un fallo de autorización, aunque produzca una respuesta útil. El panel debe permitir ver estas diferencias.

Un log registra un hecho detallado. Una métrica agrega cantidades: latencia, errores, cola pendiente o coste. Una traza conecta operaciones de una ejecución mediante spans, intervalos con inicio, fin y atributos. OpenTelemetry define herramientas y convenciones para producir estas señales; no obliga a usar un proveedor de observabilidad concreto.

{
  "event": "tool.finished",
  "run_id": "r-17",
  "call_id": "c-8",
  "operation_id": "op-8",
  "attempt": 2,
  "duration_ms": 412,
  "status": "ok",
  "artifact_hash": "sha256:..."
}

Los identificadores permiten relacionar una queja con la trayectoria. Evita poner run_id como etiqueta de todas las métricas agregadas: millones de valores distintos aumentan mucho la cardinalidad y el coste. Úsalo en logs y trazas; agrega métricas por dimensiones acotadas como herramienta, ruta y resultado.

Para una respuesta RAG incorrecta, sigue esta secuencia:

1. ¿El documento correcto existía y estaba autorizado?
2. ¿La recuperación lo devolvió entre candidatos?
3. ¿El constructor lo incluyó y conservó su versión?
4. ¿El modelo usó esa evidencia correctamente?
5. ¿La verificación detectó la afirmación sin soporte?

Si falló el segundo paso, mejorar el prompt final no soluciona la recuperación. Si el modelo vio un documento obsoleto, cambiar de modelo puede repetir el mismo error con mayor coste. Un manifiesto de contexto y referencias de versión hacen que estas preguntas sean respondibles.

Crea casos con entrada, datos, resultado aceptable y fallos prohibidos. Incluye tareas normales, ausencia de evidencia, permisos, ambigüedad y fallos de infraestructura. Separa casos usados para ajustar prompts de casos reservados para comparar versiones.

CASOS = [
    {"id": "known", "question": "¿Cómo se verifica un backup?",
     "expected_sources": {"restore-guide"}, "must_abstain": False},
    {"id": "missing", "question": "¿Cuál fue el ingreso de ayer?",
     "expected_sources": set(), "must_abstain": True},
]


def evaluar(resultado, caso):
    cited = set(resultado["sources"])
    return {
        "fuentes_presentes": caso["expected_sources"] <= cited,
        "abstencion_correcta": resultado["abstained"] == caso["must_abstain"],
    }

Este evaluador comprueba estructura y comportamiento de abstención, no veracidad semántica. Una respuesta puede citar el identificador correcto y decir algo que ese documento no sostiene. Añade comprobaciones de dominio y revisión de una muestra para cubrir ese límite.

Usa comprobaciones deterministas cuando exista una regla clara: JSON válido, total calculado, permisos, cita perteneciente al conjunto recuperado, pruebas sobre un artefacto. Son rápidas y repetibles.

Un modelo como juez puede valorar aspectos difíciles de codificar, pero también se equivoca, favorece estilos o sigue instrucciones dentro de la respuesta evaluada. Dale una rúbrica explícita y ejemplos calibrados. Compara sus decisiones con revisión humana antes de usarlo como único gate. No confundas acuerdo entre dos modelos con una prueba objetiva.

Para un informe, una rúbrica puede puntuar cobertura de requisitos, soporte de afirmaciones, manejo de incertidumbre y utilidad del siguiente paso. Evita una única nota vaga de «calidad». Dos versiones con la misma media pueden tener fallos muy distintos.

Prueba	Invariante comprobada
Caída antes de guardar decisión	No aparece una operación aceptada a medias
Caída después del efecto interno	Reinicio no duplica el artefacto
Timeout de efecto externo	Se reconcilia o conserva incertidumbre
Lease caducado y worker antiguo activo	Se rechaza su escritura obsoleta
Entrega de hijo duplicada	Se admite una vez en la trayectoria
Cancelación durante inferencia	No se inicia una herramienta posterior
Documento de otro tenant	No aparece ni en snippets ni en lectura
Replay de eventos	Reconstruye vista sin ejecutar efectos

Estas pruebas son distintas de evaluar la inteligencia del modelo. Un modelo simulado es adecuado para ellas porque hace determinista la propuesta. Después se necesitan casos reales para medir cómo el modelo elige herramientas y utiliza evidencia.

Ejecuta las mismas tareas, fuentes y restricciones con ambas versiones. Registra versión de prompt, modelo, herramienta, índice y contexto. Repite casos variables cuando sea necesario y muestra dispersión, no solo el mejor resultado.

Mide coste por resultado válido: coste total dividido por tareas que superan criterios, junto a la tasa de éxito. Si un cambio reduce coste por llamada pero aumenta fallos y reintentos, puede empeorar el coste de resolver necesidades reales. Observa también percentiles de latencia; una media baja puede ocultar tareas que tardan diez veces más.

No necesitas una plataforma de experimentación enorme. Un archivo de casos, un runner reproducible, resultados guardados y una tabla comparativa pueden bastar para un equipo pequeño.

Cuando un run se atasca, mira primero estado, lease y operación pendiente. Si está esperando, comprueba la condición de reanudación. Si repite acciones, compara argumentos y observaciones. Si el coste crece, identifica la rama y el tipo de consumo. Si produjo una entrega incorrecta, sigue la cadena de evidencia.

Una corrección puede requerir reanudar desde el último checkpoint, invalidar memoria obsoleta o crear una nueva ejecución con una instrucción aclarada. No edites silenciosamente el historial para hacer que parezca correcto: perderías la posibilidad de explicar el incidente.

• Observability primer, OpenTelemetry: logs, métricas, trazas y fiabilidad.
• Building effective agents, Anthropic: evaluación y feedback sobre tareas reales.