Průvodce návrhem zabezpečeného řešení pro odvozování víceklientských rag

Načítání rozšířené generace (RAG) je vzor pro vytváření aplikací, ve kterých se základní modely používají k odůvodnění proprietárních informací nebo jiných informací, které nejsou veřejně dostupné na internetu. Klientská aplikace obecně volá vrstvu orchestrace, která načítá relevantní informace z úložiště dat, jako je například vektorová databáze. Vrstva orchestrace předává tato data jako součást kontextu jako podkladová data do základního modelu.

Víceklientských řešení používá více zákazníků, kde se každý zákazník (tenant) skládá z více uživatelů ze stejné organizace, společnosti nebo skupiny. Ve scénářích s více tenanty je potřeba zajistit, aby tenanti nebo jednotlivci v rámci tenantů mohli zahrnout pouze základní data, která mají oprávnění k zobrazení.

I když existují obavy s více tenanty nad rámec toho, aby uživatelé měli přístup jenom k informacím, které mají vidět, tento článek se zaměřuje na tento aspekt víceklientské architektury. Tento článek začíná přehledem architektur RAG pro jednoho tenanta, probírá výzvy týkající se víceklientské architektury s RAG a některé běžné přístupy, které je potřeba dodržovat, a končí zabezpečenými aspekty a doporučeními týkajícími se víceklientské architektury.

Architektura RAG s jedním tenantem s orchestrátorem

Obrázek č. 1. Architektura RAG s jedním tenantem

Workflow

V této architektuře RAG s jedním tenantem má orchestrátor odpovědnost za načtení relevantních proprietárních dat tenantů z úložišť dat a jejich poskytování jako základu dat do základního modelu. Následuje pracovní postup vysoké úrovně:

1. Uživatel vydá žádost o inteligentní webovou aplikaci.
2. Zprostředkovatel identity ověřuje žadatele.
3. Inteligentní aplikace volá rozhraní API orchestrátoru s dotazem uživatele a autorizačním tokenem pro uživatele.
4. Logika orchestrace extrahuje dotaz uživatele z požadavku a volá příslušné úložiště dat pro načtení relevantních podkladových dat pro dotaz. Podkladová data se přidají do výzvy, která se odešle do základního modelu, například do modelu zveřejněného v Azure OpenAI, v dalším kroku.
5. Logika orchestrace se připojí k rozhraní API pro odvozování základního modelu a odešle výzvu, která obsahuje načtená data zem. Výsledky se vrátí do inteligentní aplikace.

Další informace o podrobnostech RAG najdete v tématu Navrhování a vývoj řešení RAG.

Architektura RAG s jedním tenantem s přímým přístupem k datům

Varianta architektury RAG s jedním tenantem využívá schopnost služby Azure OpenAI integrovat přímo s úložišti dat, jako je Azure Search. V této architektuře buď nemáte vlastní orchestrátor, nebo váš orchestrátor má méně zodpovědností. Rozhraní API Azure OpenAI má odpovědnost za volání do úložiště dat za účelem načtení podkladových dat a předání dat do jazykového modelu. Naopak máte menší kontrolu nad tím, jaká podkladová data se mají načíst, a levnost těchto dat.

Obrázek č. 2. Architektura RAG s jedním tenantem s přímým přístupem k datům ze služby Azure OpenAI

Workflow

V této architektuře RAG má služba poskytující základní model odpovědnost za načtení odpovídajících proprietárních dat tenantů z úložišť dat a použití těchto dat jako základu dat do základního modelu. Následuje základní pracovní postup (kurzíva je shodná s architekturou RAG s jedním tenantem s pracovním postupem orchestrátoru):

1. Uživatel vydá žádost o inteligentní webovou aplikaci.
2. Zprostředkovatel identity ověřuje žadatele.
3. Inteligentní aplikace pak zavolá službu Azure OpenAI s uživatelským dotazem.
4. Služba Azure OpenAI se připojuje k podporovaným úložištím dat, jako je Azure AI Search a Azure Blob Storage, a načte základní data. Základní data se používají jako součást kontextu, když služba Azure OpenAI volá jazykový model OpenAI. Výsledky se vrátí do inteligentní aplikace.

Aby bylo možné tuto architekturu vzít v úvahu v řešení s více tenanty, služba, jako je Azure OpenAI, která přímo přistupuje k podkladovým datům, musí podporovat víceklientské logiky vyžadované vaším řešením.

Víceklientská architektura v architektuře RAG

Ve víceklientských řešeních můžou data tenanta existovat v úložišti specifickém pro tenanta nebo spolu s ostatními tenanty ve víceklientských úložištích. V úložišti, které se sdílí napříč tenanty, můžou existovat také data. Jako podkladová data by měla být použita pouze data, která má uživatel oprávnění k zobrazení. Uživatelé by měli vidět jenom běžná data (všechna data) nebo data ze svého tenanta s použitými pravidly filtrování, aby měli jistotu, že uvidí jenom data, která mají oprávnění k zobrazení.

Obrázek 3: Architektura RAG – s více tenanty úložiště dat

Workflow

Tento pracovní postup je stejný jako v architektuře RAG s jedním tenantem s orchestrátorem s výjimkou kroku 4.

1. Uživatel vydá žádost o inteligentní webovou aplikaci.
2. Zprostředkovatel identity ověřuje žadatele.
3. Inteligentní aplikace volá rozhraní API orchestrátoru s dotazem uživatele a autorizačním tokenem pro uživatele.
4. Logika orchestrace extrahuje dotaz uživatele z požadavku a volá příslušná úložiště dat pro načtení autorizovaných tenantů a relevantních podkladových dat pro dotaz. Základní data se přidají do výzvy, která se odešle do Azure OpenAI v dalším kroku. Patří sem některé nebo všechny následující kroky:
   1. Logika orchestrace načítá uzemnění dat z příslušné instance úložiště dat specifické pro tenanta a potenciálně použije pravidla filtrování zabezpečení pro vrácení pouze dat, ke které má uživatel oprávnění k přístupu.
   2. Logika orchestrace načte z víceklientské úložiště dat uzemnění odpovídajícího tenanta a potenciálně použije pravidla filtrování zabezpečení tak, aby vracela pouze data, ke které má uživatel oprávnění k přístupu.
   3. Logika orchestrace načítá data z úložiště dat, které se sdílí napříč tenanty.
5. Logika orchestrace se připojí k rozhraní API pro odvozování základního modelu a odešle výzvu, která obsahuje načtená data zem. Výsledky se vrátí do inteligentní aplikace.

Aspekty návrhu víceklientských dat v RAG

Volba modelů izolace úložiště

Existují dva hlavní přístupy architektury pro úložiště a data ve scénářích s více tenanty: úložiště na tenanta a víceklientské úložiště. Tyto přístupy jsou kromě úložišť obsahujících data, která jsou sdílená napříč tenanty. Tato část se týká každého přístupu. Je třeba poznamenat, že vaše víceklientové řešení může používat kombinaci těchto přístupů.

Store-per-tenant

V úložišti podle názvu má každý tenant vlastní úložiště. Mezi výhody tohoto přístupu patří izolace dat i výkonu. Data každého tenanta jsou zapouzdřena ve vlastním úložišti. Ve většině datových služeb nejsou izolovaná úložiště náchylná k problému hlučného souseda jiných tenantů. Tento přístup také zjednodušuje přidělování nákladů, protože celé náklady na nasazení úložiště je možné přiřadit jednomu tenantovi.

Výzvy tohoto přístupu mohou zahrnovat vyšší režii na správu a provoz a vyšší náklady. Tento přístup by se neměl brát v úvahu, pokud existuje velký počet malých tenantů, jako jsou scénáře typu business-to-consumer. Tento přístup může také narazit na omezení služby.

V kontextu tohoto scénáře AI by úložiště pro tenanta znamenalo, že podkladová data potřebná k přenesení relevance do kontextu pocházejí z existujícího nebo nového úložiště dat, které obsahuje pouze základní data pro tenanta. V této topologii je instance databáze diskriminátorem používaná pro jednotlivé tenanty.

Úložiště s více tenanty

Ve víceklientských úložištích existuje několik tenantů ve stejném úložišti. Mezi výhody tohoto přístupu patří potenciál optimalizace nákladů, možnost zpracovat vyšší počet tenantů než model úložiště a snížit režii správy kvůli nižšímu počtu instancí úložiště.

Problémy při používání sdílených úložišť zahrnují nutnost zajistit izolaci dat, správu dat, potenciál antipatternu hlučného souseda a obtížné přidělování nákladů tenantům. Nejdůležitějším problémem tohoto přístupu je zajištění izolace dat. Zodpovídáte za implementaci přístupu k zabezpečení, abyste zajistili, že tenanti budou mít přístup pouze ke svým datům. Správa dat může být také výzvou v případě, že tenanti mají různé životní cyklus dat, které můžou vyžadovat operace, jako je vytváření indexů podle různých plánů.

Některé platformy mají funkce, které můžete využít při implementaci izolace dat tenanta ve sdílených úložištích. Azure Cosmos DB má například nativní podporu pro dělení a horizontální dělení a je běžné používat identifikátor tenanta jako klíč oddílu k zajištění určité úrovně izolace mezi tenanty. Azure SQL a Postgres Flex podporují zabezpečení na úrovni řádků, i když se tato funkce běžně nepoužívá ve víceklientských řešeních, protože pokud plánujete jejich použití ve víceklientských úložištích, musíte řešení navrhnout kolem těchto funkcí.

V kontextu tohoto scénáře umělé inteligence by to znamenalo, že základní data pro všechny tenanty přicházejí do stejného úložiště dat tak, aby dotaz na toto úložiště dat musel obsahovat diskriminátor tenanta, aby se zajistilo, že odpovědi budou omezené na vrácení pouze relevantních dat v kontextu tenanta.

Sdílené obchody

Víceklientová řešení často obsahují data sdílená napříč tenanty. V ukázkovém víceklientské řešení pro zdravotnickou doménu může existovat databáze, která uchovává obecné lékařské informace nebo informace, které nejsou specifické pro tenanta.

V kontextu tohoto scénáře umělé inteligence by to bylo obecně přístupné základní úložiště dat, které konkrétně nepotřebuje filtrování na základě jakéhokoli tenanta, protože data jsou relevantní a autorizovaná pro všechny tenanty v systému.

Identita

Identita je klíčovým aspektem víceklientských řešení , včetně zabezpečeného víceklientských rag. Inteligentní aplikace by se měla integrovat s zprostředkovatelem identity (IDP), aby ověřila identitu uživatele. Řešení RAG s více tenanty potřebuje adresář identit, ve kterém jsou uložené autoritativní identity nebo odkazy na identity. Tato identita musí protékat řetězem požadavků, což umožňuje podřízeným službám, jako je orchestrátor, nebo dokonce samotné úložiště dat k identifikaci uživatele.

Vyžadujete také způsob mapování uživatele na tenanta , abyste mohli udělit přístup k datům tohoto tenanta.

Definování požadavků na tenanta a autorizaci

Při vytváření víceklientských řešení RAG musíte definovat, co je tenant pro vaše řešení. Mezi dva běžné modely, ze které si můžete vybrat, patří B2B (business-to-business) a B2C (business-to-consumer). Toto rozhodnutí vám pomůže informovat o oblastech, které byste měli zvážit při navrhování řešení. Pochopení počtu tenantů je důležité pro rozhodování o modelu úložiště dat. Velký počet tenantů může vyžadovat model s více tenanty na úložiště, zatímco menší číslo může umožňovat úložiště na model tenanta. Důležité je také množství dat pro jednotlivé tenanty. Pokud tenanti mají velké objemy dat, které vám můžou bránit v používání víceklientských úložišť kvůli omezením velikosti úložiště dat.

V existujících úlohách, které se rozšiřují tak, aby podporovaly tento scénář umělé inteligence, jste tuto volbu už možná udělali. Obecně řečeno, pro zemská data budete moct použít stávající topologii úložiště dat, pokud toto úložiště dat může poskytovat dostatečnou levnost a splňovat všechny ostatní požadavky na nefunkční funkce. Pokud ale zavádíte nové komponenty, jako je vyhrazené úložiště vektorového vyhledávání jako vyhrazené uzemněné úložiště, musíte toto rozhodnutí provést, přičemž zvažte faktory, jako je vaše aktuální strategie razítka nasazení, dopad roviny řízení aplikace a všechny rozdíly životního cyklu dat pro jednotlivé tenanty (například situace s platbami za výkon).)

Jakmile definujete, co je tenant pro vaše řešení, musíte definovat požadavky na autorizaci dat. Zatímco tenanti přistupují jenom k datům ze svého tenanta, požadavky na autorizaci můžou být podrobnější. Například ve zdravotnickém řešení můžete mít pravidla, jako jsou:

• Pacient má přístup pouze k vlastním datům o pacientech.
• Zdravotnický pracovník má přístup k datům svých pacientů.
• Finanční uživatel má přístup pouze k datům souvisejícím s financemi.
• Klinický auditor může zobrazit všechna data pacientů
• Všichni uživatelé mají přístup k základním lékařským znalostem ve sdíleném úložišti dat.

V aplikaci RAG založené na dokumentech můžete chtít omezit přístup uživatelů k dokumentům na základě schématu označování nebo úrovní citlivosti nastavených na dokumenty.

Jakmile budete mít definici toho, co je tenant a máte jasný přehled o autorizačních pravidlech, použijte tyto informace jako požadavky na vaše řešení úložiště dat.

Filtrování

Filtrování, označované také jako oříznutí zabezpečení, označuje pouze data uživatelům, kteří mají oprávnění k zobrazení. Ve scénáři s více tenanty RAG může být uživatel mapován na úložiště specifické pro tenanta. To neznamená, že by měl mít uživatel přístup ke všem datům v daném úložišti. V části Definování požadavků na tenanta a autorizaci jsme probrali důležitost definování požadavků na autorizaci pro vaše data. Tato autorizační pravidla by se měla používat jako základ pro filtrování.

Filtrování lze provést pomocí funkcí datové platformy, jako je zabezpečení na úrovni řádků, nebo může vyžadovat vlastní logiku, data nebo metadata. Tyto funkce platformy se znovu nepoužívají ve víceklientských řešeních, protože je potřeba navrhnout systém kolem těchto funkcí.

Zapouzdření logiky víceklientských dat

Doporučujeme mít rozhraní API před jakýmkoli mechanismem úložiště, který používáte. Rozhraní API funguje jako vrátný a vynucuje, že uživatelé získají přístup jenom k informacím, ke kterým by měli získat přístup.

Obrázek č. 4. Architektura RAG s více tenanty s zapouzdřením víceklientské logiky přístupu k datům tenanta

Jak jsme uvedli dříve v tomto článku, uživatelský přístup k datům může být omezen:

• Tenant uživatele
• Funkce platformy
• Vlastní pravidla filtrování nebo oříznutí zabezpečení

Tato vrstva by měla mít následující odpovědnosti:

• Směrování dotazu do úložiště konkrétního tenanta v modelu úložiště na tenanta
• Výběr pouze dat z tenanta uživatele ve víceklientských úložištích
• Použití vhodné identity pro uživatele k podpoře logiky autorizace s podporou platformy
• Vynucení vlastní logiky oříznutí zabezpečení
• Ukládání protokolů přístupu k informacím o uzemnění pro účely auditu

Kód, který potřebuje přístup k datům tenanta, by neměl být schopen dotazovat se přímo na back-endová úložiště. Všechny požadavky na data by měly protékat touto vrstvou rozhraní API. Tato vrstva rozhraní API poskytuje jediný bod zásad správného řízení nebo vrstvy zabezpečení nad daty tenanta. Tento přístup udržuje logiku autorizace přístupu k datům tenanta a uživatelů z různých oblastí aplikace. Tato logika je zapouzdřená ve vrstvě rozhraní API. Tato zapouzdření usnadňuje ověřování a testování řešení.

Shrnutí

Při návrhu řešení pro odvozování víceklientských RAG musíte vzít v úvahu, jak pro tenanty navrhnout základní datové řešení. Seznamte se s počtem tenantů a množstvím uložených dat pro jednotlivé tenanty. Tyto informace vám pomůžou navrhnout řešení tenantů dat. Doporučujeme implementovat vrstvu rozhraní API, která zapouzdřuje logiku přístupu k datům, včetně logiky více tenantů i filtrování.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

• John Downs | Hlavní softwarový inženýr
• Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data &AI

Další kroky

Související prostředky

• Architektura saaS a víceklientských řešení
• Základní referenční architektura pro chat OpenAI
• Základní referenční architektura pro chat OpenAI
• Přístup k Azure OpenAI a dalším jazykovým modelům prostřednictvím brány