Versionera promptar, modeller och arbetsflöden som en sammanhållen AI-release

En AI-release är hela den beteendepåverkande konfigurationen, inte bara modellnamnet eller prompttexten. Om en incident uppstår efter ett modellbyte räcker det därför inte alltid att återställa modellen: den nya prompten, verktygsdefinitionen, behörighetsregeln, kontextinställningen eller vägen för återförsök kan fortfarande vara aktiv. Releasearbetet behöver ge ett enda svar på tre frågor: vad testades, vad betjänade en viss begäran och vilket komplett kompatibelt paket kan få tillbaka trafiken?

Vad ska räknas som en sammanhållen AI-release?

En sammanhållen AI-release ska omfatta de delar som faktiskt kan förändra tjänstens svar, befogenheter, risk, kostnad, svarstid eller observerbarhet. NIST beskriver aktiviteterna i AI-livscykeln som beroende av varandra, medan Google Clouds MLOps-vägledning framhåller att produktionssystem består av betydligt mer än modellkod. Den exakta gränsen är systemspecifik, men den bör beslutas före testning och inte rekonstrueras först när något har gått fel.

• Prompt och instruktioner, inklusive mallar och systemmeddelanden.
• Upplöst modellidentifierare samt effektiva sampling-, längd- och inferensinställningar.
• Verktygsscheman, behörigheter, godkännandekrav, policyer och skyddsregler.
• Retrieval, kontextkällor, arbetsflödeskod, in- och utdatascheman samt runtime-beroenden.
• Feature flags, routing, anslutningar och andra miljöbindningar som påverkar hur en begäran hanteras.

Utvärderingsdata, bedömare, bedömningskriterier och trösklar körs normalt inte i tjänstens svarsväg, men de påverkar beslutet att släppa fram kandidaten. De ska därför versionshanteras som kvalitetssäkrande tillgångar och länkas till releaseposten. När en väsentlig runtime-komponent eller sådan beslutsgrund ändras ska ändringen kunna identifieras separat; annars går det inte att avgöra om resultat mellan två granskningar verkligen är jämförbara.

Hur binds hela beteendestacken i ett releasemanifest?

Hela beteendestacken binds genom ett fryst kandidatmanifest som pekar på upplösta versioner, digestar, innehållshashar, commit-ID:n eller andra stabila referenser. Ett alias som ”produktion” eller ”senaste” är bara en föränderlig pekare. MLflow visar exempelvis både oföränderliga promptversioner och föränderliga alias och modellinställningar, vilket illustrerar varför releaseposten måste fånga den effektiva konfiguration som faktiskt utvärderades.

• Release-ID, skapelsetid, ägare, måltjänst, status och tidigare känt fungerande release.
• Upplöst identitet och effektiva inställningar för varje runtime-komponent.
• Miljöbindningar, kompatibilitetsvillkor, migreringar, routing och godkända anslutningar utan att lagra hemligheter.
• Länkar till byggresultat, utvärderingsversioner, godkännanden, stoppvillkor, återställningsägare och åtgärdsrutin.

Manifestet bör vara oföränderligt efter att kandidaten har skapats. Planerad trafikandel, kohortregel, starttid och utfall hör i stället hemma i länkade befordringsposter. En förhandsgodkänd exponeringsökning kan därmed avse samma kandidat, men ett byte av prompt, modellparameter, verktyg, behörighet, policy, retrievalinställning, schema eller annan beteendepåverkande bindning kräver en ny releaseidentitet och ny relevant evidens.

För supportassistenten kan kandidaten support-assistant-r18 binda prompt p-42, modellögonblicksbild m-2026-07 med temperatur 0,2 och övriga parametrar, CRM-schemat t-9, policyn policy-12, arbetsflödescommitten wf-a71, utdataschemat reply-6 och låsfilen för runtime. Releasepaketet länkar separat till eval-23 och bedömarversionerna. support-assistant-r17 får bara anges som återställningsmål efter en kompatibilitetskontroll av de nya valfria fälten för förfallodatum och eskaleringsorsak.

Om något kan ändra det betjänade beteendet eller underlaget som godkänner beteendet behöver det en upplöst identitet i releaseposten.

Vilken evidens ska avgöra om kandidaten får gå vidare?

Kandidaten får gå vidare först när det exakta kompletta paketet har klarat relevanta kontroller och en namngiven ägare har registrerat beslutet befordra, avvakta eller avslå. NIST efterfrågar dokumenterade, repeterbara utvärderingsmetoder och ett uttryckligt beslut om driftsättning. Underlaget ska därför visa metod, testdata, bedömare, kriterier, trösklar, resultat, avvikelser och vem som tog beslutet.

Releasenoteringen ska vara skriven för ett beslut, inte som en lista över commitmeddelanden. Beskriv avsett beteende, ändrade beroenden, berörda scenarier och gränssnitt, förändrade behörigheter eller loggar, kända begränsningar, kvarstående risk, utrullningsägare och ett kompatibelt återställningsmål. Arbetsflödesspecifika exempel och kostsamma gränsfall behövs eftersom generella modellutvärderingar inte fångar varje verksamhetskontext.

Ett högt totalresultat får inte dölja ett väsentligt kontraktsfel, obehörig verktygsanvändning, en säkerhetsbrist eller en försämring i ett viktigt segment. Google Cloud rekommenderar jämförelse mot nuvarande lösning och kontroll av segment och tjänstegränssnitt. För mer riskfyllda releaser kan den som godkänner befordran vara en annan person än ändringsförfattaren; även små team bör spara beslut, underlag och eventuella undantag.

Hur ska samma kandidat flyttas in i produktion?

Samma upplösta kandidat ska flyttas genom en stegvis och mätbar befordringsstege. Börja om möjligt med skuggkörning eller återspelning utan verkande åtgärder; skrivande verktyg och andra konsekvensskapande funktioner ska vara avstängda eller sandlådade. Fortsätt därefter till intern användning, en stabil produktionskohort, utökad exponering och slutligen full trafik, med ett dokumenterat beslut efter varje steg.

1. Skuggkör representativa ärenden och jämför hela spår med nuvarande release utan att upprepa externa åtgärder.
2. Släpp fram en intern användargrupp medan alla konsekvensskapande verktyg behåller sina godkännandekrav.
3. Tilldela en stabil kanariekohort så att samma användare eller ärenden inte hoppar godtyckligt mellan releaser.
4. Öka exponeringen först när tjänstens avtalade evidens- och observationskrav är uppfyllda.
5. Flytta till full trafik men behåll det verifierade återställningsmålet och fortsatt releasemärkt uppföljning.

Trafikregler, tilldelning, observationsperiod och disposition registreras som driftsättningshändelser kopplade till release-ID:t. Kandidatens prompt, modellinställningar, verktyg, policyer, kontext och arbetsflöde får inte justeras i smyg mellan stegen. Trafikandelar, urvalskrav och tidsfönster ska väljas utifrån tjänstens risk, trafik, upptäcktstid och driftkapacitet; det finns inga universella värden som gör en kanarie säker.

Offlineprov, skuggtrafik och en begränsad kohort kompletterar varandra men bevisar inte full produktionssäkerhet. Skuggkörningen saknar vissa återkopplingseffekter från verklig användning, medan kanariekohorten kan missa sällsynta kombinationer eller trafiksegment. Behåll därför stabil kohorttilldelning och releasemärkt telemetri, jämför uppgiftsresultat, verktygsbeteende, tillförlitlighet, svarstid och kostnad med den nuvarande releasen och dokumentera vad observationen inte täckte.

När ska releasen stoppas, och vad måste återställningen omfatta?

Releasen ska stoppas när ett förhandsbestämt hårt villkor utlöses, och trafiken ska då återföras till ett komplett kompatibelt känt fungerande paket. Hårda stopp passar för väsentliga säkerhets- eller policybrott, obehörigt verktygsbeteende, brutna kontrakt och allvarliga tillförlitlighetsfel. Övriga försämringar bedöms mot tjänstens egna gränser. Oklara fynd kan motivera paus och undersökning i stället för omedelbar återställning, men även det beslutet behöver en ägare.

Återställ inte bara modellen om prompten, verktygskontraktet eller arbetsflödet också ändrades. Kontrollera först att föregående paket fortfarande passar aktuella scheman, tillstånd, migreringar, routingregler, verktyg och leverantörstillgänglighet. Google Cloud rekommenderar att återgång till föregående tjänsteversion provas i förväg och att den tidigare versionen registreras med driftsättningsinformationen. Ett oprövat versionsnamn är inte ett tillräckligt reservmål.

• Stäng kandidatens framtida trafik och validera det återställda paketet.
• Identifiera berörda begäranden, arbetsflödesvägar och externa åtgärds-ID:n via relesemärkta spår.
• Isolera fortsatt verktygsåtkomst eller annan pågående påverkan när det är behörigt och nödvändigt.
• Följ en separat godkänd rutin för avstämning, rättelse, avisering, återställande eller kompensationsåtgärd.
• Dokumentera utlösare, tider, omfattning, beslut, slutligt utfall och ansvarig för uppföljningen.

Konfigurationsåterställningen styr bara kommande routing. Den raderar inte redan skickade meddelanden, återkallar inte godkännanden och tar inte automatiskt bort poster som ett verktyg har skapat i ett externt system. För supportassistenten innebär det att felaktiga CRM-uppgifter måste identifieras från spåren och hanteras enligt en behörig CRM-rutin. Vilken rättelse som är lämplig beror på åtgärden och organisationens ansvar, inte på releasemekanismen.

Vilket register gör AI-releasen rekonstruerbar i efterhand?

Ett hållbart register måste göra både den effektiva konfigurationen och releasebeslutet rekonstruerbara. Spara det frysta manifestet, upplösta komponentidentifierare och parametrar, miljöbindningar, kompatibilitetsresultat, versioner och resultat för utvärderingstillgångar, godkännanden, driftsättningshändelser, trafikfördelning, fynd, återställningar och slutlig disposition. Google Clouds vägledning rekommenderar motsvarande härledning för komponenter, körningar, parametrar, artefakter, utvärderingar och föregående modell.

• Release-ID på varje spår, tillsammans med arbetsflödesväg, generationer, verktygsanrop, överlämningar, skyddsregler, tidsdata och utfall.
• Applikationens spår-ID och leverantörens begärans-ID där sådana finns, så att felsökning kan följa systemgränser.
• Beslutsägare, underlag, undantag, kohortregler, exponeringstidpunkter, stopporsaker och återställningsvalidering.
• Styrda referenser eller urval i stället för ett krav att spara varje känslig prompt, nyttolast, verktygsinmatning eller modellutdata.

Kalla resultatet konfigurationsreproducerbarhet och beslutsreproducerbarhet. Låsta identifierare, arkiverade inställningar och spår gör det möjligt att förstå vad som borde ha körts och varför kandidaten godkändes, men de garanterar inte byte-identiska svar från en stokastisk eller driftad AI-tjänst. När releasen ändrar känslig datahantering, långtgående behörigheter, reglerade arbetsflöden eller åtgärder i externa system behöver berörda säkerhets-, integritets-, juridik-, arkiv-, risk- eller domänansvariga avgöra de specifika kraven.