Firemný RAG: oprávnenia a testy skôr než pekné odpovede

Otázka má vždy používateľa a povolené zdroje

V ukážke firemného asistenta sa dvaja ľudia opýtajú na podmienky rovnakej zákazky. Jeden smie čítať verejný produktový list, druhý aj internú obchodnú ponuku. Správna odpoveď sa preto môže líšiť. Vyhľadávanie relevantných dokumentov samo osebe nestačí: systém musí vedieť, komu odpovedá, z ktorých zdrojov smie čerpať a kedy má priznať chýbajúci podklad.

RAG spája získanie kontextu s generovaním odpovede. Pri technickom návrhu tieto časti vyhodnocujeme oddelene. Ak asistent nesprístupní potrebný dokument, lepší textový model chýbajúce informácie spoľahlivo nenahradí. Ak získame správne podklady, generovanie ich stále môže nesprávne vysvetliť. Nasledujúci návrh je modelový a nepopisuje architektúru ani namerané výsledky konkrétnej klientskej realizácie.

Oprávnenia preneste na každý vyhľadávaný úsek

Pri rozdelení dokumentu na úseky zachováme ID zdroja, verziu a údaje potrebné na rozhodnutie o prístupe. OWASP upozorňuje, že oprávnenia sa musia uplatniť aj pri vyhľadávaní. Microsoft dokumentuje filtrovanie podľa identity ako jednu z implementačných možností. Filtre vytvorí server z overenej identity; používateľ ich nemôže nahradiť vlastným tenant ID alebo zoznamom skupín.

Ochranu uplatníme pred vrátením výsledkov a opäť pred vložením kontextu do modelu. Úsek bez platných prístupových údajov nepovažujeme za verejný. Ani reranker, ktorý na posúdenie relevantnosti používa ďalší model, nesmie dostať nepovolený text. Nasledujúci pseudokód zjednodušuje komponenty a nepredstavuje hotovú implementáciu. Skutočný systém musí riešiť aj chyby politiky, revízie oprávnení a obsah predchádzajúcich správ.

principal = authenticate(request)
scope = access_policy.read_scope(principal)

hits = search(
  query=request.question,
  tenant=scope.tenant,
  allowed_documents=scope.document_ids
)

context = access_policy.require_current_access(principal, hits)
ranked_context = rerank_only_authorised(context)
answer = generate(question=request.question, context=ranked_context)

access_policy.require_current_access(principal, ranked_context)
return validate_answer(answer, allowed_sources=ranked_context)

Zmeny prístupov zasiahnu index, cache aj konverzáciu

Dokument môže byť správne indexovaný a neskôr sa zmení jeho prístup. Kým dorazí aktualizácia indexu, staré metadáta by mohli umožniť únik. Pri citlivom obsahu preto kontrolujeme aktuálnu politiku na dôveryhodnom zdroji, prípadne používame overenú revíziu oprávnení s dohodnutou čerstvosťou. Pri nedostupnej politike prístup odmietneme. Výpadok autorizačnej služby nesmie automaticky rozšíriť oprávnenia.

Rovnaký problém má cache odpovedí. Text pripravený pre vedúceho nepatrí automaticky kolegovi s podobnou otázkou. Kľúč cache a podmienky použitia musia rešpektovať hranicu organizácie, prístupový rozsah aj verzie zdrojov. Odobratie prístupu musí zneplatniť súvisiace výsledky a zohľadniť ich v konverzačnej pamäti. Pred ďalšou otázkou nemožno do kontextu jednoducho vrátiť celý starý prepis, ak už obsahuje odobraté podklady.

Dokumenty môžu obsahovať pokyny útočníka

Aj povolený dokument môže obsahovať text, ktorý sa snaží zmeniť správanie asistenta. OWASP opisuje nepriamu prompt injection aj cez získané podklady. Pripojenie znalostnej databázy túto hrozbu neodstraňuje. Systém preto oddeľuje aplikačné pokyny od citovaných dát a obmedzuje zdroje, rozsah kontextu a nástroje dostupné modelu. Samotná veta v prompte o ignorovaní cudzích pokynov nie je bezpečnostná hranica.

Pri modeli určenom na odpovede nepovolíme zápis do objednávok iba preto, že by ho technicky dokázal navrhnúť. Ak neskôr pridáme vykonávanie krokov, aplikácia skontroluje identitu, oprávnenie a argumenty každej operácie samostatne. Filtre vstupu a výstupu môžu zachytiť časť útokov, ale nezaručia odolnosť voči všetkým variantom. Návrh musí počítať s odmietnutím požiadavky, kontrolou človekom a dohľadateľným vysvetlením, ktoré zdroje ovplyvnili odpoveď.

Testovacia sada musí poznať otázku aj očakávané dôkazy

Zostavíme úlohy z reálneho informačného procesu, no bez zverejnenia citlivých dokumentov. Každý test obsahuje otázku, rolu používateľa, povolené zdroje, očakávané podklady a kritérium odpovede. Zaradíme aj prípad, keď správny dokument neexistuje, obsahuje rozporné verzie alebo ho používateľ nesmie čítať. Odmietnutie môže byť pri takom teste správny výsledok.

Nasledujúca tabuľka ilustruje návrh sady. Očakávané zdroje pripraví človek, ktorý pozná proces a dokumenty. Pri dôležitých tvrdeniach uloží konkrétny úsek, nie iba názov súboru. Časť úloh vyhradíme na nezávislé overenie, aby úpravy vyhľadávania neboli iba prispôsobením otázkam, ktoré vývojári už poznajú. Každá zmena dokumentu môže vyžadovať úpravu očakávaného výsledku.

Vyhľadávanie a generovanie merajte oddelene

Pri vyhľadávaní sledujeme, koľko z očakávaných relevantných zdrojov sa nachádza medzi získanými výsledkami. Ak test očakáva tri konkrétne dokumenty a systém nájde dva, zodpovedajúci recall na ID dokumentov je dve tretiny. Ragas popisuje ID-based context recall aj hodnotenie pokrytia tvrdení v referenčnej odpovedi. Nie sú to totožné merania; zvolenú jednotku preto pomenujeme.

Pri porovnaní zachováme rovnaký prístupový rozsah, sadu otázok a limit získaných úsekov. Inak rozdiel nemusí spôsobovať nový retriever. Počet výsledkov má cenu: viac kontextu zvýši prenos a prácu modelu a môže pridať rušivý text. Bezpečnostné prípady vykazujeme samostatne. Vysoký priemer kvality bežných odpovedí nesmie skryť jeden prípad, keď systém získal cudzie dáta.

Citácia ešte nepotvrdzuje správnosť tvrdenia

Pri odpovedi kontrolujeme, či sa jej konkrétne tvrdenia opierajú o dodaný kontext, či odpovedá na otázku a či citované zdroje skutočne podporujú uvedený záver. Asistent môže správne uviesť existujúci dokument a pritom mu pripísať vetu, ktorá v ňom nie je. Aplikácia overí, že všetky ID citácií patria medzi povolené získané zdroje. Obsahový vzťah tvrdenia a dôkazu vyžaduje ďalšie hodnotenie.

Automatický hodnotiteľ je užitočný na triedenie väčšej sady, jeho výstup však porovnáme s úsudkom ľudí na vzorke. Ragas výskum oddeľuje aspekty kvality získaného kontextu a výslednej odpovede; konkrétne skóre nemá univerzálnu hranicu použiteľnosti. Pre vlastný proces si určíme chyby, ktoré vyžadujú zastavenie, a chyby, ktoré iba zhoršujú užitočnosť. Pri schvaľovaní alebo osobných údajoch býva rozdiel medzi týmito triedami zásadný.

Pilot musí umožniť nájsť príčinu chyby

Pri pilotnom nasadení zaznamenáme verzie indexu, zdrojov, vyhľadávania a konfigurácie generovania. Výsledok potom vieme priradiť ku konkrétnemu rozhodnutiu systému. S obsahom otázok a odpovedí zaobchádzame podľa ich citlivosti; prevádzkový log nemá automaticky kopírovať všetky firemné dokumenty. Sledujeme tiež čas odpovede, náklady a počet požiadaviek, pri ktorých asistent nemal dostatok podkladov.

Nasledujúce kontroly sú návrhom overenia, nie výsledkami vykonaného klientského auditu. Po oprave chyby pridáme reprodukovateľný prípad do sady. Pred výmenou modelu zopakujeme rovnaké úlohy s rovnakými dátami a oprávneniami. Tak vieme odlíšiť zmenu štýlu odpovede od zmeny jej vecnej kvality alebo sprístupnených informácií.

• Odoberte dokumentu prístup počas rozpracovanej požiadavky a overte správanie pred vrátením odpovede.
• Položte rovnakú otázku dvom rolám a dvom organizáciám; skontrolujte kontext, citácie aj cache.
• Vložte do povoleného testovacieho dokumentu nepriateľský pokyn a overte, že nezíska nové oprávnenie ani nevykoná operáciu.
• Nahraďte dokument novou verziou, odstráňte ho a skontrolujte zneplatnenie úsekov aj uložených odpovedí.
• Vypnite autorizačnú službu; systém musí odmietnuť nepodložené sprístupnenie namiesto pokračovania so širším prístupom.

Od témy ku konkrétnemu riešeniu.

Súvisiaca realizácia: CBC Slovakia