Back home

Nachdem das Open-Source-Modell eingeschränkt wurde, muss zunächst die modellneutrale Schicht unabhängig sein.

Es spielt keine Rolle, ob das Modell geändert werden kann. Was wirklich problematisch ist, ist das Standardverhalten, das im Code fest codiert ist.

Sobald ein Open-Source-Modell eingeschränkt wird, ist das erste, was offengelegt wird, oft nicht der Download-Eintrag, sondern die Standardannahmen im Code. Der Modellname wurde geändert, aber die Schnittstelle ist immer noch vorhanden, aber der Geschäftsprozess stimmt nicht mehr mit dem alten Verhalten überein: Ausgabeformat, Funktionsaufrufsequenz, Ablehnungston, Kontextlänge, Sampling-Parameter, jeder von ihnen kann einzeln angezeigt werden, aber wenn man sie zusammenstapelt, wird der gesamte Link gezogen.

Es ist normalerweise schwierig, ein solches Problem als architektonisches Problem zu betrachten. Während der Entwicklungsphase habe ich nur „can run“ gesehen. Nachdem ich online gegangen war, stellte ich fest, dass die Modellauswahl bereits in die Geschäftslogik geschrieben war. Einige Felder passen sich nur an ein Rückgabeformat an, einige Wiederholungsversuche erkennen nur eine Ablehnungsmethode und einige Ausnahmefallbacks greifen standardmäßig auf das Originalmodell zurück, um eine längere Erklärung zu geben. Nachdem die Beschränkungen eingeführt worden waren, wurden all diese versteckten Haufen freigelegt.

Das Standardverhalten bindet das Modell an das Unternehmen

In der Zugriffsphase wird das Modell häufig als Hinzufügen eines SDK, Verbinden einer API und Hinzufügen eines Eingabeaufforderungsworts betrachtet. Nach der Verbindung ist es am schwierigsten, nicht den Anruf selbst zu bereinigen, sondern die Zweige, die um das Standardverhalten herum entstanden sind. Ob die Ausgabe ausschließlich JSON sein soll, ob der Toolaufruf nach einem Fehler erneut versucht werden soll, wo überlange Eingaben abgeschnitten werden sollen und auf welcher Ebene Risikokontrollaufforderungen platziert werden sollen. Diese Probleme fallen oft in den Geschäftskodex.

Sobald ein Open-Source-Modell eingeschränkt oder aus den Regalen entfernt wird oder das lokale Image und die Upstream-Version beginnen, sich zu verzweigen, sind diese Standardverhaltensweisen nicht mehr zuverlässig. Oberflächlich betrachtet wird nur das Modell geändert, aber im Grunde ist es notwendig, gleichzeitig das Parsing, die Überwachung, das Rollback und das Testen zu ändern. Das Schwierigste daran ist, nicht noch ein paar Anpassungszeilen zu schreiben, sondern dass die ursprünglichen Annahmen nicht von Anfang bis Ende explizit markiert werden.

Die Rolle der neutralen Schicht besteht darin, die impliziten Annahmen zu verbreiten

Modellneutrale Schichten sind nicht aus Abstraktionsgründen abstrakt. Seine Funktion ist sehr einfach: Platzieren Sie Eingabeaufforderungswörter, Schemaüberprüfung, Routing, Wiederholungsversuche, Downgrade, Protokolle und Auswertung an einem Ort, sodass Modellunterschiede zunächst dieselben Grenzen überschreiten. Selbst wenn das Modell durch Cloud, Open Source, lokale Inferenz oder andere Anbieter ersetzt wird, erhält das Unternehmen auf diese Weise weiterhin einen einheitlichen Input- und Output-Vertrag.

Sobald diese Schicht etabliert ist, werden viele Dinge, die ursprünglich unklar waren, plötzlich klar. Welche Felder erforderliche Werte sind, welche Felder nur Modellpräferenzen sind, welche Fehler wiederholt werden können, welche Fehler zurückgesetzt werden müssen, welche Kontexte abgeschnitten werden und welche Indikatoren wirklich verglichen werden können, ändert sich von „durch Erfahrung gespeichert“ zu „durch Schnittstellen eingeschränkt“. Die durch das eingeschränkte Modell verursachten Auswirkungen werden nicht mehr direkt in den Geschäftscode eingetragen, sondern zunächst in die neutrale Schicht.

Nicht alle Szenen sind dieser Ebene würdig

Bei einigen Szenen müssen die Schichten gar nicht so dick sein. Einmalige Zusammenfassungen, temporäre Generierungen, interne Experimente und vollständig gesperrte Werkzeugketten für einzelne Modelle reichen aus, um das Modell an diesen Stellen zu verbinden. Der Aufbau einer komplett neutralen Schicht für einen kurzlebigen Prozess wird die Kosten im Voraus nur übersteigen.

Diese Ebene wird benötigt, wenn das Modell wirklich an der geschäftlichen Beurteilung teilnimmt. Zum Beispiel Extraktion, Routing, Tool-Ausführung, Kundendienstreaktion, Überprüfungsunterstützung und Batch-Umschreiben. In diesen Szenarien ist das Modell kein Spielzeug, sondern Teil des Prozesses. Solange sich das Modell ändert oder äußere Zwänge einen bestimmten Eingang destabilisieren, ist die neutrale Schicht keine Dekoration, sondern eine Wand, die den Wandel innerhalb der Grenzen hält.

Was wirklich dazu führt, dass das Open-Source-Modell eingeschränkt wird, ist nicht die Alternative eines bestimmten Anbieters, sondern ob das Team „Modellunterschiede“ als erstklassige Bürger behandelt. Je früher das Standardverhalten im Code verbreitet wird, desto weniger passiv wird es bei späteren Modelländerungen sein. Das Modell kann sich ändern, aber die Grenzen können nicht folgen.