Online vs. offline evaluace LLM: kterou potřebujete (a kdy)

Online vs. offline evaluace LLM: kterou potřebujete (a kdy)

Online vs. offline evaluace LLM je jedno rozhodnutí, ne dvě, a naše sada promptfoo to minulý úterý potvrdila: jeden přepsaný systémový prompt, 47 testovacích případů, věrnost dolů z 0,91 na 0,74 za zhruba 90 sekund CI času. Offline kontrola zachytila regresi ještě před merge; produkční monitoring by ji potkal později, převlečenou za ticket v podpoře. Offline vs. online, stejný verdikt: dva pruhy, různé úkoly.

Offline evaluace LLM spouští model proti pevně dané datové sadě před nasazením a dokazuje, že změna nerozbila měřenou kvalitu. Online evaluace hodnotí živý produkční provoz po spuštění a odhaluje to, co datová sada nikdy neobsahovala. Většina týmů potřebuje obojí, v daném pořadí: offline hlídá deploy, online zachytává drift.

Klíčové závěry

• Offline evaluace běží proti pevné datové sadě před deploy; online evaluace hodnotí živý provoz po spuštění.
• Většina týmů potřebuje obojí: offline hlídá deploys, online zachytává to, co datová sada minula.
• Offline zachytí regresí promptu a rozbité formáty; online zachytí drift, latenci pod zátěží a integrační zvláštnosti.
• Zapojte offline evaluace jako CI merge gate; streamujte online skóre z produkčních trace do vaší eval sady.

Jak se online a offline evaluace vlastně liší? (9 dimenzí)

Oba režimy se liší v devíti osách, ale rozhodující je zdroj dat: offline evaluace hodnotí pevnou, verzovanou datovou sadu před deploy, zatímco online evaluace hodnotí živý provoz po spuštění. Každý další rozdíl, náklady, latence, riziko, governance, z tohoto rozdělení vyplývá.

Vzdělávací centrum Label Studio popisuje tento pár jako komplementární režimy, ne jako soupeře, a my souhlasíme. Tabulka tento rámec rozšiřuje o metriky specifické pro LLM, které jejich obecná ML verze nepokrývá.

Naše interpretace: offline sloupec odpovídá na otázku „rozbila tato změna něco?" a online sloupec odpovídá na „odchyluje se produkce od toho, co jsme testovali?" Řádek typů metrik je místo, kde se oba režimy rozcházejí nejvíce; náš průvodce metrikami evaluace LLM každou z nich rozebírá.

Co každý režim zachytí a co propadne oběma?

Každý režim vlastní soukromou třídu selhání, kterou ten druhý nevidí. Offline zachytí změny, které jste provedli vy; online zachytí změny, které kolem vás udělal svět. Ta drahá selhání, která přežijí obě sítě, potřebují lidského recenzenta. Tato taxonomie je naše syntéza toho, co každý režim hlásí, ne publikovaný standard.

Kvadrant „pouze offline" je místo, kde si CI brány vydělávají na svůj provoz: přepsaný prompt, který tiše sníží shodu formátu z 99 % na 91 %, je v code review neviditelný a v 47případové sadě zřejmý. Kvadrant „pouze online" je zákeřnější. Reální uživatelé formulují věci, které vaše zlatá sada nikdy neobsahovala, API třetích stran timeoutují v časech, které staging nikdy netrefí, a někdo vašemu chatbotovi nakrmí prompt o 40 000 znacích, jen aby viděl, co se stane. Pro tuto stranu náš průvodce evaluací agentů v produkci pokrývá hodnocení vícekrokových trajektorií, ne jen jednotlivých výstupů.

Spodní řádek je ten, který týmy přeskakují, a ten, který je pálí. Selhání, která vás stojí uživatele, jsou ta, která žádný režim sám nezachytí. Potřebují člověka ve smyčce.

Jak zapojit offline evaluace do CI brány? (Konfigurace, kterou nikdo neukazuje)

Přidejte eval runner jako povinnou status check na každém pull requestu, který se dotýká promptu, modelu nebo konfigurace retrievalu. Assertněte práh. Pod ním zablokujte merge. promptfoo dokumentuje přesně tento CI vzor a je to ten, který provozujeme.

Krok GitHub Actions

Zjednodušená verze brány, kterou dnes provozujeme:

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 konfigurace deklaruje testovací případy a asserty; eval skončí nenulovým kódem, když sada klesne pod práh, GitHub označí povinnou check za selhanou a tlačítko merge zešedne. Filtr paths je důležitý: oprava README by neměla pálit judge tokeny.

Co brána skutečně zachytí

Živá verze hodnotí náš RAG řetězec support-agenta proti 47 zlatým případům na každém PR ovlivňujícím prompt. Plný běh trvá asi 90 sekund CI času a merge se automaticky zablokuje, pokud věrnost klesne pod 0,82. Za tři měsíce zachytila dvě regrese, které by se jinak dostaly do produkce: přepis systémového promptu, který stlačil věrnost z 0,91 na 0,74, a změna retrieveru, která zdvojnásobila délku kontextu a stáhla relevantnost odpovědi pod práh. Ani jedna nevypadala v review nebezpečně.

Brána věrnosti v CI stojí 90 sekund na PR. Regrese věrnosti v produkci vás stojí ticket v podpoře a rollback.

Porovnali jsme runnery, které můžete do tohoto vzoru zapojit, promptfoo, DeepEval a další, v našem žebříčku nástrojů pro evaluaci LLM.

Které nástroje běží který režim? (Matice nástrojů a režimů)

Žádný jediný nástroj neovládá oba pruhy čistě. promptfoo a DeepEval jsou offline-first runnery, které umí hodnotit exportovaná produkční data na plán; Langfuse a LangSmith jsou online-first úložiště trace, která přišroubují LLM-as-judge scorery na ingescované trace. Matice je náš výklad dokumentace každého vendoru: interpretace, ne evangelium.

Vyberte promptfoo nebo DeepEval, pokud vaše první potřeba je merge gate, která blokuje špatné prompty v CI. Vyberte Langfuse nebo LangSmith, pokud vaše první potřeba je hodnocení živého provozu, a naše srovnání Langfuse vs. LangSmith jde do hloubky tohoto výběru. OpenAI Evals zůstává outsiderem: offline runner ve stylu registru bez produkční strany.

promptfoo hlídá vaše PR. Langfuse hodnotí vaše produkční trace. Žádný nenahrazuje ten druhý.

Jak zpětná smyčka mění online selhání v offline testy?

Vzorkujte nízko hodnocené produkční trace, olabelujte je a commitněte do offline eval sady. Regresní sada pak roste s každým překvapením, které vám produkce přinese, a další deploy je hlídán rozšířenou sadou. Rámec setrvačníku je náš; je to ta část, kterou většina týmů nikdy nepostaví.

Cyklus, jak ho provozujeme:

1. Online scorery označí trace pod judge skóre 0,7.
2. Týdně vzorkujeme 20 až 30 označených trace.
3. Člověk každý olabeluje: očekávaný výstup plus třída selhání.
4. Olabelované případy vstoupí do offline eval sady jako nové zlaté příklady.
5. Další PR běží proti rozšířené sadě a smyčka se restartuje.

Vzorkování začíná na vaší vrstvě LLM observability, protože trace jsou surovina. Co se kadence týče: týdenní poráží měsíční, protože drift se kumuluje. Labelujeme 10 až 15 případů týdně a sada je „dost velká", když nové labely přestanou hýbat mírou úspěšnosti, kolem 150 až 250 případů pro úzce zaměřeného support agenta. Hranice mezi režimy se stále rozmazává: Deepchecks uvádí, že inženýři Union.ai plánují své „offline" evaluace každých pár minut, čímž je efektivně mění v téměř real-time kontroly.

Vaše eval sada není pevný artefakt. Roste každý týden, kdy vás produkce překvapí.

Kdy potřebujete obojí? (Online vs. offline evaluace LLM podle fáze)

Obojí potřebujete od týdne spuštění dál, ale rovnováha se po fázích posouvá: offline nese před-deploy práci sama, týden spuštění přidává shadow nebo canary hodnocení, ustálený stav se opírá o online monitoring s periodickými offline přehodnoceními a drift alert by měl skončit reprodukovaným offline testem plus větší eval sadou.

Fáze před deploy je nejlevnější místo pro přísnost: zablokovaný merge stojí minuty; špatný release stojí důvěru. Týden spuštění je místo, kde týmy investují málo, přitom shadow hodnocení na malém řezu provozu stojí málo a odhalí, zda zlatá sada lhala. Ustálený stav je místo, kde nastupuje sebeuspokojení, takže re-evaluaci dejte do kalendáře.

Co EU AI Act?

Povinnosti EU AI Act pro vysoce rizikové systémy se zavádějí postupně do srpna 2026, s úplným časovým harmonogramem zveřejněným na EUR-Lex, a vzor shody se čistě mapuje na oba režimy. Dokumentované offline důkazy ukazují, že systém splnil cíle kvality před vydáním; průběžný online monitoring ukazuje, že je plní i poté. Náš výklad je, že auditní stopa potřebuje oba artefakty, protože samotné offline logy nedokazují, že systém zůstal v souladu, a samotné dashboardy nedokazují, že byl v souladu při spuštění. To je interpretace, ne právní poradenství; náš pilíř pipeline evaluace LLM mapuje celou sadu požadavků.

Offline evaluace je váš důkaz. Online evaluace je váš systém včasného varování. Regulátoři chtějí obojí.

O autorovi: Mert Batur je spoluzakladatel Techsy.io, kde tým dodává AI agenty, automatizační systémy a hlasové/SDR pipeline pro B2B klienty. Píše o stacku nástrojů pro LLM, který tým Techsy skutečně používá v produkci. Spojte se na LinkedIn.

Často kladené otázky

Co je offline evaluace LLM?

Offline evaluace LLM spouští model nebo prompt proti pevné, verzované datové sadě před nasazením. Typické kontroly zahrnují věrnost k retrieval kontextu, relevantnost odpovědi, shodu formátu a benchmark skóre. Protože se datová sada během běhu nemění, výsledky jsou reprodukovatelné a porovnatelné diffem, což je přesně důvod, proč offline sady fungují jako CI merge gate.

Co je online evaluace LLM?

Online evaluace LLM hodnotí živý produkční provoz po spuštění. LLM-as-judge scorer hodnotí vzorkované trace na halucinace, tón nebo správnost volání nástrojů a skóre streamuje na dashboard. Absorbuje také signály, které offline testy nevidí: latenci pod zátěží, zpětnou vazbu uživatelů a jak se reálné dotazy liší od vaší zlaté sady.

Kdy použít offline vs. online evaluaci LLM?

Použijte offline evaluaci k hlídání deploy: každá změna promptu, modelu nebo retrievalu by měla projít sadou před merge. Použijte online evaluaci k monitorování toho, co se nasadí. Většina týmů řadí obě za sebe, místo aby vybírala jednu: nejprve offline, online od týdne spuštění dál, s produkčními selháními tekoucími zpět do offline sady.

Jaký je příklad online vs. offline evaluace LLM?

Offline příklad: sada promptfoo spouští 200 zlatých otázek podpory na každém pull requestu a blokuje merge, pokud věrnost klesne pod 0,82. Online příklad: Langfuse hodnotí 10 % živých trace LLM-as-judge kontrolou halucinací a spustí alert, když týdenní průměr poklesne. Stejný rubrik, jiný zdroj dat.

Jak zapadá human-in-the-loop do evaluace LLM?

Lidé uzavírají mezeru, kterou žádný režim nepokrývá: nové okrajové případy, subjektivní hodnocení kvality a drift tónu značky. Praktická kadence je labelování 10 až 20 vzorkovaných nízko hodnocených trace týdně a commitování olabelovaných případů do offline eval sady. Fronta review je vstup pipeline, ne vedlejší projekt.

Jak fungují evaluace Langfuse pro online hodnocení?

Langfuse ingestuje trace z vaší aplikace a poté připojí LLM-as-judge evaluátory, které hodnotí každý trace podle rubriku: halucinace, relevantnost, toxicita nebo vlastní prompt. Skóre dopadají na dashboard klíčovaný podle relací a uživatelů. Týmy exportují trvale nízko hodnocené trace do offline datové sady pro regresní testování. Náš žebříček observability platforem porovnává úložiště trace, která tento vzor zásobují.

Jak přidat offline evaluace do CI/CD pipeline?

Přidejte eval runner jako povinnou status check na pull requestech, které se dotýkají promptů, modelů nebo konfigurace retrievalu. promptfoo i DeepEval běží headless a při selhání assertu skončí nenulovým kódem, což automaticky zablokuje merge. YAML brána zmíněná dříve v tomto článku je funkční šablona; začněte s 30 až 50 případy.

Vyžaduje EU AI Act offline nebo online evaluaci?

Efektivně obojí. Pro vysoce rizikové systémy zákon očekává dokumentované důkazy, že cíle kvality byly splněny před vydáním, což znamená offline artefakty, plus průběžný monitoring po nasazení, což znamená online telemetrii. Jeho fázované termíny běží do srpna 2026 dle EUR-Lex. To je náš výklad vzoru shody, ne právní poradenství.

Může LLM-as-a-judge běžet v offline i online režimu?

Ano, a měl by, protože rubrik se přenáší. V offline režimu judge hodnotí každý výstup eval sady v batchi během CI. V online režimu stejný judge prompt hodnotí vzorkované produkční trace téměř v reálném čase. Udržení jednoho rubriku napříč oběma režimy je to, co dělá vaši offline baseline porovnatelnou s vaším online signálem driftu.

Jaké metriky se liší mezi offline a online evaluací?

Offline metriky měří kvalitu výstupu proti ground truth: věrnost, relevantnost odpovědi, shoda formátu, benchmark skóre. Online metriky přidávají provozní a behaviorální signály: p95 latenci, chybovost, míru halucinací na živém provozu, skóre driftu a spokojenost uživatelů. Offline seznam se ptá „je to dobré?" a online seznam se ptá „je to stále dobré?"

Krátká verze

• Offline a online evaluace jsou komplementární pruhy, ne buď/a: jeden hlídá, co nasadíte, druhý sleduje, co jste nasadili.
• Začněte s CI bránou tento týden, přidejte online hodnocení trace při spuštění a zapojte zpětnou smyčku, než vaše eval sada zestárne.
• Smyčka je ten systém. Statická zlatá datová sada hnije; rostoucí se kumuluje.

Pokud chcete druhý pár očí na vaši eval pipeline, získejte bezplatnou konzultaci.