Evidencia — Modelo de referencia de ingeniería
Arquitectura de inteligencia de decisión
Cómo convertir datos y modelos dispersos en decisiones en las que las personas realmente confían y sobre las que actúan — con la incertidumbre, la autoridad humana y el bucle de retroalimentación de resultados diseñados desde el principio, no añadidos después. Sus compensaciones, modos de fallo y límites incluidos.
Modelo de referencia de ingeniería
Una arquitectura de referencia, generalizada a partir de patrones de apoyo a la decisión. No es un producto ni trabajo de un cliente.
Propósito
Para qué sirve esta arquitectura.
Esta arquitectura convierte datos y modelos dispersos en decisiones en las que las personas realmente confían y sobre las que actúan, con la incertidumbre, la autoridad humana y el bucle de retroalimentación de resultados convertidos en partes explícitas del diseño en lugar de ideas tardías.
Cuándo es apropiada
- Decisiones repetidas de la misma naturaleza, donde los resultados pueden eventualmente observarse y medirse.
- Situaciones en las que una puntuación por sí sola no es suficiente; alguien debe ser responsable de la decisión con consecuencias.
- Operaciones que ya recopilan los datos de los que depende una decisión, o pueden empezar a hacerlo.
Arquitectura
Componentes, relaciones y límites.
Una decisión funciona como un bucle gobernado, no como una puntuación unidireccional. Cada componente tiene un rol definido, y el resultado vuelve para mejorar la siguiente decisión.
Bucle de decisión
Descripción textual de este diagrama
La decisión se ejecuta como un bucle gobernado:
- Entradas — las variables definidas de las que depende la decisión.
- Modelo + confianza — una respuesta con una confianza calibrada, no una simple suposición.
- Autoridad humana — una persona es responsable de las decisiones consecuentes o de baja confianza.
- Acción — se aplica la decisión.
- Resultado — el resultado se registra y se retroalimenta para mejorar el modelo.
Componentes
- Entradas y características
- Las señales definidas de las que depende una decisión, con su origen y actualidad conocidos.
- Modelo y reglas
- Los modelos producen estimaciones; reglas explícitas codifican las restricciones y la política que siempre deben cumplirse.
- Confianza calibrada
- Cada estimación lleva una confianza que se ha verificado contra la realidad, para que los casos de baja confianza puedan tratarse de forma diferente.
- Política de decisión
- Los umbrales y las bandas que convierten una estimación más su confianza en una acción o una escalada; propiedad de un humano, versionados y auditables.
- Autoridad humana
- Una persona posee las decisiones con consecuencias y de baja confianza, puede anular cualquiera de ellas, y establece los umbrales.
- Captura de resultados y retroalimentación
- La acción y su resultado posterior se registran y se retroalimentan para monitorizar la calidad y mejorar el modelo.
Límites de datos y autoridad
Los datos y la autoridad están acotados para que la decisión pueda gobernarse y su comportamiento no pueda desviarse sin ser detectado.
- El modelo que estima y la política de decisión que actúa se mantienen separados, de modo que los umbrales puedan cambiar sin reentrenamiento y revisarse por sí mismos.
- Solo los roles autorizados pueden cambiar los umbrales o anular decisiones, y cada uno de esos cambios se registra.
- Las entradas viven dentro de un límite de datos con acceso de mínimo privilegio; las características usadas en una decisión se registran para un examen posterior.
- Los resultados se capturan sin filtrar datos personales a lugares donde no deberían estar.
Autoridad humana
Dónde una persona permanece al mando.
El humano no es un simple sello al final. La autoridad y la capacidad de dar forma al sistema están diseñadas de antemano.
- Una persona posee las decisiones con consecuencias y toda decisión de baja confianza.
- Las personas fijan y revisan los umbrales de decisión; el sistema no mueve en silencio sus propias metas.
- Se esperan anulaciones, se registran con un motivo, y se usan como señal de que el modelo o los umbrales pueden necesitar atención.
- La interfaz muestra la incertidumbre y las razones detrás de una estimación, de modo que una decisión esté informada en lugar de delegada a un número.
Evaluación
Cómo se mide, y cómo se gestiona la incertidumbre.
Un sistema de decisión se juzga por la calidad de sus decisiones frente a resultados reales, no por una métrica de modelo aislada.
Qué se mide
- Calidad de la decisión frente a los resultados observados, una vez que se conocen.
- Calibración: ¿una confianza del 80 % significa tener razón aproximadamente el 80 % del tiempo?
- Precisión y exhaustividad en los umbrales elegidos, donde realmente se sitúa el punto de operación.
- Tasa de anulación y los resultados de las decisiones anuladas.
- La medida operativa o de negocio real que la decisión pretende mover.
Incertidumbre
La confianza está calibrada y se transporta hasta la política de decisión. Una estimación cuya confianza cae en una banda de abstención se escala a un humano en lugar de actuarse automáticamente. La incertidumbre se muestra a quien decide, no se oculta detrás de un único número.
Observabilidad
Las entradas, la estimación y su confianza, la decisión, y el resultado eventual se registran para que la deriva y la mala calibración sean detectables. La monitorización compara el comportamiento en vivo con la línea base de evaluación y activa una revisión cuando divergen.
Modos de fallo
Cómo falla, y qué se mantiene.
| Modo de fallo | Mitigación |
|---|---|
| Confianza mal calibrada | Medir la calibración explícitamente, recalibrar, y monitorizarla en operación; tratar el exceso de confianza como un defecto, no un detalle. |
| Filtración de retroalimentación o contaminación de etiquetas | Reservar los datos honestamente, esperar los resultados reales diferidos, y mantener el entrenamiento separado de la ruta de decisión en vivo. |
| Cambio de distribución | Vigilar las distribuciones de entrada y resultado, alarmar ante la deriva, y reevaluar según un calendario en lugar de suponer que el modelo de ayer sigue siendo válido. |
| Sesgo de automatización | Mostrar la incertidumbre y el razonamiento, exigir un motivo para las anulaciones, y revisar las decisiones donde los humanos siempre están de acuerdo con el modelo. |
| Optimizar un proxy en lugar del resultado real | Vincular la evaluación al resultado operativo real, y revisar la métrica cuando el proxy y el resultado diverjan. |
Alternativas rechazadas
Qué se consideró, y por qué no se eligió.
-
Automatizar por completo la decisión con consecuencias
Considerado Elimina el cuello de botella humano y es coherente.
Rechazado Nadie es responsable de una decisión errónea con consecuencias, y no hay autoridad para detenerla. La automatización se reserva para casos de baja consecuencia y alta confianza.
-
Una puntuación de caja negra sin confianza
Considerado Es sencilla de exponer e integrar.
Rechazado Sin confianza calibrada, la política de decisión no puede tratar de forma distinta los casos inciertos, y el sistema no puede gobernarse. En su lugar, la confianza se convierte en un elemento de primer nivel.
-
Un panel donde los humanos hacen todo
Considerado Mantiene a los humanos con control total.
Rechazado No escala y produce decisiones inconsistentes entre personas. El modelo gestiona lo rutinario y expone lo incierto, reservando a los humanos para el juicio.
-
Un motor de reglas puro
Considerado Es transparente y predecible.
Rechazado Es frágil donde los patrones son complejos y no puede aprender de los resultados. Sin embargo, donde las reglas realmente bastan, son la respuesta correcta (véase más abajo).
Despliegue y coste
Cómo se despliega, y qué determina su coste.
- Puntuación por lotes (batch)
- Decisiones calculadas según un calendario cuando la operación no necesita una respuesta instantánea; más simple y económica de operar.
- Puntuación en tiempo real
- Decisiones servidas a demanda cuando la operación necesita una respuesta en el momento, a un coste operativo más alto.
- Modo sombra primero
- El sistema funciona junto al proceso actual, con sus decisiones registradas pero no ejecutadas, hasta que la evaluación demuestra que es seguro otorgarle autoridad.
Coste operativo
El coste está determinado por el desarrollo y la validación del modelo, la infraestructura de monitorización y retroalimentación, y la revisión humana continua, no solo por la puntuación. Se describe de forma cualitativa; una estimación real depende del volumen de decisiones, las necesidades de latencia, y cuánta revisión humana exige la consecuencia.
Cuándo no usar esta arquitectura
Los límites, con honestidad.
- Cuando una regla simple o un informe claro ya produce la decisión correcta; no añadir ningún modelo.
- Cuando los resultados nunca pueden observarse, de modo que la decisión nunca puede evaluarse ni mejorarse.
- Cuando la decisión es rara o puntual; la inversión en evaluación y monitorización no se amortizará.
- Cuando los datos disponibles son demasiado escasos o demasiado sesgados para respaldar una estimación fiable; primero hay que corregir los datos.
Lo que esto demuestra y lo que no demuestra
Demuestra
- Que la incertidumbre y la autoridad humana pueden convertirse en partes de primer nivel de una arquitectura de decisión.
- Que el bucle de retroalimentación de resultados pertenece a la arquitectura, no a una fase posterior.
No demuestra
- Que un modelo alcance una precisión de decisión determinada.
- Que la automatización esté justificada para una decisión específica.
Cómo inspeccionarlo
Lea el diagrama de componentes y autoridad, el tratamiento de la incertidumbre y la retroalimentación, y la sección «cuándo una respuesta más simple es mejor».
Contratación
Empiece por lo que debe cambiar.
Si las decisiones son lentas o inciertas porque los datos y el juicio viven separados, un mandato comienza haciendo explícita la decisión, su incertidumbre y su autoridad.
También puede enviar una RFP, o solicitar un acuerdo de confidencialidad primero.