Governance, důvěra a bezpečnost

Retrieval-Augmented Generation jako řízené volání nástroje — ne magie

Dotazretrieve_knowledge()Filtr dleidentityVektorovéhledáníVloženo dopromptu

Retrieval-Augmented Generation, neboli RAG, bývá prezentován jako něco blízkého černé skříňce — extra mozek přilepený k jazykovému modelu, který nějak zná věci, na kterých model nebyl trénován. Toto rámování dělá reálnou škodu každému, kdo se snaží jasně uvažovat o tom, k čemu RAG systém může a nemůže přistupovat, a co by se s ním mohlo pokazit. Užitečnější a přesnější rámování je mnohem prostší: RAG je řízené volání nástroje.

Posun od cpaní k volání

Starší, jednodušší přístup, jak dát modelu přístup k proprietárním informacím, je statické cpaní kontextu: vzít celé dokumenty a jejich obsah vložit přímo do promptu, pokaždé, bez ohledu na to, zda je otázka v daném tahu vůbec potřebuje. To má dva jasné problémy. Nese vysoké náklady na tokeny a přidává latenci, protože celý dokument cestuje s každým požadavkem bez ohledu na relevanci. A má v podstatě žádné bezpečnostní filtrování — pokud je dokument v promptu, model ho může vidět a potenciálně zobrazit jakoukoliv jeho část, bez kontroly, zda tazatel skutečně má oprávnění tento obsah vidět.

Alternativou je zacházet s retrievalem jako s nástrojem, který agent volá za běhu, podle potřeby. Typický průběh: přijde dotaz, agent zavolá retrieval nástroj — něco jako retrieve_knowledge() — tento nástroj nejdřív aplikuje filtr řízení přístupu podle identity, vektorové hledání proběhne jen nad obsahem, který tento filtr povoluje, a do promptu pro daný konkrétní tah se vloží jen relevantní, povolené výsledky. To je efemérní: v žádné konverzaci nesedí statický nános dokumentů bez ohledu na relevanci a filtrování podle identity probíhá před hledáním, ne jako dodatečná úvaha nad výsledky.

Výhrada, kterou stojí za to si podržet

Bylo by nadsázkou nazvat úspory RAG založeného na nástrojích absolutními. Schéma samotného retrieval nástroje musí být pořád registrováno a pořád spotřebovává prostor v tokenech v každém jednom tahu, bez ohledu na to, zda je v daném tahu skutečně zavolán, přesně jako u jakéhokoliv jiného nástroje dostupného agentovi. Přínosy odklonu od statického cpaní kontextu jsou reálné a typicky velké, ale nejsou doslova nulové.

Proč na tomto přerámování záleží

Jakmile je RAG chápán jako řízené volání nástroje spíš než tajemný extra podsystém, celá řada dřív nejasných otázek se stává konkrétní a zodpověditelnou. K čemu má tento systém přístup? K čemukoliv, co filtr řízení přístupu retrieval nástroje povolí pro tohoto konkrétního uživatele, v tuto konkrétní chvíli — stejný druh otázky, jakou byste položili u jakéhokoliv jiného nástroje s vymezenými oprávněními. Co se loguje? Cokoliv, co už pokrývá trasovací infrastruktura pro každé jiné volání nástroje, protože retrieval je volání nástroje. Nic na RAG nemusí být bráno jako výjimečné, jakmile je takto pochopeno — a přesně proto podnikové nasazení profituje z toho, myslet na něj jako na řízené volání nástroje od začátku, místo dodatečného nalepování governance na něco, co bylo navrženo a vysvětlováno, jako by to byla magie.

Otázky pro váš tým

  • Víte přesně, ke kterým datovým zdrojům mají AI nástroje vaší organizace aktuálně přístup?
  • Co byste chtěli logovat při každém volání retrievalu?

Také dostupné v jazyce English

← Důvěřuj, ale prověřuj: Vynucení schématu, strukturované výstupy a evaluace agentů Suverenita dat v éře agentů: Co "zero data retention" skutečně znamená →