Så designar jag ett system som överlever när en modell byts ut
Modellbyten är inte undantag längre. De är normal drift. Därför försöker jag bygga AI-system som kan byta motor utan att kasta affärsregler, evals och state machine samtidigt.
Modellbyten är inte undantag längre. De är normal drift. Därför försöker jag bygga AI-system som kan byta motor utan att kasta affärsregler, evals och state machine samtidigt.
Modellen är en dependency
Jag behandlar numera språkmodellen ungefär som en databasdrivrutin eller betalprovider: viktig, men inte identisk med produkten. Om affärsregler, output-schema och state transitions bara finns implicit i en prompt för en viss modell blir ett modellbyte ett omskrivningsprojekt.
Lås kontraktet ovanför modellen
Jag definierar input, output-schema, tool permissions, required evidence och felstatusar utanför modellprompten. Då kan två modeller testas mot samma kontrakt. Prompten får vara adapterlagret, inte databasen för alla regler.
Pin production, test latest
I produktion föredrar jag stabila, explicita modellversioner när leverantören erbjuder dem. Samtidigt kör jag regressioner mot nyare kandidatmodeller. Google skiljer uttryckligen mellan stable, preview, latest och experimental och varnar för att latest kan byta under aliaset. Det illustrerar varför en produktionsmiljö behöver ett medvetet versionsval.
Capability tests före migration
Jag byter inte modell för att en benchmark säger att den är bättre. Jag kör mina egna golden cases: tool calling, JSON/schema, språk, källtrohet, edge cases, long-context-beteende och de felmoder som varit dyra historiskt. Om den nya modellen vinner på generella reasoningtester men regressar på en kritisk workflow-funktion är den inte en drop-in replacement.
Deprecation ska vara ett normalt driftfall
Anthropic publicerar model deprecation och tentative retirement dates; andra leverantörer har liknande livscykler. Jag vill därför ha en inventory över var modell-ID används, vilka prompts/adapters som hör till det och vilken fallback som redan är verifierad. Då blir en deprecation ett planerat change request i stället för incident.
Separera model-specific tuning
Vissa modeller behöver annorlunda instruktioner, tool descriptions eller reasoninginställningar. Jag lägger det i adapters. Den normativa arbetsprocessen ligger kvar i ett gemensamt lager. Det är samma princip jag använder för portabla Skills: kärnan ska beskriva vad som måste vara sant; adaptern beskriver hur en specifik runtime bäst kommer dit.
Överlevnadsförmåga är en evalfråga
Ett system är modelloberoende först när jag kan visa att en annan godkänd modell klarar kontraktet. En abstrakt model_provider-klass räcker inte. Den verkliga portabiliteten sitter i testfallen, datamodellen, state machine och frånvaron av leverantörsspecifika antaganden i affärslogiken.