Sdílet prostřednictvím

LLM a Azure OpenAI ve vzoru rozšířeného generování načítání (RAG) (Preview)

  • Článek

Důležité

Toto je funkce Preview. Tyto informace se týkají funkce předběžné verze, která může být před vydáním podstatně upravena. Microsoft neposkytuje žádné záruky, výslovné ani předpokládané, týkající se zde uváděných informací.

Tento článek nabízí názorný příklad použití velkých jazykových modelů (LLM) a Azure OpenAI v kontextu vzoru rozšířeného generování načtení (RAG). Konkrétně zkoumá, jak můžete aplikovat tyto technologie v suverénního cílových zónách, a bere v úvahu důležité mantinely.

Scénář

Běžným scénářem je použití LLM k zapojení do konverzací pomocí vašich vlastních dat prostřednictvím vzoru rozšířeného generování načtení (RAG).. Tento vzor vám umožňuje využít schopnosti uvažování LLM a generovat odpovědi na základě vašich konkrétních dat, aniž byste museli model dolaďovat. Usnadňuje bezproblémovou integraci LLM do vašich stávajících obchodních procesů nebo řešení.

Cloud for Sovereignty – referenční architektura AI a LLM

Microsoft Cloud for Sovereignty poskytuje referenční architekturu, která ilustruje typickou architekturu rozšířeného generování načtení (RAG) v rámci suverénní cílové zóny (SLZ). Poskytuje přehled běžných a doporučených možností implementace technologií, terminologie, technologických principů, běžných konfiguračních prostředí a složení použitelných služeb.

Referenční architektura konfigurací AI a LLM se suverénními mantinely.

Stáhněte si PDF pro tisk tohoto schématu referenční architektury.

Klíčové fáze / tok dat jsou následující:

Cílové zóny aplikace

V hierarchii skupiny pro správu jsou tyto služby umístěny v předplatném v rámci nedůvěrné skupiny pro správu.

Zdroje dat a transformační kanály

V rámci organizace často existují zdroje dat a transformační kanály pro různé obchodní operace. Při integraci aplikací LLM, jako jsou implementace RAG, se stávajícími daty se stávají novými úlohami.

Pro zajištění řízení toku dat doporučuje referenční architektura datovou doménu v souladu s datovými cílovými zónami pro zdroje dat a umisťuje kanály transformace dat do blízkosti těchto zdrojů, aby se vytvořily datové produkty, které využívají LLM aplikace. Tento přístup zajišťuje přesnou správu dat poskytovaných řešení na bázi LLM, které je hostováno samostatně.

Komponenty transformace dat využívají různé technologie a služby k transformaci dat do formátu, který lze prohledávat a používat aplikací založenou na LLM prostřednictvím sémantického nebo vektorového vyhledávání pro základní účely. Tyto kanály mohou fungovat samy o sobě nebo mohou využívat služby umělé inteligence, jako jsou Azure služby umělé inteligence nebo Azure OpenAI, k transformaci dat pro umístění do databáze vektorového vyhledávání nebo sémantického vyhledávání.

Při používání služeb AI je síťový peering vždy zpřístupní (přes hub nebo přímo) prostřednictvím jejich privátních koncových bodů. Z důvodů správy, zabezpečení a souladu mají komponenty transformace dat oprávnění určovat, jaká data a v jakém formátu budou poskytnuta vyhledávací databázi pro úlohu LLM.

Komponenty pro transformaci dat mohou využívat různé druhy zdrojů dat, aby nabídly data s optimálním výsledkem vyhledávacím databázím, na kterých závisí úlohy LLM. Těmito datovými zdroji mohou být databáze SQL, datová jezera, nebo dokonce virtuální počítače hostující vlastní datová řešení, v závislosti na prostředí zákazníka.

Datové zdroje by neměly být přístupné přímo aplikací Orchestrator, ale místo toho by tyto zdroje měly být dostupné pouze ze soukromých hranic virtuální sítě. To vyžaduje přímou integraci virtuální sítě Microsoft Azure (například jako v případě virtuálních počítačů), služeb Private Link nebo koncových bodů služby pro virtuální síť (pouze v případě, že není k dispozici Private Link nebo přímá integrace virtuální sítě).

Komponenty související s umělou inteligencí a LLM by měly být hostovány jako úlohy ve vlastním předplatném v rámci skupiny pro správu Corp nebo Online (v závislosti na tom, zda je vyžadován veřejný přístup, nebo ne). Komponenty jsou následující:

Azure OpenAI Služba zapouzdřuje operace LLM, jako je GPT a vkládání textu, jako je Ada, a zpřístupňuje je prostřednictvím standardních rozhraní API poskytovaných Azure OpenAI Aplikace Orchestrator.

Aplikace Orchestrator funguje jako front-end s rozhraním založeným na API nebo UX a organizuje různé kroky potřebné pro vytváření prostředí založených na RAG. Často je to webová aplikace nebo webové rozhraní API. Mezi tyto kroky obvykle patří:

  • získávání dat ze sémantických vyhledávačů pro uzemnění pokynu
  • získávání dat z datových zdrojů pro uzemnění pokynu
  • správné řetězení různých požadavků do LLM

Aplikace Orchestrator uchovává historii odeslaných požadavků a přijatých odpovědí, aby bylo zajištěno, že služba Azure OpenAI bude uzemněna na základě předchozích interakcí. Například v prostředí podobném chatu, jako je ChatGPT nebo Bing Chat, aplikace Orchestrator udržuje nebo ukládá do mezipaměti historii konverzační relace tak, aby byla brána v úvahu v toku konverzace backendem služby LLM.

V prostředí Online by měl být koncový bod aplikace Orchestrator jediný, která je poskytován prostřednictvím veřejného koncového bodu chráněného bránou Web Application Firewall a službami ochrany DDoS. Pokud je Orchestrator hostován v prostředí Corp bez veřejných koncových bodů, je hostován buď ve službě, která je přímo integrována do virtuální sítě, jako jsou virtuální počítače nebo sady škálování virtuálních počítačů, nebo použijte služby, které podporují koncové body služby Private Link nebo virtuální sítě, jako je tomu v případě Azure App Services.

Search Services poskytuje data z různých zdrojů dat ve formátu optimalizovaném pro efektivní využití pro rychlé zakotvení služeb LLM. Společnost Microsoft navrhuje kombinaci vektorizace a sémantického vyhledávání pro dosažení nejlepších výsledků pro rychlé ukotvení založené na vyhledávacích službách, které podporuje Azure AI Vyhledávač. Použití sémantického hodnocení měřitelně zlepšuje relevanci vyhledávání tím, že k hodnocení výsledků vyhledávání využívá porozumění jazyku. To zlepšuje uživatelskou funkčnost u aplikací RAG, protože rychlé uzemnění se stává přesnějším díky lepším výsledkům vyhledávání z vyhledávací služby před odesláním požadavku do LLM.

Kombinace služeb umělé inteligence může být použita k vytvoření přizpůsobeného prostředí pro koncové uživatele prostřednictvím Orchestrator nebo k optimalizaci procesů zpracování dat. Představte si, že používáte službu rozpoznávání formulářů, jako je Azure AI Inteligentní Dokumenty k extrahování strukturovaných informací z formulářů a efektivnímu zpracování a shrnutí uživatelských vstupů. Tato služba pak může spolupracovat s LLM na shrnutí klíčových zjištění z těchto uznávaných formulářových vstupů. Další scénář zahrnuje použití služby pro rozpoznávání dokumentů k převodu dokumentů v různých formátech, jako jsou PDF nebo wordové dokumenty, na text. Následně může služba pro vkládání textu LLM vektorizovat tento rozpoznaný text pro další analýzu.

Služby Private Link jsou nasazeny pro všechny komponenty tak, že všechny služby jsou přístupné pouze v soukromém prostředí. Jedinou výjimkou může být aplikace Orchestrator, která, pokud je hostována v cílové zóně Online, může být nabízena veřejně za bránou Web Application Firewall nebo srovnatelnými službami.

Komponenty infrastruktury

Komponenty infrastruktury mohou být hostovány buď jako součást úlohy, nebo centrálně v centru nebo předplatném identity.

Centrální součástí infrastruktury implementace suverénní cílové zóny je centrum připojení platformy, což je virtuální síť poskytována při každém nasazení suverénní cílové zóny. Je umístěna v předplatném připojení v rámci skupiny pro správu platformy.

Sdílené síťové komponenty jsou umístěny ve virtuální síti rozbočovače. Mezi tyto komponenty obvykle patří:

  • ExpressRoute Circuits nebo VPN brány pro připojení k podnikové síti společnosti, agentury nebo organizace.

  • Firewally lze implementovat pomocí zařízení nebo kombinací Azure nabídek brány firewall, včetně brány firewall webových aplikací. Tato řešení umožňují kontrolu, filtrování a směrování provozu.

  • DDoS protection komponenty pro ochranu pracovních zátěží před distribuovanými útoky odmítnutí služby.

  • Soukromé zóny DNS pro všechny typy služeb používaných v celém prostředí virtuálních datových center implementované s přistávacími zónami.

  • Virtuální síťový peering pro připojení virtuálních sítí různých pracovních zátěží, jako jsou zdroje dat, transformace a komponenty LLM prostřednictvím sítě rozbočovače.

  • Zásady řídí tok provozu přes firewally hubu tam, kde je to potřeba.

Důležité informace

Schéma referenční architektury ukazuje reprezentativní příklad architektury zahrnující typické součásti úlohy založené na LLM RAG v kontextu suverénní cílové zóny. Je třeba mít na paměti několik aspektů, které nebyly uvedeny v předchozích částech.

Soulad s principy z rámcem Well-Architected a Cloud Adoption Framework

V předchozích částech byly stručně zmíněny některé aspekty souladu související s rámcem Well-Architected (WAF) a Cloud Adoption Framework (CAF). Je důležité si uvědomit, že všechna architektonická rozhodnutí by měla být plně v souladu se základními principy CAF a cílových zón Azure, analýzou CAF na cloudové škále a WAF, včetně pohledu WAF na Azure OpenAI.

I když je řešení mantinelů standardním postupem v prostředích cílových zón, je třeba vzít v úvahu další aspekty v několika oblastech pro úlohy LLM a AI. Nejlepší je dodržovat Soulad se základem zabezpečení Azure a standardy iniciativy základních zásad suverenity při navrhování a definování infrastruktury pro předplatné úlohy.

Hlavní úvahy, které je třeba zdůraznit pro aplikace založené na LLM RAG z těchto standardů, jsou:

Rezidence dat a výběr regionu

Suverenita ukládá přísné požadavky na rezidenci dat, a proto může omezovat nasazení na konkrétní oblasti Azure v SLZ. Výběr regionu pro úlohy LLM je omezen dostupností požadovaných služeb:

  • Ověřte, zda jsou Azure OpenAI a Azure AI Vyhledávač k dispozici ve vaší cílové oblasti, kde hostujete svá data a úloh z důvodů rezidence dat nebo blízkosti. Tyto služby jsou navíc důležité z hlediska výkonu pro funkčnost pro koncového uživatele s aplikací.

  • Za druhé, při pohledu na Azure OpenAI je důležitá dostupnost příslušných modelů LLM, protože ne všechny modely jsou stejně dostupné ve všech regionech.

  • Pokud ve vámi určené cílové oblasti nejsou dostupné zdroje dat nebo jiné kognitivní služby, možná je budete moci najít a provozovat v jiné oblasti v souladu s vašimi požadavky na umístění dat. Služba Azure OpenAI Service a Azure AI Vyhledávač však musí být z důvodu výkonu ve stejné oblasti jako aplikace Orchestrator.

Propojení

Veřejné koncové body nejsou povoleny v prostředí Corp. Proto musí být všechny služby zapouzdřeny ve virtuální síti. V závislosti na službě může nabízet možnosti přímého zapouzdření, jako jsou virtuální počítače nebo clustery AKS, Private Link nebo koncové body služby virtuální sítě. Koncové body služby virtuální sítě by měly být nahrazeny Private Link, kdykoli je to možné.

Kromě zapouzdření musí být u všech služeb deaktivován veřejný přístup. Nakonec by mělo být zapnuto vynucování zásad pomocí Azure Policy, aby nemohl být nikdy náhodně povolen veřejný přístup pro služby, kde nelze vytvořit odpovídající zásady odmítnutí. Strategií ochrany do hloubky je umožnit odpovídající schopnosti auditu pro všechny služby.

Šifrování neaktivních dat a v pohybu

Většina služeb v Azure podporuje funkce šifrování při přenosu i v klidu. Zapněte šifrování v klidu a při přenosu napříč všemi službami, pokud je k dispozici. Zapněte nejnovější verzi TLS, aktuálně TLS 1.2, pro šifrování přenosu.

Spravované identity

Používejte spravované identity pro všechny služby a komunikaci mezi službami, abyste se vyhnuli správě tajných klíčů pro přihlašovací údaje.

Rotace klíčů v Key Vault

Kdykoli jsou vyžadována bezpečnostní aktiva, jako jsou certifikáty, zapněte střídání klíčů pro tyto tajné klíče v Key Vault, abyste zachovali soulad.

Skupiny zabezpečení sítě a aplikací

V suverénním zabezpečeném prostředí je vynuceno používání skupin zabezpečení sítě (NSG) a skupin zabezpečení aplikací (ASG). Chybějící skupiny zabezpečení vedou k nevyhovujícím implementacím. Obvyklé porty SSL jsou užitečné pro většinu služeb, na které se spoléhají úlohy LLM/RAG, protože jsou založeny na HTTPS. Pro příjem dat ze zdrojů do vyhledávacích a vektorových databází jsou vyžadovány specifické porty. Veřejné IP adresy nejsou povoleny v cílových zónách Corp. Všechny služby musí být přístupné pouze ve virtuální síti, což vyžaduje použití koncových bodů služby Private Link nebo virtuální sítě pro služby PaaS.

Větší zabezpečení a mantinely suverenity

Nejdůležitější a nejzřejmější mantinely popsané v předchozích částech pro vaši infrastrukturu a návrh aplikací jsou opakovaně použitelné i mimo suverénní cílové zóny nebo cílové zóny Azure. Další globální zásady jsou vázány na centrálně spravované zdroje, jako jsou pracovní prostory Log Analytics nebo nasazení Microsoft Sentinel v podnikových cílových zónách. Během procesu návrhu infrastruktury a aplikací je zásadní vzít v úvahu tyto centrálně spravované zdroje. Zanedbání tohoto postupu může mít za následek dodatečné úsilí a čas po nasazení. Naštěstí funkce dodržování zásad Azure dokáže po nasazení identifikovat nevyhovující prostředky. Suverénní cílové zóny i cílové zóny Azure navíc poskytují zásady DeployIfNotExists pro četné zdroje, což proces dále zjednodušuje.

Některé příklady takových mantinelů jsou:

  • Aktivace přihlašování do centrálně spravovaných pracovních prostorů Log Analytics.

  • Integrace s Azure Security Center nebo Microsoft Defender for Cloud.

  • Integrace s Security Information and Event Management (SIEM), jako je Microsoft Sentinel.

  • Integrace s centrálně spravovanými firewally, firewally webových aplikací nebo ochranou DDoS.

Toto je jen několik mantinelů, které můžete identifikovat jako požadavky po prvním nasazení. Doporučujeme otestovat vaše nasazení v testovací cílové zóně a iterativně integrovat splnění těchto mantinelů do vaší infrastruktury a kódové základny aplikací. Pokud to není zcela možné, mnohé z těchto mantinelů lze vyřešit po nasazení pomocí zásad DeployIfNotExists.

Nasaďte tento scénář

Chcete-li využít výhod velkých jazykových modelů (LLM) a Azure OpenAI založených na vzoru rozšířeného generování načtení (RAG) v rámci suverénní cílové zóny, musíte nejprve nasadit a nakonfigurovat suverénní cílovou zónu (SLZ) a aplikovat iniciativy základních zásad suverenity. Podrobný přehled SLZ a všech jejích schopností najdete v dokumentaci Suverénní cílová zóna na GitHubu.

SLZ poskytuje prostředí nabízející ochranné mantinely prostřednictvím zásad a sad zásad, vynucování zabezpečení a konzistentní základní infrastrukturu pro nasazování úloh a aplikací. SLZ vychází z cílových zón Azure a rozšiřuje ji o mantinely a bezpečnostní kontroly specifické pro požadavky suverenity.

Aby zákazníci urychlili čas potřebný k dosažení hodnoty a zároveň mohli snadněji plnit cíle v oblasti dodržování předpisů, Microsoft Cloud for Sovereignty zahrnuje šablony úloh připravené k použití, které lze konzistentně nasazovat a provozovat opakovatelným způsobem. Šablony úloh jsou v souladu s iniciativami základu zásad suverenity, portfoliem zásad Cloud for Sovereignty a výchozími zásadami cílové zóny Azure.

Informace Pomocník agent šablona

Šablona Information Pomocník agent poskytuje organizacím výchozí bod k vybudování vlastní vlastní generativní schopnosti umělé inteligence k rozšíření výkonu Azure OpenAI na uživatele organizace a jejich doménová data bez dolaďování modelu. Můžete ho nasadit v rámci Cloud for Sovereignty a sladit s referenční architekturou a pokyny uvedenými v tomto článku. Informace Pomocník agent šablona je kompatibilní s rozsahem skupiny správy Sovereign Landing Zone Online pomocí konfigurace nasazení zabezpečeného režimu . Podpora pro rozsah skupiny pro správu Corp bude brzy k dispozici.

Šablona agent je kombinací kódu, dokumentace a vzdělávacích zdrojů poskytovaných zdarma zákazníkům a partnerům, které mohou pomoci urychlit čas potřebný k dosažení hodnoty.

Další informace o tom, jak nasadit a nakonfigurovat Information Pomocník, najdete v dokumentaci Information Pomocník agent template na GitHubu. Případy použití, kterých můžete dosáhnout pomocí této šablony agent, naleznete v Informační video Pomocník.