Kontraktstestet testar gränsen du äger, inte om en språkmodell beter sig identiskt varje gång. Lås därför de egenskaper som din kod måste få: det validerade resultatet, ett verktygsanrops format, ett säkert felutfall och gränser för tid och kostnad. När en kandidatmodell bryter någon av dem ska uppdateringen stoppas eller hanteras som en medveten klientändring.
Modellnamnet är inte integrationskontraktet
En modelluppdatering kan ändra mer än kvaliteten på texten. Den kan börja utelämna ett fält som tidigare fanns, välja ett annat verktyg, returnera en vägran i ett nytt format eller sluta inom en annan tidsbudget. Det behöver inte vara ett fel hos leverantören. Det blir ett fel först när din klient har byggt ett antagande som inte längre stämmer.
Börja med att skriva ner vilket kontrakt som faktiskt finns mellan din applikation och AI-lagret. Om ett svar passerar en schema-validering och blir ett internt objekt är det objektet en viktigare kontraktsyta än modellens fria formulering. Om modellen får anropa ett verktyg är verktygsnamn, argument och valideringsfel kontraktsyta. Om klienten väljer reservmodell är reglerna för när den får göra det kontraktsyta.
Teamet sparar ett lyckat svar från produktion och jämför sedan framtida svar som exakt text. Testet blir skört av skrivstil och missar samtidigt det viktiga: att ett obligatoriskt fält försvinner, att ett belopp saknar valuta eller att ett verktygsanrop inte längre går att validera. Jämför den stabila, maskinläsbara effekten i stället för formuleringen.
Välj få kontrakt som fångar verklig skada
Inventera först var modellens utdata lämnar ett tolerant AI-lager och blir styrande för resten av systemet. Det är där ett kontraktstest gör mest nytta. En bra första uppsättning är liten nog att köras i CI, men nära de konsekvenser som annars skulle nå användare eller data.
Undvik kontrakt som bara mäter en subjektiv kvalitetsbedömning, till exempel att svaret ska vara ”bra”. Sådana utvärderingar kan vara värdefulla som separat regressionstestning, men de kan inte ensamma skydda en klient mot ett trasigt format eller en oavsiktlig skrivning.
Bygg testfallen från produktionsnära gränser
Ett kontraktstest behöver inte ringa en extern modell varje gång. Börja med inspelade eller handskrivna svar på den gräns där din klient tar emot dem. Då kan testet bevisa att parsning, validering, felmappning och verktygsspärrar fungerar utan nätverk, prisvariation eller varierande modelltext.
Testa verktygsanrop som opålitlig indata
När en modell väljer funktioner eller verktyg ska anropet behandlas som indata från en extern part. Validera namnet mot en tillåten lista, validera argumenten mot ett schema och bind varje anrop till den behörighet och det ändamål som gäller i den aktuella körningen. Ett syntaxkorrekt argument är inte automatiskt ett tillåtet argument.
Gör dessutom en testbar skillnad mellan att föreslå och att genomföra. Ett verktyg som skickar e-post, ändrar data eller startar en distribution bör kunna producera en granskningsbar preview utan sid-effekt. Kontraktstestet kan då bevisa att modellen får fram en giltig preview, medan ett separat godkännande styr när den får exekveras.
Minsta uppsättning för ett skrivande verktyg
- Tillåtet verktygsnamn: okända namn stoppas innan routing eller fallback.
- Validerade argument: saknade, extra eller feltypade fält ger ett synligt fel utan sid-effekt.
- Scope: testet visar att ett anrop inte kan peka ut resurser utanför den aktuella användaren, miljön eller uppgiften.
- Preview och verkställande: samma indata kan granskas före exekvering, och verkställandet kräver ett tydligt beslut.
Gör modellbytet till en kontrollerad jämförelse
Kör den nya modellen mot samma uppsättning representativa fall och registrera det validerade utfallet, inte bara råtexten. Ett nytt men giltigt svar är inte nödvändigtvis en regression. Ett förändrat schema, ett bortfall i ett obligatoriskt fält eller ett verktygsanrop utanför scope är däremot en tydlig signal att klienten, prompten eller uppdateringen behöver behandlas.
Dela upp resultatet i tre beslut: godkänd utan ändring, godkänd med medveten kontraktsändring eller stoppad. En medveten ändring ska innehålla vilken klientversion som krävs, vilka fixtures som ersätts och hur återgången sker om den nya modellen visar ett annat beteende i produktion. Precis som vid timeout och omförsök i en AI-integration är ett otydligt mellanläge riskabelt: systemet fortsätter, men ingen vet vilket beteende som är avsiktligt.
Skilj kontraktstest från leverantörstest
Din CI ska snabbt kunna svara på om din egen kod fortfarande hanterar kända utfall säkert. Därför ska de flesta kontraktstester köras utan nätverk. En separat, begränsad testsvit kan ringa leverantörens stagingmiljö eller kandidatmodell för att hitta nya beteenden, men den måste ha hantering för pris, rate limits och icke-deterministiska svar.
När ett externt test fallerar, spara tillräckligt för att felsöka: modellidentifierare, klientversion, schema-version, tidsstämpel, valideringsfel och en redigerad representation av svaret. Spara inte hela promptar eller svar av vana. Testartefakten ska hjälpa dig reproducera gränsfelet utan att bli en ny dataläcka.
En granskningsprompt före modelluppdateringen
Granska integrationen utan att ändra produktionskod.
Lista varje punkt där modellens svar blir ett internt objekt, ett verktygsanrop eller ett användarsynligt beslut. Ange för varje punkt vilket schema, vilka obligatoriska fält och vilket säkert felutfall klienten kräver.
Föreslå en liten uppsättning fixtures: ett giltigt svar, ett svar med saknat obligatoriskt fält, ett feltypat fält, ett otillåtet verktygsanrop och ett avbrutet eller tidsbegränsat svar.
För varje skrivande verktyg: visa hur argument valideras, hur scope begränsas, vilken preview som kan granskas och vilket test som bevisar att en felaktig request inte får sid-effekt.
Avsluta med vilka kontroller som ska köras lokalt i CI, vilka som kräver en extern kandidatmodell och vilka resultat som ska stoppa uppdateringen.
Checklista innan du ändrar modell i produktion
Kontraktstester gör inte en AI-integration förutsägbar i alla detaljer. De gör däremot förändringen synlig där din egen kod behöver hålla ett löfte. Det är den nivå av kontroll som gör att en modelluppdatering kan behandlas som en vanlig, granskbar systemändring i stället för ett hopp i produktion.