Návrh aplikace pro úlohy AI v Azure

Při vytváření aplikace s funkcemi AI je potřeba vzít v úvahu mnoho možností. Vaše jedinečné funkční a nefunkční požadavky, například to, jestli je případ použití tradiční strojového učení, generování, deterministické nebo kombinace typů AI, vám pomůže zúžit rozhodnutí na vysoké úrovni o návrhu. Tyto volby zvažujete při přechodu z oblastí návrhu vysoké úrovně na oblasti návrhu nižší úrovně.

Jak je popsáno v článku Začínáme, ať už chcete vytvořit vlastní model nebo použít předem vytvořený model, je jedním z prvních důležitých rozhodnutí, která je potřeba provést. Při použití předem vytvořeného modelu zvažte tyto body:

• Katalogové zdroje. Prozkoumejte úložiště, jako je Hugging Face Model Hub, TensorFlow Hub a portál Azure AI Foundry , katalog modelů, a vyhledejte předem naučené modely. Tyto platformy poskytují rozsáhlý katalog modelů pro různé úlohy.

• 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 vyladěná pro vaši úlohu nebo doménu.

Pokyny k volbě hostitelské platformy najdete v tématu Úvahy o hostování modelu a inferování na platformě.

Tento článek popisuje běžné oblasti návrhu a faktory, které je potřeba zvážit při rozhodování o technologiích a přístupu.

Doporučení

Následující tabulka shrnuje doporučení uvedená v tomto článku.

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í modelů a ověřování uživatelů, by se měly kontejnerizovat. Tento přístup umožňuje nezávislé nasazení a škálování a usnadňuje efektivnější aktualizace a údržbu.

• modely AI. Kontejnerizujte modely AI, abyste zajistili, že jsou všechny závislosti, knihovny a konfigurace seskupené dohromady. Tento přístup izoluje modelové prostředí od hostitelského systému, aby se zabránilo konfliktům verzí, a pomáhá zajistit 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 a vrstvy ukládání do mezipaměti, můžou také těžit z kontejnerizace. Kontejnerizace těchto služeb pomáhá udržovat konzistenci verzí a usnadňuje škálování a správu těchto komponent.

Umístění komponent AI společně s dalšími komponentami úloh

Existuje několik dobrých důvodů, proč umístit komponenty AI spolu s dalšími komponentami zátěže, ale to přináší určité kompromisy. Z těchto důvodů se můžete rozhodnout umístit komponenty společně:

• citlivost latence. Spolulokujte komponenty AI s jinými službami, jako je hostování rozhraní API, pokud je důležitá nízká latence. Pokud například potřebujete odvozování v reálném čase k vylepšení uživatelského prostředí, umístění modelů AI blízko rozhraní API může minimalizovat dobu potřebnou k načtení výsledků.

• Blízkost dat. Pokud 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, aby se urychlil zpracování a odvozování.

• Využití zdrojů. Pokud konkrétní 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, které je třeba vzít v úvahu, když se rozhodujete, zda mají být komponenty umístěny společně. Možná ztratíte možnost nezávisle nasazovat nebo škálovat komponenty. Můžete také zvýšit riziko poruchy 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 tím, že 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:

• komplexní pracovní postupy. 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í, jako je směrování výsledků do různých modelů, musí být dynamicky založená na výstupech modelu.

• Škálování a správa prostředků. Přidělení prostředků pro aplikace s velkým objemem potřebujete spravovat pomocí škálování modelu, které je založené na poptávce.

• Správa stavu. Potřebujete spravovat stav a paměť interakcí uživatelů.

• načtení dat. Musíte být schopni načíst data rozšíření z indexu.

Důležité informace o používání více modelů

Pokud vaše úloha používá více modelů, je orchestrátor nezbytný. Orchestrátor směruje data a požadavky 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 poskytují funkce vázané na kontext. Sdílejí mnoho charakteristik s mikroslužbami a provádějí úlohy ve spojení s orchestrátorem. Orchestrátor může nabízet úlohy do fondu agentů, nebo agenti mohou zaregistrovat své schopnosti u orchestrátoru. Oba přístupy umožňují orchestrátoru dynamicky určit, jak rozdělit a směrovat dotaz mezi agenty.

Agentní přístupy jsou ideální, když máte společnou plochu uživatelského rozhraní s více vyvíjejícími se funkcemi, které lze zapojit do prostředí, aby v průběhu času přidávaly do toku další dovednosti a ukotvená data.

U složitých úloh, které mají mnoho agentů, je efektivnější umožnit agentům dynamicky spolupracovat 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 vzorem choreografie.

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, oddělují funkce od rozhraní API, což snižuje závislosti mezi žádající službou a rozhraním API. Brány rozhraní API poskytují pro úlohy AI následující výhody:

• více mikroslužeb. Brány pomáhají spravovat více koncových bodů modelu AI, když potřebujete vynutit konzistentní zásady, jako je omezování rychlosti a ověřování.

• správa provozu. Brány pomáhají efektivně spravovat aplikace s vysokým provozem tím, že spravují požadavky, ukládají odpovědi do mezipaměti a rozkládají zátěž.

• zabezpečení. Brány poskytují centralizované řízení přístupu, protokolování a ochranu před hrozbami pro rozhraní API za bránou.

Použití vzorů návrhu aplikací AI

V odvětví aplikací umělé inteligence bylo vytvořeno několik běžných vzorů návrhu. Můžete je použít ke zjednodušení návrhu a implementace. Mezi tyto vzory návrhu patří:

• Kombinování modelů. Tento vzor návrhu zahrnuje kombinování předpovědí z více modelů za účelem zlepšení přesnosti a robustnosti zmírněním 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. Umožňuje týmům pracovat na různých částech aplikace současně.

• architekturu řízenou událostmi. Použití událostí k aktivaci akcí umožňuje oddělit komponenty a zpracování v reálném čase, aby systém rychleji reagoval a přizpůsobil změnám dat.

Model RAG a strategie vytváření bloků dat

Model Retrieval-Augmented Generation (RAG) kombinuje generování modelů se systémy načítání, které modelu umožňují přístup k externím zdrojům znalostí pro lepší kontext a přesnost. Podrobné pokyny k tomuto vzoru naleznete v sérii článků Návrh a vývoj řešení RAG. Existují dva přístupy RAG:

• právě včas. Tento přístup načítá relevantní informace dynamicky v době požadavku, aby se zajistilo, že se vždy použijí nejnovější data. Je výhodné ve scénářích, které vyžadují kontext v reálném čase, ale můžou zavádět latenci.

• Předpočítané (v mezipaměti). Tato metoda zahrnuje ukládání výsledků načítání do mezipaměti, aby se zkrátila doba odezvy poskytováním předem vypočítaných dat. Je vhodný pro scénáře s vysokou poptávkou, ve kterých je možné ukládat konzistentní data. Data nemusí odrážet nejaktuálnější informace, což může vést k 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 s pokyny , které jsou k dispozici v sérii Návrh a vývoj řešení RAG. Tady je několik dalších doporučení, která je potřeba zvážit:

• 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í členění na základě dat o výkonu.

• Pro zachování sledovatelnosti dat pro jednotlivé bloky udržujte metadata a jedinečné identifikátory, které odkazují zpět k původnímu zdroji. Jasná dokumentace k rodokmenu pomáhá zajistit, aby uživatelé porozuměli původu dat, jejich transformacím a tomu, jak přispívá k výstupu.

Kdy použít vzory návrhu

Pokud váš případ použití splňuje popsanou podmínku, zvažte použití těchto vzorů návrhu:

• komplexní pracovní postupy. Pokud máte složité pracovní postupy nebo interakce 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 aplikaci kolísá, model, jako jsou mikroslužby, umožňuje jednotlivým komponentám nezávisle škálovat různé zatížení, aniž by to ovlivnilo 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.

Volba správných architektur a knihoven

Volba architektur a knihoven je úzce propojena s návrhem aplikace. Ovlivňují výkon, škálovatelnost a udržovatelnost. Požadavky na návrh ale můžou omezit volby architektury. Například použití semantické sady SDK jádra často podporuje návrh založený na mikroslužbách, kde je každý agent nebo funkce zapouzdřen ve své vlastní službě. Při volbě architektur a knihoven zvažte tyto faktory:

• Požadavky pro aplikaci. Požadavky aplikace, jako je zpracování v reálném čase nebo dávkové zpracování, můžou omezit výběr architektury. Pokud například aplikace vyžaduje nízkou latenci, možná budete muset použít architekturu 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 formáty dat, možná budete muset návrh znovu zvážit nebo zvolit jinou architekturu.

• týmové odborné znalosti. Sada dovedností vývojového týmu může omezit volby 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, takže možná budete chtít použít běžnější nástroj.

Návrh strategie pro identity, autorizaci a přístup

Obecně řečeno, měli byste přistupovat k identitě, autorizaci a přístupu stejným způsobem, jakým byste normálně navrhli aplikace. K co největší správě těchto oblastí byste měli použít zprostředkovatele identity, jako je ID Microsoft Entra. Mnoho aplikací umělé inteligence má ale jedinečné výzvy, které vyžadují zvláštní pozornost. Někdy je obtížné nebo dokonce nemožné zachovat seznamy řízení přístupu (ACL) v systému bez nového vývoje.

Informace o tom, jak přidat zabezpečovací ořezávání metadat do dokumentů a bloků dat, najdete v Průvodce návrhem zabezpečeného víceúčelového řešení odvozování RAG. Toto oříznutí může být založené na skupinách zabezpečení nebo podobných organizačních strukturách.

Zvažte nefunkční požadavky

Vaše úloha může mít nefunkční požadavky, které představují výzvy kvůli faktorům, které jsou součástí technologií umělé inteligence. Tady jsou některé běžné nefunkční požadavky a jejich výzvy:

• Latence při inferencích modelu / vypršení časových limitů. 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í. 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 u cloudových modelů. Návrh pro tato omezení vyžaduje pečlivou správu velikostí vstupu, dávkování požadavků v případě potřeby a potenciálně implementaci mechanismů omezování rychlosti nebo řazení do front, které spravují očekávání uživatelů a brá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žívání a generování sestav, které podporují modely přeúčtování. Tyto funkce umožňují organizacím přidělovat náklady přesně napříč odděleními. Správa chargebacků se obvykle zpracovává bránou rozhraní API, jako je Azure API Management.

Další krok