Vibecoding
Build for the vibe, debug later
Start new thread

How are you handling AI hallucinations in document processing?

by•

Hey Product Hunt community! đź‘‹

We’ve all been through this pain: you feed a 50-page PDF, financial report, or contract into an LLM, ask for a quick summary, and it confidently hands you data that is completely made up.

If a creative writing bot hallucinates, it’s fine. But when it happens during document processing—like in your RAG pipelines or data extraction—it’s an absolute disaster.

Honestly, my team and I have been losing sleep over this exact problem. It’s why we are building Ethos by DocuShell (it's an open-source verifier for document citations, source evidence, and RAG). While building it, we realized just how easily LLMs get totally confused by simple tables or negative sentences (like missing a "not" or "except").

We have our own way of handling it, but we know there isn’t just one right answer. I really want to know how other builders and founders here are tackling this.

What kind of document hallucinations are driving you crazy the most?

  • Fake numbers: Making up metrics in financial statements?

  • Connecting wrong dots: Stitching two unrelated facts together to create a fake story?

  • Getting lost: Context drifting when dealing with huge, multi-page files?

And how are you guys fighting back? Are you fixing this at the infra level, playing around with prompts, or just relying on a human-in-the-loop to double-check everything?

For example, are you using:

  1. Advanced RAG: Better chunking, hybrid search, or re-ranking?

  2. Self-Correction: Making the LLM verify its own sources against a strict schema?

  3. UI Guardrails: Forcing the system to visually highlight exactly where the answer came from?

Drop your tech stack, your worst horror stories, or your current workarounds below.

59 views

Add a comment

Replies

Best

For document processing, I try not to trust the answer unless the source is visible next to it. Better chunking and re-ranking help, but the biggest improvement is usually forcing every claim to point back to the exact page, table, or sentence it came from. If the model can’t show the evidence, I’d rather have it say “not found” than give a confident summary.

 Exactly. That’s the part we care about too.

Showing the source next to the answer is a huge step, but we’ve also seen cases where the model points to the right page and still gets the meaning wrong. It may misread a table, miss a “not,” or stretch the evidence too far.

That’s why we’re building Ethos: first find the source, then check if the claim is actually supported by it. If it isn’t, the answer should say “not found” or “unsupported” instead of sounding confident.

We open-sourced it here if you want to take a look:

Curious, where do you see this most often: summaries, data extraction, or RAG Q&A?

 That second step is exactly the hard part. I see it most often in data extraction and RAG Q&A, especially around tables, dates, pricing, legal clauses, or anything with a small negative word like “not” or “unless.” Summaries can hide the mistake, but extraction/Q&A makes it much easier to spot when the model stretched the evidence too far. I’ll take a look at Ethos — the “supported vs unsupported” layer sounds really useful.

 thanks, this is very useful. I agree. Summaries can hide the mistake, but extraction and RAG Q&A make it very clear when the model has stretched the evidence.

Tables, dates, pricing, and legal clauses are exactly the cases we worry about too. One small word like “not” or “unless” can completely change the answer.

With Ethos, we are trying to make this second step stricter: don’t just show the source, also check whether the claim is actually supported by that source. If not, mark it as unsupported.

If you get a chance to try it, I’d really value your feedback. Even one anonymised failure case from your extraction/RAG flow would be very helpful.

For document processing, the worst hallucinations I’ve seen are usually in tables and mixed-context PDFs.

The model finds the right page, but then reads the wrong row, ignores a negative condition, or combines two nearby facts that should stay separate.

What has worked best for me is a stricter pipeline: extract first, validate against schema, require page/table evidence, then allow the LLM to summarize only from verified fields. For high-risk docs, human review is still necessary, but the system should at least flag “unsupported” instead of sounding confident.

 right. Tables and mixed-context PDFs are where things get messy fast.

The model can be on the right page and still read the wrong row, miss a “not,” or combine two facts that should never be joined.

I like the pipeline you described: extract first, validate against a schema, require page/table evidence, and only then let the LLM summarize from verified fields. That is very close to how we’re thinking about Ethos too.

The goal should not be “make the answer sound better.” It should be: if the evidence does not support it, mark it as unsupported.