RAGAS (
02-ragas-ci-harness.md) is the default answer to "how do I evaluate my RAG system?" — but it's not the only framework, and interviewers who work in eval-heavy roles will probe past it. This covers four frameworks that each fix a specific gap in generic LLM-as-judge evaluation: judge calibration (ARES), diagnostic granularity (RAGChecker), judge training (ConsJudge), and human-aligned hallucination leaderboards (FaithJudge).
RAGAS's judge is a general-purpose LLM (GPT-4-class) prompted with a fixed rubric per metric. That's cheap and requires no gold labels, but it has three known weaknesses:
ARES, RAGChecker, and ConsJudge each address one of these three gaps.
Paper: Saad-Falcon et al., ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems, NAACL 2024. arXiv:2311.09476 · GitHub
Problem it targets: a generic LLM judge's score is a point estimate with no notion of how reliable it is on your data distribution.
Mechanism:
Generic LLM judge (RAGAS-style):
score = judge_llm(query, context, answer) → 0.81 (no error bar)
ARES:
1. synthetic_data = generate_domain_examples(your_corpus)
2. judge = finetune(base_llm, synthetic_data) → domain-specific judge
3. score, ci = ppi_correct(judge, human_labels_n=300)
→ 0.81 ± 0.04 (95% CI)
Reported results: ARES's fine-tuned + PPI-calibrated judges ranked RAG systems more accurately than both RAGAS and a few-shot GPT-3.5 judge across 8 knowledge-intensive tasks (KILT, SuperGLUE, AIS-derived datasets) — on context relevance specifically, the paper reports outperforming RAGAS by a wide margin — while needing only a few hundred human labels, and the judges held up reasonably well even when the query/document distribution shifted from what they were fine-tuned on.
Trade-off vs. RAGAS: ARES is heavier-weight — it requires generating synthetic domain data, running a fine-tuning job, and collecting a small human-labeled validation set. RAGAS requires none of that. Reach for ARES when you need statistically defensible eval numbers (e.g., reporting to stakeholders, comparing two systems where the RAGAS score difference is small and you need to know if it's noise), and reach for RAGAS as the default when a good-enough point estimate wired into CI is sufficient.
Paper: Ru et al. (Amazon), RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation, NeurIPS 2024 Datasets & Benchmarks. arXiv:2408.08067 · GitHub
Problem it targets: RAGAS's faithfulness/relevance scores are per-response, not per-claim — a 0.5 faithfulness score doesn't tell you which half of the answer is the problem, or whether the retriever or the generator caused it.
Mechanism: decompose both the generated response and the ground-truth answer into atomic claims, then check each claim's entailment against the retrieved chunks. This claim-level decomposition is what makes the metrics fine-grained instead of a single blended score.
| Metric group | Metric | What It Isolates |
|---|---|---|
| Overall | Precision, Recall, F1 | Claim-level correctness and completeness of the final answer |
| Retriever | Claim Recall | Fraction of ground-truth claims actually present in the retrieved chunks — a retrieval failure, not a generation one |
| Retriever | Context Precision | Fraction of retrieved chunks that are actually relevant — quantifies retrieval noise |
| Generator | Faithfulness | Fraction of the answer's claims that are entailed by the retrieved context |
| Generator | Relevant / Irrelevant Noise Sensitivity | Whether the generator gets misled by irrelevant chunks mixed into relevant context |
| Generator | Hallucination | Claims in the answer not supported by any retrieved chunk and not attributable to context noise |
| Generator | Self-Knowledge | Claims correct but not attributable to the retrieved context at all (the model used parametric knowledge instead of the provided context) |
| Generator | Context Utilization | Fraction of relevant retrieved claims that actually made it into the final answer |
This is the same retriever-vs-generator split that shows up throughout this repo's failure modes section — RAGChecker operationalizes "is this a retrieval bug or a generation bug?" as a direct metric instead of something you have to manually inspect for.
Reported results: RAGChecker's claim-level metrics correlate with human judgment noticeably better than RAGAS's — the paper reports Pearson correlation on Overall metrics around 0.62 vs. RAGAS's best of roughly 0.48 (and similar gaps on Correctness/Completeness sub-metrics), with human annotator agreement around 91% on the underlying claim judgments.
When to reach for it: you already know that your RAG system has a quality problem (from RAGAS or production complaints) and need to know whether it's the retriever or the generator before deciding where to invest engineering time. RAGChecker is a diagnostic tool for that triage step, not a replacement for a lightweight CI regression gate — it's more expensive per-sample (multiple claim-decomposition and entailment-checking LLM calls per response) than RAGAS's four-metric pass.
Paper: Liu et al., Judge as A Judge: Improving the Evaluation of Retrieval-Augmented Generation through the Judge-Consistency of Large Language Models, ACL 2025 Findings. arXiv:2502.18817 · GitHub
Problem it targets: ARES fine-tunes a judge on synthetic labels; ConsJudge instead asks "can we train a better judge without needing an external ground-truth signal for what a 'correct' judgment looks like at all?"
Mechanism:
Standard judge training (ARES-style):
synthetic (query, context, answer, human/LLM label) → fine-tune
ConsJudge:
same (query, context, answer) → N judgments via different attribute
combinations → consistency across N judgments → (accepted, rejected)
preference pair → DPO
Reported results: ConsJudge-trained judges show high agreement with a larger, stronger "reference" LLM judge, and using ConsJudge's judgments as the reward/selection signal for downstream RAG optimization (e.g., picking the best of several candidate answers) improves results across multiple base models and datasets.
When this matters: ConsJudge is a judge-training technique, not something you call per-request in production — it's most relevant if you're building your own domain-specific judge model (the way ARES does) but want to avoid depending on either human labels or a stronger, more expensive LLM as the source of training signal.
Paper: Tamber, Bao, et al. (Vectara), Benchmarking LLM Faithfulness in RAG with Evolving Leaderboards, EMNLP 2025 Industry Track. arXiv:2505.04847 · GitHub
What it is — and isn't: FaithJudge is not a fine-tuned judge model like ARES or ConsJudge. It's an LLM-as-judge methodology built on few-shot prompting with a pool of human-annotated hallucination examples (combining the FaithBench and RagTruth datasets), used to judge a candidate model's outputs for faithfulness/hallucination. The "human-guided" framing is the point: rather than asking an LLM judge to decide from scratch what counts as a hallucination, it's shown real human-labeled hallucination examples as few-shot context first, which the paper reports gives stronger agreement with human judgment than zero-shot LLM judging. It extends Vectara's earlier HHEM-based Hallucination Leaderboard.
Scope: covers summarization, QA, and data-to-text generation tasks — broader than pure RAG, but directly applicable to RAG's faithfulness/groundedness question (see Vendor Naming: Groundedness & Context Relevancy for how this terminology maps across tools). Example leaderboard result: strong models like Gemini 2.5 Flash post hallucination rates in the single digits, while small open models can post hallucination rates an order of magnitude higher.
When to reach for it: as a reference leaderboard when choosing which LLM to use as your generator (or as your RAGAS/RAGChecker judge model) based on independently-measured hallucination propensity, rather than as something you'd run inline in your own CI pipeline.
| Framework | Fixes | Requires Training/Labels? | Output | Cost per Sample |
|---|---|---|---|---|
| RAGAS (baseline) | Nothing — the default | No | Faithfulness / Answer Relevance / Context Precision / Context Recall, per response | Low (4 LLM calls) |
| ARES | No confidence interval on judge scores | Yes — synthetic data + fine-tuning + ~300 human labels | Same 3 dimensions as RAGAS, with a calibrated confidence interval | Medium (one-time fine-tune, then cheap inference) |
| RAGChecker | Coarse, response-level diagnosis | No | Claim-level retriever vs. generator metrics (8 metrics) | High (multiple claim-decomposition + entailment calls per response) |
| ConsJudge | Judge quality without human labels or a stronger reference LLM | Yes — DPO training on consistency-derived preferences | A trained judge model, used like any other LLM judge | Medium (one-time training, then cheap inference) |
| FaithJudge | Judge-human misalignment on hallucination specifically | No (uses pre-existing human-annotated examples as few-shot context) | Faithfulness/hallucination score, leaderboard-style | Low-medium (few-shot judge call) |
| If... | Reach for |
|---|---|
| You want a no-labels baseline wired into CI (the repo's default path) | RAGAS (02-ragas-ci-harness.md) |
| You need statistically defensible scores with confidence intervals, and can invest in domain fine-tuning | ARES |
| RAGAS/production flagged a quality problem and you need to know if it's the retriever or the generator | RAGChecker |
| You're building your own judge model and want to avoid depending on human labels or a stronger reference LLM | ConsJudge |
| You're picking a generator (or judge) model and want an independent, human-aligned hallucination-rate comparison | FaithJudge leaderboard |