Evaluasi LLM Online vs Offline: Mana yang Kamu Butuhkan (dan Kapan)
Evaluasi LLM online vs offline adalah satu keputusan, bukan dua, dan suite promptfoo kami membuktikannya Selasa lalu: satu system prompt yang ditulis ulang, 47 test case, faithfulness turun dari 0,91 ke 0,74 dalam sekitar 90 detik waktu CI. Cek offline menangkap regresi itu sebelum merge; monitoring produksi baru akan menemukannya belakangan, menyamar sebagai thread support. Offline vs online, vonis yang sama: dua jalur, tugas berbeda.
Eval LLM offline menjalankan model kamu terhadap dataset tetap sebelum deployment, membuktikan bahwa sebuah perubahan tidak merusak kualitas yang terukur. Evaluasi online memberi skor pada traffic produksi yang live setelah rilis, menyingkap apa yang tidak pernah ada di dataset. Kebanyakan tim butuh keduanya, secara berurutan: offline menjaga deploy, online menangkap drift.
Poin-Poin Penting
- Evaluasi offline berjalan terhadap dataset tetap sebelum deploy; evaluasi online memberi skor pada traffic live setelah rilis.
- Kebanyakan tim butuh keduanya: offline menjaga deploy, online menangkap yang terlewat oleh dataset.
- Offline menangkap regresi prompt dan rusaknya format; online menangkap drift, latensi di bawah beban, dan keanehan integrasi.
- Pasang eval offline sebagai merge gate di CI; alirkan skor online dari trace produksi ke eval set kamu.
Bagaimana Online dan Offline Sebenarnya Berbeda? (9 Dimensi)
Kedua mode berbeda pada sembilan sumbu, tapi yang paling menentukan adalah sumber data: evaluasi offline memberi skor pada dataset tetap yang ter-version sebelum deploy, sedangkan evaluasi online memberi skor pada traffic live setelah rilis. Semua perbedaan lain (biaya, latensi, risiko, tata kelola) mengikuti dari pembelahan itu.
Label Studio's learning center membingkai keduanya sebagai mode yang saling melengkapi, bukan saingan, dan kami setuju. Tabel ini memperluas bingkai tersebut dengan metrik khusus LLM yang tidak dicakup versi ML generik mereka.
| Dimensi | Offline | Online |
|---|---|---|
| Sumber data | Dataset golden tetap, ter-version di git | Trace produksi live, disampling |
| Waktu | Sebelum deploy, di setiap PR | Setelah rilis, terus-menerus |
| Biaya per run | Token judge per run suite; biaya marginal hampir nol | Token judge pada traffic tersampling; skala mengikuti volume |
| Kendala latensi | Tidak ada; batch dengan santai | Anggaran sub-detik di jalur panas |
| Risiko ke pengguna | Nol; kegagalan tidak pernah sampai ke pengguna | Nyata; output buruk mengenai sesi live |
| Kecepatan feedback | Menit per PR | Detik hingga menit di stream |
| Jenis metrik | Faithfulness, relevansi jawaban, kepatuhan format, skor benchmark | Persentil latensi, error rate, tingkat halusinasi, feedback pengguna |
| Keterulangan | Deterministik dengan model dan dataset yang dipin | Non-deterministik; komposisi traffic berubah tiap hari |
| Tata kelola dan audit | Artefak ter-version, bisa di-diff antar rilis | Dashboard dan alert; lebih sulit direproduksi |
Interpretasi kami: kolom offline menjawab "apakah perubahan ini merusak sesuatu?", dan kolom online menjawab "apakah produksi bergeser menjauh dari yang kami uji?". Baris jenis metrik adalah titik di mana keduanya paling jauh menyimpang; panduan metrik evaluasi LLM kami membedah masing-masing.
Apa yang Ditangkap Tiap Mode, dan Apa yang Lolos dari Keduanya?
Tiap mode memiliki kelas kegagalan privat yang tidak bisa dilihat mode lain. Offline menangkap perubahan yang kamu buat; online menangkap perubahan yang dibuat dunia di sekitarmu. Kegagalan mahal, yang bertahan dari kedua jaring, butuh reviewer manusia. Taksonomi ini adalah sintesis kami dari yang dilaporkan tiap mode, bukan standar yang dipublikasikan.
| Kuadran | Contoh | Tindakan |
|---|---|---|
| Hanya offline | Regresi prompt, format output rusak, penurunan skor benchmark, faithfulness di bawah ambang | Blokir merge di CI |
| Hanya online | Drift distribusi, latensi di bawah beban, keanehan integrasi, pola penyalahgunaan adversarial | Alert, sampling trace, alihkan ke eval set |
| Ditangkap keduanya | Lonjakan tingkat halusinasi, erosi konsistensi faktual | Pertahankan keduanya; deduplikasi usahanya, bukan cakupannya |
| Tidak tertangkap keduanya | Edge case baru, penilaian kualitas subjektif, pergeseran brand voice | Antrean review manusia; case terlabeli masuk ke set offline |
Kuadran hanya-offline adalah tempat CI gate membuktikan nilainya: prompt yang ditulis ulang dan diam-diam menjatuhkan kepatuhan format dari 99% ke 91% tidak terlihat di code review tapi mencolok di suite 47 case. Kuadran hanya-online lebih licik. Pengguna asli memfrasakan hal yang tidak pernah ada di golden set kamu, API pihak ketiga timeout pada jadwal yang tidak pernah kena staging, dan seseorang akan menyuapkan prompt 40.000 karakter ke chatbot kamu hanya untuk melihat apa yang terjadi. Untuk sisi itu, panduan kami tentang evaluasi agen di produksi mencakup penilaian lintasan multi-langkah, bukan hanya output tunggal.
Baris terbawah adalah yang dilewati tim, dan yang membakar mereka. Kegagalan yang membuat kamu kehilangan pengguna adalah yang tidak bisa ditangkap salah satu mode sendirian. Mereka butuh manusia di dalam loop.
Bagaimana Memasang Eval Offline ke CI Gate? (Konfigurasi yang Tidak Ditunjukkan Siapa Pun)
Tambahkan eval runner sebagai status check wajib di setiap pull request yang menyentuh prompt, model, atau konfigurasi retrieval. Tegaskan sebuah ambang. Blokir merge di bawahnya. promptfoo mendokumentasikan pola CI persis seperti ini, dan itulah yang kami jalankan.
Langkah GitHub Actions
Versi ringkas dari gate yang kami jalankan hari ini:
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-judgeKonfigurasi YAML mendeklarasikan test case dan assertion; eval keluar dengan non-zero ketika suite jatuh di bawah ambang, GitHub menandai check wajib sebagai gagal, dan tombol merge jadi abu-abu. Filter paths penting: perbaikan README seharusnya tidak membakar token judge.
Apa yang sebenarnya ditangkap gate ini
Versi live memberi skor pada rantai RAG support-agent kami terhadap 47 golden case di setiap PR yang memengaruhi prompt. Satu run penuh makan sekitar 90 detik waktu CI, dan merge otomatis terblokir jika faithfulness turun di bawah 0,82. Dalam tiga bulan, ia menangkap dua regresi yang seharusnya sudah terkirim: penulisan ulang system prompt yang mendorong faithfulness dari 0,91 ke 0,74, dan perubahan retriever yang menggandakan panjang konteks dan menyeret relevansi jawaban ke bawah ambang. Keduanya tidak terlihat berbahaya saat review.
Faithfulness gate di CI memakan 90 detik per PR. Regresi faithfulness di produksi memakan satu thread support dan satu rollback dari kamu.
Kami membandingkan runner yang bisa dipasang ke pola ini, promptfoo, DeepEval, dan sisanya, dalam ringkasan tool evaluasi LLM kami.
Tool Mana Menjalankan Mode Mana? (Matriks Tool-ke-Mode)
Tidak ada satu tool pun yang memiliki kedua jalur dengan rapi. promptfoo dan DeepEval adalah runner offline-first yang bisa memberi skor pada data produksi yang diekspor secara terjadwal; Langfuse dan LangSmith adalah penyimpan trace online-first yang menempelkan scorer LLM-as-judge ke trace yang di-ingest. Matriks ini adalah pembacaan kami atas dokumentasi tiap vendor: interpretasi, bukan kitab suci.
| Tool | Runner offline | Scorer online | Keduanya native? | Yang TIDAK dilakukan |
|---|---|---|---|---|
| promptfoo | Ya: suite YAML, native CI, paket red-team | Parsial: konfigurasi sama terhadap log yang diekspor | Offline-first; online butuh langkah ekspor | Ingest trace live; berperan sebagai dashboard monitoring |
| DeepEval | Ya: tes gaya pytest, 14+ metrik | Ya, lewat platform Confident AI | Ya, dengan add-on hosted | Library open-source saja hanya offline |
| Langfuse | Parsial: eksperimen dataset lewat SDK | Ya: evaluator judge pada trace yang di-ingest | Ya: dataset plus scorer trace | Menjalankan merge gate CI kamu; itu kamu pasang sendiri |
| LangSmith | Ya: dataset dan eksperimen offline | Ya: automasi memberi skor pada trace tersampling | Ya | Hidup di luar stack LangChain tanpa friksi |
| OpenAI Evals | Ya: eval YAML gaya registry | Tidak | Tidak | Pipeline trace produksi; model non-OpenAI |
| Arize Phoenix | Ya: eksperimen notebook-first | Ya: span dan trace dengan evaluator inline | Ya | Setup ringan; observabilitas yang utama |
Pilih promptfoo atau DeepEval jika kebutuhan pertama kamu adalah merge gate yang memblokir prompt buruk di CI. Pilih Langfuse atau LangSmith jika kebutuhan pertama kamu adalah memberi skor pada traffic live, dan perbandingan Langfuse vs LangSmith kami membahas pilihan itu dalam-dalam. OpenAI Evals tetap jadi yang aneh: runner offline gaya registry tanpa sisi produksi.
promptfoo menjaga PR kamu. Langfuse memberi skor pada trace produksi kamu. Keduanya tidak saling menggantikan.
Bagaimana Feedback Loop Mengubah Kegagalan Online Menjadi Tes Offline?
Sampling trace produksi berskor rendah, labeli, dan commit ke eval set offline. Suite regresi lalu tumbuh bersama setiap kejutan yang dilemparkan produksi ke kamu, dan deploy berikutnya dijaga oleh set yang sudah diperluas. Bingkai flywheel ini milik kami; inilah bagian yang tidak pernah dibangun kebanyakan tim.
Siklusnya, seperti yang kami jalankan:
- Scorer online menandai trace di bawah skor judge 0,7.
- Kami sampling 20 hingga 30 trace tertanda per minggu.
- Manusia melabeli masing-masing: output yang diharapkan plus kelas kegagalan.
- Case terlabeli bergabung ke eval set offline sebagai golden example baru.
- PR berikutnya berjalan terhadap suite yang diperluas, dan loop mulai lagi.
Sampling dimulai di lapisan observabilitas LLM kamu, karena trace adalah bahan bakunya. Soal irama: mingguan mengalahkan bulanan, karena drift berbunga. Kami melabeli 10 hingga 15 case per minggu, dan set "cukup besar" ketika label baru berhenti menggerakkan pass rate, sekitar 150 hingga 250 case untuk support agent yang sempit. Garis antara mode terus kabur: Deepchecks melaporkan bahwa engineer Union.ai menjadwalkan evaluasi "offline" mereka setiap beberapa menit, efektif mengubahnya menjadi cek mendekati real-time.
Eval set kamu bukan artefak tetap. Ia tumbuh setiap minggu saat produksi mengejutkan kamu.
Kapan Kamu Butuh Keduanya? (Evaluasi LLM Online vs Offline per Tahap)
Kamu butuh keduanya sejak minggu rilis dan seterusnya, tapi keseimbangannya bergeser per tahap: offline memikul kerja pra-deploy sendirian, minggu rilis menambahkan shadow atau canary scoring, kondisi mapan bersandar pada monitoring online dengan run ulang offline berkala, dan alert drift harus berakhir pada tes offline yang direproduksi plus eval set yang lebih besar.
| Tahap | Offline | Online | Tindakan |
|---|---|---|---|
| Pra-deploy | Gate regresi di setiap PR | Belum ada | Blokir merge di bawah ambang |
| Minggu rilis | Suite penuh pada release candidate | Shadow atau canary scoring pada 5-10% traffic | Bandingkan skor online terhadap baseline offline |
| Kondisi mapan | Re-eval berkala pada dataset yang disegarkan, mingguan atau bulanan | Scoring tersampling kontinu plus alert | Awasi drift; re-baseline tiap kuartal |
| Drift terdeteksi | Reproduksi trace yang gagal secara offline | Alert yang memicu trigger | Tambahkan trace terlabeli ke eval set; jaga ulang deploy berikutnya |
Pra-deploy adalah tempat termurah untuk ketat: merge yang diblokir memakan menit; rilis yang buruk memakan kepercayaan. Minggu rilis adalah tempat tim kurang berinvestasi, padahal shadow scoring pada irisan traffic kecil memakan sedikit biaya dan menyingkap apakah golden set berbohong. Kondisi mapan adalah tempat rasa puas diri masuk, jadi jadwalkan re-eval di kalender.
Bagaimana dengan EU AI Act?
Kewajiban berisiko tinggi EU AI Act berlaku bertahap hingga Agustus 2026, dengan linimasa tenggat penuh dipublikasikan di EUR-Lex, dan pola kesesuaian memetakan dengan rapi ke dua mode. Bukti offline terdokumentasi menunjukkan sistem memenuhi target kualitas sebelum rilis; monitoring online berkelanjutan menunjukkan ia terus memenuhinya setelahnya. Pembacaan kami adalah bahwa audit trail butuh kedua artefak, karena log offline saja tidak membuktikan sistem tetap patuh, dan dashboard saja tidak membuktikan ia patuh saat diluncurkan. Itu interpretasi, bukan nasihat hukum; pilar pipeline evaluasi LLM kami memetakan seluruh set persyaratan.
Evaluasi offline adalah bukti kamu. Evaluasi online adalah sistem peringatan dini kamu. Regulator menginginkan keduanya.
Tentang penulis: Mert Batur adalah Co-Founder Techsy.io, tempat tim mengirimkan agen AI, sistem automasi, dan pipeline voice/SDR untuk klien B2B. Ia menulis tentang stack tooling LLM yang benar-benar dipakai tim Techsy di produksi. Terhubung di LinkedIn.
Pertanyaan yang Sering Diajukan
Apa itu evaluasi LLM offline?
Evaluasi LLM offline menjalankan model atau prompt terhadap dataset tetap yang ter-version sebelum deployment. Cek tipikal mencakup faithfulness terhadap konteks yang di-retrieve, relevansi jawaban, kepatuhan format, dan skor benchmark. Karena dataset tidak pernah berubah di tengah run, hasilnya bisa diulang dan bisa di-diff, yang persis mengapa suite offline bekerja sebagai merge gate CI.
Apa itu evaluasi LLM online?
Evaluasi LLM online memberi skor pada traffic produksi yang live setelah rilis. Scorer LLM-as-judge menilai trace tersampling untuk halusinasi, nada, atau kebenaran tool-call, dan skornya mengalir ke dashboard. Ia juga menyerap sinyal yang tidak bisa dilihat tes offline: latensi di bawah beban, feedback pengguna, dan bagaimana kueri nyata berbeda dari golden set kamu.
Kapan saya harus memakai evaluasi LLM offline vs online?
Pakai evaluasi offline untuk menjaga deploy: setiap perubahan prompt, model, atau retrieval harus lulus suite sebelum merge. Pakai evaluasi online untuk mengawasi apa yang rilis. Kebanyakan tim mengurutkan keduanya alih-alih memilih satu: offline dulu, online sejak minggu rilis dan seterusnya, dengan kegagalan produksi mengalir balik ke set offline.
Apa contoh evaluasi LLM online vs offline?
Contoh offline: suite promptfoo menjalankan 200 pertanyaan support golden di setiap pull request dan memblokir merge jika faithfulness turun di bawah 0,82. Contoh online: Langfuse memberi skor pada 10% trace live dengan cek halusinasi LLM-as-judge dan alert ketika rata-rata mingguan merosot. Rubrik sama, sumber data berbeda.
Bagaimana human-in-the-loop cocok dengan evaluasi LLM?
Manusia menutup celah yang tidak dicakup kedua mode: edge case baru, penilaian kualitas subjektif, dan pergeseran brand voice. Irama praktis adalah melabeli 10 hingga 20 trace berskor rendah tersampling per minggu dan meng-commit case terlabeli ke eval set offline. Antrean review adalah input pipeline, bukan proyek sampingan.
Bagaimana evaluasi Langfuse bekerja untuk scoring online?
Langfuse meng-ingest trace dari aplikasi kamu, lalu menempelkan evaluator LLM-as-judge yang memberi skor pada tiap trace terhadap rubrik: halusinasi, relevansi, toksisitas, atau prompt kustom. Skor mendarat di dashboard yang dikunci ke sesi dan pengguna. Tim mengekspor trace berskor rendah persisten ke dataset offline untuk regression testing. Ringkasan platform observabilitas kami membandingkan penyimpan trace yang memasok pola ini.
Bagaimana menambahkan eval offline ke pipeline CI/CD?
Tambahkan eval runner sebagai status check wajib di pull request yang menyentuh prompt, model, atau konfigurasi retrieval. promptfoo dan DeepEval keduanya berjalan headless dan keluar non-zero saat assertion gagal, yang memblokir merge secara otomatis. Gate YAML di awal artikel ini adalah template yang berfungsi; mulai dengan 30 hingga 50 case.
Apakah EU AI Act mewajibkan evaluasi offline atau online?
Efektifnya, keduanya. Untuk sistem berisiko tinggi, Act mengharapkan bukti terdokumentasi bahwa target kualitas dipenuhi sebelum rilis, yang berarti artefak offline, plus monitoring berkelanjutan setelah deployment, yang berarti telemetri online. Tenggat bertahapnya berjalan hingga Agustus 2026 menurut EUR-Lex. Itu pembacaan kami atas pola kesesuaian, bukan nasihat hukum.
Bisakah LLM-as-a-judge berjalan di kedua mode offline dan online?
Bisa, dan seharusnya, karena rubriknya bisa dipindahkan. Offline, judge memberi skor pada setiap output eval set secara batch selama CI. Online, prompt judge yang sama memberi skor pada trace produksi tersampling mendekati real time. Menjaga satu rubrik di kedua mode adalah yang membuat baseline offline kamu bisa dibandingkan dengan sinyal drift online kamu.
Metrik apa yang berbeda antara evaluasi offline dan online?
Metrik offline mengukur kualitas output terhadap ground truth: faithfulness, relevansi jawaban, kepatuhan format, skor benchmark. Metrik online menambahkan sinyal operasional dan perilaku: latensi p95, error rate, tingkat halusinasi pada traffic live, skor drift, dan kepuasan pengguna. Daftar offline bertanya "apakah ini bagus?" dan daftar online bertanya "apakah ini masih bagus?"
Versi Pendeknya
- Evaluasi offline dan online adalah jalur yang saling melengkapi, bukan pilihan salah satu: satu menjaga apa yang kamu kirim, yang lain mengawasi apa yang sudah kamu kirim.
- Mulai dengan CI gate minggu ini, tambahkan scoring trace online saat rilis, dan pasang feedback loop sebelum eval set kamu basi.
- Loop adalah sistemnya. Dataset golden yang statis membusuk; yang tumbuh berbunga.
Jika kamu ingin sepasang mata kedua untuk pipeline eval kamu, dapatkan konsultasi gratis.