LLM’s vergelijken zonder te verdwalen in de ruis
Wanneer iemand vraagt wat LLM’s zijn en hoe ze werken, is het snelle antwoord meestal «taalmodellen die het volgende woord voorspellen». Dat klopt, maar het is onvoldoende om te beslissen welke je moet gebruiken. Het praktische verschil tussen het ene en het andere model zit niet in die definitie, maar in hoe ze met context omgaan, hoeveel ze kosten per miljoen tokens, hoe goed ze lange instructies opvolgen en tot hoever hun aandachtvenster reikt voordat ze vergeten wat er aan het begin van het gesprek werd gezegd.
Dit artikel herhaalt niet de uitleg uit het handboek. Het richt zich op wat verandert bij het vergelijken van de meest gebruikte families —GPT, Claude, Gemini, Llama en Mistral— en op de criteria die er in professioneel gebruik echt toe doen: redeneren met uitgebreide documenten, codegeneratie, operationele kosten en controle over de data.
Hoe een LLM van binnen werkt (net genoeg om te vergelijken)
Een LLM is een neuraal netwerk dat is getraind met een transformer-architectuur. Het verwerkt tekst door die op te splitsen in tokens (woordfragmenten) en berekent waarschijnlijkheden over het volgende token. Dat mechanisme, herhaald, levert samenhangende antwoorden op. Wat relevant is voor een vergelijking, is dat er twee duidelijk verschillende fasen bestaan:
- Voor training: het model absorbeert patronen uit enorme tekstcorpora. Hier wordt zijn algemene kennis en zijn basisredeneervermogen bepaald.
- Afstemming (fine-tuning en RLHF): het wordt bijgesteld om instructies op te volgen, schadelijke verzoeken te weigeren en een bepaalde toon aan te nemen. Hier wordt zijn «karakter» en zijn gehoorzaamheid bepaald.
Twee modellen van dezelfde omvang kunnen zich radicaal anders gedragen, afhankelijk van hoe die tweede fase is uitgevoerd. Daarom leidt het vergelijken van «parameters» zonder naar de afstemming te kijken tot verkeerde conclusies.
Context is niet zomaar een getal
Technische specificaties pronken met contextvensters van 128.000, 200.000 of zelfs een miljoen tokens. In de praktijk neemt de kwaliteit van het ophalen binnen dat venster af. Een patroon dat zich herhaalt bij het testen van modellen met lange contracten: informatie in het midden van het document wordt slechter opgehaald dan die aan het begin of het einde. Het is het bekende «lost in the middle»-effect, gedocumenteerd in sectorstudies over de evaluatie van lange context.
Praktische consequentie: als je een rapport van 300 pagina’s gaat analyseren, is het niet genoeg dat het model het document accepteert. Het loont om het op te splitsen, te indexeren en semantisch op te halen (RAG) in plaats van erop te vertrouwen dat het model alles met dezelfde aandacht zal lezen.
Vergelijking van de meest gebruikte families
GPT (OpenAI)
Het is de referentie vanwege het ecosysteem: volwassen API, tools, functies en een enorme community. Het blinkt uit in codegeneratie en in het opvolgen van gestructureerde instructies (JSON-uitvoer, functieaanroepen). Het historische zwakke punt is de breedsprakigheid en een zekere neiging om de gebruiker te behagen, zelfs als de premisse onjuist is. Voor taken als data-extractie met een strikt formaat is het meestal de meest voorspelbare optie.
Claude (Anthropic)
Het heeft een sterke positie verworven in lange teksten schrijven en in de analyse van uitgebreide documenten. Het produceert doorgaans teksten met minder stopwoorden en gaat beter om met genuanceerde correcties. Bij taken als redactionele revisie of het samenvatten van contracten verkiezen veel teams het vanwege de toon. Echte beperking: in sommige zeer specifieke codestromen presteert het minder dan GPT, en de integratie met externe tools is later gekomen.
Gemini (Google)
Het voordeel is de integratie met het Google-ecosysteem: zoeken, Workspace, Android. Het ruime contextvenster en de toegang tot actuele informatie via zoeken maken het nuttig voor taken die recente data vereisen. De nuance: de variabiliteit tussen versies (Flash, Pro, Ultra) is groot, en het kiezen van het verkeerde model voor een taak kan de kosten opdrijven zonder het resultaat te verbeteren.
Llama (Meta)
Het is de toonaangevende open familie. Het maakt lokale uitvoering of uitvoering op eigen servers mogelijk, wat privacyvereisten oplost die cloudmodellen niet dekken. Keerzijde: het vereist infrastructuur (GPU), onderhoud en technische kennis. Voor een kmo zonder ML-team wordt de besparing op licenties opgegeten door de operationele kosten.
Mistral
Efficiënte modellen, goed in de verhouding kwaliteit/omvang, met open en commerciële opties. Ze passen goed wanneer je een licht model nodig hebt voor classificatie, extractie of klantenservice met lage latentie. Het is niet de beste optie voor complexe redeneringen in meerdere stappen.
Snelle beslistabel
| Behoefte | Redelijke optie | Waarom |
|---|---|---|
| Code genereren en automatiseren met API’s | GPT | Ecosysteem en betrouwbare gestructureerde uitvoer |
| Lange documenten analyseren en schrijven | Claude | Verzorgde toon en goede omgang met uitgebreide context |
| Actuele data en Google-integratie | Gemini | Geïntegreerd zoeken en verbinding met Workspace |
| Privacy en lokale uitvoering | Llama | Open model, volledige controle over de data |
| Lage latentie en beperkte kosten | Mistral | Efficiënte kleine modellen |
Een praktijkgeval dat de beslissing verandert
Een juridisch team probeerde een raamcontract van 180 pagina’s te uploaden naar een model met een venster van 200.000 tokens. De verrassing: het model citeerde de clausules aan het begin en het einde correct, maar liet een strafclausule rond pagina 90 weg. Het was geen capaciteitsfout, maar een kwestie van verdeelde aandacht. De oplossing was niet van model veranderen, maar op splitsen per sectie, indexeren met embeddings en per specifieke clausule vragen. Dit is het soort beperking dat niet in benchmarkvergelijkingen verschijnt en dat je pas ontdekt door het met echte documenten te gebruiken.
Wat geen enkele LLM goed doet (nog)
Het is goed om het duidelijk te zeggen: geen enkel huidig model garandeert waarheidsgetrouwheid. Ze kunnen met volstrekte zekerheid referenties, cijfers of citaten verzinnen. Ze hebben ook geen besef van hun grenzen: als je hen naar een gegeven vraagt dat ze niet kennen, neigen ze ernaar het gat op te vullen. En ze redeneren niet strikt symbolisch: voor financiële berekeningen of formele logica blijft een spreadsheet of een regelengine betrouwbaarder.
Bovendien kan de kost per token laag lijken tot je opschaalt. Een stroom die dagelijks duizenden documenten verwerkt, kan een bescheiden maandfactuur omzetten in een aanzienlijk bedrag als het grootste model wordt gebruikt voor taken die een klein model net zo goed zou oplossen.
Hoe je kiest zonder je te vergissen
- Definieer de taak: classificeren, schrijven, extraheren, redeneren. Elk heeft een model dat uitblinkt.
- Meet met je eigen data: publieke benchmarks geven richting, maar vervangen geen test met honderd echte voorbeelden uit jouw domein.
- Bereken de totale kost: niet alleen de prijs per token, maar ook latentie, herhalingen en menselijke supervisie.
- Controleer privacy: als de data je infrastructuur niet mag verlaten, beperkt de beslissing zich tot open modellen.
- Bereid de vervanging voor: een abstractielaag gebruiken (zoals bibliotheken van het type LangChain of uniforme clients) voorkomt dat je aan één leverancier vastzit.
De nuttige vergelijking is niet «welk model is het beste», maar «welk is het beste voor deze taak, met dit budget en deze beperkingen». Die vraag verandert om de paar maanden, en daarom loont het om de stroom zo op te bouwen dat je van motor kunt wisselen zonder alles opnieuw te doen.