Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Følgende afsnit gælder for alle modelændringer, uanset om det er en proaktiv opgradering eller en reaktion på en pensionering. Definér først portene, fang en baseline fra den aktuelle model, og arbejd dig derefter igennem faserne.
Definér migrationsacceptporte
Definer acceptkriterier før evaluering af kandidatmodellen, så agentens evaluering giver en beslutning i stedet for kun et sæt scores. Omfatte:
- Minimum samlet beståelsesprocent
- Påkrævet beståelsesrate for forretningskritiske scenarier
- Kritiske fejl, der blokerer migration uanset samlet score
- Tilladt latenstid og pålidelighedsvarians
- Godkendelse af sikkerhed, overholdelse og regional behandling
- Acceptabel forbrugs- eller omkostningspåvirkning
- Påkrævet ejer- og frigivelsesgodkendelsesgodkendelse
Sammenlign den nuværende og kandidatmodel ved at bruge samme agentkonfiguration, testdata, testsæt, brugerprofiler og miljøantagelser. Undersøg individuelle regressioner i stedet for kun at stole på en gennemsnitlig score.
Modeloutputtene er probabilistiske. Kør vigtige scenarier mere end én gang, når variation kan påvirke beslutningen.
Etabler et genanvendelig evalueringsbaseline
Før du ændrer modellen, skal du oprette et testsæt, der repræsenterer agentens forretningskritiske og højfrekvente scenarier. Kør testsat mod den nuværende produktionsmodel for at etablere en baseline.
Brug både testchat og agentvurdering:
- Brug testchat til at udforske hele samtaler og inspicere orkestreringen med aktivitetskortet.
- Brug agentevaluering til at køre gentagelige testsæt, måle resultater og sammenligne kørsler over tid.
De testmetoder, du har til rådighed, afhænger af agentens sele, så bekræft dem, før du designer testsættet. Læs mere i Bekræft hvilke testmetoder din agent støtter.
Evaluer hele agentens adfærd
Godkend ikke en erstatningsmodel bare fordi dens samlede beståelsesrate ligner den nuværende model.
Dæk følgende områder. Hver af dem er en adfærd, der ofte ændres, når modellen ændres, så et testsæt, der udelader et område, kan ikke opdage en regression i det.
| Evalueringsområde | Hvad en modelændring kan ødelægge | Sådan tjekker du det |
|---|---|---|
| Svarkvalitet | Relevans, fuldstændighed, nøjagtighed, klarhed og konsistens i de spørgsmål, agenten oftest modtager. | Generel kvalitet |
| Jordnærhed og viden | Modellen svarer ud fra træningsdata i stedet for den konfigurerede videnskilde, dropper citationer eller håndterer ufuldstændige eller modstridende kilder anderledes. | Generel kvalitet |
| Undladelse | Modellen besvarer et spørgsmål uden for rammerne i stedet for at afvise eller eskalere. | Generel kvalitet, eller Custom med besvarede og afviste etiketter |
| Instruktionsfølgning | Instruktioner, som modellen pålideligt fulgte, springes over, såsom eskalationsregler, grænser, forbudte adfærdsmønstre eller en obligatorisk ansvarsfraskrivelse. | Søgeordsmatch på de nødvendige fraser, eller Custom med instruktionsspecifikke labels |
| Faste værdier og outputformat | En præcis værdi som et telefonnummer, kode eller ID omskrives eller opfindes, eller outputformen ændrer sig og bryder en downstream parser eller kanalintegration. | Præcist match eller nøgleordsmatch i det ønskede format |
| Værktøjsvalg og fastholdelse | Modellen vælger et andet værktøj, kalder ingen, eller kalder et værktøj, når intet værktøj er nødvendigt. | Værktøjsbrug med de forventede værktøjer eller emner defineret, plus en gennemgang af aktivitetskortet |
| Værktøjsinput og sekventering | Parametre udtrækkes, formateres eller standardiseres anderledes, eller trin i en multitool-opgave omarrangeres, slås sammen eller fjernes. | Værktøjsbrug med alle forventede værktøjer, plus generel kvalitet |
| Bekræftelse og fejlhåndtering | Modellen stopper med at bede om bekræftelse før en konsekvenshandling, eller en værktøjsfejl fremstilles anderledes i stedet for at blive rapporteret. | Tilpasset med bekræftelsesetiketter, plus nøgleordsmatch på det forventede fejl-sprog |
| Multiturn-adfærd | Kontekst fra tidligere ture går tabt eller fortolkes på ny, eller afklaring, emneskift og genopretning håndteres forskelligt. | Generel kvalitet på et samtaletestsæt |
| Rodet og modstridende input | Svagere håndtering af tastefejl, fragmenter og uklar hensigt, eller en anden reaktion på prompt-injektion og rolleoverskrivningsforsøg. | Generel kvalitet, plus Custom med Nægtet og Complied-etiketter |
| Sikkerhed og overholdelse af angivne standarder | Håndtering af skadeligt indhold, dataadgang, tilladelser, regional behandling og ansvarlige krav til AI. | Brugerdefinerede etiketter, sammen med en ansvarlig AI-gennemgang |
| Latenstid og pålidelighed | Responstid, timeouts, variation, mislykkede opkald og genforsøg under repræsentative betingelser. | Ikke rapporteret ved evaluering. Mål i testchat og produktionsovervågning. |
| Forbrug og omkostninger | Copilot Credit-forbrug eller andre modelrelaterede omkostninger for repræsentative scenarier. | Ikke rapporteret ved evaluering. Mål i kapacitets- og forbrugsrapportering. |
| Sprog og kanaler | Kvalitet og adfærd på tværs af understøttede sprog, brugerprofiler og implementeringskanaler. | Kør testsættet for hvert sprog, brugerprofil og kanal, der betyder noget |
Vær særligt opmærksom på instruktionsopfølgning og latenstid. En kandidatmodel kan forbedre svarkvaliteten, men introducere langsommere svar, anderledes værktøjsudvælgelsesadfærd eller fejl i instruktioner, der var pålidelige med den tidligere model.
Bekræft hvilke testmetoder din agent støtter
De testmetoder, der er tilgængelige for din agent, afhænger af dens sele.
Lær mere i:
Byg og vedligehold testsættet
- Dæk først forretningskritiske lykkeveje og store forespørgsler, derefter svære sager: edge cases, modsætningsinput, anmodninger der bør afvises eller eskaleres, værktøjsfejl, lange samtaler og flersprogede anmodninger.
- Start fra rigtig trafik. Analysetemaer og optagede samtaler skaber mere repræsentative testcases end opfundne.
- Foretræk dækning frem for polish. Et større sæt ufuldkomne tilfælde finder flere regressioner end et lille sæt perfekt formulerede.
- Giv først karakter til den nuværende model, derefter kandidaten. Sammenligningen, ikke det absolutte tal, fortæller dig, om migrationen er sikker.
- Behold sættet hos agenten i versionskontrol, og kør det uændret ved hver modelændring.
- Del sættet efter risikoområde. Et testsæt drevet af standardledningsnettet rummer op til 100 testcases, så brug separate sæt til vidensnøjagtighed, værktøjsadfærd og sikkerhedsfølsomme scenarier.
- Eksport af resultater. Evalueringsresultater opbevares i 89 dage, så eksporter dem til CSV for at holde en registrering af, hvad hver model scorede ved migreringen.
- Konverter produktionshændelser og brugerfeedback til nye regressionstests.
Lær mere i Design og operationaliser agentvurdering.
Bemærkning
Agentvurdering måler korrekthed og ydeevne, ikke AI-etik eller sikkerhedsproblemer. En agent kan bestå alle testcases og stadig give et upassende svar. Brug ansvarlige AI-gennemgange og indholdssikkerhedsfiltre sammen med evaluering.
Automatiser tilbagevendende evalueringer
Copilot Studio understøtter kørsel af evalueringer gennem Power Platform API'en, så du kan integrere modelvalidering i release-workflows og kontinuerlige integrationspipelines. For en stor agentportefølje er automatisering det, der gør gentagen kandidattestning bæredygtig i stedet for manuel. Lær mere i Automate evalueringer med Power Platform API'en.
Opdater agent-artefakterne, som en modelændring påvirker
En modelændring påvirker sjældent kun modelindstillingen. Oversæt den relevante udbydervejledning til de agent-artefakter, du kontrollerer, og valider derefter hver ændring mod din evalueringsbaseline. En oprensning, der ikke bliver gentestet, er et gæt.
| Artefakt | Typisk ændring |
|---|---|
| Agentinstruktioner | Gør implicitte forventninger eksplicitte, fjern løsninger skrevet for den tidligere model, gentag grænser og eskalationsregler og forbudte adfærdsregler entydigt, løs modstridende instruktioner, og kalibrer hvor meget selvstændig handling agenten skal tage. |
| Emne- og nodeinstruktioner | Anvend samme behandling på emneniveau, og bekræft at generative svar-noder stadig opfører sig som forventet. |
| Værktøjs- og handlingsbeskrivelser | Omskriv for klarhedens skyld. Denne beskrivelse er det, modellen læser for at afgøre, om og hvornår et værktøj skal kaldes, og vage beskrivelser forårsager både over- og underkald. |
| Beskrivelser af input- og outputparametre | Stram formatet, enhederne, eksemplerne og den nødvendige eller valgfrie semantik, så parametergenereringen forbliver korrekt. |
| Konfiguration af videnkilde | Tjek instruktioner til valg af kilde, afgrænselse og jordforbindelse igen, og verificér citationsadfærd. |
| Instruktioner til svarformatering | Gentag den krævede struktur, længde, ansvarsfraskrivelser og præcise værdier eksplicit, fordi nyere modeller ændrer standardordmængden. |
| Konfirmation og sikkerhedsporte | Genhæv eksplicitte bekræftelseskrav før konsekvenshandlinger. |
| Nedstrøms forbrugere | Opdater Power Automate-flows, adaptive kort, kanalintegrationer og enhver parser, der læser agentens output. |
| Testsættet selv | Tilføj de nye fejlmønstre, der er opdaget under migrationen. |
Migrationsfaser
De følgende faser sætter de foregående sektioner i udførelsesrækkefølge. Brug dem som arbejdsplan for en enkelt agents modelændring, uanset om ændringen er proaktiv eller drevet af en pensionering.
Fase 0: Forbered
- Bekræft kandidatmodellen er gyldig i forhold til forudsætningerne: generelt tilgængelig eller standard, tilgængelig i regionen, cross-geo posture acceptabel, administratoraktiveret og den rette brugskategori til agentens formål.
- Læs modeludbyderens opgraderingsvejledning og noter de instruktioner og værktøjsændringer, det indebærer.
- Identificer de berørte stoffer ud fra inventaret, registreringsmiljøet, ejere og kritikalitet.
- Bekræft hvilke evalueringstestmetoder agentens sele understøtter.
- Definer og godkend migrationsacceptportene.
Fase 1: Baseline den nuværende model
- Byg eller opdater regressionstestsættet , så det dækker forretningskritiske og højfrekvente scenarier.
- Kør testsættet mod den nuværende produktionsmodel for at fastlægge baseline. Gør dette, mens den nuværende model stadig er på plads, for efter modellen ændres, kan baseline ikke rekonstrueres.
- Optag latenstid og forbrug af Copilot Credit separat. Evalueringer rapporterer dem ikke.
- Eksporter resultaterne til CSV for at bevare posten ud over opbevaringsvinduet.
Fase 2: Vurder kandidaten i et ikke-produktionsmiljø
Forbered en ikke-produktionskopi af agenten, følg Copilot Studio-vejledningen til applikationslivscyklusstyring og agenttestning. Konfigurér miljøet, så det repræsenterer produktion:
- Brug de samme agentinstruktioner, emner, videnskonfiguration, værktøjer, flows, connectors, sprog og sikkerhedsantagelser.
- Brug repræsentative testidentiteter og forbindelser.
- Anvend de samme datapolitikker og relevante administratorkontroller.
- Bekræft regional tilgængelighed og om der kræves krydsgeo-dataflytning.
- Registrer eventuelle forskelle mellem test og produktion, der kan påvirke resultatet.
Skift model. Gå til agentens oversigtsside og vælg kandidatens primære model i sektionen Model . Der findes separate indstillinger til dyb ræsonnering, generative svar og prompt-byggeren, så tjek om agenten bruger disse funktioner, og om de også skal ændres.
Kør det samme testsæt igen, uændret, mod kandidatmodellen.
Sammenlign de to løb med acceptportene for at identificere forbedringer og regressioner.
Inspicer orkestreringen kvalitativt i testchatten ved at bruge aktivitetskortet til at bekræfte, hvilke værktøjer der blev valgt, i hvilken rækkefølge og med hvilke parametre.
Mål latenstid og forbrug for kandidaten og sammenlign dem med baseline.
Fase 3: Oprensning
- Opdater agent-artefakterne, som modelændringen påvirker, og kør derefter testsættet igen mod den remedierede agent. Læs mere i Forbedre agenter ved hjælp af evalueringsdrevet triage og afhjælpning.
- Iterer indtil acceptkriterierne er opfyldt, eller konkluder at kandidatmodellen ikke er egnet, og dokumenter hvorfor. At beslutte ikke at opgradere er et legitimt, evidensbaseret resultat.
Fase 4: Godkend og udrul
- Få godkendelse af acceptportalerne fra agentens ejer og frigivelsesgodkender, inklusive sikkerheds- og overholdelsesgodkendelse, når der er involveret cross-geo eller eksterne modeller.
- Udrul gennem den etablerede ALM-proces, hvor løsningen promoveres fra test til produktion. Rediger ikke produktionsagenten manuelt.
- Arranger udrulningen , når kanalen tillader det. Publicér først til et pilotpublikum eller en enkelt kanal, observer resultatet, og udvid så.
Fase 5: Overvåg og luk
- Overvåg produktionsadfærden mod acceptportene.
- Tilføj nyligt opdagede fejlmønstre til regressionstestsættet.
- Luk først migrationen, når acceptkriterierne er opfyldt i produktionen.
- Bevar evalueringsbeviserne og migrationsbeslutningsprotokollen til revision og til næste livscyklusbegivenhed.
Vigtigt!
Rollback-vejen for en modelændring er at genudrulle den tidligere validerede løsningsversion, som er langsommere end en konfigurationsskift. Denne forskel gør evalueringsporten i fase 2 så vigtig. At opdage en regression før udsendelse er billigere end at vende en bagefter.
Monitor efter migration
Arbejdet med modellivscyklussen fortsætter efter udrulning. Skærm:
- Agentvurderingsresultater og beståelsesprocenter for kritiske scenarier.
- Produktionsanalyser, transskriptioner, aktivitet, fejl og brugerfeedback.
- Fejl i instruktionsfølgning og værktøjsvalg.
- Latenstid, timeouts og pålidelighed.
- Forbruget ændrer sig.
- Sikkerheds-, compliance- og regionale behandlingshensyn.
Når produktionsovervågning identificerer et nyt fejlmønster, tilføj et repræsentativt tilfælde til regressionstestsættet. Denne praksis forbedrer den næste modelevaluering og omdanner produktionslæring til et holdbart kvalitetsgrundlag.
Telemetri på miljøniveau udsender OpenTelemetry GenAI-omfang til Application Insights, inklusive modellen brugt for hver agentkald. Brug det til at bekræfte, hvilken model produktionstrafik faktisk kører på, og til at sammenligne værktøjsvalg og pålidelighed før og efter en migrering.