Retrieval-Augmented Generation (RAG) to wzorzec tworzenia aplikacji, w których podstawowe modele są używane do rozumowania za pośrednictwem zastrzeżonych informacji lub innych informacji, które nie są publicznie dostępne w Internecie. Ogólnie rzecz biorąc, aplikacja kliencka wywołuje warstwę aranżacji, która pobiera odpowiednie informacje z magazynu danych, takiego jak wektorowa baza danych. Warstwa aranżacji przekazuje te dane w ramach kontekstu jako dane uziemienia do podstawowego modelu.
Rozwiązanie wielodostępne jest używane przez wielu klientów, gdzie każdy klient (dzierżawa) składa się z wielu użytkowników z tej samej organizacji, firmy lub grupy. W scenariuszach wielodostępnych należy upewnić się, że dzierżawcy lub osoby w ramach dzierżaw mogą uwzględniać tylko dane uziemienne, które są autoryzowane do wyświetlenia.
Chociaż istnieją wielodostępne obawy poza zapewnieniem, że użytkownicy uzyskują dostęp tylko do informacji, które mają zobaczyć, ten artykuł koncentruje się na tym aspekcie wielodostępności. Artykuł rozpoczyna się od przeglądu architektur RAG z jedną dzierżawą, omawia wyzwania związane z wielodostępnością za pomocą rozwiązania RAG i niektóre typowe podejścia do naśladowania, a także kończy się bezpiecznymi zagadnieniami i zaleceniami dotyczącymi wielodostępności.
Uwaga
W tym artykule omówiono niektóre funkcje specyficzne dla usługi Azure OpenAI, takie jak Azure OpenAI On Your Data. Oznacza to, że większość zasad omówionych w tym dokumencie ma zastosowanie do większości podstawowych modeli sztucznej inteligencji, niezależnie od platformy hosta.
Architektura RAG z jedną dzierżawą z orkiestratorem
Rysunek 1. Architektura RAG z jedną dzierżawą
Przepływ pracy
W tej architekturze RAG z jedną dzierżawą orkiestrator ponosi odpowiedzialność za pobieranie odpowiednich zastrzeżonych danych dzierżawy z magazynów danych i dostarczanie ich jako danych do podstawowego modelu. Poniżej przedstawiono ogólny przepływ pracy:
- Użytkownik wysyła żądanie do inteligentnej aplikacji internetowej.
- Dostawca tożsamości uwierzytelnia osoby żądającej.
- Aplikacja inteligentna wywołuje interfejs API orkiestratora za pomocą zapytania użytkownika i tokenu autoryzacji dla użytkownika.
- Logika aranżacji wyodrębnia zapytanie użytkownika z żądania i wywołuje odpowiedni magazyn danych, aby pobrać odpowiednie dane uziemienia dla zapytania. Dane uziemienia są dodawane do monitu wysyłanego do modelu podstawowego, na przykład modelu uwidocznionego w usłudze Azure OpenAI w następnym kroku.
- Logika aranżacji łączy się z interfejsem API wnioskowania modelu podstawowego i wysyła monit zawierający pobrane dane uziemienia. Wyniki są zwracane do inteligentnej aplikacji.
Aby uzyskać więcej informacji na temat szczegółów programu RAG, zobacz Projektowanie i opracowywanie rozwiązania RAG.
Architektura RAG z jedną dzierżawą z bezpośrednim dostępem do danych
Wariant architektury RAG z jedną dzierżawą korzysta z możliwości integracji usługi Azure OpenAI bezpośrednio z magazynami danych, takimi jak Usługa Azure Search. W tej architekturze nie masz własnego koordynatora lub orkiestrator ma mniej obowiązków. Interfejs API usługi Azure OpenAI ponosi odpowiedzialność za wywołanie magazynu danych w celu pobrania danych uziemienia i przekazania tych danych do modelu językowego. Z kolei masz mniejszą kontrolę nad tym, jakie dane uzamierające mają być pobierane i mają znaczenie dla tych danych.
Uwaga
Usługa Azure OpenAI zarządzana przez firmę Microsoft integruje się z magazynem danych. Sam model nie integruje się z magazynami danych. Model odbiera dane uziemienia w dokładnie taki sam sposób, jak w przypadku pobierania danych przez koordynatora.
Rysunek 2. Architektura RAG z jedną dzierżawą z bezpośrednim dostępem do danych z usługi Azure OpenAI
Przepływ pracy
W tej architekturze RAG usługa zapewniająca podstawowy model ponosi odpowiedzialność za pobieranie odpowiednich zastrzeżonych danych dzierżawy z magazynów danych i używanie tych danych jako danych uzymierania do modelu podstawowego. Poniżej przedstawiono ogólny przepływ pracy (italicyzowane kroki są identyczne z architekturą RAG pojedynczej dzierżawy z przepływem pracy orkiestratora):
- Użytkownik wysyła żądanie do inteligentnej aplikacji internetowej.
- Dostawca tożsamości uwierzytelnia osoby żądającej.
- Następnie inteligentna aplikacja wywołuje usługę Azure OpenAI za pomocą zapytania użytkownika.
- Usługa Azure OpenAI łączy się z obsługiwanymi magazynami danych, takimi jak azure AI Search i Azure Blob Storage, aby pobrać dane uziemienia. Dane uziemienia są używane jako część kontekstu, gdy usługa Azure OpenAI wywołuje model języka OpenAI. Wyniki są zwracane do inteligentnej aplikacji.
Aby wziąć pod uwagę tę architekturę w rozwiązaniu wielodostępnym, usługa, taka jak Azure OpenAI, która uzyskuje bezpośredni dostęp do danych uziemienia, musi obsługiwać logikę wielodostępną wymaganą przez rozwiązanie.
Wielodostępność w architekturze RAG
W rozwiązaniach wielodostępnych dane dzierżawy mogą istnieć w magazynie specyficznym dla dzierżawy lub współistnieć z innymi dzierżawami w magazynie wielodostępnym. Mogą również istnieć dane w magazynie, który jest współużytkowany w dzierżawach. Tylko dane, które użytkownik ma uprawnienia do wyświetlenia, powinny być używane jako dane uziemowe. Użytkownicy powinni widzieć tylko wspólne (wszystkie dzierżawy) dane lub dane z dzierżawy z zastosowanymi regułami filtrowania, aby upewnić się, że widzą tylko dane, które są autoryzowane do wyświetlenia.
Rysunek 3. Architektura RAG — z wieloma dzierżawami magazynu danych
Przepływ pracy
Ten przepływ pracy jest taki sam jak w architekturze RAG z jedną dzierżawą z orkiestratorem z wyjątkiem kroku 4.
- Użytkownik wysyła żądanie do inteligentnej aplikacji internetowej.
- Dostawca tożsamości uwierzytelnia osoby żądającej.
- Aplikacja inteligentna wywołuje interfejs API orkiestratora za pomocą zapytania użytkownika i tokenu autoryzacji dla użytkownika.
- Logika aranżacji wyodrębnia zapytanie użytkownika z żądania i wywołuje odpowiednie magazyny danych, aby pobrać autoryzowane przez dzierżawę odpowiednie dane uziemienia dla zapytania. Dane uziemienia są dodawane do monitu wysyłanego do usługi Azure OpenAI w następnym kroku. Niektóre lub wszystkie poniższe kroki są wykonywane:
- Logika aranżacji pobiera dane uziemienia z odpowiedniego wystąpienia magazynu danych specyficznego dla dzierżawy, potencjalnie stosując reguły filtrowania zabezpieczeń w celu zwrócenia tylko danych, do których użytkownik ma uprawnienia dostępu.
- Logika aranżacji pobiera dane uziemania odpowiedniej dzierżawy z wielodostępnego magazynu danych, potencjalnie stosując reguły filtrowania zabezpieczeń w celu zwrócenia tylko danych, do których użytkownik ma uprawnienia dostępu.
- Logika aranżacji pobiera dane z magazynu danych współużytkowanego przez dzierżawców.
- Logika aranżacji łączy się z interfejsem API wnioskowania modelu podstawowego i wysyła monit zawierający pobrane dane uziemienia. Wyniki są zwracane do inteligentnej aplikacji.
Zagadnienia dotyczące projektowania danych wielodostępnych w programie RAG
Wybieranie modeli izolacji magazynu
Istnieją dwa główne podejścia architektoniczne do magazynowania i danych w scenariuszach wielodostępnych: magazyn na dzierżawę i magazyny wielodostępne. Te podejścia są dodatkiem do magazynów zawierających dane współużytkowane przez dzierżawy. Ta sekcja dotyczy każdego podejścia. Należy zauważyć, że rozwiązanie wielodostępne może używać kombinacji tych metod.
Magazyn na dzierżawę
W magazynie na dzierżawę, jak sugeruje nazwa, każda dzierżawa ma własny magazyn. Zalety tego podejścia obejmują zarówno dane, jak i izolację wydajności. Dane każdej dzierżawy są hermetyzowane we własnym magazynie. W większości usług danych izolowane magazyny nie są podatne na hałaśliwy problem sąsiada innych dzierżaw. Takie podejście upraszcza również alokację kosztów, ponieważ cały koszt wdrożenia magazynu można przypisać jednej dzierżawie.
Wyzwania związane z tym podejściem mogą obejmować wyższe koszty związane z zarządzaniem i operacjami oraz wyższe koszty. Takie podejście nie powinno być brane pod uwagę, gdy istnieje duża liczba małych dzierżaw, takich jak scenariusze biznesowe-klient. Takie podejście może również być sprzeczne z ograniczeniami usługi.
W kontekście tego scenariusza sztucznej inteligencji magazyn na dzierżawę oznacza, że dane uziemienia niezbędne do wprowadzenia trafności do kontekstu będą pochodzić z istniejącego lub nowego magazynu danych, który zawiera tylko dane uziemienne dla dzierżawy. W tej topologii wystąpienie bazy danych jest dyskryminujące używane na dzierżawę.
Magazyny wielodostępne
W wielodostępnych magazynach wiele dzierżaw współistnieje w tym samym magazynie. Zalety tego podejścia obejmują potencjał optymalizacji kosztów, możliwość obsługi większej liczby dzierżaw niż model magazynu na dzierżawę oraz niższe koszty związane z zarządzaniem ze względu na niższą liczbę wystąpień sklepu.
Wyzwania związane z używaniem magazynów udostępnionych obejmują konieczność zapewnienia izolacji danych, zarządzania danymi, potencjalnego hałaśliwego antywzorzec sąsiada oraz trudności z przydzielaniem kosztów dzierżawcom. Zapewnienie izolacji danych jest najważniejszym problemem z tym podejściem. Masz obowiązek zaimplementowania podejścia zabezpieczeń w celu zapewnienia, że dzierżawcy będą mogli uzyskiwać dostęp tylko do swoich danych. Zarządzanie danymi może być również wyzwaniem, jeśli dzierżawcy mają różne cykle życia danych, które mogą wymagać operacji, takich jak tworzenie indeksów w różnych harmonogramach.
Niektóre platformy mają funkcje, które można wykorzystać podczas implementowania izolacji danych dzierżawy w magazynach udostępnionych. Na przykład usługa Azure Cosmos DB ma natywną obsługę partycjonowania i fragmentowania, dlatego często używa się identyfikatora dzierżawy jako klucza partycji, aby zapewnić pewien poziom izolacji między dzierżawami. Usługi Azure SQL i Postgres Flex obsługują zabezpieczenia na poziomie wiersza, chociaż ta funkcja nie jest często używana w rozwiązaniach wielodostępnych, ponieważ należy zaprojektować rozwiązanie wokół tych funkcji, jeśli planujesz ich używać w magazynie wielodostępnym.
W kontekście tego scenariusza sztucznej inteligencji oznaczałoby to, że dane uziemienia dla wszystkich dzierżaw są przesyłane w tym samym magazynie danych, w taki sposób, że zapytanie do tego magazynu danych musi zawierać dyskryminujące dzierżawy, aby zapewnić ograniczenie odpowiedzi w celu przywrócenia tylko odpowiednich danych w kontekście dzierżawy.
Magazyny udostępnione
Rozwiązania wielodostępne często zawierają dane współużytkowane przez dzierżawy. W przykładowym rozwiązaniu wielodostępnym dla domeny opieki zdrowotnej może istnieć baza danych, która przechowuje ogólne informacje medyczne lub informacje, które nie są specyficzne dla dzierżawy.
W kontekście tego scenariusza sztucznej inteligencji byłoby to ogólnie dostępny magazyn danych uziemienia, który nie wymaga specjalnie filtrowania na podstawie żadnej dzierżawy, ponieważ dane są istotne i autoryzowane dla wszystkich dzierżaw w systemie.
Tożsamość
Tożsamość jest kluczowym aspektem wielodostępnych rozwiązań , w tym bezpiecznego wielodostępnego systemu RAG. Inteligentna aplikacja powinna zostać zintegrowana z dostawcą tożsamości w celu uwierzytelnienia tożsamości użytkownika. Wielodostępne rozwiązanie RAG wymaga katalogu tożsamości, w którym są przechowywane tożsamości autorytatywne lub odwołania do tożsamości. Ta tożsamość musi przepływać przez łańcuch żądań, umożliwiając usługom podrzędnym, takim jak orkiestrator, a nawet samemu magazynowi danych, aby zidentyfikować użytkownika.
Wymagane jest również mapowanie użytkownika na dzierżawę , aby można było udzielić dostępu do tych danych dzierżawy.
Definiowanie wymagań dotyczących dzierżawy i autoryzacji
Podczas tworzenia wielodostępnego rozwiązania RAG należy zdefiniować dzierżawę dla rozwiązania. Dwa typowe modele do wyboru to business-to-business (B2B) i B2C (business-to-consumer). Ta determinacja pomaga poinformować o obszarach, które należy wziąć pod uwagę podczas tworzenia architektury rozwiązania. Zrozumienie liczby dzierżaw ma kluczowe znaczenie dla podejmowania decyzji o modelu magazynu danych. Duża liczba dzierżaw może wymagać modelu z wieloma dzierżawami na magazyn, podczas gdy mniejsza liczba może zezwalać na magazyn na model dzierżawy. Ilość danych na dzierżawę jest również ważna. Jeśli dzierżawcy mają duże ilości danych, które mogą uniemożliwić korzystanie z wielodostępnych magazynów z powodu ograniczeń rozmiaru magazynu danych.
W istniejących obciążeniach, które są rozszerzane w celu obsługi tego scenariusza sztucznej inteligencji, być może został już wybrany. Ogólnie rzecz biorąc, będzie można użyć istniejącej topologii magazynu danych dla danych uziemienia, jeśli magazyn danych może zapewnić wystarczającą trafność i spełnić inne wymagania niefunkcjonalne. Jeśli jednak wprowadzasz nowe składniki, takie jak dedykowany magazyn wyszukiwania wektorów jako dedykowany magazyn uziemienia, musisz podjąć tę decyzję, biorąc pod uwagę czynniki, takie jak bieżąca strategia sygnatury wdrożenia, wpływ płaszczyzny sterowania aplikacjami i wszelkie różnice cyklu życia danych dla dzierżawy (takie jak sytuacje związane z wydajnością płatności za wydajność).
Po zdefiniowaniu dzierżawy rozwiązania należy zdefiniować wymagania dotyczące autoryzacji danych. Chociaż dzierżawcy będą uzyskiwać dostęp tylko do danych z dzierżawy, wymagania dotyczące autoryzacji mogą być bardziej szczegółowe. Na przykład w rozwiązaniu opieki zdrowotnej mogą istnieć reguły, takie jak:
- Pacjent może uzyskiwać dostęp tylko do własnych danych pacjentów
- Pracownik służby zdrowia może uzyskiwać dostęp do danych swoich pacjentów
- Użytkownik finansowy może uzyskiwać dostęp tylko do danych związanych z finansami
- Audytor kliniczny może zobaczyć dane wszystkich pacjentów
- Wszyscy użytkownicy mogą uzyskiwać dostęp do podstawowej wiedzy medycznej w udostępnionym magazynie danych
W aplikacji RAG opartej na dokumentach możesz ograniczyć użytkownikom dostęp do dokumentów na podstawie schematu tagowania lub poziomów poufności ustawionych na dokumentach.
Gdy masz definicję dzierżawy i masz jasne informacje o regułach autoryzacji, użyj tych informacji jako wymagań dotyczących rozwiązania magazynu danych.
Filtrowanie
Filtrowanie, nazywane również przycinaniem zabezpieczeń, odnosi się do uwidaczniania tylko danych użytkownikom, do których mają uprawnienia do wyświetlenia. W scenariuszu wielodostępnym RAG użytkownik może zostać zamapowany na magazyn specyficzny dla dzierżawy. Nie oznacza to, że użytkownik powinien mieć dostęp do wszystkich danych w tym magazynie. W artykule Definiowanie wymagań dotyczących dzierżawy i autoryzacji omówiliśmy znaczenie definiowania wymagań dotyczących autoryzacji dla danych. Te reguły autoryzacji powinny być używane jako podstawa filtrowania.
Filtrowanie można wykonać przy użyciu funkcji platformy danych, takich jak zabezpieczenia na poziomie wiersza, lub może wymagać niestandardowej logiki, danych lub metadanych. Ponownie te funkcje platformy nie są często używane w rozwiązaniach wielodostępnych ze względu na konieczność projektowania systemu wokół tych funkcji.
Hermetyzowanie wielodostępnych logiki danych
Zaleca się posiadanie interfejsu API przed mechanizmem magazynu, którego używasz. Interfejs API działa jako strażnik, wymuszając, że użytkownicy uzyskują dostęp tylko do informacji, do których powinni uzyskać dostęp.
Rysunek 4. Wielodostępna architektura RAG z hermetyzacją interfejsu API hermetyzowania wielodostępnych logiki dostępu do danych dzierżawy
Jak wspomniano wcześniej w tym artykule, dostęp użytkowników do danych może być ograniczony przez:
- Dzierżawa użytkownika
- Funkcje platformy
- Niestandardowe reguły filtrowania/przycinania zabezpieczeń.
Ta warstwa powinna mieć następujące obowiązki:
- Kierowanie zapytania do magazynu specyficznego dla dzierżawy w modelu magazynu na dzierżawę
- Wybieranie tylko danych z dzierżawy użytkownika w magazynach wielodostępnych
- Użyj odpowiedniej tożsamości dla użytkownika do obsługi logiki autoryzacji z obsługą platformy
- Wymuszanie niestandardowego przycinania zabezpieczeń logiki
- Przechowywanie dzienników dostępu do informacji o uziemieniu na potrzeby inspekcji
Kod, który musi uzyskiwać dostęp do danych dzierżawy, nie powinien mieć możliwości bezpośredniego wykonywania zapytań dotyczących magazynów zaplecza. Wszystkie żądania dotyczące danych powinny przepływać przez tę warstwę interfejsu API. Ta warstwa interfejsu API zapewnia pojedynczy punkt ładu lub warstwy zabezpieczeń na podstawie danych dzierżawy. Takie podejście pozwala zachować logikę autoryzacji dostępu do danych dzierżawy i użytkowników przed krwawieniem do różnych obszarów aplikacji. Ta logika jest hermetyzowana w warstwie interfejsu API. Ta hermetyzacja ułatwia walidację i testowanie rozwiązania.
Podsumowanie
Podczas projektowania wielodostępnego rozwiązania wnioskowania RAG należy wziąć pod uwagę sposób tworzenia architektury rozwiązania danych uziemienia dla dzierżaw. Uzyskaj informacje na temat liczby dzierżaw i ilości przechowywanych danych dla dzierżawy. Te informacje ułatwiają projektowanie rozwiązania dzierżawy danych. Zalecamy zaimplementowanie warstwy interfejsu API, która hermetyzuje logikę dostępu do danych, w tym zarówno wielodostępną, jak i logikę filtrowania.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
- John Downs | Główny inżynier oprogramowania
- Daniel Scott-Raynsford | Starszy architekt rozwiązań partnerskich, dane i sztuczna inteligencja