Návrh zabezpečeného řešení pro víceklientské RAG inferencing

Retrieval-Augmented Generování (RAG) je vzor pro vytváření aplikací, které používají základní vzorové modely k práci s proprietárními informacemi nebo jinými daty, 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é řešení slouží více zákazníkům. Každý zákazník nebo tenant se 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, ke kterým mají oprávnění přistupovat.

Existují obavy týkající se víceklientského prostředí kromě zajištění, že uživatelé mají přístup výhradně k informacím, ke kterým mají oprávnění. Tento článek se ale zaměřuje na daný aspekt víceklientské architektury. Tento článek začíná přehledem architektur RAG s jedním tenantem. Diskutuje o výzvách, které můžete při víceklientské architektuře s RAG zaznamenat, a o některých běžných přístupech, které lze přijmout. Popisuje také víceklientské aspekty a doporučení pro lepší zabezpečení.

Poznámka

Tento článek popisuje několik funkcí specifických pro službu Azure OpenAI, jako je azure OpenAI ve vašich datech. Většinu principů popsaných v tomto článku však můžete použít pro základní modely AI na libovolné platformě.

Architektura RAG s jedním tenantem s orchestrátorem

V diagramu se uživatel připojí k inteligentní aplikaci. Inteligentní aplikace se připojí k zprostředkovateli identity. Inteligentní aplikace se pak připojí k orchestrátoru. Orchestrátor se připojuje k databázím a úložištům vektorů. Orchestrátor se pak připojí k základnímu modelu.

Pracovní postup

V této architektuře RAG s jedním tenantem orchestrátor načte relevantní proprietární data tenanta z úložišť dat a poskytuje je jako základní data modelu. Následující kroky popisují 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 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. Uzemňovací data se přidají do výzvy, která je odeslána do základového modelu, například modelu vystavené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á podkladová data. Výsledky se vrátí do inteligentní aplikace.

Další informace najdete v tématu Návrh a vývoj řešení RAG.

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

Tato varianta architektury RAG s jedním tenantem používá funkci On Your Data Azure OpenAI k přímé integraci s úložišti dat, jako je Azure AI 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 volá do úložiště dat, aby získalo podkladová data, a tato data předává jazykovému modelu. Tato metoda poskytuje menší kontrolu nad tím, jaká výchozí data načíst a jejich relevantnost.

Poznámka

Azure OpenAI spravuje Microsoft. Integruje se s úložištěm dat, ale samotný model se neintegruje s úložištěm dat. Model přijímá základní data stejným způsobem jako při načítání dat orchestrátorem.

V diagramu se uživatel připojí k inteligentní aplikaci. Inteligentní aplikace se připojí k zprostředkovateli identity. Inteligentní aplikace se pak připojí k Azure OpenAI. Azure OpenAI se připojuje k podporovaným úložištům dat, jako je Azure AI Search a Azure Blob Storage. Vyhledávání AI pak předává data jako součást kontextu jazykovému modelu.

Pracovní postup

V této architektuře RAG služba, která poskytuje nadřazený model, načte příslušná proprietární nájemcovská data z úložišť dat a tato data používá jako zakotvovací data k nadřazenému modelu. Následující kroky popisují pracovní postup vysoké úrovně. Kroky psané kurzívou jsou totožné s předchozí 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 volá Azure OpenAI s dotazem uživatele.
4. Azure OpenAI se připojuje k podporovaným úložištím dat, jako je služba AI Search a Azure Blob Storage, a načte základní data. Základní data se používají jako součást kontextu, když Azure OpenAI volá jazykový model OpenAI. Výsledky se vrátí do inteligentní aplikace.

Pokud chcete tuto architekturu použít ve víceklientském řešení, musí služba, která přímo přistupuje k podkladovým datům, jako je Azure OpenAI, podporovat víceklientské logiky, kterou vaše řešení vyžaduje.

Víceklientství v RAG architektuře

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. Data můžou být také v úložišti, které se sdílí napříč tenanty. Jako podkladová data by měla být použita pouze data, ke kterým má uživatel oprávnění. Uživatel by měl vidět jenom běžná nebo všechna data nebo data ze svého tenanta, která jsou filtrovaná, aby se zajistilo, že uvidí jenom data, ke kterým má oprávnění přistupovat.

V diagramu se uživatel připojí k inteligentní aplikaci. Inteligentní aplikace se připojí k zprostředkovateli identity. Inteligentní aplikace se pak připojí k orchestrátoru. Orchestrátor se připojuje k jednoprovozní databázi, víceklientské databázi nebo ke sdílené databázi. Orchestrátor se pak připojí k základnímu modelu.

Pracovní postup

Následující kroky popisují pracovní postup vysoké úrovně. Kroky psané kurzívou jsou shodné s architekturou RAG pro jednoho nájemníka a 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 volá rozhraní API orchestrátoru pomocí dotazu uživatele a autorizačního tokenu 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í dat autorizovaných pro tenanta a relevantních podkladových informací pro dotaz. Návrhová data jsou přidána do podnětu zaslaného do Azure OpenAI v následujícím kroku. Patří sem některé nebo všechny následující kroky:
   1. Logika orchestrace načítá základní data z příslušné instance úložiště dat specifické pro tenanta a potenciálně použije pravidla filtrování zabezpečení tak, aby vracela pouze data, ke kterým má uživatel oprávnění k přístupu.
   2. Logika orchestrace získá podkladová data příslušného nájemce z úložiště dat pro více nájemců a případně použije bezpečnostní pravidla filtrování, aby vrátila pouze data, ke kterým 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á podkladová data. Výsledky se vrátí do inteligentní aplikace.

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

Při návrhu víceklientských řešení odvozování RAG zvažte následující možnosti.

Volba modelu izolace úložiště

Dva hlavní přístupy architektury pro úložiště a data ve scénářích s více nájemci jsou úložiště pro každého nájemce a víceklientské úložiště. Tyto přístupy jsou kromě úložišť, která obsahují data sdílená napříč nájemníky. Vaše víceklientové řešení může používat kombinaci těchto přístupů.

Provozovna pro každého nájemníka

V úložištích pro jednotlivé nájemce má každý nájemce 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 od jiných uživatelů. 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.

Tento přístup může představovat výzvy, jako je vyšší správa a provozní režie a vyšší náklady. Tento přístup byste neměli používat, pokud máte velký počet malých tenantů, jako je ve scénářích typu business-to-consumer. Tento přístup může také dosáhnout nebo překročit limity služby .

V kontextu tohoto scénáře AI úložiště na každého jednotlivého nájemce znamená, že nezbytná základní data zajišťující relevanci v rámci kontextu pochází z existujícího nebo nového úložiště dat, které obsahuje pouze základní data pro nájemce. V této topologii je instance databáze diskriminátorem, který se používá pro každého tenanta.

Úložiště s více nájemníky

Ve víceklientských úložištích spoluexistují data více nájemců ve stejném úložišti. Mezi výhody tohoto přístupu patří potenciál optimalizace nákladů, schopnost zpracovávat větší počet tenantů než u modelu jedno úložiště na tenanta a nižší režijní náklady na správu díky nižšímu počtu instancí úložiště.

Problémy při používání sdílených úložišť zahrnují potřebu izolace a správy dat, potenciál antipatternu hlučného sousedaa složitější přidělování nákladů tenantům. Izolace dat je nejdůležitějším problémem při použití tohoto přístupu. Potřebujete implementovat zabezpečené přístupy, abyste zajistili, že tenanti budou mít přístup jenom k jejich datům. Správa dat může být také náročná, pokud mají tenanti různé životní cyklus dat, které vyžadují operace, jako je vytváření indexů podle různých plánů.

Některé platformy mají funkce, které můžete použí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í dat a shardování. Obvykle se jako klíč oddílu používá identifikátor tenanta, který poskytuje určitou izolaci mezi tenanty. Flexibilní server Azure SQL a Azure Database for PostgreSQL podporují zabezpečení na úrovni řádků. Tyto funkce se ale obvykle nepoužívají ve víceklientských řešeních, protože pokud máte v úmyslu je používat ve víceklientských úložištích, musíte řešení navrhnout kolem těchto funkcí.

V rámci tohoto scénáře umělé inteligence se data pro všechny nájemníky slučují ve stejném úložišti dat. Proto váš dotaz na toto úložiště dat musí obsahovat diskriminátor tenanta, aby se zajistilo, že odpovědi budou omezené tak, aby v kontextu tenanta vrátily jenom relevantní data.

Sdílené obchody

Víceklientová řešení často sdílejí data napříč tenanty. V příkladu víceklientských řešení pro zdravotnickou doménu může databáze ukládat obecné lékařské informace nebo informace, které nejsou specifické pro tenanta.

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

Identita

Identity je klíčovým aspektem víceklientských řešení, včetně víceklientských řešení RAG. Inteligentní aplikace by se měla integrovat s zprostředkovatelem identity, aby ověřila identitu uživatele. Řešení RAG s více tenanty potřebuje adresář identit , který ukládá autoritativní identity nebo odkazy na identity. Tato identita musí protékat řetězem požadavků a umožnit podřízeným službám, jako je orchestrátor nebo samotné úložiště dat, identifikovat uživatele.

Potřebujete také způsob, jak namapovat uživatele na tenanta, abyste mohli udělit přístup k datům daného 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ří modely business-to-business a business-to-consumer. Model, který zvolíte, vám pomůže určit, jaké další faktory byste měli při sestavování řešení zvážit. Pochopení počtu tenantů je důležité pro výběr modelu úložiště dat. Velký počet nájemců může vyžadovat model, který má pro každý obchod více nájemců. Menší počet nájemníků může umožňovat model obchodu na nájemníka. Důležité je také množství dat pro každého tenanta. Tenanti, kteří mají velké objemy dat, vám můžou zabránit v používání víceklientských úložišť kvůli omezením velikosti úložiště dat.

Pokud máte v úmyslu rozšířit stávající úlohu tak, aby podporovala tento scénář umělé inteligence, možná jste toto rozhodnutí už udělali. Obecně řečeno, pro základní data můžete použít stávající topologii datového úložiště, pokud toto úložiště dat může poskytovat dostatečnou relevantnost a splňuje všechny ostatní nefunkční požadavky. Pokud ale plánujete zavést nové komponenty, jako je vyhrazené úložiště vektorového vyhledávání jako vyhrazené uzemněné úložiště, musíte toto rozhodnutí přesto učinit. Vezměte v úvahu faktory, jako jsou vaše aktuální strategie nasazení pomocí razítka, dopad řídicí roviny aplikace a všechny rozdíly v životním cyklu dat jednotlivých tenantů, například situace s platbou za výkon.

Po definování tenanta pro vaše řešení je potřeba definovat požadavky na autorizaci dat. Tenanti přistupují jenom k datům ze svého tenanta, ale vaše 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 vidět 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 přiřazených k dokumentům.

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í dat

Omezení přístupu pouze k datům, ke kterým mají uživatelé oprávnění, se označuje jako filtrování nebo zabezpečení oříznutím. 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. Definování požadavků na tenanta a autorizaci popisuje důležitost definování požadavků na autorizaci pro vaše data. Tato autorizační pravidla byste měli použít jako základ pro filtrování.

K implementaci filtrování můžete použít funkce datové platformy, jako je zabezpečení na úrovni řádků. Nebo můžete potřebovat vlastní logiku, data nebo metadata. Tyto funkce platformy se obvykle nepoužívají ve víceklientských řešeních, protože potřebujete navrhnout systém kolem těchto funkcí.

Zapouzdření víceklientské datové logiky

Doporučujeme mít rozhraní API před mechanismem úložiště, který používáte. Rozhraní API funguje jako vrátný, který pomáhá zajistit, aby uživatelé získali přístup jenom k informacím, ke kterým mají oprávnění přistupovat.

V diagramu se uživatel připojí k inteligentní aplikaci. Inteligentní aplikace se připojí k zprostředkovateli identity. Inteligentní aplikace se pak připojí k orchestrátoru. Orchestrátor se připojuje k vrstvě rozhraní API. Vrstva rozhraní API se připojuje k databázím a úložištům vektorů. Orchestrátor se pak připojí k základnímu modelu.

Přístup uživatelů k datům může být omezen:

• Tenant uživatele.
• Funkce platformy.
• Vlastní pravidla filtrování nebo omezení zabezpečení

Vrstva rozhraní API by měla:

• Dotaz nasměrujte do úložiště určeného pro jednotlivého tenanta v modelu úložiště pro jednotlivé tenanty.
• Vyberte pouze data z tenanta uživatele ve víceklientských úložištích.
• Pro podporu autorizační logiky s podporou platformy použijte příslušnou identitu uživatele.
• Prosazujte vlastní logiku omezení přístupu podle zabezpečení.
• Ukládat protokoly 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 přes vrstvu rozhraní API. Tato vrstva rozhraní API poskytuje jediný bod řízení nebo zabezpečení pro data vašeho tenanta. Tento přístup brání autorizační logice přístupu k datům tenanta a uživatelů do jiný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 víceklientských řešení odvozování RAG je nutné zvážit, jak navrhnout základní datové řešení pro vaše tenanty. Seznamte se s počtem tenantů a množstvím uložených dat pro jednotlivé tenanty. Pomocí těchto informací můžete navrhnout řešení rezidentnosti dat. Doporučujeme implementovat vrstvu rozhraní API, která zapouzdřuje logiku přístupu k datům, včetně víceklientské logiky a logiky filtrování.

Přispěvatelé

Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Hlavní autoři:

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

Pokud chcete zobrazit nepublikované profily LinkedIn, přihlaste se na LinkedIn.

Další krok

Návrh a vývoj řešení RAG

Související prostředky

• Architektura SaaS a řešení víceklientská
• Základní architektura chatu AI Foundry
• Základní referenční architektura chatu AI Foundry
• přístup k Azure OpenAI a dalším jazykovým modelům prostřednictvím brány