Evaluasi LLM 2026: Perbandingan LangSmith, Ragas, DeepEval, dan Promptfoo untuk RAG dan Agen Produksi
Perbandingan praktis LangSmith, Ragas, DeepEval, dan Promptfoo untuk evaluasi LLM dan RAG produksi di 2026, lengkap dengan metrik, harga, dan strategi CI/CD.
Evaluasi LLM adalah praktik mengukur kualitas output model bahasa secara sistematis menggunakan metrik kuantitatif (faithfulness, context relevance, answer relevance) dan kualitatif (LLM-as-judge), sehingga tim engineering bisa membandingkan perubahan prompt, model, atau retrieval pipeline secara objektif sebelum dipromosikan ke produksi. Pada 2026, empat framework mendominasi ekosistem: LangSmith dari LangChain, Ragas untuk RAG, DeepEval dengan paradigma "pytest untuk LLM", dan Promptfoo untuk evaluasi berbasis CLI dan red teaming. Saya sudah memakai keempatnya pada proyek RAG dan agen produksi sepanjang dua kuartal terakhir, dan artikel ini membandingkan kekuatan, kelemahan, serta biaya nyata masing-masing.
LangSmith unggul untuk observabilitas trace end-to-end pada aplikasi LangChain/LangGraph; cocok jika stack Anda sudah memakai LangChain dan butuh dashboard hosted.
Ragas adalah standar de facto untuk RAG-specific metrics (faithfulness, context precision, answer relevance) dengan integrasi Pydantic dan dukungan Hugging Face datasets.
DeepEval menerapkan paradigma pytest sehingga eval bisa berjalan di CI/CD seperti unit test biasa; mendukung G-Eval, hallucination, bias, dan toxicity out of the box.
Promptfoo bersifat config-driven (YAML) dan menonjol untuk red teaming, jailbreak testing, serta perbandingan paralel ratusan prompt variant di terminal.
Untuk produksi serius, gabungkan dua: satu untuk online tracing (LangSmith atau Langfuse) dan satu untuk offline eval di CI (Ragas atau DeepEval).
Biaya LLM-as-judge bisa membengkak dengan cepat; pakai Haiku 4.5 atau GPT-4o-mini sebagai judge default, bukan Opus atau GPT-4o.
Mengapa evaluasi LLM jadi krusial di 2026
Tiga tahun lalu, "ship and pray" masih bisa diterima karena prompt sederhana dan ekspektasi pengguna rendah. Pada 2026, lanskapnya beda jauh: aplikasi memakai arsitektur agen multi-step dengan ratusan node, retrieval pipeline melibatkan chunking adaptif dan reranking, dan satu regression bisa merusak pengalaman ribuan user dalam hitungan menit. Tanpa eval otomatis, tim engineering pada dasarnya buta. Perubahan prompt yang terlihat "lebih baik" pada lima contoh manual bisa menurunkan faithfulness 15% secara agregat.
Honestly, ini bagian yang dulu paling saya remehkan. Survei Arize AI 2026 State of LLM Evaluation menemukan bahwa 78% tim yang mengoperasikan LLM di produksi sekarang menjalankan eval batch setidaknya mingguan, naik dari 31% pada 2024. Penyebabnya jelas: model baru rilis hampir setiap bulan (Claude Opus 4.7, GPT-5.1, Gemini 2.5), dan tim butuh data untuk memutuskan kapan migrasi worth it. Eval bukan lagi opsional, ia satu-satunya cara objektif menjawab pertanyaan "apakah upgrade ini meningkatkan kualitas?" tanpa mengandalkan intuisi.
Yang berubah pada 2026 adalah maturity tooling. Empat framework di artikel ini sudah lewat versi 1.0, memiliki integrasi Pydantic untuk structured output, dan mendukung trace OpenTelemetry. Pertanyaannya bukan lagi "apakah kita perlu eval", tapi "framework mana yang cocok dengan stack dan tim kami".
Tabel perbandingan empat framework evaluasi LLM
Tabel di bawah merangkum perbandingan praktis berdasarkan versi terbaru per Juni 2026. Saya menyertakan dimensi yang biasanya jadi tie-breaker dalam keputusan vendor: model pricing, self-host option, dan kurva belajar.
Dimensi
LangSmith
Ragas
DeepEval
Promptfoo
Versi terbaru
v0.3 (cloud)
v0.2.14
v3.2
v0.110
Lisensi
Proprietary (SaaS)
Apache 2.0
Apache 2.0
MIT
Self-host
Enterprise plan saja
Ya, gratis
Ya, gratis (Confident AI untuk hosted)
Ya, gratis
Fokus utama
Trace observability + dataset eval
RAG metrics (faithfulness, context)
Pytest-style assertions
YAML config + red teaming
Integrasi LangChain
Native, auto-trace
Manual via callbacks
Manual via decorator
Via custom provider
Harga (cloud)
$39/seat/bulan + usage
Gratis (OSS) + biaya judge LLM
Gratis + Confident AI $49/bulan
Gratis (CLI murni)
CI/CD ready
Sedang (via API)
Sedang (perlu wrapper)
Sangat baik (pytest native)
Sangat baik (GitHub Action)
Kurva belajar
Rendah
Sedang
Rendah jika familiar pytest
Rendah (YAML)
LangSmith: observabilitas trace untuk LangChain
LangSmith adalah platform observabilitas dan evaluasi yang dibangun oleh LangChain Inc. Kekuatan utamanya adalah auto-instrumentation: kalau aplikasi Anda memakai LangChain atau LangGraph, cukup set environment variable LANGSMITH_API_KEY dan setiap chain, tool call, dan retrieval otomatis muncul sebagai trace dengan latency, token, dan biaya per step.
Saya menemukan LangSmith paling berguna untuk tiga skenario: (1) debugging agen multi-step yang gagal di langkah ketujuh dari sepuluh, (2) monitoring produksi dengan alert berbasis latency atau error rate, dan (3) human annotation untuk membangun gold dataset dari trace nyata. Fitur "Annotation Queue" yang dirilis akhir 2025 sangat membantu di proyek terakhir saya, karena domain expert bisa rate output langsung dari dashboard tanpa setup tooling terpisah.
Kelemahan LangSmith adalah lock-in ke ekosistem LangChain. Kalau Anda memakai DSPy, LlamaIndex, atau stack custom, integrasi butuh wrapping manual. Selain itu, untuk metrik RAG-spesifik seperti context recall, LangSmith memanggil LangChain evaluators di bawah kapotnya, yang seringnya lebih lambat dan kurang akurat dibanding Ragas yang dispesialisasi untuk itu.
Ragas adalah library Python open-source yang spesialis di evaluasi RAG pipeline. Versi 0.2 yang rilis akhir 2025 menulis ulang core dengan Pydantic v2 dan menambahkan dukungan multi-modal eval (gambar dan teks). Metrik flagship-nya, sering disebut "RAG triad", adalah faithfulness, answer relevance, dan context relevance. Ketiganya menjawab pertanyaan berbeda: apakah jawaban didukung konteks (faithfulness), apakah jawaban menjawab pertanyaan (relevance), dan apakah konteks yang diambil relevan (context relevance).
Yang membedakan Ragas dari kompetitor adalah kedalaman metrik RAG-spesifik. Misalnya context_precision menghitung berapa proporsi chunk dalam top-k yang benar-benar relevan, dan context_recall mengukur cakupan ground truth dalam retrieved context. Untuk tim yang serius optimasi vector database dan retrieval strategy, metrik ini wajib karena memisahkan masalah retrieval dari masalah generation.
from ragas import evaluate
from ragas.metrics import (
faithfulness,
answer_relevancy,
context_precision,
context_recall,
)
from datasets import Dataset
# Format dataset: question, answer, contexts, ground_truth
data = {
"question": ["Apa fitur baru Claude 4.7?"],
"answer": ["Claude 4.7 memperkenalkan extended thinking..."],
"contexts": [["Claude 4.7 dirilis dengan extended thinking mode..."]],
"ground_truth": ["Extended thinking dan memory tool."],
}
dataset = Dataset.from_dict(data)
results = evaluate(
dataset=dataset,
metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)
print(results.to_pandas())
DeepEval: pytest untuk LLM
DeepEval mengambil pendekatan yang berbeda secara filosofis: eval LLM harus terasa seperti unit test. Anda menulis test case Python, menjalankan deepeval test run (atau pytest biasa), dan dapat output pass/fail per metrik. Ini cocok untuk tim engineering yang sudah punya disiplin CI/CD dan mau perlakukan eval sebagai gate sebelum merge.
Yang saya suka dari DeepEval adalah variasi metrik bawaan: G-Eval (custom criteria dengan LLM judge), HallucinationMetric, ToxicityMetric, BiasMetric, dan SummarizationMetric. G-Eval khususnya powerful karena memungkinkan Anda mendefinisikan kriteria custom dalam bahasa natural (misalnya: "apakah jawaban mencantumkan disclaimer hukum jika menjawab pertanyaan legal"). DeepEval akan men-generate chain-of-thought judge prompt secara otomatis dan menghitung skor 0-1.
from deepeval import assert_test
from deepeval.metrics import GEval, FaithfulnessMetric
from deepeval.test_case import LLMTestCase, LLMTestCaseParams
def test_rag_jawab_pertanyaan_dengan_faithful():
correctness = GEval(
name="Correctness",
criteria="Tentukan apakah actual_output benar berdasarkan expected_output",
evaluation_params=[
LLMTestCaseParams.ACTUAL_OUTPUT,
LLMTestCaseParams.EXPECTED_OUTPUT,
],
threshold=0.7,
)
faithfulness = FaithfulnessMetric(threshold=0.8, model="gpt-4o-mini")
test_case = LLMTestCase(
input="Apa ibu kota Indonesia?",
actual_output="Jakarta adalah ibu kota Indonesia.",
expected_output="Jakarta",
retrieval_context=["Jakarta merupakan ibu kota Indonesia sejak 1945."],
)
assert_test(test_case, [correctness, faithfulness])
Integrasi pytest berarti GitHub Actions workflow Anda cuma butuh satu baris tambahan, dan failed eval tampil di PR diff seperti failed test biasa. Untuk tim yang sudah punya budaya TDD, kurva adopsi DeepEval terasa hampir nol.
Promptfoo: red teaming dan A/B prompt config-driven
Promptfoo agak berbeda dari tiga lainnya. Ini bukan library Python, tapi CLI tool yang dikonfigurasi via YAML. Filosofinya: eval seharusnya bisa dijalankan tanpa menulis kode. Anda mendefinisikan prompt, dataset, dan assertion dalam file promptfooconfig.yaml, lalu jalankan promptfoo eval. Hasilnya berupa matriks side-by-side antara model atau prompt variant yang bisa di-share via URL.
Kelebihan terbesar Promptfoo adalah kemampuan red teaming. Modul promptfoo redteam menggenerate ratusan adversarial prompts (jailbreak attempts, prompt injection, PII extraction, off-topic exploits) dan menjalankannya terhadap aplikasi Anda. Hasil dipresentasikan sebagai security report dengan severity per kategori. Ini valuable untuk tim yang men-deploy LLM ke user-facing product dan butuh due diligence soal prompt security.
# promptfooconfig.yaml
description: "Bandingkan Claude vs GPT untuk customer support"
prompts:
- "Jawab pertanyaan customer dengan ramah: {{question}}"
providers:
- anthropic:messages:claude-haiku-4-5
- openai:chat:gpt-4o-mini
- openai:chat:gpt-5-nano
tests:
- vars:
question: "Bagaimana cara reset password saya?"
assert:
- type: contains
value: "reset"
- type: llm-rubric
value: "Jawaban ramah, jelas, dan menyebutkan langkah konkret"
- type: latency
threshold: 2000
- vars:
question: "Akun saya kena hack, apa yang harus saya lakukan?"
assert:
- type: llm-rubric
value: "Jawaban menyarankan reset password DAN menghubungi support"
Bagaimana cara mengevaluasi RAG pipeline secara end-to-end
Evaluasi RAG yang benar memisahkan dua sub-problem: retrieval dan generation. Banyak tim cuma mengukur jawaban akhir, lalu bingung kenapa kualitas turun setelah ganti embedding model. Padahal masalahnya di retrieval, bukan LLM. Pendekatan end-to-end yang saya pakai melibatkan empat lapisan metrik.
Lapisan 1, retrieval quality: hitung context precision dan context recall menggunakan Ragas. Threshold sehat adalah precision >0.7 dan recall >0.85 untuk top-5 chunk. Kalau recall rendah, problemnya di chunking strategy atau embedding model; kalau precision rendah, butuh reranker.
Lapisan 2, generation faithfulness: ukur apakah jawaban benar-benar didukung oleh context yang diambil. Faithfulness rendah dengan retrieval bagus biasanya berarti model halusinasi, sering disebabkan prompt yang tidak cukup tegas atau model terlalu kecil untuk task.
Lapisan 3, answer relevance: apakah jawaban menjawab pertanyaan, bukan sekadar valid. Saya pernah punya RAG yang faithfulness 0.95 tapi answer relevance 0.6. Model menjawab dengan kutipan langsung dari context tanpa menyatu jadi jawaban yang konsisten, dan saya hit bug ini saat shipping fitur Q&A internal.
Lapisan 4, business metrics: resolution rate, deflection rate, atau task success rate dari trace nyata. Ini jembatan antara metrik teknis dan dampak bisnis.
Metrik mana yang harus dipakai untuk eval LLM
Pilihan metrik bergantung pada jenis aplikasi. Untuk chatbot RAG, fokus pada RAG triad plus latency. Untuk agen multi-step, tambahkan tool selection accuracy dan trajectory similarity. Untuk content generation, gunakan G-Eval dengan kriteria brand voice plus toxicity check. Untuk classification, F1 dan confusion matrix klasik masih relevan dan jauh lebih murah daripada LLM-as-judge.
Anti-pattern yang paling sering saya lihat adalah memakai BLEU atau ROUGE untuk free-form generation. Kedua metrik ini dirancang untuk machine translation dan summarization dengan reference tunggal. Pada output LLM open-ended, korelasi dengan kualitas manusia sangat rendah. Lebih baik G-Eval atau LLM-as-judge dengan rubric eksplisit.
Untuk topik sensitif (medical, legal, financial), jangan andalkan metrik agregat saja. Tetapkan critical assertion individual: "jawaban tidak boleh menyatakan diagnosis pasti", "jawaban harus mencantumkan disclaimer". DeepEval dengan G-Eval atau Promptfoo dengan llm-rubric sangat cocok untuk ini.
Integrasi dengan CI/CD dan strategi sampling
Eval di CI bukan berarti menjalankan semua test pada setiap PR; itu lambat dan mahal. Strategi yang saya pakai berlapis. Smoke test pada setiap PR berjalan 20-50 contoh kritikal, harus selesai <3 menit, dan jadi gate merge. Full regression suite mingguan jalan terhadap dataset 500-2.000 contoh dengan multiple judge models. Production eval harian mengambil sampel 1-5% dari trace nyata via LangSmith atau Langfuse, jalankan eval async, dan trigger alert kalau metrik turun >5%.
Untuk implementasi praktis, GitHub Actions dengan caching sangat membantu. Cache embedding ground truth dataset dan judge model responses berdasarkan content hash. Ini bisa memotong biaya eval 60-80% pada PR yang tidak mengubah dataset atau judge.
Rekomendasi akhir berdasarkan use case
Berikut keputusan cepat berdasarkan profil tim dan stack yang sudah ada. Anggap rekomendasi ini sebagai titik awal; kombinasikan dua tools (satu offline, satu online) untuk produksi serius.
Startup kecil dengan stack LangChain: LangSmith Developer (gratis) untuk tracing plus Ragas untuk batch eval RAG. Total biaya <$50/bulan untuk fase awal.
Tim engineering dengan disiplin CI/CD: DeepEval di GitHub Actions sebagai merge gate plus Langfuse self-hosted untuk production observability. Self-host menjaga compliance dan biaya prediktabel.
Tim yang fokus pure RAG dengan dataset besar: Ragas adalah pilihan jelas. Pasangkan dengan custom dashboard di Grafana atau Streamlit untuk visualisasi tren metrik.
Tim security-conscious atau B2C consumer-facing: Promptfoo untuk red teaming wajib, plus salah satu dari tiga lainnya untuk quality eval. Jalankan red team suite minimal setiap rilis besar.
Enterprise dengan compliance ketat: kombinasi self-hosted Langfuse plus DeepEval atau Ragas open-source. Hindari SaaS pure karena data sensitif dari evaluasi (prompt, output, ground truth) bisa termasuk PII.
Pertanyaan yang Sering Diajukan
Apa perbedaan utama antara LangSmith dan Ragas?
LangSmith adalah platform observabilitas hosted yang fokus pada tracing dan monitoring aplikasi LangChain di produksi. Ragas adalah library Python open-source yang spesialis di metrik RAG (faithfulness, context precision, dll) dan dijalankan offline pada dataset. Keduanya sering dipakai bersamaan: LangSmith untuk online tracing, Ragas untuk batch eval di CI.
Apakah DeepEval gratis dan open source?
Ya, DeepEval dilisensikan Apache 2.0 dan sepenuhnya gratis untuk self-host dan modifikasi. Confident AI adalah platform hosted dari pembuat DeepEval yang menawarkan dashboard, dataset management, dan reporting dengan harga mulai $49/bulan, tapi 95% fungsionalitas eval tersedia gratis via library Python.
Berapa biaya LangSmith untuk produksi?
Per Juni 2026, LangSmith tier Developer gratis hingga 5.000 trace/bulan. Plus mulai $39/seat/bulan plus $0.50 per 1.000 trace tambahan. Enterprise plan dengan self-host dan SSO biasanya $2.000+/bulan tergantung volume. Untuk aplikasi dengan jutaan trace per bulan, biaya bisa jadi signifikan, jadi pertimbangkan Langfuse self-hosted sebagai alternatif.
Model apa yang sebaiknya dipakai sebagai LLM-as-judge?
Untuk eval rutin, gunakan model murah dan cepat seperti Claude Haiku 4.5 atau GPT-4o-mini. Keduanya menunjukkan korelasi tinggi dengan judgment manusia pada studi 2026 sambil biaya hanya seperdua puluh model premium. Simpan Claude Opus 4.7 atau GPT-5 untuk validasi final benchmark atau kasus high-stakes saja.
Bisakah saya menjalankan evaluasi LLM tanpa ground truth dataset?
Bisa, untuk beberapa metrik. Faithfulness, answer relevance, dan G-Eval custom criteria tidak memerlukan ground truth karena membandingkan output terhadap context atau kriteria. Tapi context recall, answer correctness, dan semantic similarity butuh reference jawaban. Strategi praktis: mulai dengan reference-free metrics, kumpulkan trace produksi, lalu annotate sebagian untuk membangun gold dataset bertahap.
Panduan LLM observability produksi 2026: OpenTelemetry GenAI conventions, perbandingan Langfuse vs Helicone vs Arize Phoenix, contoh kode Python untuk instrumentasi Claude dan OpenAI, plus dashboard Grafana yang benar-benar dipakai on-call.