Testování a hodnocení úloh AI v Azure
Účelem testování v úlohách AI je zajistit kvalitu při zavedení změny v systému. Testování může ověřit, jestli úloha splňuje zjištěné cíle a splňuje očekávání uživatelů. Zabraňuje také regresím kvality. Tento proces zahrnuje provádění testů napříč různými funkčními oblastmi a posouzení kvality funkcí, zpracování zatížení, předvídatelnosti a dalších kritérií na základě požadavků na úlohy.
Výsledky testů poskytují kritické datové body pro rozhodnutí , jako je to, jestli jsou komponenty AI připravené k vydání a které skladové položky nebo funkce jsou vhodné. Kromě toho testování může sloužit jako systém oznámení pro selhání a pomáhá zjišťovat problémy v produkčním prostředí prostřednictvím rutinních nebo syntetických testů.
Architektura Azure Well-Architected Framework popisuje komplexní metodologii testování. Měli byste použít různé typy testů v různých fázích životního cyklu vývoje a napříč různými systémovými komponentami a toky. Bez těchtotestůch Například menší chyby kódu se můžou stát velkými chybami systému. Chování systému se může stát nepředvídatelným nebo může způsobit zkreslené výsledky z důvodu nedeterministické povahy systémů AI. Přidělení prostředků může být také neefektivní a skutečná uživatelská data nebo systémové prostředky mohou být zneužity, protože tyto systémy jsou ohroženy zneužitím.
Musíte navrhnout a vyvíjet prostředky úloh s ohledem na testování. Pokud například provádíte manipulaci s daty a měníte tvar zdrojových dat pro přípravu funkcí, dodržujte osvědčené postupy kódování a ujistěte se, že kód strukturujete tak, aby podporoval testování. Tato strategie zahrnuje návrh kódu pro usnadnění efektivního testování jednotek a izolování testů z funkčnosti kódu a jeho závislostí. V tomto příkladu musíte navrhnout systém, který může provádět v testovacím prostředí s dostatečně reprezentativními testovacími daty z hlediska objemu a podobně.
Součásti úloh musíte bezpečně nasadit do produkčního prostředí. Součástí postupů bezpečného nasazení úloh je strategické testování, které pomáhá zajistit správné chování před tím, než uživatelé nebo data systém spotřebují. Strategické testování je nezbytné během počátečního nasazení a s tím, jak se systém vyvíjí a prochází změnami kódu nebo infrastruktury. Před nasazením změn do produkčního prostředí otestujte všechny navrhované změny kódu a infrastruktury související s AI.
Tento článek se zaměřuje na použití této metodologie na aspekty AI architektury. Postup provedení těchto testů není v rozsahu.
Doporučení
Tady je souhrn doporučení uvedených v tomto článku.
| Doporučení | Popis |
|---|---|
| Definujte metriky úspěšnosti pro vaši testovací strategii. | Stejně jako jakýkoli jiný typ testování úloh musíte zachytit a analyzovat příslušné metriky pro daný test, abyste měli jistotu, že test poskytuje užitečné přehledy o vaší úloze AI. ▪ Definování metrik úspěšnosti |
| Proveďte kompletní testování kanálů příjmu a zpracování dat v průběhu životního cyklu vývoje. | Testy můžou ověřit data a pomoct zajistit, aby proces manipulace s daty fungoval podle očekávání. Zabudujte testování v rané fázi návrhu, abyste zajistili kvalitu dat a vhodné technologie a volby velikosti. Vývoj testů jednotek pro vlastní kód během vývoje a provádění produkčních testů v reálném čase za účelem zachycení problémů a ověření funkčnosti ▪ Testování příjmu dat |
| Spusťte testy pro trénovací úlohy, abyste měli jistotu, že se skripty volají a fungují podle očekávání. | Zátěžové a výkonnostní testování vám může poskytnout přehled o volbě a velikosti výpočetních prostředků, které jsou vhodné ke spuštění úloh. Testy jednotek mohou ověřit nástroj kódu a zachytit regrese při aktualizaci závislostí. ▪ Otestování pracovního postupu trénování |
| Vyhodnoťte a otestujte model, abyste se vyhnuli duplikaci při trénování, hodnocení a testování dat. | Pokud chcete zajistit, aby se zdrojová data úplně nepoužívala pro trénování, musíte si rezervovat jedinečná data pro vyhodnocení modelu a konečné testování. Tyto podmnožina nejsou zahrnuté ve skutečném procesu trénování. ▪ Vyhodnocení a otestování modelu |
| Otestujte koncový bod odvozování. | Proveďte zátěžové testování na koncovém bodu, který hostuje server pro odvozování, a na základě těchto výsledků testu zvolte skladové položky GPU. Pro koncové body hostované platformou jako službou (PaaS) otestujte propustnost a potenciální selhání. Tyto koncové body jsou dostupné, proto proveďte řádné testování zabezpečení, abyste zabránili situacím s jailbreakem. ▪ Otestování koncového bodu odvozování |
| Otestujte správnost návrhu indexu, aby dotazy přinesly relevantní výsledky. | Funkční a integrační testování pomáhá zajistit, aby data byla přesná, a testování schématu indexu kontroluje zpětnou kompatibilitu. Předzpracování kroků je nutné otestovat pro kvalitu. Zátěžové testování určuje vhodné skladové položky pro prostředky a kontrolní mechanismy zabezpečení chrání důvěrnost dat. ▪ Testování podkladových dat |
| Otestujte orchestrátor a ověřte jeho funkčnost a zabezpečení. | Provedení jednotek, funkčních, integračních a běhových testů, včetně testování režimu zatížení a selhání, za účelem zajištění výkonu a spolehlivosti Testování zabezpečení a bezpečnosti obsahu je také zásadní pro ochranu systému a dat. ▪ Testování orchestrátoru |
| Test pro rozpad modelu. | Rozpad modelu je nevyhnutelné problém, který ovlivňuje většinu úloh umělé inteligence. Testování odchylek dat a konceptů vám může pomoct chytit model brzy a zmírnit problém dříve, než negativně ovlivní vaši úlohu. ▪ Prevence rozpadu modelu |
Definování metrik úspěšnosti
Doporučujeme použít standardní hodnoty a měřit prediktivní výkon modelu pomocí dobře definovaných metrik. Tady jsou některé běžné metriky.
Přesnost představuje poměr správně predikovaných instancí k celkovým instancím v testovací datové sadě. Jedná se o běžnou míru celkového výkonu modelu.
Přesnost je poměr pravdivě pozitivních predikcí k součtu pravdivě pozitivních a falešně pozitivních výsledků. Je užitečné, když minimalizujete falešně pozitivní výsledky, například v lékařských diagnostikách.
Citlivost měří poměr pravdivě pozitivních výsledků k součtu pravdivě pozitivních a falešně negativních výsledků. Je důležité, když se vyhnete falešně negativním výsledkům nebo chybí relevantní případy.
Specificita vypočítá poměr pravdivých záporných hodnot k součtu pravdivých negativních výsledků a falešně pozitivních výsledků. Je relevantní, když optimalizujete přesné záporné předpovědi.
Poznámka:
Při definování metrik úspěšnosti pro regresní modely zvažte přidání následujících metrik:
Střední absolutní chyba (MAE) měří průměrný absolutní rozdíl mezi predikovanými hodnotami a skutečnými hodnotami. Vypočítat ji tak, že vezme střední hodnotu absolutních rozdílů mezi každou skutečnou hodnotou a odpovídající předpovězenou hodnotou. MAE je v porovnání s MSE a RMSE méně citlivá na odlehlé hodnoty.
Střední kvadratická chyba (MSE) měří průměrný kvadratický rozdíl mezi skutečnými hodnotami a predikovanými hodnotami. Vypočítá se průměrem kvadratických rozdílů mezi každou skutečnou hodnotou a odpovídající předpovězenou hodnotou. MSE postihuje větší chyby silněji než MAE, protože chyby jsou kvadratické.
Odmocnina střední kvadratická chyba (RMSE) je druhá odmocnina MSE. Poskytuje míru průměrné absolutní chyby mezi skutečnými a predikovanými hodnotami, ale ve stejných jednotkách jako původní data. RMSE je v porovnání s MAE citlivější na odlehlé hodnoty, protože před průměrem umocní chyby.
Testování příjmu dat
Datové kanály, jako jsou procesy extrakce, transformace a načítání (ETL), přesun a manipulace s daty. Otestujte část úlohy ETL a ujistěte se, že spolehlivě ingestuje data a že jsou data vysoce kvalitní a přijatelná pro analýzu a přípravu funkcí. Ujistěte se, že čištění a zpracování dat zahrnuje testy, které potvrdí, že manipulace s daty funguje podle očekávání.
Testování by mělo být integrováno v průběhu životního cyklu, včetně fází návrhu, vývoje a výroby.
Testování pro usnadnění možností návrhu
Když shromáždíte požadavky na úlohu, klíčovým rozhodovacím krokem je volba konkrétní technologické možnosti, která je pro váš návrh proveditelná.
Na základě vašich požadavků ETL a kritérií přijetí proveďte průzkumné funkční testy a vyberte nejvhodnější produkt, jeho skladové položky a funkce, které provádějí požadované úkoly. Testování konceptu, testování technologie a testování schopností jsou nezbytné k vyhodnocení, jestli zvolíte správnou technologii a jestli je správně nastavená.
Ve scénářích, ve kterých integrujete AI do stávající architektury, otestujte, jak dobře se nová technologie může integrovat s aktuálním systémem.
Počáteční požadavky na úlohy se můžou změnit. Předpokládejme, že firma očekává růst a systém musí zpracovávat dvojité běžné dotazy uživatelů. Toto očekávání vyžaduje správné plánování kapacity. Doporučujeme proaktivní testování, abyste porozuměli tomu, jak systém reaguje na další data, a aby provedl úpravy velikosti řízené daty stávající velikosti nebo volby nových produktů. Pro testování kapacity doporučujeme kombinovat funkční testování s zátěžovým a výkonnostním testováním a používat syntetické funkce k simulaci realistických podmínek.
Testování kvality kódu
Pokud je kód součástí, ujistěte se, že prochází testováním jednotek, a pokud selže, nespustí se. Je například běžné mít vlastní kód, který se spouští jako součást příjmu dat. K čištění a zpracování dat se používá také kód. Spusťte testy jednotek, abyste zajistili, že se kód chová podle návrhu a že manipulace s daty funguje podle očekávání.
Testy můžete spouštět jako součást průběžné integrace a kanálu průběžného doručování.
Testování v živém systému
Funkční testování by se mělo rozšířit na živý systém. Pokud tyto testy selžou, zvažte aktivaci výstrah, aby bylo v případě potřeby zahájeno okamžité šetření. Několik příkladů:
Spuštěním plánovaných testů ověřte, že se shromáždil správný objem dat, pokud se data ingestují podle nastaveného plánu s očekávanou velikostí.
Spusťte testy, které detekují problémy s daty, jako jsou chybějící hodnoty nebo duplicitní data, a proveďte základní kontroly integrity dat. Pokud data obsahují dočasné informace, které označují jejich aktuálnost, mohou tyto testy zkontrolovat tyto informace a potenciálně zabránit podřízeným procesům v používání zastaralých dat.
Zkontrolujte dostupnost externích závislostí. Úloha čištění dat může například volat jinou službu pro extrakci tabulek nebo předběžné zpracování. Spuštěním testů ověřte, že jsou k dispozici, protože jejich nedostupnost by mohla ovlivnit proces ETL.
Dalším způsobem, jak otestovat správnost systému ETL v produkčním prostředí, je prostřednictvím syntetického testování. Díky tomu, že jsou v produkčním prostředí k dispozici známá testovací data, jsou vysoce efektivní. Můžete ho použít k ověření kompletního zpracování porovnáním známého počátečního stavu s očekávaným koncovým stavem pro tato data. Dokument je například nutný k procházení informací o dokumentech a obsahuje osobní údaje. Vložení syntetického dokumentu může otestovat, že úloha provádí úlohu manipulace s daty podle očekávání.
Experimentujte také uvolněním různých prostředí, označovaných také jako testování A/B, abyste se před úplným potvrzením naučili z interakcí uživatelů. Testování A/B pomáhá zabránit regresím kvality.
Testování dat shromážděných během příjmu dat
Součástí procesu příjmu dat z různých zdrojů dat jsou testy, které ověřují, že trénovací data odpovídají vašim očekáváním.
Trénování modelu strojového učení s neúplnými nebo poškozenými daty může být kontraproduktivní. Může vést k plýtvání úsilím a vést k tomu, že model, který nedokáže vytvořit smysluplné předpovědi. Kanály příjmu a předběžného zpracování dat zahrnují testy kvality jako kontrolní body. Tyto testy vám můžou pomoct ověřit, že vaše data odpovídají očekáváním, která jste nastavili během analýzy dat a přípravy funkcí.
Následující seznam obsahuje některé příklady testovacích případů:
Otestujte úplnost. Otestujte očekávané množství trénovacích dat a ověřte úplnost datové sady. Tento test zajistí, že poskytnete dostatek dat pro trénování modelu.
Otestujte důležité informace. Pokud je trénování založené na známých entitách, jako jsou konkrétní záznamy nebo identifikátory, otestujte datovou sadu a ujistěte se, že jsou tyto entity přítomny. Toto ověření zajišťuje, že chybí důležité informace.
Otestujte irelevantní data. Ingestované údaje by neměly obsahovat irelevantní ani chybné položky. Proces příjmu dat by měl tato data vyfiltrovat.
Otestujte aktuálnost. Aktuálnost přijatých dat by neměla mít vliv na prediktivní výkon modelu. Ověřte, že data odrážejí přiměřeně aktuální informace a nejsou zastaralá z předchozích spuštění. Pokud například očekáváte, že data budou obsahovat záznamy z minulého týdne, ale po importu dat neexistují žádné takové záznamy, které by mohly znamenat problém s neúspěšným importem nebo aktuálností dat ve zdrojovém systému.
Provádění rutinních testů
Důležitým problémem při příjmu dat je objem dat a propustnost. Průběžné vyhodnocování během operací je nezbytné, aby se zabránilo kritickým bodům výkonu. Toto průběžné hodnocení by mělo být součástí vašich provozních procesů, nikoli jen jednorázového testu. Cílem je zajistit, aby tým úloh nezmeškal cíle na úrovni služeb.
Představte si situaci, kdy monitorování značí snížení výkonu. Pokud chcete tyto podmínky zmírnit, přehodnotujte a optimalizujte procesy ETL. Po provedení změn vám testy výkonnosti pomůžou zajistit, aby změny splňovaly požadovanou propustnost.
Poznámka:
Testování a monitorování slouží k různým účelům. Proveďte testy, abyste vyhodnotili potenciální změny systému, obvykle před implementací jakýchkoli změn. Průběžně monitorujte a vyhodnocujte celkový stav systému.
Otestování pracovního postupu trénování
Trénování modelu pomocí vlastního kódu, jako jsou skripty PyTorch, které dělají skutečnou trénovací práci. Tyto skripty běží na výpočetních prostředcích, například v poznámkových blocích nebo úlohách Azure Machine Learning, které také vyžadují paměť a síťové prostředky. Doporučujeme zátěžové testování během fáze návrhu vyhodnotit potřeby výpočetních prostředků a zajistit, aby navrhované skladové položky byly vhodné. Často potřebujete ruční testování, abyste zjistili nejlepší konfiguraci pro efektivní spuštění úlohy v rámci časového limitu.
Napište skripty pomocí specializovaných sad SDK, které zpracovávají většinu úloh. Vzhledem k tomu, že skripty jsou stále kódem, měli byste integrovat testování jednotek jako součást vývoje. Tyto testy vám pomůžou zajistit, aby při aktualizaci závislostí nedošlo k žádné regresi. Pokud testování jednotek není možné, je ruční testování nezbytné před nasazením nového kódu, aby se zabránilo regresím kvality.
Tyto skripty se spouští jako součást pracovního postupu, jako je studio Azure Machine Learning, které můžou poskytnout přehled o tom, kdy a jestli se skript spustil. Doporučujeme ale spouštět integrační testy, abyste měli jistotu, že tyto skripty jsou spolehlivě vyvolány.
Vyhodnocení a otestování modelu
Poznámka:
Hodnocení a testování modelů se často používají zaměnitelně, ale měly by se považovat za samostatné procesy, které používají odlišné datové sady. Vyhodnocení je iterativní aktivita, kterou provádíte ve fázi vývoje. Zaměřuje se na experimentování a nalezení nejlepšího modelu se správnou úrovní ladění. Zahrnuje úpravu hyperparametrů, konfigurací nebo funkcí a následné vyhodnocení modelu na základě různých metrik. Jakmile identifikujete nejlepší model, proveďte testy během nasazení.
Testování zahrnuje ověření celého systému, včetně vyladěných modelů a komponent jiných než AI, aby bylo možné zkontrolovat, jestli fungují správně, dobře integrovat a poskytovat očekávané výsledky v souladu se standardy kvality. Vyhodnoťte model in situ spolu s dalšími komponentami úlohy. Tento proces zahrnuje odesílání požadavků do modelu, vyhodnocení odpovědí a rozhodování na základě testovacích dat. I když testování není možné před produkčním prostředím, doporučujeme, abyste také provedli testy v produkčním prostředí pomocí skutečných dat a syntetických dat.
Použití dat k vyhodnocení a testování
Obvykle existují tři klíčové datové sady rozdělené ze zdrojových dat: trénování, vyhodnocení a testování.
K trénování modelu použijte trénovací datovou sadu, která je obvykle největší podmnožinou. K upřesnění modelu prostřednictvím iterativního procesu pomocí jiné datové sady můžete vyhodnotit různé permutace. Jakmile najdete uspokojivou permutaci, otestujte ji na testovací datové sadě.
Všechny datové sady by měly obsahovat vysoce kvalitní data, aby se minimalizoval šum. Testovací případy příjmu dat a předzpracování kanálů můžou sloužit jako kontrolní body kvality. Nedostatek vzorků může také přiřazovat k datům nízké kvality. Používejte syntetická data k vyvážení a dosažení jednotnosti v datové sadě. Tento přístup je užitečný pro trénovací modely, jako jsou modely detekce podvodů, kde jsou skutečné případy podvodů vzácné, což ztěžuje získání dostatečné statistické síly pro spolehlivé předpovědi.
Abyste se vyhnuli předsudkům v předpovědích, ponechte všechny datové sady odlišné. K vyhodnocení byste neměli používat trénovací data a k testování byste neměli používat data vyhodnocení. Vyhraďte si jedinečná data pro vyhodnocení modelu a konečné testování.
Použití metrik vyhodnocení
Trénování modelu a výběr správného modelu pro produkci jsou vzájemně závislé procesy. Nejdřív je potřeba zvolit model, ale po experimentování a vyhodnocení se to může změnit.
Vyhodnocení modelu následuje jako smyčka experimentování, která pomocí metrik vyhodnocuje řadu permutací modelů, parametrů a funkcí. Tyto metriky poskytují vědecké hodnocení, která musíte iterativním způsobem porovnat v různých verzích a konfiguracích, abyste mohli určit nejlepší model. Další informace najdete v tématu Metriky vyhodnocení.
Podobný přístup se vztahuje na modely generující umělé inteligence. Mají procesy, které vyhodnocují a kvantifikují výsledky uživatelského prostředí na základě výkonu modelu. Uzemnění je například jednou z klíčových metrik, které kvantifikují, jak dobře model odpovídá zdrojovým datům. Levancy je další důležitá metrika, která označuje, jak je relevantní odpověď na dotaz. Například metriky najdete v tématu Vyhodnocení a monitorování metrik pro generování umělé inteligence.
Vyhodnoťte různé typy modelů pomocí různých metrik. Důležitost každé metriky se může lišit v závislosti na scénáři. Určete prioritu metrik na základě případu použití. Například nestrannost je zásadní v zodpovědné umělé inteligenci. I přes dobré testování mohou modely stále vykazovat nespravedlivé předsudky kvůli zkresleným zdrojovým datům. Výsledky můžou mít vysoké skóre v levnosti, ale nízké v nestrannosti. Integrujte vyhodnocení nestrannosti do procesu, abyste zajistili nestranné výsledky.
Generování umělé inteligence se integruje s kódem orchestrace, logikou směrování a indexem pro načítání rozšířené generace (RAG), což komplikuje vyhodnocení. I když byste modely měli vyhodnotit jednotlivě pomocí metrik, je také důležité vyhodnotit další systémové komponenty.
Test modelu
Jemné ladění je v podstatě testování, protože upravuje předem natrénovaný model tak, aby změnil jeho chování. K pochopení počátečního výkonu modelu je potřeba začít se směrným plánem. Po vyladění znovu vyhodnocete výkon modelu, abyste zajistili, že splňuje standardy kvality. Zvažte následující běžné metriky vyhodnocení:
Uzemnění odkazuje na zarovnání modelu se zdrojovými daty. Základní model generuje odpovědi, které jsou konzistentní s realitou.
Levancy označuje, jak relevantní je odpověď na danou otázku. Vysoce uzemněná odpověď může chybět, pokud se na tuto otázku neřeší přímo.
Podobnost měří podobnost mezi zdrojovým textem dat a vygenerovanou odpovědí. Používal model přesné formulace? Nedostatek redakčních zásad správného řízení může snížit skóre podobnosti.
Načtení označuje efektivitu indexových dotazů. Vyhodnoťte, jak dobře načtená data indexu odpovídají otázce. Irelevantní data z vyhledávání v indexu toto skóre sníží. Vyšší skóre načítání značí nižší variabilitu, protože se spoléhají výhradně na dotazy indexu.
Fluency se vztahuje k použití slovníku. Pokud model dodržuje vodítko stylu a prezentuje obsah ve vhodném formátu, může být plynulý, i když chybí uzemnění nebo převyšující.
Soudržnost vyhodnocuje, jestli řečový proud modelu přirozeně a koherentním způsobem. Vyhodnocuje, jestli konverzace vypadá jako pravá výměna.
Testování hyperparametrů
Parametry modelu závisí na rozhodnutích o návrhu specifických pro aplikaci. V rámci návrhu aplikace zvolte model a parametry na základě případů použití vaší úlohy. Proces testování má iterativní vnitřní smyčku, kde se trénovací data porovnávala s testovacími daty a ověřila, že model trénuje na zamýšlené datové sadě. Parametry jsou také vyladěné tak, aby model mohl provádět předpovědi s přijatelnou úrovní přesnosti.
Kompromis. Vnitřní smyčka zahrnuje výpočetní náklady na trénování modelu a náklady na jeho vyhodnocení prostřednictvím testů. Do této smyčky musíte zohlednit čas, který vyžaduje trénování a testování modelu. Očekáváme, že proces testování bude trvat déle, než je proces trénování. Počáteční testování na podmnožině trénovacích dat můžete provést k vyhodnocení toho, jestli model vytváří rozumné výsledky. Tuto testovací sadu můžete postupně vertikálně navýšit na úplnou datovou sadu.
Otestování koncového bodu odvozování
Koncový bod odvozování je rozhraní REST API, které umožňuje přístup k modelům pro vytváření předpovědí. Jedná se o rozhraní, ve kterém odesíláte data jako součást požadavku a získáte odpověď, která obsahuje výsledky z modelu. Koncový bod je hostovaný na výpočetních prostředcích, což může být PaaS, jako je Služba Azure OpenAI nebo server odvozování od jiných společností než Microsoft, například NVIDIA Triton Inference Server, TorchServe a BentoML. Ve scénářích PaaS zpracovává poskytovatel služeb testování v určitém rozsahu. Pokud ale koncový bod hostujete, zacházejte s ním jako s jakýmkoli jiným rozhraním API a důkladně ho otestujte.
I když model testujete během trénování a hodnocení, testování koncového bodu odvozování zahrnuje zajištění správného fungování mechanismů kolem tohoto modelu, jako je zpracování požadavků, vytváření odpovědí, škálování a koordinace napříč instancemi. Vytvořte komplexní testovací plán, který se zabývá případy použití na základě vašich požadavků. Tato část popisuje některé ukázkové testovací případy a typy testů, které je potřeba zvážit.
Aspekty testování pro odvozování hostitelských serverů
Je důležité pochopit charakteristiky zatížení výpočetních prostředků a ověřit výkon prostřednictvím zátěžového testování. Tyto akce vám pomůžou zvolit technologie při návrhu nebo optimalizaci architektury. Různé servery pro odvozování mají například různé charakteristiky výkonu. Kód spotřebovává cykly procesoru a paměť při nárůstu počtu souběžných připojení. Porozumíte tomu, jak váš kód a výpočetní prostředky fungují v rámci standardních a špiček zatížení. Zátěžové testování Azure je dobrou volbou pro zátěžové testování a může generovat velké objemové zatížení. Oblíbené jsou i další opensourcové možnosti, jako je Apache JMeter. Zvažte vyvolání těchto testů přímo z vašeho prostředí. Machine Learning se například dobře integruje se zátěžovým testováním.
Dalším klíčovým rozhodnutím je volba možností GPU. Mnoho modelů kvůli jejich návrhu vyžaduje grafické procesory (GPU) pro efektivní odvozování. Zátěžové testování vám pomůže pochopit limity výkonu skladové položky GPU a zabránit nadměrnému zřízení, což jsou významné finanční aspekty.
U hostitelských platforem mimo PaaS je zabezpečení zásadní, protože rozhraní API je veřejně zveřejněné. Je důležité zajistit, aby koncový bod nebyl zneužít nebo ohrožen, což může ohrozit celý systém. Tento koncový bod zahrňte jako součást rutinního testování zabezpečení spolu s dalšími veřejnými koncovými body. Zvažte provádění testů, jako je penetrační testování, v živém systému. Dalším aspektem zabezpečení je bezpečnost obsahu. Kód může volat specializovaná rozhraní API, která detekují škodlivý obsah v datové části požadavku a odpovědi. Azure AI Content Safety je možné volat z testování, aby se usnadnilo testování bezpečnosti obsahu.
Klíčové strategie najdete v tématu Doporučení pro testování zabezpečení.
Aspekty testování koncových bodů odvozování PaaS
Klient by měl při odesílání požadavků do koncového bodu odvozovat ve službě PaaS očekávat chyby. K selháním může dojít z důvodu přetížení systému, nereagujícího back-endu a dalších chybových podmínek. Proveďte analýzu režimu selhání služby a otestujte tyto potenciální chyby. K návrhu a implementaci strategií zmírnění rizik v klientském kódu se vyžaduje analýza režimu selhání. Rozhraní API Azure OpenAI například omezují požadavky vrácením kódu odpovědi na chybu HTTP 429. Klient by měl tuto chybu zpracovat pomocí mechanismů opakování a jističů. Další informace najdete v tématu Doporučení k provádění analýzy režimu selhání.
Testování služeb PaaS vám může pomoct vybrat skladové položky služeb, protože rozumíte souvisejícím nákladům, jako jsou průběžné platby nebo předem zřízené výpočetní prostředky. Pomocí cenových kalkulaček Azure můžete vyhodnotit zatížení, frekvenci a využití tokenů a určit nejlepší možnosti fakturace a výpočetních prostředků. Simulace úloh s nízkonákladovými skladovými jednotkami a odůvodněním vysoce koncových možností, jako jsou zřízené jednotky propustnosti (PTU) pro Azure OpenAI
Zátěžové testování není tak relevantní pro výpočetní prostředky s průběžnými platbami, protože s neomezenou kapacitou narazíte na problémy. Testování ověří limity a kvóty. Nedoporučujeme zátěžové testování výpočetních prostředků s průběžným platbou, protože se jedná o významné finanční výdaje. Měli byste ale zátěžový test ověřit propustnost, která se měří v tokenech za minutu nebo požadavky za minutu. Na rozdíl od standardních rozhraníAPIch Klíčem je porozumět počtu aktivních uživatelů a odpovídajícím způsobem měřit propustnost. Další informace najdete v tématu Měření propustnosti.
Použití bezpečnostních prvků
Bez ohledu na to, jestli používáte odvozovací server nebo možnost PaaS, zodpovídáte za zabezpečení. S koncovými body rozhraní API je důležité testovat kontroly zabezpečení jailbreaku a obsahu. Ujistěte se, že se tyto ovládací prvky nedají obejít a fungují podle očekávání. Odeslání známé blokované položky vám například může pomoct ověřit, jestli jsou zavedené bezpečnostní prvky a fungují správně před nasazením. Zvažte spuštění těchto testů podle potřeby nebo jejich integraci do procesu vydání.
Je důležité otestovat, jestli systém může neúmyslně zveřejnit informace, které by neměl. Systém by například neměl zveřejnit osobní údaje v datové části odpovědi. Otestujte také, jestli klient nemá přístup ke koncovým bodům určeným pro jiné identity. Proveďte testy zabezpečení a ověřte, že rozhraní API s ověřovacími a autorizačními mechanismy nevrací důvěrné informace a udržuje správné segmentace uživatelů.
Testování podkladových dat
Návrh dat ovlivňuje efektivitu generujícího modelu a základní data jsou důležitou součástí. Podkladová data poskytují více kontextu pro zvýšení relevance odpovědi. Indexuje se před dosažením modelu. K tomuto indexu se přistupuje v reálném čase, protože uživatel čeká na odpověď.
Proveďte komplexní testování a začleňte tento proces jako součást návrhu dat. Implementujte proces testování, který vyhodnocuje a kvantifikuje výsledky prostředí zákazníka na základě výkonu, orchestrace, indexu, předběžného zpracování a zdrojových dat modelu. Monitorujte a změřte metriky kvality iterativním způsobem. Tady je několik aspektů:
Důkladně otestujte zpracování dat pomocí funkčního a integračního testování. Ověřte, že jsou data načtena podle očekávání a zda jsou všechna data přítomna.
Otestujte schéma indexu pro zpětnou kompatibilitu. Všechny změny dokumentu nebo pole byste měli otestovat, abyste měli jistotu, že nová verze bude i nadále vyhovovat předchozím verzím dat.
Před indexováním dat prochází přípravou na snížení šumu a předsudků a umožnění efektivního dotazování. Tento proces zahrnuje předběžné zpracování, blokování dat a výpočet vkládání a každý krok ukládá data do kontextu nebo souborů v indexu. Tento postup provádí kanál orchestrace, jako jsou sady dovedností poskytované službou Azure AI Search. Kód orchestrace musíte otestovat, abyste zajistili, že se nezmešká žádné kroky a zpracovávaná data jsou vysoce kvalitní.
Testy by měly zkontrolovat stará data, syntetické hodnoty, prázdné tabulky, aktualizaci dat a zpracování v nejnovější verzi. Pokud dojde k selhání testů, možná budete muset upravit vyhledávací dotaz a index. Tento proces zahrnuje úpravy filtrů a dalších prvků probíraných dříve. Testování byste měli považovat za iterativní aktivitu.
Indexy jsou složité a výkon dotazů se může lišit v závislosti na struktuře indexu, která vyžaduje odhad zatížení. Správné zátěžové testování může pomoct určit různé skladové položky úložiště, výpočetních prostředků a dalších prostředků, které jsou k dispozici pro podporu vašich požadavků.
Musíte otestovat všechny kontrolní mechanismy zabezpečení. Například data můžou být rozdělena do samostatných dokumentů. Každý oddíl má řízení přístupu. Abyste ochránili důvěrnost, musíte tyto ovládací prvky řádně otestovat.
Testování orchestrátoru
Klíčovou součástí aplikace RAG je centrální orchestrátor. Tento kód koordinuje různé úlohy, které se vztahují k počáteční otázce uživatele. Úlohy orchestratoru obvykle vyžadují pochopení záměru uživatele, připojení k indexu, aby vyhledaly základní data a volaly koncový bod odvozování. Pokud agenti potřebují provádět úlohy, jako je volání rozhraní REST API, tento kód tyto úlohy zpracovává v kontextu.
Kód orchestrace můžete vyvíjet v libovolném jazyce nebo ho psát úplně od začátku. K urychlení a zjednodušení procesu vývoje ale doporučujeme používat technologie, jako je tok výzvy v Azure AI Studiu nebo cyklické acyklické grafy Apache Airflow. Tok výzvy poskytuje prostředí v době návrhu. Slouží k modularizaci úkolů jako jednotek a propojení vstupů a výstupů jednotlivých jednotek a nakonec tvoří kód orchestrace, který představuje celý proces.
Izolujte svůj orchestrační kód. Vyvíjejte ho samostatně a nasaďte ji jako mikroslužbu s online koncovým bodem a rozhraním REST API pro přístup. Tento přístup zajišťuje modularitu a snadné nasazení.
Z hlediska testování zachází s tímto kódem stejně jako s ostatními testy jednotek. Důležitějším aspektem je ale jeho funkce, například logika směrování, kterou můžete ověřit prostřednictvím funkčního a integračního testování. Otestujte přípravu výzvy, abyste zajistili, že kód dokáže správně rozpoznat záměr uživatele a směrovat volání. Existuje několik architektur a knihoven pro testování, jako je Scikit-learn, modul torch.testing PyTorch, FairML pro předsudky a testování nestrannosti a analýza modelu TensorFlow pro vyhodnocení modelu.
Také proveďte běhové testy, jako je testování v režimu selhání. Můžete například otestovat potenciální selhání související s omezeními tokenů.
Určité běhové testy vám můžou pomoct při rozhodování. Spusťte zátěžové testy , abyste pochopili, jak se tento kód chová pod stresem, a použijte výsledky pro plánování kapacity. Vzhledem k tomu, že je tento kód umístěný v klíčovém bodě architektury, kde potřebuje oslovit jiné služby, může pomoct shromažďovat telemetrická data ze všech těchto volání. Tato data můžou poskytovat přehled o tom, kolik času se věnuje místnímu zpracování a síťovým voláním, a určit chování jiných komponent, jako je potenciální latence. Technologie, jako je tok výzvy, mají integrované možnosti telemetrie pro usnadnění tohoto procesu. Jinak začleníte telemetrii do vlastního kódu.
Poznámka:
Testování tohoto kódu má vliv na náklady. Pokud například k hostování koncového bodu odvozování použijete Azure OpenAI, zátěžové testování je běžný postup, který vám pomůže určit limity systému. Azure OpenAI se ale účtuje za každé volání, což může výrazně usnadnit zátěžové testování. Jedním ze způsobů, jak optimalizovat poplatky, je použití nepoužívaných PTU Azure OpenAI v testovacím prostředí. Případně můžete simulovat koncový bod odvození.
Aspekty zabezpečení se týkají kódu orchestrace i modelu. Zahrňte testování pro jailbreak, kde je cílem narušit zabezpečení modelu. Útočníci s modelem přímo nekomuagují. Nejprve komunikují s kódem orchestrace. Kód orchestrace přijímá požadavky uživatelů a parsuje je. Pokud kód orchestrace obdrží škodlivý požadavek, může tento požadavek předat modelu a potenciálně ohrozit model.
Bezpečnost obsahu je dalším důležitým aspektem. V chatovací aplikaci přijímá kód orchestrace text chatu. V kódu zvažte volání služby zabezpečení obsahu. Odešle výzvu uživatele i kontext základu pro analýzu a obdrží posouzení rizika. Prompt Shields je sjednocené rozhraní API, které analyzuje vstupy velkých jazykových modelů a detekuje útoky na výzvy uživatele a útoky na dokumenty, což jsou dva běžné typy nežádoucích vstupů.
Řízení zabezpečení a ověřování jsou zásadní pro koncový bod RESTful. Potřebujete spravovat ověřování a zajistit důkladné testování.
Prevence rozpadu modelu
Běžným problémem pro všechny modely je v průběhu času určité snížení výkonu. Změny, které jsou interní a externí pro úlohu, nakonec způsobí snížení kvality modelu a jeho výstupů. K rozpadu modelu dochází dvěma způsoby:
Posun dat nastane, když se vstupní data změní. Díky novému vstupu dat je trénovaný model zastaralý. Můžete mít například model, který predikuje vzory hlasování v určité geografické oblasti, jako je oblast. Pokud je oblast překreslená a demografické údaje o populaci této oblasti, je potřeba model aktualizovat tak, aby odpovídal změnám.
K posunu konceptu dochází, když se podmínky, které jsou pro úlohy a modely externí, mění tak, že výstupy modelu už neodpovídají realitě. Můžete mít například model prognóz prodeje pro technologický produkt. Pokud konkurent neočekávaně zavádí pokročilejší konkurenční produkt, který upozorňuje na veřejnost, musíte model aktualizovat na základě toho, jak se mění trendy spotřebitelů.
Pokud je to možné, použijte automatizované testování k detekci a vyhodnocení rozkladu modelu v životním cyklu modelu. Pokud váš model predikuje diskrétní hodnoty, můžete vytvořit testy pro vyhodnocení předpovědí proti těmto hodnotám v průběhu času a změřit odchylku mezi očekávanými a skutečnými výsledky. Doplňte toto testování monitorováním za účelem zjištění posunu v průběhu času porovnáním souhrnných statistik a metrik vzdálenosti.
Dalším běžným přístupem k identifikaci rozpadu modelu je zpětná vazba uživatelů. Příkladem zpětné vazby uživatelů je mechanismus odezvy palce nahoru nebo palce dolů. Sledování pozitivní a negativní zpětné vazby v průběhu času a vytvoření upozornění při splnění prahové hodnoty negativní zpětné vazby vám může pomoct zjistit, kdy prozkoumat kvalitu modelu.
Bez ohledu na signály, které používáte k identifikaci rozpadu modelu, provozní tým, který je upozorňovaný na potenciální pokles, potřebuje zapojit datového vědce, aby prozkoumal signál a určil, jestli se rozpad děje a původní příčina.
Implementace nástrojů
Pomocí kolektoru dat Azure Machine Learning můžete získat protokolování vstupních a výstupních dat v reálném čase z modelů nasazených do spravovaných online koncových bodů nebo online koncových bodů Kubernetes. Machine Learning ukládá protokolovaná data odvozování v úložišti objektů blob v Azure. Tato data pak můžete použít pro monitorování, ladění nebo auditování modelů, které poskytují pozorovatelnost výkonu nasazených modelů. Pokud nasadíte model mimo službu Machine Learning nebo do dávkového koncového bodu služby Machine Learning, nemůžete využít kolektor dat a potřebujete zprovoznit jiný proces shromažďování dat.
K implementaci monitorování použijte monitorování modelu Machine Learning. Machine Learning získává monitorovací signály prováděním statistických výpočtů na streamovaných produkčních datech odvozování a referenčních dat. Referenční data mohou být historická trénovací data, ověřovací data nebo základní pravdivá data. Na druhou stranu data odvozování produkce odkazují na vstupní a výstupní data modelu shromážděná v produkčním prostředí.
- Podívejte se na monitorování modelu Machine Learning a seznamte se s možnostmi monitorování služby Machine Learning a metrikami , které zachycuje a analyzuje.
- Další doporučení pro monitorování najdete v osvědčených postupech .