PaperlayerView exact revision on arXiv

Source-linked AI summary

RAGScope: A Leakage-Controlled, Cost-Aware Evidence-Gating Protocol for RAG Hallucination Triage

Zeming Liu, Qibai Chen, Jingtao Zhang, Hang Lyu

arXiv:2609.39075v1cs.CRcs.AI

TL;DR

RAG systems need a way to route outputs between local acceptance and costly review, while leakage can make cheap gates appear more general than they are. RAGScope evaluates local gates with leakage controls and deployment-oriented reporting; results show useful pooled RAGTruth gains but a sharp source-transfer boundary for calibration.

  • Problem

    RAG systems need selective routing because reviewing every answer with a large verifier or human is expensive, while accepting every answer can let unsupported content pass.

    Source: §I · p. 1

  • Method

    RAGScope evaluates local evidence gates using context-grouped splits, fold-scoped preprocessing, group bootstrap intervals, deployment operating points, runtime accounting, and source-shift checks.

    Source: §I · p. 1, B. Baselines and Metrics · p. 3

  • Results

    RAGScope-E reaches pooled AP 0.660 on RAGTruth, but calibrated cross-source performance averages only 0.466 AUROC on HaluBench.

    Source: A. RQ1–RQ2: RAGTruth Triage · p. 4, D. RQ5: Source Shift and Target… · p. 5

  • Takeaways & Limitations

    Cheap evidence gates are viable first-stage routers when evaluation reports task-specific operating points, runtime, uncertainty, and target-domain transfer rather than only pooled scores.

    Source: §VII · p. 7

    The study measures source adaptation on public benchmarks, not temporal drift or production generalization.

    Source: B. Limitations · p. 7

Abstract

from arXiv · show

Retrieval-augmented generation (RAG) systems need inexpensive ways to route generated answers: accept low-risk outputs, review uncertain ones, and reserve strong verifiers for the expensive tail. We present RAGScope, a leakage-controlled protocol for evaluating local evidence gates that use only the task input, retrieved context, and answer text. The protocol combines context-grouped splits, fold-scoped preprocessing, group bootstrap intervals, deployment operating points, end-to-end runtime, and explicit source-shift stress tests. On three RAGTruth tasks, the enhanced gate RAGScope-E reaches 0.798 AUROC and 0.660 average precision (AP) in pooled grouped cross-validation. Its pooled AP exceeds ROUGE-L by 0.034 with a 95% context-group interval of [0.002, 0.064], although the AUROC gain is not significant and ROUGE-L remains stronger on data-to-text. At a top-10% review budget, RAGScope-E attains 0.748 precision; accepting the lowest-risk 50% yields 0.141 residual unfaithfulness. RAGScope-E runs in 6.22 ms/example on CPU, versus 145.75 and 223.07 ms/example for the tested DeBERTa-NLI and HHEM settings. A 14,900-example HaluBench stress test exposes the deployment boundary: an in-domain calibrated gate reaches 0.879 AUROC, but leave-source-out calibration averages only 0.466. Target-only calibration recovers to 0.675 AUROC with 100 labels per source and 0.685 with 200. Cheap evidence gates are therefore useful routing components, but learned calibration must be validated and adapted within the target domain.

I. INTRODUCTION

RAGScope frames RAG triage as routing answers between local acceptance and costly review, while treating leakage control and deployment conditions as part of evaluation. It evaluates lightweight gates, verifier baselines, and source-shift behavior, with gains that are useful but not universal.

I. INTRODUCTION

  • Routing is selective: accept outputs judged safe locally and escalate uncertain ones, avoiding the expense of reviewing every answer or silently accepting unsupported content.Large verifiers and human review can make evaluation expensive and slow.Source: §I · p. 1
  • RAGScope combines context-grouped splits, fold-scoped TF-IDF preprocessing, group bootstrap intervals, deployment operating points, and source-shift checks to evaluate lightweight evidence gates.The protocol is designed to keep claims useful under grouped examples, task heterogeneity, and realistic deployment operating points.Source: §I · p. 1
  • RAGScope-E improves pooled AP and QA triage, but does not dominate ROUGE-L on every RAGTruth task.The contribution describes pooled AP as the strongest supported gain and identifies data-to-text as a counterexample.Source: §I · p. 1
  • Local DeBERTa-NLI and HHEM verifier baselines are compared with RAGScope-E on accuracy and CPU runtime to expose cost and task-level deployment boundaries.The comparison also addresses verifier mismatch.Source: §I · p. 1
  • Across six HaluBench sources, cross-source transfer can fail sharply, while target-only calibration with small labeled samples restores useful ranking performance.This stress test marks a deployment boundary for learned calibration.Source: §I · p. 1

II. EVIDENCE-GATING PROTOCOL

RAGScope treats a local gate as a risk-scoring router, not a final factuality judge. Its protocol pairs grouped evaluation and fold-scoped feature construction with operating-point metrics that expose deployment trade-offs.

II. EVIDENCE-GATING PROTOCOL

  • A gate scores task input, retrieved context, and candidate answer for unfaithfulness risk; high-risk outputs can be reviewed or verified, while low-risk outputs are accepted only at a chosen tolerance.The gate changes which examples consume expensive verification budget rather than making the final factuality decision alone.Source: §II · p. 1
  • Fig. 1 summarizes controls including fold-scoped feature construction, context-grouped evaluation, group uncertainty intervals, fixed review/accept operating points, and runtime accounting.Together, these controls define the evaluation protocol for local evidence signals as a first-stage router.Source: Figure 1 · p. 2

A. Routing Metrics

  • Review precision measures how concentrated the flagged queue is, while accepted risk measures unfaithfulness among the lowest-risk examples accepted automatically.At review budget ρ the highest-risk examples are reviewed; at acceptance budget α the lowest-risk examples are accepted.Source: A. Routing Metrics · p. 2
  • These operating-point quantities complement AUROC and AP by exposing threshold behavior that deployment teams must choose before using a gate.A strong pooled AUROC may not enrich the reviewed queue, and good review precision may coexist with unsafe residual accepted risk.Source: A. Routing Metrics · p. 2, §II · p. 2

B. Lightweight Evidence Features

RAGScope-Z uses monotone evidence-missing signals, beginning with uncovered answer-token fraction. The base feature family adds lexical, length, support, and numeric features, while RAGScope-C applies logistic regression to those features.

B. Lightweight Evidence Features

  • RAGScope-Z scores the fraction of non-stopword answer tokens absent from the context as its simplest evidence-missing baseline.Tokens are lowercased alphanumeric spans; sentence boundaries use punctuation and line breaks, and numeric matching strips commas.Source: B. Lightweight Evidence Features · p. 2
  • The base feature family adds answer and context lengths, coverage and overlap measures, supported-run and sentence-support measures, and numeric coverage and count.Source: B. Lightweight Evidence Features · p. 2
  • RAGScope-C trains a logistic regression model over the base features for settings with local labels and a fixed operating policy.The model uses standardization, balanced class weights, and L2 regularization.Source: B. Lightweight Evidence Features · p. 2

C. Enhanced Local Gate

RAGScope-E adds four local support features to the base feature family, with data-dependent TF-IDF preprocessing fitted within training folds. The protocol also specifies grouped evaluation, deployment operating points, runtime measurement, and source-shift checks.

C. Enhanced Local Gate

  • RAGScope-E adds ROUGE-L, token-F1, TF-IDF, and maximum sentence-level TF-IDF risk features without remote services, LLMs, or NLI models.Its TF-IDF vocabulary and IDF weights are fitted on each training fold and applied to held-out examples.Source: C. Enhanced Local Gate · p. 2

D. Protocol Requirements

  • The protocol pairs grouped evaluation and group-bootstrap intervals with preset review or acceptance workloads, complete CPU runtime, and source-holdout calibration checks.Review points span the top-risk 5–30%, while acceptance points span the lowest-risk 50–90%.Source: D. Protocol Requirements · pp. 2–3, Table I · p. 3

III. EXPERIMENTAL DESIGN

The experiments ask how local evidence signals perform under grouped RAGTruth evaluation, at deployment operating points, against local verifiers, and under source shift. They use RAGTruth task outputs and a deliberately difficult HaluBench transfer test.

III. EXPERIMENTAL DESIGN

  • The experimental design tests cheap local triage, RAGScope-E’s gains and failures, deployment operating points, verifier comparisons, and calibration under source shift.Source: §III · p. 3

A. Datasets

  • RAGTruth evaluation covers QA, summarization, and data-to-text, with 900 processed public test examples per task and 2,700 total.Positive labels denote unfaithful or hallucinated outputs; faithfulness labels derive from annotated hallucination spans.Source: A. Datasets · p. 3
  • HaluBench supplies 14,900 examples from six source datasets for in-domain, leave-source-out, and target-label recovery evaluations.Target adaptation samples 25, 50, 100, or 200 labels per source, using a fixed stratified target test set and ten seeds.Source: A. Datasets · p. 3

B. Baselines and Metrics

The study compares cheap local signals and learned gates with two local CPU verifier baselines, reporting ranking metrics, group-bootstrap uncertainty, operating points, and runtime. Learned RAGTruth results use out-of-fold scores, while HaluBench tests source-level transfer and target adaptation.

B. Baselines and Metrics

  • Baselines range from lexical and TF-IDF risks to learned gates and local DeBERTa-v3-small NLI and Vectara HHEM verifiers.DeBERTa uses three lexically selected context sentences; the fuller HHEM setting uses complete context truncated to 512 tokens.Source: B. Baselines and Metrics · p. 3
  • Reported metrics include AUROC, AP, context-group bootstrap intervals, paired deltas, operating points, and complete local CPU runtime per example.AP is emphasized because positive rates vary across tasks, from 0.178 for QA to 0.643 for data-to-text.Source: B. Baselines and Metrics · p. 3
  • Every learned RAGTruth score is out-of-fold, and HaluBench leave-source-out intervals resample within source while adaptation results average across six sources.HaluBench adaptation standard errors use ten repeated stratified target splits.Source: B. Baselines and Metrics · p. 3, Table II · p. 3

A. RQ1–RQ2: RAGTruth Triage

RAGScope-E improves pooled average precision and performs strongly on QA, but it does not dominate ROUGE-L across tasks. The evidence supports shared-queue triage, not a task-universal detector.

A. RQ1–RQ2: RAGTruth Triage

B. RQ3: Operating Points

Operating-point results show that review and acceptance policies should reflect workload and task. Local verifier comparisons also favor a cheap routing gate before stronger checks on the expensive tail.

B. RQ3: Operating Points

  • At the top-10% review point, RAGScope-E's combined precision edge over ROUGE-L is small with overlapping intervals; QA favors RAGScope-E, while data-to-text favors ROUGE-L.Review precision remains above the 0.349 base rate for all three cheap scores.Source: Table VI · p. 5, B. RQ3: Operating Points · p. 5
  • As more examples are accepted automatically, residual unfaithfulness rises; when task identity is known, thresholds should be selected per task.The best cheap baseline differs by task, especially between QA and data-to-text.Source: Table VI · p. 5, B. RQ3: Operating Points · p. 5

C. RQ4: Cost Versus Local Verifiers

  • HHEM with full context truncated to 512 tokens reaches 0.655 [0.625, 0.687] AUROC and 0.420 [0.388, 0.457] AP, below RAGScope-E on the combined set.The tested local verifier settings are slower and less accurate on RAGTruth.Source: Table VII · p. 5, C. RQ4: Cost Versus Local Verifiers · p. 5
  • DeBERTa receives the top three lexically selected context sentences, whereas HHEM gets fuller context truncated to 512 tokens; RAGScope-E can screen candidates before verifier use.The evidence-selection policy should be reported with the model because the settings differ in context coverage and runtime.Source: C. RQ4: Cost Versus Local Verifiers · p. 5

D. RQ5: Source Shift and Target Adaptation

Learned calibration transfers poorly across HaluBench sources, but target-only labels recover ranking performance. Deployment guidance therefore pairs budgeted routing with target-scoped validation and source-shift checks.

A. Deployment Guidance

  • Choose a budgeted review or acceptance policy, validate it on grouped examples with deployment-matched preprocessing, and select per-task thresholds when task identity is available.A learned gate calibrated on another source should remain disabled until a target-labeled audit supports transfer of its ranking and operating points.Source: A. Deployment Guidance · pp. 5–6

D. RQ5: Source Shift and Target Adaptation

  • HaluBench calibration reaches 0.879 AUROC in-domain but averages only 0.466 AUROC under leave-source-out evaluation.Cross-source calibration also averages 0.460 AP, below the zero-shot macro values of 0.644 AUROC and 0.552 AP.Source: D. RQ5: Source Shift and Target… · p. 5, Table VIII · p. 6
  • Target-only calibration reaches 0.665 AUROC with 50 labels per source and 0.685 AUROC with 200 labels per source.At 200 labels per source, AP reaches 0.649; the operational rule is target-scoped fitting, grouped validation, and threshold selection.Source: D. RQ5: Source Shift and Target… · p. 5, Table VIII · p. 6

A. Deployment Guidance

  • Run the gate across answers, route high-risk outputs to stronger checks, and periodically audit accepted outputs; report workload, residual risk, group intervals, runtime, and source-shift results.The protocol is designed to remain compatible with downstream verifiers or human review.Source: A. Deployment Guidance · p. 6

B. Limitations

RAGScope is shallow and queue-sensitive, while its verifier comparison and benchmark setup constrain how broadly the results can be generalized. The reported evaluations do not establish temporal or production generalization.

B. Limitations

  • RAGScope cannot prove factuality, handle multi-hop reasoning, or detect contradictions that reuse evidence tokens.Source: B. Limitations · p. 6
  • Pooled metrics can shift with task base rates, so combined results need per-task reporting to expose weak gates.Source: B. Limitations · p. 6
  • The verifier comparison uses local CPU inference, top-three lexical evidence for DeBERTa-NLI, and truncated full-context HHEM, leaving stronger production setups untested.Source: B. Limitations · p. 7
  • RAGTruth uses public benchmark splits with grouped cross-validation, while HaluBench adaptation samples labels from the evaluated source; neither tests temporal or production generalization.Source: B. Limitations · p. 7

VI. RELATED WORK

RAGScope frames low-cost RAG routing as complementary to verifier-based evaluation and makes grouped validation, operating points, cost, and source transfer part of the claim. Its conclusion treats cheap gates as first-stage routers whose evaluation must report task-specific behavior and target-domain transfer.

VI. RELATED WORK

  • RAGScope differs from broader RAG evaluation by centering low-cost routing and jointly requiring grouped validation, operating points, cost, and source transfer.Source: §VI · p. 7
  • RAGScope complements NLI,, sampling, FActScore, and LLM judges [5] with a millisecond-scale signal before stronger judges.Source: §VI · p. 7
  • Its operating points adapt selective classification [14] to RAG by reviewing high-risk answers or accepting only low-risk ones.Source: §VI · p. 7

VII. CONCLUSION

  • Under grouped RAGTruth evaluation, RAGScope-E improves pooled AP and QA triage but not every task; HaluBench shows source transfer can sharply weaken calibration.Source: §VII · p. 7
  • Cheap evidence gates are viable first-stage routers only when evaluation reports task-specific operating points, runtime, uncertainty, and target-domain transfer.Source: §VII · p. 7

Related papers

Loading 2609.39075v1…