Online vs offline LLM-evaluatie: welke heb je nodig (en wanneer)?

Online vs offline LLM-evaluatie: welke heb je nodig (en wanneer)?

Online vs offline LLM-evaluatie is één beslissing, geen twee, en onze promptfoo-suite bewees het vorige week dinsdag: één herschreven systeemprompt, 47 testcases, faithfulness van 0,91 naar 0,74 in pakweg 90 seconden CI-tijd. De offline check ving die regressie vóór de merge; productiemonitoring had hem later opgepikt, verkleed als supportthread. Offline of online, hetzelfde oordeel: twee banen, andere taken.

Offline LLM-evaluatie draait je model tegen een vaste dataset vóór deployment en bewijst dat een wijziging de gemeten kwaliteit niet brak. Online evaluatie scoort live productietraffic na lancering en legt bloot wat de dataset nooit bevatte. De meeste teams hebben beide nodig, in die volgorde: offline gatet de deploy, online vangt de drift.

Belangrijkste punten

• Offline evaluatie draait tegen een vaste dataset vóór deploy; online evaluatie scoort live verkeer na lancering.
• De meeste teams hebben beide nodig: offline gatet deploys, online vangt wat de dataset miste.
• Offline vangt promptregressies en formatbreuken; online vangt drift, latency onder belasting en integratie-eigenaardigheden.
• Koppel offline evals als CI-merge-gate; stream online scores uit productietraces je eval-set in.

Waarin verschillen online en offline evaluatie eigenlijk? (9 dimensies)

De twee modi verschillen op negen assen, maar de beslissende is de databron: offline evaluatie scoort een vaste, geversioneerde dataset vóór deploy, terwijl online evaluatie live verkeer scoort na lancering. Elk ander verschil (kosten, latency, risico, governance) volgt uit die scheiding.

Label Studio's learning center presenteert het paar als complementaire modi in plaats van rivalen, en daar zijn we het mee eens. De tabel breidt die framing uit met LLM-specifieke metrics die hun generieke ML-versie niet dekt.

Onze interpretatie: de offline kolom beantwoordt de vraag "heeft deze wijziging iets kapotgemaakt?", en de online kolom beantwoordt "drijft de productie weg van wat we getest hebben?". De rij over soorten metrics is waar de twee het hardst uiteenlopen; onze gids voor LLM-evaluatiemetrics splitst elke metric uit.

Wat vangt elke modus, en wat glipt door beide?

Elke modus heeft een eigen foutklasse die de andere niet kan zien. Offline vangt wijzigingen die jíj maakte; online vangt wijzigingen die de wereld om je heen maakte. De dure fouten, degene die beide netten overleven, vragen om een menselijke reviewer. Deze indeling is onze synthese van wat elke modus rapporteert, geen gepubliceerde standaard.

Het kwadrant "alleen offline" is waar CI-gates hun geld verdienen: een herschreven prompt die format-compliance stil laat zakken van 99% naar 91% is onzichtbaar in code review en overduidelijk in een 47-case suite. Het kwadrant "alleen online" is geniepiger. Echte gebruikers formuleren dingen die je golden set nooit deed, externe API's timen uit op schema's die staging nooit raakt, en iemand zal je chatbot een prompt van 40.000 tekens voeren, gewoon om te kijken wat er gebeurt. Voor die kant dekt onze gids over agents evalueren in productie het scoren van multi-step trajecten, niet alleen losse outputs.

De onderste rij is degene die teams overslaan, en degene die ze opbreekt. De fouten die je gebruikers kosten, zijn precies degene die geen van beide modi alleen vangt. Die hebben een mens in de loop nodig.

Hoe koppel je offline evals aan een CI-gate? (De configuratie die niemand laat zien)

Voeg een eval-runner toe als vereiste status check op elke pull request die een prompt, model of retrieval-configuratie raakt. Assert een drempel. Blokkeer de merge eronder. promptfoo documenteert exact dit CI-patroon, en het is degene die wij draaien.

De GitHub Actions-stap

Een uitgeklede versie van de gate die wij vandaag draaien:

name: llm-eval-gate

on:
  pull_request:
    paths: ["prompts/**", "evals/**", "src/rag/**"]

jobs:
  faithfulness-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Run offline evals, fail the PR on regression
        run: npx promptfoo@latest eval --config evals/support-agent.yaml
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}  # LLM-as-judge

De YAML-config declareert de testcases en de assertions; eval sluit af met niet-nul wanneer de suite onder de drempel zakt, GitHub markeert de vereiste check als gefaald en de merge-knop wordt grijs. Het paths-filter doet ertoe: een README-fix moet geen judge-tokens verbranden.

Wat de gate echt vangt

De live versie scoort onze support-agent RAG-keten tegen 47 golden cases bij elke prompt-rakende PR. Een volledige run duurt ongeveer 90 seconden CI-tijd, en de merge blokkeert automatisch als faithfulness onder 0,82 zakt. In drie maanden heeft hij twee regressies gevangen die anders uitgerold waren: een herschreven systeemprompt die faithfulness van 0,91 naar 0,74 duwde, en een retriever-wijziging die de contextlengte verdubbelde en answer relevancy onder de drempel trok. Geen van beide zag er gevaarlijk uit in review.

Een faithfulness-gate in CI kost 90 seconden per PR. Een faithfulness-regressie in productie kost je een supportthread en een rollback.

We vergeleken de runners die je in dit patroon kunt plakken, promptfoo, DeepEval en de rest, in onze roundup van LLM-evaluatietools.

Welke tools draaien welke modus? (Tool-naar-modusmatrix)

Geen enkele tool bezit beide banen netjes. promptfoo en DeepEval zijn offline-first runners die geëxporteerde productiedata op schema kunnen scoren; Langfuse en LangSmith zijn online-first trace-opslag die LLM-as-judge-scorers op geïngesteerde traces bouten. De matrix is onze lezing van de docs van elke vendor: interpretatie, geen evangelie.

Kies promptfoo of DeepEval als je eerste behoefte een merge-gate is die slechte prompts in CI blokkeert. Kies Langfuse of LangSmith als je eerste behoefte het scoren van live verkeer is, en onze Langfuse vs LangSmith-vergelijking gaat diep op die keuze in. OpenAI Evals blijft de buitenbeent: een registry-stijl offline runner zonder productiekant.

promptfoo gatet je PR's. Langfuse scoort je productietraces. Geen van beide vervangt de andere.

Hoe zet de feedbackloop online fouten om in offline tests?

Sample laag scorende productietraces, label ze en commit ze naar de offline eval-set. De regressiesuite groeit dan met elke verrassing die productie je voorschotelt, en de volgende deploy wordt gegatet op de uitgebreide set. De vliegwiel-framing is van ons; het is het deel dat de meeste teams nooit bouwen.

De cyclus, zoals wij hem draaien:

1. Online scorers vlaggen traces onder een 0,7 judge-score.
2. We samplen 20 tot 30 gevlagde traces per week.
3. Een mens labelt elk exemplaar: verwachte output plus foutklasse.
4. Gelabelde cases komen als nieuwe golden examples in de offline eval-set.
5. De volgende PR draait tegen de uitgebreide suite en de loop herstart.

Sampling begint bij je LLM-observability-laag, want traces zijn de grondstof. Over cadans: wekelijks wint van maandelijks, want drift compundeert. We labelen 10 tot 15 cases per week, en de set is "groot genoeg" wanneer nieuwe labels de slagingsratio niet meer bewegen, rond 150 tot 250 cases voor een smalle support-agent. De grens tussen modi blijft vervagen: Deepchecks meldt dat engineers van Union.ai hun "offline" evaluaties om de paar minuten inplannen, wat ze effectief tot near-real-time checks maakt.

Je eval-set is geen vast artefact. Hij groeit elke week dat productie je verrast.

Wanneer heb je beide nodig? (Online vs offline LLM-evaluatie per fase)

Je hebt beide nodig vanaf lanceerweek, maar de balans verschuift per fase: offline draagt het pre-deploy-werk alleen, lanceerweek voegt shadow- of canary-scoring toe, steady state leunt op online monitoring met periodieke offline re-runs, en een drift-alert zou moeten eindigen in een gereproduceerde offline test plus een grotere eval-set.

Pre-deploy is de goedkoopste plek om streng te zijn: een geblokkeerde merge kost minuten; een slechte release kost vertrouwen. Lanceerweek is waar teams te weinig investeren, terwijl shadow-scoring op een klein stukje verkeer weinig kost en onthult of de golden set loog. Steady state is waar zelfgenoegzaamheid toeslaat, dus zet de herevaluatie in je agenda.

Hoe zit het met de EU AI Act?

De high-risk-verplichtingen van de EU AI Act faseren in tot augustus 2026, met de volledige deadlinetijdlijn gepubliceerd op EUR-Lex, en het conformiteitspatroon mapt schoon op de twee modi. Gedocumenteerd offline bewijs toont dat het systeem kwaliteitsdoelen haalde vóór release; doorlopende online monitoring toont dat het ze daarna blijft halen. Onze lezing is dat een audittrail beide artefacten nodig heeft, want offline logs alleen bewijzen niet dat het systeem compliant bleef, en dashboards alleen bewijzen niet dat het compliant lanceerde. Dat is interpretatie, geen juridisch advies; onze LLM-evaluatiepijplijn-pillar mapt de volledige vereistenset.

Offline evaluatie is je bewijs. Online evaluatie is je vroegwaarschuwingssysteem. Toezichthouders willen beide.

Over de auteur: Mert Batur is Co-Founder van Techsy.io, waar het team AI-agents, automatiseringssystemen en voice/SDR-pijplijnen voor B2B-klanten uitrolt. Hij schrijft over de LLM-toolingstack die het Techsy-team daadwerkelijk in productie draait. Verbind op LinkedIn.

Veelgestelde vragen

Wat is offline LLM-evaluatie?

Offline LLM-evaluatie draait een model of prompt tegen een vaste, geversioneerde dataset vóór deployment. Gangbare checks zijn faithfulness aan opgehaalde context, answer relevancy, format-compliance en benchmarkscores. Omdat de dataset tijdens een run nooit verandert, zijn resultaten herhaalbaar en diffbaar, precies waarom offline suites werken als CI-merge-gates.

Wat is online LLM-evaluatie?

Online LLM-evaluatie scoort live productietraffic na lancering. Een LLM-as-judge-scorer beoordeelt gesamplede traces op hallucinatie, toon of tool-call-correctheid, en de scores stromen naar een dashboard. Het pakt ook signalen op die offline tests niet zien: latency onder belasting, gebruikersfeedback en hoe echte queries afwijken van je golden set.

Wanneer gebruik ik offline vs online LLM-evaluatie?

Gebruik offline evaluatie om deploys te gaten: elke prompt-, model- of retrieval-wijziging moet door de suite vóór de merge. Gebruik online evaluatie om te monitoren wat uitgerold is. De meeste teams draaien beide in volgorde in plaats van één te kiezen: eerst offline, online vanaf lanceerweek, met productiefouten die terugstromen in de offline set.

Wat is een voorbeeld van online vs offline LLM-evaluatie?

Offline voorbeeld: een promptfoo-suite draait 200 golden supportvragen bij elke pull request en blokkeert de merge als faithfulness onder 0,82 zakt. Online voorbeeld: Langfuse scoort 10% van de live traces met een LLM-as-judge hallucinatie-check en alert wanneer het weekgemiddelde zakt. Dezelfde rubric, andere databron.

Hoe past human-in-the-loop in LLM-evaluatie?

Mensen dichten het gat dat geen van beide modi dekt: nieuwe edge cases, subjectieve kwaliteitsoordelen en brand-voice-drift. Een praktische cadans is 10 tot 20 gesamplede laag-scorende traces per week labelen en de gelabelde cases committen naar de offline eval-set. De reviewwachtrij is een pipeline-input, geen sideproject.

Hoe werken Langfuse-evaluaties voor online scoring?

Langfuse neemt traces van je applicatie in en koppelt er LLM-as-judge-evaluators aan die elke trace tegen een rubric scoren: hallucinatie, relevantie, toxiciteit of een custom prompt. Scores landen op een dashboard gekoppeld aan sessies en gebruikers. Teams exporteren structureel laag scorende traces naar een offline dataset voor regressietests. Onze roundup van observabilityplatforms vergelijkt de trace-opslag die dit patroon voedt.

Hoe voeg ik offline evals toe aan een CI/CD-pipeline?

Voeg een eval-runner toe als vereiste status check op pull requests die prompts, modellen of retrieval-configuratie raken. promptfoo en DeepEval draaien beide headless en sluiten af met niet-nul bij een gefaalde assertion, wat de merge automatisch blokkeert. De YAML-gate eerder in dit artikel is een werkend sjabloon; begin met 30 tot 50 cases.

Vereist de EU AI Act offline of online evaluatie?

Effectief beide. Voor high-risk systemen verwacht de Act gedocumenteerd bewijs dat kwaliteitsdoelen gehaald zijn vóór release, wat offline artefacten betekent, plus doorlopende monitoring na deployment, wat online telemetrie betekent. De gefaseerde deadlines lopen tot augustus 2026 volgens EUR-Lex. Dat is onze lezing van het conformiteitspatroon, geen juridisch advies.

Kan LLM-as-a-judge in zowel offline als online modus draaien?

Ja, en dat moet ook, want de rubric reist mee. Offline scoort de judge elke eval-set-output in batch tijdens CI. Online scoort dezelfde judge-prompt gesamplede productietraces in near real time. Eén rubric over beide modi aanhouden is wat je offline baseline vergelijkbaar maakt met je online driftsignaal.

Welke metrics verschillen tussen offline en online evaluatie?

Offline metrics meten outputkwaliteit tegen ground truth: faithfulness, answer relevancy, format-compliance, benchmarkscores. Online metrics voegen operationele en gedragsmatige signalen toe: p95-latency, foutpercentage, hallucinatieratio op live verkeer, driftscore en gebruikerstevredenheid. De offline lijst vraagt "is het goed?" en de online lijst vraagt "is het nog steeds goed?".

De korte versie

• Offline en online evaluatie zijn complementaire banen, geen of-of: de ene gatet wat je uitrolt, de andere bewaakt wat je uitgerold hebt.
• Begin deze week met de CI-gate, voeg online trace-scoring toe bij lancering en koppel de feedbackloop voordat je eval-set veroudert.
• De loop is het systeem. Een statische golden dataset vergaat; een groeiende compundeert.

Wil je een tweede paar ogen op je eval-pijplijn? Plan een gratis adviesgesprek.