Testa och utvärdera AI-arbetsbelastningar i Azure
Syftet med testning i AI-arbetsbelastningar är att säkerställa kvalitet när en ändring introduceras i systemet. Testning kan verifiera om arbetsbelastningen uppfyller identifierade mål och uppfyller användarnas förväntningar. Det förhindrar också kvalitetsregressioner. Den här processen omfattar att utföra tester inom olika funktionella områden och utvärdera kvaliteten på funktioner, belastningshantering, förutsägbarhet och andra kriterier baserat på arbetsbelastningskrav.
Testresultat ger viktiga datapunkter för beslut som om AI-komponenter är redo för lansering och vilka SKU:er eller funktioner som är lämpliga. Dessutom kan testning fungera som ett meddelandesystem för fel och hjälpa till att identifiera problem i produktionen genom rutinmässiga eller syntetiska tester.
Azure Well-Architected Framework beskriver en omfattande testmetod. Du bör använda olika typer av tester i olika skeden av utvecklingslivscykeln och mellan olika systemkomponenter och flöden. Utan dessa tester kan utrullningsbara ändringar försämra systemkvaliteten. Mindre kodfel kan till exempel bli stora systemfel. Systembeteendet kan bli oförutsägbart eller ge partiska resultat på grund av AI-systemens icke-obestämda karaktär. Resursallokeringen kan också vara ineffektiv och verkliga användardata eller systemresurser kan utnyttjas eftersom dessa system är sårbara för missbruk.
Du måste utforma och utveckla arbetsbelastningstillgångar med testning i åtanke. När du till exempel utför datamanipulering och omformar källdata för funktionsutveckling följer du god kodningspraxis och ser till att du strukturerar koden så att den stöder testning. I den här strategin ingår att utforma koden för att underlätta effektiv enhetstestning och isolera testerna från kodens funktioner och dess beroenden. I det här exemplet måste du utforma ett system som kan utföras i en testmiljö med tillräckligt representativa testdata när det gäller volym och likhet.
Du måste distribuera arbetsbelastningskomponenter till produktion på ett säkert sätt. En del av arbetsbelastningens säkra distributionsmetoder är strategisk testning för att säkerställa korrekt beteende innan användare eller data använder systemet. Strategisk testning är viktigt under den inledande distributionen och när systemet utvecklas och genomgår kod- eller infrastrukturändringar. Testa alla föreslagna ändringar i AI-relaterad kod och infrastruktur innan du distribuerar ändringarna till produktion.
Den här artikeln fokuserar på att tillämpa den metoden på AI-aspekterna av arkitekturen. Hur du utför dessa tester finns inte i omfånget.
Rekommendationer
Här är sammanfattningen av rekommendationerna i den här artikeln.
| Rekommendation | beskrivning |
|---|---|
| Definiera framgångsmått för din teststrategi. | Precis som andra typer av arbetsbelastningstester måste du samla in och analysera lämpliga mått för ett visst test för att säkerställa att testet ger användbara insikter om din AI-arbetsbelastning. ▪ Definiera lyckade mått |
| Utför slutpunkt-till-slutpunkt-testning av dina datainmatnings- och bearbetningspipelines under hela utvecklingslivscykeln. | Tester kan verifiera data och hjälpa dig att se till att datamanipuleringsprocessen fungerar som avsett. Införliva testning tidigt i designfasen för att säkerställa datakvalitet och lämplig teknik och storleksval. Utveckla enhetstester för anpassad kod under utvecklingen och utför produktionstester i realtid för att fånga upp problem och validera funktioner. ▪ Testa datainmatning |
| Kör tester för träningsjobb för att se till att skripten anropas och fungerar som förväntat. | Belastnings- och prestandatestning kan ge insikter om val och storleksändring av beräkning som är lämplig för att köra jobben. Enhetstester kan verifiera verktyget för koden och fånga regressioner när beroenden uppdateras. ▪ Testa träningsarbetsflödet |
| Utvärdera och testa modellen för att undvika duplicering i tränings-, utvärderings- och testdata. | För att säkerställa att källdata inte används helt för träning måste du reservera unika data för modellutvärdering och slutlig testning. Dessa delmängder ingår inte i själva träningsprocessen. ▪ Utvärdera och testa modellen |
| Testa slutpunkten för slutsatsdragning. | Utför belastningstestning på slutpunkten som din slutsatsdragningsserver är värd för och välj GPU-SKU:er baserat på dessa testresultat. För PaaS-värdbaserade slutpunkter (Plattform som en tjänst) testar du dataflödet och de potentiella felen. Dessa slutpunkter kan nås, så utför korrekt säkerhetstestning för att förhindra jailbreaking-situationer. ▪ Testa slutpunkten för slutsatsdragning |
| Testa indexdesignens korrekthet så att frågor ger relevanta resultat. | Funktions- och integreringstestning hjälper dig att se till att data är korrekta och att indexschematestning söker efter bakåtkompatibilitet. Du måste testa förbearbetningsstegen för kvalitet. Belastningstestning avgör lämpliga SKU:er för resurser och säkerhetskontroller skyddar datasekretessen. ▪ Testa jordningsdata |
| Testa orkestratorn för att verifiera dess funktioner och säkerhet. | Utför enhets-, funktions-, integrerings- och körningstester, inklusive testning av belastnings- och felläge, för att säkerställa prestanda och tillförlitlighet. Säkerhets- och innehållssäkerhetstestning är också avgörande för att skydda systemet och data. ▪ Testa orkestratorn |
| Test för modellförfall. | Modellförfall är ett oundvikligt problem som påverkar de flesta AI-arbetsbelastningar. Testning av data och konceptavvikelser kan hjälpa dig att fånga modellförfall tidigt och minimera problemet innan det påverkar din arbetsbelastning negativt. ▪ Förhindra modellförfall |
Definiera lyckade mått
Vi rekommenderar att du har en baslinje och mäter modellens förutsägelsekraft med hjälp av väldefinierade mått. Här följer några vanliga mått.
Noggrannhet representerar förhållandet mellan korrekt förutsagda instanser och de totala instanserna i testdatauppsättningen. Det är ett vanligt mått på övergripande modellprestanda.
Precision är förhållandet mellan sanna positiva förutsägelser och summan av sanna positiva identifieringar och falska positiva identifieringar. Det är användbart när det är viktigt att minimera falska positiva identifieringar, till exempel i medicinska diagnoser.
Känslighet mäter förhållandet mellan sanna positiva identifieringar och summan av sanna positiva och falska negativa värden. Det är värdefullt när det är viktigt att undvika falska negativa identifieringar eller att relevanta fall saknas.
Specificitet beräknar förhållandet mellan sanna negativa värden och summan av sanna negativa och falska positiva identifieringar. Det är relevant när du optimerar för korrekta negativa förutsägelser.
Kommentar
När du definierar framgångsmått för regressionsmodeller bör du överväga att lägga till följande mått:
Mean Absolute Error (MAE) mäter den genomsnittliga absoluta skillnaden mellan de förutsagda värdena och de faktiska värdena. Beräkna det genom att ta medelvärdet av de absoluta skillnaderna mellan varje faktiskt värde och dess motsvarande förutsagda värde. MAE är mindre känslig för extremvärden jämfört med MSE och RMSE.
MSE (Mean Squared Error) mäter den genomsnittliga kvadratskillnaden mellan de faktiska värdena och de förutsagda värdena. Beräkna det genom att ta medelvärdet av kvadratskillnaderna mellan varje faktiskt värde och dess motsvarande förutsagda värde. MSE straffar större fel mer än MAE eftersom felen är kvadratiska.
RMSE (Root Mean Squared Error) är kvadratroten för MSE. Det ger ett mått på det genomsnittliga absoluta felet mellan de faktiska och förutsagda värdena, men i samma enheter som de ursprungliga data. RMSE är mer känsligt för extremvärden jämfört med MAE eftersom det kvadraterar felen före genomsnitt.
Testa datainmatning
Datapipelines, som att extrahera, transformera och läsa in (ETL) processer, flytta och manipulera data. Testa ETL-delen av arbetsbelastningen för att se till att den matar in data på ett tillförlitligt sätt och att data är av hög kvalitet och godkända för analys och funktionsutveckling. Kontrollera att datarensning och bearbetning innehåller tester för att bekräfta att datamanipulering fungerar som avsett.
Testningen bör integreras under hela livscykeln, inklusive utformnings-, utvecklings- och produktionsfaserna.
Testa för att underlätta designval
När du samlar in krav för arbetsbelastningen är ett viktigt beslutssteg att välja ett specifikt teknikalternativ som är genomförbart för din design.
Baserat på dina ETL-krav och acceptanskriterier utför du undersökande funktionella tester för att välja den lämpligaste produkten, dess SKU:er och funktioner som utför de avsedda uppgifterna. Konceptbevis, teknikbevis och bevis på funktionstester är viktiga för att utvärdera om du väljer rätt teknik och om den har rätt storlek.
För scenarier där du införlivar AI i en befintlig arkitektur kan du testa hur väl den nya tekniken kan integreras med det aktuella systemet.
De inledande arbetsbelastningskraven kan ändras. Anta att företaget förväntar sig tillväxt och att systemet måste hantera dubbla vanliga användarfrågor. Den här förväntan kräver korrekt kapacitetsplanering. Vi rekommenderar proaktiv testning för att förstå hur systemet svarar på extra data och för att göra datadrivna justeringar av befintlig storlek eller göra nya produktval. För kapacitetstestning rekommenderar vi att du kombinerar funktionell testning med belastnings- och prestandatestning och använder syntetiska för att simulera realistiska förhållanden.
Testa för att säkerställa kodkvalitet
När koden ingår kontrollerar du att den genomgår enhetstestning och inte släpps om den misslyckas. Det är till exempel vanligt att ha anpassad kod som körs som en del av inmatningen. Det finns också kod som används för datarensning och bearbetning. Kör enhetstester för att säkerställa att koden fungerar enligt dess design och att datamanipulering fungerar som förväntat.
Kör tester som en del av din pipeline för kontinuerlig integrering och kontinuerlig leverans.
Testa i det aktiva systemet
Funktionstestning bör omfatta det aktiva systemet. Om dessa tester misslyckas bör du överväga att utlösa aviseringar för att initiera omedelbara undersökningar om det behövs. Nedan följer några exempel:
Kör schemalagda tester för att kontrollera att rätt datavolym samlades in om data matas in enligt ett angivet schema med en förväntad mängd.
Kör tester som identifierar dataproblem, till exempel saknade värden eller duplicerade data, och utför grundläggande dataintegritetskontroller. Om data innehåller tidsmässig information som indikerar dess färskhet kan dessa tester kontrollera informationen och eventuellt förhindra att nedströmsprocesser använder inaktuella data.
Kontrollera tillgängligheten för externa beroenden. Ett datarensningsjobb kan till exempel anropa en annan tjänst för att extrahera tabeller eller förbearbetning. Kör tester för att säkerställa att de är tillgängliga eftersom deras otillgänglighet kan påverka ETL-processen.
Ett annat sätt att testa ETL-systemets korrekthet i produktionen är genom syntetisk testning. Att ha kända testdata tillgängliga i produktion är mycket effektivt. Du kan använda den för att verifiera bearbetning från slutpunkt till slutpunkt genom att jämföra det kända starttillståndet med det förväntade sluttillståndet för dessa data. Ett dokument krävs till exempel för att gå igenom dokumentinformation och innehåller personuppgifter. När du matar in ett syntetiskt dokument kan du testa att arbetsbelastningen utför datamanipuleringsjobbet som avsett.
Experimentera dessutom genom att släppa olika upplevelser, även kallat A/B-testning, för att lära dig av användarinteraktioner innan du genomför dem helt. A/B-testning hjälper dig att förhindra kvalitetsregressioner.
Testa data som samlas in under inmatning
Som en del av inmatningsprocessen från olika datakällor inkluderar du tester för att verifiera att träningsdata matchar dina förväntningar.
Att träna en maskininlärningsmodell med ofullständiga eller skadade data kan vara kontraproduktivt. Det kan leda till bortkastade ansträngningar och resultera i en modell som inte kan göra meningsfulla förutsägelser. Dina datainmatnings- och förbearbetningspipelines innehåller kvalitetstester som kontrollpunkter. De här testerna kan hjälpa dig att kontrollera att dina data överensstämmer med de förväntningar som du har angett under dataanalys och funktionsutveckling.
Följande lista innehåller några exempel på testfall:
Testa för fullständighet. Testa den förväntade mängden träningsdata för att verifiera datamängdens fullständighet. Det här testet säkerställer att du tillhandahåller tillräckligt med data för att träna modellen.
Testa för viktig information. Om träningen baseras på kända entiteter, till exempel specifika poster eller identifierare, testar du datauppsättningen för att se till att dessa entiteter finns. Den här verifieringen säkerställer att viktig information inte saknas.
Testa för irrelevanta data. Inmatade data får inte innehålla irrelevanta eller felaktiga poster. Datainmatningsprocessen bör filtrera bort dessa data.
Testa för färskhet. Färskhet i inmatade data bör inte påverka modellens prediktiva effekt. Verifiera att data återspeglar rimligen aktuell information och inte är inaktuella från tidigare körningar. Om du till exempel förväntar dig att data ska innehålla poster från den senaste veckan, men det inte finns några sådana poster efter att du har importerat data, kan det tyda på ett problem med en misslyckad import eller data freshness i källsystemet.
Utföra rutintester
Ett stort problem med datainmatning är mängden data och dataflöde. Kontinuerlig utvärdering under driften är nödvändig för att förhindra flaskhalsar i prestanda. Den här pågående utvärderingen bör vara en del av dina operativa processer i stället för bara ett engångstest. Målet är att se till att arbetsbelastningsteamet inte missar sina servicenivåmål.
Tänk dig en situation där övervakning indikerar prestandaförsämring. Om du vill minimera sådana villkor kan du omvärdera och optimera ETL-processerna. När du har ändrat kan prestandatester hjälpa dig att se till att ändringarna uppfyller det dataflöde som krävs.
Kommentar
Testning och övervakning har olika syften. Utför tester för att utvärdera potentiella ändringar i systemet, vanligtvis innan du implementerar några ändringar. Utför kontinuerligt övervakning för att utvärdera systemets allmänna hälsa.
Testa träningsarbetsflödet
Träna en modell med hjälp av anpassad kod, till exempel PyTorch-skript, som utför det faktiska träningsarbetet. Dessa skript körs på beräkning, till exempel i notebook-filer eller Azure Machine Learning-jobb, som också kräver minnes- och nätverksresurser. Vi rekommenderar belastningstestning under designfasen för att utvärdera beräkningsbehoven och se till att de föreslagna SKU:erna är lämpliga. Du behöver ofta manuell testning för att fastställa den bästa konfigurationen för att effektivt köra arbetsbelastningen inom tidsgränsen.
Skriv skripten med hjälp av specialiserade SDK:er, som hanterar de flesta av uppgifterna. Men eftersom skript fortfarande är kod bör du integrera enhetstestning som en del av utvecklingen. De här testerna hjälper dig att se till att inga regressioner inträffar när du uppdaterar beroenden. Om enhetstestning inte är möjligt krävs manuell testning innan du distribuerar ny kod för att förhindra kvalitetsregressioner.
Dessa skript körs som en del av ett arbetsflöde, till exempel Azure Machine Learning-studio, som kan ge insikter om när och om skriptet kördes. Men vi rekommenderar att du kör integreringstester för att se till att skripten anropas på ett tillförlitligt sätt.
Utvärdera och testa modellen
Kommentar
Modellutvärdering och testning används ofta omväxlande, men de bör betraktas som separata processer som använder distinkta datauppsättningar. Utvärdering är en iterativ aktivitet som du gör under utvecklingsfasen. Den fokuserar på experimentering för att hitta den bästa modellen med rätt justeringsnivå. Den omfattar justering av hyperparametrar, konfigurationer eller funktioner och sedan utvärdering av modellen baserat på olika mått. När du har identifierat den bästa modellen utför du tester under distributionen.
Testning omfattar verifiering av hela systemet, inklusive den finjusterade modellen och icke-AI-komponenter, för att kontrollera att de fungerar korrekt, integrera väl och leverera förväntade resultat i enlighet med kvalitetsstandarder. Utvärdera en modell på plats tillsammans med andra komponenter i arbetsbelastningen. Processen omfattar att skicka begäranden till modellen, utvärdera dess svar och fatta ett go- eller no-go-beslut baserat på testdata. Även om testning inte är förhandlingsbar före produktion rekommenderar vi att du även utför tester i produktion med hjälp av verkliga data och syntetiska data.
Använda data för att utvärdera och testa
Vanligtvis finns det tre viktiga datauppsättningar partitionerade från källdata: träning, utvärdering och testning.
Använd träningsdatauppsättningen, som vanligtvis är den största delmängden, för att träna modellen. Använd en annan datauppsättning för utvärdering för att förfina modellen genom en iterativ process genom att utvärdera olika permutationer. När du har hittat en tillfredsställande permutation testar du den mot testdatauppsättningen.
Alla datauppsättningar bör innehålla data av hög kvalitet för att minimera bruset. Dina testfall om datainmatning och förbearbetningspipelines kan fungera som kvalitetskontroller. Brist på exempel kan också tillskriva data av låg kvalitet. Använd syntetiska data för att balansera och uppnå enhetlighet i datauppsättningen. Den här metoden är användbar för träningsmodeller som modeller för bedrägeriidentifiering, där verkliga bedrägeriinstanser är sällsynta, vilket gör det svårt att få tillräcklig statistisk kraft för tillförlitliga förutsägelser.
Om du vill undvika bias i förutsägelser bör du hålla alla datauppsättningar åtskilda. Du bör inte använda träningsdata för utvärdering och du bör inte använda utvärderingsdata för testning. Reservera unika data för modellutvärdering och slutlig testning.
Använda utvärderingsmått
Att träna en modell och välja rätt för produktion är beroende av varandra. Du måste välja en modell från början, men den kan ändras efter experimentering och utvärdering.
Modellutvärderingen följer som en experimenteringsloop som utvärderar många permutationer av modeller, parametrar och funktioner med hjälp av mått. Dessa mått ger vetenskapliga betyg som du måste jämföra iterativt mellan olika versioner och konfigurationer för att fastställa den bästa modellen. Mer information finns i Utvärderingsmått.
En liknande metod gäller för generativa AI-modeller. Ha processer som utvärderar och kvantifierar resultatet av användarupplevelsen baserat på modellens prestanda. Till exempel är groundedness ett av de viktigaste måtten som kvantifierar hur väl modellen överensstämmer med källdata. Relevans är ett annat viktigt mått som anger hur relevant svaret är för frågan. Exempelmått finns i Utvärderings- och övervakningsmått för generativ AI.
Utvärdera olika typer av modeller med hjälp av olika mått. Vikten av varje mått kan variera beroende på scenariot. Prioritera mått baserat på användningsfallet. Rättvisa är till exempel avgörande för ansvarsfull AI. Trots bra testning kan modeller fortfarande uppvisa orättvisa fördomar på grund av partiska källdata. Resultaten kan få höga resultat i relevans men låg i rättvisa. Integrera rättviseutvärderingar i processen för att säkerställa opartiska resultat.
Generativ AI integreras med orkestreringskod, routningslogik och ett index för hämtning av utökad generation (RAG), vilket komplicerar utvärderingen. Även om du bör utvärdera modellerna individuellt med hjälp av mått är det också viktigt att utvärdera andra systemkomponenter.
Testa modellen
Finjusteringen testas i princip eftersom den ändrar en förtränad modell för att ändra dess beteende. Det kräver att du börjar med en baslinje för att förstå modellens initiala prestanda. Efter finjusteringen omvärderar du modellens prestanda för att säkerställa att den uppfyller kvalitetsstandarderna. Tänk på följande vanliga utvärderingsmått:
Groundedness refererar till modellens justering med källdata. En grundad modell genererar svar som överensstämmer med verkligheten.
Relevans anger hur relevant svaret är på en viss fråga. Ett starkt grundat svar kan sakna relevans om det inte tar upp frågan direkt.
Likheten mäter likheten mellan en källdatatext och det genererade svaret. Använde modellen exakta formuleringar? Brist på redaktionell styrning kan sänka likhetspoängen.
Hämtning anger effektiviteten för indexfrågor. Utvärdera hur väl hämtade indexdata överensstämmer med frågan. Irrelevanta data från indexsökningen sänker den här poängen. Högre hämtningspoäng indikerar lägre variabilitet eftersom de enbart förlitar sig på indexfrågorna.
Fluency relaterar till ordförrådsanvändningen. Om modellen följer en formatguide och presenterar innehåll i lämpligt format kan den vara flytande även om den saknar grundande eller relevans.
Konsekvens utvärderar om modellens tal flödar naturligt och konsekvent. Den utvärderar om samtalet känns som ett äkta utbyte.
Testa hyperparametrar
Modellparametrar beror på programspecifika designbeslut. Som en del av programdesignen väljer du modellen och parametrarna baserat på arbetsbelastningens användningsfall. Testprocessen har en iterativ inre loop där träningsdata jämförs med testdata för att verifiera att modellen tränar på den avsedda datamängden. Dessutom justeras parametrarna så att modellen kan göra förutsägelser med en acceptabel noggrannhetsnivå.
Kompromiss. Den inre loopen innehåller beräkningskostnader för att träna modellen och kostnaden för att utvärdera den via tester. Du måste ta hänsyn till den tid som modellträning och testning kräver i den här loopen. Förvänta dig att testningsprocessen tar längre tid än träningsprocessen. Du kan utföra inledande tester på en delmängd träningsdata för att bedöma om modellen ger rimliga resultat. Du kan gradvis skala upp testuppsättningen till den fullständiga datamängden.
Testa slutpunkten för slutsatsdragning
En slutpunkt för slutsatsdragning är REST-API:et som ger åtkomst till modeller för att göra förutsägelser. Det är gränssnittet där du skickar data som en del av begäran och får ett svar som innehåller resultat från modellen. Slutpunkten finns på beräkning, som kan vara PaaS som Azure OpenAI Service eller en inferensserver från andra länder än Microsoft, till exempel NVIDIA Triton Inference Server, TorchServe och BentoML. I PaaS-scenarier hanterar tjänstleverantören testningen i viss utsträckning. Men om du är värd för slutpunkten behandlar du den som alla andra API:er och testar den noggrant.
Även om du testar modellen under träning och utvärdering innebär testning av slutpunkten för slutsatsdragning att mekanismerna kring modellen, till exempel bearbetning av begäranden, skapande av svar, skalning och samordning mellan instanser, fungerar korrekt. Skapa en omfattande testplan som omfattar användningsfall baserat på dina krav. I det här avsnittet beskrivs några exempel på testfall och testtyper att överväga.
Testöverväganden för slutsatsdragningsvärdservrar
Det är viktigt att förstå belastningsegenskaperna för beräkningen och validera prestanda genom belastningstestning. De här åtgärderna hjälper dig att välja teknik när du utformar eller optimerar arkitekturen. Olika slutsatsdragningsservrar har till exempel varierande prestandaegenskaper. Koden förbrukar CPU-cykler och minne när antalet samtidiga anslutningar ökar. Förstå hur koden och beräkningsresurserna presterar under standard- och belastningstoppar. Azure Load Testing är ett bra alternativ för belastningstestning och kan generera hög volymbelastning. Andra alternativ med öppen källkod, till exempel Apache JMeter, är också populära. Överväg att anropa dessa tester direkt från din miljö. Machine Learning integrerar till exempel bra med belastningstestning.
Ett annat viktigt beslut är valet av GPU-funktioner. Många modeller kräver GPU:er för effektiv slutsatsdragning på grund av deras design. Belastningstestning hjälper dig att förstå prestandagränserna för en GPU-SKU och förhindrar överetablering, vilket är viktiga ekonomiska överväganden.
För icke-PaaS-värdplattformar är säkerhet avgörande eftersom API:et exponeras offentligt. Det är viktigt att se till att slutpunkten inte utnyttjas eller komprometteras, vilket kan äventyra hela systemet. Inkludera den här slutpunkten som en del av din rutinmässiga säkerhetstestning tillsammans med andra offentliga slutpunkter. Överväg att utföra tester, till exempel intrångstestning, i det aktiva systemet. En annan aspekt av säkerheten är innehållssäkerhet. Din kod kan anropa specialiserade API:er som identifierar skadligt innehåll i nyttolasten för begäran och svar. Azure AI Content Safety kan anropas från din testning för att underlätta innehållssäkerhetstestning.
Viktiga strategier finns i Rekommendationer för säkerhetstestning.
Testöverväganden för Slutpunkter för PaaS-slutsatsdragning
Klienten bör förvänta sig fel när den skickar begäranden till slutpunkten för slutsatsdragning i PaaS-tjänsten. Fel kan inträffa på grund av systemöverbelastning, svarslösa serverdelar och andra feltillstånd. Utför fellägesanalys på tjänsten och testa de potentiella felen. Analys av felläge krävs för att utforma och implementera åtgärdsstrategier i klientkoden. Azure OpenAI-API:er begränsar till exempel begäranden genom att returnera en HTTP 429-felsvarskod. Klienten ska hantera det felet med hjälp av återförsöksmekanismer och kretsbrytare. Mer information finns i Rekommendationer för analys av felläge.
Genom att testa PaaS-tjänster kan du välja tjänst-SKU:er eftersom du förstår de associerade kostnaderna, till exempel betala per användning eller företablerad beräkning. Använd Priskalkylatorer för Azure för att utvärdera arbetsbelastningar, frekvens och tokenanvändning för att fastställa de bästa fakturerings- och beräkningsalternativen. Simulera arbetsbelastningar med lågkostnads-SKU:er och justera avancerade alternativ som etablerade dataflödesenheter (PTUs) för Azure OpenAI.
Belastningstestning är inte lika relevant för användningsbaserad beräkning eftersom du med oändlig kapacitet inte stöter på problem. Testning validerar gränserna och kvoterna. Vi rekommenderar inte belastningstestning för användningsbaserad beräkning eftersom det är en betydande ekonomisk kostnad. Du bör dock läsa in test för att verifiera dataflödet, som mäts i token per minut eller begäranden per minut. Till skillnad från standard-API:er som tar hänsyn till mått som begärandestorlek utvärderar den här metoden arbetsbelastningar baserat på token för att fastställa användning. Nyckeln är att förstå antalet aktiva användare och mäta dataflödet i enlighet med detta. Mer information finns i Mäta ditt dataflöde.
Använda säkerhetskontroller
Oavsett om du använder en slutsatsdragningsserver eller ett PaaS-alternativ är säkerheten ditt ansvar. Med API-slutpunkter är det viktigt att testa säkerhetskontroller för jailbreaking och innehåll. Kontrollera att dessa kontroller inte kan kringgås och fungerar som förväntat. Om du till exempel skickar ett känt blockerat objekt kan du kontrollera om säkerhetskontrollerna är på plats och fungerar korrekt före distributionen. Överväg att köra dessa tester efter behov eller integrera dem i lanseringsprocessen.
Det är viktigt att testa om systemet oavsiktligt kan exponera information som det inte ska. Systemet bör till exempel inte exponera personlig information i svarsnyttolasten. Testa också för att se till att en klient inte kan komma åt slutpunkter som är avsedda för andra identiteter. Utför säkerhetstester för att kontrollera att API:et, med dess autentiserings- och auktoriseringsmekanismer, inte läcker konfidentiell information och upprätthåller rätt användarsegmentering.
Testa jordningsdata
Datadesign påverkar en generativ modells effektivitet och grunddata är den kritiska komponenten. Grunddata ger mer kontext för att öka svarets relevans. Den indexeras innan den når modellen. Det här indexet nås i realtid när användaren väntar på ett svar.
Utför testning från slutpunkt till slutpunkt och införliva den processen som en del av datadesignen. Implementera en testprocess som utvärderar och kvantifierar resultatet av kundens upplevelse baserat på modellens prestanda, orkestrering, index, förbearbetning och källdata. Övervaka och mäta kvalitetsmåtten iterativt. Här följer några överväganden:
Testa databearbetningen noggrant med hjälp av funktions- och integreringstestning. Kontrollera att data läses in som förväntat och att alla data finns.
Testa indexschemat för bakåtkompatibilitet. Du bör testa alla ändringar i ett dokument eller fält för att säkerställa att den nya versionen fortfarande kan hantera tidigare versioner av data.
Innan data indexeras förbereds de för att minska brus och bias och möjliggöra effektiv frågekörning. Den här processen omfattar förbearbetning, segmentering och beräkning av inbäddningar, och varje steg sparar data i kontexten eller filerna i indexet. En orkestreringspipeline, till exempel kunskapsuppsättningar som tillhandahålls av Azure AI Search, utför dessa steg. Du måste testa orkestreringskoden för att säkerställa att inga steg missas och att bearbetade data håller hög kvalitet.
Tester bör söka efter gamla data, syntetiska värden, tomma tabeller, datauppdatering och bearbetning av den senaste versionen. Om testfel inträffar kan du behöva justera sökfrågan och indexet. Den här processen omfattar justering av filter och andra element som diskuterats tidigare. Du bör tänka på testning som en iterativ aktivitet.
Index är komplexa och frågeprestanda kan variera beroende på indexstruktur, vilket kräver belastningsuppskattning. Korrekt belastningstestning kan hjälpa dig att fastställa de olika SKU:erna för lagring, beräkning och andra resurser som är tillgängliga för att stödja dina krav.
Du måste testa alla säkerhetskontroller. Data kan till exempel partitioneras i separata dokument. Varje partition har åtkomstkontroller. Du måste testa kontrollerna korrekt för att skydda konfidentialiteten.
Testa orkestratorn
En viktig komponent i ett RAG-program är den centrala orkestratorn. Den här koden samordnar olika uppgifter som relaterar till den första användarfrågan. Orchestrator-uppgifter kräver vanligtvis en förståelse av användarens avsikt, en anslutning till indexet för att leta upp grunddata och anropa slutpunkten för slutsatsdragning. Om agenter behöver utföra uppgifter, till exempel att anropa REST-API:er, hanterar den här koden dessa uppgifter i kontexten.
Du kan utveckla orkestreringskod på valfritt språk eller skriva den från grunden. Vi rekommenderar dock att du använder tekniker som promptflöde i Azure AI Studio eller Apache Airflows riktade Acyclic Graphs (DAG) för att påskynda och förenkla utvecklingsprocessen. Prompt flow ger en designtidsupplevelse. Använd den för att modularisera uppgifter som enheter och ansluta indata och utdata för varje enhet, vilket i slutändan utgör orkestreringskoden, som representerar hela processen.
Isolera orkestreringskoden. Utveckla den separat och distribuera den som en mikrotjänst med en onlineslutpunkt och REST-API för åtkomst. Den här metoden säkerställer modularitet och enkel distribution.
Ur ett testperspektiv behandlar du den här koden som andra kod- och enhetstester. Den viktigaste aspekten är dock dess funktioner, till exempel routningslogik, som du kan verifiera genom funktions- och integreringstestning. Testpromptteknik för att säkerställa att koden kan identifiera användar avsikt och dirigera anrop på rätt sätt. Det finns flera ramverk och bibliotek för testning, till exempel Scikit-learn, PyTorchs torch.testing-modul, FairML för bias- och rättvisetestning och TensorFlow Model Analysis för modellutvärdering.
Utför även körningstester, till exempel testning av felläge. Testa till exempel potentiella fel som är relaterade till tokenbegränsningar.
Vissa körningstester kan hjälpa dig att fatta ett beslut. Kör belastningstester för att förstå hur den här koden beter sig under stress och använda resultaten för kapacitetsplanering. Eftersom den här koden är placerad vid en avgörande punkt i arkitekturen där den behöver nå andra tjänster, kan den hjälpa till att samla in telemetri från alla dessa anrop. Dessa data kan ge insikter om hur mycket tid som läggs på lokal bearbetning jämfört med nätverksanrop och fastställa beteendet för andra komponenter, till exempel potentiell svarstid. Tekniker som promptflöde har inbyggda telemetrifunktioner för att underlätta den här processen. Annars kan du införliva telemetri i din anpassade kod.
Kommentar
Att testa den här koden har kostnadskonsekvenser. Om du till exempel använder Azure OpenAI som värd för slutpunkten för slutsatsdragning är stresstestning en vanlig metod som kan hjälpa dig att fastställa systemets gränser. Azure OpenAI debiterar dock för varje anrop, vilket kan göra omfattande stresstester dyra. Ett sätt att optimera avgifter är att använda oanvända PTUs för Azure OpenAI i en testmiljö. Du kan också simulera slutpunkten för slutsatsdragning.
Säkerhetsproblem gäller både orkestreringskoden och modellen. Inkludera testning för jailbreaking, där målet är att bryta modellens säkerhet. Angripare interagerar inte direkt med modellen. De interagerar först med orkestreringskoden. Orkestreringskoden tar emot användarbegäranden och parsar dem. Om orkestreringskoden tar emot en skadlig begäran kan den vidarebefordra begäran till modellen och eventuellt kompromettera modellen.
Innehållssäkerhet är en annan viktig aspekt. I ett chattrobotprogram tar orkestreringskoden emot chatttext. I koden bör du överväga att anropa en tjänst för innehållssäkerhet. Skicka både användarprompten och grundkontexten för analys och ta emot en bedömning av risken. Prompt Shields är ett enhetligt API som analyserar indata från stora språkmodeller och identifierar användarpromptattacker och dokumentattacker, som är två vanliga typer av indata från angripare.
Säkerhetskontroll och autentisering är avgörande för en RESTful-slutpunkt. Du måste hantera autentisering och säkerställa noggrann testning.
Förhindra modellförfall
Ett vanligt problem för alla modeller är en viss grad av försämring över tid. Ändringar som är interna och externa för arbetsbelastningen orsakar så småningom en försämring av modellens kvalitet och dess utdata. Modellförfall sker på två sätt:
Dataavvikelse inträffar när indata ändras. Nya dataindata gör den tränade modellen inaktuell. Du kan till exempel ha en modell som förutsäger röstningsmönster för ett visst geografiskt område, till exempel ett distrikt. Om distriktet ritas om och befolkningsdemografin för distriktet ändras måste din modell uppdateras för att ta hänsyn till ändringarna.
Konceptavvikelse inträffar när villkor som är externa för arbetsbelastningen och modellen ändras på ett sådant sätt att modellens utdata inte längre matchar verkligheten. Du kan till exempel ha en försäljningsprognosmodell för en teknikprodukt. Om en konkurrent oväntat introducerar en mer avancerad konkurrerande produkt som drar stor uppmärksamhet från allmänheten måste du uppdatera din modell baserat på hur konsumenttrender förändras.
När det är möjligt kan du använda automatiserad testning för att identifiera och utvärdera modellförfall under modellens livscykel. Om din modell förutsäger diskreta värden kan du skapa tester för att utvärdera förutsägelser mot dessa värden över tid och mäta avvikelsen mellan förväntade och faktiska resultat. Komplettera den här testningen med övervakning för att identifiera drift över tid genom att jämföra sammanfattningsstatistik och avståndsmått.
En annan vanlig metod för att identifiera modellförfall är användarfeedback. Ett exempel på användarfeedback är en svarsmekanism med tummen upp eller tummen ned. Att spåra positiv eller negativ feedback över tid och skapa en avisering när du uppfyller ett tröskelvärde för negativ feedback kan hjälpa dig att veta när du ska undersöka modellens kvalitet.
Oavsett vilka signaler du använder för att identifiera modellförfall måste driftteamet som varnas om potentiellt förfall engagera en dataforskare för att undersöka signalen och avgöra om förfall sker och grundorsaken.
Implementera verktyg
Använd Azure Machine Learning-datainsamlaren för att få realtidsloggning av indata och utdata från modeller som distribueras till hanterade onlineslutpunkter eller Kubernetes onlineslutpunkter. Machine Learning lagrar loggade slutsatsdragningsdata i Azure Blob Storage. Du kan sedan använda dessa data för modellövervakning, felsökning eller granskning, vilket ger observerbarhet i prestanda för dina distribuerade modeller. Om du distribuerar en modell utanför Machine Learning eller till en Machine Learning-batchslutpunkt kan du inte dra nytta av datainsamlaren och behöver operationalisera en annan datainsamlingsprocess.
Använd maskininlärningsmodellövervakning för att implementera övervakning. Machine Learning hämtar övervakningssignaler genom att utföra statistiska beräkningar på strömmade produktionsinferensdata och referensdata. Referensdata kan vara historiska träningsdata, valideringsdata eller mark sanningsdata. Å andra sidan refererar produktionsinferensdata till modellens indata och utdata som samlas in i produktionen.
- Se Maskininlärningsmodellövervakning för att lära dig mer om övervakningsfunktionerna i Machine Learning och de mått som den samlar in och analyserar.
- Mer rekommendationer för övervakning finns i metodtipsen.