Delen via


AI-workloads testen en evalueren in Azure

Het doel van het testen in AI-workloads is om kwaliteit te garanderen wanneer een wijziging in het systeem wordt geïntroduceerd. Testen kan valideren of de workload voldoet aan geïdentificeerde doelen en voldoet aan de verwachtingen van de gebruiker. Het voorkomt ook kwaliteitsregressies. Dit proces omvat het uitvoeren van tests op verschillende functionele gebieden en het beoordelen van de kwaliteit van functionaliteit, belastingafhandeling, voorspelbaarheid en andere criteria op basis van workloadvereisten.

Testresultaten bieden kritieke gegevenspunten voor beslissingen zoals of AI-onderdelen gereed zijn voor release en welke SKU's of functies geschikt zijn. Daarnaast kan het testen fungeren als een meldingssysteem voor fouten en helpen bij het detecteren van problemen in de productie door middel van routine- of synthetische tests.

Het Azure Well-Architected Framework bevat een uitgebreide testmethode. U moet verschillende soorten tests gebruiken in verschillende fasen van de ontwikkelingslevenscyclus en in verschillende systeemonderdelen en stromen. Zonder deze tests kunnen uitgerolde wijzigingen de systeemkwaliteit verminderen. Kleine codefouten kunnen bijvoorbeeld grote systeemfouten worden. Systeemgedrag kan onvoorspelbaar worden of leiden tot vooroordelen vanwege de niet-deterministische aard van AI-systemen. Resourcetoewijzing kan ook inefficiënt zijn en echte gebruikersgegevens of systeemresources kunnen worden misbruikt omdat deze systemen kwetsbaar zijn voor misbruik.

U moet workloadassets ontwerpen en ontwikkelen met het oog op testen. Wanneer u bijvoorbeeld gegevensbewerkingen uitvoert en brongegevens hervormt voor functie-engineering, moet u zich houden aan goede coderingsprocedures en ervoor zorgen dat u de code structureert ter ondersteuning van tests. Deze strategie omvat het ontwerpen van de code om effectieve eenheidstests te vergemakkelijken en de tests te isoleren van de functionaliteit van de code en de bijbehorende afhankelijkheden. In dit voorbeeld moet u een systeem ontwerpen dat kan worden uitgevoerd in een testomgeving met voldoende representatieve testgegevens in termen van volume en gelijkenis.

U moet workloadonderdelen veilig implementeren in productie. Een deel van de veilige implementatieprocedures van een workload is strategische tests om ervoor te zorgen dat het juiste gedrag wordt gegarandeerd voordat gebruikers of gegevens het systeem verbruiken. Strategische tests zijn essentieel tijdens de eerste implementatie en naarmate het systeem zich ontwikkelt en code of infrastructuurwijzigingen ondergaat. Test alle voorgestelde wijzigingen in AI-gerelateerde code en infrastructuur voordat u de wijzigingen in de productie implementeert.

Dit artikel richt zich op het toepassen van die methodologie op de AI-aspecten van de architectuur. Hoe u deze tests uitvoert, valt niet binnen het bereik.

Aanbevelingen

Hier volgt een samenvatting van de aanbevelingen in dit artikel.

Aanbeveling Beschrijving
Definieer metrische succesgegevens voor uw teststrategie. Net als bij elk ander type workloadtests moet u de juiste metrische gegevens voor een bepaalde test vastleggen en analyseren om ervoor te zorgen dat uw test nuttige inzichten biedt over uw AI-workload.

Metrische succesgegevens definiëren
Voer end-to-end tests uit voor uw gegevensopname en -verwerking van pijplijnen gedurende de levenscyclus van de ontwikkeling. Tests kunnen de gegevens valideren en u helpen ervoor te zorgen dat het proces voor gegevensmanipulatie naar behoren werkt. Neem vroeg in de ontwerpfase tests op om ervoor te zorgen dat gegevenskwaliteit en de juiste technologie en groottekeuzen worden gegarandeerd. Ontwikkel eenheidstests voor aangepaste code tijdens de ontwikkeling en voer realtime productietests uit om problemen te ondervangen en functionaliteit te valideren.

Gegevensopname testen
Voer tests uit voor trainingstaken om ervoor te zorgen dat de scripts worden aangeroepen en werken zoals verwacht. Belasting- en prestatietests kunnen inzicht bieden in de keuze en grootte van de berekening die geschikt is om de taken uit te voeren. Eenheidstests kunnen het hulpprogramma van de code valideren en regressies vangen wanneer afhankelijkheden worden bijgewerkt.

De trainingswerkstroom testen
Evalueer en test het model om duplicatie in trainings-, evaluatie- en testgegevens te voorkomen. Om ervoor te zorgen dat brongegevens niet volledig worden gebruikt voor training, moet u unieke gegevens reserveren voor modelevaluatie en definitieve tests. Deze subsets worden niet opgenomen in het daadwerkelijke trainingsproces.

Het model evalueren en testen
Test het deductie-eindpunt. Voer belastingstests uit op het eindpunt dat door de deductieserver wordt gehost en kies GPU-SKU's op basis van deze testresultaten. Voor paaS-eindpunten (Platform as a Service) die worden gehost, test u de doorvoer en de mogelijke fouten. Deze eindpunten zijn bereikbaar, dus voer de juiste beveiligingstests uit om jailbreakingsituaties te voorkomen.

Het deductie-eindpunt testen
Test de juistheid van het indexontwerp zodat query's relevante resultaten opleveren. Functionele en integratietests helpen u ervoor te zorgen dat gegevens nauwkeurig zijn en dat het testen van indexschema's controleert op compatibiliteit met eerdere versies. U moet voorverwerkingsstappen testen voor kwaliteit. Belastingstests bepalen geschikte SKU's voor resources en beveiligingsmaatregelen beschermen de vertrouwelijkheid van gegevens.

De grondgegevens testen
Test de orchestrator om de functionaliteit en beveiliging te valideren. Voer eenheids-, functionele, integratie- en runtimetests uit, waaronder belasting- en foutmodustests, om prestaties en betrouwbaarheid te garanderen. Beveiligings- en inhoudsveiligheidstests zijn ook van cruciaal belang om het systeem en de gegevens te beschermen.

De orchestrator testen
Test op modelverval. Modelverval is een onvermijdelijk probleem dat van invloed is op de meeste AI-workloads. Door te testen op gegevens- en conceptdrift kunt u modelverval vroegtijdig ondervangen en het probleem beperken voordat dit de workload nadelig beïnvloedt.

Modelverval voorkomen

Metrische succesgegevens definiëren

U wordt aangeraden een basislijn te hebben en de voorspellende kracht van het model te meten met behulp van goed gedefinieerde metrische gegevens. Hier volgen enkele algemene metrische gegevens.

  • Nauwkeurigheid vertegenwoordigt de verhouding van correct voorspelde exemplaren tot de totale exemplaren in de testgegevensset. Dit is een algemene meting van de algehele modelprestaties.

  • Precisie is de verhouding van terecht-positieve voorspellingen tot de som van terecht-positieven en fout-positieven. Het is handig bij het minimaliseren van fout-positieven is bijvoorbeeld belangrijk, zoals in medische diagnoses.

  • Gevoeligheid meet de verhouding van terecht-positieven tot de som van terecht-positieven en fout-negatieven. Het is waardevol wanneer u fout-negatieven vermijdt of relevante gevallen mist, is essentieel.

  • Specificiteit berekent de verhouding van terecht-negatieven tot de som van terecht-negatieven en fout-positieven. Dit is relevant wanneer u optimaliseert voor nauwkeurige negatieve voorspellingen.

Notitie

Wanneer u metrische succesgegevens voor regressiemodellen definieert, kunt u overwegen de volgende metrische gegevens toe te voegen:

  • Gemiddelde absolute fout (MAE) meet het gemiddelde absolute verschil tussen de voorspelde waarden en de werkelijke waarden. Bereken deze door het gemiddelde van de absolute verschillen tussen elke werkelijke waarde en de bijbehorende voorspelde waarde te nemen. MAE is minder gevoelig voor uitbijters vergeleken met MSE en RMSE.

  • Gemiddelde kwadratische fout (MSE) meet het gemiddelde kwadratische verschil tussen de werkelijke waarden en de voorspelde waarden. Bereken deze door het gemiddelde van de kwadratische verschillen tussen elke werkelijke waarde en de bijbehorende voorspelde waarde te berekenen. MSE bestraft grotere fouten zwaarder dan MAE, omdat de fouten kwadrateren.

  • Root Mean Squared Error (RMSE) is de vierkantswortel van de MSE. Het biedt een meting van de gemiddelde absolute fout tussen de werkelijke en voorspelde waarden, maar in dezelfde eenheden als de oorspronkelijke gegevens. RMSE is gevoeliger voor uitbijters vergeleken met MAE, omdat het de fouten kwadrateert voor het gemiddelde.

Gegevensopname testen

Gegevenspijplijnen, zoals ETL-processen (extraheren, transformeren en laden), verplaatsen en manipuleren. Test het ETL-gedeelte van de workload om ervoor te zorgen dat gegevens betrouwbaar worden opgenomen en dat de gegevens van hoge kwaliteit en acceptabel zijn voor analyse- en functie-engineering. Zorg ervoor dat het opschonen en verwerken van gegevens tests bevat om te bevestigen dat gegevensmanipulatie naar behoren functioneert.

Testen moeten gedurende de hele levenscyclus worden geïntegreerd, met inbegrip van de ontwerp-, ontwikkelings- en productiefasen.

Testen om ontwerpkeuzen te vergemakkelijken

Wanneer u vereisten voor de workload verzamelt, is het kiezen van een specifieke technologieoptie die geschikt is voor uw ontwerp.

Voer op basis van uw ETL-vereisten en acceptatiecriteria verkennende functionele tests uit om het meest geschikte product, de SKU's en functies te selecteren die de beoogde taken uitvoeren. Proof of concept, proof of technology en proof of capabilities tests zijn essentieel om te evalueren of u de juiste technologie kiest en of deze de juiste grootte heeft.

Voor scenario's waarin u AI in een bestaande architectuur opneemt, test u hoe goed de nieuwe technologie kan worden geïntegreerd met het huidige systeem.

De eerste workloadvereisten kunnen veranderen. Stel dat het bedrijf de groei verwacht en dat het systeem dubbele gebruikersquery's moet verwerken. Voor deze verwachting is de juiste capaciteitsplanning vereist. We raden u aan proactieve tests uit te voeren om te begrijpen hoe het systeem reageert op de extra gegevens en om gegevensgestuurde aanpassingen aan te brengen in bestaande grootten of om nieuwe productkeuzen te maken. Voor capaciteitstests raden we u aan om functionele tests te combineren met belasting- en prestatietests en synthetische stoffen te gebruiken om realistische omstandigheden te simuleren.

Testen om codekwaliteit te garanderen

Wanneer code is opgenomen, moet u ervoor zorgen dat deze eenheidstests doorloopt en niet wordt vrijgegeven als deze mislukt. Het is bijvoorbeeld gebruikelijk om aangepaste code te hebben die wordt uitgevoerd als onderdeel van opname. Er wordt ook code gebruikt voor het opschonen en verwerken van gegevens. Voer eenheidstests uit om ervoor te zorgen dat de code zich gedraagt volgens het ontwerp en dat gegevensmanipulatie naar verwachting functioneert.

Voer tests uit als onderdeel van uw continue integratie en continue leveringspijplijn.

Testen in het live systeem

Functionele tests moeten worden uitgebreid naar het livesysteem. Als deze tests mislukken, kunt u eventueel waarschuwingen activeren om onmiddellijk onderzoek te starten. Hieronder volgen een aantal voorbeelden:

  • Voer geplande tests uit om te controleren of het juiste gegevensvolume is verzameld als gegevens worden opgenomen volgens een ingestelde planning met een verwachte hoeveelheid.

  • Voer tests uit die problemen met gegevens detecteren, zoals ontbrekende waarden of dubbele gegevens, en eenvoudige controles voor gegevensintegriteit uitvoeren. Als gegevens tijdelijke informatie bevatten die de nieuwheid aangeeft, kunnen deze tests die informatie controleren en mogelijk voorkomen dat downstreamprocessen verouderde gegevens gebruiken.

  • Controleer de beschikbaarheid van externe afhankelijkheden. Een taak voor het opschonen van gegevens kan bijvoorbeeld een andere service aanroepen voor het extraheren van tabellen of voorverwerking. Voer tests uit om ervoor te zorgen dat ze beschikbaar zijn omdat hun onbeschikbaarheid van invloed kan zijn op het ETL-proces.

Een andere manier om de juistheid van het ETL-systeem in productie te testen, is door middel van synthetische tests. Het feit dat er bekende testgegevens beschikbaar zijn in productie, is zeer effectief. U kunt deze gebruiken om end-to-end verwerking te valideren door de bekende beginstatus te vergelijken met de verwachte eindstatus voor die gegevens. Een document is bijvoorbeeld vereist om documentinformatie te doorlopen en persoonlijke gegevens te bevatten. Het injecteren van een synthetisch document kan testen of de werkbelasting de taak voor gegevensbewerking uitvoert zoals bedoeld.

Experimenteer bovendien door verschillende ervaringen, ook wel bekend als A/B-tests, uit te brengen om te leren van gebruikersinteracties voordat ze volledig worden doorgevoerd. A/B-tests helpen u kwaliteitsregressies te voorkomen.

Gegevens testen die tijdens de opname worden verzameld

Neem als onderdeel van het opnameproces uit verschillende gegevensbronnen tests op om te valideren dat trainingsgegevens overeenkomen met uw verwachtingen.

Het trainen van een machine learning-model met onvolledige of beschadigde gegevens kan contraproductief zijn. Dit kan leiden tot verspilde inspanningen en resulteren in een model dat geen zinvolle voorspellingen kan doen. Uw pijplijnen voor gegevensopname en voorverwerking bevatten kwaliteitstests als controlepunten. Met deze tests kunt u controleren of uw gegevens overeenkomen met de verwachtingen die u hebt ingesteld tijdens gegevensanalyse en functie-engineering.

De volgende lijst bevat enkele voorbeeldtestcases:

  • Test op volledigheid. Test de verwachte hoeveelheid trainingsgegevens om de volledigheid van de gegevensset te controleren. Deze test zorgt ervoor dat u voldoende gegevens opgeeft om het model te trainen.

  • Test op kritieke informatie. Als de training is gebaseerd op bekende entiteiten, zoals specifieke records of id's, test u de gegevensset om ervoor te zorgen dat deze entiteiten aanwezig zijn. Deze validatie zorgt ervoor dat kritieke informatie niet ontbreekt.

  • Test op irrelevante gegevens. Opgenomen gegevens mogen geen irrelevante of onjuiste vermeldingen bevatten. Het gegevensopnameproces moet die gegevens eruit filteren.

  • Test op versheid. De versheid van de opgenomen gegevens mag geen invloed hebben op de voorspellende kracht van het model. Controleer of de gegevens redelijk actuele informatie weerspiegelen en niet verouderd zijn ten opzichte van eerdere uitvoeringen. Als u bijvoorbeeld verwacht dat de gegevens records uit de afgelopen week bevatten, maar er geen dergelijke records zijn nadat u de gegevens hebt geïmporteerd, kan dit duiden op een mislukte import of een probleem met het vernieuwen van gegevens in het bronsysteem.

Routinetests uitvoeren

Een belangrijk probleem met gegevensopname is het volume van gegevens en doorvoer. Continue evaluatie tijdens bewerkingen is nodig om knelpunten in de prestaties te voorkomen. Deze doorlopende evaluatie moet deel uitmaken van uw operationele processen in plaats van slechts een eenmalige test. Het doel is ervoor te zorgen dat het workloadteam de serviceniveaudoelstellingen niet mist.

Houd rekening met een situatie waarin bewaking aangeeft dat de prestaties afnemen. Als u dergelijke omstandigheden wilt beperken, evalueert en optimaliseert u de ETL-processen. Nadat u wijzigingen hebt aangebracht, kunnen prestatietests u helpen ervoor te zorgen dat de wijzigingen voldoen aan de vereiste doorvoer.

Notitie

Testen en bewaken dienen voor verschillende doeleinden. Voer tests uit om mogelijke wijzigingen in het systeem te evalueren, meestal voordat u wijzigingen implementeert. Voer continu bewaking uit om de algehele status van het systeem te beoordelen.

De trainingswerkstroom testen

Train een model met behulp van aangepaste code, zoals PyTorch-scripts, die het werkelijke trainingswerk uitvoeren. Deze scripts worden uitgevoerd op rekenkracht, zoals in notebooks of Azure Machine Learning-taken, waarvoor ook geheugen- en netwerkresources nodig zijn. We raden u aan belastingtests uit te voeren tijdens de ontwerpfase om de rekenbehoeften te evalueren en ervoor te zorgen dat de voorgestelde SKU's geschikt zijn. U hebt vaak handmatige tests nodig om de beste configuratie te bepalen om de workload efficiënt uit te voeren binnen de tijdslimiet.

Schrijf de scripts met behulp van gespecialiseerde SDK's, die de meeste taken verwerken. Omdat scripts echter nog steeds code zijn, moet u eenheidstests integreren als onderdeel van de ontwikkeling. Deze tests helpen u ervoor te zorgen dat er geen regressies optreden wanneer u afhankelijkheden bijwerkt. Als eenheidstests niet mogelijk zijn, is handmatig testen nodig voordat u nieuwe code implementeert om kwaliteitsregressies te voorkomen.

Deze scripts worden uitgevoerd als onderdeel van een werkstroom, zoals Azure Machine Learning-studio, die inzicht kunnen geven in wanneer en of het script is uitgevoerd. U wordt echter aangeraden integratietests uit te voeren om ervoor te zorgen dat deze scripts betrouwbaar worden aangeroepen.

Het model evalueren en testen

Notitie

Modelevaluatie en -tests worden vaak door elkaar gebruikt, maar ze moeten worden beschouwd als afzonderlijke processen die gebruikmaken van afzonderlijke gegevenssets. Evaluatie is een iteratieve activiteit die u tijdens de ontwikkelingsfase uitvoert. Het richt zich op experimenten om het beste model te vinden met het juiste afstemmingsniveau. Het omvat het aanpassen van hyperparameters, configuraties of functies en vervolgens het evalueren van het model op basis van verschillende metrische gegevens. Nadat u het beste model hebt geïdentificeerd, voert u tests uit tijdens de implementatie.

Testen omvat het controleren van het hele systeem, inclusief het afgestemde model en niet-AI-onderdelen, om te controleren of ze correct werken, goed te integreren en de verwachte resultaten te leveren in overeenstemming met de kwaliteitsnormen. Evalueer een model in situ naast andere onderdelen van de workload. Het proces omvat het verzenden van aanvragen naar het model, het evalueren van de antwoorden en het maken van een go- of no-go-beslissing op basis van de testgegevens. Hoewel het testen niet kan worden uitgevoerd vóór de productie, raden we u aan ook tests in productie uit te voeren met behulp van echte gegevens en synthetische gegevens.

Gegevens gebruiken om te evalueren en testen

Doorgaans zijn er drie belangrijke gegevenssets gepartitioneerd op basis van de brongegevens: training, evaluatie en testen.

Gebruik de trainingsgegevensset, die meestal de grootste subset is, om het model te trainen. Gebruik een andere gegevensset voor evaluatie om het model te verfijnen via een iteratief proces door verschillende permutaties te beoordelen. Nadat u een bevredigende permutatie hebt gevonden, test u deze op basis van de testgegevensset.

Alle gegevenssets moeten gegevens van hoge kwaliteit bevatten om ruis te minimaliseren. Uw testcases voor gegevensopname en voorverwerking van pijplijnen kunnen fungeren als controlepunten voor kwaliteit. Een gebrek aan voorbeelden kan ook worden gebruikt voor gegevens van lage kwaliteit. Gebruik synthetische gegevens om uniformiteit in de gegevensset te verdelen en te bereiken. Deze aanpak is handig voor het trainen van modellen zoals fraudedetectiemodellen, waarbij echte fraudeexemplaren zeldzaam zijn, waardoor het moeilijk is om voldoende statistische kracht te krijgen voor betrouwbare voorspellingen.

Als u vooroordelen in voorspellingen wilt voorkomen, houdt u alle gegevenssets uniek. U moet geen trainingsgegevens gebruiken voor evaluatie en u mag geen evaluatiegegevens gebruiken om te testen. Reserveer unieke gegevens voor modelevaluatie en definitieve tests.

Metrische evaluatiegegevens gebruiken

Het trainen van een model en het selecteren van de juiste model voor productie zijn onderling afhankelijke processen. U moet eerst een model kiezen, maar dit kan veranderen na experimenten en evaluatie.

Modelevaluatie volgt als een experimentenlus die talloze permutaties van modellen, parameters en functies evalueert met behulp van metrische gegevens. Deze metrische gegevens bieden wetenschappelijke classificaties, die u iteratief moet vergelijken met verschillende versies en configuraties om het beste model te bepalen. Zie Metrische evaluatiegegevens voor meer informatie.

Een vergelijkbare benadering is van toepassing op generatieve AI-modellen. Processen hebben die de resultaten van de gebruikerservaring evalueren en kwantificeren op basis van de prestaties van het model. Geaardheid is bijvoorbeeld een van de belangrijkste metrische gegevens die kwantificeren hoe goed het model overeenkomt met brongegevens. Relevantie is een andere belangrijke metriek die aangeeft hoe relevant het antwoord is voor de query. Zie Bijvoorbeeld metrische gegevens evaluatie en bewaking van metrische gegevens voor generatieve AI.

Evalueer verschillende typen modellen met behulp van verschillende metrische gegevens. Het belang van elke metriek kan variëren, afhankelijk van het scenario. Prioriteit geven aan metrische gegevens op basis van de use-case. Fairness is bijvoorbeeld cruciaal in verantwoorde AI. Ondanks goede tests kunnen modellen nog steeds oneerlijke vooroordelen vertonen vanwege bevooroordeerde brongegevens. Resultaten kunnen hoog scoren op relevantie, maar laag in redelijkheid. Integreer fairness-evaluaties in het proces om onbevoorhaamde resultaten te garanderen.

Generation AI integreert met indelingscode, routeringslogica en een index voor het ophalen van augmented generation (RAG), wat de evaluatie bemoeilijkt. Hoewel u de modellen afzonderlijk moet evalueren met behulp van metrische gegevens, is het ook belangrijk om andere systeemonderdelen te evalueren.

Het model testen

Fijnafstemming is in wezen testen omdat het een vooraf getraind model wijzigt om het gedrag ervan te wijzigen. Hiervoor moet u beginnen met een basislijn om inzicht te hebben in de initiële prestaties van het model. Na het afstemmen kunt u de prestaties van het model opnieuw evalueren om ervoor te zorgen dat het voldoet aan de kwaliteitsnormen. Bekijk de volgende algemene metrische evaluatiegegevens:

  • Geaardheid verwijst naar de uitlijning van het model met de brongegevens. Een geaard model genereert antwoorden die consistent zijn met de realiteit.

  • Relevantie geeft aan hoe relevant het antwoord is voor een bepaalde vraag. Een zeer geaard antwoord kan een gebrek aan relevantie hebben als de vraag niet rechtstreeks wordt beantwoord.

  • Overeenkomst meet de gelijkenis tussen een brongegevenstekst en het gegenereerde antwoord. Heeft het model nauwkeurige formulering gebruikt? Een gebrek aan redactionele governance kan de gelijkenisscore verlagen.

  • Ophalen geeft de effectiviteit van indexquery's aan. Evalueer hoe goed de opgehaalde indexgegevens overeenkomen met de vraag. Irrelevante gegevens uit de indexzoekopdracht verlagen deze score. Hogere scores voor het ophalen geven een lagere variabiliteit aan, omdat ze alleen afhankelijk zijn van de indexquery's.

  • Fluency heeft betrekking op het vocabulaire gebruik. Als het model voldoet aan een stijlgids en inhoud in de juiste indeling presenteert, kan het vloeiend zijn, zelfs als er geen grond of relevantie is.

  • Coherentie evalueert of de spraakstromen van het model op natuurlijke en coherente wijze stromen. Het beoordeelt of het gesprek een echte uitwisseling voelt.

Hyperparameters testen

Modelparameters zijn afhankelijk van toepassingsspecifieke ontwerpbeslissingen. Als onderdeel van uw toepassingsontwerp kiest u het model en de parameters op basis van de use cases van uw workload. Het testproces heeft een iteratieve binnenste lus waarbij trainingsgegevens worden vergeleken met testgegevens om te controleren of het model wordt getraind op de beoogde gegevensset. Ook worden de parameters afgestemd, zodat het model voorspellingen kan doen met een acceptabel nauwkeurigheidsniveau.

Compromis. De binnenste lus omvat rekenkosten voor het trainen van het model en de kosten voor het evalueren ervan via tests. U moet rekening houden met de tijd die nodig is voor het trainen en testen van modellen in deze lus. Verwacht dat het testproces langer duurt dan het trainingsproces. U kunt initiële tests uitvoeren op een subset van trainingsgegevens om te beoordelen of het model redelijke resultaten oplevert. U kunt die testset geleidelijk omhoog schalen naar de volledige gegevensset.

Het deductie-eindpunt testen

Een deductie-eindpunt is de REST API die toegang biedt tot modellen voor het maken van voorspellingen. Dit is de interface waar u gegevens verzendt als onderdeel van de aanvraag en een antwoord krijgt dat resultaten van het model bevat. Het eindpunt wordt gehost op compute, wat PaaS kan zijn, zoals Azure OpenAI-service of een niet-Microsoft-deductieserver, zoals NVIDIA Triton Inference Server, TorchServe en BentoML. In PaaS-scenario's verwerkt de serviceprovider de tests in bepaalde mate. Als u het eindpunt echter host, behandelt u het als een andere API en test u het grondig.

Hoewel u het model test tijdens de training en evaluatie, moet u het deductie-eindpunt testen om ervoor te zorgen dat de mechanismen rond dat model, zoals het verwerken van aanvragen, het maken van antwoorden, schalen en coördinatie tussen exemplaren, correct werken. Maak een uitgebreid testplan waarin gebruiksvoorbeelden worden behandeld op basis van uw vereisten. In deze sectie worden enkele voorbeeldtestcases en testtypen beschreven die u kunt overwegen.

Testoverwegingen voor deductiehostingservers

Het is belangrijk om inzicht te hebben in de belastingskenmerken van de berekening en de prestaties te valideren via belastingstests. Met deze acties kunt u technologieën kiezen wanneer u de architectuur ontwerpt of optimaliseert. Verschillende deductieservers hebben bijvoorbeeld verschillende prestatiekenmerken. De code verbruikt CPU-cycli en geheugen naarmate het aantal gelijktijdige verbindingen toeneemt. Meer informatie over hoe uw code en de rekenresources presteren onder standaard- en piekbelastingsomstandigheden. Azure Load Testing is een goede optie voor belastingstests en kan een hoge volumebelasting genereren. Andere opensource-opties, zoals Apache JMeter, zijn ook populair. Overweeg deze tests rechtstreeks vanuit uw omgeving aan te roepen. Machine Learning kan bijvoorbeeld goed worden geïntegreerd met Load Testing.

Een andere belangrijke beslissing is de keuze van GPU-mogelijkheden. Veel modellen vereisen GPU's voor effectieve deductie vanwege hun ontwerp. Belastingstests helpen u inzicht te krijgen in de prestatielimieten van een GPU-SKU en voorkomt overprovisioning, wat aanzienlijke financiële overwegingen zijn.

Compromis. GPU-SKU's zijn duur. Hoewel u conservatieve keuzes kunt maken in uw SKU-selectie, is het belangrijk om continu te controleren of GPU-resources te weinig worden gebruikt en waar mogelijk rechten hebben. Nadat u aanpassingen hebt aangebracht, test u het resourcegebruik om de balans te behouden tussen kostenefficiëntie en prestatieoptimalisatie. Zie Aanbevelingen voor het optimaliseren van onderdeelkosten voor strategieën voor kostenoptimalisatie.

Voor niet-PaaS-hostingplatforms is beveiliging cruciaal omdat de API openbaar wordt weergegeven. Het is belangrijk om ervoor te zorgen dat het eindpunt niet wordt misbruikt of aangetast, waardoor het hele systeem in gevaar kan worden gebracht. Neem dit eindpunt op als onderdeel van uw routinebeveiligingstests, samen met andere openbare eindpunten. Overweeg om tests, zoals penetratietests, uit te voeren op het live systeem. Een ander aspect van beveiliging is inhoudsveiligheid. Uw code kan worden aangeroepen bij gespecialiseerde API's die schadelijke inhoud in de nettolading van de aanvraag en het antwoord detecteren. Azure AI Content Safety kan worden aangeroepen vanuit uw test om de veiligheid van inhoud te vergemakkelijken.

Zie Aanbevelingen voor beveiligingstests voor belangrijke strategieën.

Testoverwegingen voor PaaS-deductie-eindpunten

De client moet fouten verwachten wanneer er aanvragen worden verzonden naar het deductie-eindpunt op de PaaS-service. Fouten kunnen optreden vanwege systeemoverbelasting, niet-reagerende back-ends en andere foutvoorwaarden. Voer analyse van de foutmodus uit op de service en test deze mogelijke fouten. Analyse van foutmodus is vereist voor het ontwerpen en implementeren van risicobeperkingsstrategieën in de clientcode. Zo beperken Azure OpenAI-API's aanvragen door een HTTP 429-foutcode te retourneren. De client moet deze fout afhandelen met behulp van mechanismen voor opnieuw proberen en circuitonderbrekers. Zie Aanbevelingen voor het uitvoeren van analyse van de foutmodus voor meer informatie.

Het testen van PaaS-services kan u helpen bij het selecteren van service-SKU's, omdat u de bijbehorende kosten begrijpt, zoals betalen per gebruik of vooraf ingerichte berekeningen. Gebruik Azure-prijscalculators om workloads, frequentie en tokengebruik te evalueren om de beste facturerings- en rekenopties te bepalen. Simuleer workloads met goedkope SKU's en rechtvaardig geavanceerde opties, zoals ingerichte doorvoereenheden (PTU's) voor Azure OpenAI.

Belastingstests zijn niet zo relevant voor betalen per gebruik-rekenproces, omdat u met oneindige capaciteit geen problemen ondervindt. Testen valideert de limieten en quota. Het wordt afgeraden belastingstests voor betalen per gebruik-rekenproces te testen, omdat dit een aanzienlijke financiële kosten is. U moet echter een belastingtest uitvoeren om de doorvoer te controleren, die wordt gemeten in tokens per minuut of aanvragen per minuut. In tegenstelling tot standaard-API's die rekening houden met metrische gegevens, zoals de aanvraaggrootte, evalueert deze benadering workloads op basis van tokens om het gebruik te bepalen. De sleutel is om het aantal actieve gebruikers te begrijpen en de doorvoer dienovereenkomstig te meten. Zie Uw doorvoer meten voor meer informatie.

Beveiligingscontroles gebruiken

Ongeacht of u een deductieserver of een PaaS-optie gebruikt, is beveiliging uw verantwoordelijkheid. Met API-eindpunten is het van cruciaal belang om te testen op jailbreaking en beveiliging van inhoud. Zorg ervoor dat deze besturingselementen niet kunnen worden overgeslagen en werken zoals verwacht. Als u bijvoorbeeld een bekend geblokkeerd item verzendt, kunt u controleren of er beveiligingscontroles aanwezig zijn en goed werken voordat de implementatie wordt uitgevoerd. Overweeg deze tests indien nodig uit te voeren of te integreren in het releaseproces.

Het is belangrijk om te testen of het systeem per ongeluk informatie kan weergeven. Het systeem mag bijvoorbeeld geen persoonlijke gegevens weergeven in de nettolading van het antwoord. Test ook om ervoor te zorgen dat een client geen toegang heeft tot eindpunten die zijn bedoeld voor andere identiteiten. Voer beveiligingstests uit om te controleren of de API, met de verificatie- en autorisatiemechanismen, geen vertrouwelijke informatie lekt en de juiste gebruikerssegmentatie onderhoudt.

De grondgegevens testen

Gegevensontwerp is van invloed op de efficiëntie van een generatief model en aardingsgegevens zijn het kritieke onderdeel. Grondgegevens bieden meer context om de relevantie van het antwoord te verbeteren. Deze wordt geïndexeerd voordat het model wordt bereikt. Deze index wordt in realtime geopend wanneer de gebruiker wacht op een antwoord.

Voer end-to-end tests uit en neem dat proces op als onderdeel van het gegevensontwerp. Implementeer een testproces dat de resultaten van de ervaring van de klant evalueert en kwantificeert op basis van de prestaties, indeling, index, voorverwerking en brongegevens van het model. De metrische kwaliteitsgegevens iteratief bewaken en meten. Hier volgen enkele overwegingen:

  • Test de gegevensverwerking grondig met behulp van functionele en integratietests. Controleer of de gegevens zijn geladen zoals verwacht en of alle gegevens aanwezig zijn.

  • Test het indexschema voor compatibiliteit met eerdere versies. U moet een wijziging in een document of veld testen om ervoor te zorgen dat de nieuwe versie nog steeds geschikt is voor eerdere versies van gegevens.

  • Voordat gegevens worden geïndexeerd, ondergaat deze voorbereiding om ruis en vooroordelen te verminderen en efficiënte query's mogelijk te maken. Dit proces omvat voorverwerking, segmentering en berekening van insluitingen, en elke stap slaat gegevens op in de context of bestanden in de index. Een indelingspijplijn, zoals vaardighedensets die worden geleverd door Azure AI Search, voert deze stappen uit. U moet de indelingscode testen om ervoor te zorgen dat er geen stappen worden gemist en dat de verwerkte gegevens van hoge kwaliteit zijn.

    Tests moeten controleren op oude gegevens, synthetische waarden, lege tabellen, gegevensvernieuwing en verwerking op de nieuwste versie. Als er testfouten optreden, moet u mogelijk de zoekquery en index aanpassen. Dit proces omvat het aanpassen van filters en andere elementen die eerder zijn besproken. U moet het testen beschouwen als een iteratieve activiteit.

  • Indexen zijn complex en queryprestaties kunnen variëren op basis van de indexstructuur. Hiervoor is een schatting van de belasting vereist. Het testen van de juiste belasting kan helpen bij het bepalen van de verschillende SKU's voor opslag, berekening en andere resources die beschikbaar zijn om uw vereisten te ondersteunen.

  • U moet alle beveiligingscontroles testen. Gegevens kunnen bijvoorbeeld worden gepartitioneerd in afzonderlijke documenten. Elke partitie heeft toegangsbeheer. U moet deze controles goed testen om vertrouwelijkheid te beschermen.

De orchestrator testen

Een belangrijk onderdeel van een RAG-toepassing is de centrale orchestrator. Deze code coördineert verschillende taken die betrekking hebben op de eerste vraag van de gebruiker. Orchestrator-taken vereisen doorgaans inzicht in de intentie van de gebruiker, een verbinding met de index om grondgegevens op te zoeken en het deductie-eindpunt aan te roepen. Als agents taken moeten uitvoeren, zoals het aanroepen van REST API's, verwerkt deze code deze taken binnen de context.

U kunt indelingscode ontwikkelen in elke taal of helemaal zelf schrijven. We raden u echter aan om technologieën zoals prompt flow te gebruiken in de Azure AI Foundry-portal of de Gerichte Acyclische Grafen (DAGs) van Apache Airflow om het ontwikkelingsproces te versnellen en te vereenvoudigen. Promptstroom biedt een ontwerptijdervaring. Gebruik het om taken te modulariseren als eenheden en invoer en uitvoer van elke eenheid te verbinden, waardoor uiteindelijk de indelingscode wordt gevormd, die het hele proces vertegenwoordigt.

De indelingscode isoleren. Ontwikkel deze afzonderlijk en implementeer deze als een microservice met een online-eindpunt en REST API voor toegang. Deze aanpak zorgt voor modulariteit en implementatiegemak.

Behandel deze code vanuit een testperspectief als elke andere code en voer eenheidstests uit. Het belangrijkste aspect is echter de functionaliteit, zoals de routeringslogica, die u kunt valideren via functionele en integratietests. Testprompt engineering om ervoor te zorgen dat de code de intentie van de gebruiker kan detecteren en aanroepen op de juiste manier kan routeren. Er zijn verschillende frameworks en bibliotheken voor testen, zoals Scikit-learn, de module torch.testing van PyTorch, FairML voor vooroordelen en fairness-tests en TensorFlow-modelanalyse voor modelevaluatie.

Voer ook runtimetests uit, zoals het testen van de foutmodus. Test bijvoorbeeld mogelijke fouten die betrekking hebben op tokenbeperkingen.

Bepaalde runtimetests kunnen u helpen bij het nemen van een beslissing. Voer belastingstests uit om te begrijpen hoe deze code zich gedraagt onder stress en gebruik de resultaten voor capaciteitsplanning. Omdat deze code zich op een cruciaal punt in de architectuur bevindt waar deze andere services moet bereiken, kan deze helpen bij het verzamelen van telemetrie van al deze aanroepen. Deze gegevens kunnen inzicht geven in de hoeveelheid tijd die wordt besteed aan lokale verwerking versus netwerkaanroepen en het gedrag van andere onderdelen bepalen, zoals mogelijke latentie. Technologieën zoals promptstromen hebben ingebouwde telemetriemogelijkheden om dit proces te vergemakkelijken. Anders moet u telemetrie opnemen in uw aangepaste code.

Notitie

Het testen van deze code heeft gevolgen voor de kosten. Als u bijvoorbeeld Azure OpenAI gebruikt om uw deductie-eindpunt te hosten, is stresstests een veelvoorkomende procedure waarmee u de limieten van het systeem kunt bepalen. Azure OpenAI brengt echter kosten in rekening voor elke oproep, waardoor uitgebreide stresstests duur kunnen zijn. Een manier om kosten te optimaliseren, is het gebruik van ongebruikte PTU's van Azure OpenAI in een testomgeving. U kunt ook het deductie-eindpunt simuleren.

Beveiligingsproblemen zijn van toepassing op zowel de indelingscode als het model. Neem het testen op jailbreaking op, waarbij het doel is om de beveiliging van het model te verbreken. Aanvallers communiceren niet rechtstreeks met het model. Ze communiceren eerst met de indelingscode. De indelingscode ontvangt aanvragen van gebruikers en parseert deze. Als de indelingscode een kwaadwillende aanvraag ontvangt, kan deze aanvraag doorsturen naar het model en mogelijk inbreuk maken op het model.

Inhoudsveiligheid is een ander belangrijk aspect. In een chatbottoepassing ontvangt indelingscode chattekst. Overweeg in de code een veiligheidsservice voor inhoud aan te roepen. Verzend zowel de gebruikersprompt als de grondcontext voor analyse en ontvang een beoordeling van het risico. Prompt Shields is een geïntegreerde API die invoer van grote taalmodellen analyseert en gebruikerspromptaanvallen en documentaanvallen detecteert. Dit zijn twee veelvoorkomende typen adversarial invoer.

Beveiligingsbeheer en -verificatie zijn cruciaal voor een RESTful-eindpunt. U moet verificatie beheren en grondig testen.

Modelverval voorkomen

Een veelvoorkomend probleem voor alle modellen is een zekere mate van verslechtering in de loop van de tijd. Wijzigingen die intern en extern zijn voor de workload veroorzaken uiteindelijk een verslechtering van de kwaliteit van het model en de uitvoer ervan. Modelverval treedt op twee manieren op:

  • Gegevensdrift treedt op wanneer de invoergegevens worden gewijzigd. Nieuwe gegevensinvoer zorgt ervoor dat het getrainde model verouderd is. U hebt bijvoorbeeld een model waarmee stempatronen van een bepaald geografisch gebied, zoals een district, worden voorspeld. Als het district opnieuw wordt getekend en de demografische gegevens van de bevolking van dat district veranderen, moet uw model worden bijgewerkt om rekening te houden met de wijzigingen.

  • Conceptdrift treedt op wanneer voorwaarden die zich buiten de werkbelasting bevinden en het model zodanig veranderen dat het model niet langer overeenkomt met de realiteit. U hebt bijvoorbeeld een verkoopprognosemodel voor een technologieproduct. Als een concurrent onverwacht een geavanceerder concurrerend product introduceert dat aanzienlijke aandacht trekt van het publiek, moet u uw model bijwerken op basis van de manier waarop consumententrends veranderen.

Gebruik indien mogelijk geautomatiseerde tests om verval van het model te detecteren en te evalueren gedurende de levenscyclus van uw model. Als uw model discrete waarden voorspelt, kunt u tests maken om voorspellingen te evalueren op basis van deze waarden in de loop van de tijd en de afwijking tussen verwachte en werkelijke resultaten te meten. Vul deze test aan met bewaking om drift in de loop van de tijd te detecteren door samenvattingsstatistieken en metrische gegevens over afstand te vergelijken.

Een andere veelvoorkomende benadering om modelverval te identificeren, is feedback van gebruikers. Een voorbeeld van feedback van gebruikers is een duim omhoog of duim omlaag reactiemechanisme. Het bijhouden van de positieve versus negatieve feedback in de loop van de tijd en het maken van een waarschuwing wanneer u aan een drempelwaarde voor negatieve feedback voldoet, kan u helpen bij het onderzoeken van de kwaliteit van het model.

Ongeacht de signalen die u gebruikt om modelverval te identificeren, moet het operationele team dat wordt gewaarschuwd over potentieel verval een data scientist betrekken om het signaal te onderzoeken en te bepalen of verval plaatsvindt en de hoofdoorzaak.

Hulpprogramma's implementeren

Gebruik Azure Machine Learning-gegevensverzamelaar om realtime logboekregistratie van invoer- en uitvoergegevens op te halen uit modellen die zijn geïmplementeerd voor beheerde online-eindpunten of Kubernetes Online-eindpunten. Machine Learning slaat de vastgelegde deductiegegevens op in Azure Blob Storage. U kunt deze gegevens vervolgens gebruiken voor modelbewaking, foutopsporing of controle, die waarneembaarheid biedt in de prestaties van uw geïmplementeerde modellen. Als u een model buiten Machine Learning of op een Machine Learning-batcheindpunt implementeert, kunt u niet profiteren van gegevensverzamelaar en een ander proces voor gegevensverzameling operationeel maken.

Machine Learning-modelbewaking gebruiken om bewaking te implementeren. Machine Learning verkrijgt bewakingssignalen door statistische berekeningen uit te voeren op gestreamde productiedeductiegegevens en referentiegegevens. De referentiegegevens kunnen historische trainingsgegevens, validatiegegevens of grondwaargegevens zijn. Aan de andere kant verwijzen de productiedeductiegegevens naar de invoer- en uitvoergegevens van het model die in de productie zijn verzameld.

Volgende stappen