AI toevoegen aan een bestaande webapp

De meeste teams die deze vraag stellen hebben de lastige delen al. Er is een database met echte data, een authenticatiesysteem, een deploymentpipeline, en gebruikers die het merken als iets kapotgaat. Dat is een veel betere startpositie dan een greenfield AI-project, en het verandert de volgorde waarin het werk moet gebeuren.

Welke feature bouw je als eerste?

Kies een taak die iemand al met de hand doet, herhaaldelijk, in je product. Supportmedewerkers die dezelfde uitleg plakken. Ops die PDF’s leest en vijf velden in een formulier kopieert. Gebruikers die een lijst scrollen omdat zoeken alleen exacte woorden matcht.

Die maken goede eerste features om drie redenen. De waarde is meetbaar, omdat je ongeveer weet hoeveel minuten de handmatige versie kost. De trainingsdata bestaat al, in de vorm van wat die mensen vorige maand deden. En de definitie van “goed” is beschikbaar bij iemand in het gebouw, wat je zo nodig hebt.

Vermijd, als eerste feature, alles waarvan de output ongezien naar een klant gaat, alles dat meer dan twee systemen overspant, en alles waarbij niemand kan zeggen hoe een goed antwoord eruitziet.

Waarom grounding meer uitmaakt dan het model

Een algemeen model weet veel van de wereld en niets van jouw bedrijf. Vraag het naar je restitutiebeleid en het produceert iets dat klinkt als een restitutiebeleid, wat erger is dan nutteloos.

Grounding is de oplossing: haal de relevante tekst uit je eigen systemen, zet die in de prompt, en instrueer het model alleen daaruit te antwoorden. Dat is retrieval-augmented generation, en daar gaat de engineeringtijd écht naartoe.

In de praktijk betekent dat beslissen wat een ophaalbare eenheid is (een document is meestal te groot, een zin te klein, een sectie ongeveer goed), een doorzoekbare index van die eenheden naast de bronrecords houden, en het model de handvol meest relevante stukken meegeven plus waar elk vandaan komt, zodat het antwoord ze kan citeren.

Je bestaande database is vaak genoeg om te beginnen. Postgres met pgvector, of zelfs full-text search, draagt een eerste feature verder dan teams verwachten. Een dedicated vector database is een schaalbeslissing, geen startvereiste.

Welke budgetten zet je voordat je code schrijft?

Drie getallen, afgesproken voor de implementatie, omdat elk het ontwerp verandert:

Nauwkeurigheid. Verzamel dertig tot vijftig echte voorbeelden met bekende goede antwoorden, en bepaal welk percentage goed moet zijn voordat de feature het waard is om te shippen. Dertig voorbeelden in een spreadsheet is een volkomen respectabele evalset, en het zijn er dertig meer dan de meeste teams hebben.

Latentie. Een zoekvak moet instant voelen; een nachtelijke documentpipeline niet. Die ene beslissing bepaalt of je een groot model kunt veroorloven, of je streaming nodig hebt, en of het werk in een queue hoort.

Kosten per call. Vermenigvuldig het verwachte aantal tokens met de prijs van de provider, en daarna met je verwachte maandvolume. Doe dit op een bierviltje voordat je bouwt, want dit is het getal dat de feature later het vaakst doodt, en het ontwerp dat het redt (een kleiner model, gecachte retrieval, een goedkoper eerste filter) is veel makkelijker aan het begin te kiezen.

Hoe ship je het zonder het product te riskeren?

Zet de feature achter een flag en zet hem aan voor een handvol gebruikers die weten dat ze vroeg zijn. Log elke request en response, inclusief de opgehaalde context, zodat je bij een slecht antwoord precies kunt zien waar het model naar keek.

Houd een mens in de lus overal waar de feature schrijft, verstuurt of uitgeeft. Een agent die opstelt en om goedkeuring vraagt is ongeveer even nuttig als een die autonoom handelt, en faalt een stuk netter.

Vergelijk daarna met de budgetten die je zette. Als de nauwkeurigheid tekortschiet, zit de fix bijna altijd in retrieval en niet in prompting: het model kan de juiste tekst meestal niet zien. Als de kosten tekortschieten, kijk eerst hoeveel context je meestuurt voordat je naar iets anders kijkt.

Waar de tijd écht naartoe gaat

Teams verwachten steevast dat het modelwerk domineert, en merken dat het dat niet doet. Bij een typische eerste feature is promptontwerp een paar dagen. Retrieval (beslissen wat je indexeert, die index synchroon houden als records veranderen, de resultaten goed maken) is een paar weken. Evaluatie, de interface, permissies, fouttoestanden, logging en de rollout zijn de rest.

Dat is een gewoon softwareproject met een ongebruikelijk onderdeel in het midden, en dat is goed nieuws: je bestaande engineeringpraktijk geldt grotendeels. De delen die écht nieuw zijn, zijn de evalset en de gewoonte om het model standaard als onbetrouwbaar te behandelen.

De volgorde, ingekort

1. Kies één repetitieve taak in het product.
2. Schrijf dertig echte voorbeelden op, met hun juiste antwoorden.
3. Zet budgetten voor nauwkeurigheid, latentie en kosten.
4. Bouw retrieval over data die je al hebt.
5. Ship achter een flag naar een kleine groep, en log alles.
6. Meet tegen de budgetten, fix eerst retrieval, verbreed.

Niets hiervan vraagt om een platformmigratie, een nieuw team of een strategiedeck. Het vraagt om iets kleins genoeg om af te maken, en om eerlijk te zijn over of het werkt.