Filtri di metadati RAG per chatbot AI: separare lingua, versione e accesso

Un chatbot AI può trovare passaggi di testo semanticamente molto simili e preparare comunque la risposta sbagliata: le istruzioni in inglese anziché quelle in italiano, la documentazione della versione precedente anziché quella attuale o note interne per un ospite senza autorizzazione. Il ranking in questi casi non è necessariamente scadente. È lo spazio di ricerca a essere errato.

I filtri di metadati RAG risolvono esattamente questo problema. Delimitano prima o durante la ricerca quali documenti e chunk possono essere presi in considerazione come contesto. La rilevanza risponde poi alla domanda "Cosa si adatta meglio a livello di contenuto?". Il filtro risponde prima a "Cosa è consentito e opportuno considerare in questa situazione?".

Perché la sola similarità non è un ambito affidabile

La ricerca vettoriale e ibrida ordina i contenuti in base alla vicinanza linguistica o semantica. Un manuale per la versione 4 del prodotto può risultare estremamente simile a una domanda sulla versione 5. Un listino prezzi per un altro mercato può contenere gli stessi nomi di prodotto. E un documento di supporto interno può fornire una risposta più precisa rispetto alle FAQ pubbliche, anche se non dovrebbe mai apparire in una chat pubblica.

Per questo motivo il retriever dovrebbe distinguere nettamente due tipi di condizioni:

• Confini rigidi come tenant, ruolo, stato di pubblicazione o ambito dati consentito. In presenza di un valore sconosciuto, la ricerca deve rimanere chiusa.
• Criteri di selezione di dominio come lingua, famiglia di prodotti, versione, regione o periodo di validità. Aumentano la precisione ed evitano contesti contraddittori.

L'attuale panoramica OWASP per le applicazioni LLM attribuisce esplicitamente i rischi legati a vettori ed embedding al confine di fiducia di un'applicazione AI. Si tratta di una prospettiva fondamentale: un controllo di autenticazione prima della chat non basta se la successiva ricerca per similarità opera comunque su un indice troppo ampio.

Uno schema di metadati efficace nella pratica quotidiana

Filtri efficaci non iniziano con una query complessa, ma con pochi campi canonici. Per molti chatbot web sono sufficienti sei gruppi:

• Lingua e mercato: ad esempio locale e market, con valori definiti anziché testo libero.
• Prodotto e versione: ID prodotto stabile, intervallo di versioni ed eventualmente piattaforma o piano.
• Validità: stato di approvazione, valido dal, valido al e una versione univoca della fonte.
• Pubblico di destinazione: pubblico, cliente, partner o team interno – separato dalla verifica effettiva dei ruoli.
• Ambito di accesso: tenant, gruppo o principal, ricavati esclusivamente dal contesto del server verificato.
• Origine: ID origine, URL, tipo di documento e area di contenuto responsabile per garantire la tracciabilità.

I metadati appartengono al livello in cui viene eseguita la ricerca. Se un documento viene suddiviso in chunk, i campi chiave dell'ambito devono essere trasferiti in modo affidabile a ciascun chunk. Altrimenti un documento può essere classificato correttamente, mentre i singoli risultati di ricerca perdono questa classificazione. La documentazione di OpenAI su File Search mostra, ad esempio, come utilizzare gli attributi dei file per i filtri di metadati. La riferimento di Amazon Bedrock documenta operatori di confronto, elenco e intervallo per la medesima idea di fondo.

Non lasciare mai autorizzare i filtri al modello linguistico

Un modello può ricavare dalla domanda indicazioni come la lingua o il riferimento al prodotto. Non deve tuttavia decidere a quale tenant appartenga una persona o quali ruoli possieda. Questi valori devono provenire dalla sessione, dal sistema di identità e dalle regole aziendali lato server. Inoltre, una stringa di filtro generata dal modello non dovrebbe essere trasmessa senza verifica al servizio di ricerca.

Un flusso robusto è strutturato come segue:

1. Il server autentica la richiesta e determina l'ambito dei dati consentiti.
2. Regole deterministiche impostano i campi rigidi come tenant, ruolo e stato di pubblicazione.
3. Le caratteristiche rilevate come lingua o prodotto vengono convalidate rispetto ai valori consentiti.
4. Il retriever esegue solo una struttura di filtro tipizzata e parametrizzata.
5. L'applicazione verifica nuovamente le fonti restituite rispetto all'ambito previsto.
6. In caso di contesto mancante o contraddittorio, il chatbot chiede chiarimenti o restituisce un fallback sicuro.

La documentazione Microsoft sui Security Filters evidenzia una distinzione utile: un principal nel filtro è inizialmente solo un valore. Autenticazione e autorizzazione devono avvenire in modo affidabile all'esterno dell'espressione di ricerca. Per i portali clienti, il nostro articolo sulla separazione tra chatbot AI pubblico e autenticato approfondisce questa distinzione.

Pre-filtering o Post-filtering?

La posizione del filtro influisce sulla qualità e sui tempi di esecuzione. Un pre-filtro delimita i candidati già durante la ricerca vettoriale. Un post-filtro effettua inizialmente una ricerca più ampia e rimuove successivamente i risultati non consentiti. Secondo la documentazione Azure sui filtri vettoriali, il post-filtering con filtri selettivi e valori bassi di k può trascurare risultati pertinenti; il pre-filtering privilegia il recall nel sottoinsieme consentito, ma con filtri molto restrittivi può richiedere un carico computazionale maggiore.

Per i limiti di accesso rigidi, il modello "cerca prima in modo ampio, nascondi dopo" non è un approccio adeguato. L'ambito autorizzato deve essere imposto all'interno della query di ricerca. Per i filtri di puro dominio, un team può misurare le varianti pre e post. In questo caso non conta solo il tempo medio di risposta, ma anche quante volte un risultato presente e consentito viene omesso a causa dell'ordine scelto.

I filtri non sostituiscono il ranking. All'interno del corpus consentito, la Hybrid Search e il Reranking possono continuare a dare priorità alle fonti migliori. La sequenza è quindi: definire l'ambito, recuperare i candidati, valutare la rilevanza, verificare le fonti, generare la risposta.

Quattro casi di filtraggio tipici

Lingua con fallback consapevole

Per una domanda in italiano, il primo recupero dovrebbe selezionare contenuti in italiano approvati. Se non viene trovato alcun risultato, l'applicazione non deve mescolare silenziosamente più lingue. Un secondo percorso esplicito può ricadere su una lingua di base approvata e segnalare questa condizione nella risposta. Una Locale-QA per basi di conoscenza multilingue verifica inoltre se le varianti sono davvero equivalenti a livello di contenuto.

Versione del prodotto e validità temporale

Una fonte non dovrebbe apparire aggiornata solo perché è stata scansionata di recente. Determinanti sono la versione e l'approvazione a livello di dominio. Contrassegnate i contenuti con un ID prodotto stabile, intervallo di versioni, valid_from, valid_until e stato. In caso di approvazioni sovrapposte, la pipeline deve segnalare un conflitto anziché inserire entrambi i testi nello stesso prompt. Il modo in cui la frequenza di scansione e la gestione delle fonti interagiscono è descritto nella guida su come mantenere aggiornata la base di conoscenza del chatbot AI.

Tenant e ruolo

In caso di indice condiviso, ogni query deve includere il tenant e i principal validi determinati lato server. La mancanza di metadati ACL significa "non recuperabile", non "pubblico". Dopo un cambio di ruolo o la revoca di un'autorizzazione, un test deve dimostrare che le vecchie sessioni non ricevano più chunk precedentemente consentiti.

Supporto pubblico e istruzioni operative interne

Un'istruzione di escalation interna può adattarsi perfettamente a livello tecnico a una richiesta del cliente. Questo non la rende una fonte consentita. Separate l'ambito di pubblicazione dal tipo di documento; contrassegnate i contenuti non approvati come esclusi di default. Un bot pubblico dovrebbe, in caso di dubbio, passare a un percorso di contatto o handoff anziché tirare a indovinare dettagli interni.

Gli errori di implementazione più frequenti

• Tassonomia a testo libero: valori come it, IT e it-IT formano involontariamente tre gruppi distinti.
• Default-open: i chunk privi di ruolo, stato o tenant finiscono in qualsiasi spazio di ricerca.
• Logica booleana errata: un OR tra tenant e lingua annulla praticamente il confine rigido.
• Drift tra documento e chunk: durante la reindicizzazione, i nuovi metadati non vengono trasferiti a tutti i chunk.
• Solo test positivi: il team verifica se un documento consentito appare, ma non se un documento vietato con formulazione simile viene effettivamente escluso.
• Risultati vuoti gestiti come problema del modello: un filtro restrittivo non restituisce nulla e l'applicazione lascia che il modello continui a rispondere senza fonti.

QA dei filtri: testare i confini, non solo i risultati

Un set di test adeguato contiene per ogni risposta prevista almeno un contro-candidato simile: lingua errata, vecchia versione, approvazione scaduta, altro tenant o pubblico di destinazione interno. In questo modo il test dimostra se il filtro separa davvero o se si limita a posizionare casualmente in cima il risultato corretto.

I metriche chiave includono il tasso di violazione dell'ambito, il recall nel sottoinsieme consentito, la percentuale di retrieval vuoti, il numero di valori di metadati sconosciuti, la latenza del filtro al 95° percentile nonché la quota di fallback e domande di chiarimento. Per i contenuti con restrizioni, il tasso di violazione dell'ambito tollerato deve essere pari a zero. Il NIST AI RMF Core raccomanda di testare i sistemi di AI prima dell'impiego e regolarmente durante l'uso, documentando i limiti di sicurezza, affidabilità e contesto.

A questo scopo non registrate contenuti non necessari o domande complete degli utenti. Di solito sono sufficienti versione del filtro, ambito astratto, numero di candidati, ID delle fonti selezionate, motivo del rifiuto ed esito del post-check. In questo modo la ricerca degli errori rimane possibile senza creare un secondo data leak nel sistema di osservabilità.

Checklist pratica prima del rilascio

1. Documentare i campi di metadati canonici, i tipi di dati, i valori consentiti e i proprietari.
2. Separare i confini di accesso rigidi dai campi di selezione di dominio.
3. Trattare rigorosamente i valori rilevanti per la sicurezza mancanti come non autorizzati.
4. Costruire i filtri a partire dal contesto del server verificato e parametrizzare gli input.
5. Rileggere a campione i metadati dopo l'ingestione e il chunking.
6. Testare casi positivi, negativi, limite e di revoca rispetto all'indice reale.
7. Misurare il comportamento dei pre/post-filtri con valori realistici di k e ambiti selettivi.
8. Indirizzare i risultati vuoti verso una domanda di chiarimento, un fallback sicuro o l'handoff umano.
9. Versionare le modifiche ai filtri e rilasciarle insieme a test di regressione del retrieval.

I filtri di metadati RAG sono quindi molto più di una funzionalità di comodità della ricerca. Rappresentano il collegamento tra modello di contenuto, identità, attualità e qualità del retrieval. Chi definisce prima l'ambito in modo deterministico offre al ranking e al modello linguistico una base di lavoro più piccola, pulita e verificabile.

Passo successivo: Scegliete una richiesta di supporto reale e create cinque contro-fonti quasi pertinenti provenienti da lingua, versione e autorizzazione errate. Solo quando nessuna di esse supera l'ambito di retrieval consentito, il filtro può essere integrato nel flusso di chat in produzione.

Fonti

• OpenAI: File Search e Metadata Filtering
• Microsoft: Filtri nelle query vettoriali
• Microsoft: Security Filter Pattern
• Amazon Bedrock: API RetrievalFilter
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026