Probabilistische Grenze

COADF P-1 legt das Minimum fest: Eine probabilistische Komponente liefert einen Wert zusammen mit einer Konfidenz und der Methode, mit der der Wert gewonnen wurde, nie einen nackten Wert, und sie erreicht nie unmittelbar eine Ausgabe. Dieses Muster handelt von der zweiten Hälfte, und genau diese Hälfte geht in Implementierungen verloren. Die Antwort eines Modells darf in das System gelangen. Was sie nicht darf, ist, auf irgendeinem Weg zu dem zu werden, was das System als feststehend behandelt.

Drei Dinge müssen gleichzeitig gelten:

• Die Ausgabe hat einen eigenen Typ. Ein Vorschlag und ein maßgeblicher Datensatz sind verschiedene Typen, verschiedene Tabellen oder verschiedene Nachrichten. Code, der das eine hält, kann es nicht dort übergeben, wo das andere erwartet wird, ohne einen expliziten Schritt, den jemand prüfen kann.
• Die Grenze validiert zur Laufzeit. Der Vertrag wird geprüft, wenn die Antwort eintrifft, in dem Prozess, der sie empfängt, gleichgültig, was der Absender nach eigener Aussage geprüft hat.
• Die Herkunft reist mit dem Wert. Die Methode, das Modell und seine Revision, die Prompt-Revision und die Fundstelle in der Quelle bleiben über jeden Schritt hinweg angehängt, die Serialisierung eingeschlossen. Ohne sie kann P-4 nichts rekonstruieren und P-5 nichts offenlegen.

P-1 lässt die Komponente außerdem eine Konfidenz melden. Wie Konfidenz ausgedrückt, vergeben und verwendet wird, gehört zu P-2, das COADF nur als Prinzip veröffentlicht. Dieser Companion beschreibt es nicht, und nichts im Folgenden hängt davon ab.

Die Ausgabe eines Modells entsteht in einem Prozess, der sich nicht so aus seinen Eingaben reproduzieren lässt wie die Ausgabe eines Parsers: Sampling, Modellaktualisierungen und Prompt-Änderungen verschieben sie. Für einen Vorschlag ist das hinnehmbar, für eine Tatsache nicht. Das Risiko ist nicht, dass ein Modell manchmal falschliegt; alles liegt manchmal falsch. Das Risiko ist, die Fähigkeit zu verlieren, zu sagen, welche Werte woher stammen, denn jede spätere Kontrolle hängt davon ab. Ein Tor stoppt nur, was es sehen kann, eine Offenlegung benennt nur, was gekennzeichnet ist, und eine prüfende Person prüft nur, was noch auf seine Quelle verweist.

Der Verlust ist selten eine Entscheidung. Er geschieht in einer gewöhnlichen Codezeile: eine ORM-Entität, die aus dem JSON des Modells befüllt wird, weil die Feldnamen zufällig passten, ein Antwortmodell, das die Herkunft weglässt, weil niemand sie ergänzt hat, ein Batch-Import, der das Formular umgeht, in dem die Validierung lag. Das Muster existiert, damit sich diese Zeile nicht schreiben lässt, ohne dass es auffällt.

Isolation ist architektonisch, nicht zwingend physisch

Microservices sind nicht erforderlich. Die Eigenschaft gilt, wenn kein Codepfad der probabilistischen Seite erlaubt, ein maßgebliches Objekt zu erzeugen, und ein einzelner Prozess kann sie ebenso gut einhalten wie ein Netzwerk. Die Topologie wird aus eigenen Gründen gewählt (eine Inferenzlast getrennt skalieren, die Client-Bibliothek eines Anbieters isolieren, unabhängig deployen), und dann wird die Grenze in der gewählten Form gebaut. Die vier Abbildungen unten halten dieselbe Eigenschaft in vier Formen ein.

Dieselben vier Elemente in jeder Topologie

• Unterschiedliche Typen. Die probabilistische Seite kann einen Vorschlag konstruieren und sonst nichts. Der maßgebliche Datensatz wird nur von Domänencode gebaut, aus einem Vorschlag und etwas, das die probabilistische Seite nicht erzeugen kann.
• Laufzeitvalidierung auf jeder empfangenden Seite. Ein striktes Schema: nicht deklarierte Felder werden abgelehnt, keine Typumwandlung, geschlossene Vokabulare für kategoriale Werte, begrenzte Längen. In einer verteilten Topologie validiert jeder Empfänger, auch die Domänenseite, wenn der Absender der eigene Dienst ist: „Wir haben vor dem Senden validiert“ ist eine Aussage über ein anderes Deployable, womöglich über eine ältere Version davon.
• Herkunft im Vertrag. Deklariert, verpflichtend und von jedem Mapper und Serialisierer auf dem Weg nach außen erhalten.
• Ein expliziter Übernahmeschritt. Der einzige Weg vom Vorschlag zum maßgeblichen Datensatz ist eine Funktion, ein Endpunkt oder ein Befehl, der verlangt, was die probabilistische Seite nicht liefern kann. Für Werte, die ein Sprachmodell abgeleitet hat, verlangt der öffentliche Fence F-03 von COADF eine menschliche Prüfung, bevor sie eine veröffentlichte Ausgabe erreichen. Die Übernahme selbst wird in der Prüfspur festgehalten.

Deterministische Validierung um stochastische Ausgaben

Prüfungen, die nur den Wert lesen (seine Form, sein Vokabular, seine Einheit, die Bereiche, die die Domäne selbst festlegt), laufen, bevor ein Mensch ihn ansieht. Sie machen einen Wert nicht wahr. Sie machen einen unmöglichen Wert unmöglich, und zwar jedes Mal auf dieselbe Weise, worauf sich ein Mensch, der den Wert prüft, verlassen kann.

Durchsetzungsmöglichkeiten, von der schwächsten zur stärksten

Die meisten Systeme brauchen die ersten drei immer und die letzten beiden, wenn die probabilistische Komponente eigenständig deployt wird. Das Profil für Python und FastAPI setzt die ersten drei um; das Cloud-native-Profil ergänzt die letzten beiden.

• Oberflächen, die nur Vorschläge zeigen. Die Modellausgabe wird einem Menschen als Vorschlag angezeigt und nie als Wert gespeichert. Einfach und stark; die Nachvollziehbarkeit dessen, was vorgeschlagen wurde, geht verloren, es sei denn, auch die Vorschläge werden festgehalten.
• Ein gemeinsamer, sprachneutraler Vertrag (JSON Schema, Protocol Buffers) statt sprachnativer Modelle. Besser über Sprachgrenzen hinweg; die Frage der Strenge wandert ins Schema, wo über zusätzliche Eigenschaften und Formate ausdrücklich entschieden werden muss.
• Modi für strukturierte Ausgaben in Modell-APIs. Sie verringern fehlerhafte Antworten beim Produzenten. Sie entbinden den Konsumenten nicht von der Validierung, denn der Konsument kann nicht verifizieren, wie der Produzent konfiguriert war.
• Getrennte Speicherung für Vorschläge und Datensätze, zwei Tabellen oder zwei Speicher statt einer Tabelle mit Status. Aufwendiger, und die Trennung wird in jeder Abfrage sichtbar, die irgendjemand schreibt.

• Die Grenze steuert, wohin Modellausgaben gelangen können. Sie macht Modellausgaben nicht korrekt, und ein wohlgeformter falscher Wert besteht jede Prüfung in diesem Muster.
• Typtrennung stoppt Versehen, keine Absicht. Wer Schreibzugriff auf die Domäne hat, kann ein maßgebliches Objekt von Hand konstruieren; sichtbar wird das durch Code-Review und die Prüfspur.
• Dieses Muster sagt nicht, wann ein Vorschlag einen Menschen braucht oder wie Konfidenz ausgedrückt wird. Das gehört zu P-2 und P-3, die COADF nur als Prinzipien veröffentlicht.
• Validierung ist nur so gut wie der Vertrag. Ein freizügiges Schema, streng validiert, bleibt freizügig.