Udostępnij za pośrednictwem

LLMs i Azure OpenAI w generowaniu plików wyszukiwania (RAG) (wersja zapoznawcza)

  • Artykuł

Ważne

Jest to funkcja w wersji zapoznawczej. Informacje te dotyczą funkcji w wersji wstępnej, która może zostać znacznie zmodyfikowana przed jej udostępnieniem. Firma Microsoft nie udziela żadnych gwarancji, jawnych lub domniemanych, w odniesieniu do informacji podanych w tym miejscu.

W tym artykule przedstawiono ilustrujący przykład używania modeli dużych języków (LLMs) i platformy Azure OpenAI w kontekście wzorca generowanie informacji o nowej wersji (RAG). W szczególności opisano sposób zastosowania tych technologii w różnych strefach docelowych przy jednoczesnym uwzględnieniu ważnych informacji na temat sposobu działania tych technologii.

Scenariusz

Często spotykaną sytuacją jest użycie LLM do konwersacji przy użyciu własnych danych za pośrednictwem wzorca Pobierania generowania (RAG). Ten wzorzec pozwala na użycie umiejętności z porozumień w programie LLM i generowanie odpowiedzi na podstawie określonych danych bez konieczności dostrojenia modelu. Ułatwia ono płynne zintegrowanie oprogramowania LLM z istniejącymi procesami biznesowymi lub rozwiązaniami.

Cloud for Sovereignty — architektura odwołań AI i LLM

Microsoft Cloud for Sovereignty zawiera architekturę referencyjną ilustrujące typową architekturę wyszukiwania i generowania (RAG) w strefie docelowej (SLZ). Zawiera omówienie typowych i zalecanych opcji technologii implementacji, terminologii, zasad technologii, wspólnych środowisk konfiguracyjnych i konfigurowania odpowiednich usług.

Architektura referencyjna konfiguracji AI i LLM z suwerennymi barierami ochronnymi.

Pobierz plik PDF do wydrukowania tego schematu architektury.

Kluczowe etapy/przepływ danych są następujące:

Strefy docelowe aplikacji

W hierarchii grupy zarządzania te usługi są umieszczane w subskrypcji w niezawieranej grupie zarządzania.

Źródła danych i potoki transformacji

Źródła danych i potoki transformacji często istnieją w ramach organizacji jako wiersza operacji biznesowych. Kiedy integrujesz aplikacje LLM, takie jak implementacje z istniejącymi danymi, stają się one nowymi obciążeniami.

W celu zapewnienia kontroli przepływu danych architektura odwołania zaleca wyrównanie danych domeny ze strefami lądowania danych dla źródeł danych i miejsc, w których mają być zamykane potoki transformacji danych w celu utworzenia produktów danych używanych przez aplikacje LLM. Ta metoda zapewnia dokładne zarządzanie danymi obsługiwanymi w rozwiązaniu opartym na llm, które jest hostowane oddzielnie.

Komponenty transformacji danych wykorzystują różne technologie i usługi w celu przekształcenia danych w format, który może być wyszukiwany i używany przez aplikację opartą na LLM za pomocą wyszukiwania semantycznego lub wektorowego w celu uziemienia. Te potoki mogą działać samodzielnie lub mogą korzystać z usług sztucznej inteligencji, takich jak usługi sztucznej inteligencji Azure lub Azure OpenAI, w celu przekształcenia danych w celu umieszczenia ich w bazie danych wyszukiwania wektorowego lub semantycznego.

Podczas używania usług AI komunikacja równorzędna sieciowa zawsze udostępni je (za pośrednictwem centrum lub bezpośrednio) za pośrednictwem ich prywatnych punktów końcowych. Ze względów bezpieczeństwa i zgodności składniki transformacji danych mogą określić, jakie dane i w jakim formacie są dostępne w bazie danych wyszukiwania obciążenia llm.

Składniki transformacji danych mogą używać różnego rodzaju źródeł danych, aby oferować dane o optymalnej wydajności w bazach danych wyszukiwania, na których opierają się obciążenia LLM. Te źródła danych mogą być bazami danych SQL, źródłami danych lub nawet maszyny wirtualne hostującym niestandardowe rozwiązania danych, zależnie od środowiska klienta.

Źródła danych nie powinny być dostępne bezpośrednio przez aplikację Grawertor, ale zamiast tego powinny być dostępne tylko poza prywatnymi granicą sieci wirtualnej. To oznacza bezpośrednią integrację z siecią wirtualną Microsoft Azure (np. w przypadku maszyny wirtualnej), usług Private Link lub usług sieci wirtualnej (tylko jeśli nie jest dostępna bezpośrednia integracja z siecią wirtualną).

Składniki związane z AI i LLM powinny być hostowane jako obciążenia w ich subskrypcji w grupie zarządzania Corp lub Online (w zależności od tego, czy jest wymagany dostęp publiczny, czy nie). Tymi składnikami są:

Usługa OpenAI Azure hermetyzuje operacje LLM, takie jak GPT i osadzanie tekstu, takie jak Ada, udostępniając je za pośrednictwem standardowych interfejsów API dostarczonych przez Azure OpenAI do aplikacji Orchestrator.

Aplikacja orkiestracji działa jako przód z interfejsem API lub interfejsem opartym na systemie UX i umożliwia tworzenie różnych kroków wymaganych do tworzenia interfejsów opartych na RAG. Często jest to aplikacja sieci Web lub interfejs API sieci Web. Kroki te zazwyczaj obejmują:

  • ściąganie danych z aparatów wyszukiwania monitów o monity
  • ściąganie danych ze źródeł danych w celu monitu o monit
  • poprawne nadsyłanie różnych żądań do llm

Aplikacja Orchestrator przechowuje historię wysłanych żądań i otrzymanych odpowiedzi, aby zapewnić, że usługa Azure OpenAI zostanie uziemiona na podstawie poprzednich interakcji. Na przykład w trakcie rozmowy, takiej jak ChatGPT lub Bing Chat, aplikacja orkiestracji obsługuje lub buforuje historię sesji rozmowy, tak aby była rozsyłana w przepływie rozmowy przez zaplecza usługi LLM.

W środowisku Online punkt końcowy aplikacji orkiestracji powinna być jedyną aplikacją dostarczaną za pośrednictwem serwera punkt końcowy chronionej przez Zaporę aplikacji sieci Web i usługi ochrony DDoS. Jeśli rozwiązanie jest hostowane w środowisku Corp, bez publicznych punktów końcowych, albo jest hostowane w usłudze zintegrowanej bezpośrednio z siecią wirtualną, na przykład na maszynach wirtualnych lub zestawach skalowania SCALONY, albo jest używane usługi obsługi punktów końcowych usługi Private Link lub Virtual Network, co ma miejsce w przypadku usług Azure App Services.

Usługi wyszukiwania udostępniają dane z różnych źródeł danych w formacie zoptymalizowanym pod kątem efektywnego wykorzystania w celu szybkiego uziemienia usług LLM. Firma Microsoft proponuje połączenie specjalizacji i wyszukiwania zasobów w celu osiągnięcia najlepszych wyników w zakresie monitów opartych na usługach wyszukiwania obsługiwanych przez usługę Wyszukiwanie Azure AI Search. Użycie rankingów semantycznych w sposób znaczny poprawia przydatność wyszukiwania, używając znajomości języka do klasyfikacji wyników wyszukiwania. Poprawia to obsługę aplikacji RAG dzięki temu, że monity stają się bardziej dokładne, dzięki lepszemu wyszukiwaniu wyników wyszukiwania z poziomu usługi wyszukiwania przed wysłaniem żądania do LLM.

Kombinacja usług AI może być używana do tworzenia dostosowanych interfejsów dla użytkowników końcowych za pośrednictwem orkiestracji lub do optymalizowania procesów in niestosowania danych. Załóżmy, że używając usługi rozpoznawania formularzy, takiej jak usługa Analiza dokumentu Azure AI, można wyodrębnić ustrukturalnione informacje z formularzy oraz efektywnie przetwarzać i podsumowywać dane wejściowe użytkowników. Ta usługa może następnie współpracować z LLM w celu podsumowania najważniejszych ustaleń kluczowych wyników kluczowych z rozpoznanych danych wejściowych formularza. Innym scenariuszem jest użycie usługi rozpoznawania dokumentów do konwertowania dokumentów w różnych formatach, takich jak formatach PDF lub dokumenty programu Word na tekst. Następnie usługa osadzenia tekstu LLM może użyć tego tekstu do dalszej analizy.

Usługi Private połączone są wdrażane dla wszystkich składników, tak aby wszystkie usługi były dostępne tylko w środowisku prywatnym. Jedyną wyjątkiem może być aplikacja orkiestracji, która hostowana w strefie docelowej usługi Online może być publicznie oferowana za zaporą aplikacji sieci Web lub porównywalnymi usługami.

Składniki infrastruktury

Składniki infrastruktury mogą być hostowane w ramach obciążenia lub centralnie w centrum lub w subskrypcji tożsamości.

Głównym składnikiem infrastruktury implementacji suwerennej strefy docelowej jest Centrum połączeń platform, które jest siecią wirtualną dostarczaną przez każde wdrożenie strefy docelowej. Jest ono umieszczane w subskrypcji połączeń w grupie zarządzania platformami.

Udostępnione składniki sieci są umieszczane w sieci wirtualnej koncentratora. Komponenty te zazwyczaj obejmują:

  • Obwody usługi ExpressRoute lub bramy sieci VPN do łączności z siecią firmową firmy, agencji lub organizacji.

  • Zapory sieciowe mogą być wdrażane za pomocą urządzeń lub kombinacji ofert Azure Firewall, w tym Web Application Firewall. Te rozwiązania umożliwiają inspekcję ruchu, filtrowanie i rozsyłanie.

  • Składniki ochrony przed atakami DDoS służące do ochrony obciążeń przed rozproszonymi atakami typu "odmowa usługi".

  • Prywatne strefy DNS dla wszystkich typów usług używanych w całym krajobrazie wirtualnych centrów danych zaimplementowane za pomocą stref docelowych.

  • Komunikacja równorzędna sieci wirtualnych służąca do łączenia sieci wirtualnych różnych obciążeń, takich jak źródła danych, transformacja i składniki LLM, za pośrednictwem sieci koncentratora.

  • Zasady kontrolują przepływ ruchu przez zapory koncentratora w razie potrzeby.

Kwestie wymagające rozważenia

Na diagramie architektury odwołania przedstawiono przykładową architekturę obejmującą typowe składniki obciążenia opartego na RAG LLM, w kontekście strefy docelowej. Należy pamiętać o kilku kwestii, które nie zostały uwzględnione w poprzednich sekcjach.

Dostosowanie do zasad z dobrze sytego programu i struktury Cloud Adoption Framework

W poprzednich sekcjach wspomniano o niektórych aspektach wyrównania związanych z dobrze zaprojektowanej architektury (WAF) i Cloud Adoption Framework (CAF). Należy zwrócić uwagę, że wszystkie decyzje dotyczące architektury powinny być w pełni zgodne z podstawowymi zasadami architektury CAF i stref docelowych Azure, analizą w chmurze CAF oraz zasadami WAF, w tym perspektywą WAF na platformie Azure OpenAI.

Mimo że w środowisku strefy docelowej nie są uwzględnione standardowe procedury, należy wziąć pod uwagę kilka obszarów prac związanych z LLM i AI. Najlepiej jest postępować zgodnie z planem zgodności z planem bazowym Azure i standardami inicjatyw zasad podstaw Sovereignty podczas projektowania i definiowania infrastruktury dla subskrypcji obciążenia.

Najważniejsze kwestie, które należy wziąć pod uwagę podczas pracy z aplikacjami opartymi na RAG LLM, są następujące:

Wybór miejsca i regionu dla danych

Konsekwencyjnie konsekwencji danych, a zatem może ograniczyć wdrożenia w określonych regionach platformy Azure w wersji SLZ. Wybór regionu dla prac LLM jest ograniczony przez dostępność wymaganych usług:

  • Sprawdź, czy zarówno usługa Azure OpenAI, jak i usługa Azure AI Search są dostępne w regionie docelowym, w którym hostują dane i dane w trakcie pracy ze względów bezpieczeństwa i/lub przyczyny. Ponadto usługi te są ważne z punktu widzenia perspektyw wydajności dla doświadczenia użytkownika końcowego w pracy z aplikacją.

  • Po drugie, gdy patrzysz na platformę Azure OpenAI, dostępność odpowiednich modeli LLM jest ważna, ponieważ nie wszystkie modele są jednakowo dostępne we wszystkich regionach.

  • Jeśli źródła danych lub inne usługi cognitive nie są dostępne w wskazanym regionie docelowym, może być możliwe ich znalezienie i obsługa w innym regionie w celu dostosowania ich do wymagań dotyczących jakości danych. Jednak ze względów wydajności usługa Azure OpenAI i usługa Azure AI Search muszą znajdować się w tym samym regionie, co aplikacja orkiestracji.

Sieć

W środowiskach Corp nie są dozwolone publiczne punkty końcowe. W związku z tym wszystkie usługi muszą być przechowane w sieci wirtualnej. W zależności od usługi może być dostępne funkcje bezpośredniego przetwarzania, takie jak maszyny wirtualne lub klastry AKS, łącze prywatne lub punkty końcowe usługi sieci wirtualnej. Punkty końcowe usługi sieci wirtualnej powinny być w miarę możliwości zastępowane przez łącze prywatne.

Oprócz możliwości dostępu publicznego należy wyłączyć dla wszystkich usług. Na koniec należy włączyć funkcję wymuszania zasad za pomocą zasad Azure, tak aby dostęp publiczny nie został przypadkowo włączony dla usług, których nie można utworzyć odpowiednich zasad odmowa. Strategii szczegółowej jest włączenie odpowiednich funkcji inspekcji dla wszystkich usług.

Szyfrowanie podczas pracy i w przechowaniu

Większość usług na platformie Azure obsługuje zarówno szyfrowanie w systemie, jak i w przypadku funkcji rest. Włącz szyfrowanie podczas pracy w terenie i w różnych usługach, gdy są dostępne. Włącz najnowszą wersję standardu TLS (obecnie TLS 1.2) dla szyfrowania szyfrowania.

Tożsamości zarządzane

Tożsamości zarządzane są używane we wszystkich usługach i komunikacji między usługami w celu uniknięcia zarządzania tajnymi danymi poświadczeń.

Klucz nie jest przechowywny w Magazynie kluczy

Gdy są wymagane zasoby zabezpieczeń, takie jak certyfikaty, należy włączyć klucz do tajnych danych w Magazynie kluczy, aby zachować zgodność.

Grupy zabezpieczeń sieci i aplikacji

W bezpiecznym środowisku wymuszane jest użycie sieciowych grup zabezpieczeń (NSG) i grup zabezpieczeń aplikacji (ASG). Brakujące grupy zabezpieczeń prowadzą do wdrożeń niekomputerowych. Typowe porty SSL są przydatne w przypadku większości usług, na których korzystają obciążenia LLM/RAG, ponieważ są oparte na protokole HTTPS. Do wydychanych danych ze źródeł do baz danych wyszukiwania i baz danych są wymagane określone porty. W strefach docelowych Corp nie są dozwolone publiczne adresy IP. Z tego powodu w strefach docelowych Corp nie są dozwolone wszystkie usługi muszą być dostępne tylko w sieci wirtualnej, co wymaga użycia punktów końcowych usługi Private Link lub Virtual Network w przypadku usług PaaS.

Więcej zabezpieczeń i bezpieczeństwo

Najważniejsze i najważniejsze obszary, które zostały uwzględnione we wcześniejszych sekcjach projektowania infrastruktury i aplikacji, można ponownie wykorzystać poza strefami docelowymi Azure. Inne globalne zasady są związane z centralnie zarządzanymi zasobami, takimi jak obszary robocze analizy dzienników lub wdrożenia programu Microsoft Sentinel w obszarach docelowych na skali enterprise. Podczas procesu projektowania infrastruktury i aplikacji kluczowe znaczenie ma to, aby uwzględnić te centralnie zarządzane zasoby. Zaniedbanie w tym celu może spowodować dodatkowe nakłady pracy i czas po wdrożeniu. Dzięki funkcji zgodności z zasadami platformy Azure po wdrożeniu można zidentyfikować zasoby, które nie są zgodne. Ponadto zarówno strefy docelowe Azure, jak i strefy docelowe Azure zawierają zasady DeployIfNotExists dla wielu zasobów, co jeszcze bardziej upraszcza proces.

Przykłady takich danych to:

  • Aktywacja rejestrowania się w centralnie zarządzanych obszarach roboczych analizy dzienników.

  • Integracja z Azure Security Center lub Microsoft Defender for Cloud.

  • Integracja z informacjami o zabezpieczeniach zarządzanie wydarzeniami (SIEM), takich jak Microsoft Sentinel.

  • Integracja z centralnie zarządzanymi zaporami, zaporami aplikacji sieci Web lub ochroną DDoS.

Oto kilka pierwotnej konfiguracji, które mogą się okazać wymaganiami po początkowym wdrożeniu. Zalecamy przetestowanie wdrożeń w strefie docelowej testowej i iteratively integrowanie wdrożenia z bazą kodu infrastruktury i aplikacji. Jeśli nie jest to całkowicie możliwe, wiele z tych adresów można rozwiązać po wdrożeniu z zasadami DeployIfNotExists.

Wdrożyć ten scenariusz

Aby można było korzystać z modeli dużych języków (LLMs) i platformy Azure OpenAI w oparciu o wzorzec pobierania i generowania plików (REG) w obrębie stref docelowych, należy najpierw wdrożyć i skonfigurować strefę docelową (SLZ), a następnie zastosować inicjatywy policyjne związane z planem bazowym w tej strefie. Aby uzyskać szczegółowy przegląd SLZ i wszystkich jego możliwości, zobacz dokumentację suwerennych stref docelowych w serwisie GitHub.

System SLZ udostępnia środowisko, które oferuje zestawy zasad i zasad, wymuszanie zabezpieczeń i spójną infrastrukturę podstawową do wdrażania prac i aplikacji. SLZ opiera się na strefach lądowania Azure i rozszerza ją o poręcze i mechanizmy bezpieczeństwa specyficzne dla wymagań suwerenności.

Aby pomóc klientom skrócić czas osiągania korzyści, jednocześnie pomagając im w osiąganiu celów związanych ze zgodnością, Microsoft Cloud for Sovereignty zawiera gotowe do użycia szablony obciążeń, które można konsekwentnie wdrażać i obsługiwać w powtarzalny sposób. Szablony zadań są dostosowane do Podstawowego planu inicjatyw zasad suwerenności, Portfolio zasad Cloud for Suwereignty i Domyślne zasady Azure Landing Zone.

Szablon Asystent informacji agent

Szablon Information Asystent agent stanowi punkt wyjścia dla organizacji do tworzenia własnych niestandardowych funkcji generatywnej sztucznej inteligencji w celu rozszerzenia możliwości Azure OpenAI na użytkowników organizacji i ich dane domenowe bez konieczności dostrajania modelu. Możesz go wdrożyć w Cloud for Sovereignty i wyrównać z architekturą referencyjną i wytycznymi podanymi w tym artykule. Szablon Asystent informacji agent jest zgodny z zakresem grupy zarządzania Sovereign Landing Zone Online przy użyciu konfiguracji wdrożenia w trybie bezpiecznym. Wkrótce zostanie udostępniona obsługa zakresu grupy zarządzania korporacjami .

Szablon agent to połączenie kodu, dokumentacji i zasobów edukacyjnych udostępnianych bezpłatnie klientom i partnerom, które mogą pomóc w skróceniu czasu uzyskania wartości.

Aby uzyskać więcej informacji na temat wdrażania i konfigurowania Asystent informacji, zobacz dokumentację szablonu Information Asystent agent w witrynie GitHub. Aby zapoznać się z przypadkami użycia, które możesz osiągnąć za pomocą tego szablonu agent, zobacz Informacje Asystent Wideo.