Evaluare LLM online vs offline: ce îți trebuie (și când)

Evaluare LLM online vs offline: ce îți trebuie (și când)

Evaluarea LLM online vs offline este o singură decizie, nu două, iar suita noastră promptfoo a demonstrat-o marțea trecută: un system prompt rescris, 47 de cazuri de test, faithfulness-ul a scăzut de la 0,91 la 0,74 în aproximativ 90 de secunde de timp CI. Verificarea offline a prins acea regresie înainte de merge; monitorizarea din producție ar fi întâlnit-o mai târziu, deghizată într-un tichet de suport. Offline vs online, același verdict: două benzi, sarcini diferite.

Evaluarea LLM offline rulează modelul pe un set de date fix înainte de deploy, dovedind că o modificare nu a stricat calitatea măsurată. Evaluarea online scorizează traficul real din producție după lansare, expunând ce setul de date nu a conținut niciodată. Majoritatea echipelor au nevoie de ambele, secvențiate: offline blochează deploy-ul, online prinde deriva.

Concluzii cheie

• Evaluarea offline rulează pe un set de date fix înainte de deploy; evaluarea online scorizează traficul real după lansare.
• Majoritatea echipelor au nevoie de ambele: offline blochează deploy-urile, online prinde ce setul de date a ratat.
• Offline detectează regresiile de prompt și erorile de format; online detectează deriva, latența sub sarcină și ciudățeniile de integrare.
• Conectează evalurile offline ca poartă de merge în CI; transmite scorurile online din trace-urile de producție în setul de eval.

Cum diferă de fapt evaluarea online de cea offline? (9 dimensiuni)

Cele două moduri diferă pe nouă axe, dar cea decisivă este sursa de date: evaluarea offline scorizează un set de date fix, versionat, înainte de deploy, în timp ce evaluarea online scorizează traficul real după lansare. Fiecare altă diferență — cost, latență, risc, guvernanță — decurge din această separare.

Centrul de învățare Label Studio prezintă perechea ca moduri complementare, nu ca rivale, și suntem de acord. Tabelul extinde acea încadrare cu metrici specifice LLM pe care versiunea lor generică de ML nu le acoperă.

Interpretarea noastră: coloana offline răspunde la „această modificare a stricat ceva?", iar coloana online răspunde la „producția se îndepărtează de ce am testat?". Rândul cu tipuri de metrici este locul unde cele două diverg cel mai mult; ghidul nostru de metrici de evaluare LLM le detaliază pe fiecare.

Ce detectează fiecare mod și ce scapă prin ambele?

Fiecare mod deține o clasă privată de eșecuri pe care celălalt nu o poate vedea. Offline detectează modificările pe care le-ai făcut tu; online detectează modificările pe care lumea le-a făcut în jurul tău. Eșecurile costisitoare, cele care supraviețuiesc ambelor plase, au nevoie de un recenzor uman. Această taxonomie este sinteza noastră a ceea ce raportează fiecare mod, nu un standard publicat.

Cadrantul „doar offline" este locul unde porțile CI își câștigă existența: un prompt rescris care scade silențios conformitatea de format de la 99% la 91% este invizibil în code review și evident într-o suită de 47 de cazuri. Cadrantul „doar online" este mai viclean. Utilizatorii reali formulează lucruri pe care setul tău golden nu le-a făcut niciodată, API-urile terțe expiră pe programe pe care staging nu le atinge niciodată, și cineva va trimite chatbotului tău un prompt de 40.000 de caractere doar ca să vadă ce se întâmplă. Pentru acea parte, ghidul nostru despre evaluarea agenților în producție acoperă scorizarea traiectoriilor multi-pas, nu doar a ieșirilor individuale.

Rândul de jos este cel pe care echipele îl sar și cel care le arde. Eșecurile care te costă utilizatori sunt cele pe care niciun mod nu le detectează singur. Ele au nevoie de un om în buclă.

Cum conectezi evalurile offline într-o poartă CI? (Configurația pe care nimeni nu o arată)

Adaugă un runner de eval ca status check obligatoriu pe fiecare pull request care atinge un prompt, un model sau o configurație de retrieval. Aserțiunează un prag. Blochează merge-ul sub el. promptfoo documentează exact acest tipar CI, și este cel pe care îl rulăm noi.

Pasul GitHub Actions

O versiune simplificată a porții pe care o rulăm azi:

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

Configurația YAML declară cazurile de test și aserțiunile; eval iese cu cod diferit de zero când suita cade sub prag, GitHub marchează check-ul obligatoriu ca eșuat, iar butonul de merge devine gri. Filtrul paths contează: o corecție de README nu ar trebui să consume tokeni de judge.

Ce detectează de fapt poarta

Versiunea live scorizează lanțul nostru RAG de agent de suport pe 47 de cazuri golden la fiecare PR care afectează promptul. O rulare completă durează aproximativ 90 de secunde de timp CI, iar merge-ul se blochează automat dacă faithfulness-ul scade sub 0,82. În trei luni, a prins două regresii care altfel ar fi fost livrate: o rescriere de system prompt care a împins faithfulness-ul de la 0,91 la 0,74 și o modificare de retriever care a dublat lungimea contextului și a tras answer relevancy sub prag. Niciuna nu părea periculoasă în review.

O poartă de faithfulness în CI costă 90 de secunde per PR. O regresie de faithfulness în producție te costă un tichet de suport și un rollback.

Am comparat runner-ele pe care le poți conecta la acest tipar — promptfoo, DeepEval și restul — în recenzia noastră de instrumente de evaluare LLM.

Ce instrumente rulează ce mod? (Matrice instrument-mod)

Niciun instrument nu deține ambele benzi în mod curat. promptfoo și DeepEval sunt runner-e offline-first care pot scoriza date de producție exportate pe un program; Langfuse și LangSmith sunt depozite de trace online-first care atașează scorizori LLM-as-judge pe trace-urile ingerate. Matricea este lectura noastră a documentației fiecărui vendor: interpretare, nu evanghelie.

Alege promptfoo sau DeepEval dacă prima ta nevoie este o poartă de merge care blochează prompturile proaste în CI. Alege Langfuse sau LangSmith dacă prima ta nevoie este scorizarea traficului live, iar comparația noastră Langfuse vs LangSmith intră în detaliu pe acea alegere. OpenAI Evals rămâne excepția: un runner offline stil registru, fără latură de producție.

promptfoo blochează PR-urile tale. Langfuse scorizează trace-urile tale de producție. Niciunul nu-l înlocuiește pe celălalt.

Cum transformă bucla de feedback eșecurile online în teste offline?

Eșantionează trace-urile de producție cu scor scăzut, etichetează-le și comite-le în setul de eval offline. Suita de regresie crește apoi cu fiecare surpriză pe care producția ți-o aruncă, iar următorul deploy este blocat pe setul extins. Încadrarea de flywheel este a noastră; este partea pe care majoritatea echipelor nu o construiesc niciodată.

Ciclul, așa cum îl rulăm noi:

1. Scorizorii online marchează trace-urile sub 0,7 scor de judge.
2. Eșantionăm 20 până la 30 de trace-uri marcate pe săptămână.
3. Un om etichetează fiecare: ieșire așteptată plus clasa de eșec.
4. Cazurile etichetate intră în setul de eval offline ca noi exemple golden.
5. Următorul PR rulează pe suita extinsă, iar bucla se reia.

Eșantionarea începe de la stratul tău de observabilitate LLM, pentru că trace-urile sunt materia primă. Ca ritm: săptămânal bate lunar, pentru că deriva se compune. Etichetăm 10 până la 15 cazuri pe săptămână, iar setul este „suficient de mare" când etichetele noi nu mai mișcă rata de trecere — în jur de 150 până la 250 de cazuri pentru un agent de suport îngust. Linia dintre moduri se estompează continuu: Deepchecks raportează că inginerii de la Union.ai își programează evalurile „offline" la fiecare câteva minute, transformându-le efectiv în verificări aproape în timp real.

Setul tău de eval nu este un artefact fix. Crește în fiecare săptămână în care producția te surprinde.

Când ai nevoie de ambele? (Evaluare LLM online vs offline pe etape)

Ai nevoie de ambele din săptămâna de lansare, dar echilibrul se schimbă pe etape: offline poartă singur munca de pre-deploy, săptămâna de lansare adaugă scorizare shadow sau canary, starea stabilă se bazează pe monitorizare online cu re-rulări offline periodice, iar o alertă de derivă ar trebui să se termine cu un test offline reprodus plus un set de eval mai mare.

Pre-deploy este cel mai ieftin loc pentru a fi strict: un merge blocat costă minute; un release prost costă încredere. Săptămâna de lansare este locul unde echipele sub-investesc, deși scorizarea shadow pe o felie mică de trafic costă puțin și dezvăluie dacă setul golden a mințit. Starea stabilă este locul unde se instalează complacența, deci pune re-evaluarea în calendar.

Dar EU AI Act?

Obligațiile pentru sisteme de risc ridicat din EU AI Act se implementează progresiv până în august 2026, cu calendarul complet al termenelor publicat pe EUR-Lex, iar tiparul de conformitate se mapează curat pe cele două moduri. Dovezile offline documentate arată că sistemul a atins obiectivele de calitate înainte de lansare; monitorizarea online continuă arată că le menține și după. Lectura noastră este că un traseu de audit are nevoie de ambele artefacte, pentru că logurile offline singure nu dovedesc că sistemul a rămas conform, iar dashboard-urile singure nu dovedesc că a fost lansat conform. Aceasta este interpretare, nu consultanță juridică; ghidul nostru de pipeline de evaluare LLM mapează setul complet de cerințe.

Evaluarea offline este dovada ta. Evaluarea online este sistemul tău de avertizare timpurie. Reglementatorii vor ambele.

Despre autor: Mert Batur este Co-Fondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri voice/SDR pentru clienți B2B. Scrie despre stack-ul de instrumente LLM pe care echipa Techsy îl folosește efectiv în producție. Conectează-te pe LinkedIn.

Întrebări frecvente

Ce este evaluarea LLM offline?

Evaluarea LLM offline rulează un model sau un prompt pe un set de date fix, versionat, înainte de deploy. Verificările tipice includ faithfulness față de contextul recuperat, answer relevancy, conformitate de format și scoruri de benchmark. Pentru că setul de date nu se schimbă niciodată în timpul rulării, rezultatele sunt repetabile și comparabile — exact motivul pentru care suitele offline funcționează ca porți de merge în CI.

Ce este evaluarea LLM online?

Evaluarea LLM online scorizează traficul real din producție după lansare. Un scorizor LLM-as-judge evaluează trace-urile eșantionate pentru halucinație, ton sau corectitudinea apelurilor de instrumente, iar scorurile ajung pe un dashboard. Absoarbe și semnale pe care testele offline nu le pot vedea: latența sub sarcină, feedback-ul utilizatorilor și cum diferă interogările reale de setul tău golden.

Când ar trebui să folosesc evaluare LLM offline vs online?

Folosește evaluarea offline pentru a bloca deploy-urile: fiecare modificare de prompt, model sau retrieval ar trebui să treacă suita înainte de merge. Folosește evaluarea online pentru a monitoriza ce ajunge în producție. Majoritatea echipelor le secvențiază pe ambele în loc să aleagă una: offline mai întâi, online din săptămâna de lansare, cu eșecurile din producție curgând înapoi în setul offline.

Care este un exemplu de evaluare LLM online vs offline?

Exemplu offline: o suită promptfoo rulează 200 de întrebări golden de suport la fiecare pull request și blochează merge-ul dacă faithfulness-ul scade sub 0,82. Exemplu online: Langfuse scorizează 10% din trace-urile live cu o verificare de halucinație LLM-as-judge și alertează când media săptămânală scade. Același rubric, sursă de date diferită.

Cum se integrează human-in-the-loop în evaluarea LLM?

Oamenii închid golul pe care niciun mod nu-l acoperă: cazuri limită noi, evaluări subiective de calitate și derivă de ton de brand. Un ritm practic este etichetarea a 10 până la 20 de trace-uri eșantionate cu scor scăzut pe săptămână și comiterea cazurilor etichetate în setul de eval offline. Coada de revizuire este un input de pipeline, nu un proiect secundar.

Cum funcționează evalurile Langfuse pentru scorizare online?

Langfuse ingerează trace-uri din aplicația ta, apoi atașează evaluatori LLM-as-judge care scorizează fiecare trace pe un rubric: halucinație, relevancy, toxicitate sau un prompt personalizat. Scorurile ajung pe un dashboard indexat pe sesiuni și utilizatori. Echipele exportă trace-urile cu scor persistent scăzut într-un dataset offline pentru testare de regresie. Recenzia noastră de platforme de observabilitate compară depozitele de trace-uri care alimentează acest tipar.

Cum adaug evaluri offline într-un pipeline CI/CD?

Adaugă un runner de eval ca status check obligatoriu pe pull request-urile care ating prompturi, modele sau configurații de retrieval. promptfoo și DeepEval rulează ambele headless și ies cu cod diferit de zero la eșecul aserțiunii, ceea ce blochează merge-ul automat. Poarta YAML de mai devreme din acest articol este un șablon funcțional; începe cu 30 până la 50 de cazuri.

EU AI Act cere evaluare offline sau online?

Efectiv, ambele. Pentru sistemele de risc ridicat, Actul așteaptă dovezi documentate că obiectivele de calitate au fost atinse înainte de lansare — ceea ce înseamnă artefacte offline — plus monitorizare continuă după deploy — ceea ce înseamnă telemetrie online. Termenele sale progresive se întind până în august 2026 conform EUR-Lex. Aceasta este lectura noastră a tiparului de conformitate, nu consultanță juridică.

Poate LLM-as-a-judge rula în ambele moduri, offline și online?

Da, și ar trebui, pentru că rubricul se transferă. Offline, judge-ul scorizează fiecare ieșire din setul de eval în batch în timpul CI. Online, același prompt de judge scorizează trace-urile de producție eșantionate aproape în timp real. Păstrarea unui singur rubric pe ambele moduri este ceea ce face baseline-ul tău offline comparabil cu semnalul tău de derivă online.

Ce metrici diferă între evaluarea offline și cea online?

Metricile offline măsoară calitatea ieșirii față de ground truth: faithfulness, answer relevancy, conformitate de format, scoruri de benchmark. Metricile online adaugă semnale operaționale și comportamentale: latență p95, rată de eroare, rată de halucinație pe trafic live, scor de derivă și satisfacția utilizatorilor. Lista offline întreabă „este bun?" și lista online întreabă „este încă bun?"

Versiunea scurtă

• Evaluarea offline și cea online sunt benzi complementare, nu o alegere de tipul „ori/or": una blochează ce livrezi, cealaltă monitorizează ce ai livrat.
• Începe cu poarta CI săptămâna aceasta, adaugă scorizare de trace-uri online la lansare și conectează bucla de feedback înainte ca setul tău de eval să devină învechit.
• Bucla este sistemul. Un dataset golden static putrezește; unul care crește se compune.

Dacă vrei o a doua pereche de ochi pe pipeline-ul tău de eval, obține o consultație gratuită.