CAKE: Cloud Architecture Knowledge Evaluation of Large Language Models

Dit paper introduceert CAKE, een benchmark met 188 door experts gevalideerde vragen om het begrip van cloud-native softwarearchitectuur in grote taalmodellen te evalueren, en onthult dat meerkeuzevragen snel een plafond bereiken terwijl vrije antwoorden een betere differentiatie tussen modellen mogelijk maken.

De kern

Stel je voor dat je een nieuwe, superintelligente assistent hebt die je helpt met het bouwen van complexe gebouwen in de wolken (in de IT-wereld noemen we dat "cloud-native architectuur"). Deze assistent is een LLM (Large Language Model), een soort slimme computer die tekst kan schrijven en code kan genereren.

Maar hier is het probleem: Hoe weet je of deze assistent echt begrijpt hoe hij een stevig gebouw moet ontwerpen, of dat hij alleen maar goudgele zinnen uit zijn geheugen plakt?

Tot nu toe bestond er geen goede manier om dit te testen. Daarom hebben Tim en zijn team van de Universiteit van Zuid-Denemarken een nieuwe test ontwikkeld, genaamd CAKE.

Hier is wat CAKE is, vertaald naar alledaags taalgebruik:

1. De "CAKE"-proef (De Benchmark)

Stel je voor dat je een kok wilt testen die een taart moet maken.

• De oude manier (MCQ): Je vraagt de kok: "Wat is de beste ingrediënt voor een taart? A) Zout, B) Suiker, C) Aarde." De kok kiest B. Klaar. Hij scoort 100%. Maar weet hij echt hoe hij de taart moet bakken? Misschien niet. Hij heeft alleen het juiste antwoord geraden.
• De CAKE-methode: De test bestaat uit twee delen:
  1. Meerkeuzevragen (MCQ): De standaardtest om te zien of de assistent feiten kent.
  2. Vrije antwoorden (Free-Response): Hier moet de assistent zelf een ontwerp maken, een probleem oplossen of uitleggen waarom hij een bepaalde keuze maakt. Dit is als vragen: "Bak nu een taart en leg uit waarom je deze ingrediënten koos."

De test bevat 188 vragen, verdeeld over vier niveaus van moeilijkheid (gebaseerd op de beroemde "Bloom's Taxonomie"):

• Herinneren: "Wat is een container?" (Feitjes).
• Analyseren: "Waarom is dit ontwerp slecht?" (Begrijpen).
• Ontwerpen: "Maak een plan voor een schaalbaar systeem." (Creatief).
• Implementeren: "Schrijf de code voor dit systeem." (Handelen).

2. De Testresultaten: Wat hebben ze ontdekt?

De onderzoekers hebben 22 verschillende "koks" (AI-modellen) getest, van heel kleine (0,5 miljard "hersencellen") tot gigantische (70 miljard).

Hier zijn de belangrijkste lessen, vertaald in analogieën:

A. De "Meerkeuze-valstrik" (MCQ)

• Vindt: Zodra een model groter is dan een bepaalde maat (ongeveer 3 miljard parameters), haalt het bijna perfectie op de meerkeuzevragen.
• Analogie: Het is alsof je een student een meerkeuzetoets geeft. Zodra hij een beetje slim is, kan hij het juiste antwoord raden of herkennen. Hij haalt 99% goed. Maar dat betekent niet dat hij de stof begrijpt. Het is een "plaatje" dat hij herkent.
• Conclusie: Meerkeuzevragen zijn niet genoeg om te zien hoe slim een AI echt is.

B. De "Vrije Antwoorden" zijn de waarheid

• Vindt: Bij het maken van ontwerpen en het schrijven van code (vrije antwoorden) blijft het verschil tussen kleine en grote modellen groot. De grootste modellen (zoals GPT-5 Mini) doen het veel beter dan de kleinere.
• Analogie: Als je de student vraagt om een nieuw gebouw te tekenen, zie je pas het echte verschil. De kleine modellen maken veel fouten of verzonnen dingen, terwijl de grote modellen echte, werkende ontwerpen maken.
• Conclusie: Om te weten of een AI echt slim is, moet je hem laten doen, niet alleen laten kiesjes maken.

C. De "Denk-knop" (+Think) en de "Google-knop" (+Tool)

De onderzoekers hebben gekeken wat er gebeurt als je de AI extra hulpmiddelen geeft:

• De "Denk-knop" (+Think): Je zegt tegen de AI: "Denk eerst na voordat je antwoordt."
  • Resultaat: Dit helpt de AI om betere, meer doordachte antwoorden te geven bij complexe vragen. Het is alsof je een student een minuutje laat nadenken voordat hij het antwoord opschrijft.
• De "Google-knop" (+Tool): Je laat de AI zoeken op het internet.
  • Resultaat: Voor de kleine modellen is dit een ramp. Ze raken in de war, zoeken te veel en maken fouten. Het is alsof je een klein kind een zoekmachine geeft; hij verdwaalt in de informatie. Pas bij de grote modellen (ongeveer 8 miljard parameters of meer) werkt dit goed.

3. Waarom is dit belangrijk voor jou?

Als je een software-ontwikkelaar bent of een bedrijf runt dat AI gebruikt:

1. Vertrouw niet blind op meerkeuzes: Als een AI zegt dat hij "100% goed" is op een test, kan het zijn dat hij alleen maar goed is in het raden van antwoorden.
2. Gebruik de "Zekerheids-meter": De onderzoekers ontdekten dat als een AI drie keer hetzelfde antwoord geeft (zonder twijfel), het antwoord waarschijnlijk correct is. Als hij twijfelt (verschillende antwoorden), moet je het zelf controleren.
3. Kies de juiste tool: Voor simpele vragen is een klein, snel model genoeg. Maar voor het ontwerpen van complexe systemen heb je een groot, "denkend" model nodig, en laat die kleine modellen niet zoeken op het internet.

Samenvattend:
CAKE is de eerste echte "rijbewijstest" voor AI's in de wereld van cloud-architectuur. Het leert ons dat grootte niet alles is, maar dat hoe je de test afneemt (vragen of laten doen) bepaalt of je een slimme assistent hebt of alleen een slimme radelaar.

Technische samenvatting

Titel: CAKE: Evaluatie van Cloud-Architectuurkennis bij Grootte Taalmodellen (LLMs)

1. Probleemstelling

In de moderne softwareontwikkeling fungeren Large Language Models (LLMs) steeds vaker als "co-pilots" voor softwarearchitecten, vooral bij het nemen van beslissingen rondom cloud-native architectuur (microservices, containers, orchestration). Hoewel er benchmarks bestaan voor code-generatie (zoals SWE-bench) of algemene kennis (zoals MMLU), ontbreekt er een specifiek instrument om te evalueren of LLMs het conceptuele en procedurele kennis werkelijk begrijpen dat nodig is voor cloud-native architecturale beslissingen. Bestaande tools testen vaak alleen code-niveau, niet de onderliggende architecturale redenering op verschillende cognitieve niveaus.

2. Methodologie

De auteurs introduceren CAKE (Cloud Architecture Knowledge Evaluation), een benchmark specifiek ontworpen voor cloud-native softwarearchitectuur.

• Dataset: CAKE bestaat uit 188 expert-gevalideerde vragen verdeeld over vijf cloud-native thema's:
  1. Architecturale patronen
  2. Kwaliteitsattributen (bijv. schaalbaarheid, resiliency)
  3. Decompositiestrategieën
  4. Cloud-deployments
  5. Technische schuld
• Cognitieve niveaus: De vragen zijn gebaseerd op de herziene taxonomie van Bloom en dekken vier niveaus:
  1. Recall (herinneren)
  2. Analyze (analyseren)
  3. Design (ontwerpen)
  4. Implement (implementeren)
     Let op: Implementatiekennis wordt uitsluitend getest via open vragen.
• Vraagformaten:
  • Meerkeuzevragen (MCQ): 130 vragen. Beoordeeld via meerderheidsstemming (majority voting) over drie runs om positie-bias te minimaliseren.
  • Open vragen (Free-Response / FR): 58 vragen. Beoordeeld met de "LLM-as-a-judge" methode (DeepSeek-R1:32B als rechter) op een schaal van 0-5, gebaseerd op een gestructureerde rubriek.
• Geëvalueerde Modellen: Er zijn 22 modelconfiguraties getest uit vier families (Qwen, Llama, Mistral, GPT), variërend van 0.5B tot 70B parameters.
  • Drie uitvoeringsmodi werden getest:
    1. Base: Directe vraag-antwoord.
    2. +think: Gestructureerd redeneren (Chain-of-Thought).
    3. +tool: Agentisch gebruik van tools (zoals websearch).

3. Belangrijkste Bijdragen

1. De CAKE Benchmark: Het eerste benchmark-dataset dat cloud-native architectuurkennis test over meerdere cognitieve niveaus (van herinneren tot implementeren), inclusief een open-source dataset.
2. Empirische Evaluatie: Een uitgebreide studie van 22 modelconfiguraties, inclusief analyse van de impact van redenering (+think) en tool-gebruik (+tool) op verschillende modelgroottes.
3. Inzicht in Evaluatieformaten: Een fundamenteel inzicht dat MCQ en Free-Response complementaire maar verschillende facetten van kennis meten, waarbij MCQ snel verzadigt terwijl Free-Response nuance blijft bieden.

4. Resultaten

De evaluatie leverde vier opvallende bevindingen op:

• MCQ Prestaties (Verzadiging):
  • De nauwkeurigheid bij meerkeuzevragen bereikt een plafond bij modellen van 3B parameters en groter.
  • De beste modellen (zoals GPT-5-Mini en Qwen3-Coder 30B) halen bijna perfecte scores (99,2%).
  • Boven de 3B-grens leiden grotere parametergroottes nauwelijks tot significante verbeteringen in MCQ-scores.
• Free-Response Prestaties (Continu Differentiëren):
  • In tegenstelling tot MCQ, blijven de scores voor open vragen stijgen naarmate het model groter wordt en verschillen ze modellen ook binnen dezelfde grootteklasse.
  • De "Implement"-niveaus (procedurale kennis) tonen de grootste spreiding (1,36 tot 4,54), wat aantoont dat generatieve evaluatie essentieel is voor het testen van hogere orde architecturale competenties.
• Invloed van Augmentatie:
  • +think (Redeneren): Verbeterde over het algemeen de kwaliteit van open antwoorden (+0,15 tot +0,42), maar kon de MCQ-prestaties verstoren bij modellen die al dicht bij het plafond zaten (over-denken leidde tot fouten). Bij zeer kleine modellen (1B) kon redeneren de MCQ-score echter verdubbelen.
  • +tool (Tools): Tool-gebruik leidde tot prestatieachteruitgang bij kleine modellen (<8B parameters), vaak door foutieve tool-aanroepen of eindeloze zoeklussen. Pas bij modellen van ongeveer 8B of groter werd tool-gebruik effectief.
• Vertrouwen (Conviction):
  • Een unaniem antwoord (alle drie de runs hetzelfde) had een nauwkeurigheid van 89,5%, terwijl verdeelde meerderheden slechts 55,0% nauwkeurig waren. Dit suggereert dat "unanimity" een betrouwbare indicator is voor vertrouwen in productieomgevingen.

5. Betekenis en Implicaties

• Voor Praktijk: Het vertrouwen op alleen meerkeuzevragen om de capaciteiten van LLMs voor architectuur te beoordelen, leidt tot een overschatting van hun vaardigheden. Voor architecturale taken (ontwerp en implementatie) zijn open vragen noodzakelijk.
• Modelkeuze: Voor basisvragen (recall/analyse) zijn kleine modellen (3B+) al zeer betrouwbaar. Voor complexe ontwerptaken en implementatie zijn grotere modellen (zoals Mistral 14B of GPT-5) nodig, of menselijk toezicht.
• Tooling: De integratie van tools in LLM-assistenten vereist een minimum aan modelcapaciteit (ca. 8B parameters) om effectief te zijn; bij kleinere modellen kan dit contraproductief zijn.
• Toekomst: De studie benadrukt dat evaluatieformaten de meetresultaten fundamenteel beïnvloeden. Toekomstig werk moet zich richten op het uitbreiden van de benchmark naar klassieke architectuurpatronen en meertalige settings.

Conclusie: CAKE toont aan dat terwijl LLMs uitstekend zijn in het "weten" van feiten (MCQ), hun vermogen om architecturale kennis toe te passen en te genereren (Free-Response) sterk afhankelijk is van modelgrootte, trainingdata en de juiste augmentatiestrategieën.