Génération augmentée par récupération sensible à la conformité pour les corpus de reporting financier réglementé

En bref

Quatre modes d'échec du RAG ignorant de la conformité

CARAG ferme F1–F3 structurellement et F4 probabilistiquement.

La pipeline CARAG en cinq étapes

1. 1

   Ingestion + étiquetage de politique

   Chaque chunk reçoit un vecteur de politique 27 bits empaqueté dans un mot machine 32 bits — dérivé déterministiquement de champs metadata documentés. ~0,4 % de surcoût de stockage à d=1024, fp16.

2. 2

   Index sensible aux metadata (HNSW)

   Graphe hierarchical navigable small-world standard (M=32, efConstruction=200), avec la bitmask de politique co-localisée à côté de chaque vecteur pour des tests d'admissibilité O(1) par candidat.

3. 3

   Inférence de politique

   Mappe (requête, rôle utilisateur, finalité de session) vers une paire de masques (M_req, M_for) via un lookup déterministique rôle-politique plus un modulateur de session qui applique des raffinements query-conditionnels comme la deal-list active.

4. 4

   Récupérateur sensible aux contraintes

   Test d'admissibilité bitwise évalué dans la boucle interne du parcours HNSW — avant que le heap des résultats soit mis à jour. L'expansion adaptative d'ef préserve le rappel sous des politiques strictes.

5. 5

   Générateur gardé + journal d'audit ancré Merkle

   Le générateur (Amazon Nova Micro) voit explicitement les buckets admissible et inadmissible et est instruit de ne tirer que du premier. Chaque requête produit un enregistrement append-only ancré Merkle suffisant pour l'Article 12 de l'AI Act européen.

Résultats principaux

Quatre systèmes sur le benchmark de conformité SEC — n = 600 requêtes, k = 8 chunks récupérés par requête. CARAG atteint le CVR et l'ODR les plus bas en sacrifiant seulement une petite constante de token-F1.

Tableau 2, Section 6.1. CVR = Taux de Violation de Contraintes, ODR = Taux de Divulgation en Sortie. Le pré-filtre (B2) atteint le même plancher CVR que CARAG mais au prix d'une chute nette du F1 car une partition de rôle statique est trop grossière pour récupérer l'admissibilité query-conditionnelle.

Où réside le coût

Désagréger par strate de requête (loose / medium / tight) révèle où tombe le coût architectural de la conformité. Sur les requêtes loose — où la politique admet la majorité des chunks pertinents — le F1 de CARAG suit de près la baseline vanilla. L'écart se creuse légèrement sur les requêtes medium et s'ouvre pleinement sur les requêtes tight, où l'ensemble pertinent est véritablement clairsemé.

Cette strate tight est aussi celle où CVR et ODR comptent le plus : chaque violation est, par construction, sémantiquement significative — un chunk inadmissible contient la réponse. Le coût se concentre exactement là où la politique restreint substantiellement l'ensemble pertinent, pas sur les requêtes de due-diligence routinières.

Économie de production

Ce que cela signifie pour votre stack

Si vous opérez un système RAG qui touche :

• →Juridictions UE (RGPD Articles 5, 6, 22 + AI Act Articles 12–15)
• →Services financiers (Reg FD, FINRA Rule 2241, SOX / PCAOB AS 2820)
• →Santé (HIPAA, RGPD Article 9 données de catégorie spéciale)
• →Résidence transfrontalière des données (UE/US/UK/CA/Autres)

…la conformité n'est plus quelque chose que vous pouvez ajouter après coup. L'encodage bitmask de CARAG se retrofitte sur un index dense existant en jours, pas en mois, et le journal d'audit est vérifiable sous l'Article 12 de l'AI Act européen.

Citer ce travail

@techreport{bhardwaj2026carag,
  author      = {Bhardwaj, Aru},
  title       = {Compliance-Aware Retrieval-Augmented Generation
                 for Regulated Financial-Reporting Corpora:
                 A Real-World Evaluation on SEC EDGAR Filings},
  institution = {Insightrix},
  year        = {2026},
  type        = {Working Draft},
  address     = {Paris, France},
  url         = {https://arubhardwaj.eu/research/compliance-aware-rag-sec-edgar}
}