Van prompt tot product: LLM's omzetten in echte apps

Een prompt die werkt in een playground is een demo, geen product. In de kloof tussen die twee sterven de meeste AI-projecten een stille dood. Het bouwen van LLM-applicaties die echte gebruikers overleven, heeft minder te maken met slim prompten dan de demo's suggereren, en veel meer met gewone softwarediscipline. Wij hebben er genoeg van uitgebracht — Youp, MadaiOps en nu Linea — om een mening te hebben over wat die kloof daadwerkelijk dicht. Niets ervan is glamoureus.

De valkuil is dat de eerste versie af voelt. Je plakt een slimme prompt erin, het model levert iets indrukwekkends terug, en het is verleidelijk om er een UI omheen te bouwen en het een lancering te noemen. Dan komen echte gebruikers met invoer die je nooit had voorzien, doet het model met veel zelfvertrouwen iets fout, en ontdek je dat je geen manier hebt om te bepalen of je oplossing de zaken beter of slechter maakte. Dit stuk gaat over de steigers die die indrukwekkende demo veranderen in iets wat je in productie kunt draaien terwijl je 's nachts doorslaapt.

Begin met evals, niet met prompts

Het ding met de meeste hefboomwerking dat je vroeg kunt bouwen, is een evaluatieset. Geen benchmark, geen ranglijst — een map met echte invoer, gekoppeld aan hoe een goede uitvoer eruitziet. Twintig voorbeelden verslaan nul, en vijftig zorgvuldig gekozen voorbeelden verslaan er duizend die je bij elkaar hebt geschraapt.

De reden is simpel. Zodra je evals hebt, is prompt engineering geen kwestie van onderbuikgevoel meer. Je verandert een regel, je draait de set, je ziet het getal bewegen. Zonder evals is elke aanpassing bijgeloof. We hebben teams een week zien besteden aan het verbeteren van een prompt, om vervolgens terug te vallen op gevallen die ze maanden eerder al hadden opgelost, omdat niets de gevallen mat waar ze niet naar keken.

Een paar meningen die we stevig aanhangen:

• Beoordeel op uitkomsten, niet op formulering. Voor alles wat gestructureerd is — extractie, classificatie, routing — toets je op het geparste resultaat, niet op stringgelijkenis. Voor vrije tekst is een LLM-als-jurylid met een strakke rubriek prima, maar valideer het jurylid eerst tegen een handvol menselijke labels, anders meet je alleen de smaak van één model.
• Houd een regressiebestand bij. Elke productiefout wordt een permanente testcase. Zo blijft je eval-set eerlijk — hij groeit precies in de richtingen die de realiteit afdwingt.
• Versioneer je evals samen met je prompts. Een prompt zonder bijbehorende eval-set is een ongeteste codewijziging.

Als je één ding bouwt op basis van dit artikel, bouw dan dit. Alles stroomafwaarts hangt af van het kunnen beantwoorden van: heeft dat het beter gemaakt?

Guardrails zijn goedkoper dan excuses

Modellen falen op manieren waarop gewone software dat niet doet. Ze verzinnen een API die niet bestaat, gaan mee in de valse aanname van een gebruiker, of produceren geldig ogende JSON met een gehallucineerd veld. Guardrails zijn de laag die dit opvangt voordat het een gebruiker bereikt of, erger nog, een uitvoeringsstap.

Denk in drie posities.

• Input-guardrails wijzen af of saneren voordat het model draait: screening op prompt-injectie, redactie van persoonsgegevens, filtering op off-topic.
• Output-guardrails valideren wat er terugkomt: schemavalidatie, controles op onderbouwing met bronnen, beleidsfilters.
• Actie-guardrails zitten tussen het model en alles wat neveneffecten heeft.

Die derde is waar het echte risico zit. In Linea, onze agents voor workflow-automatisering, kan het model acties voorstellen — een API aanroepen, een record verplaatsen, een bericht sturen. Het voorstel en de uitvoering zijn bewust gescheiden stappen. Elke ingrijpende actie passeert een getypeerd contract en een beleidscontrole voordat er iets draait, en destructieve of onomkeerbare acties vereisen een expliciete bevestigingspoort. Een agent die het verkeerde voorstelt, is een UX-probleem waar je op kunt itereren. Een agent die het verkeerde doet, is een incident. Houd die twee faalmodi aan weerszijden van een harde grens.

De uitgesproken versie: valideer gestructureerde uitvoer tegen een schema en probeer bij falen opnieuw, in plaats van erop te vertrouwen dat het model consistent is. En laat de ruwe uitvoer van een model nooit datgene zijn wat een onomkeerbare actie in gang zet. Zet er altijd een deterministische controle tussen.

Budgetteer latentie en kosten als features

Latentie en kosten zijn geen dingen die je aan het eind meet. Het zijn beperkingen waartegen je vanaf het begin ontwerpt, want ze veranderen de architectuur, niet alleen de rekening.

Stel expliciete budgetten in per gebruikersgerichte actie: een p95-latentiedoel en een kostenplafond per aanroep. Zodra die zijn opgeschreven, worden de ontwerpbeslissingen makkelijker. Een paar patronen waar we steeds naar grijpen:

• Kies per stap het juiste model. De meeste pipelines hebben één of twee stappen die echt het frontier-model nodig hebben en meerdere die een kleiner, sneller model prima aankan. Simpele classificatie naar een goedkoop model routeren en het dure model reserveren voor de zware redeneerstap is de optimalisatie met het hoogste rendement, en meestal verbetert het ook de latentie.
• Stream de eerste token. Voor alles wat conversationeel is, wordt de waargenomen latentie gedomineerd door de tijd tot de eerste token. Een gestreamd antwoord dat vier seconden duurt, voelt beter dan een blokkerend antwoord dat er twee duurt.
• Cache agressief. Prompt-caching op stabiele systeemcontext, gewone resultaatcaching op herhaalde invoer. Een aanzienlijk deel van het productieverkeer is bijna-duplicaat.

De afweging die je in je hoofd moet houden: grotere modellen verminderen je engineeringinspanning, maar verhogen je marginale kosten en latentie voorgoed. Goedkopere modellen schuiven werk naar jou toe — meer zorg voor prompts, meer guardrails, meer evals — maar dat werk is een eenmalige kost tegenover een permanente besparing. Voor alles met volume: investeer de engineering.

Houd mensen in de loop, met opzet

"Human in the loop" wordt zo vaak gezegd dat het niets meer betekent. Goed gedaan is het geen achtervang voor als de AI faalt — het is een ontworpen taakverdeling. De vraag is niet of je een mens moet betrekken, maar waar het oordeel van de mens meer waard is dan de latentie die het toevoegt.

Het patroon dat ons het best heeft gediend, is escalatie op basis van vertrouwensniveau. Het systeem handelt de zelfverzekerde meerderheid automatisch af en routeert de onzekere minderheid naar een persoon, met de redenering van het model erbij zodat de mens in seconden beslist, niet in minuten. In MadaiOps stromen orderoperaties binnen normale parameters gewoon door; alles wat afwijkt komt met context bij een operator terecht in plaats van stilzwijgend te worden uitgevoerd. De beoordelaar past niet op de machine. Die besteedt zijn aandacht alleen daar waar die schaars en waardevol is.

Nog één regel: registreer de correcties van de mens en voed ze terug naar je eval-set en je prompts. Een human-in-the-loop-systeem dat niet leert van zijn mensen, betaalt gewoon twee keer voor hetzelfde werk.

Weet wat je niet moet automatiseren

Het moeilijkste oordeel in dit vak is terughoudendheid. Niet elke taak zou aan een model moeten worden overgedragen, en volwassenheid is weten welke je met rust moet laten.

Onze grove test: automatiseer waar de kosten van een fout laag zijn, of waar de fout makkelijk te detecteren en terug te draaien is. Concepten opstellen, samenvatten, extraheren, classificeren, routeren — goede kandidaten. Een verkeerd concept wordt bewerkt; een verkeerde samenvatting wordt bij het lezen betrapt. Wees veel voorzichtiger waar fouten duur, moeilijk te detecteren of onomkeerbaar zijn: alles wat geld verplaatst, een onherroepelijke communicatie verstuurt, of een juridische of medische beslissing neemt. Daar hoort het model in een ondersteunende rol — opties aandragen, concepten opstellen ter beoordeling — niet achter het stuur.

De lijn die we aanhouden: als je niet kunt beschrijven hoe je zou betrappen dat het model fout zit, ben je niet klaar om die stap te automatiseren. Het vermogen om falen te detecteren is de echte voorwaarde, meer dan nauwkeurigheid. Een stap die voor 95% nauwkeurig is en die je volledig kunt verifiëren, is veiliger om uit te brengen dan één die voor 99% nauwkeurig is maar die je niet kunt verifiëren.

De vorm van het werk

Een prompt in een product veranderen is grotendeels het weinig glamoureuze deel: evals zodat je kunt meten, guardrails zodat fouten ingeperkt blijven, budgetten zodat het snel en betaalbaar blijft, mensen geplaatst waar oordeel ertoe doet, en de discipline om sommige dingen niet te automatiseren. Het model is misschien twintig procent van het systeem. De andere tachtig procent is de engineering die zijn incidentele briljantie veilig maakt om op te vertrouwen.

Het goede nieuws is dat dit vertrouwd werk is. Het beloont dezelfde instincten die goede software van welke soort dan ook maken: meet voordat je verandert, perk je impactradius in, respecteer de tijd van je gebruikers. Het model is nieuw. Het vak is dat niet.