Compliance-Aware Retrieval-Augmented Generation per corpora di reporting finanziario regolamentato

In sintesi

Quattro modalità di fallimento del RAG ignaro della compliance

CARAG chiude F1–F3 strutturalmente e F4 probabilisticamente.

La pipeline CARAG a cinque stadi

1. 1

   Ingestion + etichettatura della policy

   Ogni chunk riceve un vettore di policy a 27 bit impacchettato in una parola macchina a 32 bit — derivato deterministicamente da campi metadata documentati. ~0,4% di overhead di storage a d=1024, fp16.

2. 2

   Indice metadata-aware (HNSW)

   Grafo hierarchical navigable small-world standard (M=32, efConstruction=200), con la bitmask di policy co-localizzata accanto a ciascun vettore per test di ammissibilità O(1) per candidato.

3. 3

   Inferenza della policy

   Mappa (query, ruolo utente, scopo della sessione) in una coppia di maschere (M_req, M_for) tramite un lookup deterministico ruolo-policy più un modulatore di sessione che applica raffinamenti query-condizionali come la deal-list attiva.

4. 4

   Retriever sensibile ai vincoli

   Test di ammissibilità bitwise valutato dentro il loop interno della traversata HNSW — prima che l'heap dei risultati venga aggiornato. L'espansione adattiva di ef preserva il recall sotto policy strette.

5. 5

   Generatore guardato + audit log Merkle-anchored

   Il generatore (Amazon Nova Micro) vede esplicitamente i bucket ammissibile e inammissibile ed è istruito a usare solo il primo. Ogni query produce un record append-only con ancoraggio Merkle sufficiente per l'Articolo 12 dell'AI Act europeo.

Risultati principali

Quattro sistemi sul benchmark di compliance SEC — n = 600 query, k = 8 chunk recuperati per query. CARAG ottiene il CVR e l'ODR più bassi sacrificando solo una piccola costante di token-F1.

Tabella 2, Sezione 6.1. CVR = Tasso di violazione dei vincoli, ODR = Tasso di disclosure dell'output. Il pre-filter (B2) raggiunge lo stesso pavimento CVR di CARAG ma al costo di un calo netto di F1 perché una partizione di ruolo statica è troppo grossolana per recuperare l'ammissibilità query-condizionale.

Dove vive il costo

Disaggregando per strato di query (loose / medium / tight) si rivela dove cade il costo architetturale della compliance. Sulle query loose — dove la policy ammette la maggior parte dei chunk rilevanti — l'F1 di CARAG segue da vicino la baseline vanilla. Il divario si allarga leggermente sulle query medium e si apre completamente sulle query tight, dove il set rilevante è genuinamente sparso.

Quello strato tight è anche dove CVR e ODR contano di più: ogni violazione è, per costruzione, semanticamente significativa — un chunk inammissibile contiene la risposta. Il costo si concentra esattamente dove la policy restringe sostanzialmente il set rilevante, non sulle query di due-diligence ordinarie.

Economia di produzione

Cosa significa per il tuo stack

Se gestisci un sistema RAG che tocca:

• →Giurisdizioni UE (GDPR Articoli 5, 6, 22 + AI Act Articoli 12–15)
• →Servizi finanziari (Reg FD, FINRA Rule 2241, SOX / PCAOB AS 2820)
• →Sanità (HIPAA, GDPR Articolo 9 dati di categoria speciale)
• →Residenza dati cross-border (UE/US/UK/CA/Altri)

…la compliance non è più qualcosa che puoi aggiungere a posteriori. La codifica bitmask di CARAG si retrofitta su un indice denso esistente in giorni, non mesi, e l'audit log è verificabile sotto l'Articolo 12 dell'AI Act europeo.

Cita questo lavoro

@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}
}