Een taalmodel kiezen is vandaag de dag geen kwestie van geloof. Het is een technische beslissing die invloed heeft op kosten, latentie, privacy en uitvoerkwaliteit. En om een goede keuze te maken, is het verstandig te begrijpen wat er schuilt onder die zwarte doos die we LLM noemen. Deze vergelijking gaat niet over «welke de beste is», maar over waarom elke modelfamilie zich anders gedraagt afhankelijk van de taak, en waar je op moet letten voordat je er een integreert in je workflow.
De gemeenschappelijke architectuur: allemaal vertrekken ze vanuit dezelfde truc
De huidige modellen (GPT, Claude, Gemini, Llama, Mistral) zijn directe afstammelingen van de transformer, gepresenteerd in het paper Attention Is All You Need (2017). Het kernidee: de tekst parallel verwerken via aandachtsmechanismen die wegen welke woorden uit de context het meest van belang zijn om het volgende te voorspellen. De training gebeurt met gradiëntdaling over miljarden tokens, en de uitvoer is een waarschijnlijkheidsverdeling over het volgende token.
Dat detail is belangrijk: het model «weet» niets in strikte zin. Het berekent waarschijnlijkheden. Daarom kan het zelfverzekerd klinken terwijl het een bibliografische referentie verzint. Het verschil tussen modellen zit niet in het concept, maar in hoe ze na de voortraining worden afgesteld (RLHF, DPO, constitutional AI) en in de hoeveelheid en kwaliteit van de data die ze te zien krijgen.
Vergelijking van de vier families die het meest worden gebruikt
GPT (OpenAI): het breedste ecosysteem
De GPT-4o-familie en zijn mini-varianten bieden native multimodaliteit (tekst, beeld, audio) en een zeer goed gedocumenteerde API. Hun sterkste punt is de integratie: plugins, assistenten, volwassen function calling. Hun praktische zwakte is de ondoorzichtigheid over de training en de afhankelijkheid van één enkele leverancier. Voor snelle prototypes en tools van derden is het de route met de minste wrijving.
Claude (Anthropic): lange context en genuanceerde antwoorden
Claude valt op door uitgebreide contextvensters (honderden duizenden tokens in zijn recente versies) en door een conservatief gedrag bij dubbelzinnige instructies: het neigt ernaar om verduidelijking te vragen in plaats van te improviseren. Bij taken zoals het analyseren van lange documenten of het reviewen van code wordt die voorzichtigheid gewaardeerd. Bij pure creatieve generatie is het soms minder gedurfd dan gewenst.
Gemini (Google): integratie met het ecosysteem en multimodaliteit
De Flash- en Pro-versies zijn ontworpen om samen te leven met Google-diensten (Workspace, Vertex AI, zoeken). Hun lange context en multimodale capaciteit zijn competitief. De keerzijde: de documentatie en de quotumlimieten veranderen vaak, en de verschillen tussen Flash- en Pro-versies hebben veel invloed op de kwaliteit van het redeneren.
Llama en Mistral: open gewichten en volledige controle
Hier is de logica anders. De gewichten zijn beschikbaar (met licenties die je beter leest, niet allemaal zijn ze even ruimdenkend). Je kunt ze lokaal of in je eigen cloud draaien, ze afstellen met fine-tuning en het gedrag auditen. De prijs is de infrastructuur: een model van 70B parameters in FP16 heeft ongeveer 140 GB VRAM nodig alleen al voor de gewichten, plus geheugen voor de context. Kwantisatie naar 4 bits reduceert dat cijfer tot een hanteerbare omvang op high-end consumenten-GPU’s, maar introduceert meetbare degradatie bij redeneertaken.
Wat je echt moet vergelijken voordat je kiest
- Reëel versus effectief contextvenster: dat een model 200.000 tokens aankondigt, betekent niet dat het de samenhang over dat hele bereik behoudt. De verzwakte aandacht op tussenliggende posities (het fenomeen lost in the middle) is gedocumenteerd in studies uit de sector. Test met je eigen lange document voordat je erop vertrouwt.
- Latentie en kosten per token: een groot model kan meerdere seconden nodig hebben om een volledig antwoord te genereren. Voor interactieve chat winnen kleine, afgestelde modellen vaak op het vlak van waargenomen snelheid.
- Gedrag bij weigering: allemaal hebben ze filters. Het verschil zit in hoeveel valse positieven ze genereren. Een model dat een legitieme medische vraag weigert uit overdreven voorzichtigheid is een operationeel probleem.
- Determinisme en temperatuur: bij temperatuur 0 is de uitvoer bij de meeste API’s niet volledig reproduceerbaar tussen aanroepen. Als je identieke resultaten nodig hebt, zul je de uitvoer moeten cachen of valideren.
Een concreet geval: de fout om de context af te meten aan de aankondiging
Een paar maanden geleden, tijdens het werk aan het extraheren van clausules uit huurcontracten, stelden we vast dat een model met een venster van 128.000 tokens clausules begon weg te laten die zich in het midden van het document bevonden wanneer dit meer dan 60 pagina’s bedroeg. De oplossing was niet van model te wisselen, maar het document op te splitsen in secties en gedeeltelijke samenvattingen aan elkaar te koppelen. Het is een patroon dat zich herhaalt: de aangekondigde limiet is niet de bruikbare limiet. Wie LLM’s in productie integreert, leert al snel dat context-engineering (wat je erin stopt en in welke volgorde) zwaarder weegt dan de keuze van het merk van het model.
Een andere veelvoorkomende fout: aannemen dat een model met betere algemene benchmarks beter zal zijn in jouw domein. Evaluaties zoals MMLU of HumanEval meten brede capaciteiten, niet jouw use case. De enige geldige test is een eigen evaluatieset, met echte voorbeelden uit je bedrijf en gedefinieerde acceptatiecriteria.
Beperkingen die geen enkel model nog oplost
LLM’s hebben geen persistent geheugen tussen sessies, tenzij je dat zelf bouwt (RAG, vector databases, geschiedenis). Ze verifiëren feiten niet zelf: als je ze om een cijfer vraagt, genereren ze het met dezelfde zekerheid als een correct cijfer. Ze redeneren niet betrouwbaar symbolisch bij problemen van formele logica met veel variabelen. En ze zijn op zichzelf niet geschikt voor medische, juridische of financiële beslissingen zonder menselijk toezicht: de officiële documentatie van de leveranciers zelf waarschuwt daarvoor.
Het is ook niet verstandig ze te gebruiken als orakels voor actualiteit. Hun kennis heeft een kennisafsluitdatum, en hoewel sommige een webzoekopdracht integreren, voegt die integratie latentie en een extra foutlaag toe (welke bron ze kiezen, hoe ze die citeren).
Hoe je in de praktijk beslist
Voor classificatie- en extractietaken met hoog volume is een klein model met fine-tuning meestal goedkoper en voorspelbaarder dan een groot model. Voor complexe redeneringen en lange documenten besparen modellen met uitgebreide context architectuur. Voor gevoelige data die je infrastructuur niet mogen verlaten, zijn open gewichten de enige echte weg, met de onderhoudskosten als prijs. En voor prototypes bespaart de API met de beste documentatie en community je dagen werk.
Geen enkele keuze is definitief: modellen veranderen om de paar maanden en wat vandaag de referentie is, is morgen achterhaald. Ontwerp je integratie met een abstractielaag boven de leverancier en een eigen evaluatieset. Dat stelt je in staat van model te wisselen zonder het product te herschrijven, wat de meest rendabele beslissing op lange termijn is.
En een laatste waarschuwing voor transparantie: er bestaat geen model dat correcte antwoorden garandeert. De kwaliteit hangt af van de context die je het geeft, van hoe je de instructie formuleert en van de validatie die je erachter zet. Elke belofte van onfeilbare resultaten kun je beter met enige afstand bekijken.