If you've read one RAG tutorial, you've read them all. The standard recipe is everywhere: chunk documents, embed them, shove them in a vector store, and retrieve the top-k by cosine similarity. It works perfectly for a Wikipedia paragraph and fails the moment a real enterprise document hits it[reference:46]. This article, a manifesto for building enterprise RAG systems, argues for ten positions that break from this mainstream tutorial approach.
The Core Argument
The central thesis is that RAG is not machine learning; it's an engineering problem. Most failures aren't due to model weaknesses but identifiable broken components in your pipeline. The default tutorial focuses on optimizing the wrong things—like chunk sizes and model fine-tuning—while ignoring the architectural choices that truly matter for reliability, interpretability, and cost.
Ten Positions That Change Everything
The article lays out ten key positions, categorized into three layers. The first four take on the standard retrieval recipe directly: structure first, dictionaries before models (expert vocabularies beat generic embeddings for enterprise terms), rerankers as a tool not a default stage, and never using one vector store for everything. The next three set the enterprise frame: understanding that enterprise RAG is not open-domain QA, designing systems that amplify domain experts rather than bypass them, and using deterministic dispatchers over agentic freedom for inspectability. The final three cover the audit dimension: per-failure evaluation, relational structure between pipeline bricks, and citations as the primary explanation[reference:47].
Why Tutorials Fail
Mainstream tutorials fail because they copy the 'Google' playbook: optimizing for recall@100 on a ten-million-document index. This doesn't transfer to enterprise settings, which have a few hundred document types and a known set of questions. Tutorials also skip the hard parts of production: how to handle listing questions that break top-k retrieval, how to parse questions before searching, and how to build an audit trail.
A Roadmap for Enterprise RAG
The article concludes that the questions on the document you have, asked by the people who need answers, should drive every architectural choice. It maps out a comprehensive series of articles that argue these positions in detail, from parsing documents as relational data to building a corpus index with SQL. The result is a blueprint for building RAG systems that are not just demos but production-grade, trustworthy tools for the enterprise[reference:48].