# Evaluación, observabilidad y control canonical_url: https://www.3.14financialcontents.com/es/capacidades/evaluacion-observabilidad-y-control/ markdown_url: https://www.3.14financialcontents.com/es/capacidades/evaluacion-observabilidad-y-control/index.md language: es-ES content_type: capabilities status: published description: Diseñamos evals, pruebas adversariales, benchmarks, simulaciones, validadores, trazas, métricas y mecanismos de observabilidad para modelos, agentes, sistemas de conocimiento, workflows, software y sistemas físicos. Combinamos evaluación… Medir cómo funciona un sistema de IA, detectar dónde falla y controlar qué puede hacer. ## Qué responde la evaluación - qué calidad alcanza - bajo qué condiciones - frente a qué baseline - qué error produce - cómo lo detectamos - qué consecuencia tiene - cómo se recupera - qué aprende el sistema ## Tecnologías y prácticas - pytest - evaluación programática - challenge sets - revisión humana - simulación - tracing distribuido - OpenTelemetry - métricas y dashboards - logs estructurados - versionado - feature flags - shadow mode - canary - rollback - tests HIL - tests de seguridad - DSPy y GEPA con evals - evaluaciones propias de dominio Una evaluación descubre bajo qué condiciones el sistema encuentra sus límites; la observabilidad permite saber qué conviene mejorar después. Un sistema inteligente puede encontrar sus límites en muchos lugares. La fuente puede estar desactualizada. La recuperación puede seleccionar un fragmento parecido. El modelo puede interpretar mal. Una herramienta puede ejecutar dos veces. Un workflow puede perder estado. Una interfaz puede presentar una decisión sin contexto. Una máquina puede actuar con una estimación insuficiente. Evaluamos el recorrido completo. La observabilidad conserva las señales necesarias para responder después de cada ejecución. El control limita la autoridad y permite detener, revisar, revertir o escalar. ## Evaluar desde el resultado hacia atrás Empezamos por el resultado esperado. Después identificamos decisiones, acciones, políticas, herramientas, modelos, recuperación, fuentes y datos. Cada componente posee métricas propias y una relación con el resultado. Un modelo puede mejorar precisión y aumentar latencia. Un agente puede completar más casos y elevar el coste. Una automatización puede reducir pasos y aumentar las excepciones. La evaluación del sistema relaciona esas consecuencias. ## Capas de evaluación **Información.** Cobertura, vigencia, procedencia, resolución de entidades, soporte, contradicción y abstención. **Lenguaje.** Fidelidad, terminología, omisión, adición, naturalidad, registro y coherencia multiformato. **Machine learning.** Rendimiento, calibración, validación temporal, coste de error, robustez, deriva y política. **Agentes.** Resultado, selección de herramientas, cumplimiento de políticas, estado, coste, latencia, recuperación y abstención. **Workflows.** Transición, durabilidad, reintentos, eventos, idempotencia, compensación y finalización. **Interfaces humanas.** Comprensión, carga, correcciones, tiempo, calidad de decisión y recurrencia. **Software.** Contratos, pruebas, disponibilidad, errores, seguridad y observabilidad. **Inteligencia Física.** Percepción, estimación, planificación, control, seguridad, verificación y recuperación. ## Evals representativas Un conjunto de evaluación debe representar el uso: casos habituales, casos difíciles, bordes, excepciones, datos incompletos, contradicciones, cambios de régimen, fallos, diferentes perfiles y consecuencias desiguales. Las evals se versionan junto a criterio, datos, respuestas de referencia, revisiones, severidad, cobertura y condiciones. Las métricas automáticas se complementan con revisión humana cuando la calidad depende de significado, criterio o contexto. ## Revisión adversarial La revisión adversarial intenta refutar la afirmación de que el sistema funciona. Pregunta: - ¿qué fuente parece pertinente y no sostiene la conclusión?; - ¿qué entrada plausible rompe el esquema?; - ¿qué permiso permite una acción indebida?; - ¿qué evento llega dos veces?; - ¿qué caso hace que una métrica agregada oculte un fallo?; - ¿qué frase es fluida y cambia el significado?; - ¿qué acción técnica correcta deja el resultado sin producir?; - ¿qué simulación excluye una tolerancia relevante?; - ¿qué excepción convertiría una regla en una mala política? Esta práctica descubre condiciones antes de que la operación las convierta en incidentes. ## Simulación La simulación permite reproducir cargas, eventos, fallos, secuencias, entornos, decisiones y operaciones físicas. Puede utilizarse para probar workflows, comparar políticas, examinar recuperación, estudiar sensibilidad, generar escenarios, validar control y preparar HIL. La simulación conserva sus supuestos. El resultado indica comportamiento dentro de esos supuestos. ## Observabilidad por trayectoria Las trazas se organizan por caso, pregunta, decisión u operación. Una traza puede relacionar: ```text ENTRADA ↓ FUENTES RECUPERADAS ↓ CONTEXTO ↓ MODELO Y VERSIÓN ↓ DECISIÓN ↓ HERRAMIENTA ↓ INTERVENCIÓN ↓ ACCIÓN ↓ RESULTADO ``` Cada evento incluye identificadores, tiempo, estado y versión. La observabilidad permite depurar, explicar, auditar, comparar, atribuir, recuperar y optimizar. Los datos sensibles se protegen mediante permisos, minimización y políticas de retención. ## Evidencia y trazabilidad Una explicación generada puede sonar convincente. La trazabilidad muestra el recorrido real. Conservamos qué información entró, qué regla se aplicó, qué modelo y configuración se utilizaron, qué herramienta actuó, qué persona decidió y qué resultado se observó. En inteligencia informacional, la afirmación se enlaza con la fuente. En inteligencia operacional, la acción se enlaza con el estado y con su efecto. ## Control de autoridad El sistema clasifica acciones por impacto, reversibilidad, sensibilidad, coste, riesgo y necesidad de autoridad. Los controles pueden incluir solo lectura, propuesta, simulación, shadow mode, confirmación, autorización, límites, doble control, ejecución acotada, parada y rollback. La autonomía crece por recorrido y acción, apoyada en evidencia de comportamiento. ## Gating y madurez Cada capacidad puede avanzar mediante gates. Ejemplo: ```text F0 — REPRESENTACIÓN VALIDADA F1 — PRUEBAS DETERMINISTAS F2 — EVAL REPRESENTATIVA F3 — CASOS ADVERSOS F4 — INTEGRACIÓN F5 — SHADOW MODE F6 — OPERACIÓN ACOTADA F7 — AMPLIACIÓN ``` El nombre y número pueden adaptarse a cada proyecto. El gate declara evidencia, criterio, resultado, excepciones, bloqueos y autoridad de aprobación. La madurez se comunica como estado y alcance. ## Recuperación El sistema prepara respuesta ante salida inválida, fuente ausente, permiso insuficiente, fallo de herramienta, duplicado, timeout, evento fuera de orden, inconsistencia, pérdida de percepción y resultado ambiguo. La recuperación puede reintentar, cambiar de ruta, solicitar información, reducir alcance, compensar, escalar, detener o conservar pendiente. La traza registra el fallo y el estado restante. ## Métricas operativas Además de calidad técnica, observamos tiempo total, tiempo de espera, coste, carga humana, reintentos, derivaciones, reaperturas, finalizaciones verificadas, disponibilidad, estabilidad, incidentes, adopción y mejora frente a baseline. Una métrica se interpreta junto al objetivo y las restricciones. ## Aprendizaje Los resultados pueden modificar datos, prompts, modelos, reglas, umbrales, herramientas, interfaces, rutas, permisos y evaluaciones. El cambio pasa por versión y prueba. Una excepción se conserva con contexto y se analiza por recurrencia, impacto y similitud antes de convertirse en regla. ## Cierre La confianza se construye haciendo visible el comportamiento y diseñando qué debe ocurrir cuando el sistema encuentra sus límites. --- https://www.3.14financialcontents.com/llms.txt · https://www.3.14financialcontents.com/llms-full.txt