Ga naar hoofdinhoud

AI-architectuur

AI raakt vrijwel elk werkblad. Om te voorkomen dat dat neerkomt op vijftien plekken die elk hun eigen aanroep doen, loopt alles via één gateway.

Eén gateway voor alle generatie

Elke AI-aanroep gaat door één serverside gateway. Die regelt:

  • Promptresolutie serverside. Aanroepende code geeft nooit prompttekst mee, alleen een sleutel uit een vaste lijst. De bijbehorende prompt wordt op de server opgezocht — met een eventuele tenant-specifieke variant, anders de standaardversie. Een client kan dus geen eigen instructies aan het model meegeven.
  • Modelkeuze per taaksoort. Zware redeneertaken krijgen het sterkste model; mechanisch werk zoals ontdubbelen, clusteren en labelen krijgt een sneller en goedkoper model. Die toewijzing staat centraal, niet verspreid over de code.
  • Bestendigheid. Time-outs per taaksoort, en opnieuw proberen uitsluitend bij tijdelijke storingen aan leverancierszijde — nooit na een time-out, want dat garandeert alleen maar een tweede time-out.
  • Budgetbewaking. Vóór elke aanroep wordt het verbruiksbudget van de tenant getoetst.
  • Verbruiksregistratie. Model, tokens en kosten per aanroep worden vastgelegd voor inzicht en kostentoerekening.

De grounding-keten

Zo komt een onderbouwde AI-bewering tot stand:

  1. Opknippen. Een geüpload document wordt verdeeld in samenhangende blokken van ongeveer 400 tokens, zo'n 300 Nederlandse woorden, met respect voor zins- en kopgrenzen. Eerder werd met kleinere fragmenten gewerkt; die bleken te versnipperd voor bruikbare synthese.
  2. Betekenis vastleggen. Elk blok krijgt een numerieke representatie van zijn betekenis, opgeslagen in dezelfde database.
  3. Zoeken, begrensd op aantal. Bij een AI-vraag worden de acht best passende blokken opgehaald. Er staat vandaag geen ondergrens op de gelijkenisscore. Een eerder gekalibreerde ondergrens is nooit in gebruik geweest: toen hij op twee echte dossiers werd nagemeten, nam hij daar 75 respectievelijk 100 procent van het bewijs weg. Welke waarde er wél hoort is een open vraag; tot die beantwoord is begrenst het aantal, niet een drempel.
  4. Alleen bronmateriaal. Het zoeken gebeurt over een afgeschermde weergave die uitsluitend aangeleverd bronmateriaal bevat. Eerder gegenereerde AI-output kan nooit als bewijs terugkomen — bewaakt met een eigen contracttest.
  5. Gecontroleerde verwijzing. Het model moet verwijzen naar de fragmenten die het daadwerkelijk kreeg. De server toetst elke verwijzing tegen die set. Een verwijzing die er niet in zat, wordt geweigerd of gemarkeerd.
  6. Vastleggen bij de bewering. Bestandsnaam, pagina en fragment worden meegeschreven, zodat de bronvermelding leesbaar blijft als het document later opnieuw wordt geïndexeerd.

Stap 5 is het verschil tussen "vraag het model om bronnen" en een controleerbare bewijsketen.

Latency en betrouwbaarheid

Serverless functies hebben een harde bovengrens van 60 seconden. Toen voor kwaliteitsredenen op een sterker maar trager model werd overgestapt, liepen zware generaties daar tegenaan: de functie werd afgebroken en de gebruiker kreeg een onbegrijpelijke fout.

Dat is structureel opgelost in plaats van door terug te gaan naar een zwakker model:

  • Streamen. Het antwoord komt binnen terwijl het geschreven wordt. Daarmee verdwijnt de time-outmuur én ziet de gebruiker voortgang.
  • Regelgewijze uitvoer. Gegenereerde lijsten komen regel voor regel binnen. Wordt een generatie toch afgekapt, dan levert dat een bruikbaar deelresultaat op in plaats van een onbruikbaar half bericht.
  • Achtergrondtaken. Werk dat niet binnen één functie past, loopt als taak met eigen status en voortgang. De gebruiker kan wegklikken en terugkomen.
  • Modelkeuze per taakzwaarte en hergebruik van vaste promptdelen, wat zowel tijd als kosten scheelt.

De budgetbewaking blijft in al deze paden actief, ook wanneer aanroepen parallel lopen.