Online vs offline LLM-evaluering: Hvilken du skal bruge (og hvornår)

Online vs offline LLM-evaluering: Hvilken du skal bruge (og hvornår)

Online vs offline LLM-evaluering er én beslutning, ikke to, og vores promptfoo-setup beviste det i tirsdags: én omskrevet systemprompt, 47 testcases, faithfulness ned fra 0,91 til 0,74 på cirka 90 sekunder CI-tid. Offline-tjekket fangede den regression før merge; produktionsovervågning ville have mødt den senere, forklædt som en supporttråd. Offline mod online, samme dom: to spor, forskellige job.

Offline LLM-evaluering kører din model mod et fast datasæt før deploy og beviser, at en ændring ikke ødelagde den målte kvalitet. Online-evaluering scorer live produktionstrafik efter lancering og afslører det, datasættet aldrig indeholdt. De fleste team har brug for begge, sekventieret: offline vogter deployet, online fanger drift.

Nøglepointer

• Offline-evaluering kører mod et fast datasæt før deploy; online-evaluering scorer live trafik efter lancering.
• De fleste team har brug for begge: offline vogter deploy, online fanger det, datasættet missede.
• Offline fanger promptregressioner og formatbrud; online fanger drift, latens under belastning og integrationsejendommeligheder.
• Kobl offline-evalueringer som en CI-merge-gate; strømm online-scoringer fra produktionsspor ind i dit evalueringssæt.

Hvordan adskiller online og offline evaluering sig faktisk? (9 dimensioner)

De to tilstande adskiller sig på ni akser, men den afgørende er datakilden: offline-evaluering scorer et fast, versioneret datasæt før deploy, mens online-evaluering scorer live trafik efter lancering. Alle andre forskelle, omkostning, latens, risiko, styring, følger af det skel.

Label Studios læringscenter rammer parret som komplementære tilstande frem for rivaler, og vi er enige. Tabellen udvider den ramme med LLM-specifikke metrikker, som deres generiske ML-version ikke dækker.

Vores tolkning: offline-kolonnen besvarer "ødelagde denne ændring noget?", og online-kolonnen besvarer "driver produktionen væk fra det, vi testede?". Metriktyper-rækken er dér, hvor de to skiller mest; vores guide til LLM-evalueringsmetrikker gennemgår hver enkelt.

Hvad fanger hver tilstand, og hvad falder igennem begge?

Hver tilstand ejer en privat fejlklasse, den anden ikke kan se. Offline fanger ændringer, du selv lavede; online fanger ændringer, verden lavede omkring dig. De dyre fejl, dem der overlever begge net, kræver en menneskelig anmelder. Denne taksonomi er vores syntese af, hvad hver tilstand rapporterer, ikke en publiceret standard.

Kun-offline-kvadranten er dér, hvor CI-gates tjener deres løn: en omskrevet prompt, der stille sænker formatoverholdelse fra 99% til 91%, er usynlig i code review og åbenlys i en 47-case suite. Kun-online-kvadranten er mere lumsk. Rigtige brugere formulerer ting, dit golden-sæt aldrig gjorde, tredjeparts-API'er timer ud på tidspunkter, staging aldrig rammer, og nogen vil fodre din chatbot en prompt på 40.000 tegn bare for at se, hvad der sker. Til den side dækker vores guide til evaluering af agenter i produktion scoring af flertrins-trajektorier, ikke bare enkelte output.

Den nederste række er den, team springer over, og den der brænder dem. De fejl, der koster dig brugere, er dem, ingen af tilstandene fanger alene. De kræver et menneske i loopet.

Hvordan kobler du offline-evalueringer ind i en CI-gate? (Konfigurationen ingen viser)

Tilføj en eval-runner som et påkrævet status-tjek på hver pull request, der rører en prompt, model eller retrieval-konfiguration. Hæv en tærskel. Blokér merge under den. promptfoo dokumenterer præcis dette CI-mønster, og det er det, vi kører.

GitHub Actions-trinnet

En nedbarberet version af den gate, vi kører i dag:

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

YAML-konfigurationen erklærer testcases og assertions; eval afslutter med non-zero, når suiten falder under tærsklen, GitHub markerer det påkrævede tjek som fejlet, og merge-knappen bliver grå. paths-filteret betyder noget: et README-fix bør ikke brænde judge-tokens af.

Hvad gaten faktisk fanger

Den live version scorer vores support-agent RAG-kæde mod 47 golden-cases på hver prompt-påvirkende PR. En fuld kørsel tager cirka 90 sekunder CI-tid, og merge blokeres automatisk, hvis faithfulness falder under 0,82. På tre måneder har den fanget to regressioner, der ellers ville være blevet shipped: en omskrivning af systemprompten, der skubbede faithfulness fra 0,91 til 0,74, og en retriever-ændring, der fordoblede kontekstlængden og trak answer relevancy under tærsklen. Ingen af dem så farlige ud i review.

En faithfulness-gate i CI koster 90 sekunder pr. PR. En faithfulness-regression i produktion koster dig en supporttråd og en rollback.

Vi sammenlignede de runnere, du kan sætte i dette mønster, promptfoo, DeepEval og resten, i vores roundup af LLM-evalueringsværktøjer.

Hvilke værktøjer kører hvilken tilstand? (Værktøj-til-tilstand-matrix)

Intet enkelt værktøj ejer begge spor rent. promptfoo og DeepEval er offline-første runnere, der kan score eksporterede produktionsdata på et schedule; Langfuse og LangSmith er online-første trace-lagre, der monterer LLM-as-judge-scorere på ingestede traces. Matrixen er vores læsning af hver leverandørs dokumentation: tolkning, ikke evangelium.

Vælg promptfoo eller DeepEval, hvis dit første behov er en merge-gate, der blokerer dårlige prompter i CI. Vælg Langfuse eller LangSmith, hvis dit første behov er at score live trafik, og vores sammenligning af Langfuse mod LangSmith går i dybden med det valg. OpenAI Evals forbliver den særling: en registry-lignende offline-runner uden produktionsside.

promptfoo vogter dine PR'er. Langfuse scorer dine produktionsspor. Ingen af dem erstatter den anden.

Hvordan vender feedbackloopet online-fejl til offline-tests?

Sample lavt scorende produktionsspor, label dem, og commit dem til offline-evalueringssættet. Regressionssuiten vokser så med hver overraskelse, produktionen smider efter dig, og det næste deploy gates på det udvidede sæt. Svinghjulsrammen er vores; det er den del, de fleste team aldrig bygger.

Cyklussen, som vi kører den:

1. Online-scorere flagger traces under en judge-score på 0,7.
2. Vi sampler 20 til 30 flaggede traces om ugen.
3. Et menneske labeler hver enkelt: forventet output plus fejlklasse.
4. Labelde cases slutter sig til offline-evalueringssættet som nye golden-eksempler.
5. Den næste PR kører mod den udvidede suite, og loopet genstarter.

Sampling starter i dit LLM-observability-lag, fordi traces er råmaterialet. Om kadence: ugentligt slår månedligt, fordi drift akkumuleres. Vi labeler 10 til 15 cases om ugen, og sættet er "stort nok", når nye labels holder op med at flytte beståelsesraten, omkring 150 til 250 cases for en smal support-agent. Skellet mellem tilstandene bliver ved med at udviskes: Deepchecks rapporterer, at Union.ai-ingeniører scheduler deres "offline"-evalueringer hvert par minutter, hvilket reelt gør dem til næsten-realtids-tjek.

Dit evalueringssæt er ikke et fast artefakt. Det vokser hver uge, produktionen overrasker dig.

Hvornår har du brug for begge? (Online vs offline LLM-evaluering efter fase)

Du har brug for begge fra lanceringsugen og frem, men balancen skifter efter fase: offline bærer arbejdet før deploy alene, lanceringsugen tilføjer shadow- eller canary-scoring, steady state læner sig op ad online-overvågning med periodiske offline-genkørsler, og en drift-alarm bør ende i en reproduceret offline-test plus et større evalueringssæt.

Før deploy er det billigste sted at være streng: en blokeret merge koster minutter; en dårlig release koster tillid. Lanceringsugen er dér, team underinvesterer, selvom shadow-scoring på en lille trafikskive koster lidt og afslører, om golden-sættet løj. Steady state er dér, selvtilfredsheden sniger sig ind, så sæt gen-evalueringen i kalenderen.

Hvad med EU AI Act?

EU AI Act's højrisiko-forpligtelser fases ind frem til august 2026, med den fulde deadline-tidslinje publiceret på EUR-Lex, og overensstemmelsesmønstret mapper rent over på de to tilstande. Dokumenteret offline-materiale viser, at systemet opfyldte kvalitetsmål før release; løbende online-overvågning viser, at det bliver ved med at opfylde dem efter. Vores læsning er, at et auditrail har brug for begge artefakter, fordi offline-logs alene ikke beviser, at systemet forblev compliant, og dashboards alene ikke beviser, at det blev lanceret compliant. Det er tolkning, ikke juridisk rådgivning; vores LLM-evalueringspipeline-pillar mapper det fulde kravssæt.

Offline-evaluering er dit bevis. Online-evaluering er dit tidligt-varslingssystem. Regulatorer vil have begge.

Om forfatteren: Mert Batur er medstifter af Techsy.io, hvor teamet shipper AI-agenter, automatiseringssystemer og voice/SDR-pipelines til B2B-kunder. Han skriver om den LLM-værktøjsstak, Techsy-teamet faktisk bruger i produktionen. Forbind på LinkedIn.

Ofte stillede spørgsmål

Hvad er offline LLM-evaluering?

Offline LLM-evaluering kører en model eller prompt mod et fast, versioneret datasæt før deploy. Typiske tjek inkluderer faithfulness over for hentet kontekst, answer relevancy, formatoverholdelse og benchmark-scorer. Fordi datasættet aldrig ændrer sig midt i en kørsel, er resultaterne repeterbare og diffbare, hvilket er præcis derfor offline-suites fungerer som CI-merge-gates.

Hvad er online LLM-evaluering?

Online LLM-evaluering scorer live produktionstrafik efter lancering. En LLM-as-judge-scorer vurderer samplede traces for hallucination, tone eller tool-call-korrekthed, og scorerne strømmer til et dashboard. Den optager også signaler, som offline-tests ikke kan se: latens under belastning, brugerfeedback og hvordan rigtige forespørgsler adskiller sig fra dit golden-sæt.

Hvornår skal jeg bruge offline vs online LLM-evaluering?

Brug offline-evaluering til at gate deploy: hver prompt-, model- eller retrieval-ændring bør bestå suiten før merge. Brug online-evaluering til at overvåge det, der shipper. De fleste team sekventierer begge frem for at vælge én: offline først, online fra lanceringsugen og frem, med produktionsfejl, der flyder tilbage i offline-sættet.

Hvad er et eksempel på online vs offline LLM-evaluering?

Offline-eksempel: en promptfoo-suite kører 200 golden-supportspørgsmål på hver pull request og blokerer merge, hvis faithfulness falder under 0,82. Online-eksempel: Langfuse scorer 10% af live traces med et LLM-as-judge hallucinationstjek og alarmerer, når ugegennemsnittet dykker. Samme rubric, forskellige datakilder.

Hvordan passer human-in-the-loop ind i LLM-evaluering?

Mennesker lukker det gab, ingen af tilstandene dækker: nye edge cases, subjektive kvalitetsvurderinger og drift i brand voice. En praktisk kadence er at label 10 til 20 samplede lav-score-traces om ugen og committe de labelde cases til offline-evalueringssættet. Review-køen er et pipeline-input, ikke et sideprojekt.

Hvordan fungerer Langfuse-evalueringer til online-scoring?

Langfuse ingester traces fra din applikation og vedhæfter derefter LLM-as-judge-evaluatorer, der scorer hvert trace mod en rubric: hallucination, relevans, toksicitet eller en brugerdefineret prompt. Scorerne lander på et dashboard nøglet til sessioner og brugere. Team eksporterer vedvarende lav-score-traces til et offline-datasæt til regressionstest. Vores roundup af observability-platforme sammenligner de trace-lagre, der føder dette mønster.

Hvordan tilføjer jeg offline-evalueringer til en CI/CD-pipeline?

Tilføj en eval-runner som et påkrævet status-tjek på pull requests, der rører prompter, modeller eller retrieval-konfiguration. Både promptfoo og DeepEval kører headless og afslutter med non-zero ved assertion-fejl, hvilket blokerer merge automatisk. YAML-gaten tidligere i dette indlæg er en arbejdende skabelon; start med 30 til 50 cases.

Kræver EU AI Act offline eller online evaluering?

Reelt begge. For højrisikosystemer forventer loven dokumenteret bevis for, at kvalitetsmål blev opfyldt før release, hvilket betyder offline-artefakter, plus løbende overvågning efter deploy, hvilket betyder online-telemetri. Dens fasede deadlines løber frem til august 2026 ifølge EUR-Lex. Det er vores læsning af overensstemmelsesmønstret, ikke juridisk rådgivning.

Kan LLM-as-a-judge køre i både offline og online tilstand?

Ja, og det bør den, fordi rubric'en overføres. Offline scorer judgen hvert output i evalueringssættet i batch under CI. Online scorer den samme judge-prompt samplede produktionstraces i næsten realtid. At holde én rubric på tværs af begge tilstande er det, der gør din offline-baseline sammenlignelig med dit online-driftssignal.

Hvilke metrikker adskiller sig mellem offline og online evaluering?

Offline-metrikker måler outputkvalitet mod ground truth: faithfulness, answer relevancy, formatoverholdelse, benchmark-scorer. Online-metrikker tilføjer drifts- og adfærdssignaler: p95-latens, fejlrate, hallucinationsrate på live trafik, drift-score og brugertilfredshed. Offline-listen spørger "er den god?", og online-listen spørger "er den stadig god?".

Den korte version

• Offline og online evaluering er komplementære spor, ikke enten/eller: den ene vogter det, du shipper, den anden overvåger det, du har shipped.
• Start med CI-gaten i denne uge, tilføj online trace-scoring ved lancering, og kobl feedbackloopet, før dit evalueringssæt bliver forældet.
• Loopet er systemet. Et statisk golden-datasæt rådner; et voksende akkumulerer.

Hvis du vil have et ekstra par øjne på din evalueringspipeline, få en gratis konsultation.