Online vs offline LLM-evaluering: Hvilken du trenger (og når)

Online vs offline LLM-evaluering: Hvilken du trenger (og når)

Online vs offline LLM-evaluering er én beslutning, ikke to, og promptfoo-oppsettet vårt beviste det forrige tirsdag: én omskrevet systemprompt, 47 testcases, faithfulness ned fra 0,91 til 0,74 på omtrent 90 sekunder CI-tid. Offline-sjekken fanget den regresjonen før merge; produksjonsovervåking ville ha møtt den senere, forkledd som en supporttråd. Offline vs online, samme dom: to løyper, ulike jobber.

Offline LLM-evaluering kjører modellen mot et fast datasett før deploy, og beviser at en endring ikke ødela målt kvalitet. Online-evaluering scorer live produksjonstrafikk etter lansering, og avdekker det datasettet aldri inneholdt. De fleste team trenger begge, sekvensiert: offline vokter deployen, online fanger opp drift.

Nøkkelpoeng

• Offline-evaluering kjører mot et fast datasett før deploy; online-evaluering scorer live trafikk etter lansering.
• De fleste team trenger begge: offline vokter deployer, online fanger det datasettet gikk glipp av.
• Offline fanger promptregresjoner og formatbrudd; online fanger drift, latens under last og integrasjonssæregenheter.
• Koble offline-evalueringer som en CI-merge-gate; strømm online-scorer fra produksjonsspor inn i evalueringssettet ditt.

Hvordan skiller egentlig online og offline evaluering seg? (9 dimensjoner)

De to modusene skiller seg på ni akser, men den avgjørende er datakilden: offline-evaluering scorer et fast, versjonert datasett før deploy, mens online-evaluering scorer live trafikk etter lansering. Alle andre forskjeller, kostnad, latens, risiko og styring, følger av det skillet.

Label Studios læringssenter definerer paret som komplementære moduser snarere enn rivaler, og vi er enige. Tabellen utvider den rammen med LLM-spesifikke metrikker som den generiske ML-versjonen deres ikke dekker.

Vår tolkning: offline-kolonnen svarer på «øydela denne endringen noe?», og online-kolonnen svarer på «driver produksjonen bort fra det vi testet?». Metrikktyper-raden er der de to skiller seg hardest; guiden vår om LLM-evalueringsmetrikker bryter ned hver enkelt.

Hva fanger hver modus, og hva faller gjennom begge?

Hver modus eier en privat feilklasse den andre ikke kan se. Offline fanger endringer du gjorde; online fanger endringer verden gjorde rundt deg. De dyre feilene, de som overlever begge nettene, trenger en menneskelig gjennomgang. Denne taksonomien er vår syntese av hva hver modus rapporterer, ikke en publisert standard.

Kun-offline-kvadranten er der CI-gater tjener sin plass: en omskrevet prompt som stille senker formatetterlevelse fra 99 % til 91 %, er usynlig i kodegjennomgang og åpenbar i en 47-sakers suite. Kun-online-kvadranten er mer lumsk. Ekte brukere formulerer ting gull-settet ditt aldri gjorde, tredjeparts-APIer timer ut etter en plan staging aldri treffer, og noen kommer til å fôre chatboten din en 40 000-tegns prompt bare for å se hva som skjer. For den siden dekker guiden vår om evaluering av agenter i produksjon scoring av flertrinns trajektorier, ikke bare enkeltoutputs.

Den nederste raden er den team hopper over, og den som brenner dem. Feilene som koster deg brukere, er de ingen av modusene fanger alene. De trenger et menneske i løkken.

Hvordan kobler du offline-evalueringer inn i en CI-gate? (Konfigen ingen viser)

Legg til en evalueringsrunner som en påkrevd statussjekk på hver pull request som berører en prompt, modell eller retrieval-konfig. Hevd en terskel. Blokker merge under den. promptfoo dokumenterer nøyaktig dette CI-mønsteret, og det er det vi kjører.

GitHub Actions-steget

En nedskalert versjon av gaten vi kjø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-konfigen erklærer testcasene og assertene; eval avslutter med ikke-null når suiten faller under terskelen, GitHub markerer den påkrevde sjekken som feilet, og merge-knappen blir grå. paths-filteret betyr noe: en README-fiks bør ikke brenne dommer-tokens.

Hva gaten faktisk fanger

Live-versjonen scorer support-agent-RAG-kjeden vår mot 47 gull-cases på hver prompt-påvirkende PR. En full kjøring tar omtrent 90 sekunder CI-tid, og merge blokkeres automatisk hvis faithfulness faller under 0,82. På tre måneder har den fanget to regresjoner som ellers ville ha blitt shippet: en omskriving av systemprompten som presset faithfulness fra 0,91 til 0,74, og en retriever-endring som doblet kontekstlengden og dro svarrelevans under terskelen. Ingen av dem så farlige ut i gjennomgang.

En faithfulness-gate i CI koster 90 sekunder per PR. En faithfulness-regresjon i produksjon koster deg en supporttråd og en rollback.

Vi sammenlignet runnerne du kan plugge inn i dette mønsteret, promptfoo, DeepEval og resten, i rundtaket vårt om LLM-evalueringsverktøy.

Hvilke verktøy kjører hvilken modus? (Verktøy-til-modus-matrise)

Ingen enkeltverktøy eier begge løypene rent. promptfoo og DeepEval er offline-første runnere som kan score eksporterte produksjonsdata etter en plan; Langfuse og LangSmith er online-første sporlagre som bolter LLM-as-judge-scorere på inntatte spor. Matrisen er vår lesning av hvert leverandørs dokumentasjon: tolkning, ikke evangelium.

Velg promptfoo eller DeepEval hvis det første behovet ditt er en merge-gate som blokkerer dårlige prompter i CI. Velg Langfuse eller LangSmith hvis det første behovet er å score live trafikk, og sammenligningen vår om Langfuse vs LangSmith går i dybden på det valget. OpenAI Evals forblir den rare: en registristil offline-runner uten produksjonsside.

promptfoo vokter PR-ene dine. Langfuse scorer produksjonssporene dine. Ingen erstatter den andre.

Hvordan gjør tilbakemeldingsløkken online-feil om til offline-tester?

Sample lavt-scorende produksjonsspor, merk dem og commit dem til offline-evalueringssettet. Regresjonssuiten vokser da med hver overraskelse produksjonen kaster på deg, og neste deploy voktes mot det utvidede settet. Svinghjul-rammen er vår; det er delen de fleste team aldri bygger.

Syklusen, slik vi kjører den:

1. Online-scorere flagger spor under 0,7 i dommer-score.
2. Vi sampler 20 til 30 flaggede spor per uke.
3. Et menneske merker hvert: forventet output pluss feilklasse.
4. Merkede saker blir med i offline-evalueringssettet som nye gull-eksempler.
5. Neste PR kjører mot den utvidede suiten, og løkken starter på nytt.

Sampling starter i LLM-observabilitets-laget ditt, fordi spor er råmaterialet. Om kadens: ukentlig slår månedlig, fordi drift akkumuleres. Vi merker 10 til 15 saker i uken, og settet er «stort nok» når nye merkelapper slutter å flytte beståelsesraten, rundt 150 til 250 saker for en smal support-agent. Skillet mellom modusene viskes stadig ut: Deepchecks rapporterer at Union.ai-ingeniører planlegger «offline»-evalueringene sine hvert par minutt, noe som i praksis gjør dem til nær-sanntids sjekker.

Evalueringssettet ditt er ikke en fast artefakt. Det vokser hver uke produksjonen overrasker deg.

Når trenger du begge? (Online vs offline LLM-evaluering etter fase)

Du trenger begge fra lanseringsuken og fremover, men balansen skifter etter fase: offline bærer jobben før deploy alene, lanseringsuken legger til shadow- eller canary-scoring, stabil drift lener seg på online-overvåking med periodiske offline-omkjøringer, og en driftsalarm bør ende i en reprodusert offline-test pluss et større evalueringssett.

Før deploy er det billigste stedet å være streng: en blokkert merge koster minutter; en dårlig utgivelse koster tillit. Lanseringsuken er der team underinvesterer, selv om shadow-scoring på en liten trafikkskive koster lite og avslører om gull-settet løy. Stabil drift er der selvtilfredsheten setter inn, så sett re-evalueringen i kalenderen.

Hva med EUs AI Act?

Høyrisiko-forpliktelsene i EUs AI Act fases inn frem til august 2026, med den fulle tidsplanen for frister publisert på EUR-Lex, og samsvarsmønsteret mapper rent på de to modusene. Dokumenterte offline-bevis viser at systemet oppfylte kvalitetsmål før utgivelse; løpende online-overvåking viser at det fortsetter å oppfylle dem etterpå. Vår lesning er at et revisjonsspor trenger begge artefakter, fordi offline-logger alene ikke beviser at systemet forble i samsvar, og dashbord alene ikke beviser at det ble lansert i samsvar. Det er tolkning, ikke juridisk rådgivning; søylen vår om LLM-evalueringspipeline mapper det fulle kravsettet.

Offline-evaluering er beviset ditt. Online-evaluering er tidligvarslingssystemet ditt. Regulatorer vil ha begge.

Om forfatteren: Mert Batur er medgrunnlegger av Techsy.io, der teamet shipper AI-agenter, automatiseringssystemer og tale-/SDR-pipelines for B2B-kunder. Han skriver om LLM-verktøystacken Techsy-teamet faktisk bruker i produksjon. Koble til på LinkedIn.

Ofte stilte spørsmål

Hva er offline LLM-evaluering?

Offline LLM-evaluering kjører en modell eller prompt mot et fast, versjonert datasett før deploy. Typiske sjekker inkluderer faithfulness til hentet kontekst, svarrelevans, formatetterlevelse og benchmark-scorer. Fordi datasettet aldri endres midt i en kjøring, er resultatene repeterbare og diffbare, som er nøyaktig hvorfor offline-suiter fungerer som CI-merge-gater.

Hva er online LLM-evaluering?

Online LLM-evaluering scorer live produksjonstrafikk etter lansering. En LLM-as-judge-scorer vurderer samplede spor for hallusinasjon, tone eller verktøykall-korrekthet, og scorene strømmer til et dashbord. Den absorberer også signaler offline-tester ikke kan se: latens under last, brukertilbakemeldinger og hvordan ekte spørringer skiller seg fra gull-settet ditt.

Når bør jeg bruke offline vs online LLM-evaluering?

Bruk offline-evaluering for å vokte deployer: hver prompt-, modell- eller retrieval-endring bør bestå suiten før merge. Bruk online-evaluering for å overvåke det som shipper. De fleste team sekvensierer begge i stedet for å velge én: offline først, online fra lanseringsuken og fremover, med produksjonsfeil som flyter tilbake til offline-settet.

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

Offline-eksempel: en promptfoo-suite kjører 200 gull-supportspørsmål på hver pull request og blokkerer merge hvis faithfulness faller under 0,82. Online-eksempel: Langfuse scorer 10 % av live spor med en LLM-as-judge-hallusinasjonssjekk og varsler når ukegjennomsnittet glipper. Samme rubrikk, ulik datakilde.

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

Mennesker tetter gapet ingen av modusene dekker: nye grensetilfeller, subjektive kvalitetsvurderinger og drift i merkevarestemme. En praktisk kadens er å merke 10 til 20 samplede lav-score-spor per uke og committe de merkede sakene til offline-evalueringssettet. Gjennomgangskøen er en pipeline-input, ikke et sideprosjekt.

Hvordan fungerer Langfuse-evalueringer for online-scoring?

Langfuse inntar spor fra applikasjonen din og fester deretter LLM-as-judge-evaluatorer som scorer hvert spor mot en rubrikk: hallusinasjon, relevans, toksisitet eller en egendefinert prompt. Scorene lander på et dashbord knyttet til sesjoner og brukere. Team eksporterer vedvarende lavt-scorende spor til et offline-datasett for regresjonstesting. Rundtaket vårt om observabilitetsplattformer sammenligner sporlagrene som mater dette mønsteret.

Hvordan legger jeg til offline-evalueringer i en CI/CD-pipeline?

Legg til en evalueringsrunner som en påkrevd statussjekk på pull requests som berører prompter, modeller eller retrieval-konfig. Både promptfoo og DeepEval kjører headless og avslutter med ikke-null ved assert-feil, noe som blokkerer merge automatisk. YAML-gaten tidligere i dette innlegget er en fungerende mal; start med 30 til 50 saker.

Krever EUs AI Act offline eller online evaluering?

I praksis begge. For høyrisikosystemer forventer loven dokumenterte bevis på at kvalitetsmål ble oppfylt før utgivelse, som betyr offline-artefakter, pluss løpende overvåking etter deploy, som betyr online-telemetri. De fasede fristene løper frem til august 2026 ifølge EUR-Lex. Det er vår lesning av samsvarsmønsteret, ikke juridisk rådgivning.

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

Ja, og det bør den, fordi rubrikken overføres. Offline scorer dommeren hvert evalueringssett-output i batch under CI. Online scorer den samme dommer-prompten samplede produksjonsspor i nær sanntid. Å holde én rubrikk på tvers av begge moduser er det som gjør offline-baselinjen din sammenlignbar med online-driftsignalet ditt.

Hvilke metrikker skiller seg mellom offline og online evaluering?

Offline-metrikker måler outputkvalitet mot fasit: faithfulness, svarrelevans, formatetterlevelse, benchmark-scorer. Online-metrikker legger til drifts- og atferdssignaler: p95-latens, feilrate, hallusinasjonsrate på live trafikk, drifts-score og brukertilfredshet. Offline-listen spør «er den god?», og online-listen spør «er den fortsatt god?»

Den korte versjonen

• Offline og online evaluering er komplementære løyper, ikke et enten/eller: den ene vokter det du shipper, den andre overvåker det du shippet.
• Start med CI-gaten denne uken, legg til online-spor-scoring ved lansering, og koble tilbakemeldingsløkken før evalueringssettet ditt blir foreldet.
• Løkken er systemet. Et statisk gull-datasett råtner; et voksende akkumulerer.

Hvis du vil ha et par ekstra øyne på evalueringspipelinen din, få en gratis konsultasjon.