Die Risiken des Open-Source-Modells liegen zunächst auf der Zugriffsebene

In den letzten Tagen gab es eine Diskussion darüber, ob Open-Source-Modelle von der Verschärfung der US-Politik betroffen sein werden. Das erste, was sich in der Technik ändert, sind nicht die Modellfunktionen, sondern die Standardzugänglichkeit. Das Modell ist noch da, ebenso die Papiere. Was als erstes wirklich zittert, sind die Pull-Adresse, die Mirror-Quelle, die Hosting-Plattform, die Lizenzbedingungen und die regionale Verfügbarkeit. Das erste, was Menschen, die Zugangsarbeit leisten, oft begegnet, ist nicht „das Modell ist nicht stark genug“, sondern „können wir es heute noch stabil hinbekommen?“

Die Standarderreichbarkeit wird zunächst schlechter

In der Vergangenheit war das ärgerlichste Problem beim Modellzugriff: „Gestern konnte das gleiche Modell heruntergeladen werden, aber heute erhielt es plötzlich eine 403.“ Diese Art von Änderung sieht aus wie eine kleine Schwankung in der Lieferkette, bringt aber tatsächlich die gesamte Verbindung in einen instabilen Zustand: Der Gewichts-Download muss erneut versucht werden, die Bildquelle muss gewechselt werden, die Prüfsumme muss neu berechnet werden, das Bereitstellungsbild muss neu gepackt werden und auch der Cache im CI wird ungültig. Oberflächlich betrachtet wird nur der Schritt des Erhaltens des Modells spröde gemacht, tatsächlich wird dem System jedoch die Prämisse der „Benutzerfreundlichkeit“ entzogen.

Das Open-Source-Modell wird oft so verstanden: „Nachdem der Code Open Source ist, wird er nicht mehr von anderen kontrolliert.“ Dieser Satz ist nur zur Hälfte richtig. Offener Quellcode bedeutet nicht, dass er standardmäßig zugänglich ist, und die Sichtbarkeit im Warehouse bedeutet nicht, dass die Produktionsumgebung stabil gestartet werden kann. Wer hostet es, in welcher Region existiert es, ob sich die Lizenz geändert hat und ob es Einschränkungen bei der Downloadhäufigkeit gibt. Sobald diese Details durch die Plattform, Richtlinien oder Geschäftsbedingungen blockiert werden, sieht das Team nicht „das Modell verschwindet“, sondern „Dinge, die leicht verfügbar waren, beginnen sich zu einer Infrastruktur zu entwickeln, die gewartet werden muss.“

Die Modellschnittstelle wird bis zur Systemgrenze vergrößert

Als ich in der Vergangenheit alle Details zum Modellrouting aufschrieb, war es am schwierigsten zu sammeln, dass die Punktzahl nicht um zwei oder drei Punkte daneben lag, sondern dass die Modellschnittstelle nicht stabil genug war. Sobald eine Basis ersetzt wird, ändern sich die Eingabeaufforderungsgewohnheiten, die Ausgabestruktur, das Tool-Aufrufformat und das Verhalten im langen Kontext entsprechend. Der Modellname scheint sich nicht geändert zu haben, aber der Parser, der Auswertungssatz, das Wiedergabeprotokoll und die Fehlerbehandlung im System müssen neu ausgeführt werden. Was in diesem Moment am leichtesten aufgedeckt wurde, war, dass das System „ein bestimmtes Modell“ mit „einer bestimmten Fähigkeit“ verwechselte.

Dies ist auch der am meisten übersehene Bereich in Diskussionen über Open-Source-Modelle. Was wirklich wertvoll ist, ist nicht der Name selbst, sondern die Menge an ersetzbaren Funktionen, die er bieten kann: Vervollständigung, Klassifizierung, Extraktion, Dialog, Tool-Aufruf, lange Artikelzusammenfassung und Codegenerierung. Solange die Zugriffsschicht diese Funktionen an bestimmte Modelle bindet, werden alle nachfolgenden Änderungen zu Migrationskosten führen. Wird die Schnittstellenschicht hingegen zunächst zu einem stabilen Vertrag verdichtet, kann die Basis wie eine Abhängigkeit ersetzt werden und das Risiko ist nur begrenzt begrenzt.

Routing und Fallback sind wichtiger als Substantive

Unabhängig davon, ob das Open-Source-Modell „versiegelt“ wird oder nicht, hängt die Auswirkung auf das endgültige System normalerweise nicht vom Namen des Modells ab, sondern davon, ob es einen Ausweg gibt. Wenn ein Team alle Aufgaben auf ein einziges Remote-Modell überträgt, führen alle geografischen Einschränkungen, Zugangsbeschränkungen oder Änderungen in den Geschäftsstrategien direkt zu Betriebsunterbrechungen. Im Gegenteil: Solange lokal ausführbare Modelle, Backup-Hosting-Quellen, Modellpools unterschiedlicher Fähigkeitsstufen und wiederholbare Evaluierungssätze vorhanden sind, erhöhen externe Einschränkungen bestenfalls die Umstellungskosten und führen nicht dazu, dass das System sofort nicht mehr verfügbar ist.

Daher ist es bei der Beurteilung auf Modellebene am besten, nicht nur zu fragen: „Welches Modell ist stärker“, sondern auch: „Kann diese Fähigkeitskette durch eine Basis ersetzt werden?“ Können die Gewichte in einem kontrollierbaren Lager aufbewahrt werden? Können Abhängigkeiten an feste Versionen gebunden werden? Können Routing, Caching, Wiedergabe und Rollback zu einem vollständigen Aktionssatz zusammengefasst werden? Diese Fragen liegen näher an der tatsächlichen Grenze als der Modellname. Das Risiko einer Modellbeschränkung wird nicht zuerst verschwinden, aber die Standarderreichbarkeit wird sich zuerst ändern; und was das System aufrechterhalten muss, ist niemals ein Modell, sondern eine Reihe von Funktionen, die kontinuierlich bereitgestellt werden können.