Eine schlechte KI-Architektur schlägt immer ein gutes Modell.

Solange die Architektur nicht stimmt, bleibt selbst das beste Modell unter seinen Möglichkeiten. Nicht weil ihm die Fähigkeiten fehlen, sondern weil das kaputte System drumherum gegen es arbeitet. Wenn die Ergebnisse also enttäuschen, geben die meisten Teams dem Modell die Schuld. Das löst so gut wie nie das eigentliche Problem.

Ein Modell, das in einer kaputten Architektur läuft, liefert konstant zu wenig, egal wie leistungsfähig es ist.

Der Mythos vom besseren Modell

Wenn die Ergebnisse enttäuschen, ist der Reflex, dem Modell die Schuld zu geben: auf die neueste Version upgraden, Anbieter wechseln, ein größeres Context Window hinzufügen. Das löst fast nie das eigentliche Problem, denn die Architektur bestimmt die Standardeinstellungen. Wird eine Ausgabe nicht gegen eine Quelle geprüft, vertraut irgendwann jemand einer falschen Antwort, egal welches Modell sie produziert hat. Ist der Kostenverlauf pro Durchlauf nicht sichtbar, überrascht die Rechnung am Monatsende jemanden, egal wie effizient das Modell selbst ist.

Das Modell in einer kaputten Architektur zu wechseln, ändert nur, auf welche Art genau sie kaputtgeht.

KI spiegelt die Disziplin der Person, die sie nutzt. Die falsche Architektur verstärkt schlechte Disziplin, statt sie zu korrigieren.

Was die Architektur tatsächlich kontrolliert

Ein System, das an ein einziges Modell gebunden ist, hat ein Verfallsdatum, denn jeder Anbieter wird irgendwann überholt, und ein System ohne Fallback-Route bricht an dem Tag zusammen, an dem die primäre Route ausfällt. Ein System ohne Verifizierungsschritt vertraut allem, was zurückkommt, und der Fehler zeigt sich erst, wenn er beim Kunden ankommt. Ein System ohne Kostentransparenz kann eine Fünf-Cent-Abfrage nicht von einer Fünf-Dollar-Abfrage unterscheiden, bis die Rechnung eintrifft. Nichts davon ist die Schuld des Modells. All das ist eine Entscheidung, die jemand über das System drumherum getroffen hat, oder häufiger: nicht getroffen hat.

Die Modellqualität spielt am Rande immer noch eine Rolle. Aber ein gutes Modell in einer kaputten Architektur halluziniert trotzdem lautlos, kostet trotzdem mehr, als jemand getrackt hat, und hört trotzdem auf zu funktionieren, sobald der Anbieter eine API ändert, die niemand im Blick hatte.

Warum trotzdem dem Modell die Schuld gegeben wird

Ein Modell auszutauschen ist eine Änderung in einer Zeile und fühlt sich befriedigend nach Handeln an. Die Architektur drumherum zu reparieren bedeutet, dass sich jemand mit den unbequemen Fragen auseinandersetzen muss: Was passiert, wenn dieser Call fehlschlägt, wer prüft die Ausgabe, bevor sie beim Kunden ankommt, was kostet das pro Durchlauf und wer behält das im Auge. Diese Fragen sind in einer Demo weniger sichtbar, also werden sie aufgeschoben, und das Modell bekommt die Schuld für ein Problem, das es nicht verursacht hat.

The ODB Way

Bei ODB Growth ist das Modell eine Einstellung, kein Fundament. Jede Call-Site deklariert ihren Wire Contract und die minimale Fähigkeit, die sie braucht, die Ausgabe wird gegen eine Quelle geprüft statt blind vertraut, und die Kosten pro Durchlauf sind im System sichtbar statt als Überraschung auf einer Rechnung zu landen.

Diese Architektur macht das Modell austauschbar, ohne alles neu schreiben zu müssen, und sie macht die Ergebnisse auch vorhersehbar, egal welcher Anbieter dieses Quartal gerade vorne liegt. Reparieren Sie das System, in dem das Modell läuft, und die Wahl des Modells entscheidet nicht mehr darüber, ob das Projekt funktioniert.