Byt AI-modell och pröva med samma flöde

Granska hela det berörda applikationsflödet när du byter modell. En ny modellbeteckning i konfigurationen räcker inte som bevis. Använd en befintlig utvärderingsuppsättning och dokumentera vilken förändring du faktiskt jämför.

Dokumentera båda konfigurationerna tydligt

Dokumentera modellbeteckning, promptversion, tillförda källor, verktyg och inställningar för båda varianterna. Om indata, regler och bearbetning förblir lika kan du undersöka modellbytet mer riktat. Om även prompt, adapter eller bedömning måste ändras jämför du två applikationskonfigurationer; tillskriv inte skillnaden enbart modellen.

Microsoft beskriver jämförelser av sparade varianter med samma fall och granskning av enskilda fel. De förväntade sakliga besluten för ditt flöde ska vara fastställda före jämförelsen.

Gör skillnader synliga för varje fall

Följande exempel är helt påhittat. En applikation ska extrahera en projektkod ur ett meddelande eller begära manuell granskning. Den beviljar ingen projektåtkomst. Fältnamnen är vårt eget interna schema, inget leverantörs-API.

Tabellen innehåller antagna utdata som förklaring. Det är inget utfört modelltest. Fallbeskrivningarna ersätter inte versionshanterade originalindata i en verklig jämförelse.

I det andra fallet väljer den nya varianten ett projekt trots oklarheten. I det tredje bryter den mot fältkontraktet. En sammanlagd bedömning kan dölja dessa olika felorsaker. Formellt giltiga utdata måste också vara sakligt korrekta.

Hantera fel före fortsatt bearbetning

OWASP rekommenderar att modellutdata valideras innan de skickas till efterföljande komponenter. I exemplet får ett saknat obligatoriskt fält inte behandlas som en lyckad extrahering. Applikationen måste avvisa utdata eller leda dem till avsedd granskning. Ett projektfält ger fortfarande ingen åtkomsträtt.

Kontrollera utöver sak- och formatfall även de språk som faktiskt behövs, avbrott och omförsök. En enda körning visar ingen stabil felfrekvens. Om kända fel används för att anpassa den nya varianten behövs ytterligare undanhållna fall för en oberoende kontroll.

Planera driftsättning och återgång tillsammans

Bestäm före driftsättning vilka fel som hindrar bytet och vem som bedömer olösta skillnader. I tabellexemplet behöver först det förhastade projektvalet från ett oklart meddelande och det saknade obligatoriska fältet hanteras.

Behåll den tidigare applikationskonfigurationen och en kontrollerad väg tillbaka. Klargör också om den tidigare modellen fortfarande är tillgänglig och lagrade data förblir kompatibla. Följ efter bytet de faktiska resultaten i det berörda flödet; tre illustrativa fall visar ingen generell produktionsmognad.

Källor

• Microsoft — Evaluate models, prompts, and agents

• OWASP 2025 — Improper Output Handling