Online vs offline LLM-arviointi: kumman tarvitset (ja milloin)

Online vs offline LLM-arviointi: kumman tarvitset (ja milloin)

Online- ja offline-LLM-arviointi on yksi päätös, ei kaksi, ja promptfoo-sarjamme todisti sen viime tiistaina: yksi uudelleenkirjoitettu järjestelmäprompti, 47 testitapausta, uskollisuus (faithfulness) laski 0,91:stä 0,74:ään noin 90 sekunnin CI-ajossa. Offline-tarkistus nappasi tuon regression ennen mergeä; tuotannon seuranta olisi kohdannut sen myöhemmin, tukipyynnöksi naamioituneena. Offline vai online, sama tuomio: kaksi kaistaa, eri tehtävät.

Offline-LLM-arviointi ajaa mallisi kiinteää data-aineistoa vastaan ennen julkaisua ja todistaa, ettei muutos rikkonut mitattua laatua. Online-arviointi pisteyttää live-tuotantoliikennettä julkaisun jälkeen ja paljastaa, mitä aineisto ei koskaan sisältänyt. Useimmat tiimit tarvitsevat molemmat, oikeassa järjestyksessä: offline toimii julkaisun porttina, online nappaa ajautumisen.

Keskeiset opit

• Offline-arviointi ajetaan kiinteää aineistoa vastaan ennen julkaisua; online-arviointi pisteyttää live-liikennettä julkaisun jälkeen.
• Useimmat tiimit tarvitsevat molemmat: offline on julkaisujen portti, online nappaa sen, mitä aineisto ei nähnyt.
• Offline nappaa promptiregressiot ja muotovirheet; online nappaa ajautumisen, viiveen kuormassa ja integraatioiden erikoisuudet.
• Kytke offline-evalit CI:n merge-portiksi; syötä online-pisteet tuotannon traceista eval-aineistoosi.

Miten online- ja offline-arviointi oikeastaan eroavat? (9 ulottuvuutta)

Kaksi moodia eroavat yhdeksällä akselilla, mutta ratkaiseva ero on datalähde: offline-arviointi pisteyttää kiinteän, versionoidun aineiston ennen julkaisua, kun taas online-arviointi pisteyttää live-liikennettä julkaisun jälkeen. Kaikki muut erot, kustannukset, viive, riski, hallinnointi, seuraavat tästä jakolinjasta.

Label Studion oppimiskeskus kuvaa paria toisiaan täydentävinä moodeina, ei kilpailijoina, ja olemme samaa mieltä. Taulukko laajentaa tätä kehystä LLM-kohtaisilla mittareilla, joita heidän yleinen ML-versionsa ei kata.

Tulkintamme: offline-sarake vastaa kysymykseen "rikkoiko tämä muutos jotain?", online-sarake kysymykseen "ajautuuko tuotanto pois siitä, mitä testasimme?". Mittarityyppien rivi on kohta, jossa kaksi eroavat eniten; LLM-arviointimittareiden oppaamme erittelee jokaisen.

Mitä kumpikin moodi nappaa, ja mikä livahtaa molempien ohi?

Kummallakin moodilla on oma virheluokkansa, jota toinen ei näe. Offline nappaa sinun tekemäsi muutokset; online nappaa maailman ympärilläsi tekemät muutokset. Kalliit virheet, ne jotka selviävät molemmista verkoista, tarvitsevat ihmistarkastajan. Tämä taksonomia on oma synteesimme siitä, mitä kumpikin moodi raportoi, ei julkaistu standardi.

Vain offline -neljännes on se, jossa CI-portit ansaitsevat hintansa: uudelleenkirjoitettu prompti, joka pudottaa muodonmukaisuuden hiljaa 99 %:sta 91 %:iin, on näkymätön koodikatselmuksessa ja ilmiselvä 47 tapauksen sarjassa. Vain online -neljännes on kavalampi. Oikeat käyttäjät muotoilevat asioita, joita kulta-aineistosi ei koskaan tehnyt, kolmannen osapuolen APIt aikakatkeavat aikatauluissa, joita staging ei koskaan kohtaa, ja joku syöttää chatbotillesi 40 000 merkin promptin ihan vain nähdäkseen mitä tapahtuu. Tuota puolta varten oppaamme agenttien arvioinnista tuotannossa kattaa monivaiheisten polkujen pisteytyksen, ei vain yksittäisiä vastauksia.

Alin rivi on se, jonka tiimit jättävät väliin, ja se joka polttaa heitä. Virheet, jotka maksavat sinulle käyttäjiä, ovat juuri niitä, joita kumpikaan moodi ei nappaa yksinään. Ne tarvitsevat ihmisen mukaan silmukkaan.

Miten offline-evalit kytketään CI-portiksi? (Konfiguraatio, jota kukaan ei näytä)

Lisää eval-ajo pakolliseksi status-tarkistukseksi jokaiselle pull requestille, joka koskee promptia, mallia tai retrieval-konfiguraatiota. Aseta kynnysarvo. Estä merge sen alle. promptfoon dokumentaatio kuvaa juuri tämän CI-kuvion, ja se on se, jota me ajamme.

GitHub Actions -vaihe

Karsittu versio portista, jota tällä hetkellä ajamme:

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-konfiguraatio määrittelee testitapaukset ja assertit; eval palauttaa nollasta poikkeavan paluukoodin, kun sarja jää alle kynnyksen, GitHub merkitsee pakollisen tarkistuksen epäonnistuneeksi ja merge-nappi harmaantuu. paths-suodattimella on väliä: README-korjauksen ei pidä polttaa tuomarin tokeneita.

Mitä portti oikeasti nappaa

Live-versio pisteyttää tukibottimme RAG-ketjun 47 kultatapausta vastaan jokaisella prompttiin vaikuttavalla PR:llä. Täysi ajo vie noin 90 sekuntia CI-aikaa, ja merge estyy automaattisesti, jos uskollisuus laskee alle 0,82:n. Kolmessa kuukaudessa se on napannut kaksi regressiota, jotka olisivat muuten päätyneet tuotantoon: järjestelmäpromptin uudelleenkirjoitus, joka pudotti uskollisuuden 0,91:stä 0,74:ään, ja retriever-muutos, joka kaksinkertaisti kontekstin pituuden ja veti vastauksen osuvuuden alle kynnyksen. Kumpikaan ei näyttänyt vaaralliselta katselmuksessa.

Uskollisuusportti CI:ssä maksaa 90 sekuntia per PR. Uskollisuusregressio tuotannossa maksaa tukipyynnön ja rollbackin.

Vertailimme tähän kuvioon sopivat ajurit, promptfoon, DeepEvalin ja muut, LLM-arviointityökalujen yhteenvedossamme.

Mitkä työkalut ajavat kumpaa moodia? (Työkalu-moodi-matriisi)

Mikään yksittäinen työkalu ei hallitse molempia kaistoja puhtaasti. promptfoo ja DeepEval ovat offline-painotteisia ajureita, jotka voivat pisteyttää vietyä tuotantodataa aikataulussa; Langfuse ja LangSmith ovat online-painotteisia trace-arkistoja, jotka liittävät LLM-tuomari-pisteyttimiä sisään luettuihin traceihin. Matriisi on oma lukumme kunkin toimittajan dokumentaatiosta: tulkintaa, ei totuutta.

Valitse promptfoo tai DeepEval, jos ensimmäinen tarpeesi on merge-portti, joka estää huonot promptit CI:ssä. Valitse Langfuse tai LangSmith, jos ensimmäinen tarpeesi on live-liikenteen pisteytys, ja Langfuse vs LangSmith -vertailumme menee tuohon valintaan syvälle. OpenAI Evals jää outolinnuksi: rekisterityylinen offline-ajo ilman tuotantopuolta.

promptfoo toimii PR:iesi porttina. Langfuse pisteyttää tuotannon tracet. Kumpikaan ei korvaa toista.

Miten palautesilmukka muuttaa online-virheet offline-testeiksi?

Otosta matalia pisteitä saaneet tuotannon tracet, labeloi ne ja committoi ne offline-eval-aineistoon. Regressiosarja kasvaa jokaisen yllätyksen myötä, jonka tuotanto heittää eteesi, ja seuraava julkaisu portitetaan laajennettua sarjaa vastaan. Vauhtipyöräkehys on meidän; se on osa, jota useimmat tiimit eivät koskaan rakenna.

Silmukka sellaisena kuin me sen ajamme:

1. Online-pisteyttimet liputtavat tracet, joiden tuomaripiste jää alle 0,7:n.
2. Otostamme 20–30 liputettua tracea viikossa.
3. Ihminen labeloi jokaisen: odotettu vastaus ja virheluokka.
4. Labeloidut tapaukset liittyvät offline-eval-aineistoon uusina kultaesimerkkeinä.
5. Seuraava PR ajetaan laajennettua sarjaa vastaan, ja silmukka alkaa alusta.

Otostus alkaa LLM-havainnointikerroksestasi, koska tracet ovat raaka-ainetta. Rytmistä: viikoittainen voittaa kuukausittaisen, koska ajautuminen kasautuu. Labeloimme 10–15 tapausta viikossa, ja aineisto on "riittävän iso", kun uudet labelit eivät enää liikuta läpimenoastetta, kapealle tukibotille noin 150–250 tapausta. Raja moodien välillä hämärtyy koko ajan: Deepchecks raportoi, että Union.ain insinöörit ajavat "offline"-evalinsa muutaman minuutin välein, mikä tekee niistä käytännössä lähes reaaliaikaisia tarkistuksia.

Eval-aineistosi ei ole kiinteä artefakti. Se kasvaa joka viikko, kun tuotanto yllättää sinut.

Milloin tarvitset molemmat? (Online vs offline LLM-arviointi vaiheittain)

Tarvitset molemmat julkaisuviikosta eteenpäin, mutta painotus muuttuu vaiheittain: offline kantaa julkaisua edeltävän työn yksin, julkaisuviikko lisää varjo- tai canary-pisteytyksen, vakiintunut tila nojaa online-seurantaan ja säännöllisiin offline-uusinta-ajoihin, ja ajautumishälytyksen pitäisi päätyä toistettuun offline-testiin ja isompaan eval-aineistoon.

Julkaisua edeltävä vaihe on halvin paikka olla tiukka: estetty merge maksaa minuutteja; huono julkaisu maksaa luottamusta. Julkaisuviikko on kohta, jossa tiimit sijoittavat liian vähän, vaikka varjopisteytys pienellä liikenneviipaleella maksaa vähän ja paljastaa, valehteliko kulta-aineisto. Vakiintuneessa tilassa välinpitämättömyys iskee, joten laita uudelleenarviointi kalenteriin.

Entä EU:n AI-asetus?

EU:n AI-asetuksen korkean riskin velvoitteet tulevat voimaan vaiheittain elokuuhun 2026 mennessä, ja täysi määräaikataulu on julkaistu EUR-Lexissä; vaatimustenmukaisuuskuvio sopii puhtaasti molempiin moodeihin. Dokumentoitu offline-näyttö osoittaa, että järjestelmä täytti laatutavoitteet ennen julkaisua; jatkuva online-seuranta osoittaa, että se täyttää ne edelleen. Tulkintamme on, että auditointiketju tarvitsee molemmat artefaktit, koska pelkät offline-lokit eivät todista järjestelmän pysyneen vaatimusten mukaisena, eivätkä pelkät kojelaudat todista sen lähteneen liikkeelle vaatimusten mukaisesti. Se on tulkintaa, ei juridiikkaa; LLM-arviointiputken pilarimme kartoittaa koko vaatimusjoukon.

Offline-arviointi on näyttösi. Online-arviointi on varhaisvaroitusjärjestelmäsi. Sääntelijät haluavat molemmat.

Kirjoittajasta: Mert Batur on Techsy.io:n perustajaosakas, jonka tiimi toimittaa tekoälyagentteja, automaatiojärjestelmiä ja ääni-/SDR-putkia B2B-asiakkaille. Hän kirjoittaa LLM-työkalupinosta, jota Techsyn tiimi käyttää oikeasti tuotannossa. Yhdistä LinkedInissä.

Usein kysytyt kysymykset

Mitä on offline-LLM-arviointi?

Offline-LLM-arviointi ajaa mallin tai promptin kiinteää, versioitua data-aineistoa vastaan ennen julkaisua. Tyypillisiä tarkistuksia ovat uskollisuus haettuun kontekstiin, vastauksen osuvuus, muodonmukaisuus ja benchmark-pisteet. Koska aineisto ei koskaan muutu kesken ajon, tulokset ovat toistettavia ja diffattavia, ja juuri siksi offline-sarjat toimivat CI-merge-portteina.

Mitä on online-LLM-arviointi?

Online-LLM-arviointi pisteyttää live-tuotantoliikennettä julkaisun jälkeen. LLM-tuomari-pisteytin arvioi otostettuja traceja hallusinaation, sävyn tai työkalukutsujen oikeellisuuden osalta, ja pisteet virtaavat kojelaudalle. Se imee myös signaaleja, joita offline-testit eivät näe: viive kuormassa, käyttäjäpalaute ja se, miten todelliset kyselyt eroavat kulta-aineistostasi.

Milloin käytän offline- ja milloin online-LLM-arviointia?

Käytä offline-arviointia julkaisujen porttina: jokaisen prompti-, malli- tai retrieval-muutoksen pitäisi läpäistä sarja ennen mergeä. Käytä online-arviointia sen seurantaan, mitä julkaistaan. Useimmat tiimit ajoittavat molemmat sen sijaan, että valitsisivat toisen: ensin offline, julkaisuviikosta eteenpäin online, ja tuotantovirrat virtaavat takaisin offline-aineistoon.

Mikä on esimerkki online- ja offline-LLM-arvioinnista?

Offline-esimerkki: promptfoo-sarja ajaa 200 kultaista tukikysymystä jokaisella pull requestilla ja estää mergen, jos uskollisuus laskee alle 0,82:n. Online-esimerkki: Langfuse pisteyttää 10 % live-traceista LLM-tuomarin hallusinaatiotarkistuksella ja hälyttää, kun viikkokeskiarvo lipsuu. Sama arviointiperuste, eri datalähde.

Miten human-in-the-loop sopii LLM-arviointiin?

Ihmiset kurovat umpeen aukon, jota kumpikaan moodi ei kata: uudet reunatapaukset, subjektiiviset laatuarviot ja brändiäänen ajautuminen. Käytännöllinen rytmi on labeloida 10–20 otostettua matalan pisteen tracea viikossa ja committtaa labeloidut tapaukset offline-eval-aineistoon. Tarkastusjono on putken syöte, ei sivuprojekti.

Miten Langfuse-evaluaatiot toimivat online-pisteytyksessä?

Langfuse lukee tracet sovelluksestasi ja liittaa niihin LLM-tuomari-evaluaattorit, jotka pisteyttävät jokaisen tracen arviointiperustetta vastaan: hallusinaatio, osuvuus, toksisuus tai räätälöity prompti. Pisteet päätyvät kojelaudalle, joka on avaimoitu sessioiden ja käyttäjien mukaan. Tiimit vievät pysyvästi matalia pisteitä saavat tracet offline-aineistoon regressiotestausta varten. Havainnointialustojen yhteenvetomme vertailee trace-arkistoja, jotka syöttävät tätä kuviota.

Miten lisään offline-evalit CI/CD-putkeen?

Lisää eval-ajo pakolliseksi status-tarkistukseksi pull requesteille, jotka koskevat prompteja, malleja tai retrieval-konfiguraatiota. Sekä promptfoo että DeepEval ajavat headless-tilassa ja palauttavat nollasta poikkeavan paluukoodin assertin epäonnistuessa, mikä estää mergen automaattisesti. Tämän artikkelin aiempi YAML-portti on toimiva mallipohja; aloita 30–50 tapauksella.

Vaatiiko EU:n AI-asetus offline- vai online-arviointia?

Käytännössä molempia. Korkean riskin järjestelmiltä asetus odottaa dokumentoitua näyttöä siitä, että laatutavoitteet täytettiin ennen julkaisua, mikä tarkoittaa offline-artefakteja, sekä jatkuvaa seurantaa julkaisun jälkeen, mikä tarkoittaa online-telemetriaa. Sen vaiheittaiset määräajat ulottuvat elokuuhun 2026 EUR-Lexin mukaan. Se on tulkintamme vaatimustenmukaisuuskuviosta, ei juridiikkaa.

Voiko LLM-as-a-judge toimia sekä offline- että online-moodissa?

Kyllä, ja sen kuuluukin, koska arviointiperuste siirtyy. Offlinessa tuomari pisteyttää jokaisen eval-aineiston vastauksen eräajossa CI:n aikana. Onlinessa sama tuomariprompti pisteyttää otostettuja tuotannon traceja lähes reaaliajassa. Yhden arviointiperusteen pitäminen molemmissa moodeissa on se, mikä tekee offline-baselinestasi vertailukelpoisen online-ajautumissignaalin kanssa.

Mitkä mittarit eroavat offline- ja online-arvioinnin välillä?

Offline-mittarit mittaavat vastauksen laatua totuutta vastaan: uskollisuus, vastauksen osuvuus, muodonmukaisuus, benchmark-pisteet. Online-mittarit lisäävät operatiivisia ja käyttäytymissignaaleja: p95-viive, virheaste, hallusinaatioaste live-liikenteessä, ajautumispiste ja käyttäjätyytyväisyys. Offline-lista kysyy "onko se hyvä?" ja online-lista "onko se yhä hyvä?".

Lyhyt versio

• Offline- ja online-arviointi ovat toisiaan täydentäviä kaistoja, eivät joko/tai-valinta: toinen toimii porttina sille, mitä julkaiset, toinen vahtii sitä, mitä julkaisit.
• Aloita CI-portti tällä viikolla, lisää online-tracejen pisteytys julkaisun yhteyteen ja kytke palautesilmukka ennen kuin eval-aineistosi vanhenee.
• Silmukka on järjestelmä. Staattinen kulta-aineisto mätänee; kasvava kasautuu.

Jos haluat toisen parin silmiä eval-putkellesi, pyydä ilmainen konsultaatio.