Een slechte AI-architectuur wint het altijd van een goed model.

Zolang je de architectuur niet fixt, blijft zelfs het beste model onder de maat presteren. Niet omdat het niet capabel genoeg is, maar omdat het kapotte systeem eromheen tegen het model werkt. Dus als de resultaten tegenvallen, geeft het team al snel het model de schuld. Dat lost het echte probleem bijna nooit op.

Een model dat draait binnen een kapotte architectuur blijft structureel onderpresteren, hoe capabel het ook is.

De mythe van het betere model

Als resultaten tegenvallen, is het instinct om het model de schuld te geven: upgraden naar de nieuwste versie, overstappen naar een andere provider, een groter context window toevoegen. Dat lost het echte probleem bijna nooit op, want de architectuur bepaalt de defaults. Als output niet tegen een bron gecontroleerd wordt, vertrouwt iemand uiteindelijk een fout antwoord, ongeacht welk model het produceerde. Als kosten niet per run zichtbaar zijn, verrast de rekening aan het eind van de maand iemand, ongeacht hoe efficiënt het model zelf is.

Van model wisselen binnen een kapotte architectuur verandert alleen op welke specifieke manier het kapotgaat.

AI weerspiegelt de discipline van de gebruiker. De verkeerde architectuur versterkt slechte discipline in plaats van die te corrigeren.

Wat de architectuur echt bepaalt

Een systeem dat vastzit aan één model heeft een houdbaarheidsdatum, want elke provider wordt vroeg of laat ingehaald, en een systeem zonder fallback-route breekt op de dag dat de primaire route dat doet. Een systeem zonder verificatiestap vertrouwt alles wat terugkomt, en de fout komt pas aan het licht zodra die een klant bereikt. Een systeem zonder kostenzichtbaarheid kan het verschil niet zien tussen een query van vijf cent en een van vijf dollar, totdat de factuur binnenkomt. Niets daarvan is de schuld van het model. Het is allemaal een beslissing die iemand heeft genomen, of vaker: niet heeft genomen, over het systeem eromheen.

Modelkwaliteit telt nog steeds mee, in de marge. Maar een goed model in een kapotte architectuur blijft stilletjes hallucineren, blijft meer kosten dan iemand bijhield, en stopt alsnog met werken op de dag dat de provider een API aanpast waar niemand op lette.

Waarom het model toch de schuld krijgt

Een model wisselen is een regel code en een bevredigend gevoel van actie. De architectuur eromheen fixen betekent dat iemand moet stilstaan bij de ongemakkelijke vragen: wat gebeurt er als deze aanroep faalt, wie checkt de output voordat die een klant bereikt, wat kost dit per run en wie houdt dat in de gaten. Die vragen zijn minder zichtbaar in een demo, dus worden ze uitgesteld, en krijgt het model de schuld van een probleem dat het niet veroorzaakt heeft.

The ODB Way

Bij ODB Growth is het model een instelling, geen fundament. Elk call-punt legt zijn wire contract vast en de minimale capaciteit die het nodig heeft, output wordt tegen een bron gecontroleerd in plaats van op vertrouwen aangenomen, en kosten per run zijn zichtbaar in het systeem in plaats van een verrassing op de factuur.

Die architectuur maakt het model verwisselbaar zonder herschrijven, en zorgt ook voor voorspelbare resultaten, ongeacht welke provider dit kwartaal toevallig voorop loopt. Fix het systeem waarin het model draait, en de keuze van het model bepaalt niet langer of het project werkt.