Woher unsere Modelle kommen und was wir prüfen
Eine Bestandsaufnahme ist eine langweilige Übung, die gelegentlich eine unangenehme Zahl hervorbringt. Unsere war elf: elf Modell- und Embedding-Artefakte, aus öffentlichen Registries in Systeme gezogen, die wir betreiben — bei vieren davon konnten wir die Herkunft benennen.
Die Annahme, die wir getroffen hatten
Wir liefern Systeme um Modelle herum, statt sie zu trainieren. Daraus folgte, so dachten wir, dass Fragen zu Trainingsdaten den Organisationen gehören, die trainieren. Das ist eine vernünftige Arbeitsteilung, und sie überspringt still einen Schritt.
Der Schritt ist, dass wir trotzdem Artefakte ziehen. Embedding-Modelle, Reranker, ein kleiner Klassifikator, Tokenizer: Jedes kommt aus einer Registry, wird in einen Prozess geladen, den wir betreiben, und verarbeitet Kundendaten. Das ist eine Lieferkette, ob wir sie so nennen oder nicht.
Was die Bestandsaufnahme ergab
Elf Artefakte über die Systeme hinweg, die wir betreiben. Vier hatten eine festgelegte Version und eine dokumentierte Quelle. Drei waren auf ein bewegliches Tag festgelegt, womit das Getestete und das Laufende nur per Konvention zusammenhängen. Vier wurden zur Container-Bauzeit ganz ohne Festlegung gezogen.
Nichts war schiefgegangen. Das gehört deutlich gesagt, denn der Befund ist kein Vorfall, sondern das Fehlen einer Kontrolle — und solche bleiben viel leichter bestehen, weil nichts auf sie aufmerksam macht.
Warum die Forschung uns hinsehen ließ
Bowen und Kollegen veröffentlichten in jenem August eine Arbeit dazu, wie Datenvergiftung in Sprachmodellen skaliert. Sie untersuchen das Verhältnis zwischen der Menge vergifteter Daten und der Wirkung auf das entstehende Modell und finden, dass größere Modelle in den gemessenen Bedingungen nicht von sich aus widerstandsfähiger waren.
Wir sind nicht in der Lage, so etwas in einem heruntergeladenen Artefakt zu erkennen — und genau deshalb hat es unser Verhalten geändert. Wenn wir nicht prüfen können, was wir laden, betreffen die verbleibenden Kontrollen nur die Herkunft und das, was es anfassen darf.
| Kontrolle | Wo wir sie anwenden |
|---|---|
| Festlegung auf einen Inhalts-Hash | Jedes Modellartefakt, ohne Ausnahme |
| Spiegelung in eigene Registry | Alles auf einem Produktionspfad |
| Quelle und Lizenz festhalten | Alle elf, in einer Datei |
| Kein Netz aus dem Inferenzprozess | Alles im Eigenbetrieb |
Was wir geändert haben
Jedes Artefakt ist auf einen Digest statt auf ein Tag festgelegt und in eine Registry gespiegelt, die wir kontrollieren. Das ist nicht raffiniert und beseitigt den Fehler, dass das im März Laufende nicht das im Januar Getestete ist.
Die Inferenzprozesse haben ihren ausgehenden Netzzugang verloren. Ein selbst betriebenes Modell muss das Internet nicht erreichen, um eine Frage zu beantworten, und diese Möglichkeit zu entfernen heißt, dass ein sich schlecht verhaltendes Artefakt erheblich weniger zur Verfügung hat als eines, das eine Verbindung öffnen kann.
Die Lizenzhälfte davon
Dieselbe Bestandsaufnahme diente einem zweiten Zweck, den wir ebenfalls vor uns hergeschoben hatten. Bei vier der elf konnte niemand im Projekt die Lizenzbedingungen nennen, und eines hatte Bedingungen, die einen von einem Kunden angefragten Anwendungsfall einschränkten.
Das ist ein kaufmännisches und kein Sicherheitsrisiko, und es schlägt weit eher zu. Wir halten die Lizenz heute neben dem Digest fest, was beim Ziehen nichts kostet und eine Frage beantwortet, die sonst mitten in einer Vertragsverhandlung auftaucht.
Was wir nicht können
Wir können Gewichte nicht sinnvoll prüfen. Es gibt keine praktikable Kontrolle an einem heruntergeladenen Modell, die uns sagen würde, ob es sich bei irgendeiner seltenen Eingabe schlecht verhält — und etwas anderes zu suggerieren wäre das schlechteste Ergebnis dieses Beitrags.
Unsere Haltung betrifft daher die Folgen, nicht die Erkennung. Ein Modell läuft ohne Netz, ohne Zugangsdaten und ohne Werkzeuge, seine Ausgabe durchläuft dieselbe Validierung wie jede andere nicht vertrauenswürdige Eingabe, und was es beeinflussen kann, ist durch den Entwurf begrenzt statt durch Vertrauen.
Was wir Anbieter fragen
Drei Fragen, und wir stellen sie auch gehosteten Anbietern. Welche Version rufe ich auf und kann ich sie festlegen? Welche Vorlaufzeit gilt für ihre Abkündigung? Und wie ist Ihre Praxis bei Verhaltensänderungen innerhalb einer Version?
Die dritte Frage bekommt die unbefriedigendsten Antworten und ist betrieblich die wichtigste: Ein System, das gegen ein Modell justiert wurde, das sich still darunter verändert, ist ein System, dessen Referenzset Geschichte misst.
Was wir nicht behaupten
Wir behaupten nicht, Festlegen und Spiegeln machten ein Artefakt vertrauenswürdig. Sie machen es konsistent, was eine andere Eigenschaft ist — und ein konsistent kompromittiertes Artefakt ist genauso kompromittiert wie ein inkonsistentes.
Wir behaupten auch nicht, elf sei viel oder wenig. Es ist, was wir hatten, wir hatten vorher nicht gezählt, und der Wert der Übung lag vor allem darin zu entdecken, dass sieben davon nicht festgelegt waren, nicht in der Summe.