The uncomfortable truth: Most "hallucination" complaints about RAG-based assistants are not hallucinations. They're the model accurately retrieving and summarizing dirty source data. Your product catalog has two conflicting prices for the same SKU. Your knowledge base has three versions of the same policy document, two of which are outdated. Your support bot is giving wrong answers because it's reading wrong source data — and doing it faithfully.
The fix is boring: clean your source data before ingestion.
How RAG Works (and Where Data Quality Breaks It)
RAG (Retrieval-Augmented Generation) pipelines work in two stages:
- Retrieval: User asks a question → system finds the most relevant documents/chunks from your knowledge base
- Generation: An LLM summarizes or answers using the retrieved context
Data quality problems corrupt Stage 1 (what gets retrieved) and Stage 2 (what the model reads). A better model doesn't fix bad source data — it just summarizes it more fluently.
Sohovi profiles your datasets for quality issues in minutes — see what's broken before it breaks your pipeline — try Sohovi free.
The 5 Data Quality Failure Patterns in RAG
Pattern 1: Duplicate Documents Skew Retrieval
What happens: Your product FAQ exists in 3 slightly different versions (the original, a "2024 update," and a "version for APAC"). All three are embedded. A question about that FAQ retrieves all three, and the model synthesizes an answer that blends all versions — which may contradict itself.
The wrong AI output:
"The return policy is 30 days. However, for most products, it's 14 days. For APAC customers, it's 30 business days."
The data fix: Deduplicate source documents before ingestion. Keep the canonical version; archive or delete superseded versions. If the APAC version genuinely differs, add metadata tagging so retrieval routes by region rather than mixing all versions.
Sohovi automatically finds every duplicate in your dataset — including near-matches — and shows you exactly which rows are affected.
Pattern 2: Two Conflicting Values for the Same Entity
What happens: Your product catalog has SKU-1234 listed at $299 in the pricing sheet, $279 in the marketing copy, and $319 in the reseller document. All three are embedded. The price question retrieves all three.
The wrong AI output:
"The price of SKU-1234 is $279."
Or worse:
"The price varies. It may be $279, $299, or $319 depending on the source."
The data fix: Establish a canonical source of truth for each data type (pricing lives in the pricing sheet; the catalog and marketing copy reference it, not define it). Deconflict before embedding. Flag records with conflicting values for human review.
Pattern 3: Stale Records Without Timestamps
What happens: You embedded your policy documents 18 months ago. The refund policy changed 6 months ago. The old policy document is still in your knowledge base, and since there's no timestamp metadata, retrieval returns both old and new versions with equal probability.
The wrong AI output:
"Our refund policy is 30 days from purchase."
(When the current policy is actually 14 days.)
The data fix: Every embedded document needs a last_updated timestamp as metadata. Retrieval should weight recency. Implement a document lifecycle process: when a policy changes, mark the old version as deprecated and reduce or remove it from the active retrieval index.
Pattern 4: Inconsistent Entity Names Split Context
What happens: Your knowledge base refers to the same product as "Sohovi Pro," "Sohovi Professional," "S-Pro," and "the pro plan." Embeddings for these phrases cluster separately. A question about "Sohovi Pro" may not retrieve documents that only mention "S-Pro."
The wrong AI output:
"I don't have information about 'Sohovi Professional.'"
(When you have 40 documents about it, under a different name.)
The data fix: Standardize entity names in source documents before embedding. Maintain a canonical name list and apply it consistently. Or add a synonym/alias metadata field to your document index so retrieval handles variants at query time.
Pattern 5: Junk and Placeholder Rows Retrieved as Facts
What happens: Your knowledge base was populated from a database export that included test records, template rows ("Enter product description here"), and rows created by QA automation ("Test product - do not ship"). These are embedded alongside real records.
The wrong AI output:
"We also offer 'Test product - do not ship' for $0."
The data fix: Profile and clean your source data before ingestion. Filter out rows matching test/placeholder patterns: zero-value prices, names containing "test" / "lorem ipsum" / "placeholder," records created before your system's launch date.
Pre-Ingestion Data Quality Checklist
Before embedding any dataset into a RAG pipeline, verify:
- [ ] No duplicate documents (same content under different file names or paths)
- [ ] No conflicting values for the same entity/attribute — if conflicts exist, resolve or tag them
- [ ] All documents have
last_updatedtimestamps and deprecated versions are removed - [ ] Entity names are standardized — no synonyms or abbreviations that would split retrieval
- [ ] No test, placeholder, or template rows
- [ ] Completeness check: key fields (product name, price, policy name) have no nulls
- [ ] Character encoding is consistent (no garbled Unicode characters)
- [ ] File types and structures are uniform (consistent column names in tabular sources)
Profile First, Then Embed
The same profiling you'd do on a customer database applies directly to RAG source data:
- Duplicate rate — what % of documents are near-identical?
- Null rate on key fields — what % of product records have no description?
- Conflicting values — how many entities have multiple different values for the same attribute?
- Age distribution — what % of documents haven't been updated in more than 12 months?
Upload your knowledge-base export to Sohovi before ingestion and see these metrics in one pass — the same profiler that works on CRM exports works on structured RAG source data.
Frequently Asked Questions
Q: Won't a better LLM handle noisy source data more intelligently? Better models produce more fluent outputs from bad data — they don't fix the underlying problem. A frontier model summarizing three conflicting prices produces a more polished-sounding response about the three prices; it doesn't pick the right one. The fix is always in the data, not the model.
Q: How often should I re-clean RAG source data? Every time the source changes. For static knowledge bases (a policy document set), run a full quality check when policies update. For dynamic sources (product catalog, pricing), consider a validation gate in your ingestion pipeline that runs automatically on each export before embedding.
Q: Is RAG-specific data quality different from general data quality? The principles are the same; the consequences are more visible. A dirty CRM produces bad reports that someone might notice eventually. A dirty RAG system produces embarrassing chatbot responses that users encounter immediately and vocally. The urgency is higher; the fix is the same boring process.
Q: What should I do if my RAG source data can't be cleaned (legacy system, no access)? Add metadata at ingestion time — timestamps, source labels, confidence scores — and implement retrieval logic that deprioritizes old or low-confidence sources. Prompt engineering can help (tell the model to express uncertainty when sources conflict). But these are workarounds; source data cleaning is the real fix.
Before you blame the model, profile your source data. Drag your knowledge-base export into Sohovi and see the duplicate rate, null rates, and conflicting values in one view — all in your browser, nothing uploaded.