Hook


Imagine you're asking a friend for directions to a restaurant, and they confidently tell you it's on Main Street. Then another friend—equally confident—tells you it's on Oak Avenue. Your first friend doesn't acknowledge the disagreement. They don't say "Wait, I think I heard it was somewhere else." They just double down and act like they were right all along.


That's what most RAG systems do when they encounter contradictory source documents.


They pull conflicting information from your knowledge base, mash it together, and generate an answer that sounds authoritative while potentially being incomplete or misleading. The system doesn't hallucinate facts from thin air—it hallucinates *confidence* about which contradictory source is actually right.


This is a real problem. Healthcare systems cite conflicting guidelines. Legal systems have outdated regulations that contradict newer ones. Policy databases have regional variations. Corporate knowledge bases have information that's been superseded but never fully removed.


But here's the thing: your RAG system doesn't have to choose. It can be honest about contradictions. And we're going to walk through exactly how to build that.


What You Will Learn


By the end of this post, you'll understand:


  • **Why standard RAG systems hallucinate when sources conflict** (it's not stupidity, it's architecture)
  • **The exact detection mechanisms** that catch contradictions before they become confident-sounding lies
  • **A step-by-step implementation approach** you can adapt to your own systems
  • **How to handle edge cases** like "sources that seem contradictory but aren't really"
  • **Practical patterns** for surfacing conflicts to users without breaking your system

    • This isn't theoretical. We're going to look at real code patterns, real problems, and real solutions you can implement this week.


    Simple Explanation (Analogy First)


    Think of a standard RAG system like a research intern who gets nervous around contradictions.


    You ask the intern: "When did Company X go public?" They retrieve five documents. Three say 2015. Two say 2016. Instead of saying "I found conflicting info," they get nervous. They think *you* want a confident answer, so they pick the majority and hand it to you with full certainty: "2015."


    Now imagine a better intern. Same five documents. Same conflict. But this intern says: "Three sources say 2015. Two sources say 2016. Here's who says what and why there might be a discrepancy—maybe one source is talking about IPO filing vs. trading start date."


    That's the difference. The first intern hallucinates confidence. The second handles reality.


    Building this better system means:


  • **Detecting** when sources actually contradict (not just say things differently)
  • **Tagging** each claim with exactly where it came from
  • **Routing** conflicted cases through a special pathway instead of forcing them through the normal LLM
  • **Presenting** the contradiction honestly to your user

    • That's it. Not complicated. Just different.


    How It Works


    Layer 1: Contradiction Detection (Before the LLM)


    This is where most people get it wrong. They throw all the retrieved documents at the LLM and hope it figures it out. Instead, you want to detect contradictions *before* you do generation.


    Here's the pattern:


    Step 1: Extract atomic claims from each document.


    Don't just throw paragraphs at the system. Parse them into discrete claims. "Company X went public in 2015" is a different claim than "Company X filed for IPO in 2014." Your detection system needs to work at this granularity.


    Step 2: Create a contradiction detection function.


    This doesn't need to be complex. You can use embedding similarity to find semantically opposite claims, or a smaller LLM to do pairwise comparison. The goal: identify which documents contradict each other.


    Something like:


    For each pair of retrieved documents:

    - Extract main claims

    - Check if they assert opposite things about the same fact

    - Flag as CONTRADICTORY if confidence > threshold

    - Store which specific claims conflict



    Step 3: Mark your retrieval results.


    Don't just return `[doc1, doc2, doc3]`. Return something like:


    [

    {doc: doc1, claims: [...], conflicts_with: [doc2]},

    {doc: doc2, claims: [...], conflicts_with: [doc1]},

    {doc: doc3, claims: [...], conflicts_with: []}

    ]



    Now your system *knows* there's a contradiction before the LLM ever sees it.


    Layer 2: Routing (Conditional Paths)


    Once you know there's a contradiction, you don't use the same pipeline as when everything agrees.


    If no contradictions exist: Use your standard RAG pipeline. Retrieve, synthesize, generate. Normal behavior.


    If contradictions exist: Switch to a conflict-aware pathway:


  • **Explicit sourcing mode**: Don't let the LLM synthesize freely. Force it to state claims with attribution. "Document A says X. Document B says Y."

  • **Confidence reduction mode**: The LLM generates answers but tags claims with confidence levels based on source agreement.

  • **User-facing transparency**: Actually tell the human that you found conflicting information and let them see both sides.

    • The key is: *different pathways for different situations*. Standard RAG for consensus. Conflict-aware RAG for contradictions.


    Layer 3: Prompt Engineering for Conflicts


    Your prompt needs to explicitly handle this case. Something like:



    You are analyzing source documents to answer a question.

    Some of these documents contain contradictory information.


    Your job:

  • Identify claims that appear in the sources
  • Note which sources agree and which disagree
  • Explain the contradiction honestly
  • Do NOT pick a side and pretend there's no conflict
  • Do NOT generate information beyond what's in the sources

    • If sources disagree about a core fact:

  • State each perspective clearly
  • Note which source says what
  • Suggest possible reasons for the discrepancy (e.g., timing, definition, scope)
  • Do not claim one is correct unless the sources themselves do


    • This prompt is doing the opposite of the standard approach. It's *rewarding* honesty about contradictions instead of punishing it.


    Layer 4: User-Facing Display


    Finally, you need to actually show the user what's happening.


    Instead of:


    "Company X went public in 2015."



    Show:


    "Sources disagree about this:

  • Sources A & B: Went public in 2015
  • Sources C & D: Went public in 2016
  • Possible reason: IPO filing vs. first trading day"


    • Users actually prefer this. It's honest. It explains uncertainty instead of hiding it.


    Real World Example


    Let's walk through a concrete example: a healthcare RAG system answering questions about medication dosing.


    The Scenario:


    User asks: "What's the correct dose of Drug X for condition Y?"


    Your retrieval system finds:

  • Document A (FDA guidelines from 2024): 10mg daily
  • Document B (European guidelines from 2024): 15mg daily
  • Document C (Recent clinical trial): 12mg showed best outcomes
  • Document D (Older hospital protocol): 20mg daily

    • What a standard RAG does:

    Picks one (usually the first), buries the others, generates: "The recommended dose is 10mg daily." Confident. Wrong. Dangerous.


    What our improved system does:


    Step 1 - Detection:

    The system extracts claims:

  • FDA: dose = 10mg
  • European: dose = 15mg
  • Trial: dose = 12mg
  • Hospital: dose = 20mg

    • It runs contradiction detection and finds: these are conflicting claims about the same fact.


    Step 2 - Routing:

    Because contradictions exist, it switches to conflict-aware mode.


    Step 3 - Generation:

    With the special prompt, the LLM generates:



    Dosing recommendations vary by region and recent evidence:


    OFFICIAL GUIDELINES:

  • FDA (2024): 10mg daily
  • European authorities (2024): 15mg daily
  • Difference: likely reflects different population data and risk tolerance

    • RECENT EVIDENCE:

  • 2024 Clinical trial: 12mg showed optimal efficacy
  • Hospital protocol (outdated): 20mg—no longer recommended

    • RECOMMENDATION:

    Consult prescribing information for your region. FDA dosing (10mg) is more conservative; European dosing (15mg) may be appropriate depending on patient factors.



    Step 4 - Display:

    The system shows the user this conflict explicitly, with sources cited, so they can make an informed decision.


    This is more helpful, more honest, and ironically more trustworthy than confidently picking one answer.


    Why It Matters in 2026


    Here's why this is becoming critical:


    1. RAG systems are everywhere now.


    Every company is deploying knowledge bases with LLMs on top. More systems means more conflicts waiting to be hallucinated away.


    2. Regulations are starting to care.


    In regulated industries (healthcare, finance, law), hallucinating confidence about conflicting sources is becoming a liability. Systems that admit uncertainty are actually safer.


    3. Users are getting smarter.


    People are starting to catch when AI systems BS them. Honesty about contradictions is becoming a competitive advantage, not a weakness.


    4. Real-world knowledge is messy.


    Federal vs. state laws. Old guidance vs. new. Different expert opinions. Contradictions aren't edge cases—they're normal. Your system needs to handle them.


    Common Misconceptions


    Misconception 1: "If we show conflicts, users will lose trust."


    Opposite is true. Users lose trust when you confidently give them incomplete or wrong answers. Admitting "sources disagree" and explaining why is *more* trustworthy.


    Misconception 2: "Detecting contradictions requires perfect semantic understanding."


    No. You don't need to perfectly understand everything. You can be conservative: only flag clear, high-confidence contradictions. Ambiguous cases can go through normal RAG. Better to miss some than false alarm constantly.


    Misconception 3: "This is too complex to implement."


    It's genuinely not. You need: (a) a function that compares document claims, (b) a conditional in your pipeline, (c) a different prompt. That's most of it. You can build this in a weekend.


    Misconception 4: "The LLM should figure out contradictions on its own."


    It should, but it often won't—especially if contradictory sources are far apart in the context window, or if the conflict is subtle. Building it explicitly gives you control and reliability.


    Misconception 5: "We need to resolve contradictions, not surface them."


    Sometimes, sure. But most often, *you can't*. Different regions have different rules. Different experts have different opinions. Different time periods have different facts. The honest move is to surface the contradiction and let the human decide.


    Key Takeaways


  • **Standard RAG systems hallucinate confidence when sources conflict.** They pick a side without admitting there's a conflict. This is a design problem, not an intelligence problem.

  • **Contradiction detection should happen before generation.** Parse documents into claims, compare them, flag contradictions *before* the LLM sees them.

  • **Use different pipelines for different situations.** Consensus cases use standard RAG. Conflict cases use conflict-aware RAG with explicit sourcing and reduced confidence.

  • **Honesty is a feature.** Users actually prefer "sources disagree" to confident answers that happen to be incomplete. Admitting uncertainty builds trust.

  • **Implementation is practical.** You need contradiction detection, conditional routing, a modified prompt, and transparent display. It's not simple, but it's achievable.

  • **Real-world knowledge is messy.** Contradictions aren't bugs to hide—they're features to surface. Your system should reflect reality, not smooth it over.

    • What To Do Next


    This week:


  • **Audit your current RAG system.** Take 20 queries and manually check: are any of the retrieved documents contradictory? Are you handling those cases well? Most systems fail this test.

  • **Build a simple contradiction detector.** Start with a function that takes two documents and uses embedding similarity or a small model to flag if they assert opposite things about the same fact. Don't overthink it.

  • **Test it on your actual data.** Run it on 100 queries from your knowledge base. How many times do contradictions actually appear? This tells you how much this matters for your use case.

    • Next month:


  • **Implement the routing layer.** When contradictions are detected, route to a conflict-aware prompt instead of your standard one. This is maybe 30 lines of conditional logic.

  • **Modify your prompt.** Write a version that explicitly handles conflicts. Test it with your detected contradiction cases. Does it surface the conflict honestly or do you need to iterate?

  • **Update your UI.** Show users when sources conflict. Let them see both sides. Measure if this increases trust (spoiler: it usually does).

  • **Document your conflicts.** Keep a log of contradiction cases. Are they real conflicts or false positives? Use this to tune your detector.

    • Start small. Pick one use case. Build it right. Then expand.


    Your RAG system can be honest. It's not hard. It's just a different approach than the standard "pick a source and sound confident" pipeline.


    Let me know what you find when you test this on your own systems.