Versionsstyr prompter, modeller og workflowlogik som én AI-release

En AI-release er hele den konfiguration, som kan ændre den leverede adfærd – ikke blot en promptstreng eller navnet på et modelendpoint. Hvis teamet kun ruller modellen tilbage, kan den nye prompt, værktøjskontrakt, tilladelsesregel, retrievalindstilling eller retry-logik fortsat være aktiv. Resultatet er en konfiguration, som hverken svarer til den testede kandidat eller til den tidligere stabile release.

Driftsopgaven er derfor at give den samlede adfærdsstak én identitet, fryse de opløste komponenter og knytte evaluering, godkendelse og deploymenthændelser til denne identitet. Så kan teamet svare på tre afgørende spørgsmål: Hvad blev faktisk testet? Hvilken konfiguration betjente en problematisk request? Hvilken kompatibel helhed skal modtage trafikken, hvis udrulningen stoppes?

Hvad skal tælle som én AI-release?

Én AI-release skal omfatte enhver runtime-afhængighed, der kan ændre tjenestens adfærd, myndighed, risiko, pris, svartid eller observerbarhed. Den praktiske grænse går derfor rundt om den effektive konfiguration, som møder en request. NIST beskriver aktiviteter og komponenter gennem AI-livscyklussen som indbyrdes afhængige, mens Google Cloud fremhæver, at et produktionssystem rummer langt mere end selve modelkoden.

• Prompten og dens opløste version eller indholdshash.
• Det konkrete modelsnapshot samt temperatur, outputgrænse og øvrige effektive inferensparametre.
• Værktøjsskemaer, forbindelser, tilladelser og krav om menneskelig godkendelse.
• Politikker, guardrails, retrieval- og kontekstindstillinger samt routingregler.
• Workflowkode, input- og outputskemaer, runtime-afhængigheder og adfærdspåvirkende miljøbindinger.

Evalueringsdatasæt, bedømmere, rubrikker og tærskler kører normalt ikke i serving-stien, men de påvirker beslutningen om at sende kandidaten videre. De skal derfor versionsstyres og forbindes med releaseposten som assurance-aktiver. Første- og tredjepartsafhængigheder hører kun med, når de reelt kan ændre tjenesten eller fortolkningen af dens evidens; grænsen skal dokumenteres for det konkrete system.

Hvordan bindes adfærdsstakken i et release-manifest?

Adfærdsstakken bindes ved at oprette et uforanderligt kandidatmanifest med én release-id og opløste referencer til alle relevante komponenter. Manifestet skal mindst angive oprettelsestidspunkt, ejer, måltjeneste, status, stopbetingelser, rollbackansvarlig og den foregående kendte stabile release. Ændres en adfærdspåvirkende komponent, opstår en ny kandidat – også når ændringen ser lille ud.

• Brug versionsnumre, commits, artefaktdigests, indholdshashes eller andre stabile referencer.
• Gem de effektive indstillinger sammen med identiteten; et alias som production eller latest er kun en flytbar pegepind.
• Registrer feature-flagets identitet, routingbegrænsninger, godkendte forbindelser og relevante data- eller retrievalreferencer uden at gemme hemmeligheder.
• Notér kompatibilitetskrav, migreringer og skemaændringer, som kan begrænse rollback.
• Knyt buildresultater, evalueringer, godkendelser og rolloutplanen til manifestet i stedet for at blande dem ind i komponenthistorikkerne.

Tag en intern supportassistent, der opsummerer sager, foreslår svar og først må oprette en CRM-opgave efter medarbejderens godkendelse. Kandidaten support-assistant-r18 kan binde prompt p-42, modelsnapshot m-2026-07 med parametre, værktøjsskema t-9, tilladelsespolitik policy-12, workflowcommit wf-a71, outputskema reply-6 og runtime-låsen. Releasepakken linker særskilt til evalueringssuite eval-23 og de anvendte bedømmerversioner.

Manifestet må ikke muteres, når eksponeringen ændres. Trafikandel, kohorteregel, deploymenttidspunkt og beslutning registreres som tilknyttede promoveringshændelser. En på forhånd godkendt eksponeringsstigning kan fortsætte med samme kandidat. En ændret routing- eller miljøbinding, der påvirker kontekst, myndighed eller behandling af den enkelte request, kræver derimod en ny release-id og ny evidens.

Kan noget ændre den leverede adfærd – eller evidensen, der godkender den – skal det have en opløst identitet i releaseposten.

Hvilken evidens afgør, om kandidaten må fortsætte?

Kandidaten må kun fortsætte på baggrund af dokumenteret evidens for præcis den komplette konfiguration, som skal promoveres. Releasenoterne bør forklare den tilsigtede adfærdsændring, alle ændrede afhængigheder, berørte scenarier og grænseflader, ændringer i tilladelser eller observerbarhed, kendte begrænsninger, restrisiko, rolloutansvar og det kompatible rollbackmål. Noterne skal støtte en beslutning, ikke blot genfortælle commits.

Generelle modelbenchmarks er utilstrækkelige til et konkret forretningsworkflow. Brug virkelige scenarier, vigtige segmenter og sjældne, men kostbare randtilfælde; kontrollér samtidig automatiske bedømmere med relevant faglig vurdering. Sammenlign kandidaten med den aktuelle release. Et pænt samlet gennemsnit må ikke skjule brud på kontrakter, tilladelser eller sikkerhedsregler eller en væsentlig regression i et vigtigt segment.

Versionsstyr også evalueringsdatasæt, bedømmere, rubrikker og tærskler. En ændret port kan ændre resultatets betydning, selv om runtime-kandidaten er identisk. Hver port skal slutte med en registreret beslutning om at promovere, holde eller afvise samt en navngiven ejer. Ved højere risiko kan forfatteren til ændringen og den, der godkender produktionseksponering, være forskellige personer.

Hvordan flyttes den samme kandidat sikkert i produktion?

Den samme opløste kandidat skal flyttes gennem målte trin uden at blive ændret undervejs. Offlineevaluering og produktionsobservation supplerer hinanden: Den første giver kontrollerede sammenligninger, mens den anden viser adfærd under mere realistiske forhold. Ingen af delene dokumenterer fuldstændig sikkerhed. En begrænset kohorte kan mangle sjældne fejltilstande, sæsonudsving eller trafik, som reagerer anderledes på systemet.

1. Kør shadow eller ikke-handlende replay, hvor skriveværktøjer og andre konsekvensfulde sideeffekter er deaktiveret eller lagt i sandkasse.
2. Giv derefter en intern gruppe adgang, mens alle eksterne handlinger fortsat følger de aftalte godkendelser.
3. Brug en stabil, sticky produktionskohorte, så sammenligningen ikke forstyrres af skiftende tildeling mellem releases.
4. Udvid eksponeringen efter det aftalte observationsvindue og de aftalte evidenskrav.
5. Flyt til fuld trafik, men behold release-tagget overvågning og den kompatible tidligere release i det fastlagte tidsrum.

Sammenlign opgavekvalitet, sikkerhed, værktøjsadfærd, fejl, svartid og omkostning med den aktuelle release gennem hele forløbet. Trafikandel, nødvendigt antal observationer og periodens længde skal vælges ud fra tjenestens risiko, trafikmængde, detektionstid og bemanding – ikke kopieres som universelle standardtal. Hvis prompten, modellen, et værktøj, en politik, et skema eller en relevant binding ændres, begynder processen med en ny kandidat.

Hvornår skal releasen stoppes, og hvad skal rollback gendanne?

Releasen skal stoppes straks ved en på forhånd defineret sikkerheds- eller politikovertrædelse, uautoriseret værktøjsadfærd, kontraktbrud eller alvorlig driftsfejl. Andre kvalitets-, omkostnings- eller svartidsregressioner bør følge tjenestespecifikke grænser. Et uklart fund kan begrunde en pause og undersøgelse frem for automatisk rollback, men beslutningen, evidensen og den ansvarlige skal stadig registreres eksplicit.

• Flyt trafikken til den komplette, kendte stabile release – ikke til en tilfældig blanding af gamle og nye komponenter.
• Kontrollér skemaer, tilstandsændringer, migreringer, værktøjskontrakter, routing og udbydertilgængelighed før skiftet.
• Øv gendannelsen, mens systemet er roligt, og registrer hvor lang tid valideringen faktisk tager.
• Bekræft efter skiftet, at den stabile release betjener trafikken, og at de kritiske service- og myndighedskontroller er intakte.

Rollback styrer kun fremtidig routing. Det sletter ikke allerede sendte beskeder, tilbagefører ikke datawrites, annullerer ikke godkendelser og fjerner ikke opgaver, som et værktøj har oprettet i et eksternt system. Brug release-tagget tracing til at finde berørte requests og handlings-id'er. Følg derefter et særskilt, autoriseret beredskab for afgrænsning, afstemning, korrektion, underretning, genetablering eller kompenserende handling.

Hvilken dokumentation gør en AI-release rekonstruerbar?

En AI-release bliver rekonstruerbar, når den varige post forbinder den uforanderlige kandidat med den evidens og de beslutninger, der førte den gennem produktionen. Bevar manifestet, opløste komponentidentiteter og parametre, miljøbindinger, kompatibilitetsresultater, evalueringsversioner og resultater, godkendelser, deploymenthændelser, trafiktildeling, fund, rollbackhændelser og den endelige disposition. Posten skal vise både hvad der kørte, og hvorfor det blev tilladt.

• Release-id på traces, så genereringer, værktøjskald, overdragelser, guardrails, timing og udfald kan tilskrives.
• Applikationens trace-id og udbyderens request-id, når de findes.
• Tidspunkt, miljø, kohorte, trafikandel, beslutningsejer og eventuelle godkendte undtagelser.
• Henvisninger til resultater og styrede stikprøver frem for automatisk lagring af alle prompts, input, output og kundedata.

Målet er konfigurationsreproducerbarhed og beslutningsreproducerbarhed: Teamet kan genfinde den effektive opsætning og forstå den daværende beslutning. Fastgjorte identiteter, arkiverede indstillinger og request-id'er garanterer ikke byte-identisk gengivelse fra stokastiske eller hostede AI-tjenester. Start med den mindste releasepakke, der stadig identificerer kandidaten, evidensen, promoveringsbeslutningerne og rollbackmålet. Inddrag organisationens kvalificerede specialister, når ændringen berører følsomme data, vidtgående tilladelser, regulerede workflows, opbevaring eller udbedring af eksterne handlinger.