Modelfamilies en generaties uitgelegd
Wie werkt met grote taalmodellen en AI-systemen komt dagelijks een woud aan benamingen tegen. Een typische modelnaam lijkt op het eerste gezicht vaak op een willekeurige aaneenschakeling van merknaampjes, getallen, maataanduidingen en cryptische afkortingen. Deze namen proberen echter drie verschillende dimensies tegelijk uit te drukken: van welke maker het model afkomstig is, uit welke technologische generatie het stamt, en welke specifieke variant of maat het betreft.
Doordat aanbieders deze informatie in één korte tekenreeks proberen te proppen, ontstaat er snel verwarring. Het helpt om te begrijpen hoe deze namen zijn opgebouwd en hoe de onderliggende logica werkt. Wanneer je de structuur achter de naamgeving herkent, kun je sneller inschatten wat voor vlees je in de kuip hebt, welke impact een overstap heeft op je infrastructuur en wanneer het noodzakelijk is om je evaluaties opnieuw uit te voeren.
De opbouw van een modelnaam
In de praktijk bestaat een gestructureerde modelnaam uit vier herkenbare bouwstenen. Niet elke aanbieder gebruikt ze allemaal expliciet, maar in de kern is de opbouw vrijwel altijd terug te herleiden naar dezelfde elementen.
| Element | Functie | Aandachtspunt |
|---|---|---|
| Familienaam | Identificeert de maker of de productlijn. | Geeft de algemene architectuurfilosofie aan. |
| Generatienummer | Duidt op een grote architectuursprong of trainingsronde. | Verschuiving van basiseigenschappen en dataset. |
| Maataanduiding | Geeft de omvang van de capaciteit of parameters aan. | Alleen vergelijkbaar binnen dezelfde familie. |
| Achtervoegsel | Specificeert de afstemming, taak of modus. | Bepaalt de feitelijke geschiktheid voor interactie. |
De familienaam koppelt het model aan een specifieke organisatie of een herkenbare merklijn. Binnen een familienaam delen opeenvolgende modellen vaak vergelijkbare keuzes qua tokenization, basisarchitectuur en ontwerpprincipes.
Het generatienummer geeft een temporele of technologische stap aan. Een opvolgend nummer betekent meestal dat de ontwikkelaar de basistrainingsdata heeft vernieuwd, de netwerkarchitectuur heeft gewijzigd of een fundamenteel ander trainingsproces heeft toegepast.
De maataanduiding verwijst direct of indirect naar de capaciteit van het model. Dit gebeurt soms expliciet via het aantal parameters, maar vaker met abstractere termen als 'klein', 'middel' of 'groot'.
Tot slot duidt het achtervoegsel op de specifieke nabehandeling of doelgroep. Denk aan aanduidingen die aangeven of het model puur tekst aanvult, is afgestemd op het opvolgen van instructies, of geoptimaliseerd is voor specifieke taken zoals redeneren, code genereren of chatten.
Het verschil tussen generaties en varianten
Een van de belangrijkste onderscheiden bij de selectie van modellen is het verschil tussen een nieuwe generatie en een nieuwe variant binnen een bestaande generatie. Dit onderscheid bepaalt in grote mate wat de impact is op een bestaande softwaretoepassing.
Een nieuwe generatie representeert een fundamentele herziening. De maker heeft het model vanaf nul getraind op een nieuwe dataset, wellicht een andere contextlengte geïntroduceerd, of de opbouw van de lagen gewijzigd. Hierdoor veranderen ook de subtiele nuances van het model: de manier waarop het reageert op instructies, de taalbeheersing en de neiging tot foutieve aannames. Stap je over naar een nieuwe generatie, dan dien je het model te behandelen als een volledig nieuw onderdeel van je systeem. Alle prompts, randgevallen en evaluaties moeten opnieuw worden getoetst.
Een nieuwe variant binnen dezelfde generatie betreft meestal een tussentijdse update. Denk aan een hernieuwde afstemming (fine-tuning) om veiligheidseigenschappen te verbeteren, een uitbreiding van de ondersteunde talen, of een efficiëntere kwantisatie. Hoewel de basiscapaciteiten grotendeels gelijk blijven, kunnen ook kleine variantupdates onverwachte gedragsveranderingen veroorzaken. Uitgebreide informatie over het opvangen en beheren van deze tussentijdse wijzigingen lees je op de pagina over modelversies en deprecatie.
Let op: Een hoger generatienummer levert niet automatisch betere resultaten op voor jouw specifieke toepassingsdomein. Nieuwe generaties worden vaak geoptimaliseerd op algemene benchmarks, wat ertoe kan leiden dat specifieke niches anders presteren dan in de vorige generatie.
Waarom een hoger versienummer geen garantie is
Het is een veelgemaakte denkfout om aan te nemen dat een nieuwere generatie op alle fronten superieur is aan de oudere. Wanneer ontwikkelaars een nieuwe generatie bouwen, verschuiven de prioriteiten tijdens het trainingsproces. Een model kan bijvoorbeeld sterk verbeterd zijn in logisch redeneren en meertaligheid, maar tegelijk strenger zijn afgesteld op het gebied van veiligheid, waardoor het bij bepaalde creatieve opdrachten sneller weigert te antwoorden.
Daarnaast kunnen veranderingen in de tokenizer betekenen dat bepaalde domeinspecifieke termen of codefragmenten efficiënter of juist minder efficiënt worden verwerkt. Voor wie vooraf wil inschatten welke variant het beste past bij een specifieke casus, biedt het overzicht over een model kiezen concrete handvatten voor het evalueren van deze trade-offs.
Maataanduidingen: de zin en onzin van parameteraantallen
Naast de generatie vormt de maat van een model een belangrijk selectiecriterium. De maat wordt in het open-source domein vaak uitgedrukt in het aantal parameters waaronder het model is getraind. Bij gesloten modellen wordt vaak gebruikgemaakt van relatieve termen zoals 'nano', 'micro', 'small', 'medium' of 'large'.
Het is essentieel om te begrijpen dat parameteraantallen alleen een bruikbare vergelijking opleveren wanneer je twee modellen binnen dezelfde modelfamilie en generatie vergelijkt. Een model van 8 miljard parameters uit een nieuwe generatie kan op veel taken beter presteren dan een model van 70 miljard parameters uit een verouderde generatie. Dit komt door slimmere trainingsarchitecturen, een betere datakwaliteit en efficiëntere afstemming.
Bovendien spelen de theoretische en praktische grondbeginselen van het model een grote rol. Wil je dieper ingaan op de precieze werking van gewichten en opslagvormen, bekijk dan de uitleg over parameters en gewichten op onze leerafdeling.
Een extra complicatie bij maataanduidingen is het opkomen van gedistilleerde modellen. Hierbij wordt de kennis van een zeer groot model overgedragen op een kleiner model. Een klein gedistilleerd model kan op specifieke taken uitstekend presteren, terwijl het totale aantal parameters bescheiden blijft. Voor een diepere duik in deze techniek verwijzen we naar het artikel over gedistilleerde modellen.
Achtervoegsels en de impact van afstemming
De letters of woorden die achteraan een modelnaam hangen, vertellen je hoe het model geconditioneerd is. Een basismodel (vaak aangeduid als base of simpelweg zonder achtervoegsel) is puur getraind om het meest logische volgende woord te voorspellen. Als je een basismodel een vraag stelt zoals "Wat is de hoofdstad van Frankrijk?", zal het niet zelden antwoorden met "En wat is de hoofdstad van Duitsland?", omdat het de invoer ziet als de start van een meerkeuzetoets.
Om een model bruikbaar te maken voor interactie, past men instructie-afstemming toe. Dit herken je aan achtervoegsels zoals:
- Instruct / Chat: Het model is geoptimaliseerd om vragen direct te beantwoorden en dialoog te voeren.
- Code: Het model heeft extra training gehad op programmeertalen en technische documentatie.
- Vision / VL: Het model kan naast tekst ook afbeeldingen als invoer verwerken (multimodaal).
- Reasoning / Thought: Het model gebruikt een interne tussenstap om complexe vraagstukken stapsgewijs te ontleden alvorens te antwoorden.
Het verschil in gedrag tussen een basismodel en een instructie-afgestemd model is vele malen groter dan het verschil tussen twee opeenvolgende maten van hetzelfde model. Binnen applicatie-ontwikkeling werk je in veruit de meeste gevallen met instructie-afgestemde varianten.
Aliassen: navigeren langs bewegende doelen
In veel cloud-omgevingen en API-diensten komen ontwikkelaars zogenaamde aliassen of pointer names tegen. Dit zijn generieke namen zoals model-latest of model-preview. Deze aliassen verwijzen achter de schermen naar een specifiek, gehost model. Biedt de leverancier een update aan, dan wordt de alias omgezet naar het nieuwe model.
Hoewel dit voor prototyping handig is, brengt het in een productie-omgeving grote risico's met zich mee. Een update van de onderliggende endpoint kan ertoe leiden dat je applicatie van de ene op de andere dag andere antwoorden geeft, anders omgaat met gestructureerde invoer (zoals JSON), of op een andere manier weigert. Voor het waarborgen van consistente resultaten is het noodzakelijk om dit risico af te dekken. Meer achtergrond hierover vindt u in de gids over reproduceerbaarheid.
Best practice voor code en configuraties
De vuistregel voor software-architectuur is helder: gebruik in je code, scripts en configuratiebestanden altijd de meest specifieke, geversioneerde modelaanduiding die de aanbieder ondersteunt. Maak alleen gebruik van algemene aliassen in experimentele omgevingen om te ontdekken of een nieuwe versie waarde toevoegt.
Als je gebruikmaakt van een tussenlaag of dynamische verdeling van verzoeken, is het verstandig om het specifieke model expliciet mee te geven. Uitgebreide strategieën voor het aansturen van meerdere endpoints vind je in de documentatie over model routing.
Open versus gesloten modellen: verschil in precisie
Er is een duidelijk verschil in hoe de community van open modellen en commerciële gesloten aanbieders hun producten noemen.
Bij open modellen (modellen waarvan de gewichten openbaar zijn vrijgegeven) is de naamgeving over het algemeen zeer transparant en gedetailleerd. De naam bevat vrijwel altijd de familienaam, de generatie, het exacte parameteraantal, de afstemmingsstatus en vaak de kwantisatiegraad (zoals 4-bit of 8-bit). Dit is noodzakelijk omdat ontwikkelaars het model lokaal of op eigen infrastructuur moeten draaien, waarbij het geheugengebruik exact berekend moet worden.
Bij gesloten diensten (modellen die uitsluitend via een API bereikbaar zijn) kiezen aanbieders vaker voor marketinggerichte namen. Parameter-aantallen en exacte netwerkarchitecturen worden zelden bekendgemaakt. In plaats daarvan gebruikt men abstracte aanduidingen om snelheids- en prijsklassen aan te duiden. Wel leveren gesloten aanbieders vaak datum-gebaseerde versienummers (zoals een achtervoegsel met een datum) om specifieke versies te kunnen blijven aanroepen.
Omgaan met gewijzigde naamgeving van aanbieders
Het komt regelmatig voor dat een aanbieder halverwege de levenscyclus van een product de naamgevingssystematiek omgooit. Een lijn die eerst met cijfers werd aangeduid, krijgt ineens kleurnamen, of een maataanduiding vervalt ten gunste van een nieuwe merknaam. Dit kan voor verwarring zorgen in interne documentatie en rapportages.
De meest effectieve methode om dit op te vangen, is het hanteren van een interne index. Geef binnen de eigen organisatie elk model een vaste, interne ID. Koppel deze interne ID in een configuratiebestand aan de daadwerkelijke API-string van de leverancier. Mocht de leverancier de naam van het model of het endpoint aanpassen, dan hoef je alleen de verwijzing in het configuratiebestand bij te werken, terwijl je interne logs, evaluaties en codeboeken consistent blijven.
Praktische leesvolgorde bij een onbekende modelnaam
Wanneer je geconfronteerd wordt met een onbekende tekenreeks in een repository of API-documentatie, gebruik dan het volgende stappenplan om de naam te ontleden:
- Zoek de familienaam: Welke organisatie of merklijn staat aan de basis van dit model?
- Bepaal de generatie: Is dit een eerste, tweede of latere generatie binnen deze familie? Hoe verhoudt zich dit tot de huidige stand van de techniek?
- Identificeer de variant en maat: Om welke grootteklasse gaat het, en betreft het een basismodel of een afgestemde versie?
- Controleer de versie-indicator: Bevat de naam een specifieke datum of versienummer, of is het een algemene alias?
- Beoordeel de geschiktheid: Pas na het doorlopen van de bovenstaande stappen heeft het zin om te bepalen of het model inhoudelijk en infrastructureel past bij jouw toepassing.
Door deze systematische aanpak te hanteren, voorkom je dat je tijd verspilt aan het testen van modellen die qua afstemming of omvang niet aansluiten bij je eisen.
