Deel:𝕏LinkedInRedditFacebookKopieer link

Instructievolgzaamheid kwantificeren via IFEval

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 6 augustus 2026

Bij het evalueren van grote taalmodellen (LLM's) ligt de focus vaak op kennisretentie, logisch redeneren of taalkundige vloeiendheid. Hoewel deze eigenschappen cruciaal zijn voor generieke chatbots, schieten traditionele benchmarks tekort wanneer een model in een geautomatiseerde softwarepijplijn moet opereren. In dergelijke scenario's is de cruciale vraag niet alleen of het model het juiste antwoord weet, maar of het antwoord exact voldoet aan de meegegeven structuur en randvoorwaarden. Dit aspect wordt aangeduid als instructievolgzaamheid (instruction-following).

Systemen die afhankelijk zijn van gestructureerde data-extractie, geautomatiseerde codegeneratie of specifieke formattering vereisen een model dat instructies tot op de letter nauwkeurig uitvoert. IFEval (Instruction Following Evaluation) is ontworpen om dit specifieke gedrag objectief en reproduceerbaar te meten. In dit artikel wordt dieper ingegaan op de werking van IFEval, hoe dit verschilt van andere evaluatiemethoden, en hoe je deze principes toepast binnen een eigen software-architectuur.

Wat is instructievolgzaamheid en waarom staat het los van kennis?

Het is belangrijk om een scherp onderscheid te maken tussen de feitelijke juistheid van een antwoord en de mate waarin een model instructies opvolgt. Een model kan over uitzonderlijke vakkennis beschikken, maar toch onbruikbaar zijn in een productieomgeving als het structurele restricties negeert. Stel dat een prompt vraagt: "Geef een samenvatting van het stikstofbeleid in exact drie alinea's, zonder gebruik te maken van de letter 'e', en start de laatste alinea met het woord 'Concluderend'."

Een model dat een feitelijk perfecte samenvatting geeft van vier alinea's waarin tientallen keren de letter 'e' voorkomt, heeft inhoudelijk een correct antwoord geleverd, maar faalt volledig op het gebied van instructievolgzaamheid. In toepassingen waarin de uitvoer van een LLM direct doorgegeven wordt aan een parser of database, leiden zulke afwijkingen tot systeemfouten.

Binnen de bredere context van modeltesten helpt het om te begrijpen hoe dit type evaluatie zich verhoudt tot algemene scoreborden. Voor een breder perspectief op het interpreteren van algemene modelprestaties kun je ons artikel over benchmarks lezen raadplegen. Waar klassieke benchmarks zich richten op 'wat' het model weet, richt IFEval zich op 'hoe' het model de output structureert.

Het kernidee achter IFEval: Verifieerbare instructies

Traditionele methoden om complexe tekstgeneratie te beoordelen leunen vaak op menselijke annotatoren of grotere taalmodellen die als rechter optreden (LLM-as-a-judge). Beide methoden introduceren ruis, subjectiviteit en inconsistentie. IFEval lost dit op door uitsluitend gebruik te maken van objectief verifieerbare instructies (verifiable instructions). Dit zijn opdrachten waarvan de correctheid niet afhangt van semantische interpretatie, maar deterministisch kan worden vastgesteld met behulp van eenvoudige programmacode.

IFEval richt zich op zogeheten 'heuristische constraints'. Dit zijn specifieke regels die met reguliere expressies (regex) of eenvoudige algoritmen gecontroleerd kunnen worden. Enkele categorieën van dergelijke instructies zijn:

Doordat de evaluatie via code verloopt, is de meting volledig reproduceerbaar. Er is geen sprake van bias en de kosten voor het draaien van de benchmark zijn minimaal in vergelijking met het inzetten van menselijke beoordelaars of API-calls naar commerciële jury-modellen.

Strikte versus losse scoring

IFEval rapporteert prestaties over het algemeen via twee verschillende methodologieën: *strict scoring* (strikte scoring) en *loose scoring* (losse scoring). Het verschil tussen beide is essentieel om de praktische inzetbaarheid van een model te beoordelen.

Aspect Strikte Scoring (Strict) Losse Scoring (Loose)
Behandeling van witruimte Telt exact mee; extra regeleinden kunnen leiden tot afkeuring. Wordt genormaliseerd (trimmings van spaties en witregels).
Interpunctie en Casing Exacte match vereist, inclusief hoofdletters en punten. Vaak case-insensitive en negeert kleine interpunctieverschillen.
Conversatie-opvulling Modeluitingen zoals "Natuurlijk, hier is het:" leiden direct tot falen. Kan door heuristieken worden weggefilterd voor de controle.
Toepassing Kritieke API-koppelingen en parsers. Interactieve chatbots voor menselijke eindgebruikers.

In een productieomgeving waarin JSON-pockets direct uit de tekst gefilterd moeten worden, is strikte scoring de enige metriek die ertoe doet. Als een model de neiging heeft om beleefdheidsformules toe te voegen ("Hier is het gevraagde schema: ..."), breekt de strikte parser, ook al is de uiteindelijke JSON inhoudelijk correct. Losse scoring is daarentegen waardevol als de output bedoeld is voor een menselijke lezer die niet struikelt over een extra spatie of een ontbrekende hoofdletter.

Prompt-niveau versus instructie-niveau nauwkeurigheid

Een cruciaal aspect van IFEval is de manier waarop scores worden berekend. De benchmark maakt onderscheid tussen twee detailniveaus:

1. Prompt-niveau nauwkeurigheid (Prompt-level accuracy)

Hierbij wordt gekeken of een model voldoet aan *alle* gestelde eisen binnen één prompt. Als een prompt drie verschillende instructies bevat (bijvoorbeeld: schrijf in het Nederlands, gebruik maximaal 150 woorden, en vermijd de letter 'e') en het model voldoet aan slechts twee van de drie, dan is de score voor die prompt een nul (0). Deze metriek is binair en geeft aan hoe betrouwbaar het model is bij complexe, samengestelde opdrachten.

2. Instructie-niveau nauwkeurigheid (Instruction-level accuracy)

Deze metriek kijkt naar het percentage individuele instructies dat succesvol is uitgevoerd, ongeacht of ze in dezelfde prompt stonden. In het bovenstaande voorbeeld zou het model een score van 66,7% (2 van de 3) behalen. Deze score geeft een genuanceerder beeld van de capaciteiten van het model en helpt ontwikkelaars te begrijpen of een model 'bijna' functioneel is, of dat het systematisch specifieke typen instructies negeert.

Modellen vertonen vaak een sterke daling in prompt-niveau nauwkeurigheid naarmate het aantal constraints per prompt toeneemt. Dit fenomeen benadrukt de noodzaak om bij de inrichting van applicaties instructies zo veel mogelijk op te delen of gebruik te maken van specifieke technieken om invoer en uitvoer te structureren.

Zelf een verifieerbare instructieset opbouwen

Om de betrouwbaarheid van LLM's binnen een specifiek bedrijfsdomein te garanderen, is het raadzaam om een eigen, domeinspecifieke variant van IFEval op te zetten. Dit stelt je in staat om regressietesten uit te voeren telkens wanneer er een prompt, modelversie of systeemarchitectuur verandert. Voor een gestructureerde aanpak hiervan kun je het stappenplan voor een eigen benchmark opzetten raadplegen.

Het bouwen van een eigen evaluatieset bestaat uit drie stappen: het selecteren van instructietypen, het schrijven van deterministische verificatiefuncties, en het inrichten van de testloop.

Stap 1: Definieer de constraints

Richt je op constraints die direct invloed hebben op jouw applicatie. Als je data extraheert om een database te vullen, focus dan op JSON-validatie, XML-tags en datatypes. Als je blogposts genereert, focus dan op woordlimieten en paragraafstructuren.

Stap 2: Schrijf de verificatiecode

Hieronder staat een voorbeeld van een Python-verificatiefunctie die controleert of een modeluitvoer voldoet aan drie specifieke criteria: het moet exact drie alinea's bevatten, mag geen uitroeptekens bevatten, en moet eindigen met een specifieke zin.

def test_instructie_volgzaamheid(model_output: str) -> dict:
    # Restrictie 1: Exact drie alinea's (gescheiden door dubbele regeleinden)
    paragraphs = [p.strip() for p in model_output.strip().split('\n\n') if p.strip()]
    constraint_paragraphs = len(paragraphs) == 3

    # Restrictie 2: Geen uitroeptekens
    constraint_no_exclamation = "!" not in model_output

    # Restrictie 3: Eindigen met een specifieke zin (negeer trailing whitespace)
    expected_ending = "Dit is het einde van de samenvatting."
    clean_output = model_output.strip().rstrip('.')
    clean_expected = expected_ending.rstrip('.')
    constraint_ending = clean_output.endswith(clean_expected)

    return {
        "score_prompt_niveau": int(constraint_paragraphs and constraint_no_exclamation and constraint_ending),
        "details": {
            "drie_alineas": constraint_paragraphs,
            "geen_uitroeptekens": constraint_no_exclamation,
            "juiste_afsluiting": constraint_ending
        }
    }

Door dit type code uit te voeren over een testset van bijvoorbeeld honderd unieke prompts, genereer je een betrouwbaar beeld van de prestaties van het model zonder dat daar handmatige controle voor nodig is.

Valkuilen bij het ontwerpen van instructietests

Bij het opzetten van een evaluatiesysteem gebaseerd op IFEval-principes liggen enkele subtiele valkuilen op de loer. Het niet onderkennen van deze factoren kan leiden tot foutieve testresultaten en onterechte conclusies over modelprestaties.

Tegenstrijdige of overmatige eisen

Het is eenvoudig om prompts te ontwerpen die onbedoeld tegenstrijdige opdrachten bevatten. Een prompt die vraagt om "een samenvatting van exact 50 woorden" en tegelijkertijd eist dat er "minimaal 5 specifieke kernconcepten uitgebreid worden toegelicht", dwingt het model in een onmogelijke spagaat. Dit meet niet de instructievolgzaamheid, maar het vermogen van het model om te gaan met logische paradoxen.

Taalafhankelijke verificatieregels

Veel IFEval-implementaties zijn oorspronkelijk in het Engels geschreven. Bij het vertalen of aanpassen naar het Nederlands ontstaan er problemen met taalspecifieke eigenschappen. Denk aan:

Fouten in de verificatiecode zelf

Een veelvoorkomend probleem is dat de code die de controle uitvoert (de 'grader') zelf bugs bevat. Als de code bijvoorbeeld faalt op het correct parsen van unicode-karakters of regeleinden op Windows-systemen (`\r\n` versus `\n`), worden correcte modelantwoorden ten onrechte als fout gemarkeerd. Uitgebreide unit-tests voor de verificatiefuncties zijn daarom een vereiste.

Relatie met systeemprompts en output-afdwinging

De score die een model behaalt op een instructietest staat niet op zichzelf; deze is sterk afhankelijk van hoe de interactie met het model is vormgegeven. Twee belangrijke factoren spelen hierbij een rol: het ontwerp van de systeemprompt en het gebruik van programmatische afdwinging.

Een goed geformuleerde systeemprompt legt de basisregels vast waaraan het model zich moet houden gedurende de gehele sessie. Door restricties op te nemen in de systeemrol in plaats van de gebruikersrol, kan de stabiliteit van de output aanzienlijk worden verhoogd. Voor best practices op dit gebied kun je onze gids over systeemprompts raadplegen.

Wanneer absolute garanties nodig zijn voor de structuur van de output, is het bovendien onverstandig om uitsluitend te vertrouwen op de instructievolgzaamheid van het model zelf. In kritieke systemen combineer je prompts met schema-validatie en geforceerde JSON-structuren. Het toepassen van deze technieken vermindert de afhankelijkheid van de ruwe modelprestaties. Meer informatie over hoe je dit implementeert, vind je in de artikelen over output-formaten afdwingen en het gebruik van api-gebaseerde structured output.

Wat betekent een lage score in de praktijk?

Als een model tijdens een IFEval-meting laag scoort op instructievolgzaamheid, heeft dit directe consequenties voor de architectuur van de software waarin het model is geïntegreerd. Het simpelweg accepteren van de output is dan geen optie. Ontwikkelaars moeten in dat geval mitigerende maatregelen treffen:

  1. Retry-mechanismen implementeren: Wanneer de verificatiecode detecteert dat de output niet voldoet aan de gestelde eisen, kan het systeem automatisch een nieuwe aanvraag indienen, eventueel met een aangepaste temperatuur (temperature-parameter).
  2. Zelfcorrectie-loops (Self-correction): De foutmelding van de verificatiecode kan worden teruggekoppeld aan het model ("Je output bevatte 4 alinea's in plaats van 3. Corrigeer dit."). Dit verhoogt de kans op een correcte output bij de tweede poging, al brengt dit extra latentie en API-kosten met zich mee.
  3. Robuuste parsers bouwen: In plaats van te eisen dat het model exact JSON levert zonder extra tekst, kan de parser zo worden ontworpen dat deze met regex de JSON-pockets uit een grotere lap tekst filtert. Dit vangt fouten op aan de ontvangende kant.

Integratie in regressietesten

Het meten van instructievolgzaamheid is geen eenmalige taak. Bij updates van LLM-providers, veranderingen in model-routing of aanpassingen in de applicatiecode kunnen prestaties onverwacht verschuiven. Het opnemen van IFEval-achtige tests in de CI/CD-pijplijn (Continuous Integration/Continuous Deployment) is daarom aan te raden.

Door bij elke codewijziging een vaste set van vijftig tot honderd verifieerbare prompts af te vuren op het model, voorkom je dat regressie ongemerkt de productieomgeving bereikt. Dit proces sluit nauw aan bij het opzetten van breder prompt-beheer. Lees voor een diepere duik in deze integratie ons artikel over regressietesten voor prompts.

Belangrijke afweging: Hoewel grotere modellen over het algemeen beter scoren op complexe instructiesets, kunnen kleinere, specifiek gefinetunede modellen (bijvoorbeeld via Direct Preference Optimization of reinforcement learning op instructietaken) vergelijkbare of betere resultaten behalen op specifieke formatteringstaken, tegen een fractie van de kosten.

Conclusie

IFEval biedt een methodisch antwoord op de uitdagingen van subjectieve LLM-evaluatie. Door te focussen op deterministisch controleerbare constraints, stelt het ontwikkelaars in staat om de betrouwbaarheid van taalmodellen in softwarepijplijnen objectief te kwantificeren. Of het nu gaat om het handhaven van lengtebeperkingen, het uitsluiten van specifieke woorden of het afdwingen van XML-structuren: het meten en monitoren van instructievolgzaamheid is een noodzakelijke stap voor elke organisatie die LLM's serieus in productie wil nemen.

Lees ook