Versjoner prompter, modeller og arbeidsflyt som én AI-lansering

En AI-lansering er hele konfigurasjonen som kan endre det brukeren faktisk møter, ikke bare modellnavnet eller promptteksten. Ruller teamet tilbake modellen, men lar en ny verktøykontrakt, tillatelse eller rutingregel stå igjen, er ikke den testede tilstanden gjenopprettet. Én samlet lanseringsidentitet gjør det mulig å se hva som ble evaluert, hva som betjente en problematisk forespørsel, og hvilken komplett konfigurasjon trafikken kan føres tilbake til.

Hva skal regnes som én AI-lansering?

Én AI-lansering skal omfatte alle avhengigheter som kan endre levert atferd, myndighet, risiko, kostnad, responstid eller observerbarhet. NIST beskriver AI-livsløpet som gjensidig avhengige aktiviteter, mens Google Cloud beskriver produksjons-ML som langt mer enn modellkode. Den praktiske konsekvensen er en systemspesifikk avgrensning: ta med det som faktisk kan påvirke tjenesten, uansett om komponenten er utviklet internt eller levert av en tredjepart.

• Prompten, den oppløste modellidentifikatoren og alle effektive inferensparametere.
• Verktøyskjemaer, tillatelser, policyer, kontrollmekanismer og godkjenningskrav.
• Henting av kunnskap, kontekstinnstillinger, arbeidsflytkode, inn- og utskjemaer og kjøretidsavhengigheter.
• Ruting, funksjonsflagg, godkjente forbindelser og andre miljøbindinger som endrer behandlingen av en forespørsel.

Evalueringsdatasett, bedømmere, rubrikker og terskler hører også hjemme i lanseringsposten, men i en egen rolle. De kjører vanligvis ikke i betjeningsbanen; de påvirker beslutningen om kandidaten får slippe videre. Når en terskel eller bedømmer endres, kan det samme resultatet tolkes annerledes. Derfor må både kjørekandidaten og beslutningsgrunnlaget ha versjoner som kan kobles sammen uten at de blandes til én uoversiktlig artefakt.

Opprett en ny kandidat når prompt, modelløyeblikksbilde, parameter, policy, verktøykontrakt, tillatelse, hentekonfigurasjon, arbeidsflyt, skjema, avhengighet eller atferdspåvirkende binding endres. Komponentenes egne historikker er fortsatt nyttige, men de kan ikke være eneste dokumentasjon. Etter en hendelse bør ingen måtte rekonstruere den effektive kombinasjonen ved å gjette hvilke aliaser og innstillinger som tilfeldigvis gjaldt på utrullingstidspunktet.

Hvordan bindes atferdsstakken i et lanseringsmanifest?

Atferdsstakken bindes ved å fryse et manifest med én lanserings-ID og stabile referanser til alle effektive komponenter. Manifestet bør angi opprettelsestid, eier, måltjeneste, status, stoppvilkår, ansvarlig for tilbakerulling og forrige kjente fungerende versjon. Bruk en versjon, commit-ID, artefaktsammendrag eller innholdshash som faktisk identifiserer innholdet. Et alias som «produksjon» eller «nyeste» er bare en flyttbar peker og må oppløses.

MLflow viser hvorfor oppløsningen er viktig: promptmaler kan ha uforanderlige versjoner og endringsbare aliaser, mens enkelte modellinnstillinger kan endres etter promptversjoneringen. OpenAI anbefaler dessuten festede modelløyeblikksbilder fordi promptatferd kan endres mellom øyeblikksbilder. Manifestet må derfor lagre den testede modellidentifikatoren, parameterverdiene og den effektive konfigurasjonen, ikke bare navnet på registerobjektet som pekte dit.

• Identitet: lanserings-ID, eier, måltjeneste, tidspunkt, status og forrige kjente fungerende versjon.
• Komponenter: oppløste versjoner eller sammendrag for prompt, modell, verktøy, policy, arbeidsflyt, skjemaer og kjøretid.
• Miljø: ruting, funksjonsflagg, data- eller hentereferanse og godkjente forbindelser, men aldri selve hemmelighetene.
• Beslutning: lenker til evalueringspakke, bedømmerversjoner, resultater, godkjenning, stoppvilkår og oppfølgingsplan.
• Kompatibilitet: skjemaer, migreringer, leverandørtilgjengelighet og bindinger som må fungere ved gjenoppretting.

Tenk på en intern kundestøtteassistent. Kandidaten support-assistant-r18 binder prompt p-42, modelløyeblikksbilde m-2026-07 med parametere, verktøyskjema t-9, tillatelsespolicy policy-12, arbeidsflyt-commit wf-a71, svarskjema reply-6 og låsen for kjøretidsavhengigheter. Evalueringspakken lenker separat til eval-23 og bedømmerversjonene. R17 kan bare oppgis som gjenopprettingsmål etter at nye, valgfrie forfalls- og eskaleringsfelt er kontrollert for kompatibilitet.

Kan noe endre levert atferd eller beviset som godkjenner den, trenger det en oppløst identitet i lanseringsposten.

Hvilke bevis avgjør om kandidaten får gå videre?

Kandidaten skal gå videre på grunnlag av dokumenterte tester av akkurat den komplette konfigurasjonen som kan nå produksjon. Lanseringsnotatet bør beskrive ønsket atferdsendring, alle endrede avhengigheter, berørte situasjoner og grensesnitt, endringer i tillatelser og observerbarhet, kjent usikkerhet, rest-risiko, utrullingsansvar og et kompatibelt gjenopprettingsmål. Da blir notatet et beslutningsgrunnlag, ikke en oppramsing av tekniske commits.

Sammenlign kandidaten med gjeldende versjon på kontrakter, oppgaveutførelse, relevante avvisninger og eskaleringer, viktige segmenter, kostbare randtilfeller, verktøyatferd, stabilitet, responstid og kostnad. Generelle modellmålinger kan ikke beskrive alle nyansene i en bestemt arbeidsflyt. En samlet poengsum må heller ikke skjule et vesentlig kontraktsbrudd, en myndighetsoverskridelse, et sikkerhetsproblem eller en tilbakegang i et viktig segment.

Hver port skal ende med «fremme», «hold» eller «avvis», med navngitt eier og lenke til beviset. For høyere risiko kan den som skrev endringen, være en annen enn den som godkjenner produksjonssettingen. Datasett, rubrikker, bedømmere og terskler må følge resultatet med egne versjoner. Ellers kan teamet se at en kandidat «bestod», men ikke rekonstruere hvilken prøve eller vurderingsregel utsagnet viste til.

Hvordan skal samme kandidat flyttes inn i produksjon?

Den samme oppløste kandidaten skal flyttes gjennom målte trinn uten at konfigurasjonen endres underveis. Start med skyggekjøring eller ikke-utførende avspilling når det er praktisk mulig. Skriveverktøy og andre handlinger med konsekvenser må da deaktiveres eller kjøres i en sandkasse; produksjonshandlinger skal ikke spilles blindt på nytt. Fortsett deretter til intern bruk, en stabil kanarikohort, utvidet eksponering og til slutt full trafikk.

1. Kjør representative saker i skygge og sammenlign hele spor, uten at kandidaten kan utføre eksterne handlinger.
2. Åpne for en intern brukergruppe mens alle handlinger fortsatt følger de godkjente tillatelses- og kontrollreglene.
3. Bruk en stabil produksjonskohort og sammenlign oppgave-, sikkerhets-, verktøy-, stabilitets-, tids- og kostnadssignaler med gjeldende versjon.
4. Utvid først når avtalte observasjons- og utvalgskrav er oppfylt, og behold kandidatens konfigurasjon uendret.
5. Flytt til full trafikk, behold gjenopprettingsmålet i avtalt periode og fortsett versjonsmerket overvåking.

Kohortregel, trafikkfordeling, observasjonstid og beslutning lagres som utrullingshendelser som peker på kandidaten. En forhåndsgodkjent økning i eksponering er ikke i seg selv en ny kandidat. Endres derimot prompt, modellinnstilling, verktøy, tillatelse, policy, kontekst, arbeidsflyt, skjema, avhengighet eller miljøbinding som påvirker forespørselen, kreves ny identitet og nytt evidensløp. Dermed vet operatørene at det som måles, er det som faktisk ble godkjent.

Ingen universell kanariandel eller observasjonsperiode passer alle tjenester. Velg dem ut fra konsekvens, trafikkmengde, hvor raskt feil kan oppdages, og hvor mye teamet kan følge opp. En skyggekjøring mangler ofte virkningene av ekte brukeratferd, mens en kanarikohort kan gå glipp av sjeldne situasjoner. Begrenset eksponering gir derfor ny informasjon, men beviser ikke full produksjonssikkerhet eller komplett dekning.

Når skal lanseringen stanses, og hva må tilbakerullingen gjenopprette?

Lanseringen skal stanses ved et forhåndsdefinert brudd på sikkerhet eller policy, uautorisert verktøyatferd, et vesentlig kontraktsbrudd eller alvorlig stabilitetssvikt. Andre tilbakeganger følger tjenestens egne, forhåndsgodkjente grenser. Et uklart funn kan tilsi pause og undersøkelse i stedet for automatisk tilbakerulling, men også da må eier, beslutning og neste kontroll være tydelige. Stoppregelen skal være avtalt før trafikken økes, ikke forhandles mens hendelsen pågår.

Tilbakerulling skal føre trafikken til hele den kompatible, kjente fungerende pakken, ikke bare bytte én komponent. Gjenopprettingsmålet må derfor inneholde sin egen prompt, modellkonfigurasjon, verktøy, tillatelser, policy, arbeidsflyt, skjemaer, avhengigheter og bindinger. Øv på rutingen før den trengs, og kontroller skjemaer, tilstandsendringer, migreringer, verktøykontrakter, leverandørtilgjengelighet og ruting på nytt. En tidligere versjon er ikke automatisk kjørbar i dagens miljø.

• Registrer utløser, første observerte tidspunkt, berørt kandidat, kohort og arbeidsflytbane.
• Bekreft gjenopprettingsmålet og dokumenter kompatibilitetskontrollen før trafikken flyttes.
• Valider tjenesten etter gjenoppretting og registrer tidspunkt, resultat og ansvarlig.
• Håndter berørte forespørsler og eksterne handlings-ID-er i en separat, autorisert oppfølgingsprosedyre.

Konfigurasjonstilbakerulling påvirker fremtidig ruting. Den sletter ikke meldinger, reverserer ikke dataregistreringer, trekker ikke tilbake godkjenninger og fjerner ikke oppgaver som allerede er opprettet i et eksternt system. Bruk versjonsmerkede spor til å finne berørte forespørsler, arbeidsflytbaner og handlings-ID-er. Deretter må virksomhetens autoriserte prosedyre styre sperring, avstemming, korrigering, varsling, gjenoppretting eller kompenserende handling. Dette er et eget ansvarsløp, ikke en egenskap ved modelltilbakerullingen.

Hvilken dokumentasjon gjør en AI-lansering rekonstruerbar?

En AI-lansering blir rekonstruerbar når registeret bevarer både den effektive konfigurasjonen, beviset og beslutningsforløpet. Ta vare på det frosne kandidatmanifestet, oppløste komponentidentifikatorer og parametere, miljøbindinger, kompatibilitetsfunn, evalueringsversjoner og resultater, godkjenninger, utrullingshendelser, trafikkfordeling, funn, tilbakerullinger og endelig disposisjon. Det skal være mulig å fastslå hva som kunne kjøre, hvorfor kandidaten ble fremmet, og hva observasjonen senere viste.

Legg lanserings-ID-en ved applikasjonssporene, slik at genereringer, verktøykall, overleveringer, kontrollmekanismer, tidsbruk og utfall kan knyttes til kandidaten som betjente forespørselen. Registrer også leverandørens forespørsels-ID og applikasjonens spor-ID når de finnes. Det gir et kryss-systemlig holdepunkt under feilsøking. Sporingsverktøy gjør imidlertid ikke koblingen automatisk til et egendefinert manifest; metadatafeltet og praksisen må bygges inn i arbeidsflyten.

• Kandidatmanifest, komponentversjoner, effektive parametere og relevante miljøbindinger.
• Evalueringsressurser, resultater, kjente begrensninger, godkjenninger og unntak.
• Utrullingstrinn, kohortregler, trafikkfordeling, observasjonstid og hver beslutning.
• Versjonsmerkede spor, funn, gjenopprettingshendelser, validering og endelig disposisjon.
• Styrte referanser til sensitive data, uten et generelt krav om å lagre alle nyttelaster.

Målet er konfigurasjonsreproduserbarhet og beslutningsreproduserbarhet, ikke et løfte om identiske modellutdata. Festede identifikatorer, arkiverte innstillinger og spor kan vise hva systemet var satt opp til å gjøre og hvilket bevis beslutningen bygget på. Stokastisk sampling og endringer i vertsbaserte tjenester kan likevel hindre byteidentisk avspilling. Bevar derfor de minste opplysningene som gir tilstrekkelig avstamning, mens sensitive prompt-, verktøy- og kundedata håndteres etter virksomhetens regler.

Den minste brukbare lanseringspakken er den som entydig identifiserer kandidaten, den versjonerte evalueringen, de trinnvise beslutningene og det kompatible gjenopprettingsmålet. Når en endring berører sensitive data, omfattende tillatelser, regulerte arbeidsflyter, arkivplikt eller oppfølging av eksterne handlinger, må relevante fagansvarlige for sikkerhet, personvern, juridiske forhold, dokumentasjon, risiko eller domene involveres. Denne driftsmodellen organiserer beslutningen, men avgjør ikke slike krav.