Waarom bijna alles wat je over LLM’s in productie is verteld maar half klopt
Ik heb teams zes maanden werk zien weggooien omdat ze uitgingen van twee tegenstrijdige ideeën: dat een LLM werkte als een REST-endpoint en dat het voldoende was om het gewoon te lanceren, of dat het zo onvoorspelbaar was dat het niet de moeite loonde om het uit het lab te halen. Geen van beide houdt stand bij contact met echt verkeer. Volgens de officiële documentatie van de belangrijkste modelproviders variëren latentie, kosten en kwaliteit niet-lineair met de context, de temperatuur en de lengte van de respons, en dat doorbreekt veel van de beloftes die in talks en posts de ronde doen.
Dit artikel bespreekt de mythes die het meeste kwaad doen bij het naar productie brengen van taalmodellen en confronteert ze met wat er gebeurt wanneer het systeem echte gebruikers bedient: herhaalpogingen, slecht gevormde prompts, gevoelige gegevens en piekbelasting. Er zijn geen garanties op resultaten: er zijn patronen die in bepaalde contexten werken en andere die jammerlijk falen.
Mythe 1: «De perfecte prompt maakt engineering overbodig»
De prompt is belangrijk, maar vervangt de architectuur niet. Een team waarmee ik samenwerkte bouwde een supportassistent die in handmatige tests nauwkeurig antwoordde. In productie faalde dezelfde prompt zodra gebruikers in hoofdletters begonnen te schrijven, met fouten of door screenshots te plakken die door een gebrekkige OCR waren getranscribeerd. Het percentage nuttige antwoorden daalde zonder dat het model was veranderd.
Wat wél werkt
- Invoervalidatie: tekst normaliseren, lengte beperken en taal detecteren voordat het model wordt aangeroepen.
- Uitvoercontracten: JSON met een schema eisen en valideren met een library; bij falen opnieuw proberen met een beperkte correctieprompt.
- Deterministische fallback: voor veelvoorkomende queries kunnen een template of regels beter en goedkoper antwoorden dan het model.
De realiteit is dat de prompt een onderdeel van het systeem is, niet het systeem zelf. Volwassen teams versioneren prompts als code, evalueren ze met testsets en meten regressies voordat ze uitrollen.
Mythe 2: «Meer context verbetert het antwoord altijd»
Een groot contextvenster is nuttig, maar niet gratis. Volgens de documentatie van de providers groeien kosten en latentie met de invoertokens, en in de praktijk verbetert de kwaliteit niet monotoon: tien irrelevante documenten erin stoppen verwatert het signaal en vergroot de kans dat het model tangentiële informatie citeert.
Concreet voorbeeld van falen
In een interne zoekfunctie over technische documentatie verbeterde de overgang van 3 naar 15 opgehaalde fragmenten de dekking van correcte antwoorden bij brede vragen, maar verslechterde de antwoorden op detailvragen omdat het juiste fragment begraven raakte tussen andere vergelijkbare fragmenten. De oplossing was niet het vergroten van de context, maar het verbeteren van de ranking van de retrieval en het beperken tot de fragmenten met de hoogste score, met een afkapdrempel.
Beperkingen die je moet erkennen
Er bestaat geen magisch aantal fragmenten. Het hangt af van het domein, de kwaliteit van de index en het type vraag. Wie beweert «gebruik altijd top-k=5» simplificeert. Je moet het meten met een eigen evaluatieset.
Mythe 3: «Het model is deterministisch als ik temperatuur 0 instel»
Temperatuur 0 vermindert de variabiliteit, maar elimineert die niet bij alle providers of alle modellen. Bovendien verbergt het schijnbare determinisme een andere bron van variatie: stille wijzigingen in het gehoste model. Dezelfde identifier kan worden bijgewerkt en antwoorden veranderen, iets waar de documentatie van verschillende providers expliciet voor waarschuwt.
Praktische gevolgen
- Specifieke versies vastzetten wanneer de provider dat toestaat.
- Een regressietestset onderhouden die na elke versiewijziging wordt uitgevoerd.
- De modelversie bij elk antwoord vastleggen om te kunnen auditen.
Als je product ervan afhangt dat de uitvoer identiek is tussen uitvoeringen, is een LLM niet het juiste hulpmiddel voor dat deel. Daar is deterministische logica beter geschikt.
Mythe 4: «Het kost weinig omdat de token goedkoop is»
De kosten per token lijken laag totdat je ze vermenigvuldigt met gebruikers, herhaalpogingen en context. Een patroon dat ik vaak zie: een chatbot die de volledige gespreksgeschiedenis bij elke aanroep meestuurt. Bij gesprekken van twintig beurten groeien de kosten kwadratisch ten opzichte van het aantal beurten, niet lineair.
Wat je kunt doen
- De oude geschiedenis samenvatten en alleen de laatste relevante beurten bewaren.
- Antwoorden cachen voor herhaalde vragen, als het domein dat toelaat.
- Eenvoudige queries naar kleine modellen routeren en de grote reserveren voor complexe gevallen.
- Uitgavelimieten per gebruiker of per sessie instellen.
Er bestaat geen universele besparingsformule. Elk cijfer dat wordt gedeeld zonder context van verkeer en contextlengte is anekdotisch. Wat wél consistent is: zonder observability van invoer- en uitvoertokens raken de kosten uit de hand.
Mythe 5: «Als het in de demo werkt, is het klaar voor productie»
De demo toont het gelukkige pad. Productie is het ongelukkige pad: lege invoer, pogingen tot promptinjectie, gebruikers die dingen vragen buiten bereik, uitval van de provider en wachttijden. Volgens sectorstudies over betrouwbaarheid van diensten zijn storingen in externe afhankelijkheden een veelvoorkomende oorzaak van incidenten, en een LLM is nog een externe afhankelijkheid.
Minimale checklist voordat je het aan gebruikers blootstelt
- Time-outs en herhaalpogingen met exponentiële backoff, met een maximum aantal pogingen.
- Circuit breaker om de provider niet te bestoken wanneer die faalt.
- Duidelijke degradatiemeldingen wanneer het model niet beschikbaar is.
- Invoer- en uitvoerfilters voor persoonsgegevens en schadelijke inhoud.
- Logging van traces met prompt, antwoord, latentie en kosten, met een gedefinieerde bewaartermijn.
Niets hiervan is glamoureus, maar het is wat een prototype onderscheidt van een dienst die een maandagochtend overleeft.
Mythe 6: «Evaluatie los je op met goede automatische metrieken»
Automatische metrieken zoals BLEU of ROUGE hebben een zwakke correlatie met de ervaren bruikbaarheid bij open taken. Voor een systeem voor gegevensextractie met een vast schema werkt een nauwkeurigheidsmetriek. Voor een conversatieassistent niet.
Wat in de praktijk werkt
- Een kleine maar representatieve evaluatieset, beoordeeld door mensen uit het domein.
- Peer-evaluatie of rubrieken voor subjectieve taken.
- Periodieke steekproeven van echte antwoorden om drift te detecteren.
Ik erken een beperking: het bouwen en onderhouden van die set kost tijd en schaalt niet zo goed als een automatisch script. Maar zonder die set is elke bewering over de kwaliteit van het systeem een mening.
Mythe 7: «Privacy los je op met een juridische kennisgeving»
Het versturen van gebruikersgegevens naar een externe provider heeft implicaties die een kennisgeving niet oplost. Je moet weten wat er wordt verstuurd, hoeveel er wordt bewaard en in welke jurisdictie het wordt verwerkt. Sommige teams ontdekken laat dat ze e-mails en telefoonnummers in de prompts opnamen omdat het oorspronkelijke formulier ze ongefilterd verzamelde.
Concrete maatregelen
- Identificatoren pseudonimiseren voordat de prompt wordt opgebouwd.
- Definiëren welke velden het systeem nooit verlaten.
- De bewaarvoorwaarden van de provider controleren en, indien nodig, deployments gebruiken die geen gegevens opslaan.
Dit is geen juridisch advies, en je kunt het beste overleggen met wie daarvoor verantwoordelijk is. Maar technisch gezien is filteren vóór verzending goedkoper dan achteraf herstellen.
Mythe 8: «Een LLM vervangt het supportteam of het contentteam»
Het kan de belasting bij repetitieve taken verminderen, maar introduceert een toezichtkost. Een model dat zelfverzekerd antwoordt over onderwerpen die het niet beheerst, genereert meer werk dan het bespaart. Bij klantenserviceprojecten blijft menselijke beoordeling van antwoorden met lage betrouwbaarheid nodig om kostbare fouten te voorkomen.
De realiteit is saaier: de LLM is een hulpmiddel binnen een workflow, met mensen op de risicopunten. De gevallen waarin het zonder toezicht werkt, zijn die met een gesloten schema en lage foutconsequenties, zoals het classificeren van tickets of het samenvatten van interne teksten.
Wat je je wel moet realiseren voordat je begint
- Je hebt observability nodig vanaf dag één, niet achteraf.
- De werkelijke kosten begrijp je pas wanneer er verkeer is, niet in het lab.
- Kwaliteit meet je met eigen data, niet met publieke benchmarks.
- Er zullen wijzigingen bij de provider zijn die je product beïnvloeden zonder dat je zelf iets aanraakt.
- Sommige taken zou je niet met een LLM moeten oplossen: exacte berekeningen, strikte naleving van regelgeving of beslissingen met onomkeerbare gevolgen.
LLM’s in productie implementeren is minder magie en meer engineeringdiscipline: versionering, evaluatie, limieten en gecontroleerde degradatie. De mythes verkopen shortcuts; de realiteit vraagt om meten voordat je belooft.