Voordat je code aanraakt: beslissingen die alles bepalen
Een taalmodel integreren in een website begint niet met het installeren van een SDK. Het begint met het beantwoorden van drie vragen die de rest van de checklist bepalen: welke concrete taak lost het LLM op, waar wordt de inferentie uitgevoerd en wie draagt de kosten per token. Als je voor alle drie geen sluitend antwoord hebt, wordt elke integratie uiteindelijk een duur prototype dat niemand onderhoudt.
Deze checklist is geordend naar echte projectfasen. Het is geen theoretische gids: elk punt bevat de reden waarom het bestaat en de typische fout die het voorkomt. Sommige punten zijn niet op alle gevallen van toepassing en dat geef ik expliciet aan.
Fase 1. Definitie van de use case (sla dit deel niet over)
1.1. Schrijf de taak in één verifieerbare zin
‘De gebruikerservaring verbeteren’ is geen taak. ‘Inkomende supporttickets classificeren in vijf categorieën met een betrouwbaarheidslabel’ is dat wel. Als je niet kunt meten of het antwoord van het model correct is, kun je het niet met garanties integreren.
1.2. Controleer of een LLM echt nodig is
Veel taken die aan LLM’s worden toegeschreven, worden opgelost met regels, reguliere expressies of een klassieke classifier die goedkoper en deterministischer is. Een LLM blinkt uit in vrije taal, ambiguïteit en generatie; het faalt bij exacte berekeningen, strikte logica en gegevens die elke minuut veranderen. Als jouw geval ‘een bedrag uit een factuur met vast formaat extraheren’ is, heb je waarschijnlijk geen generatief model nodig.
1.3. Definieer de maximaal aanvaardbare kost per interactie
De prijzen per miljoen tokens verschillen sterk tussen aanbieders en tussen modellen van dezelfde familie. Bereken vóór de integratie: gemiddelde promptlengte + gemiddelde antwoordlengte × geschat dagelijks volume. Een chatbot die 3.000 vragen per dag ontvangt met prompts van 2.000 tokens kan meer kosten dan de jaarlijkse hosting van de site. Heb dat getal voordat je de eerste regel schrijft.
Fase 2. Architectuur en beveiliging
2.1. De API-sleutel reist nooit naar de browser
Dit is de meest voorkomende en duurste fout. Elke aanroep vanuit JavaScript aan de clientzijde stelt de sleutel bloot in de ontwikkelaarstools. De aanroep naar de aanbieder moet vanuit je server of een edge-functie vertrekken. Als je streaming naar de browser nodig hebt, gebruik een proxy in je backend die de chunks doorstuurt.
2.2. Kies tussen externe API en zelfgehost model
Externe API: snel te implementeren, geen infrastructuur, maar je bent afhankelijk van beschikbaarheid en prijzen van de aanbieder, en de gegevens verlaten je omgeving. Zelfgehost model (bijvoorbeeld open gewichten geserveerd met lokale inferentietools): volledige controle en vaste kosten, maar vereist GPU, onderhoud en knowhow. Voor kleine of middelgrote websites is de API meestal de verstandige keuze; voor gevoelige gegevens met strikte eisen aan gegevensresidentie kan zelfhosting verplicht zijn.
2.3. Filter en minimaliseer de gegevens die je verstuurt
Verwijder vóór het versturen van een prompt persoonlijke identificatoren, e-mails en betaalgegevens die het model niet nodig heeft. Het is niet alleen naleving van regelgeving: het vermindert tokens en verbetert de kwaliteit van het antwoord door ruis te verwijderen.
2.4. Bescherming tegen prompt injection
Als het LLM inhoud verwerkt die de gebruiker beheert (reacties, productbeschrijvingen, geplakte teksten), ga er dan van uit dat die inhoud kwaadaardige instructies kan bevatten. Praktische mitigaties: scheid systeeminstructies en gebruikersinhoud met duidelijke scheidingstekens, valideer de uitvoer tegen een schema, en laat de uitvoer van het model nooit destructieve acties activeren zonder menselijke bevestiging.
Fase 3. Ontwerp van de prompt en de uitvoer
3.1. Stabiele en geversioneerde systeeminstructie
Bewaar de systeemprompt in een bestand met versiebeheer. Wanneer je één woord wijzigt, kun je resultaten vergelijken. Prompts die in de code leven, vermengd met de bedrijfslogica, zijn onmogelijk te auditen.
3.2. Gestructureerde uitvoer waar mogelijk
Als het resultaat een database of een interface voedt, vraag dan JSON met een gedefinieerd schema en valideer het antwoord met een strikte parser. Als het model vrije tekst teruggeeft en jij splitst op komma’s, breek je zodra het model van formaat verandert. De meeste huidige aanbieders bieden modi voor gestructureerde uitvoer; gebruik die.
3.3. Voeg voorbeelden toe aan de prompt (few-shot)
Twee of drie voorbeelden van correcte invoer-uitvoer verbeteren het resultaat meestal meer dan alinea’s met instructies. Ze kosten tokens, dus reserveer ze voor taken waar het formaat belangrijk is.
3.4. Definieer het gedrag bij twijfel
Geef expliciet aan wat het model moet doen wanneer het iets niet weet: een veld vertrouwen: laag teruggeven, een concrete zin om door te verwijzen naar een mens, of een leeg antwoord dat je interface interpreteert. Zonder deze instructie verzint het model met volle overtuiging.
Fase 4. Integratie in de frontend
4.1. Laadstatussen en annulering
Generatieve antwoorden duren seconden. De interface heeft een zichtbare wachtstatus nodig en een annuleerknop die het verzoek afbreekt. Als je streaming gebruikt, toon de tekst terwijl die binnenkomt: dat vermindert de waargenomen traagheid aanzienlijk.
4.2. Toegankelijkheid van de component
De container voor antwoorden moet aria-live=»polite» hebben zodat schermlezers de nieuwe tekst aankondigen. Streaming zonder toegankelijkheidsbeheer levert kapotte ervaringen op voor gebruikers met schermlezers.
4.3. Limieten aan de clientzijde en aan de serverzijde
Beperk de invoerlengte aan beide kanten. Een tekstveld zonder limiet is een directe weg naar gigantische prompts die je factuur opblazen. Voeg ook een limiet toe op verzoeken per sessie of per IP.
Fase 5. Kwaliteit, evaluatie en monitoring
5.1. Testset met verwachte antwoorden
Verzamel vóór publicatie tussen de 30 en 100 representatieve gevallen met het correcte antwoord handmatig geannoteerd. Voer de prompt er elke keer tegen uit wanneer je hem wijzigt. Zonder deze testbank is elke wijziging een gok.
5.2. Logging van verzoeken en antwoorden (met zorg)
Bewaar de prompt, het antwoord en de latentie om te kunnen debuggen. Anonimiseer vóór opslag en definieer een bewaartermijn. Een log zonder bewaarbeleid wordt een passief.
5.3. Waarschuwingen voor kosten en latentie
Stel een drempel voor dagelijkse uitgaven in die je waarschuwt voordat de factuur uit de hand loopt. Een oneindige lus aan de clientzijde of een bot die verzoeken herhaalt, kan het verbruik binnen enkele uren vermenigvuldigen.
Fase 6. SEO en zichtbaarheid
6.1. Gegenereerde inhoud wordt niet vanzelf geïndexeerd
Als het LLM pagina’s of fragmenten genereert die je wilt positioneren, hebben ze een eigen URL, titel, metabeschrijving en server-side rendering nodig. Een widget die tekst genereert binnen een div na een gebruikersinteractie voegt niets toe aan het crawlen.
6.2. Genereer geen massale inhoud zonder beoordeling
De kwaliteitsrichtlijnen van zoekmachines ontmoedigen inhoud die op schaal wordt geproduceerd zonder toegevoegde waarde. Als je het LLM gebruikt om te schrijven, gebruik het dan als concept met redactionele beoordeling. Volgens de officiële documentatie van de belangrijkste zoekmachines blijft het criterium het nut voor de gebruiker, niet de productiemethode.
6.3. Blokkeer of markeer de interne routes van de assistent
De endpoints van je API en de generatieroutes mogen niet crawlbaar of indexeerbaar zijn. Voeg noindex en beperkingen toe in robots.txt waar van toepassing.
Fase 7. Lancering en onderhoud
7.1. Geleidelijke uitrol
Activeer de functie eerst voor een percentage van de gebruikers. Meet foutpercentage, latentie en tevredenheid voordat je het voor al het verkeer opent.
7.2. Degradatieplan
Wat gebeurt er als de aanbieder 429- of 500-fouten teruggeeft? Definieer een reserveantwoord: bericht van onbeschikbaarheid, contactformulier of gecachet antwoord. Een assistent die de pagina breekt wanneer de API faalt, is erger dan geen assistent hebben.
7.3. Periodieke herziening van het model
Aanbieders trekken modelversies in met voorafgaande waarschuwingen. Noteer de deprecatiedatum van de versie die je gebruikt en test de migratie voordat die verplicht wordt. Prompts die zijn afgestemd op één versie kunnen zich anders gedragen in de volgende.
Een concreet geval en zijn les
In een project voor een assistent voor een winkel in componenten testte het team de prompt met catalogusvragen en die werkte goed. Bij publicatie begonnen gebruikers te vragen naar compatibiliteit tussen onderdelen. Het model antwoordde met overtuiging over combinaties die niet in de catalogus bestonden. De oorzaak: de prompt bevatte een steekproef van producten, niet de volledige catalogus, en het model vulde de gaten plausibel in. De oplossing was niet een betere prompt, maar het ophalen van de relevante producten uit de database en die als context mee te geven bij elk verzoek. Les: als het antwoord afhangt van gegevens die veranderen, heeft het model toegang nodig tot die gegevens op het moment van het verzoek, niet een statische steekproef in de prompt.
Wat deze checklist niet oplost
Er is geen garantie dat het model op alles correct antwoordt. LLM’s hallucineren, en geen enkele configuratie elimineert dat gedrag volledig. Er bestaat ook geen perfecte prompt: wat vandaag werkt, kan verslechteren met de volgende update van de aanbieder. En er zijn taken waarbij een LLM niet het juiste hulpmiddel is: exacte zoekopdrachten, financiële berekeningen, deterministische filters. Dat tijdig erkennen bespaart budget en frustratie.
Als je deze fasen in volgorde doorloopt en de beslissingen van elke fase op schrift vastlegt, heb je iets waardevollers dan een werkende integratie: je hebt een integratie die je kunt onderhouden wanneer het model, de aanbieder of het team verandert.