Filtre de metadate RAG pentru chatbots IA: separarea limbii, versiunii și accesului

Un chatbot IA poate găsi fragmente de text foarte similare din punct de vedere semantic și totuși să pregătească un răspuns greșit: instrucțiunile în engleză în loc de cele în română, documentația unei versiuni anterioare în loc de cea curentă sau note interne destinate unui vizitator fără autorizație. În acest caz, clasamentul (ranking-ul) nu este neapărat slab. Spațiul de căutare a fost greșit.

Filtrele de metadate RAG rezolvă exact această problemă. Ele limitează, înainte sau în timpul căutării, ce documente și fragmente (chunks) pot fi luate în considerare ca context. Relevanța răspunde apoi la întrebarea „Ce se potrivește cel mai bine din punct de vedere al conținutului?”. În schimb, filtrul răspunde mai întâi la întrebarea „Ce are voie și ce ar trebui să fie luat în considerare în această situație?”.

De ce similitudinea nu este, de una singură, un domeniu de aplicare de încredere

Căutarea vectorială și hibridă ordonează conținutul după proximitatea lingvistică sau semantică. Un manual pentru versiunea 4 a unui produs poate fi extrem de similar cu o întrebare despre versiunea 5. O listă de prețuri pentru o altă piață poate conține aceleași nume de produse. Iar un document intern de suport poate oferi un răspuns mai precis decât FAQ-ul public, deși nu ar trebui să apară niciodată într-un chat public.

De aceea, modulul de căutare (retriever) ar trebui să facă diferența între două tipuri de condiții:

• Linii roșii (limite stricte) precum tenantul, rolul, statusul de publicare sau domeniul de date permis. În cazul unei valori necunoscute, căutarea trebuie să rămână închisă.
• Criterii de selecție funcționale precum limba, familia de produse, versiunea, regiunea sau perioada de valabilitate. Acestea cresc precizia și previn inserarea de contexte contradictorii.

Ghidul actual OWASP pentru aplicații LLM atribuie în mod explicit riscurile legate de vectori și embeddings limitei de încredere (trust boundary) a unei aplicații IA. Aceasta este o perspectivă importantă: o verificare de autentificare înaintea chatului nu este suficientă dacă căutarea ulterioară pe bază de similitudine rulează pe un index mult prea larg.

Un schemă de metadate viabilă în activitatea de zi cu zi

Filtrele bune nu încep cu o interogare lungă, ci cu câteva câmpuri canonice. Pentru mulți chatbots de pe site-urile web sunt suficiente șase grupuri:

• Limbă și piață: de exemplu locale și market, cu valori strict definite în loc de text liber.
• Produs și versiune: ID de produs stabil, interval de versiuni și opțional platforma sau tariful.
• Valabilitate: status de aprobare, valabil de la, valabil până la și o versiune clară a sursei.
• Grup țintă: public, client, partener sau echipă internă – separat de verificarea efectivă a rolurilor.
• Domeniu de acces: tenant, grup sau principal, exclusiv din contextul verificat al serverului.
• Origine: ID-ul sursei, URL, tipul de document și domeniul de conținut responsabil pentru trasabilitate.

Metadatele aparțin nivelului la care se efectuează căutarea. Dacă un document este împărțit în fragmente (chunks), câmpurile decisive ale domeniului de aplicare trebuie să ajungă în mod fiabil pe fiecare fragment. Altfel, un document poate fi clasificat corect, în timp ce rezultatele individuale ale căutării pierd această încadrare. Documentația OpenAI File Search arată, de exemplu, cum sunt utilizate atributele fișierelor pentru filtrarea metadatelor. Ghidul de referință Amazon Bedrock documentează operatorii de comparație, listă și interval pentru aceeași idee de bază.

Nu lăsați niciodată modelul de limbaj să autorizeze filtrele

Un model poate deduce indicii precum limba sau referința la un produs din întrebarea utilizatorului. Totuși, el nu are voie să decidă din ce tenant face parte o persoană sau ce rol are aceasta. Aceste valori trebuie să provină din sesiune, din sistemul de identitate și din regulile de business de pe server. De asemenea, un șir de filtrare generat de model nu ar trebui transmis neverificat către serviciul de căutare.

Un flux robust arată astfel:

1. Serverul autentifică cererea și determină domeniul de date permis.
2. Regulile deterministe fixează câmpurile stricte precum tenantul, rolul și statusul publicării.
3. Caracteristicile detectate, cum ar fi limba sau produsul, sunt validate comparativ cu valorile permise.
4. Modulul de căutare (retriever) execută doar o structură de filtrare tipizată și parametrizată.
5. Aplicația verifică din nou sursele returnate pentru a se asigura că respectă domeniul de aplicare așteptat.
6. În cazul în care contextul lipsește sau este contradictoriu, chatbotul cere clarificări sau oferă o alternativă de rezervă (fallback) sigură.

Documentația Microsoft Security Filters face o distincție utilă: un principal din filtru este inițial doar o valoare. Autentificarea și autorizarea trebuie să aibă loc în mod fiabil în afara expresiei de căutare. Pentru portalurile de clienți, articolul nostru despre separarea chatbotului IA public de cel autentificat aprofundează această delimitare.

Pre-filtrare sau post-filtrare?

Poziția filtrului influențează calitatea și timpul de execuție. O pre-filtrare limitează candidații încă din timpul căutării vectoriale. O post-filtrare caută mai întâi mai larg și elimină ulterior rezultatele nepermise. Conform documentației Azure Vector Filters, post-filtrarea poate rata rezultate potrivite în cazul filtrelor selective și al unui k mic; pre-filtrarea favorizează rata de recuperare (recall) în subsetul permis, dar poate genera un cost de calcul mai mare în cazul filtrelor foarte restrânse.

Pentru limitele stricte de acces, abordarea „caută mai întâi larg, ascunde după aceea” nu este un model de bază adecvat. Domeniul autorizat trebuie impus în interiorul interogării de căutare. Pentru filtrele pur tehnice sau de business, o echipă poate măsura variantele de pre- și post-filtrare. Ceea ce contează nu este doar timpul mediu de răspuns, ci și cât de des un rezultat existent și permis lipsește din cauza ordinii alese.

Filtrele nu înlocuiesc clasamentul (ranking-ul). În cadrul corpusului permis, Hybrid Search și Reranking pot continua să prioritizeze cele mai bune surse. Prin urmare, ordinea este: definirea domeniului de aplicare, preluarea candidaților, evaluarea relevanței, verificarea surselor, generarea răspunsului.

Patru cazuri tipice de filtrare

Limbă cu fallback intenționat

Pentru o întrebare în română, prima căutare ar trebui să selecteze conținut aprobat în limba română. Dacă nu există niciun rezultat, aplicația nu ar trebui să amestece în mod silențios mai multe limbi. Calea secundară, definită explicit, poate reveni la o limbă de bază aprobată și poate semnala acest lucru în răspuns. O verificare de tip Locale-QA pentru baze de cunoștințe multilingve testează suplimentar dacă variantele sunt într-adevăr echivalente din punct de vedere al conținutului.

Versiunea produsului și valabilitatea temporală

O sursă nu ar trebui să pară de actualitate doar pentru că a fost scanată (crawled) recent. Decisive sunt versiunea tehnică și aprobarea. Marcați conținutul cu ID-ul stabil al produsului, intervalul de versiuni, valid_from, valid_until și statusul. În cazul unor aprobări care se suprapun, fluxul de date trebuie să raporteze un conflict în loc să plaseze ambele texte în același prompt. Modul în care interacționează cadența de scanare și întreținerea surselor este descris în ghidul privind actualizarea bazei de cunoștințe a chatbotului IA.

Tenant și rol

În cazul unui index comun, fiecare interogare trebuie să conțină tenantul determinat pe server și principalii valabili. Lipsa metadatelor ACL înseamnă „inaccesibil”, nu „public”. După schimbarea rolului sau revocarea unei autorizații, un test trebuie să arate că sesiunile vechi nu mai primesc fragmente care erau permise anterior.

Suport public și instrucțiuni interne de lucru

O instrucțiune internă de escaladare se poate potrivi perfect din punct de vedere tehnic cu întrebarea unui client. Acest lucru nu o face o sursă permisă. Separați domeniul de publicare de tipul de document; marcați conținutul neaprobat ca fiind exclus în mod implicit. Un bot public ar trebui, în caz de dubiu, să treacă la o cale de contact sau preluare de către un operator uman (handoff), în loc să ghicească detalii interne.

Cele mai frecvente erori de implementare

• Taxonomie în text liber: Valori precum ro, RO și ro-RO formează neintenționat trei grupuri diferite.
• Deschis implicit (Default-open): Fragmentele fără rol, status sau tenant ajung în orice spațiu de căutare.
• Logică booleană greșită: Un operator OR între tenant și limbă anulează practic limita strictă de acces.
• Deriva dintre document și fragment (Chunk Drift): La re-indexare, metadatele noi nu sunt transferate tuturor fragmentelor.
• Doar teste pozitive: Echipa verifică dacă apare un document permis, dar nu și dacă un document interzis care sună similar este exclus cu siguranță.
• Rezultatele goale tratate ca o problemă a modelului: Un filtru restrâns nu returnează nimic, iar aplicația lasă modelul să răspundă în continuare fără surse.

QA pentru filtre: testați limitele, nu doar rezultatele

Un set de testare adecvat conține, pentru fiecare răspuns așteptat, cel puțin un contra-candidat apropiat: limbă greșită, versiune veche, aprobare expirată, alt tenant sau grup țintă intern. Astfel, testul arată dacă filtrul separă într-adevăr conținutul și nu doar plasează aleatoriu rezultatul corect în top.

Indicatorii cheie de performanță (KPI) importanți sunt rata de încălcare a domeniului de aplicare (scope violation rate), recall-ul în subsetul permis, ponderea căutărilor goale, numărul de valori necunoscute ale metadatelor, latența filtrului la percentila 95, precum și ponderea fallback-urilor și a întrebărilor de clarificare. Pentru conținutul restricționat, rata tolerată de încălcare a domeniului trebuie să fie zero. Cadrul de lucru NIST AI RMF Core recomandă testarea sistemelor IA înainte de implementare și regulat în producție, precum și documentarea limitelor de securitate, fiabilitate și context.

Pentru aceasta, nu jurnațizați conținut inutil sau întrebări complete ale utilizatorilor. În cele mai multe cazuri sunt suficiente versiunea filtrului, domeniul abstract, numărul de candidați, ID-urile surselor selectate, motivul respingerii și rezultatul post-verificării. În acest fel, depanarea rămâne posibilă fără a crea o a doua scurgere de date în sistemul de observabilitate.

Listă de verificare practică înainte de lansare

1. Documentați câmpurile canonice de metadate, tipurile de date, valorile permise și responsabilii.
2. Separați limitele stricte de acces de câmpurile funcționale de selecție.
3. Tratați consecvent valorile lipsă relevante pentru securitate ca fiind neautorizate.
4. Construiți filtrele din contextul verificat al serverului și parametrizați datele de intrare.
5. Recitiți prin sondaj metadatele după procesul de ingestie și fragmentare (chunking).
6. Testați cazurile pozitive, negative, de limită și de revocare pe indexul real.
7. Măsurați comportamentul de pre-/post-filtrare cu o valoare realistă a lui k și domenii selective.
8. Direcționați rezultatele goale către o întrebare de clarificare, un fallback sigur sau o preluare de către un operator uman.
9. Versionați modificările de filtre și lansați-le împreună cu teste de regresie pentru căutare.

Filtrele de metadate RAG sunt astfel mai mult decât o caracteristică de confort a căutării. Ele reprezintă legătura dintre modelul de conținut, identitate, actualitate și calitatea căutării. Cine stabilește mai întâi domeniul de aplicare în mod determinist oferă clasamentului și modelului de limbaj o bază de lucru mai mică, mai curată și ușor de verificat.

Pasul următor: Alegeți o întrebare reală de suport și construiți pentru ea cinci contra-surse aproape potrivite din limba, versiunea și autorizația greșite. Abia când niciuna dintre ele nu depășește domeniul de căutare permis, filtrul ar trebui integrat în fluxul de chat din producție.

Surse

• OpenAI: File Search și Metadata Filtering
• Microsoft: Filtre în interogări vectoriale
• Microsoft: Pattern pentru filtre de securitate
• Amazon Bedrock: RetrievalFilter API
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026