Online vs Offline LLM-Utvärdering: Vilken du Behöver (och När)

Online vs offline LLM-utvärdering: vilken du behöver (och när)

Online vs offline LLM-utvärdering är ett beslut, inte två, och vår promptfoo-svit bevisade det i tisdags: en omskriven systemprompt, 47 testfall, faithfulness ned från 0,91 till 0,74 på ungefär 90 sekunder CI-tid. Offlinekontrollen fångade regressionen innan merge; produktionsövervakning hade mött den senare, utklädd till ett supportärende. Offline vs online, samma slutsats: två filer, olika jobb.

Offline LLM-utvärdering kör din modell mot ett fast dataset innan deploy och bevisar att en ändring inte sänkte mätbar kvalitet. Onlineutvärdering poängsätter live produktionstrafik efter lansering och blottlägger det datasetet aldrig innehöll. De flesta team behöver båda, i sekvens: offline grindar deployn, online fångar datadriften.

Nyckelpoänger

• Offlineutvärdering körs mot ett fast dataset före deploy; onlineutvärdering poängsätter live trafik efter lansering.
• De flesta team behöver båda: offline grindar deploys, online fångar det datasetet missade.
• Offline fångar promptregressioner och formatbrott; online fångar datadrift, latens under last och integrationsegenheter.
• Koppla in offline-evals som en merge-grind i CI; strömma onlinepoäng från produktionstraces till ditt eval-set.

Hur skiljer sig online- och offlineutvärdering egentligen åt? (9 dimensioner)

De två lägena skiljer sig på nio axlar, men den avgörande är datakällan: offlineutvärdering poängsätter ett fast, versionerat dataset före deploy, medan onlineutvärdering poängsätter live trafik efter lansering. Alla andra skillnader, kostnad, latens, risk, styrning, följer av den delningen.

Label Studios lärcenter ramar in paret som kompletterande lägen snarare än rivaler, och vi håller med. Tabellen utökar den ramen med LLM-specifika mätvärden som deras generiska ML-version inte täcker.

Vår tolkning: offlinekolumnen svarar på "har den här ändringen förstört något?", och onlinekolumnen svarar på "driver produktionen bort från det vi testade?". Raden med mätvärdestyper är där de två skiljer sig som mest; vår guide om LLM-utvärderingsmätvärden går igenom varje mätvärde.

Vad fångar varje läge, och vad faller genom båda?

Varje läge äger en privat felklass som det andra inte kan se. Offline fångar ändringar du gjorde; online fångar ändringar världen gjorde runt dig. De dyra felen, de som överlever båda näten, behöver en mänsklig granskare. Den här taxonomin är vår syntes av vad varje läge rapporterar, inte en publicerad standard.

Offline-kvadranten är där CI-grindar tjänar sitt lönekuvert: en omskriven prompt som tyst sänker formatefterlevnaden från 99 % till 91 % är osynlig i kodgranskning och uppenbar i en 47 fall stor svit. Online-kvadranten är lömskare. Riktiga användare formulerar saker ditt golden-set aldrig gjorde, tredjeparts-API:er timeoutar enligt scheman som staging aldrig träffar, och någon kommer att mata din chattbot med en 40 000 tecken lång prompt bara för att se vad som händer. För den sidan täcker vår guide om att utvärdera agenter i produktion poängsättning av flerstegstrajektorier, inte bara enstaka utdata.

Den nedersta raden är den team hoppar över, och den som bränner dem. Felen som kostar dig användare är de som inget läge fångar ensamt. De behöver en människa i loopen.

Hur kopplar man in offline-evals i en CI-grind? (Konfiggen ingen visar)

Lägg till en eval-runner som en obligatorisk statuskontroll på varje pull request som rör en prompt, modell eller retrieval-konfig. Sätt en tröskel. Blockera merge under den. promptfoo dokumenterar exakt detta CI-mönster, och det är det vi kör.

GitHub Actions-steget

En nedbantad version av grinden vi kör idag:

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-konfiggen deklarerar testfallen och assertionerna; eval avslutar med icke-nollkod när sviten faller under tröskeln, GitHub markerar den obligatoriska statuskontrollen som misslyckad och merge-knappen grånar. paths-filtret spelar roll: en README-fix ska inte bränna domartokens.

Vad grinden faktiskt fångar

Den skarpa versionen poängsätter vår supportagent-RAG-kedja mot 47 golden-fall på varje PR som påverkar prompten. En full körning tar ungefär 90 sekunder CI-tid, och merge blockeras automatiskt om faithfulness sjunker under 0,82. På tre månader har den fångat två regressioner som annars hade skeppats: en omskrivning av systemprompten som pressade faithfulness från 0,91 till 0,74, och en retriever-ändring som fördubblade kontextlängden och drog answer relevancy under tröskeln. Ingen av dem såg farlig ut i granskning.

En faithfulness-grind i CI kostar 90 sekunder per PR. En faithfulness-regression i produktion kostar dig ett supportärende och en rollback.

Vi jämförde runnarna du kan koppla in i det här mönstret, promptfoo, DeepEval och resten, i vår genomgång av LLM-utvärderingsverktyg.

Vilka verktyg kör vilket läge? (Verktyg-till-läge-matris)

Inget enskilt verktyg äger båda filerna rent. promptfoo och DeepEval är offline-först-runnare som kan poängsätta exporterad produktionsdata på schema; Langfuse och LangSmith är online-först-tracelagringar som bultar fast LLM-as-a-judge-poängsättare på inlästa traces. Matrisen är vår läsning av varje leverantörs dokumentation: tolkning, inte sanning.

Välj promptfoo eller DeepEval om ditt första behov är en merge-grind som blockerar dåliga promptar i CI. Välj Langfuse eller LangSmith om ditt första behov är att poängsätta live trafik, och vår jämförelse av Langfuse vs LangSmith går på djupet med det valet. OpenAI Evals förblir det udda kortet: en registerliknande offline-runner utan produktionssida.

promptfoo grindar dina PR:er. Langfuse poängsätter dina produktionstraces. Inget ersätter det andra.

Hur gör feedback-loopen onlinefel till offlinetester?

Sampla lågpoängade produktionstraces, labela dem och committa dem till offline-eval-setet. Regressionssviten växer då med varje överraskning produktionen bjuder på, och nästa deploy grindas mot den utökade sviten. Svänghjulsramen är vår; det är delen de flesta team aldrig bygger.

Cykeln, som vi kör den:

1. Online-poängsättare flaggar traces under 0,7 i domarpoäng.
2. Vi samplar 20 till 30 flaggade traces i veckan.
3. En människa labelar varje fall: förväntad utdata plus felklass.
4. Labelade fall går in i offline-eval-setet som nya golden-exempel.
5. Nästa PR körs mot den utökade sviten, och loopen startar om.

Samplingen börjar i ditt LLM-observabilitets-lager, eftersom traces är råmaterialet. Om kadens: veckovis slår månadsvis, eftersom drift räntar på. Vi labelar 10 till 15 fall i veckan, och setet är "tillräckligt stort" när nya labels slutar flytta godkännandegraden, runt 150 till 250 fall för en smal supportagent. Gränsen mellan lägena fortsätter att suddas ut: Deepchecks rapporterar att Union.ai-ingenjörer schemalägger sina "offline"-utvärderingar med några minuters mellanrum, vilket i praktiken gör dem till nära-realtidskontroller.

Ditt eval-set är ingen fast artefakt. Det växer varje vecka produktionen överraskar dig.

När behöver du båda? (Online vs offline LLM-utvärdering per fas)

Du behöver båda från lanseringsveckan och framåt, men balansen förskjuts per fas: offline bär arbetet före deploy ensam, lanseringsveckan lägger till shadow- eller canary-poängsättning, stabilt läge lutar sig mot onlineövervakning med periodiska offline-omkörningar, och ett driftlarm bör sluta i ett reproducerat offlinetest plus ett större eval-set.

Före deploy är den billigaste platsen att vara strikt: en blockerad merge kostar minuter; en dålig release kostar förtroende. Lanseringsveckan är där team underinvesterar, trots att shadow-poängsättning på en liten trafikskiva kostar lite och avslöjar om golden-setet ljög. I stabilt läge infinner sig självbelåtenheten, så sätt omkörningen i kalendern.

Vad händer med EU:s AI-lag?

EU:s AI-lags högrisksskyldigheter fasas in fram till augusti 2026, med den fullständiga deadlinetidslinjen publicerad på EUR-Lex, och överensstämmelsemönstret mappas rent på de två lägena. Dokumenterade offlinebevis visar att systemet uppnådde kvalitetsmålen före release; pågående onlineövervakning visar att det fortsätter uppnå dem efteråt. Vår läsning är att ett granskningsspår behöver båda artefakterna, eftersom offlineloggar ensamma inte bevisar att systemet förblev kompatibelt, och dashboards ensamma inte bevisar att det lanserades kompatibelt. Det är tolkning, inte juridisk rådgivning; vår huvudguide om LLM-utvärderingspipelines mappar hela kravuppsättningen.

Offlineutvärdering är dina bevis. Onlineutvärdering är ditt tidiga varningssystem. Regulatorer vill ha båda.

Om författaren: Mert Batur är medgrundare av Techsy.io, där teamet levererar AI-agenter, automationssystem och röst-/SDR-pipelines för B2B-kunder. Han skriver om LLM-verktygsstacken som Techsy-teamet faktiskt använder i produktion. Följ honom på LinkedIn.

Vanliga frågor

Vad är offline LLM-utvärdering?

Offline LLM-utvärdering kör en modell eller prompt mot ett fast, versionerat dataset före deploy. Typiska kontroller innefattar faithfulness mot hämtad kontext, answer relevancy, formatefterlevnad och benchmark-poäng. Eftersom datasetet aldrig ändras mitt i en körning är resultaten repeterbara och diffbara, vilket är exakt varför offline-sviter fungerar som CI-merge-grindar.

Vad är online LLM-utvärdering?

Online LLM-utvärdering poängsätter live produktionstrafik efter lansering. En LLM-as-a-judge-poängsättare betygsätter samplade traces för hallucination, tonfall eller korrekthet i verktygsanrop, och poängen strömmas till en dashboard. Den tar också upp signaler som offlinetester inte kan se: latens under last, användarfeedback och hur riktiga frågor skiljer sig från ditt golden-set.

När ska jag använda offline vs online LLM-utvärdering?

Använd offlineutvärdering för att grinda deploys: varje prompt-, modell- eller retrieval-ändring ska passera sviten före merge. Använd onlineutvärdering för att övervaka det som skeppas. De flesta team sekvenserar båda istället för att välja en: offline först, online från lanseringsveckan och framåt, med produktionsfel som flödar tillbaka till offline-setet.

Vad är ett exempel på online vs offline LLM-utvärdering?

Offline-exempel: en promptfoo-svit kör 200 golden-supportfrågor på varje pull request och blockerar merge om faithfulness sjunker under 0,82. Online-exempel: Langfuse poängsätter 10 % av live traces med en LLM-as-a-judge-hallucinationskontroll och larmar när veckomedelvärdet sjunker. Samma bedömningsmall, olika datakälla.

Hur passar human-in-the-loop in i LLM-utvärdering?

Människor stänger gapet som inget läge täcker: nya edge cases, subjektiva kvalitetsbedömningar och varumärkesröstdrift. En praktisk kadens är att labela 10 till 20 samplade lågpoängade traces i veckan och committa de labelade fallen till offline-eval-setet. Granskningskön är en pipeline-input, inte ett sidoprojekt.

Hur fungerar Langfuse-utvärderingar för online-poängsättning?

Langfuse läser in traces från din applikation och fäster sedan LLM-as-a-judge-evaluatorer som poängsätter varje trace mot en bedömningsmall: hallucination, relevans, toxicitet eller en anpassad prompt. Poängen hamnar på en dashboard kopplad till sessioner och användare. Team exporterar ihållande lågpoängade traces till ett offlinedataset för regressionstestning. Vår genomgång av observabilitetsplattformar jämför tracelagringarna som matar det här mönstret.

Hur lägger jag till offline-evals i en CI/CD-pipeline?

Lägg till en eval-runner som en obligatorisk statuskontroll på pull requests som rör promptar, modeller eller retrieval-konfig. Både promptfoo och DeepEval kör headless och avslutar med icke-nollkod vid assertion-fel, vilket blockerar merge automatiskt. YAML-grinden tidigare i det här inlägget är en fungerande mall; börja med 30 till 50 fall.

Kräver EU:s AI-lag offline- eller onlineutvärdering?

I praktiken båda. För högriskssystem förväntar sig lagen dokumenterade bevis på att kvalitetsmålen uppnåddes före release, vilket betyder offlineartefakter, plus pågående övervakning efter deploy, vilket betyder onlinetelemetri. Dess fasade deadlines löper fram till augusti 2026 enligt EUR-Lex. Det är vår läsning av överensstämmelsemönstret, inte juridisk rådgivning.

Kan LLM-as-a-judge köras i både offline- och onlineläge?

Ja, och det bör den, eftersom bedömningsmallen överförs. Offline poängsätter domaren varje eval-set-utdata i batch under CI. Online poängsätter samma domarprompt samplade produktionstraces i nära realtid. Att hålla en enda bedömningsmall över båda lägena är vad som gör din offline-baslinje jämförbar med din online-driftsignal.

Vilka mätvärden skiljer sig mellan offline- och onlineutvärdering?

Offlinemätvärden mäter utdatakvalitet mot facit: faithfulness, answer relevancy, formatefterlevnad, benchmark-poäng. Onlinemätvärden lägger till operativa och beteendemässiga signaler: p95-latens, felfrekvens, hallucinationsfrekvens på live trafik, driftpoäng och användarnöjdhet. Offlinelistan frågar "är den bra?" och onlinelistan frågar "är den fortfarande bra?"

Den korta versionen

• Offline- och onlineutvärdering är kompletterande filer, inte antingen/eller: den ena grindar det du skeppar, den andra övervakar det du skeppat.
• Börja med CI-grinden den här veckan, lägg till online-trace-poängsättning vid lansering och koppla feedback-loopen innan ditt eval-set blir inaktuellt.
• Loopen är systemet. Ett statiskt golden-dataset ruttnar; ett växande räntar.

Om du vill ha ett par extra ögon på din eval-pipeline, boka en gratis konsultation.