{"id":3425319,"date":"2025-05-20T14:41:59","date_gmt":"2025-05-20T12:41:59","guid":{"rendered":"https:\/\/datanorth.ai\/blog\/evals-openais-framework-for-evaluating-llms"},"modified":"2026-09-18T11:13:42","modified_gmt":"2026-09-18T09:13:42","slug":"openai-evals-evalueren-van-llms","status":"publish","type":"post","link":"https:\/\/datanorth.ai\/nl\/blog\/openai-evals-evalueren-van-llms","title":{"rendered":"Evals: OpenAI’s eerdere standaard voor het evalueren van LLM’s"},"content":{"rendered":"\n

OpenAI Evals is een opensourceframework waarmee je grote taalmodellen, ook wel LLM’s, en AI-toepassingen kunt testen. Een eval bestaat uit een testinvoer, een verwacht resultaat of beoordelingsregel en de gemeten uitkomst. Daarmee beantwoord je een praktische vraag: voert deze versie van onze AI-toepassing de taak goed genoeg uit?<\/p>\n\n\n\n

OpenAI gebruikt de naam Evals ook voor zijn gehoste evaluatieplatform, dat wordt uitgefaseerd. Het onderscheid helpt je een werkwijze te kiezen die bruikbaar blijft wanneer je van model of tool wisselt.<\/p>\n\n\n\n

De huidige status van OpenAI Evals<\/h2>\n\n\n\n

Status gecontroleerd op 16 september 2026.<\/strong> Volgens OpenAI zijn bestaande evaluaties in het gehoste platform vanaf 31 oktober 2026 alleen nog te bekijken. Het Evals-dashboard en de API sluiten naar verwachting op 30 november 2026. Bekijk de actuele Evals-documentatie<\/a>. Deze aankondiging gaat over het gehoste product. Het oorspronkelijke opensourceframework en het evalueren van AI in algemene zin zijn afzonderlijke begrippen.<\/p>\n\n\n\n

Begrip<\/strong><\/th>Betekenis<\/strong><\/th>Waar je op let<\/strong><\/th><\/tr><\/thead>
Een eval<\/td>Een test van modelgedrag of een AI-toepassing<\/td>Leg vast welke taak goed moet gaan<\/td><\/tr>
OpenAI Evals-framework<\/td>Het opensourceproject met een register van evaluaties<\/td>Controleer afhankelijkheden en modelcompatibiliteit<\/td><\/tr>
Gehost Evals-platform<\/td>Het dashboard en de API van OpenAI voor evaluaties<\/td>Houd rekening met de aangekondigde sluiting<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Het oorspronkelijke OpenAI Evals-project<\/a> werkt met evaluatiedefinities en datasets. Bij de oorspronkelijke werkwijze horen YAML-configuraties en JSONL-bestanden. De introductie in het OpenAI Cookbook<\/a> is inmiddels als gearchiveerd gemarkeerd. Controleer daarom installatievoorbeelden en modelnamen voordat je ze overneemt.<\/p>\n\n\n\n

Voor bestaande gehoste evaluaties beschrijft OpenAI een overstap naar Promptfoo<\/a>. Daarbij maak je prompts, modelinstellingen, testgevallen en beoordelingsregels opnieuw aan en controleer je een nieuwe testrun. Vergelijk ook de beoordeling zelf: dezelfde bedoeling levert in een andere tool niet vanzelf dezelfde score op.<\/p>\n\n\n\n

Waarom je een taalmodel systematisch test<\/h2>\n\n\n\n

Een klantenservicebot kan een vriendelijk antwoord geven en een vraag toch naar de verkeerde afdeling sturen. Een documentassistent kan de juiste informatie noemen met een verwijzing naar het verkeerde document. Een goedkoper model kan eenvoudige vragen goed afhandelen, maar een verzoek om een medewerker missen.<\/p>\n\n\n\n

Met evals zie je zulke verschillen voordat je een aanpassing in gebruik neemt. Je vergelijkt modellen, prompts of wijzigingen in gekoppelde tools. Ook de proceseigenaar kan concreet beoordelen welke gevallen beter gaan, wat misgaat en welke fouten het zwaarst wegen.<\/p>\n\n\n\n

De uitkomst hangt af van je testset en beoordelingsregels. Een hoge score op eenvoudige voorbeelden zegt weinig over lastige klantvragen. Herhaal tests wanneer wisselende modelantwoorden bepalend kunnen zijn voor je keuze.<\/p>\n\n\n\n

Wat je bij een AI toepassing meet<\/h2>\n\n\n\n

Begin bij het gewenste gedrag. Een router moet de juiste afdeling kiezen, een kennisassistent moet antwoorden onderbouwen en een AI-agent moet eventuele toestemming voor handelingen respecteren.<\/p>\n\n\n\n

Toepassing<\/strong><\/th>Bruikbare controles<\/strong><\/th>Wat een totaalscore kan verbergen<\/strong><\/th><\/tr><\/thead>
Klantvragen verdelen<\/td>Juiste categorie en doorverwijzing<\/td>Een verzoek om een medewerker blijft bij de bot<\/td><\/tr>
Vragen over documenten<\/td>Juist antwoord en passende bron<\/td>Het antwoord verwijst naar het verkeerde document<\/td><\/tr>
Gegevens uitlezen<\/td>Geldige structuur en juiste veldwaarden<\/td>Geldige JSON met een onjuist factuurbedrag<\/td><\/tr>
AI-agent met tools<\/td>Juiste tool, invoer en afgeronde taak<\/td>Een wijziging zonder de vereiste toestemming<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Vaste controles<\/strong> zijn geschikt voor exacte labels, verplichte velden en rekenregels. Een AI-beoordelaar<\/strong> kan open antwoorden toetsen aan een rubric: een beschrijving van wat goed, onvoldoende of onacceptabel is. Laat mensen twijfelgevallen beoordelen en controleren of de automatische beoordeling aansluit op de praktijk. De documentatie over graders<\/a> beschrijft onder meer tekstcontroles, gelijkenisscores, modelbeoordeling en controles met Python.<\/p>\n\n\n\n

Beoordeel zichtbare antwoorden en handelingen. Een overtuigende uitleg bewijst niet dat het verborgen redeneerproces van een model klopt.<\/p>\n\n\n\n

Praktijkvoorbeeld voor een Nederlandse webshop<\/h2>\n\n\n\n

Stel dat een webshop een LLM gebruikt om berichten te verdelen. De labels in de applicatie zijn delivery, billing en manual_review: bezorging, facturatie en menselijke beoordeling. Een expliciet verzoek om een medewerker moet altijd naar manual_review. In dit voorbeeld geldt dat ook voor berichten die over zowel bezorging als facturatie gaan.<\/p>\n\n\n\n

Hieronder staan verzonnen testgevallen en uitkomsten ter illustratie<\/strong>. Het zijn geen gemeten resultaten van DataNorth of een specifiek model. Versie A stelt de huidige prompt voor, versie B een voorgestelde wijziging.<\/p>\n\n\n\n

Klantbericht<\/strong><\/th>Verwacht label<\/strong><\/th>A<\/strong><\/th>B<\/strong><\/th><\/tr><\/thead>
Waar blijft mijn pakket?<\/td>delivery<\/td>delivery<\/td>delivery<\/td><\/tr>
Het bedrag op mijn factuur klopt niet<\/td>billing<\/td>billing<\/td>billing<\/td><\/tr>
Ik wil een medewerker spreken<\/td>manual_review<\/td>manual_review<\/td>delivery<\/td><\/tr>
Dubbel betaald via iDEAL en mijn pakket is te laat<\/td>manual_review<\/td>billing<\/td>manual_review<\/td><\/tr>
Waar is bestelling 123?<\/td>delivery<\/td>billing<\/td>delivery<\/td><\/tr>
Mag ik een btw-factuur ontvangen?<\/td>billing<\/td>billing<\/td>billing<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Versie A heeft vier van de zes gevallen goed, oftewel 66,7%. Versie B heeft er vijf goed en komt op 83,3%. Toch mist B het expliciete verzoek om een medewerker. Als die doorverwijzing een voorwaarde voor ingebruikname is, voldoet B nog niet.<\/p>\n\n\n\n

De hogere totaalscore is dus onvoldoende om de wijziging goed te keuren. Je moet ook weten welke fouten zijn ontstaan en wat die voor de klant betekenen.<\/p>\n\n\n\n

\"Evals\"<\/figure>\n\n\n\n

Het voorbeeld controleren met Python<\/h3>\n\n\n\n

Dit zelfstandige Python-voorbeeld beoordeelt de getoonde uitkomsten van versie B. Het roept geen model aan en heeft geen API-sleutel nodig. Voor een echte test vervang je de uitkomsten door vastgelegde antwoorden van je toepassing.<\/p>\n\n\n\n

expected = [\n    \"delivery\", \"billing\", \"manual_review\",\n    \"manual_review\", \"delivery\", \"billing\",\n]\ncandidate = [\n    \"delivery\", \"billing\", \"delivery\",\n    \"manual_review\", \"delivery\", \"billing\",\n]\nassert len(candidate) == len(expected)\ncorrect = sum(a == b for a, b in zip(candidate, expected))\nprint(f\"Correct: {correct}\/{len(expected)}\")\nprint(\"Doorverwijzing correct:\", candidate[2] == expected[2])<\/code><\/pre>\n\n\n\n
De uitkomst is Correct: 5\/6 en Doorverwijzing correct: False. Je controleert hiermee de labels en \u00e9\u00e9n regel voor doorverwijzing. Antwoordkwaliteit, snelheid en het verdere gesprek vallen buiten deze test. Zes voorbeelden maken de aanpak duidelijk, maar zijn onvoldoende om de betrouwbaarheid in productie vast te stellen.<\/p>\n\n\n\n
Een evaluatie opzetten voor jouw organisatie<\/h2>\n\n\n\n
    \n
  1. Bepaal de beslissing.<\/strong> Leg vast welke keuze je met de evaluatie wilt onderbouwen. Mag een nieuwe prompt bijvoorbeeld de bestaande router vervangen? Spreek vooraf af welke fouten een introductie blokkeren.<\/li>\n\n\n\n
  2. Verzamel herkenbare testgevallen.<\/strong> Neem gewone vragen, onduidelijke formuleringen, ontbrekende informatie en eerder gemaakte fouten op. Laat iemand met proceskennis de gewenste uitkomst vastleggen. Gebruik Nederlandse klanttaal, inclusief afkortingen en typefouten. Een uitsluitend vertaalde Engelse testset mist mogelijk zulke variatie.<\/li>\n\n\n\n
  3. Houd ontwikkeling en beoordeling uit elkaar.<\/strong> Gebruik een deel van de voorbeelden om de prompt te verbeteren. Bewaar een ander deel voor de beoordeling. Leg vast welke voorbeelden tijdens het ontwikkelen beschikbaar waren, zodat je ziet of de oplossing vooral op die voorbeelden is afgestemd.<\/li>\n\n\n\n
  4. Vergelijk onder gelijke omstandigheden.<\/strong> Gebruik voor beide versies dezelfde beoordelingsset en regels. Bewaar de prompt, modelnaam, instellingen en relevante wijzigingen in de applicatie. Herhaal tests wanneer wisselende antwoorden de beslissing kunnen be\u00efnvloeden.<\/li>\n\n\n\n
  5. Bekijk fouten per categorie.<\/strong> Rapporteer doorverwijzingen los van gewone bezorgvragen. Beoordeel bij een kennisassistent ook welke documenten zijn opgehaald. Zo kun je een zoekprobleem onderscheiden van een fout in het uiteindelijke antwoord.<\/li>\n\n\n\n
  6. Onderhoud de tests na ingebruikname.<\/strong> Voeg nieuwe praktijkfouten toe als gecontroleerde testgevallen. Draai een gerichte selectie tijdens het ontwikkelen en een bredere set voor een release. Bewaar eerdere foutgevallen om te voorkomen dat ze terugkeren.<\/li>\n<\/ol>\n\n\n\n
    OpenAI noemt in zijn richtlijnen voor evaluaties<\/a> onder meer taakspecifieke tests, menselijke controle van beoordelaars en doorlopend evalueren. De stappen hierboven vertalen die principes naar een concrete beslissing over ingebruikname.<\/p>\n\n\n\n
    Kosten en vertrouwelijke gegevens<\/h2>\n\n\n\n
    Begroot de kosten van het geteste model, eventuele beoordelingsmodellen, tools en menselijke controle. Tweehonderd testgevallen, drie varianten en twee herhalingen betekenen 1.200 uitvoeringen van je toepassing. Aparte modelbeoordelingen komen daar nog bij.<\/p>\n\n\n\n
    Meet ook de reactietijd. Een nauwkeuriger antwoord dat tweemaal zo lang duurt, kan ongeschikt zijn voor live klantenservice. Bij een nachtelijke verwerking van documenten kan die afweging anders uitvallen.<\/p>\n\n\n\n
    Een afgeschermde testomgeving betekent niet automatisch dat alle gegevens daar blijven. Als je invoer naar een extern model of een externe beoordelaar stuurt, vindt ook daar verwerking plaats. Gebruik waar mogelijk verzonnen voorbeelden, verwijder overbodige persoonsgegevens en controleer waar prompts, antwoorden en testlogboeken worden opgeslagen. Neem zowel het geteste model als de beoordelingsdienst mee in die controle.<\/p>\n\n\n\n
    Aan de slag met een evaluatieplan<\/h2>\n\n\n\n
    Kies \u00e9\u00e9n belangrijk werkproces, leg vast welke fouten onacceptabel zijn en vergelijk de huidige toepassing met \u00e9\u00e9n voorgestelde wijziging. Hulp nodig bij de testgevallen of de interpretatie? Bekijk onze AI-consultancy<\/a> of bespreek je evaluatievraag met DataNorth<\/a>.<\/p>\n\n\n\n
    Veelgestelde vragen (FAQ) over Evals<\/h2>\n\n\n\n
    \n
    Wat is het verschil tussen een eval en een benchmark<\/strong><\/summary>\n
    Een eval is een gestructureerde evaluatie. Een benchmark is een gestandaardiseerde test of verzameling tests waarmee je prestaties vergelijkt. Publieke benchmarks kunnen helpen bij een eerste modelselectie. Je eigen evals laten zien hoe een model omgaat met jouw documenten, gebruikers en werkproces.<\/p>\n<\/details>\n\n\n\n
    Kan ik ook Claude of Gemini evalueren<\/strong><\/summary>\n
    Ja, met dezelfde evaluatiemethode kun je uitkomsten van verschillende aanbieders vergelijken. Je testtool heeft daarvoor een geschikte koppeling nodig. Controleer ondersteuning voor het model, de gebruikte tools en het antwoordformaat. Houd testgevallen en beoordelingsregels gelijk.<\/p>\n<\/details>\n\n\n\n
    Hoeveel testgevallen heb ik nodig<\/strong><\/summary>\n
    Daar is geen vast aantal voor. Begin met gecontroleerde voorbeelden van de belangrijkste situaties. Breid de set uit waar fouten of onzekerheid gevolgen hebben voor je beslissing. Rapporteer belangrijke categorie\u00ebn afzonderlijk. Honderd eenvoudige vragen zeggen weinig over een uitzondering die je nooit hebt getest.<\/p>\n<\/details>\n\n\n\n
    Voorkomen evals dat een model informatie verzint<\/strong><\/summary>\n
    Evals helpen ongefundeerde antwoorden op te sporen en te meten binnen je testset. Ze bieden geen garantie dat een toepassing nooit informatie verzint. Combineer de tests met passende broninformatie, controles in de applicatie en onderzoek naar fouten uit de praktijk.<\/p>\n<\/details>\n\n\n\n
    Is de gehoste Evals API nog geschikt voor een nieuw project<\/strong><\/summary>\n
    Kies een evaluatiewerkwijze die je ook na de aangekondigde sluiting kunt onderhouden. Bewaar datasets en beoordelingsregels in een overdraagbaar formaat. Bekijk de eerder genoemde migratiehandleiding voordat je tijd investeert in een gehoste integratie.<\/p>\n<\/details>\n<\/div>\n