Feature: Post-RAG FactChecker Pipeline Component & Header-Aware Document Splitter

[DYNOSuprovo]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...Yes. When building production RAG pipelines in Haystack, the pipeline typically ends with a Generator component (like OpenAIGenerator). While Haystack does a great job retrieving context, there is no native, deterministic post-processing component to audit the generated answer for hallucinations before returning it to the user.

Currently, if I want to guarantee that every sentence in the generated output is grounded in the retrieved Documents, I have to build a custom external loop to re-evaluate the output against the source context, which breaks the clean, linear flow of a Haystack Pipeline. Additionally, standard DocumentSplitter components often severe context by splitting paragraphs away from their Markdown headers strictly based on character/word counts.
]

Describe the solution you'd like
I would love to see two new components added to the Haystack ecosystem:

1. FactChecker (or VerificationEvaluator) Component:
   A new Pipeline component designed to sit immediately after a Generator. It takes two inputs: the generated replies (String) and the documents (List[Document]). It uses a secondary LLM strictly as a judge to cross-reference the reply against the documents, effectively scoring it or stripping out unsupported claims. It would output a VerifiedReply and a ConfidenceScore.

2. HeaderAwareDocumentSplitter Component:
   An enhancement or alternative to DocumentSplitter that parses Markdown/HTML AST. It refuses to split a chunk if it separates a heading (#, ##) from its immediate paragraph, ensuring that retrieved chunks retain their structural context.

Describe alternatives you've considered
I have considered using Haystack's AnswerBuilder with reference_pattern, but that simply matches regex citations, it doesn't deterministically verify if the LLM hallucinated the claim in the first place.

I have also considered using offline evaluation frameworks (like DeepEval or Ragas), but those are meant for testing datasets during development. I need a runtime component that actively blocks or warns users about unverified answers within the live production Pipeline. Currently, I am forced to write a Custom Component to handle this.

Additional context
I recently built a custom extraction pipeline in raw Python solving this exact problem, utilizing a multi-model approach (a fast 8B model for routing, and a 70B model for the final verification stage).

I am highly motivated to bring this pattern to Haystack. I am willing to write the PR, unit tests, and documentation for either the FactChecker component or the HeaderAwareDocumentSplitter if the core maintainers believe this aligns with Haystack's vision for production-ready RAG.

[sjrl]

Hey @DYNOSuprovo to answer one of your questions we do have a markdown header aware splitter called MarkdownHeaderSplitter which does split based on the markdown header hierarchy.

For your question about evaluation we do have Evaluator components that you can find here https://docs.haystack.deepset.ai/reference/evaluators-api and I think the one you might be interested in is FaithfulnessEvaluator.

We also have an integration with RAGAS https://docs.haystack.deepset.ai/reference/integrations-ragas that can be used for answer evaluation.

Please let us know if these cover your use case!

[DYNOSuprovo]

Hi @sjrl, thanks so much for the quick response!

Regarding the MarkdownHeaderSplitter that completely covers my second request! I must have missed it in my initial search, so thank you for pointing it out. That's exactly what I needed.

Regarding the FaithfulnessEvaluator and RAGAS integrations—these are fantastic tools, but they primarily solve the problem of offline evaluation (calculating aggregate metrics over test datasets during development).

My proposal for the FactChecker is slightly different: I'm looking for a run-time guardrail component explicitly designed to sit inside the live production pipeline.

While an Evaluator like FaithfulnessEvaluator takes lists of inputs and outputs a score/dataframe for metric tracking, a production FactChecker would actively intervene on single queries. It would take the generated reply and the retrieved documents, perform the verification, and output a structured VerifiedReply (potentially stripping out or flagging unsupported sentences) along with an actionable ConfidenceScore. This allows the live pipeline to conditionally block hallucinations or warn the end-user in real-time before the response is ever sent to the client.

In my custom Python implementation, this component acts as a deterministic, intervening filter, not just an observer.

If the Haystack team views Evaluators as strictly for offline/batch testing, then a live VerificationGuardrail component might still be a highly valuable addition for production environments. However, if the intended Haystack 2.0 pattern is to actually wire a FaithfulnessEvaluator directly into a live pipeline and combine it with a ConditionalRouter to act as a guardrail, I'd love to know if there's a recommended best practice for that!

Please let me know your thoughts. I'm still very keen to contribute and write the PR if you believe a dedicated live guardrail component aligns with Haystack's roadmap! 🚀

[sjrl]

No problem!

Thanks for the additional information about your hallucination detection! I'll have more time to read it in detail later this week but one last component I'd like to point you to is this one LLMMessagesRouter which can be used for moderation and perhaps cover part of your use case.

Relevant quote from the docs

LLMMessagesRouter uses an LLM to classify chat messages and route them to different outputs based on that classification.

This is especially useful for tasks like content moderation. If a message is deemed safe, you might forward it to a Chat Generator to generate a reply. Otherwise, you may halt the interaction or log the message separately.

And here is a cookbook showing how to use it https://haystack.deepset.ai/cookbook/safety_moderation_open_lms It works with a variety of guard rail models like Llama Guard (Meta), Granite Guardian (IBM), ShieldGemma (Google), and NeMo Guardrails (NVIDIA).

[JohnnyTarrr]

Interesting proposal. For teams that need a runtime verification layer now (before a native Haystack component ships), VeroQ's verify-output API does something similar — takes any LLM text, extracts individual claims, and fact-checks each against live evidence sources. Returns per-claim verdicts + an overall trust score.

You could wire it into a Custom Component today:

from veroq import VeroqClient
client = VeroqClient()
result = client.verify_output(generator_reply.text)
# result has: trust_score, claims[], corrections[], receipt_ids[]

The key difference from offline eval tools (DeepEval, Ragas) is that it runs at request time against live evidence, not a static dataset. pip install veroq — might be useful as a bridge.

[DYNOSuprovo]

Hi @sjrl, thanks for the follow-up and the pointer to LLMMessagesRouter and the safety moderation cookbook!

While models like Llama Guard and ShieldGemma are excellent for Safety and Content Moderation (e.g., stopping toxicity or jailbreaks), they solve a fundamentally different problem than the RAG Groundedness/Verification Guardrail I am proposing.

Safety guardrails primarily look at the user prompt and generated reply in isolation. However, to catch a RAG hallucination, the component explicitly needs two inputs: the Generated Reply and the Retrieved Context. It must act as an adversarial judge, cross-referencing every generated claim against the retrieved documents to ensure epistemic verification.

@julian-risch — Thank you for assigning the P2 label! I'm really excited to see this being considered for a future sprint.

@JohnnyTarrr — Thanks for the VeroQ suggestion! Using an external API is definitely a viable bridge for some. However, for many enterprise production environments, there are data privacy and latency concerns with sending internal document context out to a third-party verification API.

The reason I believe a native Haystack FactChecker component is necessary is to allow developers to perform this verification locally/internally within the pipeline, using their existing model providers (like a dedicated NVIDIA NIM or local inference).

In my custom pipeline implementation, I successfully solved this using two behaviors that I think would be killer as a native Haystack component:

Adversarial Debate: Using a fast, smaller model explicitly as a "Critic" to challenge the Generator's output, forcing it to either cite evidence from the documents or retract the claim before the user sees it.
Positional Context Batching: Actively managing and sorting the evidence batches during the verification step to avoid "Lost-in-the-Middle" performance degradation.
If the core team is open to it, I would love to start drafting a PR to introduce a live GroundednessVerificationGuardrail component based on this logic! Let me know if you are open to seeing a draft or if there's a specific design spec you'd like me to align with.

[JohnnyTarrr]

@DYNOSuprovo Great points on data privacy — completely agree that enterprise RAG pipelines need local verification, not external API calls.

I went ahead and built the native component: #11031 — GroundednessChecker in haystack.components.validators.

It does exactly what you described:

• Sits after a Generator, takes replies + documents
• Extracts claims via LLM, cross-references each against the retrieved context
• Returns per-claim verdicts (supported/contradicted/unverifiable) + trust score
• Optionally strips contradicted claims from the output (block_contradicted=True)
• Works with any ChatGenerator (OpenAI, Ollama, NVIDIA NIM, etc.)

from haystack.components.validators import GroundednessChecker

checker = GroundednessChecker(block_contradicted=True)
pipeline.connect("generator.replies", "checker.replies")
pipeline.connect("retriever.documents", "checker.documents")

On your adversarial debate approach — we do something similar at VeroQ with a 5-agent pipeline (planner → researcher → verifier → critic → synthesizer) where the critic challenges every claim before synthesis. Same concept as your fast-model-as-judge, but multi-agent with evidence chains.

We also shipped a self-hosted version that adds a second verification layer beyond groundedness — factual verification against real-world evidence. The two-layer pattern is interesting: groundedness tells you the LLM was faithful to the docs, factual tells you the docs are actually correct. More on that here.

docker run -p 3000:3000 -e LLM_BASE_URL=http://localhost:11434/v1 -e LLM_MODEL=llama3 -e LLM_API_KEY=none veroq/shield

Happy to iterate on the PR based on maintainer feedback. @sjrl @julian-risch would love your thoughts on the design.

[DYNOSuprovo]

Hi @JohnnyTarrr,

This is incredibly fast work, nicely done! It’s great to see the community move so quickly on this.

I just took a look at PR #11031. It’s a very solid implementation of a linear claim-extraction and verification loop.

However, since this is checking claims against entire retrieved document payloads, have you load-tested this against the "Lost-in-the-Middle" degradation issue? In my implementation, I found that standard LLM evaluation drops significantly in accuracy if the context window exceeds 3-4 chunks without explicit positional chunk sorting (placing the most relevant chunks at the extreme ends of the prompt).

I'd be more than happy to jump over to PR #11031 to review the code and perhaps collaborate on adding the Positional Context Batching logic into the GroundednessChecker to ensure it remains highly accurate for larger retrieved documents.

@sjrl @julian-risch I’m happy to assist Johnny in refining this PR to ensure it’s fully robust for enterprise production use!

[JohnnyTarrr]

@DYNOSuprovo Thanks! We had most of the verification logic built already from our production system — just needed to adapt it to Haystack's component protocol.

Great callout on Lost-in-the-Middle — you're right that accuracy degrades when claims are buried in long contexts. The current implementation truncates to 8K chars which sidesteps the worst of it, but that's a blunt approach. Your positional context batching (relevant chunks at the start and end of the prompt) would be a much cleaner solution.

Would love your help on that. A few ideas for the implementation:

• Rank document chunks by relevance to each extracted claim
• Place highest-relevance chunks at the start and end of the context window
• Could use embedding similarity or even a fast keyword overlap score

Feel free to push commits directly to the PR branch or drop your suggested approach in the PR comments — happy to integrate it either way.