Nachdem das Open-Source-Modell eingeschränkt wurde, scheitert zunächst die Regressionsbeurteilung.

Sobald externe Beschränkungen auf ein Open-Source-Modell fallen, ist das erste, was kaputt geht, oft nicht die Frage: „Kann es noch heruntergeladen werden?“ aber „Können die Ergebnisse dieses Mal zusammen mit dem letzten Mal betrachtet werden?“ Der Modellname ist weiterhin vorhanden und die Schnittstelle kann weiterhin angeschlossen werden. Was wirklich schwierig wird, ist, dass die Urteilslinie zu driften beginnt: Der gleiche Satz an Aufforderungswörtern, die gleiche Menge an Proben und der gleiche Arbeitsablauf führen dazu, dass die Ergebnisse nicht mehr die gleiche Verhaltensverteilung aufweisen.

Auf dem Papier sieht das Ganze einfach aus, aber in der Praxis wird es sehr nervig. Das zuvor passable Ausgabeformat hat plötzlich etwas mehr Erklärung, die zuvor stabile Funktionsaufrufsequenz beginnt sich zu ändern, es gibt in einigen Bereichen eine zusätzliche Ebene von Richtlinienaufforderungen oder dieselbe Anfrage erhält unter verschiedenen Eingängen unterschiedliche Kontextlängen. Jeder einzelne von ihnen ist kein Zufall, aber zusammengenommen wird er das Urteil über die Rückkehr verwirren.

Was zuerst kaputt ging, war das Vergleichskaliber.

Viele Teams werden sich zunächst auf die Benchmark-Ergebnisse konzentrieren, aber die Ergebnisse eignen sich nur zur Angabe der ungefähren Fähigkeiten und nicht zur Erklärung, „ob das aktuelle Verhalten noch vom alten Prozess verfolgt werden kann“. Der eigentliche Ansatzpunkt, online zu gehen, besteht nicht darin, dass das Modell alleine läuft, sondern darin, dass es mit dem Parser, Tool-Aufrufen, Wiederholungsversuchen, Caching, Auditing und Routing zusammenarbeitet. Solange einer der Links das Kaliber ändert, verliert die Partitur ihre Referenzbedeutung.

Die typischste Situation ist, dass im Bewertungssatz keine Probleme erkennbar sind, die Kette jedoch online abzufallen beginnt. Die Testproben sind sauber genug und das Modell beantwortet Fragen sehr gut. Sobald jedoch echte Eingaben eingehen, kann eine geringfügige Felddrift nachfolgende automatisierte Schritte beeinflussen. Das Ergebnis sieht so aus, als ob „das Modell weiterhin verwendet werden kann“, aber tatsächlich bedeutet es „die Vergleichsmethode ist fehlgeschlagen“.

Die Baseline sollte entsprechend dem Workflow gespeichert werden

Um solche Änderungen zu unterdrücken, verlassen wir uns nicht darauf, weitere Listenrunden auszuführen, sondern die Basislinie in einen wiederholbaren Workflow umzuwandeln. Die Eingabe muss eine Version haben, die Ausgabe muss ein Schema haben, die Tool-Antwort muss abspielbar sein und fehlgeschlagene Beispiele müssen den ursprünglichen Kontext beibehalten. Nur so können wir nach dem Wechsel auf andere Modelle, andere Regionen und andere Strategien erkennen, ob die Abweichung im Modell selbst oder in den vorderen und hinteren Gliedern liegt.

Diese Art von Grundlinie hat die größte Angst, nur eine Punktzahl und eine Schlussfolgerung zu speichern. Ergebnisse werden verwendet, um Menschen zu trösten, Schlussfolgerungen werden verwendet, um Berichte zu schreiben, aber die wirklich nützlichen Details fehlen. Sobald die Einschränkungen später verschärft werden, kann das Team nur noch die Proben auffüllen, das Kaliber auffüllen und die abnormalen Grenzen auffüllen, was einer Aufteilung der Vergleichsarbeit, die in einem Durchgang hätte abgeschlossen werden können, in mehrere Nacharbeitsrunden gleichkommt.

Der wahre Preis der Migration besteht darin, das Vertrauen wiederherzustellen

Nachdem das Modell eingeschränkt wurde, sieht die Migrationsaktion so aus, als würde man zu einem verfügbaren Element wechseln, aber sie stellt tatsächlich das Vertrauen wieder her, dass „dieser Prozess relativ stabil ist“. Vertrauen entsteht nicht durch einen einzigen erfolgreichen Anruf, sondern durch eine Reihe von Vergleichsergebnissen, die wiederholt überprüft werden können. Ohne diese Ergebnismenge wäre es nur vorübergehend lauffähig, wenn wir in die Vergangenheit wechseln würden; Mit dieser Ergebnismenge läge es im kontrollierbaren Bereich, wenn wir in die Vergangenheit wechseln würden.

Aus diesem Grund haben einige Teams oberflächlich den Austausch abgeschlossen, intern müssen sie jedoch noch lange warten, bis sie den Mut haben, ihre Kapazitäten zu erhöhen. Was wirklich feststeckt, ist nicht die Zugriffsaktion, sondern die Frage, ob die wichtigsten Grenzen des alten Prozesses im neuen Modell noch gelten. Solange diese Frage nicht eindeutig beantwortet ist, ist jede Aussage, dass „die Migration abgeschlossen ist“, nur eine inszenierte Aussage.

Nur die Teile, die für den Test geeignet sind, sind einen Nachbau wert

Nicht alle Szenarien sind es wert, die Regressionskette so schwer zu gestalten. Ad-hoc-Gespräche, einfache Generierung und einmalige Zusammenfassungen haben lose Grenzen und übermäßige Konstruktion ist Zeitverschwendung. Sobald das Modell jedoch beginnt, an der Codegenerierung, der Informationsextraktion, Routing-Entscheidungen und der Tool-Ausführung mitzuwirken, ist die Regressionsbeurteilung nicht länger ein Beiwerk, sondern ein Teil des Arbeitsablaufs.

Äußere Zwänge können diesen Unterschied verstärken. Ob es weiterhin verwendet werden kann, ist meist nur die oberflächlichste Schicht; Was wirklich darüber entscheidet, ob das Team stabil sein kann, ist, ob es eine stabile Methode gibt, um die neuen Ergebnisse zum Vergleich mit der alten Basislinie zu vergleichen. Sobald der Vergleich hergestellt ist, handelt es sich bei der Migration lediglich um ein technisches Problem. Sobald der Vergleich fehlschlägt, werden alle nachfolgenden Urteile ins Wanken geraten.