Två konfigurationer hör till en uppgraderingsgranskning: den som redan accepterats för uppgiften och det föreslagna ersättningsalternativet. Utan bevis för båda kan teamet beskriva den nya mjukvaran men kan inte förklara förändringen i sin egen arbetsprocess. Vår rekommendation är att göra ett godkännandebevis till en del av uppgraderingen, innan den gamla konfigurationen försvinner.
Denna augustiuppföljningsartikel undersöktes och publicerades i september. Den föreslår en praktisk granskningsmetod; den rapporterar inte en mätt kundimplementering eller lovar någon särskild förbättring.
Bevara det gamla beslutet
Börja med anledningen till att den befintliga konfigurationen accepterades. Lokalisera modellidentitet, runtime-version, testinmatningar och granskningskriterier. Om det dokumentet inte finns, skriv ner vad som fortfarande kan verifieras och identifiera de saknade delarna. Återskapa inte ett lyckat test ur minnet och presentera det som en observation.
Behåll den gamla konfigurationen tillgänglig genom organisationens normala förändringsprocess medan kandidaten utvärderas. Det kan kräva att mer än modelfilen spelas in: dokumentationen, promptmallar och applikationsinställningar kan också påverka uppgiften. Spela in de delar som är viktiga för den föreslagna ändringen.
För en delad AI Server-distribution, namnge de applikationsarbetsflöden som är beroende av tjänsten. En ändring som hjälper ett arbetsflöde kan kräva ett annat godkännandebeslut för ett annat. Behandla tjänstens användare som en del av granskningsgränsen istället för att anta att en demonstration representerar dem alla.
Ange den avsedda förbättringen
En uppgradering bör ha en konkret anledning. Teamet kan söka en stödd runtime, en korrigering av ett känt fel eller bättre resultat på en viss uppgift. Skriv den anledningen i en form som kan kontrolleras. “Använd den nyare modellen” anger en åtgärd; det definierar inte den förväntade nyttan.
NIST:s AI RMF-översikt beskriver övervägande av tillförlitlighet över design, användning och utvärdering av AI-system.[1] Vår tillämpning av den principen är att hålla utvärderingen kopplad till ändringen. Ett tidigare godkännandebeslut bör inte tyst bli bevis för en konfiguration som aldrig var en del av testet.
Ange också vad som måste förbli acceptabelt. Om arbetsflödet exporterar strukturerad data måste exporten fortfarande uppfylla sitt mottagaravtal. Om granskare är beroende av källreferenser måste referenserna fortfarande stödja svaret. Dessa villkor hör hemma bredvid den önskade förbättringen, inte i en separat bortglömd checklista.
Jämför samma arbete
Använd den behållna inmatningsuppsättningen för den gamla och kandidatkonfigurationen. Använd samma granskningskriterier. Spela in förändringar i utdata som är viktiga för uppgiften, inklusive nya fel. En utvärderare ska inte behöva gissa om ett gynnsamt resultat kom från uppgraderingen eller från att byta ut de svåra testinmatningarna.
MLCommons definierar inferensbenchmarks med specificerade arbetsbelastningar och kvalitetsvillkor.[2] Den överförbara lärdomen för en intern granskning är vikten av villkor, inte en rättighet att låna ett externt prestandaresultat. Mät den faktiska arbetsflödet och dokumentera hur det kördes.
Håll korrekthetsgranskning separat från tidsmätning. Ett svar som kommer snabbare men utelämnar en nödvändig punkt uppfyller inte acceptanskriteriet. Ett längre svar som inte tillför någon ytterligare användbar bevisning bör inte räknas som en förbättring bara för att det finns mer text att visa.
Använd en post med plats för oenighet. Om två granskare tolkar ett resultat olika, bevara det omtvistade exemplet och lös acceptanskriteriet. Att genomsnittsbortse från oenigheten kan dölja en tvetydighet i själva uppgiften.
Bestäm innan du expanderar ändringen.
Granskningen kan ge ett snävt beslut: acceptera kandidaten för det testade arbetsflödet, upprepa ett namngivet test eller behålla den befintliga konfigurationen. Beskriv bevisen bakom beslutet och de begränsningar som kvarstår. En lyckad prövning för en dokumentuppsättning bör inte beskrivas som godkännande för varje applikation på servern.
Definiera återställningsvägen innan utrullning. Namnge vem som kan fatta beslutet och vilka bevis som skulle utlösa det. Håll proceduren tillräckligt specifik för att kunna genomföras under press. Vår medföljande artikel om modellvalsposten förklarar varför exakt kandidatidentitet är viktig här.
Översikten över företagsplattformen kan hjälpa till att rama in diskussionen om distribution. Uppgraderingsbeslutet bör fortfarande kopplas till en observerad uppgift, dess acceptansregel och en post som en annan person kan granska.
Referenser
- NIST. AI Risk Management Framework. Hämtad 2026-09-12.
- MLCommons. MLPerf Inference: Datacenter. Hämtad 2026-09-12.