Návrh aplikace pro úlohy AI v Azure
Při plánování vytváření aplikace s funkcemi AI můžete zvážit řadu možností. Vaše jedinečné funkční a nefunkční požadavky vám pomůžou zúžit rozhodnutí na vysoké úrovni o návrhu, například jestli je případ použití tradiční strojového učení, generování, deterministické nebo kombinace typů AI. Při přechodu z oblastí návrhu vysoké úrovně na oblasti návrhu nižší úrovně existuje několik možností, které je třeba zvážit na cestě.
Jak je popsáno v článku Začínáme , volba, jestli chcete vytvořit vlastní model nebo použít předem připravený model, je jedním z prvních důležitých rozhodnutí, která je potřeba provést. Při výběru předem vytvořeného modelu zvažte tyto body:
Zdroje katalogu. Prozkoumejte úložiště, jako je Hugging Face Model Hub, TensorFlow Hub nebo katalog modelů Azure AI Studio, a vyhledejte předem natrénované modely. Tyto platformy poskytují rozsáhlý katalog modelů napříč různými úlohami.
Licencování: Ujistěte se, že licenční podmínky modelu odpovídají vašim cílům zabezpečení, dodržování předpisů a aplikací, zejména pokud plánujete distribuovat aplikaci nebo ji integrovat s jinými službami.
Klíčové komponenty. Podívejte se na architekturu modelu, trénovací data, výkon a licencování a zjistěte, jestli je pro vaši úlohu nebo doménu vyladěná.
Pokyny k výběru hostitelské platformy najdete v tématu Aspekty platformy hostování modelu.
V tomto článku se seznámíte s mnoha běžnými oblastmi návrhu a faktory, které je potřeba vzít v úvahu při rozhodování o technologiích a přístupu.
Doporučení
Tady je souhrn doporučení uvedených v tomto článku.
| Doporučení | Popis |
|---|---|
| Určete prioritu řešení mimo police. | Kdykoli je to praktické, používejte řešení PaaS (Platforma jako služba) ke zpracování funkcí úloh. Pokud je to možné, použijte předem připravené a natrénované modely, abyste minimalizovali provozní a vývojovou zátěž pro vaše pracovní a provozní týmy. |
| Abstraktní funkce a možnosti mimo klienta. | Udržujte klienta co nejtenčí tím, že navrhnete back-endové služby, aby zvládly průřezové otázky, jako je omezování rychlosti a operace převzetí služeb při selhání. |
| Zablokujte přístup k úložištům dat. | Kód v systému AI by se neměl přímo dotýkat vašich úložišť dat. Směrujte všechny žádosti o data prostřednictvím vrstvy rozhraní API. Rozhraní API by měla být určená pro konkrétní požadovanou úlohu. |
| Izolujte své modely. | Podobně jako úložiště dat použijte vrstvu rozhraní API k tomu, aby fungovala jako brána pro požadavky na model. Některá řešení PaaS, jako je Azure OpenAI Service a Azure Machine Learning, k tomuto účelu používají sady SDK. Mnoho nástrojů, jako je PromptFlow, obsahuje nativní podporu šíření rozhraní API do služby. |
| Komponenty návrhu, které se dají nezávisle nasadit | Modely AI, datové kanály, front-endové komponenty a mikroslužby, jako je předzpracování dat, extrakce funkcí a odvozování, by se měly nezávisle nasazovat za účelem optimalizace flexibility, škálovatelnosti a funkčnosti úloh. |
Kontejnerizace komponent
Pokud chcete zajistit, aby vaše nezávisle nasaditelné komponenty byly plně samostatné a zjednodušily vaše nasazení, zvažte kontejnerizaci jako součást strategie návrhu. Kontejnerizované by měly být následující komponenty:
Mikroslužby: Jednotlivé mikroslužby, které zpracovávají konkrétní funkce aplikace, jako je zpracování dat, odvozování modelu nebo ověřování uživatelů, by měly být kontejnerizovány. Tento přístup umožňuje nezávislé nasazení a škálování, což usnadňuje efektivnější aktualizace a údržbu.
Modely AI: Kontejnerizace modelů AI, aby se zajistilo, že jsou všechny závislosti, knihovny a konfigurace seskupené dohromady. Tento přístup izoluje modelové prostředí od hostitelského systému, brání konfliktům verzí a zajišťuje konzistentní chování v různých prostředích nasazení.
Kanály zpracování dat: Všechny úlohy zpracování dat, které předchází nebo následují odvozování modelu, jako je čištění dat, transformace a extrakce funkcí, by měly být kontejnerizovány. Tento přístup zlepšuje reprodukovatelnost a zjednodušuje správu závislostí.
Služby infrastruktury: Služby, které poskytují podporu infrastruktury, jako jsou databáze nebo vrstvy ukládání do mezipaměti, mohou také těžit z kontejnerizace. Tento přístup pomáhá udržovat konzistenci verzí a usnadňuje škálování a správu těchto komponent.
Společné přidělení komponent AI s jinými komponentami úloh
Existuje několik dobrých důvodů, proč společně přidělovat komponenty AI s jinými komponentami úloh, ale existují kompromisy. Mezi důvody, proč byste mohli společné umístění, patří:
Citlivost latence: Spolulokujte komponenty AI s jinými službami, jako je hostování rozhraní API, když je důležitá nízká latence. Pokud se například k vylepšení uživatelského prostředí vyžaduje odvozování v reálném čase, může umístění modelů AI blízko rozhraní API minimalizovat dobu potřebnou k načtení výsledků.
Blízkost dat: Když modely AI vyžadují častý přístup ke konkrétním datovým sadám, jako je index vyhledávání, může společné přidělení těchto komponent zlepšit výkon a snížit režii přenosu dat pro rychlejší zpracování a odvozování.
Využití prostředků: Pokud některé komponenty mají doplňkové potřeby prostředků, jako je procesor a paměť, jejich společné přidělení může optimalizovat využití prostředků. Například model, který vyžaduje významné výpočty, může sdílet prostředky se službou, která má současně nižší požadavky.
Kompromis. Existují kompromisy se spolulokací komponent, které by se měly zvážit. Může dojít ke ztrátě schopnosti nezávisle nasazovat nebo škálovat komponenty. Můžete také zvýšit riziko selhání zvýšením potenciálního poloměru výbuchu incidentů.
Vyhodnocení použití orchestrátorů v řešeních generujících AI
Orchestrátor spravuje pracovní postup, který koordinuje komunikaci mezi různými komponentami řešení AI, které by jinak bylo obtížné spravovat ve složitých úlohách. Pokud má vaše úloha některou z následujících charakteristik, doporučujeme do návrhu sestavit orchestrátor:
Složité pracovní postupy: Tento pracovní postup zahrnuje několik kroků, jako je předběžné zpracování, řetězení modelů nebo následné zpracování.
Podmíněná logika: Rozhodnutí musí být dynamicky založená na výstupech modelu, jako je směrování výsledků do různých modelů.
Škálování a správa prostředků: Potřebujete spravovat přidělování prostředků pro vysokoobsádové aplikace pomocí škálování modelu na základě poptávky.
Správa stavu: Potřebujete spravovat stav a paměť interakcí uživatelů.
Načítání dat: Musíte být schopni načíst rozšířená data z indexu.
Důležité informace o používání více modelů
Pokud vaše úloha používá více modelů, je použití orchestrátoru nezbytné. Orchestrátor zodpovídá za směrování dat a požadavků na příslušný model na základě případu použití. Naplánujte tok dat mezi modely a zajistěte, aby výstupy z jednoho modelu mohly sloužit jako vstupy pro jiný. Plánování může zahrnovat procesy transformace nebo rozšiřování dat.
Orchestrace a agenti
U úloh generující umělé inteligence zvažte přístup založený na agentech, který se někdy označuje jako agentský, přístup k návrhu, aby se do orchestrace přidala rozšiřitelnost. Agenti odkazují na kontextové funkce a sdílejí mnoho charakteristik stylu mikroslužeb, které provádějí úlohy ve spojení s orchestrátorem. Orchestrátor může inzerovat úlohy do fondu agentů nebo agentů může registrovat funkce v orchestrátoru. Oba přístupy umožňují orchestrátoru dynamicky rozhodnout, jak rozdělit a směrovat dotaz mezi agenty.
Přístupy k agentům jsou ideální, když máte společnou plochu uživatelského rozhraní s několika vyvíjejícími se funkcemi, které se dají do daného prostředí zapojit , aby se do toku v průběhu času přidaly další dovednosti a zemnění dat.
U složitých úloh s mnoha agenty je efektivnější umožnit agentům dynamickou spolupráci místo použití orchestrátoru k rozdělení úloh a jejich přiřazení.
Komunikace mezi orchestrátorem a agenty by měla postupovat podle vzoru fronty tématu, kde agenti jsou odběrateli tématu a orchestrátor odesílá úlohy prostřednictvím fronty.
Použití agentického přístupu funguje nejlépe se vzorem orchestrace, nikoli s hierarchickým vzorem.
Další informace najdete v tématu Důležité informace o platformě orchestrace.
Vyhodnocení použití bran rozhraní API
Brány rozhraní API, jako je Azure API Management, abstrahují funkce od rozhraní API, která odděluje závislosti mezi požadavkem služby a rozhraním API. Brány rozhraní API poskytují pro úlohy AI následující výhody:
Několik mikroslužeb: Pomáhají spravovat více koncových bodů modelu AI a potřebujete vynutit konzistentní zásady, jako je omezování rychlosti a ověřování.
Správa provozu: Pomáhají efektivně spravovat aplikace s vysokým provozem tím, že spravují požadavky, ukládání odpovědí do mezipaměti a distribuují zatížení.
Zabezpečení: Poskytují centralizované řízení přístupu, protokolování a ochranu před hrozbami pro rozhraní API za bránou.
Využití vzorů návrhu aplikací AI
Existuje několik běžných vzorů návrhu, které byly vytvořeny v odvětví pro aplikace AI, které můžete použít ke zjednodušení návrhu a implementace. Mezi tyto vzory návrhu patří:
Přemístit model: Tento model návrhu zahrnuje kombinování předpovědí z více modelů za účelem zlepšení přesnosti a robustnosti a zmírnění slabých stránek jednotlivých modelů.
Architektura mikroslužeb: Oddělení komponent do nezávisle nasaditelných služeb vylepšuje škálovatelnost a udržovatelnost a umožňuje týmům pracovat na různých částech aplikace současně.
Architektura řízená událostmi: Použití událostí k aktivaci akcí umožňuje oddělit komponenty a zpracování v reálném čase, což umožňuje systém reagovat a přizpůsobit se měnícím datům.
Model RAG a strategie vytváření bloků dat
Model RAG (Retrieval-Augmented Generation) kombinuje generování modelů se systémy načítání, což modelu umožňuje přístup k externím zdrojům znalostí pro lepší kontext a přesnost. Podrobné pokyny k tomuto vzoru najdete v části Návrh a vývoj řešení RAG. Existují dva přístupy RAG:
Just-in-time: Tento přístup načítá relevantní informace dynamicky v době požadavku a zajišťuje tak, aby se vždy používala nejnovější data. Je výhodné ve scénářích, které vyžadují kontext v reálném čase, ale mohou zavádět latenci.
Předpočítaná (uložená v mezipaměti): Tato metoda zahrnuje ukládání výsledků načítání do mezipaměti a zkracuje dobu odezvy tím, že obsluhuje předem vypočítaná data. Je vhodný pro scénáře s vysokou poptávkou, kdy je možné ukládat konzistentní data, ale nemusí odrážet nejaktuálnější informace, což vede k potenciálním problémům s relevanci.
Při použití vzoru RAG je pro optimalizaci efektivity výkonu vaší úlohy důležitá dobře definovaná strategie vytváření bloků dat. Začněte pokyny řadou řešení RAG, které jsou k dispozici v části Návrh a vývoj. Další doporučení, která je potřeba vzít v úvahu, jsou:
Implementujte strategii dynamického vytváření bloků dat, která upravuje velikosti bloků dat na základě datového typu, složitosti dotazů a požadavků uživatelů. To může zvýšit efektivitu načítání a zachování kontextu.
Začleňte smyčky zpětné vazby pro upřesnění strategií vytváření bloků dat na základě dat o výkonu.
Zachování rodokmenu dat pro bloky dat udržováním metadat a jedinečných identifikátorů, které odkazují zpět na uzemněný zdroj. Jasná dokumentace k rodokmenu pomáhá zajistit, aby uživatelé pochopili původ dat, jejich transformace a způsob, jakým přispívá k výstupu.
Kdy použít vzory návrhu
Zvažte použití těchto vzorů návrhu, pokud váš případ použití splňuje jednu z podmínek:
Složité pracovní postupy: Při práci se složitými pracovními postupy nebo interakcemi mezi několika modely AI můžou vzorce, jako je RAG nebo mikroslužby, pomoct spravovat složitost a zajistit jasnou komunikaci mezi komponentami.
Požadavky na škálovatelnost: Pokud poptávka po vaší aplikaci kolísá, použití vzoru, jako jsou mikroslužby, umožňuje jednotlivým komponentám nezávisle škálovat různé zatížení, aniž by to mělo vliv na celkový výkon systému.
Aplikace řízené daty: Pokud vaše aplikace vyžaduje rozsáhlé zpracování dat, může architektura řízená událostmi poskytovat rychlost odezvy v reálném čase a efektivní zpracování dat.
Poznámka:
Menší aplikace nebo poc obvykle nebudou mít prospěch z přijetí některého z těchto vzorů návrhu a měly by být sestaveny pomocí zjednodušeného návrhu. Podobně platí, že pokud máte omezení zdrojů (rozpočtu, času nebo počtu prostředků), je použití zjednodušeného návrhu, který lze refaktorovat později, lepší než přijetí složitého vzoru návrhu.
Volba správných architektur a knihoven
Volba architektur a knihoven je úzce propojená s návrhem aplikací, která ovlivňuje nejen architekturu, ale také výkon, škálovatelnost a udržovatelnost. Naopak požadavky na návrh můžou omezit volby architektury a vytvořit mezi nimi dynamickou interplay. Například použití sady Sémantic Kernel SDK (SK) často podporuje návrh založený na mikroslužbách, ve kterém je každý agent nebo funkce zapouzdřen ve své vlastní službě. Faktory, které je potřeba vzít v úvahu při výběru architektur a knihoven, jsou:
Požadavky aplikace: Konkrétní požadavky aplikace, jako je zpracování v reálném čase nebo dávkové zpracování, mohou omezit výběr architektury. Pokud například aplikace vyžaduje nízkou latenci, může být vyžadována architektura s asynchronními funkcemi.
Potřeby integrace: Návrh může vyžadovat konkrétní integrace s jinými systémy nebo službami. Pokud architektura nepodporuje potřebné protokoly nebo datové formáty, může vyžadovat znovu zvážit návrh nebo vybrat jinou architekturu.
Odborné znalosti týmu: Sada dovedností vývojového týmu může omezit možnosti architektury. Návrh, který spoléhá na méně známou architekturu, může vést ke zvýšení času a složitosti vývoje a k výzvě k výběru známého nástroje.
Návrh strategie pro identity, autorizaci a přístup
Obecně řečeno byste měli přistupovat k identitě, autorizaci a přístupu stejným způsobem, jakým obvykle navrhujete aplikace. K co největší správě těchto oblastí byste měli použít zprostředkovatele identity, jako je ID Microsoft Entra. Existuje však jedinečné výzvy pro mnoho aplikací umělé inteligence, které potřebují zvláštní pozornost. Zachování seznamů řízení přístupu (ACL) prostřednictvím systému je někdy náročné nebo dokonce nemožné bez zavedení nového vývoje.
Projděte si pokyny, které najdete v zabezpečeném řešení RAG s více tenanty, a zjistěte, jak přidat metadata oříznutí zabezpečení do dokumentů a bloků dat. Toto oříznutí může být založené na skupinách zabezpečení nebo podobných organizačních konstruktorech.
Zvažte nefunkční požadavky
Pro úlohu můžete mít nefunkční požadavky, které jsou náročné kvůli faktorům, které jsou součástí technologií AI. Mezi běžné nefunkční požadavky a jejich výzvy patří:
Latence odvozování/vypršení časových limitů modelu: Aplikace umělé inteligence často vyžadují odpovědi v reálném čase nebo téměř v reálném čase. Návrh pro nízkou latenci je zásadní, což zahrnuje optimalizaci architektury modelu, kanálů zpracování dat a hardwarových prostředků. Implementace strategií ukládání do mezipaměti a zajištění efektivního načítání modelu jsou také nezbytné, aby nedocházelo k vypršení časových limitů a poskytovaly včasné odpovědi.
Omezení propustnosti tokenu nebo žádosti: Řada služeb AI omezuje počet tokenů nebo propustnost požadavků, zejména při používání cloudových modelů. Návrh pro tato omezení vyžaduje pečlivou správu velikostí vstupu, dávkové požadavky v případě potřeby a potenciálně implementaci mechanismů omezování rychlosti nebo řazení do front pro správu očekávání uživatelů a zabránění přerušení služeb.
Scénáře nákladů a vracení peněz: Návrh pro transparentnost nákladů zahrnuje implementaci funkcí sledování využití a vytváření sestav, které usnadňují modely vracení peněz, což organizacím umožňuje přesně přidělovat náklady napříč odděleními. Správa zpětného účtování se obvykle zpracovává bránou rozhraní API, jako je Azure API Management.