Skift AI-basismodel uden tab af kvalitet: Evals, Canary og Rollback

En ny AI-basismodel lover ofte bedre svar, lavere omkostninger eller hurtigere responstider. For en produktiv website-chatbot er udskiftningen dog ikke det samme som at opdatere en tilfældig softwarepakke. Selv en ny modelversion kan vægte instruktioner anderledes, formulere svar mere uddybende, generere strukturerede data afvigende eller kalde værktøjer i en anden rækkefølge. En migrering er derfor først succesfuld, når chatbotten udfører sine konkrete opgaver mindst lige så pålideligt som før – og når teamet kan skifte tilbage på få minutter, hvis der opstår problemer.

Udbydere udfaser regelmæssigt modeller. OpenAI-dokumentationen om udfasninger angiver lukningsdatoer og anbefalede erstatningsmodeller; Anthropic skelner i sin modellivscyklus mellem statusserne "Active", "Legacy", "Deprecated" og "Retired". Sådanne tidsfrister er anledningen til migreringen, men ikke dokumentation for dens kvalitet. Den dokumentation leveres kun af en test- og udrulningsprocedure, der passer til din egen chatbot.

Hvad der reelt ændres ved et skift af basismodel

Denne proces skal klart adskilles fra en migrering af embedding-modellen. Ved et embedding-skift skal dokumenter genvektoriseres, og søgeindekser skal holdes kompatible. Ved et skift af basismodel forbliver retrieval-indekset normalt uændret; det er modellen, der genererer svaret ud fra systeminstruktionen, samtalen, de fundne kilder og værktøjsresultaterne, der ændres. Derfor testes svaradfærd, kildeforankring, format, værktøjsbrug, sikkerhed, latenstid og omkostninger.

Selv en generel shadow-mode-test før launch på websitet løser kun en del af opgaven. Shadow-trafik kan forsyne to modeller med de samme input uden at levere det nye svar til brugeren. Det modelskift, der beskrives her, går videre: Det definerer på forhånd en godkendelsesmatrix, dirigerer en lille andel af den reelle trafik til kandidaten, overvåger bruger- og systemsignaler og holder en afprøvet tilbageførsel klar.

Før testen: Fastlæg en entydig migreringskontrakt

Sammenligninger er værdiløse, hvis flere ting ændrer sig samtidig. Hold derfor systemprompt, retrieval-konfiguration, værktøjsskemaer, temperatur, maksimal outputlængde og sikkerhedsregler så konstante og kompatible som muligt i første runde, og dokumenter uundgåelige parameterændringer, såsom samplingindstillinger, der ikke understøttes. Dokumenter den hidtidige model som baseline og den nye model som kandidat. Brug om muligt eksplicitte modelversioner i stedet for et dynamisk alias. Et alias kan senere pege på et andet snapshot og derved ændre den forventede reproducerbare sammenligning.

Migreringskontrakten indeholder desuden de brugergrupper og funktioner, der i første omgang udelukkes. En FAQ-chatbot kan for eksempel gå tidligt i canary, mens skriveadgang til ordrer, aftaleoplysninger eller særligt følsomme supportsager forbliver længere på basismodellen. På den måde begrænses risikoen ud fra forretningsmæssig konsekvens og ikke kun ud fra teknisk kompleksitet.

Testsættet skal afspejle den reelle trafik

Et Golden Set bør ikke kun indeholde rene standardspørgsmål. Indsaml anonymiserede eller syntetisk genskabte sager fra de vigtigste intents: entydige spørgsmål, flertydige formuleringer, opfølgende spørgsmål, manglende dokumenter, modstridende kilder, værktøjsfejl og input, der skal overdrages til et menneske. Opdel sagerne efter sprog, enhed, kundetype og risikoklasse. Dermed forbliver det synligt, om en god samlet score skjuler små, men forretningskritiske undergrupper.

Den officielle Anthropic-vejledning til succeskriterier og evals anbefaler specifikke, målbare og anvendelsesorienterede kriterier samt virkelighedsnære grænsetilfælde. Også OpenAI-vejledningen til evals beskriver tests som en væsentlig del af pålidelige applikationer, især ved opgradering eller afprøvning af nye modeller. Da OpenAI på samme side varsler udfasning af den hidtidige Evals-platform, bør dit eget Golden Set gemmes i et bærbart format og ikke være bundet til et enkelt dashboard.

En vurderingsmatrix i stedet for en enkelt gennemsnitsværdi

De følgende grænseværdier er et eksempel, ikke en universel regel. Fastlæg dem ud fra den hidtidige produktionsydelse og skadesomfanget ved en fejl. En kandidat må ikke købe en lavere tokenpris på bekostning af dårligere kildeforankring.

Automatiske tjek egner sig til JSON-skemaer, obligatoriske formuleringer, linkdestinationer, værktøjsargumenter og deterministiske forretningsregler. Tonefald, fuldstændighed og nyttige forklaringer kræver desuden en klar evalueringsskala; stikprøver udført af fagpersoner kalibrerer en LLM-baseret bedømmer. Resultaterne bør gemmes pr. intent og risikoklasse, ikke kun som en samlet score. Hvordan et sådant sæt opbygges, viser også vores guide til svarkvalitet med Golden Set.

Konkret eksempel: Modelskift i B2B-support

Antag, at en B2B-softwareudbyder driver en chatbot til produktspørgsmål, kontoadministration og klargøring af support-tickets. Teamet opretter 240 testsager: 120 hyppige vidensspørgsmål, 40 flertydige opfølgende spørgsmål, 30 sager med manglende kilde, 25 værktøjssimuleringer og 25 sikkerheds- eller overdragelsessager. Begge modeller modtager præcis de samme prompts, dokumentresultater og simulerede værktøjsresultater.

Kandidaten besvarer standardspørgsmål hurtigere og billigere, men mister konteksten til den forrige besked i fem opfølgende spørgsmål. Den samlede score ville stadig være bedre. Segmentanalysen viser dog et tydeligt kvalitetsbrud. Teamet tilføjer ikke en tilfældig undtagelse, men præciserer samtalereglen, udvider testsættet med lignende sager og tester begge modeller igen. Først da kandidaten opfylder alle hårde gates, påbegyndes den produktive canary-fase.

Til at starte med tildeles to procent af de egnede nye samtaler til kandidaten. Tildelingen udledes ved samtalestart ud fra f.eks. en hash af Conversation-ID'et og fastholdes for hele samtalen; højere canary-trin gælder kun for nye samtaler. Skrivende værktøjskald og højrisiko-intents forbliver i første omgang på basismodellen. Efter et tilstrækkeligt stort observationstidsrum følger 10, 25, 50 og til sidst 100 procent – men kun hvis hver gate fortsat er grøn. Trin og minimumsstikprøver fastlægges på forhånd, så tidspres ikke i eftertid udvander reglerne.

Online-signaler, der virkelig tæller

I canary-fasen er HTTP-fejl og gennemsnitlig latenstid ikke nok. Overvåg no-answer-rate, afbrydelser efter første svar, gentagne spørgsmål, handoff-rate, kildeklik, skemafejl og værktøjsafbrydelser opdelt på baseline og kandidat. Et fælles trace forbinder modelversion, promptversion, retrieval-matches og værktøjstrin uden at gemme unødvendige personhenførbare oplysninger. Vores indlæg om chatbot-observability forklarer dette revisionsspor i detaljer.

Sammenlign desuden omkostninger pr. succesfuldt løst sag i stedet for blot omkostninger pr. million tokens. En billigere model, der hyppigere skaber opfølgende spørgsmål eller kræver manuel opfølgning, kan være dyrere i drift. Omvendt kan en lille stigning i latenstid være acceptabel, hvis den beviseligt leverer mere præcise svar i en vigtig risikoklasse.

Rollback er en funktion, ikke et dokument

Tilbagetrækningsvejen skal være teknisk testet før det første canary-trin. Model-ID og tilhørende parametre hører hjemme i en versioneret konfiguration eller et kontrolleret feature flag. Så længe udbyderen stadig understøtter den hidtidige version, forbliver den tilgængelig som fallback under canary-fasen; inden dens udløbsdato kræves der desuden et understøttet fallback-mål. Eksisterende samtaler bør enten forblive konsekvent på deres oprindelige model eller skifte efter en udtrykkeligt afprøvet regel.

Definer hårde udløsere: for eksempel en skemafejl ved en skrivende handling, en forringelse af en sikkerhedsrelevant intent, et markant hop i fejlraten eller en overskridelse af latenstidsbudgettet. Ved et sådant signal skiftes der automatisk eller via en klart udpeget vagtordning tilbage. Derefter bevares logs, kandidatversion og den berørte stikprøve, så årsagen kan analyseres. En forberedt procedure er væsentligt mere robust end en spontan kodeudrulning; som supplement hjælper en komplet incident-response-playbook.

Tjekliste til godkendelse

• Registrer udløbsdato, erstatningsmodel og berørte endpoints fra udbyderens officielle dokumentation.
• Fastlås baseline og kandidat med uændret prompt-, retrieval- og værktøjskonfiguration.
• Opdel Golden Set efter intent, sprog og risikoklasse; tilføj grænsetilfælde og reelle fejlmønstre.
• Definer hårde gates for kildeforankring, strukturerede outputs, værktøjer, sikkerhed og handoff.
• Mål latenstid, fejlrate, tokens og omkostninger pr. løst sag.
• Hold canary-tildelingen stabil for hele samtaler, og udeluk følsomme funktioner i første omgang.
• Dokumenter trin, minimumsstikprøve, observationsvarighed og afbrydelsesgrænser før udrulning.
• Test rollback teknisk, udpeg ansvarlige, og hold et udbyderunderstøttet fallback-mål tilgængeligt.
• Fortsæt overvågningen efter 100 procent, og udvid Golden Set med nyopdagede produktionssager.

Konklusion: Modelnavnet er kun begyndelsen

Et kontrolleret skift af basismodel forbinder produktkvalitet med driftssikkerhed. Officielle livscyklusnoter giver tidsfristen, evals giver evidens for egnetheden, canary-trafik begrænser effekten af ukendte fejl, og et afprøvet rollback forkorter responstiden. Når disse fire byggestene etableres som en gentagelig proces, kan du tage nye modeller i brug uden at gøre din website-chatbot til et eksperiment for alle brugere.

Vil du planlægge modelversion, kvalitetsgates og udrulning af din website-chatbot på en struktureret måde? ChatReact hjælper dig med at opsætte vidensbase, svaradfærd og overdragelser, så ændringer forbliver målbare og kontrollerbare.