NOTĂ TEHNICĂ · SECURITATE RAG
Securitate LLM și RAG: plan de control semantic și rutare dual-LLM
O notă tehnică despre separarea deciziei de acces de generatorul principal într-un pipeline RAG, cu limite explicite pentru atacuri indirecte, riscuri la ingestie și acțiuni externe.
Termeni operaționali utilizați în notă
Termenii de mai jos sunt folosiți operațional în această notă. Ei nu sunt definiții universale, ci repere pentru a urmări relația dintre vectorul de risc, activul protejat, stratul de decizie și fluxul controlat al unui pipeline RAG.
Vector de risc
- Prompt injection direct
- Instrucțiune adversarială introdusă direct de utilizator în interfață sau în promptul de input. În această notă, termenul descrie riscul ca inputul să influențeze politica, retrieval-ul sau răspunsul generatorului principal.
- Prompt injection indirect
- Instrucțiune adversarială ascunsă în documente, pagini, PDF-uri, emailuri sau alte surse care pot ajunge în corpus. Nu este acoperită complet de o poartă semantică aplicată doar înainte de retrieval.
Activ protejat
- Context intern expus
- Situația în care fragmente din knowledge base, reguli, documente interne sau date comerciale ajung în răspunsuri unde nu ar trebui. În această notă, contextul intern este activul protejat.
Strat de decizie
- Plan de control semantic
- Stratul arhitectural care separă evaluarea intenției și decizia de acces de generatorul principal. El stabilește unde se aplică politica înainte ca retrieval-ul să fie declanșat.
- Poartă semantică (Semantic Gate)
- Componenta care clasifică intenția înainte de retrieval. Poate combina model secundar, reguli, politici și semnale de risc, fără a fi tratată ca soluție universală.
Flux controlat
- Retrieval controlat
- Extragerea contextului doar după validarea intenției și aplicarea politicilor relevante. Scopul este limitarea accesului nejustificat la baza de cunoștințe.
- Context validat
- Input și context recuperat care au trecut prin controale anterioare și sunt relevante pentru sarcina permisă. Nu reprezintă o garanție de siguranță, ci o reducere a ambiguității.
- Fail-closed
- Comportament în care sistemul oprește retrieval-ul sau escaladează cazul atunci când intenția, politica sau riscul nu pot fi evaluate suficient de clar. Reduce expunerea, dar poate crește fricțiunea sau false positives.
Colapsul frontierelor de încredere într-un RAG nativ
Într-un RAG nativ, politica de sistem, inputul utilizatorului și contextul recuperat pot ajunge în același prompt compus. Din acel moment, generatorul principal nu mai primește frontiere de încredere suficient de explicite, ci un singur spațiu textual pe care îl continuă probabilistic.
Mecanism
- Observație
- Sistemul concatenează instrucțiuni cu autoritate diferită: politica de sistem, contextul recuperat și cererea utilizatorului. Această concatenare simplifică execuția, dar poate ascunde diferența dintre surse de încredere diferite.
- Risc
- Instrucțiunile adversariale pot ajunge să fie evaluate în același spațiu cu politica și contextul intern. În această poziție, generatorul principal nu trebuie tratat ca autoritate deterministă de acces.
- Implicație
- Decizia de acces trebuie evaluată înainte ca retrieval-ul să expună context intern sau înainte ca generatorul să primească un prompt compus cu context intern sensibil.
Semnale auxiliare
- Filtre simple
- Regex-ul, listele de cuvinte și similaritatea vectorială pot ajuta la filtrare, dar pot fi insuficiente în fața obfuscării, a instrucțiunilor contextuale sau a payload-urilor ascunse în documente. În această notă, ele sunt tratate ca semnale auxiliare, nu ca strat unic de decizie.
Precizare
- Nivelul observației
- Nu presupunem aici o explicație internă completă a mecanicii atenției. Observația relevantă este arhitecturală: instrucțiuni cu niveluri diferite de încredere ajung să fie procesate în același spațiu textual.
Secțiunea următoare detaliază consecința: decizia de acces rămâne prea aproape de generator dacă frontierele nu sunt separate înainte de retrieval.
Consecința arhitecturală: generatorul nu este autoritate de acces
Din momentul în care politica, contextul recuperat și inputul utilizatorului ajung într-un prompt compus, generatorul principal nu trebuie tratat ca punct unic de control. El poate produce un răspuns conform politicii sau poate continua textul într-o direcție influențată de contextul adversarial.
Consecința arhitecturală este simplă: decizia de acces trebuie aplicată înainte ca retrieval-ul să expună context intern, nu după ce generatorul primește promptul final.
RAG NATIV
Generatorul primește context înaintea deciziei
Răspuns conform politicii
Expunere context intern
Model operațional de risc
După ce figura anterioară arată de ce generatorul nu trebuie tratat ca autoritate de acces, modelul de risc delimitează ce protejăm, cine poate influența fluxul și unde trebuie introdus controlul înainte de retrieval. Această hartă nu este o scorare universală, ci o delimitare operațională pentru arhitectura analizată în notă. În logica unui cadru de management al riscului precum NIST AI RMF, secțiunea explicitează activul protejat, vectorul de influență și controalele lipsă, fără să valideze arhitectura sau severitatea ca standard universal.
Hartă operațională
Nivelurile de risc sunt dependente de date, ACL, infrastructură și impact operațional. În această notă, riscul este tratat ca orientare arhitecturală, nu ca scor universal.
Context intern, documente proprietare, reguli, date comerciale sau fragmente din knowledge base care nu trebuie expuse în răspunsuri neautorizate.
Input adversarial, cereri ambigue sau surse care pot introduce instrucțiuni neîncredere în fluxul RAG.
Promptul compus, unde politica, contextul recuperat și inputul utilizatorului pot ajunge în același spațiu textual.
Expunerea contextului intern, manipularea răspunsului, pierderea trasabilității deciziei sau escaladarea către acțiuni nepermise.
Separarea deciziei de acces într-un plan de control semantic, cu validare înainte de retrieval și politici aplicate înainte de expunerea contextului intern.
Cum se manifestă riscul în flux
Când decizia de acces este aplicată prea târziu, riscul nu apare neapărat ca eroare tehnică. Poate apărea ca un răspuns valid ca formă, dar nepermis ca acces, rol sau conținut. Într-un RAG nativ, problema apare atunci când generatorul primește context intern înainte ca fluxul să fi stabilit separat dacă acel context poate fi consultat sau expus.
Expunere de context
Fragmente din baza de cunoștințe pot ajunge în răspuns fără ca accesul să fi fost validat separat. Problema nu este doar că modelul formulează un răspuns, ci că a primit deja context intern înainte ca politica de acces să fie aplicată într-un strat distinct.
Schimbare de rol
Generatorul poate răspunde ca și cum ar opera într-un rol de diagnostic, testare sau administrare, deși fluxul nu a validat explicit acest rol. În această situație, conflictul nu este doar textual, ci arhitectural: rolul permis nu a fost separat de cererea utilizatorului.
Răspuns plauzibil, dar nepermis
Răspunsul poate fi fluent și aparent corect, dar să depășească limitele politicii de acces sau ale contextului permis. Pentru utilizator, ieșirea pare validă; pentru arhitectură, decizia de acces a fost luată prea aproape de generator.
Decizia arhitecturală rezultată este separarea evaluării de acces înainte de retrieval. Generatorul nu trebuie să primească deja context intern și apoi să decidă singur ce poate expune; clasificarea intenției trebuie mutată în fața consultării bazei de cunoștințe. Următoarea secțiune transformă această observație într-o arhitectură de protecție: poartă semantică pre-retrieval și rutare dual-LLM.
Decizia arhitecturală: poartă semantică înainte de retrieval
După ce modelul operațional de risc arată unde apare expunerea, decizia arhitecturală este mutarea evaluării intenției și accesului înainte de retrieval. Inputul utilizatorului este clasificat într-un strat separat, iar baza de cunoștințe este consultată doar dacă intenția și politica permit acest lucru.
Rutarea dual-LLM este o implementare posibilă a acestei separări, nu singura. Un model sau un strat secundar poate clasifica intenția, în timp ce generatorul principal formulează răspunsul doar după ce retrieval-ul a fost permis și contextul a fost extras în mod controlat.
RAG protejat
Acces evaluat înainte de retrieval
Input utilizator
cerere externă sau ambiguă
Poartă semantică
clasifică intenția înainte de retrieval
Cerere respinsă sau escaladată
retrieval neinițiat
Cerere validată
intenție compatibilă
Retrieval controlat
context extras validat
Generator principal
pe input validat
Răspuns conform politicii
ieșire finală
Baza de cunoștințe este consultată doar după validare.
În această arhitectură, generatorul principal nu este eliminat din flux, ci repoziționat. Rolul lui este să formuleze răspunsul după ce intenția a fost clasificată, retrieval-ul a fost permis și contextul a fost extras în mod controlat.
Separarea reduce ambiguitatea deciziei de acces, dar nu înlocuiește controalele de ingestie, ACL, telemetrie sau validare umană pentru acțiuni cu impact. Ea stabilește doar frontiera corectă: accesul la context intern se decide înainte ca generatorul să primească promptul final.
Telemetrie și Metodologie de Validare
Metodologia de validare nu urmărește să demonstreze siguranță universală. Rolul ei este să verifice, pe infrastructura proprie, dacă poarta semantică separă cererile permise de cele nepermise înainte de retrieval, dacă deciziile sunt trasabile și dacă pragurile introduc fricțiune acceptabilă pentru utilizatori legitimi.
Evaluarea trebuie rulată pe seturi separate de cereri benigne, cereri adversariale etichetate manual și scenarii de regresie. Rezultatele trebuie tratate ca semnale interne de calibrare, nu ca benchmark public.
Ordinea fluxului
Verifică dacă retrieval-ul este inițiat doar după verdictul porții semantice.
Calitatea clasificării
Verifică unde poarta permite, respinge sau escaladează cereri etichetate manual.
Costul controlului
Măsoară false positives, latență și frecvența escalărilor către revizuire umană.
| Frontieră testată | Semnal urmărit | Ce indică | Limită de interpretare |
|---|---|---|---|
| Acces înainte de retrieval | Evenimente în care retrieval-ul ar fi încercat înainte de verdictul porții | Stabilitatea ordinii de execuție: input, poartă, retrieval permis sau blocat | Nu măsoară calitatea răspunsului final, ci respectarea frontierei de acces |
| Prompt injection direct | Rată de respingere sau escaladare pentru cereri etichetate adversarial | Capacitatea porții de a separa intențiile de acces nepermis înainte de retrieval | Depinde de corpusul de test, etichetare și praguri |
| Evaziune de rol | Escalări pentru instrucțiuni care încearcă să schimbe rolul sistemului | Sensibilitatea classifierului la reîncadrarea politicii | Pragurile prea restrictive pot crește fricțiunea pentru utilizatori legitimi |
| Obfuscare și token smuggling | Acoperire pe variante codate, mascate, transformate sau multilingve | Capacitatea controalelor de a detecta payloaduri formulate diferit | Necesită red teaming recurent; variante noi pot scăpa controalelor inițiale |
| False positives | Respingere sau escaladare pentru cereri benigne etichetate manual | Costul operațional și impactul asupra experienței utilizatorului | Un prag sigur pe un corpus poate fi prea restrictiv pe altul |
| Latență și fallback | Latența adăugată de poartă și frecvența cazurilor de confidence scăzut | Costul controlului în fluxul de răspuns | Nu este benchmark public; trebuie măsurat pe infrastructura proprie |
Limită metodologică: Metricile de mai sus validează comportamentul porții semantice la runtime: ordinea deciziei, calitatea clasificării și costul operațional al escaladărilor. Ele nu validează, singure, integritatea corpusului, corectitudinea ACL-urilor, izolarea tenantului sau siguranța acțiunilor externe.
În practică, telemetria porții trebuie citită împreună cu semnale din ingestie, retrieval, politici de acces și revizuire umană. Secțiunea măsoară dacă frontiera pre-retrieval funcționează, nu dacă întregul sistem RAG este sigur în orice condiție.
LIMITĂ A PORȚII SEMANTICE
Când riscul vine din corpus, nu din cerere
Poarta semantică controlează intenția observabilă în inputul utilizatorului înainte de retrieval. Limita apare când instrucțiunea care poate influența modelul nu vine din cerere, ci din documentele recuperate.
Într-un sistem RAG, această familie de risc este asociată cu injectarea indirectă de prompt și contaminarea corpusului RAG: documente, pagini, PDF-uri sau fragmente aparent legitime ajung să transporte instrucțiuni neautorizate în contextul recuperat. Utilizatorul poate formula o cerere legitimă, iar riscul intră prin datele pe care sistemul le consideră relevante.
Schimbarea frontierei:
În atacul direct, controlul se aplică pe cererea utilizatorului înainte de retrieval. În atacul indirect, cererea poate fi legitimă, dar contextul recuperat poate conține instrucțiuni neautorizate.
| Vector | Cerere observabilă | Unde intră riscul | Strat de control |
|---|---|---|---|
| Injectare directă de prompt | Cerere adversarială sau ostilă în interfață | Input direct în chat sau prompt de intrare | Poartă semantică pre-retrieval |
| Injectare indirectă în RAG | Cerere legitimă peste un corpus contaminat | Documente, pagini, PDF-uri, emailuri sau knowledge base | Validare pre-indexare, carantină, provenance, ACL și retrieval guards |
Consecință arhitecturală: Poarta semantică rămâne utilă pentru controlul intenției înainte de retrieval, dar nu trebuie tratată ca singurul strat de apărare. Când riscul intră prin corpus, frontiera de control se mută mai devreme: ingestie, canonicalizare, scanare, carantină, metadate, ACL și filtre aplicate la retrieval.
INGESTIE ȘI INDEXARE
Cum ajunge riscul în baza de cunoștințe
Secțiunea precedentă a arătat limita porții semantice: nu toate riscurile vin din cererea utilizatorului. În RAG, un fragment problematic poate fi preluat, extras și indexat înainte să existe o cerere concretă.
Într-un pipeline RAG, documentele sunt preluate, extrase, normalizate, fragmentate, vectorizate și stocate. Dacă ingestia tratează toate fragmentele ca text benign, instrucțiuni neautorizate sau conținut de control pot ajunge în baza de cunoștințe ca date aparent legitime. Mai târziu, retrieval-ul le poate aduce în promptul compus ca parte din contextul relevant.
Suprafețe de intrare
DOCUMENTE ÎNCĂRCATE
PDF-uri, CV-uri, exporturi sau documente interne pot conține text extras automat, metadate ori comentarii care intră în pipeline.
CONȚINUT PRELUAT AUTOMAT
Pagini web, wiki-uri, emailuri sau surse sincronizate pot aduce fragmente relevante ca formă, dar neverificate înainte de indexare.
CÂMPURI AUXILIARE
Metadate, text alternativ, comentarii, front matter sau câmpuri ascunse pot fi incluse accidental ca text de cunoaștere.
Punct critic: Punctul critic nu este traseul tehnic în sine, ci schimbarea statutului: un fragment nevalidat devine corpus interogabil. Din acel moment, o cerere legitimă poate recupera context problematic fără ca inputul utilizatorului să pară adversarial.
Consecință pentru arhitectură: Poarta semantică poate decide dacă o cerere are dreptul să declanșeze retrieval, dar nu poate valida singură fragmentele deja indexate. Pentru riscurile introduse prin corpus, controlul trebuie mutat în pipeline-ul de date: validare la ingestie, canonicalizare, carantină, proveniență, ACL și filtre aplicate înainte de asamblarea contextului.
PROPAGARE ÎN RUNTIME
Când contextul recuperat devine vector de risc
După ce un fragment nevalidat a ajuns în corpus, riscul nu mai depinde neapărat de o cerere adversarială. Utilizatorul poate formula o întrebare legitimă, iar retrieval-ul poate selecta fragmente relevante ca formă, dar problematice ca statut de încredere.
În această situație, poarta semantică poate valida corect intenția cererii, dar nu validează automat conținutul deja recuperat. Punctul critic se mută între retrieval și generare: contextul extras trebuie tratat ca material condițional, nu ca instrucțiune sau autoritate de sistem.
ETAPE DE PROPAGARE
Corpus interogabil
Fragmentul nevalidat este deja indexat și poate fi selectat de retrieval.
Cerere legitimă
Inputul utilizatorului nu pare adversarial și poate trece de poarta semantică.
Retrieval fără validare de context
Pasajele sunt recuperate după relevanță, dar fără verificarea suficientă a statutului de încredere.
Prompt compus cu risc
Generatorul primește context amestecat și poate produce un răspuns nealiniat politicii.
Cerere legitimă
intenție validă
Poartă semantică
permis
Retrieval pe corpus
selecție prin relevanță
Context recuperat mixt
statut de încredere neclar
Generator principal
formulare răspuns
Risc rezidual
răspuns nealiniat sau expunere accidentală
Control necesar: validare de context între retrieval și generare
Decizie derivată: Poarta semantică controlează intenția înainte de retrieval. Pentru riscurile care intră prin corpus, este necesar un al doilea control: validarea contextului recuperat înainte ca acesta să fie asamblat în promptul final.
CLASIFICARE OPERAȚIONALĂ
Semnale de contaminare în corpusul RAG
Secțiunile precedente au arătat cum un fragment problematic poate intra în corpus și se poate propaga prin retrieval. Aici distincția devine operațională: ce semnale trebuie tratate de pipeline ca material condițional, nu ca text de cunoaștere implicit sigur.
- Instrucțiuni mascate ca date
- Unele fragmente pot încerca să transforme conținutul documentului în comandă pentru model, în loc să rămână material de referință. Controlul relevant nu este întărirea promptului aplicată la final, ci separarea explicită între date, instrucțiuni și politică încă din ingestie.
- Reîncadrarea politicii
- Un document poate conține reguli locale, roluri sau condiții de operare incompatibile cu politica sistemului. Corpusul nu trebuie să poată defini politica de acces sau comportamentul asistentului; acestea rămân în planul de control, nu în baza de cunoștințe.
- Presiune asupra răspunsului
- Unele fragmente pot încerca să influențeze formatul, nivelul de expunere sau direcția răspunsului final. Acest semnal trebuie tratat prin validarea contextului recuperat și prin politici de output, nu prin încredere implicită în textul extras.
Consecință pentru control: Aceste semnale nu confirmă singure un incident, dar indică unde sistemul trebuie să decidă între acceptare, carantină, revizuire umană sau excludere de la indexare. Secțiunea următoare transformă aceste observații în controale aplicate la ingestie, ACL, metadate și retrieval.
PIPELINE DEFENSIV
Cum controlăm corpusul înainte să devină context
Secțiunile precedente au arătat că riscul poate intra în corpus și se poate propaga prin retrieval fără ca cererea utilizatorului să pară adversarială. De aici rezultă o decizie defensivă: documentele nu trebuie tratate ca text de cunoaștere sigur doar pentru că au fost preluate de sistem.
Într-un RAG protejat, ingestia devine un plan de control al datelor. Fragmentele sunt extrase, normalizate, scanate și marcate cu metadate înainte de indexare. Unele pot fi excluse, altele pot intra în carantină pentru revizuire, iar cele acceptate rămân condiționate de ACL, proveniență și filtre aplicate la retrieval.
Documente brute din surse interne sau externe.
Text extras, normalizat și separat de metadate sau câmpuri auxiliare.
Identifică semnale de instrucțiune, reîncadrare a politicii sau conținut nevalidat.
Frontiera decide ce intră în corpus și ce rămâne în afara indexării.
Excludere de la indexare
Carantină / revizuire umană
Acceptare condiționată
Tenant, ACL, proveniență și statut de încredere.
Corpusul rămâne interogabil doar în limitele ACL, provenienței și izolării de tenant.
REGULI DE PROIECTARE
- Canonicalizare înainte de vectorizare
- Textul trebuie adus într-o formă controlabilă înainte să fie indexat. Comentariile, metadatele și câmpurile auxiliare nu trebuie amestecate accidental cu textul de cunoaștere.
- Scanare și carantină înainte de indexare
- Semnalele de instrucțiune, reîncadrare a politicii sau obfuscare nu trebuie indexate direct. Ele pot duce la excludere, carantină sau revizuire umană.
- Proveniență, ACL și izolare de tenant
- Fragmentele acceptate trebuie să păstreze context operațional: sursă, tenant, drepturi de acces, proveniență și statut de încredere. Retrieval-ul trebuie să respecte aceste atribute înainte de asamblarea contextului.
Decizia de proiectare: Controlul nu se aplică doar la generator. Într-un RAG protejat, traseul datelor trebuie controlat înainte ca fragmentele să devină corpus interogabil și înainte ca retrieval-ul să le includă în contextul final.
MATRICE DE ACOPERIRE
Ce controlează poarta semantică și ce rămâne pentru pipeline, ACL și HITL
Secțiunile precedente au separat trei frontiere de control: intenția utilizatorului, corpusul recuperabil și acțiunile externe. Matricea de mai jos nu atribuie scoruri universale. Ea indică unde trebuie aplicat primul control și ce limită rămâne după acel control.
Într-o arhitectură prudentă, datele externe și inputurile utilizatorului sunt tratate implicit ca neîncrezute. Poarta semantică acoperă predominant cererile directe observabile la runtime, în timp ce riscurile introduse prin corpus, eșecurile ACL și abuzurile de acțiuni cer controale la nivel de infrastructură, pipeline de date sau validare umană.
GLOSĂ DE TERMENI:
ACL: reguli deterministe de acces aplicate pe tenant, rol, document sau fragment, independent de decizia modelului.
HITL: validare umană în flux pentru cazuri ambigue, escaladări sau acțiuni externe cu impact.
Pipeline de date: traseul de ingestie, metadate, indexare și retrieval prin care fragmentele devin eligibile pentru context.
A.Control la runtime: intenție și acces
| Clasă de risc | Control potrivit | Unde se aplică | Ce acoperă | Limită rămasă |
|---|---|---|---|---|
| Prompt injection direct | Poartă semantică | Înainte de retrieval | Cererile adversariale observabile în inputul utilizatorului | Obfuscare, ambiguitate semantică sau formulări dependente de prag |
| Confuzie de rol | Poartă semantică și politică de sistem | Înainte de retrieval | Încercările de reîncadrare a rolului cerut de utilizator | Cazurile ambigue pot necesita escaladare manuală |
| Obfuscare și token smuggling | Filtre sintactice și poartă semantică | Pre-retrieval | Variante cunoscute de mascare, codare sau transformare lingvistică | Variantele noi sau multilingve pot scăpa controalelor inițiale |
| Evitare multilingvă | Poartă semantică multilingvă și escaladare manuală | Runtime | Cererile formulate în limbi acoperite suficient de clasificator | Acoperirea poate fi slabă pentru limbi cu acoperire redusă sau formulări hibride |
B.Control pe date, retrieval și acțiuni
| Clasă de risc | Control potrivit | Unde se aplică | Ce acoperă | Limită rămasă |
|---|---|---|---|---|
| Injectare indirectă în RAG | Validare pre-indexare și scanare semantică | Înainte de indexare | Fragmentele suspecte înainte să devină corpus interogabil | Riscul poate intra prin corpus deja existent sau surse nevalidate |
| Contaminare la ingestie | Carantină și revizuire umană | Înainte de indexare | Documentele care prezintă semnale de instrucțiune sau reîncadrare a politicii | Filtrarea este dependentă de regulile de ingestie și de calitatea etichetării |
| Scurgere cross-tenant / eșec ACL | ACL aplicat determinist și izolare de tenant | La retrieval în baza vectorială | Accesul la fragmente în funcție de tenant, rol și drepturi | Nu trebuie rezolvat probabilistic de LLM; ține de infrastructură |
| Abuz de instrumente sau acțiuni externe | Motor de politici și HITL | Înainte de execuția API | Acțiunile cu impact extern sau ireversibil | Necesită autorizare explicită; nu trebuie lăsat doar pe decizia modelului |
Notă de citire: Matricea nu atribuie scoruri universale. Ea indică stratul unde controlul trebuie aplicat prima dată și ce limită rămâne după acel control.
Regula de proiectare: Poarta semantică este controlul potrivit pentru intenția observabilă înainte de retrieval. Nu este un control universal al corpusului, al ACL-urilor sau al acțiunilor externe.
Riscurile care intră prin documente cer controale în pipeline-ul de date. Riscurile care țin de tenant, drepturi și acces cer ACL aplicat determinist. Riscurile cu impact extern cer motor de politici și validare umană.
ANTI-PATTERNURI ARHITECTURALE
Decizii care rup separarea dintre straturi
Secțiunile precedente au separat responsabilitățile: intenția se evaluează înainte de retrieval, corpusul se validează înainte de indexare, accesul se aplică prin ACL, iar acțiunile cu impact cer HITL. Anti-patternurile de mai jos apar când aceste separări sunt ignorate sau amestecate.
Nu sunt doar greșeli de implementare. Sunt decizii structurale care fac sistemul dependent de generator, de prompt, de context deja expus sau de clasificări probabilistice aplicate prea târziu.
| Anti-pattern | De ce este problematic | Corecție arhitecturală |
|---|---|---|
| Generare înainte de clasificare | Modelul primește input nevalidat sau context sensibil înainte ca politica de acces să fie aplicată. | Clasificarea intenției și decizia de acces trebuie aplicate înainte de retrieval și înainte ca generatorul să primească promptul final. |
| Interogare brută pentru retrieval și sinteză | Aceeași intrare neîncrezută controlează atât selecția contextului din baza de cunoștințe, cât și formularea răspunsului. | Separă evaluarea intenției, interogarea corpusului și sinteza răspunsului. Retrieval-ul trebuie să fie permis și încadrat de politici, nu declanșat direct de inputul brut. |
| Pasaje nefiltrate trimise generatorului | Generatorul primește fragmente întregi, nefiltrate sau neminimizate, inclusiv text care nu este necesar pentru răspuns. | Contextul recuperat trebuie minimizat, filtrat, asociat cu proveniență și validat înainte de asamblarea promptului. |
| Corpus tratat implicit ca sigur | Documentele ingerate sunt presupuse benigne, iar scanarea, canonicalizarea, carantina și metadatele de control sunt omise. | Corpusul trebuie tratat ca material condițional. Fragmentele devin eligibile pentru retrieval doar după validare, metadate, ACL și proveniență. |
| Instrucțiuni de sistem tratate ca unic control | Instrucțiunile de sistem sunt folosite ca substitut pentru controale arhitecturale verificabile. | Promptul poate ajuta la comportament, dar nu trebuie să fie singurul strat de enforcement. Controlul trebuie aplicat în poartă semantică, pipeline de date, ACL și motor de politici. |
| Continuare la scor de încredere scăzut | Sistemul continuă execuția atunci când clasificarea intenției este ambiguă, slabă sau nesigură. | Cazurile cu scor de încredere scăzut trebuie escaladate, respinse sau trimise către fallback controlat. Nu trebuie tratate ca permisiune implicită. |
| Acțiuni externe fără validare umană | Modelului i se permite să execute acțiuni externe cu efecte ireversibile doar pe baza unei decizii probabilistice. | Acțiunile cu impact trebuie trecute prin motor de politici, autorizare explicită și HITL atunci când riscul operațional o cere. |
Regula comună: Generatorul poate formula răspunsuri, dar nu trebuie să preia roluri de acces, validare de corpus sau autorizare externă. Aceste responsabilități trebuie separate în poartă semantică, pipeline de date, ACL, motor de politici și HITL.
ÎNCHIDERE TEHNICĂ
Limite reziduale după poarta semantică
Poarta semantică reduce ambiguitatea deciziei de acces înainte de retrieval, dar nu transformă un sistem RAG într-un mediu sigur implicit. Riscurile rămase apar mai ales acolo unde semnalul nu este vizibil în cererea utilizatorului, unde corpusul a fost deja contaminat sau unde efectul depășește generarea de text.
RISCURI CARE RĂMÂN ÎN AFARA PORȚII
- Evaziune lingvistică și obfuscare
- Clasificarea intenției poate fi mai slabă în formulări multilingve, codate, mascate sau în limbi cu acoperire redusă. Aceste cazuri cer testare recurentă, fallback controlat și monitorizare pe infrastructura proprie.
- Corpus existent sau surse nevalidate
- Poarta semantică nu validează retrospectiv documentele deja indexate. Fragmentele provenite din surse vechi, sincronizări automate sau corpusuri fără proveniență clară trebuie tratate prin pipeline de date, scanare, carantină și metadate.
- ACL, tenant și proveniență
- Accesul la fragmente nu trebuie decis probabilistic de model. Separarea pe tenant, rol, document și proveniență trebuie aplicată determinist la nivel de infrastructură și retrieval.
- Acțiuni externe și instrumente
- Un răspuns generat poate părea coerent, dar acțiunile externe cu impact cer autorizare explicită, motor de politici și validare umană atunci când efectul este ireversibil sau sensibil.
Decizia finală de arhitectură: Generatorul principal poate formula răspunsuri, dar nu trebuie să devină autoritate de acces, filtru de corpus sau motor de autorizare externă. Poarta semantică tratează intenția observabilă înainte de retrieval; pipeline-ul de date tratează corpusul; ACL-ul tratează accesul; HITL tratează cazurile ambigue și acțiunile cu impact.
Concluzie tehnică: În acest model, reducerea riscului este susținută prin separarea deciziei de acces față de retrieval și generare, completată de controale la ingestie, metadate, ACL, telemetrie și validare umană. Separarea nu elimină riscul rezidual, dar mută deciziile în straturi unde pot fi aplicate, auditate și ajustate mai explicit.