This article is the manifesto of the Enterprise Document Intelligence series, which builds an enterprise RAG system from four core components. It presents ten positions where the series diverges from mainstream RAG tutorials, followed by a map of the series articles that support each argument. In 2026, as enterprises move beyond proof-of-concept RAG to production-grade systems, these distinctions are more relevant than ever.
The Problem with Mainstream RAG Tutorials
The standard RAG tutorial follows a predictable recipe: chunk the documents, push chunks into a vector store, embed the question, retrieve top-k by cosine similarity, optionally rerank, and send the hits to an LLM. Vendor decks, framework quickstarts, and conference talks all repeat this pattern. It works well on hello-world examples—a Wikipedia paragraph, a short PDF, a curated FAQ—but begins to fail when faced with real enterprise documents, which often have complex structures, mixed formats, and domain-specific terminology.
The Ten Positions
The positions are organized into three layers. The first four (positions 1–4) challenge the tutorial's retrieval recipe head-on: structure first, dictionaries before models, rerankers as a tool rather than a stage, and never one vector store for everything. The next three (positions 5–7) set the frame that the recipe ignores: what "enterprise" actually means, who the system amplifies, and who picks routes at runtime. The last three (positions 8–10) address the audit dimension: per-failure evaluation, relational structure between components, and citations as evidence.
1. Vector stores are a fallback, not a foundation
Most tutorials treat the vector store as the pipeline's entry point, routing everything through cosine similarity and relying on a reranker to fix its mistakes. This series inverts that: structure-first retrieval—using the document's declared table of contents, the corpus index, and expert keywords—handles the bulk of real questions on enterprise corpora. Embeddings come in as a safety net for residual cases (paraphrase, cross-lingual, internal acronyms), not as the default first stage.
The argument is not benchmark-driven; it's about interpretability. With keyword matching on a line_df (the per-line DataFrame produced by the parser, developed in Article 5) and filtering against the document's declared TOC, you can see exactly why a passage was retrieved: the matching terms, the section path, and the line range. With cosine similarity, you cannot—the vector says "these two ..." but offers no explanation of why.