Why do RAG systems need separate groundedness and faithfulness thresholds?

Why This Matters for Security Teams

rag evaluation is not just a model-quality exercise. In security, the distinction between groundedness and faithfulness affects whether an AI system merely cites retrieved content or actually preserves its meaning when answering a question. That difference matters for policy interpretation, incident triage, control recommendations, and user-facing security advice. If a system is grounded but not faithful, it can sound authoritative while subtly changing the risk posture.

This is why a single threshold is too blunt for operational use. Groundedness can catch answers that wander outside the retrieved corpus, while faithfulness helps detect answers that selectively compress, reorder, or overstate what the source material says. The right tolerance depends on the use case, the impact of a wrong answer, and whether the model is supporting analysis or making decisions. Current guidance suggests treating both metrics as complementary guardrails rather than interchangeable scores. For broader control context, NIST Cybersecurity Framework 2.0 remains a useful reference for aligning AI output checks with governance, detection, and response expectations.

In practice, many teams discover the gap only after an apparently well-sourced answer has already been used to justify a bad security decision, rather than through intentional evaluation design.

How It Works in Practice

Separate thresholds let teams tune evaluation to the specific failure they are trying to prevent. Groundedness usually measures whether claims can be traced to retrieved passages, so it is sensitive to unsupported additions and retrieval misses. Faithfulness checks whether the generated answer respects the evidence, even when the answer stays within the retrieved material. A response can be grounded in the sense that it references the right document, yet still be unfaithful if it overgeneralizes, omits a critical qualifier, or reverses the source’s meaning.

Operationally, teams often implement both checks in a pipeline with human review for low-confidence cases. That usually means:

• Measuring groundedness on retrieved snippets before output release.
• Scoring faithfulness against source passages to catch misrepresentation.
• Applying stricter thresholds for high-impact workflows such as security operations, legal, or customer-facing advice.
• Logging the retrieved context, prompt, and answer so failures can be reproduced and tuned.

Where this intersects with AI governance, the relevant question is not whether the model was “mostly right,” but whether the answer can be defended against the source material and the intended use. That maps well to the NIST AI Risk Management Framework, which encourages measurement, monitoring, and risk-based controls rather than one-size-fits-all scoring. For retrieval-heavy systems, the OWASP Top 10 for Large Language Model Applications is also useful for thinking about prompt injection, source manipulation, and output validation.

These controls tend to break down when the retrieval set is noisy, the source documents conflict, or the answer requires synthesis across multiple passages because scoring becomes sensitive to context selection rather than just model behaviour.

Common Variations and Edge Cases

Tighter thresholds often increase review overhead and reduce answer coverage, requiring organisations to balance user experience against assurance. That tradeoff is real in production RAG systems, especially where retrieval quality varies across document types or where users expect concise answers from incomplete evidence.

Best practice is evolving around how strict each threshold should be. Some teams set a higher bar for faithfulness than groundedness because misrepresenting evidence is often more dangerous than failing to answer. Others do the opposite in research or exploration workflows, where partial grounding may be acceptable but unsupported assertions are not. There is no universal standard for this yet, so thresholds should be tied to business impact, not abstract model scores.

Edge cases include summarisation tasks, multi-hop reasoning, and cases where the retrieved corpus itself is stale or internally inconsistent. In those environments, a model may be faithful to one source while still being operationally wrong because the evidence set is incomplete. The MITRE ATLAS framework is helpful where adversaries may manipulate retrieval content or prompts to push the model toward confident but misleading outputs. For AI systems operating under regulatory scrutiny, the EU AI Act reinforces the need for documented controls, testing, and traceability around high-impact AI behaviour.

In practice, the right answer is rarely “one threshold for both.” It is usually separate thresholds, different escalation paths, and explicit acceptance criteria for each workflow.

Related resources from NHI Mgmt Group

• How should security teams govern access in RAG systems?
• Why do RAG deployments create more data exposure risk than standard chat systems?
• What breaks when access revocation is handled in separate systems?
• What should organisations do when RAG systems can reach sensitive data?