El problema fundamental que aborda este sistema es la necesidad de clasificar con precisión activos de datos heterogéneos y en constante cambio para aplicar políticas de privacidad, en un contexto donde la ambigüedad y el volumen de datos superan la capacidad de revisión manual. La tensión central radica en que la clasificación requiere razonamiento probabilístico (manejo de señales ruidosas y contexto distribuido), mientras que la aplicación de políticas exige decisiones deterministas, explicables y reproducibles. La solución propuesta es un patrón híbrido que utiliza LLMs para interpretar la novedad y la ambigüedad, y luego destila el conocimiento adquirido en reglas deterministas versionadas para la ejecución rutinaria, priorizando la calidad del contexto sobre la optimización de prompts y desacoplando la evaluación de la optimización.
La proliferación de productos 'AI-native' agrava este desafío al introducir nuevas modalidades de datos, ciclos de iteración más rápidos, y transformaciones de datos complejas (features derivadas, embeddings). Esto requiere que la clasificación siga el significado del dato, no solo su forma, a través de múltiples representaciones. El sistema busca resolver esta dicotomía, permitiendo que la infraestructura de privacidad (PAI) opere de manera efectiva y escalable, proporcionando la base para la comprensión, descubrimiento, aplicación y demostración de cumplimiento de políticas.
Arquitectura del Sistema
La arquitectura del sistema se basa en un 'decision funnel' que prioriza la ejecución determinista. Un 'asset classifier' actúa como un servicio de plataforma con un contrato explícito y estable, recibiendo un identificador de activo y un 'bundle' de contexto, y retornando una categoría, un 'confidence score' (calibrado), un 'decision trace', la regla que coincidió (si aplica) y la información de versión. Antes de la clasificación, se construye una 'context mesh' que agrega señales de diversas fuentes: resolución de código, metadatos de propiedad, anotaciones semánticas, señales de linaje, salidas de heurísticas de ML y resultados de búsqueda de código. Esta información se consolida en un 'evidence brief' que resume las señales de apoyo y contradicción, junto con la procedencia, para evitar que el LLM procese contexto ruidoso o redundante. Se aplica un invariante de enmascaramiento para evitar el razonamiento circular, donde el LLM no puede 'descubrir' la respuesta leyendo un campo que ya la contiene.
El 'decision funnel' tiene dos caminos principales: el primero es determinista, donde reglas versionadas y validadas resuelven la mayoría del tráfico (aproximadamente 85%) con baja latencia (milisegundos). Estas reglas se generan mediante un proceso de destilación que identifica patrones estables a partir de etiquetas revisadas y trazas de decisión. El segundo camino es LLM-based, utilizado como 'fallback' para el 15% restante de activos novedosos o ambiguos. Este camino es más lento (segundos) y costoso, y el LLM razona sobre el 'evidence brief' para proponer una etiqueta candidata. Ambos caminos emiten el mismo esquema de resultados. El 'learning loop' se mantiene seguro desacoplando la evaluación de la optimización: las etiquetas de referencia son revisadas por humanos y versionadas, mientras que la optimización de prompts y reglas se evalúa contra este conjunto de referencia independiente. Un 'multi-panel judge' (tres evaluaciones LLM independientes con diferentes estrategias de prompt) y métricas como el coeficiente de correlación de Matthews y F1 macro se utilizan para garantizar la calidad, especialmente en taxonomías desequilibradas. La destilación de reglas ocurre en etapas (reglas basadas en campos, reglas compuestas, generación de reglas asistida por LLM) y cada regla candidata pasa por validación estricta (conjuntos de prueba, 'shadow mode', revisión humana) antes de ser promovida a producción sin dependencia del LLM. La gestión de versiones de reglas y prompts se realiza con semántica 'compare-and-swap' para garantizar la atomicidad y la auditabilidad.
Flujo de Clasificación de Activos Híbrido
- 1 Solicitud de Clasificación El sistema recibe un identificador de activo y solicita su clasificación.
- 2 Construcción de Context Mesh Se agregan señales de código, linaje, propiedad, anotaciones semánticas, etc.
- 3 Generación de Evidence Brief Se crea un resumen compacto de señales de apoyo/contradicción, aplicando enma...
- 4 Decision Funnel: Reglas Deterministas Se intenta clasificar el activo usando reglas versionadas y validadas (85% de...
- 5 Decision Funnel: LLM (Fallback) Si no hay regla, el LLM razona sobre el Evidence Brief (15% de tráfico, ambig...
- 6 Emisión de Resultado Se devuelve categoría, confianza, traza de decisión y metadatos de versión.
Ciclo de Aprendizaje y Destilación de Reglas
- 1 Recolección de Etiquetas El sistema recolecta etiquetas generadas por el modelo y revisadas por humanos.
- 2 Bucle de Referencia Humanos adjudican casos inciertos, creando etiquetas de referencia versionadas.
- 3 Bucle de Optimización Se mejoran prompts, enrutamiento y uso de contexto, evaluando contra el bucle...
- 4 Propuesta de Reglas Candidatas Se identifican patrones estables a partir de etiquetas y trazas de decisión.
- 5 Validación de Reglas Las reglas se prueban en conjuntos de prueba, 'shadow mode' y revisión humana.
- 6 Promoción de Reglas Las reglas validadas se despliegan como lógica determinista sin LLM.
| Capa | Tecnología | Justificación |
|---|---|---|
| data-processing | LLMs | Manejo de ambigüedad, 'cold start' y patrones novedosos en la clasificación de activos. Razonamiento sobre 'evidence briefs'. vs modelos de ML tradicionales (ej. clasificadores basados en árboles, SVM), reglas heurísticas manuales Uso de un 'judge model' más grande y diferente del 'classifier model' para evaluación independiente. |
| data-processing | Reglas Deterministas | Ejecución de clasificación de alta velocidad y bajo costo para patrones estables y rutinarios, resultantes de la destilación del conocimiento del LLM. vs dependencia exclusiva de LLMs para todas las decisiones Versionado inmutable de reglas y activación vía 'compare-and-swap' para auditabilidad. |
| storage | Sistema de Versionado | Almacenamiento y gestión de versiones de reglas, prompts, contexto y etiquetas de referencia para reproducibilidad y auditabilidad. vs almacenamiento de versiones implícito o no estructurado Etiquetas de referencia 'append-only' con proveniencia. |
| observability | Métricas de Evaluación | Monitoreo de la calidad del clasificador, incluyendo Matthews correlation coefficient, macro F1, recall por clase, balanced accuracy y calibración de confianza, especialmente para taxonomías desequilibradas. vs solo precisión general Uso de Cohen's kappa para medir el acuerdo entre jueces LLM. |
| orchestration | Tuning Controller | Sistema de auto-regulación que gestiona el ciclo de optimización, deteniendo o ralentizando el proceso ante problemas de calidad o estancamiento. vs intervención manual constante, optimización continua sin frenos Estados como Observing, Maintaining, Conserving, Pausing, Diagnosing. |
Trade-offs
Ganancias
- ▲ Precisión de clasificación
- ▲ Auditabilidad y reproducibilidad
- ▲ Eficiencia y latencia en producción
- ▲ Escalabilidad para volumen de datos
- ▲ Manejo de ambigüedad y 'cold start'
Costes
- △ Complejidad del sistema
- ▲ Costo computacional para casos LLM
- ▲ Latencia para casos LLM
# Shared scaffold (all three judges)
INPUT = masked_evidence_brief # pre-existing privacy label removed; masking invariant holds
OUTPUT = {label, rationale, confidence}
JUDGE_MODEL = larger reasoning model, deliberately != classifier model
# V1 - direct-from-evidence
verdict_1 = judge(brief, instruction="Classify the asset directly from the evidence.")
# V2 - critique-then-classify
verdict_2 = judge(brief, instruction="First critique the supporting and contradicting signals, then classify.")
# V3 - metadata-only
verdict_3 = judge(brief, instruction="Use ONLY metadata signals (on-call, lineage, semantic annotations). Ignore names and descriptions.")
# Aggregate
final_label = majority_vote(verdict_1, verdict_2, verdict_3)
Agreement = cohens_kappa(verdict_1, verdict_2, verdict_3) # inter-rater reliabilityFundamentos Teóricos
El problema de la clasificación de datos y la aplicación de políticas en sistemas distribuidos a gran escala se relaciona con principios fundamentales de la computación y la seguridad de la información. La necesidad de decisiones deterministas y auditables en un entorno probabilístico evoca los desafíos de la consistencia en sistemas distribuidos, donde algoritmos de consenso como Paxos o Raft buscan garantizar un estado único y acordado a pesar de fallos o ambigüedad. La distinción entre el razonamiento probabilístico de los LLMs y la ejecución determinista de las reglas se alinea con el concepto de 'probabilistic programming' o 'statistical relational learning', donde modelos probabilísticos se utilizan para inferir relaciones o clasificaciones que luego pueden ser utilizadas por sistemas lógicos o basados en reglas para la toma de decisiones. La gestión de la calidad del contexto y la reducción de ruido antes de la inferencia del modelo se relaciona con la ingeniería de características ('feature engineering') y la 'data provenance', conceptos clave en el aprendizaje automático y las bases de datos. La importancia de las métricas de evaluación para taxonomías desequilibradas, como el coeficiente de correlación de Matthews o F1 macro, es un tema recurrente en la literatura de aprendizaje automático, destacando la insuficiencia de la precisión simple en escenarios del mundo real. Finalmente, la idea de destilar el conocimiento de un modelo complejo en reglas más simples y ejecutables tiene paralelos con el campo de la 'explainable AI' (XAI) y la 'model distillation', donde se busca hacer los modelos más transparentes y eficientes para la inferencia en producción.