Nadat het Chinese open source-model aan banden is gelegd, is het eerste waar we ons op moeten richten de versie en het evaluatiekaliber.

Als dergelijke beperkingen eenmaal zijn opgeheven, is het eerste wat vaak niet lukt de vraag ‘Kan het nog steeds worden gedownload?’ maar “kan het nog steeds gebaseerd zijn op dezelfde reeks scores?”

Het model zelf bestaat nog steeds en de spiegeling kan worden gesynchroniseerd, maar het probleem begint te verschuiven van de ingang naar de vergelijking. Een versie die vandaag de dag goed werkt, zal op een andere machine kleine verschillen vertonen als gevolg van ‘weight slicing’, de tokenizer-versie, gevolgtrekkingsparameters of spiegelvertragingen. Als je alleen maar naar elke uitvoer kijkt, lijkt het erop dat deze nog steeds werkt; zodra het weer in de regressieset wordt geplaatst, begint de curve zich te verspreiden. Vroeger hoefde je alleen maar naar een totaalscore te kijken om te beslissen of je zou upgraden, maar nu moet je eerst uitpakken “of deze verandering uit het model of de servicestack komt”.

Het echte probleem dat door beperkingen wordt veroorzaakt, zit niet in de downloadactie zelf, maar in het versnipperen van vergelijkingsrelaties. In het verleden hoefde je je alleen op één upstream-versie te concentreren, maar nu zijn er vaak tegelijkertijd officiële bronnen, spiegelbronnen, interne caches, gekwantiseerde versies en tijdelijke terugdraaiversies. Elke lijn kan worden uitgevoerd, maar de resultaten delen niet langer dezelfde basislijn. Zodra de evaluatieset is gevorkt, zal het team snel een gemeenschappelijke taal verliezen: R&D zegt dat deze versie is verbeterd en het product zegt dat de online-ervaring niet is veranderd. Probleemoplossers moeten eerst bevestigen of het model is veranderd of de gevolgtrekkingsomgeving is veranderd.

Het lastigste aan dit soort vorken is dat deze zich niet meteen als een storing manifesteren. Op de eerste dag was er slechts een verschil van 0,3 punt tussen de twee omgevingen. Op de tweede dag begon een bepaald lang tekstfragment te drijven. Nadat ik op de derde dag terugging, ontdekte ik dat de oude resultaten niet konden worden gereproduceerd. In dit stadium gaat de discussie niet langer over “kunnen we het model krijgen?” maar “of wat we krijgen hetzelfde is.”

Wat eigenlijk als eerste moet worden afgesloten, is niet de downloadingang, maar de basislijn. De volgende zaken moeten in ieder geval vastgelegd worden:

• De hash, tokenizerversie, kwantiseringsmethode en inferentieparameters van het modelbestand.
• Evaluatieset, promptwoorden, bemonsteringsparameters en naverwerkingslogica.
• Inferentie-inkapseling gedeeld door online services en offline regressie om te voorkomen dat de twee sets implementaties afdrijven.
• Behoud het oude beeld en de basislijn bij het terugdraaien, zonder te vertrouwen op geheugenreconstructie.

Deze dingen lijken misschien triviaal, maar zodra de toegang tot modellen wordt beperkt, is deze laag van trivialiteit echt waardevol. Zonder hen kan het team alleen maar gokken op de volgende upgrade met “deze keer ziet het er goed uit”; met hen kunnen ze op zijn minst bevestigen of het probleem in het model, de inferentiestapel of de dataset zelf ligt.

Dus wanneer deze kwestie uiteindelijk onder het project valt, zal het oordeel heel eenvoudig worden: of het model kan worden verkregen is nog maar het begin; Of dezelfde set ingangen, dezelfde set parameters en dezelfde set samples continu op dezelfde lijn kan worden uitgevoerd, bepaalt of deze nog steeds stabiel kan worden gebruikt. Zolang het vergelijkende kaliber blijft bestaan, is er nog steeds speelruimte in het model; zodra het kaliber eerst uiteenloopt, zullen daaropvolgende vervanging, terugdraaien en probleemoplossing duurder worden.