RAG quality is a data engineering problem, not a model problem

The most common AI engagement we see in the mid-market right now is a struggling internal knowledge assistant. The symptom is always the same: it answers confidently from stale or wrong documents. The diagnosis is almost never the model. It is the corpus.

Retrieval-augmented generation has a supply chain: documents are collected, cleaned, chunked, embedded, indexed, and retrieved. Every stage can silently degrade. SharePoint exports duplicate content. Chunking splits tables from their headers. Embeddings go stale when documents update but the index does not. None of this is visible in a demo built on twelve hand-picked PDFs.

The fix looks exactly like data engineering because it is data engineering. Treat the document corpus as a dataset with owners, freshness SLAs, and lineage. Deduplicate at ingestion. Chunk with structure awareness (headings, tables, code blocks) rather than fixed character counts. Re-embed on document change events, not on a quarterly cron.

Measurement closes the loop. A retrieval evaluation set (a few hundred real questions with known correct sources) turns arguments about quality into a metric. When retrieval precision is measured weekly, corpus rot gets caught the way schema drift gets caught in a warehouse: automatically, before users notice.

If your organization already runs dbt with tests and documentation, you have the muscle RAG needs. Point that muscle at your documents and the model suddenly looks a lot smarter.