Nachdem Chinas Open-Source-Modell eingeschränkt wurde, müssen zunächst die Version und das Evaluierungskaliber abgezweigt werden.

Sobald solche Beschränkungen aufgehoben werden, ist die erste Frage, die normalerweise nicht beantwortet wird, nicht die Frage: „Kann es noch heruntergeladen werden?“ aber „kann es immer noch auf denselben Ergebnissen basieren?“

Das Modell selbst ist immer noch vorhanden und die Spiegelung kann synchronisiert werden, aber das Problem beginnt sich vom Eingang zum Vergleich zu verlagern. Eine Version, die heute gut funktioniert, weist auf einer anderen Maschine aufgrund von Gewichtsaufteilung, Tokenizer-Version, Inferenzparametern oder Spiegelungsverzögerungen geringfügige Unterschiede auf. Wenn man sich nur die einzelnen Ausgaben ansieht, sieht es so aus, als ob sie immer noch funktionieren. Sobald es wieder in den Regressionssatz aufgenommen wird, beginnt sich die Kurve auszubreiten. Früher musste man sich nur die Gesamtpunktzahl ansehen, um zu entscheiden, ob ein Upgrade durchgeführt werden sollte, aber jetzt muss man zuerst herausfinden, „ob diese Änderung vom Modell oder vom Service-Stack herrührt“.

Das eigentliche Problem, das durch Einschränkungen verursacht wird, liegt nicht im Download-Vorgang selbst, sondern in der Zerstörung von Vergleichsbeziehungen. Früher musste man sich nur auf eine Upstream-Version konzentrieren, heute gibt es jedoch häufig gleichzeitig offizielle Quellen, Spiegelquellen, interne Caches, quantisierte Versionen und temporäre Rollback-Versionen. Jede Zeile kann ausgeführt werden, die Ergebnisse weisen jedoch nicht mehr dieselbe Basislinie auf. Sobald der Evaluierungssatz gespalten ist, verliert das Team schnell eine gemeinsame Sprache: R&D sagt, dass diese Version verbessert wurde, und Produkt sagt, dass sich das Online-Erlebnis nicht geändert hat. Fehlerbehebungen müssen zunächst bestätigen, ob sich das Modell oder die Inferenzumgebung geändert hat.

Das Schlimmste an dieser Art von Fork ist, dass sie sich nicht sofort als Fehlfunktion bemerkbar macht. Am ersten Tag gab es nur einen Abstand von 0,3 Punkten zwischen den beiden Umgebungen. Am zweiten Tag begann eine bestimmte lange Textprobe zu driften. Nach dem Rollback am dritten Tag stellte ich fest, dass die alten Ergebnisse nicht reproduziert werden konnten. In diesem Stadium dreht sich die Diskussion nicht mehr um die Frage: „Können wir das Modell bekommen?“ sondern „ob das, was wir bekommen, dasselbe ist.“

Was wirklich zuerst heruntergefahren werden sollte, ist nicht der Download-Zugang, sondern die Baseline. Zumindest die folgenden Dinge müssen festgenagelt werden:

• Der Hash, die Tokenizer-Version, die Quantisierungsmethode und die Inferenzparameter der Modelldatei.
• Bewertungssatz, Eingabeaufforderungswörter, Probenahmeparameter und Nachbearbeitungslogik. – Von Online-Diensten gemeinsam genutzte Inferenzkapselung und Offline-Regression, um zu verhindern, dass die beiden Implementierungssätze voneinander abweichen.
• Behalten Sie beim Rollback das alte Image und die Grundlinie bei, ohne sich auf die Speicherrekonstruktion verlassen zu müssen.

Diese Dinge mögen trivial erscheinen, aber sobald der Modellzugriff eingeschränkt wird, ist es diese Ebene der Trivialität, die wirklich wertvoll ist. Ohne sie kann das Team nur auf das nächste Upgrade setzen und sagen: „Diesmal sieht es okay aus“; Mit ihnen können sie zumindest bestätigen, ob das Problem im Modell, im Inferenzstapel oder im Datensatz selbst liegt.

Wenn diese Angelegenheit schließlich dem Projekt zufällt, wird die Beurteilung sehr einfach: Ob das Modell erhalten werden kann, ist nur der Anfang; Ob derselbe Eingabesatz, derselbe Parametersatz und derselbe Probensatz kontinuierlich auf derselben Leitung ausgeführt werden können, bestimmt, ob er weiterhin stabil verwendet werden kann. Solange das Vergleichskaliber bestehen bleibt, besteht noch Spielraum im Modell; Sobald das Kaliber zuerst auseinandergeht, werden der anschließende Austausch, das Rollback und die Fehlerbehebung teurer.