{
  "source_file": "0930",
  "source_platform": "Medium",
  "author": "Angela Shi & Kezhan Shi",
  "title_listed": "Enterprise Document Intelligence: A Series on Building RAG Brick by Brick, from Minimal to Corpus scale",
  "keywords": "",
  "domain": "大模型算法",
  "content_type": "深度技术解析",
  "is_paid_flag": "否",
  "url": "https://towardsdatascience.com/document-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale/",
  "publish_date": "2026-05-22",
  "corpus_stage": "",
  "notes": "",
  "id": "b5c9287f2048",
  "collected_at": "2026-10-02T01:31:11",
  "title": "Enterprise Document Intelligence: A Series on Building RAG Brick by Brick, from Minimal to Corpus scale | Towards Data Science",
  "body_markdown": "![Revisit consent button](../images/body-df29beacd7496220cc94.svg)\nWe value your privacy\nWe use cookies to enhance your browsing experience, serve personalised ads or content, and analyse our traffic. By clicking \"Accept All\", you consent to our use of cookies.\nCustomise Reject All Accept All\nCustomise Consent Preferences ![](../images/body-2159bb67f3de8ad870eb.svg)\nWe use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.\nThe cookies that are categorised as \"Necessary\" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... Show more\nNecessaryAlways Active\nNecessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.\n  * Cookie\nBCTempID\n  * Duration\n10 minutes\n  * Description\nNo description available.\n\n\n  * Cookie\n__cf_bm\n  * Duration\n1 hour\n  * Description\nThis cookie, set by Cloudflare, is used to support Cloudflare Bot Management. \n\n\n  * Cookie\nAWSALBCORS\n  * Duration\n7 days\n  * Description\nAmazon Web Services set this cookie for load balancing.\n\n\n  * Cookie\n_cfuvid\n  * Duration\nsession\n  * Description\nCloudflare sets this cookie to track users across sessions to optimize user experience by maintaining session consistency and providing personalized services\n\n\n  * Cookie\nli_gc\n  * Duration\n6 months\n  * Description\nLinkedin set this cookie for storing visitor's consent regarding using cookies for non-essential purposes.\n\n\n  * Cookie\n__hssrc\n  * Duration\nsession\n  * Description\nThis cookie is set by Hubspot whenever it changes the session cookie. The __hssrc cookie set to 1 indicates that the user has restarted the browser, and if the cookie does not exist, it is assumed to be a new session.\n\n\n  * Cookie\n__hssc\n  * Duration\n1 hour\n  * Description\nHubSpot sets this cookie to keep track of sessions and to determine if HubSpot should increment the session number and timestamps in the __hstc cookie.\n\n\n  * Cookie\nwpEmojiSettingsSupports\n  * Duration\nsession\n  * Description\nWordPress sets this cookie when a user interacts with emojis on a WordPress site. It helps determine if the user's browser can display emojis properly.\n\n\n  * Cookie\nBCSessionID\n  * Duration\n1 year 1 month 4 days\n  * Description\nBlueconic sets this cookie as a unique identifier for the BlueConic profile.\n\n\n  * Cookie\n_octo\n  * Duration\n1 year\n  * Description\nNo description available.\n\n\n  * Cookie\nlogged_in\n  * Duration\n1 year\n  * Description\nNo description available.\n\n\n  * Cookie\n__Secure-YEC\n  * Duration\npast\n  * Description\nYouTube sets this cookie to stores the user's video player preferences using embedded YouTube video\n\n\n  * Cookie\n__eoi\n  * Duration\n6 months\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nAWSALBTGCORS\n  * Duration\n7 days\n  * Description\nNo description available.\n\n\n  * Cookie\nlogin-status-p\n  * Duration\npast\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nAWSALBTG\n  * Duration\n7 days\n  * Description\nNo description available.\n\n\n  * Cookie\ncsrf_token\n  * Duration\nsession\n  * Description\nNo description available.\n\n\n  * Cookie\ntoken_v2\n  * Duration\n1 day\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nD\n  * Duration\n1 year\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nPHPSESSID\n  * Duration\nsession\n  * Description\nThis cookie is native to PHP applications. The cookie stores and identifies a user's unique session ID to manage user sessions on the website. The cookie is a session cookie and will be deleted when all the browser windows are closed.\n\n\n  * Cookie\nVISITOR_PRIVACY_METADATA\n  * Duration\n6 months\n  * Description\nYouTube sets this cookie to store the user's cookie consent state for the current domain. \n\n\n  * Cookie\ncookietest\n  * Duration\nsession\n  * Description\nThe cookietest cookie is typically used to determine whether the user's browser accepts cookies, essential for website functionality and user experience.\n\n\n  * Cookie\n__Host-airtable-session\n  * Duration\n1 year\n  * Description\nThis cookie is used to enable us to integrate the services of Airtable.\n\n\n  * Cookie\n__Host-airtable-session.sig\n  * Duration\n1 year\n  * Description\nThis cookie is used to enable us to integrate the services of Airtable.\n\n\n  * Cookie\nm\n  * Duration\n1 year 1 month 4 days\n  * Description\nStripe sets this cookie for fraud prevention purposes. It identifies the device used to access the website, allowing the website to be formatted accordingly.\n\n\n  * Cookie\nBIGipServer*\n  * Duration\nsession\n  * Description\nMarketo sets this cookie to collect information about the user's online activity and build a profile about their interests to provide advertisements relevant to the user. \n\n\n  * Cookie\n__cfruid\n  * Duration\nsession\n  * Description\nCloudflare sets this cookie to identify trusted web traffic.\n\n\n  * Cookie\n_GRECAPTCHA\n  * Duration\n6 months\n  * Description\nGoogle Recaptcha service sets this cookie to identify bots to protect the website against malicious spam attacks.\n\n\n  * Cookie\n__Secure-YNID\n  * Duration\n6 months\n  * Description\nGoogle cookie used to protect user security and prevent fraud, especially during the login process.\n\n\n  * Cookie\ncookieyes-consent\n  * Duration\n1 year\n  * Description\nCookieYes sets this cookie to remember users' consent preferences so that their preferences are respected on subsequent visits to this site. It does not collect or store any personal information about the site visitors.\n\n\nFunctional\nFunctional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.\n  * Cookie\nlidc\n  * Duration\n1 day\n  * Description\nLinkedIn sets the lidc cookie to facilitate data center selection.\n\n\n  * Cookie\nbrw\n  * Duration\n1 year\n  * Description\nNo description available.\n\n\n  * Cookie\nbrwConsent\n  * Duration\n5 minutes\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nWMF-Uniq\n  * Duration\n1 year\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nloom_anon_comment\n  * Duration\n1 year\n  * Description\nNo description available.\n\n\n  * Cookie\nloom_referral_video\n  * Duration\nsession\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nVISITOR_INFO1_LIVE\n  * Duration\n6 months\n  * Description\nA cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.\n\n\n  * Cookie\nyt-remote-connected-devices\n  * Duration\nNever Expires\n  * Description\nYouTube sets this cookie to store the user's video preferences using embedded YouTube videos.\n\n\n  * Cookie\nytidb::LAST_RESULT_ENTRY_KEY\n  * Duration\nNever Expires\n  * Description\nThe cookie ytidb::LAST_RESULT_ENTRY_KEY is used by YouTube to store the last search result entry that was clicked by the user. This information is used to improve the user experience by providing more relevant search results in the future.\n\n\n  * Cookie\nyt-remote-device-id\n  * Duration\nNever Expires\n  * Description\nYouTube sets this cookie to store the user's video preferences using embedded YouTube videos.\n\n\n  * Cookie\nyt-remote-session-name\n  * Duration\nsession\n  * Description\nThe yt-remote-session-name cookie is used by YouTube to store the user's video player preferences using embedded YouTube video.\n\n\n  * Cookie\nyt-remote-fast-check-period\n  * Duration\nsession\n  * Description\nThe yt-remote-fast-check-period cookie is used by YouTube to store the user's video player preferences for embedded YouTube videos.\n\n\n  * Cookie\nyt-remote-session-app\n  * Duration\nsession\n  * Description\nThe yt-remote-session-app cookie is used by YouTube to store user preferences and information about the interface of the embedded YouTube video player.\n\n\n  * Cookie\nyt-remote-cast-available\n  * Duration\nsession\n  * Description\nThe yt-remote-cast-available cookie is used to store the user's preferences regarding whether casting is available on their YouTube video player.\n\n\n  * Cookie\nyt-remote-cast-installed\n  * Duration\nsession\n  * Description\nThe yt-remote-cast-installed cookie is used to store the user's video player preferences using embedded YouTube video.\n\n\n  * Cookie\ncp_session\n  * Duration\n3 months\n  * Description\nCodepen sets this cookie for Help systems found in the website.\n\n\n  * Cookie\nloid\n  * Duration\n1 year 1 month 4 days\n  * Description\nThis cookie is set by the Reddit. The cookie enables the sharing of content from the website onto the social media platform.\n\n\nAnalytics\nAnalytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.\n  * Cookie\n__hstc\n  * Duration\n6 months\n  * Description\nHubspot set this main cookie for tracking visitors. It contains the domain, initial timestamp (first visit), last timestamp (last visit), current timestamp (this visit), and session number (increments for each subsequent session).\n\n\n  * Cookie\nhubspotutk\n  * Duration\n6 months\n  * Description\nHubSpot sets this cookie to keep track of the visitors to the website. This cookie is passed to HubSpot on form submission and used when deduplicating contacts.\n\n\n  * Cookie\n_ga\n  * Duration\n1 year 1 month 4 days\n  * Description\nGoogle Analytics sets this cookie to calculate visitor, session and campaign data and track site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognise unique visitors.\n\n\n  * Cookie\n_ga_*\n  * Duration\n1 year 1 month 4 days\n  * Description\nGoogle Analytics sets this cookie to store and count page views.\n\n\n  * Cookie\n__Host-psifi.analyticsTrace\n  * Duration\n6 hours\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\n__Host-psifi.analyticsTraceV2\n  * Duration\n6 hours\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\n_gh_sess\n  * Duration\nsession\n  * Description\nGitHub sets this cookie for temporary application and framework state between pages like what step the user is on in a multiple step form.\n\n\n  * Cookie\nYSC\n  * Duration\nsession\n  * Description\nYSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.\n\n\n  * Cookie\najs_anonymous_id\n  * Duration\n1 year\n  * Description\nThis cookie is set by Segment to count the number of people who visit a certain site by tracking if they have visited before.\n\n\n  * Cookie\nvuid\n  * Duration\n1 year 1 month 4 days\n  * Description\nVimeo installs this cookie to collect tracking information by setting a unique ID to embed videos on the website. \n\n\nPerformance\nPerformance cookies are used to understand and analyse the key performance indexes of the website which helps in delivering a better user experience for the visitors.\n  * Cookie\nAWSALB\n  * Duration\n7 days\n  * Description\nAWSALB is an application load balancer cookie set by Amazon Web Services to map the session to the target.\n\n\n  * Cookie\nacq\n  * Duration\npast\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nacq.sig\n  * Duration\npast\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nptc\n  * Duration\n2 years\n  * Description\nNo description available.\n\n\nAdvertisement\nAdvertisement cookies are used to provide visitors with customised advertisements based on the pages you visited previously and to analyse the effectiveness of the ad campaigns.\n  * Cookie\nmuc_ads\n  * Duration\n1 year 1 month 4 days\n  * Description\nTwitter sets this cookie to collect user behaviour and interaction data to optimize the website.\n\n\n  * Cookie\nguest_id_marketing\n  * Duration\n1 year 1 month 4 days\n  * Description\nTwitter sets this cookie to identify and track the website visitor.\n\n\n  * Cookie\nguest_id_ads\n  * Duration\n1 year 1 month 4 days\n  * Description\nTwitter sets this cookie to identify and track the website visitor.\n\n\n  * Cookie\npersonalization_id\n  * Duration\n1 year 1 month 4 days\n  * Description\nTwitter sets this cookie to integrate and share features for social media and also store information about how the user uses the website, for tracking and targeting.\n\n\n  * Cookie\nguest_id\n  * Duration\n1 year 1 month 4 days\n  * Description\nTwitter sets this cookie to identify and track the website visitor. It registers if a user is signed in to the Twitter platform and collects information about ad preferences.\n\n\n  * Cookie\nbcookie\n  * Duration\n1 year\n  * Description\nLinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser IDs.\n\n\n  * Cookie\n__Secure-ROLLOUT_TOKEN\n  * Duration\n6 months\n  * Description\nYouTube sets this cookie to manage feature rollout and experimentation. It helps Google control which new features or interface changes are shown to users as part of testing and staged rollouts, ensuring consistent experience for a given user during an experiment.\n\n\n  * Cookie\nyt.innertube::nextId\n  * Duration\nNever Expires\n  * Description\nYouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen.\n\n\n  * Cookie\nyt.innertube::requests\n  * Duration\nNever Expires\n  * Description\nYouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen.\n\n\n  * Cookie\nsession_tracker\n  * Duration\nsession\n  * Description\nThis cookie is set by the Reddit. This cookie is used to identify trusted web traffic. It also helps in adverstising on the website.\n\n\n  * Cookie\nedgebucket\n  * Duration\nsession\n  * Description\nReddit sets this cookie to save the information about a log-on Reddit user, for the purpose of advertisement recommendations and updating the content.\n\n\n  * Cookie\ndid\n  * Duration\n1 year\n  * Description\nArbor sets this cookie to show targeted ads to site visitors.This cookie expires after 2 months or 1 year.\n\n\nUncategorised\nOther uncategorised cookies are those that are being analysed and have not been classified into a category as yet.\nNo cookies to display.\nReject All Save My Preferences Accept All\nToggle Search[](https://towardsdatascience.com/)Toggle Mobile Navigation\n[](https://towardsdatascience.com/)\nPublish AI, ML & data-science insights to a global community of data professionals.\nSign in[Submit an Article](https://write.insightmediagroup.io)\n[Latest](https://towardsdatascience.com/latest/)[Editor's Picks](https://towardsdatascience.com/tag/editors-pick/)[Newsletter](https://towardsdatascience.com/tag/the-variable/)[ShipAI](https://towardsdatascience.com/shipai/)\n* * *\n[Write For TDS](https://towardsdatascience.com/submissions/)\n[LinkedIn](https://www.linkedin.com/company/towards-data-science/)[X](https://x.com/TDataScience)Toggle Search\n[Large Language Models](https://towardsdatascience.com/category/artificial-intelligence/large-language-models/)\n# Enterprise Document Intelligence: A Series on Building RAG Brick by Brick, from Minimal to Corpus scale\nFor AI engineers who want to understand every step, not just call the library\n[Angela and Kezhan Shi](https://towardsdatascience.com/author/angela.shi/)\nMay 22, 202622 min read\n![](../images/000.jpg)\n* * *\n**Articles published in the series:**\n  * [Prompt, Context, Loop: The Three Engineering Layers Every RAG System Is Built On](https://towardsdatascience.com/prompt-context-loop-the-three-engineering-layers-every-rag-system-is-built-on/)\n\n\n  * [Loop engineering for RAG generation with prompt from a base prompt plus the rules each question needs](https://towardsdatascience.com/assemble-each-rag-generation-prompt-from-a-base-prompt-plus-the-rules-each-question-needs/).\n  * [A structure for context engineering: the four typed pieces behind every RAG answer.](https://towardsdatascience.com/letting-an-llm-pick-the-right-rag-page-the-arbiter-pattern-at-the-end-of-retrieval/) Context engineering given a structure: the four typed pieces (fixed system prompt, retrieved lines, doc-context block, PromptContext wrapper) that fill one single-document RAG LLM call.\n\n\n* * *\nAbout three years ago, generative AI took off and RAG showed up as the standard answer for “we have documents, we want to ask questions.” The pitch sounded miraculous. The implementation everyone described was the same one, over and over:\n  * chunk the documents,\n  * push the chunks into a vector store,\n  * embed the question,\n  * retrieve top-k by cosine similarity, optionally rerank,\n  * send the hits to an LLM\n\n\nVendors converged on it. Consulting decks converged on it. Conference talks converged on it.\nLearn this step by step with the interactive [AI Engineer](https://roadmap.sh/ai-engineer) roadmap.\n![](../images/001.png)\n_The RAG recipe everyone described: chunk, vector store, top-k cosine, optional rerank, LLM - Image by author_\nThen the deployments started shipping, and the results were often disappointing.\n  * Users didn’t trust the answers.\n  * Citations were vague or missing.\n  * Retrieved passages were beside the point as often as they were useful.\n\n\nAnd the team’s reflex, every time, was to pull more tools from the same toolbox:\n  * a stronger model,\n  * a longer context window,\n  * a better reranker,\n  * more MLOps for the production side.\n\n\nThe framing was always the same: “this is an IT problem. Better infrastructure, better tools, better models will fix it.”\nI started looking at it myself, on real enterprise documents, with real domain experts in the room. My experience didn’t match that framing.\nThe work that actually made a real difference wasn’t infrastructural. It was engineering, plus understanding the business domain, plus a little of the underlying math. Not deep math. Just enough to see what an embedding actually measures, what a reranker actually does, why a particular trick helps in some cases and hurts in others. And then, the piece most teams skip: knowing the documents the system is supposed to answer questions on. Who reads them. What they contain. What vocabulary the experts use. What questions come up week after week.\n**Most companies aren’t Google. They’re not research labs either.** They’re not running open-domain QA over the open web. They’re not training their own embedding models. They have a few core document types, a few dozen domain experts who already know the corpus inside out, and a recurring set of questions that need answers with citations and an audit trail. The right architecture for that context is not what vendor decks pitch and not what research papers chase. It’s an architecture that amplifies the experts and uses cheap, predictable retrieval where it can.\n**Most of the RAG systems I’ve seen in enterprise production are worse than a hundred-line Python script.** The basics are broken, and stacking more on top doesn’t help. Embeddings are too fuzzy in meaning to pick the right passage, and parsing is sloppy enough that the LLM gets garbage in, garbage out.\nWhen a system like that starts to break, the standard reflex is to add layers:\n  * a re-ranker,\n  * a fine-tuned embedding model nobody can tell is helping,\n  * a query-rewriter agent,\n  * a grader agent,\n  * an orchestrator framework that turns every question into ten LLM calls.\n\n\nEach layer adds plausibility to the demo. None of them fixes the foundation: there is still no way to tell whether the retrieved passages are the right ones, and still no way to explain to a user why a particular page came back.\nThe script we’ll build in the first article fits in about a hundred lines and has no vector database, no framework, and no agents.\nIt takes a PDF and a question, parses, retrieves the top three pages by simple cosine similarity, sends them to an LLM with a Pydantic schema, and returns a structured answer with line citations and a highlighted source PDF.\nThat script is more verifiable and more useful than many of the production systems I’ve seen up close. The gap between the two isn’t prompt engineering, and it isn’t a better retrieval algorithm. It comes from three habits the industry skips: knowing the documents, knowing what the experts already know, and not confusing RAG with machine learning.\nThis series wires those habits into a four-brick pipeline: document parsing, question parsing, retrieval, generation, with an optional PDF annotation step that hands the citation back to the reader.\n![](../images/body-b56e94e81b3fd2877863.png)\n_Four bricks plus PDF annotation, with the data named on every arrow - Image by author_\n## 1. How RAG is used in enterprise\n### 1.1 The 2020 paper: retrieval as context\nIn May 2020, Patrick Lewis and colleagues at Facebook AI Research coined the term in [_Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks_](https://arxiv.org/abs/2005.11401) (Lewis et al. 2020, arXiv preprint). Their abstract names the three failings the architecture was meant to fix, quoted directly:\nPre-trained models “cannot easily expand or revise their memory, can’t straightforwardly provide insight into their predictions, and may produce ‘hallucinations’.” The fix combined a generator (BART) with a dense vector index over Wikipedia, accessed at inference time. The architectural move that mattered: pull a passage from a corpus, hand it to the LLM, let it generate from that context rather than from training-time memory alone.\nThose three failings map cleanly onto the three properties enterprise RAG fights for: corpus freshness, citations, grounded answers. The series is a direct continuation of that 2020 line of thinking, applied to enterprise constraints.\n### 1.2 What “RAG” means in this series\nFor most developers today, “RAG” has narrowed to mean one specific recipe: a vector store, embedding-similarity retrieval, and an LLM at the end.\nThe series will keep using the word, but in its broader original sense: information extraction, information search, and question answering over a corpus of documents.\nThe retrieval mechanism is a design choice the architecture admits, not part of the definition. Many of the enterprise pipelines this series defends do not use a vector store at all; some use it as one channel among several, never as the foundation. When the announcement says “RAG”, read it in that broader sense.\n### 1.3 Extraction comes first in enterprise\nThe popular framing of RAG (the LLM writes a fluid natural-language answer from retrieved context) under-describes what enterprises actually do with it.\nThe bulk of the work is **information extraction** : pulling specific values from documents, with the LLM acting as a structured reader rather than as a writer.\n  * An underwriter needs a coverage amount, a deductible, an effective date.\n  * A compliance officer needs the list of clauses that survive termination.\n  * A paralegal needs the named parties of a contract.\n\n\nThe LLM reads the retrieved passage, identifies the answer, and returns it in a typed schema with line citations. That is extraction, with some light reformatting and cleanup. It is not generation in the creative sense.\nWhere the LLM is allowed to compose new text in enterprise work, it does so over content the system has already extracted and validated. The series defends a sharp separation: **phase one extracts the relevant information with citations, validates it, audits it**. Phase two, on top of phase one’s typed output, may compose a longer narrative (a draft notice, a summary paragraph for a report).\nTwo phases, two LLM calls, two audit surfaces. The audit trail collapses when one LLM call mixes retrieval, extraction, and creative composition. The architecture refuses that conflation.\n### 1.4 The shift from _augmented_ to _grounded_\nThe 2020 paper picked **Augmented** over alternatives like _Grounded_ or _Conditioned_. The word choice carries weight. In the 2020 framework, the generator is free to blend its parametric memory with the retrieved passages. The LLM keeps using what it learned during pre-training and consults the retrieval. Two memories, mixed. _Augmented_ presupposes that something is already there; retrieval adds to it. _Grounded_ would have meant the opposite: the generation rests on the retrieval, anchored to it, and the model is constrained not to stray from what was retrieved.\nEnterprise production inverts that assumption. Every factual claim must be backed by a retrieved passage; the LLM’s parametric memory is exiled from the _factual content_ of the answer and kept only for _procedural_ use: grammar, schema-following, verbatim span extraction, arithmetic on cited values, deduction over retrieved facts. The shift from _augmented_ to _grounded_ is small lexically and large operationally. When the LLM rephrases a retrieved clause into a JSON field `coverage_amount: 50000`, the rephrasing follows English grammar and JSON syntax: that is procedural, and we keep it. When it fills a `valid_until: \"2027-12-31\"` field with a date that is not in the retrieved text, that is factual, and we block it.\nThe series keeps the architecture from the 2020 paper and narrows what the LLM is allowed to do with its parametric memory.\n![](../images/body-abaa15cab18cd5bcfef6.png)\n_Academic RAG blends stored and retrieved knowledge ; enterprise grounds answers in retrieval only - Image by author_\n### 1.5 Long context isn’t a substitute\nA million-token window does not collapse the enterprise corpus to one prompt. The corpus is thousands to hundreds of thousands of documents, and finding the right one still has to happen before any LLM call. And a long-context answer drawn from a million-token blob cannot tell the user which page backs which claim. RAG with line-level citations does.\n## 2. Why “Enterprise Document Intelligence” rather than “Enterprise RAG”\nOne objection comes up repeatedly when the series is pitched, and it pushes toward the broader name. Two scope claims complete the picture : what “Enterprise” really means as an architectural constraint, and which corpus shape the series handles.\n### 2.1 RAG names one mode of the work, not all of it\nRAG, in its strict sense, is retrieval-augmented question answering. The architecture the series defends covers more than that. Classification at ingestion, field extraction at scale, versioning, SQL aggregation, evaluation, security: several of these are not RAG in any standard sense. The SQL agent of Article 17 isn’t RAG at all; it is the point where retrieval ends and data systems take over. The follow-up volume adds translation, summarization, side-by-side comparison, redaction; these are also not RAG. “Document Intelligence” names the broader work; “RAG” is one of its modes, specifically the question-answering one.\n![](../images/body-f5f984d2528a07bffd5b.png)\n_Volume 1: deep on RAG-QA over PDFs. Volume 2: other tasks, same discipline - Image by author_\n### 2.2 “Enterprise” as an architectural constraint\nThe _Enterprise_ qualifier is not a market segment. It is a constraint. The corpus is controlled, not the open web. The expert is in the loop, and the system amplifies what they already know. The audit trail is mandatory because every answer can be challenged. The dispatcher is deterministic because reproducibility matters. Open-domain assistants make different trade-offs. The series is for engineers building inside that constraint, and every architectural choice in it follows from it.\n### 2.3 The shape of the corpus the series handles\nThe series’ main case is a corpus of **homogeneous, independent documents** : a few thousand to a few hundred thousand PDFs of the same type. When the corpus mixes several types, the first move is to classify into groups (Article 15), then run a homogeneous pipeline per group. Each document is read on its own ; the corpus index sits on top of all of them.\nA **case file** (a credit application, a contract renewal, an insurance claim) is a small bundle of heterogeneous PDFs about one entity. The series stays on PDFs throughout, so a handful of small files can simply be concatenated and treated as a single document. This is where the table of contents pays off : several PDFs, each with its own TOC, read like one larger document with nested sections after concatenation, and the retrieval brick (Article 7) already knows how to navigate it. The follow-up volume builds proper case-file routing with per-document-type signals when the bundle gets too varied or too large to glue together.\nThe harder shape is **many case files, many document types per file** : hundreds of cases, each with five to fifty heterogeneous documents inside. The orchestration on top of that exceeds what a single corpus index alone offers. The series names the case for honesty about scope and leaves the full treatment to the follow-up volume ; the primitives built in Parts IV-V carry over.\nIf your archive is one of the homogeneous shapes, the series covers it end to end. If it is case-file shaped, expect this series to take you most of the way, and the follow-up volume to finish the job.\n## 3. What this series is\n**Enterprise Document Intelligence** is a brick-by-brick series for engineers and data scientists building RAG on enterprise documents: contracts, technical reports, regulatory filings, where a wrong answer triggers a regulatory finding, a contract dispute, or a refund to a client. The series focuses on **PDF as the document format** , the dominant form for the documents enterprises actually want to query. Other formats (Word, Excel, PowerPoint, email) need their own parsing and structure logic and are covered by follow-up work.\nThe “amplify the expert” stance translates into concrete architectural choices the series defends, each tied to specific articles:\n  * **Deterministic dispatchers over autonomous agents.** Experts can audit a deterministic flow. They cannot audit an agent that decides on its own which tool to call, which sub-question to issue, and when to stop. The agent saves engineering effort on the demo and pays it back during incidents that can’t be reproduced because the routing was non-deterministic. The series defends a dispatched architecture where every routing decision is explicit, logged, and inspectable. Article 13 builds it.\n  * **Vector stores are a fallback, not a foundation.** Experts already know the keywords. The vector store earns its place when keyword retrieval fails: paraphrase, cross-language, polysemy, “vehicle parked at night” matching “car overnight.” It shouldn’t be where retrieval starts. On most enterprise corpora, structure-first retrieval (TOC, classification, expert keywords) outperforms cosine similarity. Articles 2 and 7 develop the case.\n  * **Expert dictionaries beat better embedding models.** Domain vocabulary is the single most valuable artifact in the system. The synonyms, the disambiguations, the cross-product equivalences (“franchise = deductible”, “ShieldPro Elite = top-tier homeowners plan”) cannot be recovered by an IDF formula or by embedding similarity; they have to be elicited from the people who use the vocabulary every day. Article 6 makes the dictionary the central object of question parsing.\n  * **Rerankers are mostly redundant in enterprise RAG.** They are worth their cost on one narrow shape (large generic candidate pool, no curated pipeline upstream). The architectural moves the series defends (expert vocabulary, structure-aware retrieval, classify-before-retrieve) make them redundant on the questions that matter. Article 2 bis runs the empirical test.\n  * **Refuse the “connect everything to a vector store” pattern.** That pattern is optimized for the hyperscaler’s business model, not the customer’s accuracy. Classify before indexing. Filter before retrieving. Aggregate with SQL when the question is statistical. RAG handles content lookup; SQL handles counting; the corpus index sits in between. Articles 14-17 make this the core of the corpus-scale architecture.\n\n\nBehind those choices sit three positive principles that recur in every article. The work is **pragmatic and expertise-driven** : every choice gets judged on whether it builds on the accumulated knowledge of the people who already understand the documents. The architecture is **pyramidal engineering** : four named bricks (parsing, question parsing, retrieval, generation), each one a handful of named functions with explicit inputs and outputs, so a senior engineer can trace a request end-to-end in minutes. The data is **relational at every brick** : parsing produces tables, question parsing produces tables, retrieval queries them, generation writes a typed row back, never raw strings at any junction.\n![](../images/body-e63f0dc4d0e5e2fcd5ae.png)\n_One PDF in, eight linked tables out. Every later brick reads from these - Image by author_\nThree philosophical positions follow from the above and recur throughout: **embeddings are not magic** (Article 2), **RAG is not machine learning** (Article 3), **evaluation is per-failure-mode, not aggregate** (Article 20).\nThese positions come from building RAG in regulated industries: insurance, legal, financial services. They aren’t the only valid positions. They’re the ones that have held up in production where a wrong answer triggers a refund, a fine, or a lawsuit.\n## 4. What’s in the series\n### Part I: What works, what breaks\n_Build the minimal pipeline, watch where it cracks, reframe the discipline, then locate your own case before going further._ Each article sets up the next, so the four can be read in one sitting before tools or frameworks enter the picture.\n![](../images/body-1a550c8d04d1b237b39c.png)\n_The 5x5 case grid from Article 4. Place your problem before picking a technique - Image by author_\n  * **Article 1: A Minimal RAG, From PDF to Highlighted Answer.** The whole pipeline in ~100 lines. PDF in, structured JSON out, source lines highlighted on the PDF.\n\n\n  * **Article 2: Embeddings Aren’t Magic.** The predictable failure modes of RAG retrieval: negation, exact values, internal acronyms, topical proximity. Where the minimal version starts to break.\n  * **Article 2 bis (companion): Rerankers Aren’t Magic Either.** Cross-encoder rerankers fix the literal-token traps embeddings collapse, but share the same structural failure modes (negation, exact identifiers, listing, out-of-domain vocabulary). The editorial position: fallback for narrow cases, not a primary stage.\n  * **Article 3: RAG Is Not Machine Learning.** The misconception that costs RAG projects the most. RAG is search plus a generation layer, not a model to train.\n  * **Article 4: Which RAG Technique Fits Which Problem.** Diagnostic step before any technical choice. Position your problem on the 5×5 grid (document complexity × question control), then pick the simplest technique that works.\n\n\n### Part II: The four bricks\n_Parsing → question parsing → retrieval → generation._ The four bricks that carry the rest of the series. What sets the architecture apart from generic RAG: every brick produces **relational structured data** (linked DataFrames, typed rows), never raw strings. The pipeline can be inspected, replayed, and audited at every junction.\n![](../images/body-1ecc6f4498462eb31027.png)\n_Brick 2 mirrors brick 1: one question, one row, satellite tables for keywords and scope - Image by author_\n  * **Article 5: The Rich Output of a Good RAG Parser.** Brick 1: lines, tables, images, columns, TOC, cross-references. Everything lost at parsing cannot be recovered downstream.\n\n\n  * **Article 5 bis (companion): When PyMuPDF Can’t See the Table. Parsing with Azure Document Intelligence.** Same eight DataFrames, second engine. Azure adds native table cells, OCR text inside figures, deterministic captions, and a TOC reconstructed from paragraph roles when no native bookmarks exist. The `parsing_method` column tracks per-row provenance so adaptive parsing can mix fitz and Azure on the same document.\n  * **Article 6: Question Parsing in RAG. Structure Before You Search.** Brick 2: a question is an unstructured input parsed into a relational set of tables, symmetric to document parsing.\n  * **Article 7: Why Embeddings Come Last in Production RAG Retrieval.** Brick 3: retrieval is filtering structured DataFrames, not searching free text. Embeddings are the fallback, not the default.\n  * **Article 8: Generation as Controlled Execution.** Brick 4: typed input (passages plus question), typed output (Pydantic). The schema is the contract; one prompt template per answer shape.\n\n\n### Part III: Pipelines on a single document\n_The whole pipeline assembled from Part II’s improvements, then extended._ Article 1 ran the minimal pipeline end-to-end; Part II then improved each brick in isolation. Article 9 closes that loop: same kind of demo as Article 1, on the same paper, with every Part II improvement wired in together. Articles 10-12 then add specific complexity patterns: adaptive parsing (where generation tells parsing to escalate), cross-references, listing. Article 13 assembles every pattern into the orchestrator, wires the feedback loops that bound iteration, and is where the team’s accumulated wisdom lives.\n![](../images/body-afee1f00b7587317d116.png)\n_The 5x5 case grid from Article 4. Place your problem before picking a technique - Image by author_\n  * **Article 9: The Full Pipeline, End-to-End, Putting Part II Together.** Article 1 ran the pipeline minimally. Part II said how each brick can do better, in isolation. This article runs the same kind of demo as Article 1, on the same Transformer paper, with every Part II improvement wired in: richer parsing, expert-keyword question parsing with typo handling, retrieval methods combined (TOC plus keyword plus embedding with score fusion and an optional LLM arbiter), structured generation with the full schema. The gap between minimal and integrated, shown end-to-end on the same questions.\n  * **Article 10: Adaptive PDF Parsing.** Cheap parsing first; advanced parsing only where the question demands it. Adaptive escalation driven by generation feedback.\n  * **Article 11: How RAG Handles Cross-References in Contracts and Standards.** The real challenge of “complex” documents isn’t length, it’s interconnection. Two-hop retrieval that follows references.\n  * **Article 12: When RAG Has to Find All the Answers: Listing Questions.** “What are all the X?” The answer isn’t in one passage, it’s distributed. Sweep, not top-k, with explicit completeness signals.\n  * **Article 13: From One RAG Pipeline to Many: The Composite Pipeline Pattern.** Assembling every pattern into a single working system. The orchestrator and dispatcher are the team’s accumulated wisdom in code; bounded feedback loops, drift detection, and the full audit trail live here too.\n\n\n### Part IV: From one document to a whole archive\n_Naive embedding search over thousands of documents fails. The same four bricks still apply, but each one needs a structural index in front of it._ Article 14 sets the thesis with a minimal corpus pipeline run on five NIST PDFs, the kind of baseline that wastes four out of five LLM calls because nothing filtered the corpus first. Article 15 fixes the input side: a hierarchical cascade of questions populates a relational `corpus_index`, one row per document, columns for the searchable fields. Article 16 formalises the ontology that drives the cascade as five small tables hand-curated by the expert, and explains why a curated relational layer beats an LLM-extracted knowledge graph on every operational axis. Article 17 wires the query side: parse the question, filter the index, run the document-level pipeline only on the candidates the SQL agent returned.\n![](../images/body-97e3b0939b6c602d63e8.png)\n_The 5x5 case grid from Article 4. Place your problem before picking a technique - Image by author_\n  * **Article 14: Your RAG works on one PDF. Now make it work on ten thousand.** Part IV thesis. Five failure modes of naive vector RAG at scale, the mirror principle (4 bricks for one doc → 4 bricks for the corpus), a minimal `corpus_qa_baseline` run on five NIST PDFs that shows where the waste is.\n  * **Article 15: From a folder of PDFs to a queryable RAG corpus, one question at a time.** Brick 1 supercharged. A hierarchical cascade of questions populates the `corpus_index` per document, with two execution paths (regex on filename, single-doc pipeline otherwise) and nomenclature normalisation (raw extraction → canonical entity). Real runs on 24 NIST PDFs and 30 arXiv papers.\n  * **Article 16: Why your enterprise RAG needs an ontology, not a knowledge graph.** The keystone. The expert’s knowledge codified as five relational tables (cascade rules, concept keywords, concept relations, concept-to-doctype routing, nomenclature). Wins on auditability, cost, maintenance, freshness, ownership. Three sectors (NIST cybersecurity, arXiv NLP/IR, fictional insurance broker) prove the pattern transfers. Anti-GraphRAG is the consequence, not the slogan.\n  * **Article 17: How RAG answers a question across a corpus: SQL filter first, retrieval second.** Bricks 2-3-4 supercharged. The orchestrator detects intent (column / docs / hybrid), runs the SQL agent or filter-then-retrieve, dispatches generation. Three real runs on the NIST `corpus_index` close the architecture.\n\n\n### Part V: Operating in production\n_The system is built. Now run it for years._ The code architecture that lets several developers work in parallel, the storage layer that holds the replayable artifacts, per-failure-mode evaluation against a curated dataset (no aggregate-accuracy mirages), cost and latency measured as SQL aggregations on the same storage, and the security envelope wrapping all of it. RAG-specific concerns that generic ML-ops and generic security guides don’t address.\n![](../images/body-859813d034d9c2edd3b3.png)\n_The four-layer package layout that survives years of evolution. Article 18 draws the function map - Image by author_\n  * **Article 18: Code Architecture for Enterprise RAG: Four Layers and a Function Map.** The package layout that survives years of evolution. Four layers (core, storage, annotation, pipeline) with unidirectional dependencies, one method per script, and the function map that anchors every brick to its dispatcher and sub-functions.\n  * **Article 19: Storage for Enterprise RAG: One Base for Everything You Measure.** Around thirty relational tables in five sub-schemas, anchored on two hash-based identifiers (`file_id`, `question_id`). Long format for storage, wide views for output. The `llm_raw_json` column and the `query_log` table are what evaluation, cost, and audit all read from.\n  * **Article 20: Evaluating Enterprise RAG: Measure the Process, Not the Model.** Per-failure-mode evaluation as a `pandas.groupby` on a results table joined from Article 19’s storage. Aggregate metrics lie ; per-question-type metrics tell the truth.\n  * **Article 21: Cost and Latency in Enterprise RAG: Measuring from the Storage.** Same source tables as Article 20, different aggregations. Tokens, latency, alerts, versioning. Self-hosted Ollama tier-1 benchmark on the broker domain.\n  * **Article 22: Security and Compliance for Enterprise RAG.** Closing chapter. Prompt injection through documents, tenant isolation, GDPR on derived data, audit trail, document-level access control, self-hosted confidentiality boundary : the enterprise-specific layer generic security guides don’t address.\n\n\n### Bonus articles\nEach one is a cross-cutting practical concern that touches several main articles but doesn’t belong inside any single part.\n  * **B01: Spelling Variants in RAG. Why Spell-Check Alone Isn’t Enough.** Forty years of classical spell-correction (Levenshtein, BK-tree, Soundex, SymSpell) handles most single-word typos. Embeddings and LLMs absorb the rest. The practical split for enterprise RAG: spell-correct the question against the corpus vocabulary at parse time; for documents, clean the canonical references once, leave volume noisy and design retrieval around the noise.\n  * **B02: FAQ as RAG. When You Get to Design the Corpus.** A controlled-corpus counterpoint to the rest of the series. Standard RAG assumes you inherit a chaotic corpus; FAQ flips it. Parsing becomes trivial, retrieval doubles as a cache, and few-shot prompting itself becomes a retrieval problem. Closes with the feedback loop that turns the FAQ into a living corpus driven by the question stream.\n  * **B03: When the RAG Says “I Don’t Know”. Justifying the Absence of an Answer.** A confident wrong answer is a bug. A bare “no answer” with no justification is almost as bad. Each of the four bricks owes the user one piece of evidence: what was parsed, which vocabulary was searched, which pages were swept, why nothing matched. The “I don’t know” becomes auditable instead of opaque.\n  * **B04: Tables in PDFs for RAG. Don’t Flatten the Grid.** Tables are where most RAG pipelines silently fail. A linear decision tree across table types does not work because the dimensions cross. The right pattern is four levels of representation (row-as-line in `line_df`, separate `table_df`, columnar with named and typed columns, columnar but heterogeneous), a per-table diagnostic on five orthogonal axes, and a handful of idempotent operations that move tables between levels. Most tables stay at the simplest level; only the few that need it pay the cost of escalation.\n\n\nEach article stands on its own. Each builds on the previous ones in a way that should feel natural: the same minimal pipeline from Article 1 grows into the architecture of Articles 18-19 and the security envelope of Article 22, with every addition motivated by a specific failure observed earlier.\n## 5. Who this is for\n**Engineers building RAG systems on enterprise documents.** Legal, insurance, financial services, regulated industries broadly, anywhere the cost of a wrong answer is measurable. If you’ve shipped a RAG system that worked on demos and broke on real users, this series is for you.\n**Data scientists who feel that ML intuitions don’t quite map to RAG.** They don’t. The series makes the difference clear and actionable.\n**Tech leads making architectural decisions.** When to use a vector database. When not to. When agentic patterns are worth their cost. When they don’t. When to invest in deeper parsing. The series is opinionated on these calls and explains the reasoning.\n## 6. Who this isn’t for\n**Teams without internal experts on the documents.** The series assumes you have, or can get to, the people who already know your corpus:\n  * lawyers who read the contracts,\n  * underwriters who set the deductibles,\n  * compliance officers who track the regulations.\n\n\nAlmost every architectural choice in the series amplifies that expertise. If you’re building open-domain QA on a corpus nobody internal understands, the choices here will not transfer. There are settings where general-purpose retrieval and autonomous agents make more sense; this series is not about those.\n**Researchers on the frontier.** This series is about production engineering, not novel methods. It cites recent research where relevant but doesn’t try to advance it.\n**Anyone looking for a magic framework.** The series is the opposite. It’s about understanding what’s underneath the frameworks well enough to make deliberate choices. Sometimes that means using a framework. Often it means writing a hundred lines of plain code that work better than what the framework gave you.\n## 7. What this series doesn’t cover\nThe series focuses on RAG over **PDF documents** : search and generation for question answering. It doesn’t cover other document formats (Word, Excel, PowerPoint, email), side-by-side document comparison, structured data alongside documents (databases), translation pipelines, large-scale summarization, document generation, or autonomous agents on documents.\nThese are real enterprise needs. They’re left out because they’re operationally different from RAG-on-PDF. Mixing them in produces the confused architectures the series is trying to help readers avoid.\nA follow-up volume, planned for after this one closes, picks up each on its own terms: other document formats (Word / Excel / PowerPoint / email), side-by-side comparison, translation, summarization, structured data alongside documents, document generation. Same engineering discipline, applied to different problem shapes.\n## 8. How to follow the series\nThe articles will publish daily, in order, starting with Article 1: _A Minimal RAG, From PDF to Highlighted Answer_.\nIt builds the entire pipeline in about a hundred lines of Python. It sets up every article that follows by surfacing the questions a working minimal version naturally raises.\nIf you’re building RAG in production and you think the industry’s defaults are wrong, this series is what to do about it.\n## Register Now to Continue Reading\n### Unlock Towards Data Science with a Free Account\nAll articles on Towards Data Science are available to registered users. Create a free account today to access this article and thousands more.\nRegister for freeSign in to your account\n* * *\n![](../images/body-249d024535392fb76067.jpeg)\nWritten By\n## [Angela and Kezhan Shi](https://towardsdatascience.com/author/angela.shi/)\n[See all from Angela and Kezhan Shi](https://towardsdatascience.com/author/angela.shi/)\n[Artificial Intelligence](https://towardsdatascience.com/tag/artificial-intelligence/)[Rag](https://towardsdatascience.com/tag/rag/)\nShare This Article\n  * [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Ftowardsdatascience.com%2Fdocument-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale%2F&title=Enterprise%20Document%20Intelligence%3A%20A%20Series%20on%20Building%20RAG%20Brick%20by%20Brick%2C%20from%20Minimal%20to%20Corpus%20scale)\n  * [](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Ftowardsdatascience.com%2Fdocument-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale%2F&title=Enterprise%20Document%20Intelligence%3A%20A%20Series%20on%20Building%20RAG%20Brick%20by%20Brick%2C%20from%20Minimal%20to%20Corpus%20scale)\n  * [](https://x.com/share?url=https%3A%2F%2Ftowardsdatascience.com%2Fdocument-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale%2F&text=Enterprise%20Document%20Intelligence%3A%20A%20Series%20on%20Building%20RAG%20Brick%20by%20Brick%2C%20from%20Minimal%20to%20Corpus%20scale)\n\n\nTowards Data Science is a community publication. Submit your insights to reach our global audience and earn through the TDS Author Payment Program.\n[Write for TDS](https://towardsdatascience.com/submissions/)\n## Related Articles\n  * [![](../images/002.png)](https://towardsdatascience.com/understanding-events-with-artificial-intelligence-12e1ec3c5c9/)\n## [Understanding Events with Artificial Intelligence](https://towardsdatascience.com/understanding-events-with-artificial-intelligence-12e1ec3c5c9/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nWe have come across a lot of client requirements that boil down to using AI to understand events. Some systems need to classify events into...\n[Daniel Shapiro, PhD](https://towardsdatascience.com/author/lemaysolutions/)\nOctober 9, 20177 min read\n  * [![](../images/003.jpg)](https://towardsdatascience.com/enhancing-e-commerce-with-generative-ai-part-1-9e402fb30e7b/)\n## [Enhancing E-Commerce with Generative AI - Part 1](https://towardsdatascience.com/enhancing-e-commerce-with-generative-ai-part-1-9e402fb30e7b/)\n[Deep Learning](https://towardsdatascience.com/category/artificial-intelligence/deep-learning/)\nFrom Data to Product Recommendations\n[Mina Ghashami](https://towardsdatascience.com/author/mina.ghashami/)\nJuly 31, 202417 min read\n  * [![](../images/004.png)](https://towardsdatascience.com/pandas-in-the-premier-league-78f1d0c21b4f/)\n## [Pandas in the Premier League](https://towardsdatascience.com/pandas-in-the-premier-league-78f1d0c21b4f/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nHow can we get started with Pandas for Data Analysis\n[Stephen Fordham](https://towardsdatascience.com/author/stephenfordham/)\nApril 21, 20196 min read\n  * [![](../images/005.jpeg)](https://towardsdatascience.com/double-q-learning-the-easy-way-a924c4085ec3/)\n## [Double Q-Learning the Easy Way](https://towardsdatascience.com/double-q-learning-the-easy-way-a924c4085ec3/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nQ-learning (Watkins, 1989) is considered one of the breakthroughs in TD control reinforcement learning algorithm.\n[Ziad SALLOUM](https://towardsdatascience.com/author/zsalloum/)\nDecember 6, 20185 min read\n  * [![](../images/006.jpg)](https://towardsdatascience.com/intuitions-in-high-dimensional-spaces-c22f0441ce19/)\n## [Intuitions in high-dimensional spaces](https://towardsdatascience.com/intuitions-in-high-dimensional-spaces-c22f0441ce19/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nCounter-intuitive geometric properties of high-dimensional spaces\n[Peter Barrett Bryan](https://towardsdatascience.com/author/peterbbryan/)\nFebruary 9, 20223 min read\n  * [![](../images/007.png)](https://towardsdatascience.com/ai-concepts-and-real-life-36a51f1917ae/)\n## [AI concepts and real life](https://towardsdatascience.com/ai-concepts-and-real-life-36a51f1917ae/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nCapturing the Insights of how Artificial Intelligence concepts are nothing but basic human intellligence.\n[Tejasvi Sharma](https://towardsdatascience.com/author/contacttejasvi/)\nAugust 7, 20214 min read\n  * [![](../images/008.png)](https://towardsdatascience.com/exploring-llms-for-icd-coding-part-1-959e48b58b9e/)\n## [Exploring LLMs for ICD Coding - Part 1](https://towardsdatascience.com/exploring-llms-for-icd-coding-part-1-959e48b58b9e/)\n[ChatGPT](https://towardsdatascience.com/category/artificial-intelligence/chatgpt/)\nBuilding automated clinical coding systems with LLMs\n[Anand Subramanian](https://towardsdatascience.com/author/anand.subu10/)\nMay 16, 202417 min read\n  * [![](../images/009.jpeg)](https://towardsdatascience.com/evaluating-multi-step-llm-generated-content-why-customer-journeys-require-structural-metrics/)\n## [Evaluating Multi-Step LLM-Generated Content: Why Customer Journeys Require Structural Metrics](https://towardsdatascience.com/evaluating-multi-step-llm-generated-content-why-customer-journeys-require-structural-metrics/)\n[Large Language Models](https://towardsdatascience.com/category/artificial-intelligence/large-language-models/)\nHow to evaluate goal-oriented content designed to build engagement and deliver business results, and why structure matters.\n[Diana Schneider](https://towardsdatascience.com/author/diana.schneider/)\nJanuary 22, 202611 min read\n  * [![](../images/010.jpg)](https://towardsdatascience.com/end-to-end-machine-learning-project-telco-customer-churn-90744a8df97d/)\n## [End-to-end machine learning project: Telco customer churn](https://towardsdatascience.com/end-to-end-machine-learning-project-telco-customer-churn-90744a8df97d/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nAnalyzing IBM telecommunications data (Kaggle dataset)\n[Amanda Iglesias Moreno](https://towardsdatascience.com/author/amandaiglesiasmoreno/)\nNovember 23, 202119 min read\n\n\n  * [YouTube](https://www.youtube.com/c/TowardsDataScience)\n  * [X](https://x.com/TDataScience)\n  * [LinkedIn](https://www.linkedin.com/company/towards-data-science/)\n  * [Threads](https://www.threads.net/@towardsdatascience)\n  * [Bluesky](https://bsky.app/profile/towardsdatascience.com)\n\n\n[](https://towardsdatascience.com/)\nYour home for data science and AI. The world's leading publication for data science, data analytics, data engineering, machine learning, and artificial intelligence professionals.\nSubscribe to Our Newsletter[Write For TDS](https://towardsdatascience.com/submissions/)•[About](https://towardsdatascience.com/about-towards-data-science-d691af11cc2f/)•[Advertise](https://contact.towardsdatascience.com/advertise-with-towards-data-science)•[Privacy Policy](https://towardsdatascience.com/privacy-policy/)•[Terms of Use](https://towardsdatascience.com/website-terms-of-use/)\n© Insight Media Group, LLC 2026•[The New Stack](https://thenewstack.io)•[roadmap.sh](https://roadmap.sh)•[Creator Network](https://insightmediagroup.io/creator-network)\n####  Recommended Articles \nClose\n  * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607686/image?etag=1782161464448&width=500&height=500) How Relevance Models Foreshadowed Transformers for NLP ](https://towardsdatascience.com/how-relevance-models-foreshadowed-transformers-for-nlp/ \"How Relevance Models Foreshadowed Transformers for NLP\")\n  * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607639/image?etag=1781250125848&width=500&height=500) Javascript Fatigue: HTMX Is All You Need to Build ChatGPT — Part 1 ](https://towardsdatascience.com/javascript-fatigue-you-dont-need-js-to-build-chatgpt/ \"Javascript Fatigue: HTMX Is All You Need to Build ChatGPT — Part 1\")\n  * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607930/image?etag=1782124566054&width=500&height=500) The Subset Sum Problem Solved in Linear Time for Dense Enough Inputs ](https://towardsdatascience.com/subset-sum-problem-solved-in-linear-time-for-dense-enough-inputs/ \"The Subset Sum Problem Solved in Linear Time for Dense Enough Inputs\")\n  * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/3660/image?etag=1780176246070&width=500&height=500) Does Your Company Have a Data Strategy? ](https://towardsdatascience.com/does-your-company-have-a-data-strategy-e8944dbec4ae/ \"Does Your Company Have a Data Strategy?\")\n\n\n",
  "metadata": {
    "title": "Enterprise Document Intelligence: A Series on Building RAG Brick by Brick, from Minimal to Corpus scale | Towards Data Science",
    "description": "For AI engineers who want to understand every step, not just call the library",
    "keywords": null,
    "author": "Angela and Kezhan Shi",
    "og:locale": "en_US",
    "og:type": "article",
    "og:title": "Enterprise Document Intelligence: A Series on Building RAG Brick by Brick, from Minimal to Corpus scale",
    "og:description": "For AI engineers who want to understand every step, not just call the library",
    "og:url": "https://towardsdatascience.com/document-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale/",
    "og:site_name": "Towards Data Science",
    "og:image": "https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/enterprise_document_intelligence_rag_series_overview.jpg",
    "og:image:width": "1200",
    "og:image:height": "630",
    "og:image:type": "image/jpeg",
    "twitter:card": "summary_large_image",
    "twitter:site": "@TDataScience",
    "twitter:creator": "@TDataScience",
    "twitter:label1": "Written by",
    "twitter:data1": "Angela and Kezhan Shi",
    "twitter:label2": "Est. reading time",
    "twitter:data2": "22 min read",
    "article:published_time": "2026-05-22T09:00:07.000Z",
    "article:modified_time": "2026-05-22T09:00:07.000Z",
    "article:author": "https://towardsdatascience.com/author/angela.shi/"
  },
  "paywall": {
    "listed_paid": false,
    "detected": false,
    "marker": "",
    "public_only": false,
    "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙"
  },
  "crawl": {
    "success": true,
    "status_code": 202,
    "error": ""
  },
  "code_blocks": [],
  "images": [
    {
      "status": "http_404",
      "url": "https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607686/image?etag=1782161464448&width=500&height=500",
      "src": "https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607686/image?etag=1782161464448&width=500&height=500",
      "alt": "",
      "downloaded": false,
      "discovery": "saved_markdown",
      "retried_at": "2026-10-20T18:06:17Z"
    },
    {
      "status": "http_404",
      "url": "https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607639/image?etag=1781250125848&width=500&height=500",
      "src": "https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607639/image?etag=1781250125848&width=500&height=500",
      "alt": "",
      "downloaded": false,
      "discovery": "saved_markdown",
      "retried_at": "2026-10-20T18:06:17Z"
    },
    {
      "status": "http_404",
      "url": "https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607930/image?etag=1782124566054&width=500&height=500",
      "src": "https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607930/image?etag=1782124566054&width=500&height=500",
      "alt": "",
      "downloaded": false,
      "discovery": "saved_markdown",
      "retried_at": "2026-10-20T18:06:17Z"
    },
    {
      "status": "http_404",
      "url": "https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/3660/image?etag=1780176246070&width=500&height=500",
      "src": "https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/3660/image?etag=1780176246070&width=500&height=500",
      "alt": "",
      "downloaded": false,
      "discovery": "saved_markdown",
      "retried_at": "2026-10-20T18:06:17Z"
    }
  ],
  "audio": [],
  "videos": [
    {
      "url": "https://www.youtube.com/c/TowardsDataScience",
      "kind": "channel_reference",
      "status": "reference_only"
    }
  ],
  "links": [
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/latest/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/tag/editors-pick/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/tag/the-variable/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/shipai/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/submissions/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/category/artificial-intelligence/large-language-models/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/author/angela.shi/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/prompt-context-loop-the-three-engineering-layers-every-rag-system-is-built-on/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/assemble-each-rag-generation-prompt-from-a-base-prompt-plus-the-rules-each-question-needs/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/letting-an-llm-pick-the-right-rag-page-the-arbiter-pattern-at-the-end-of-retrieval/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/tag/artificial-intelligence/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/tag/rag/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/understanding-events-with-artificial-intelligence-12e1ec3c5c9/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/category/artificial-intelligence/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/author/lemaysolutions/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/enhancing-e-commerce-with-generative-ai-part-1-9e402fb30e7b/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/category/artificial-intelligence/deep-learning/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/author/mina.ghashami/"
    },
    {
      "type": "internal",
      "href": "https://towardsdatascience.com/pandas-in-the-premier-league-78f1d0c21b4f/"
    },
    {
      "type": "external",
      "href": "https://write.insightmediagroup.io"
    },
    {
      "type": "external",
      "href": "https://www.linkedin.com/company/towards-data-science/"
    },
    {
      "type": "external",
      "href": "https://x.com/TDataScience"
    },
    {
      "type": "external",
      "href": "https://roadmap.sh/ai-engineer"
    },
    {
      "type": "external",
      "href": "https://arxiv.org/abs/2005.11401"
    },
    {
      "type": "external",
      "href": "https://www.facebook.com/sharer/sharer.php?title=Enterprise+Document+Intelligence%3A+A+Series+on+Building+RAG+Brick+by+Brick%2C+from+Minimal+to+Corpus+scale&u=https%3A%2F%2Ftowardsdatascience.com%2Fdocument-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale%2F"
    },
    {
      "type": "external",
      "href": "https://www.linkedin.com/shareArticle?mini=true&title=Enterprise+Document+Intelligence%3A+A+Series+on+Building+RAG+Brick+by+Brick%2C+from+Minimal+to+Corpus+scale&url=https%3A%2F%2Ftowardsdatascience.com%2Fdocument-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale%2F"
    },
    {
      "type": "external",
      "href": "https://x.com/share?text=Enterprise+Document+Intelligence%3A+A+Series+on+Building+RAG+Brick+by+Brick%2C+from+Minimal+to+Corpus+scale&url=https%3A%2F%2Ftowardsdatascience.com%2Fdocument-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale%2F"
    },
    {
      "type": "external",
      "href": "https://www.youtube.com/c/TowardsDataScience"
    },
    {
      "type": "external",
      "href": "https://www.threads.net/@towardsdatascience"
    },
    {
      "type": "external",
      "href": "https://bsky.app/profile/towardsdatascience.com"
    },
    {
      "type": "external",
      "href": "https://thenewstack.io"
    },
    {
      "type": "external",
      "href": "https://roadmap.sh"
    },
    {
      "type": "external",
      "href": "https://insightmediagroup.io/creator-network"
    }
  ],
  "repair_version": 2,
  "repaired_at": "2026-10-20T17:32:35Z",
  "source_url": "https://towardsdatascience.com/document-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale/",
  "delivery_status": "unverified",
  "discovery_status": "http_403",
  "missing_reason": "源页面未重新核验:http_403；已按保留正文补采图片",
  "repair_error": "",
  "actual_video_files": [],
  "expected_saved_body_images": 4,
  "image_discovery": "saved_markdown",
  "source_body_markdown": "![Revisit consent button](https://cdn-cookieyes.com/assets/images/revisit.svg)\nWe value your privacy\nWe use cookies to enhance your browsing experience, serve personalised ads or content, and analyse our traffic. By clicking \"Accept All\", you consent to our use of cookies.\nCustomise Reject All Accept All\nCustomise Consent Preferences ![](https://cdn-cookieyes.com/assets/images/close.svg)\nWe use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.\nThe cookies that are categorised as \"Necessary\" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... Show more\nNecessaryAlways Active\nNecessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.\n  * Cookie\nBCTempID\n  * Duration\n10 minutes\n  * Description\nNo description available.\n\n\n  * Cookie\n__cf_bm\n  * Duration\n1 hour\n  * Description\nThis cookie, set by Cloudflare, is used to support Cloudflare Bot Management. \n\n\n  * Cookie\nAWSALBCORS\n  * Duration\n7 days\n  * Description\nAmazon Web Services set this cookie for load balancing.\n\n\n  * Cookie\n_cfuvid\n  * Duration\nsession\n  * Description\nCloudflare sets this cookie to track users across sessions to optimize user experience by maintaining session consistency and providing personalized services\n\n\n  * Cookie\nli_gc\n  * Duration\n6 months\n  * Description\nLinkedin set this cookie for storing visitor's consent regarding using cookies for non-essential purposes.\n\n\n  * Cookie\n__hssrc\n  * Duration\nsession\n  * Description\nThis cookie is set by Hubspot whenever it changes the session cookie. The __hssrc cookie set to 1 indicates that the user has restarted the browser, and if the cookie does not exist, it is assumed to be a new session.\n\n\n  * Cookie\n__hssc\n  * Duration\n1 hour\n  * Description\nHubSpot sets this cookie to keep track of sessions and to determine if HubSpot should increment the session number and timestamps in the __hstc cookie.\n\n\n  * Cookie\nwpEmojiSettingsSupports\n  * Duration\nsession\n  * Description\nWordPress sets this cookie when a user interacts with emojis on a WordPress site. It helps determine if the user's browser can display emojis properly.\n\n\n  * Cookie\nBCSessionID\n  * Duration\n1 year 1 month 4 days\n  * Description\nBlueconic sets this cookie as a unique identifier for the BlueConic profile.\n\n\n  * Cookie\n_octo\n  * Duration\n1 year\n  * Description\nNo description available.\n\n\n  * Cookie\nlogged_in\n  * Duration\n1 year\n  * Description\nNo description available.\n\n\n  * Cookie\n__Secure-YEC\n  * Duration\npast\n  * Description\nYouTube sets this cookie to stores the user's video player preferences using embedded YouTube video\n\n\n  * Cookie\n__eoi\n  * Duration\n6 months\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nAWSALBTGCORS\n  * Duration\n7 days\n  * Description\nNo description available.\n\n\n  * Cookie\nlogin-status-p\n  * Duration\npast\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nAWSALBTG\n  * Duration\n7 days\n  * Description\nNo description available.\n\n\n  * Cookie\ncsrf_token\n  * Duration\nsession\n  * Description\nNo description available.\n\n\n  * Cookie\ntoken_v2\n  * Duration\n1 day\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nD\n  * Duration\n1 year\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nPHPSESSID\n  * Duration\nsession\n  * Description\nThis cookie is native to PHP applications. The cookie stores and identifies a user's unique session ID to manage user sessions on the website. The cookie is a session cookie and will be deleted when all the browser windows are closed.\n\n\n  * Cookie\nVISITOR_PRIVACY_METADATA\n  * Duration\n6 months\n  * Description\nYouTube sets this cookie to store the user's cookie consent state for the current domain. \n\n\n  * Cookie\ncookietest\n  * Duration\nsession\n  * Description\nThe cookietest cookie is typically used to determine whether the user's browser accepts cookies, essential for website functionality and user experience.\n\n\n  * Cookie\n__Host-airtable-session\n  * Duration\n1 year\n  * Description\nThis cookie is used to enable us to integrate the services of Airtable.\n\n\n  * Cookie\n__Host-airtable-session.sig\n  * Duration\n1 year\n  * Description\nThis cookie is used to enable us to integrate the services of Airtable.\n\n\n  * Cookie\nm\n  * Duration\n1 year 1 month 4 days\n  * Description\nStripe sets this cookie for fraud prevention purposes. It identifies the device used to access the website, allowing the website to be formatted accordingly.\n\n\n  * Cookie\nBIGipServer*\n  * Duration\nsession\n  * Description\nMarketo sets this cookie to collect information about the user's online activity and build a profile about their interests to provide advertisements relevant to the user. \n\n\n  * Cookie\n__cfruid\n  * Duration\nsession\n  * Description\nCloudflare sets this cookie to identify trusted web traffic.\n\n\n  * Cookie\n_GRECAPTCHA\n  * Duration\n6 months\n  * Description\nGoogle Recaptcha service sets this cookie to identify bots to protect the website against malicious spam attacks.\n\n\n  * Cookie\n__Secure-YNID\n  * Duration\n6 months\n  * Description\nGoogle cookie used to protect user security and prevent fraud, especially during the login process.\n\n\n  * Cookie\ncookieyes-consent\n  * Duration\n1 year\n  * Description\nCookieYes sets this cookie to remember users' consent preferences so that their preferences are respected on subsequent visits to this site. It does not collect or store any personal information about the site visitors.\n\n\nFunctional\nFunctional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.\n  * Cookie\nlidc\n  * Duration\n1 day\n  * Description\nLinkedIn sets the lidc cookie to facilitate data center selection.\n\n\n  * Cookie\nbrw\n  * Duration\n1 year\n  * Description\nNo description available.\n\n\n  * Cookie\nbrwConsent\n  * Duration\n5 minutes\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nWMF-Uniq\n  * Duration\n1 year\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nloom_anon_comment\n  * Duration\n1 year\n  * Description\nNo description available.\n\n\n  * Cookie\nloom_referral_video\n  * Duration\nsession\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nVISITOR_INFO1_LIVE\n  * Duration\n6 months\n  * Description\nA cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.\n\n\n  * Cookie\nyt-remote-connected-devices\n  * Duration\nNever Expires\n  * Description\nYouTube sets this cookie to store the user's video preferences using embedded YouTube videos.\n\n\n  * Cookie\nytidb::LAST_RESULT_ENTRY_KEY\n  * Duration\nNever Expires\n  * Description\nThe cookie ytidb::LAST_RESULT_ENTRY_KEY is used by YouTube to store the last search result entry that was clicked by the user. This information is used to improve the user experience by providing more relevant search results in the future.\n\n\n  * Cookie\nyt-remote-device-id\n  * Duration\nNever Expires\n  * Description\nYouTube sets this cookie to store the user's video preferences using embedded YouTube videos.\n\n\n  * Cookie\nyt-remote-session-name\n  * Duration\nsession\n  * Description\nThe yt-remote-session-name cookie is used by YouTube to store the user's video player preferences using embedded YouTube video.\n\n\n  * Cookie\nyt-remote-fast-check-period\n  * Duration\nsession\n  * Description\nThe yt-remote-fast-check-period cookie is used by YouTube to store the user's video player preferences for embedded YouTube videos.\n\n\n  * Cookie\nyt-remote-session-app\n  * Duration\nsession\n  * Description\nThe yt-remote-session-app cookie is used by YouTube to store user preferences and information about the interface of the embedded YouTube video player.\n\n\n  * Cookie\nyt-remote-cast-available\n  * Duration\nsession\n  * Description\nThe yt-remote-cast-available cookie is used to store the user's preferences regarding whether casting is available on their YouTube video player.\n\n\n  * Cookie\nyt-remote-cast-installed\n  * Duration\nsession\n  * Description\nThe yt-remote-cast-installed cookie is used to store the user's video player preferences using embedded YouTube video.\n\n\n  * Cookie\ncp_session\n  * Duration\n3 months\n  * Description\nCodepen sets this cookie for Help systems found in the website.\n\n\n  * Cookie\nloid\n  * Duration\n1 year 1 month 4 days\n  * Description\nThis cookie is set by the Reddit. The cookie enables the sharing of content from the website onto the social media platform.\n\n\nAnalytics\nAnalytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.\n  * Cookie\n__hstc\n  * Duration\n6 months\n  * Description\nHubspot set this main cookie for tracking visitors. It contains the domain, initial timestamp (first visit), last timestamp (last visit), current timestamp (this visit), and session number (increments for each subsequent session).\n\n\n  * Cookie\nhubspotutk\n  * Duration\n6 months\n  * Description\nHubSpot sets this cookie to keep track of the visitors to the website. This cookie is passed to HubSpot on form submission and used when deduplicating contacts.\n\n\n  * Cookie\n_ga\n  * Duration\n1 year 1 month 4 days\n  * Description\nGoogle Analytics sets this cookie to calculate visitor, session and campaign data and track site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognise unique visitors.\n\n\n  * Cookie\n_ga_*\n  * Duration\n1 year 1 month 4 days\n  * Description\nGoogle Analytics sets this cookie to store and count page views.\n\n\n  * Cookie\n__Host-psifi.analyticsTrace\n  * Duration\n6 hours\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\n__Host-psifi.analyticsTraceV2\n  * Duration\n6 hours\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\n_gh_sess\n  * Duration\nsession\n  * Description\nGitHub sets this cookie for temporary application and framework state between pages like what step the user is on in a multiple step form.\n\n\n  * Cookie\nYSC\n  * Duration\nsession\n  * Description\nYSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.\n\n\n  * Cookie\najs_anonymous_id\n  * Duration\n1 year\n  * Description\nThis cookie is set by Segment to count the number of people who visit a certain site by tracking if they have visited before.\n\n\n  * Cookie\nvuid\n  * Duration\n1 year 1 month 4 days\n  * Description\nVimeo installs this cookie to collect tracking information by setting a unique ID to embed videos on the website. \n\n\nPerformance\nPerformance cookies are used to understand and analyse the key performance indexes of the website which helps in delivering a better user experience for the visitors.\n  * Cookie\nAWSALB\n  * Duration\n7 days\n  * Description\nAWSALB is an application load balancer cookie set by Amazon Web Services to map the session to the target.\n\n\n  * Cookie\nacq\n  * Duration\npast\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nacq.sig\n  * Duration\npast\n  * Description\nDescription is currently not available.\n\n\n  * Cookie\nptc\n  * Duration\n2 years\n  * Description\nNo description available.\n\n\nAdvertisement\nAdvertisement cookies are used to provide visitors with customised advertisements based on the pages you visited previously and to analyse the effectiveness of the ad campaigns.\n  * Cookie\nmuc_ads\n  * Duration\n1 year 1 month 4 days\n  * Description\nTwitter sets this cookie to collect user behaviour and interaction data to optimize the website.\n\n\n  * Cookie\nguest_id_marketing\n  * Duration\n1 year 1 month 4 days\n  * Description\nTwitter sets this cookie to identify and track the website visitor.\n\n\n  * Cookie\nguest_id_ads\n  * Duration\n1 year 1 month 4 days\n  * Description\nTwitter sets this cookie to identify and track the website visitor.\n\n\n  * Cookie\npersonalization_id\n  * Duration\n1 year 1 month 4 days\n  * Description\nTwitter sets this cookie to integrate and share features for social media and also store information about how the user uses the website, for tracking and targeting.\n\n\n  * Cookie\nguest_id\n  * Duration\n1 year 1 month 4 days\n  * Description\nTwitter sets this cookie to identify and track the website visitor. It registers if a user is signed in to the Twitter platform and collects information about ad preferences.\n\n\n  * Cookie\nbcookie\n  * Duration\n1 year\n  * Description\nLinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser IDs.\n\n\n  * Cookie\n__Secure-ROLLOUT_TOKEN\n  * Duration\n6 months\n  * Description\nYouTube sets this cookie to manage feature rollout and experimentation. It helps Google control which new features or interface changes are shown to users as part of testing and staged rollouts, ensuring consistent experience for a given user during an experiment.\n\n\n  * Cookie\nyt.innertube::nextId\n  * Duration\nNever Expires\n  * Description\nYouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen.\n\n\n  * Cookie\nyt.innertube::requests\n  * Duration\nNever Expires\n  * Description\nYouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen.\n\n\n  * Cookie\nsession_tracker\n  * Duration\nsession\n  * Description\nThis cookie is set by the Reddit. This cookie is used to identify trusted web traffic. It also helps in adverstising on the website.\n\n\n  * Cookie\nedgebucket\n  * Duration\nsession\n  * Description\nReddit sets this cookie to save the information about a log-on Reddit user, for the purpose of advertisement recommendations and updating the content.\n\n\n  * Cookie\ndid\n  * Duration\n1 year\n  * Description\nArbor sets this cookie to show targeted ads to site visitors.This cookie expires after 2 months or 1 year.\n\n\nUncategorised\nOther uncategorised cookies are those that are being analysed and have not been classified into a category as yet.\nNo cookies to display.\nReject All Save My Preferences Accept All\nToggle Search[](https://towardsdatascience.com/)Toggle Mobile Navigation\n[](https://towardsdatascience.com/)\nPublish AI, ML & data-science insights to a global community of data professionals.\nSign in[Submit an Article](https://write.insightmediagroup.io)\n[Latest](https://towardsdatascience.com/latest/)[Editor's Picks](https://towardsdatascience.com/tag/editors-pick/)[Newsletter](https://towardsdatascience.com/tag/the-variable/)[ShipAI](https://towardsdatascience.com/shipai/)\n* * *\n[Write For TDS](https://towardsdatascience.com/submissions/)\n[LinkedIn](https://www.linkedin.com/company/towards-data-science/)[X](https://x.com/TDataScience)Toggle Search\n[Large Language Models](https://towardsdatascience.com/category/artificial-intelligence/large-language-models/)\n# Enterprise Document Intelligence: A Series on Building RAG Brick by Brick, from Minimal to Corpus scale\nFor AI engineers who want to understand every step, not just call the library\n[Angela and Kezhan Shi](https://towardsdatascience.com/author/angela.shi/)\nMay 22, 202622 min read\n![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/enterprise_document_intelligence_rag_series_overview.jpg)\n* * *\n**Articles published in the series:**\n  * [Prompt, Context, Loop: The Three Engineering Layers Every RAG System Is Built On](https://towardsdatascience.com/prompt-context-loop-the-three-engineering-layers-every-rag-system-is-built-on/)\n\n\n  * [Loop engineering for RAG generation with prompt from a base prompt plus the rules each question needs](https://towardsdatascience.com/assemble-each-rag-generation-prompt-from-a-base-prompt-plus-the-rules-each-question-needs/).\n  * [A structure for context engineering: the four typed pieces behind every RAG answer.](https://towardsdatascience.com/letting-an-llm-pick-the-right-rag-page-the-arbiter-pattern-at-the-end-of-retrieval/) Context engineering given a structure: the four typed pieces (fixed system prompt, retrieved lines, doc-context block, PromptContext wrapper) that fill one single-document RAG LLM call.\n\n\n* * *\nAbout three years ago, generative AI took off and RAG showed up as the standard answer for “we have documents, we want to ask questions.” The pitch sounded miraculous. The implementation everyone described was the same one, over and over:\n  * chunk the documents,\n  * push the chunks into a vector store,\n  * embed the question,\n  * retrieve top-k by cosine similarity, optionally rerank,\n  * send the hits to an LLM\n\n\nVendors converged on it. Consulting decks converged on it. Conference talks converged on it.\nLearn this step by step with the interactive [AI Engineer](https://roadmap.sh/ai-engineer) roadmap.\n![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/image-247-1024x312.png)\n_The RAG recipe everyone described: chunk, vector store, top-k cosine, optional rerank, LLM - Image by author_\nThen the deployments started shipping, and the results were often disappointing.\n  * Users didn’t trust the answers.\n  * Citations were vague or missing.\n  * Retrieved passages were beside the point as often as they were useful.\n\n\nAnd the team’s reflex, every time, was to pull more tools from the same toolbox:\n  * a stronger model,\n  * a longer context window,\n  * a better reranker,\n  * more MLOps for the production side.\n\n\nThe framing was always the same: “this is an IT problem. Better infrastructure, better tools, better models will fix it.”\nI started looking at it myself, on real enterprise documents, with real domain experts in the room. My experience didn’t match that framing.\nThe work that actually made a real difference wasn’t infrastructural. It was engineering, plus understanding the business domain, plus a little of the underlying math. Not deep math. Just enough to see what an embedding actually measures, what a reranker actually does, why a particular trick helps in some cases and hurts in others. And then, the piece most teams skip: knowing the documents the system is supposed to answer questions on. Who reads them. What they contain. What vocabulary the experts use. What questions come up week after week.\n**Most companies aren’t Google. They’re not research labs either.** They’re not running open-domain QA over the open web. They’re not training their own embedding models. They have a few core document types, a few dozen domain experts who already know the corpus inside out, and a recurring set of questions that need answers with citations and an audit trail. The right architecture for that context is not what vendor decks pitch and not what research papers chase. It’s an architecture that amplifies the experts and uses cheap, predictable retrieval where it can.\n**Most of the RAG systems I’ve seen in enterprise production are worse than a hundred-line Python script.** The basics are broken, and stacking more on top doesn’t help. Embeddings are too fuzzy in meaning to pick the right passage, and parsing is sloppy enough that the LLM gets garbage in, garbage out.\nWhen a system like that starts to break, the standard reflex is to add layers:\n  * a re-ranker,\n  * a fine-tuned embedding model nobody can tell is helping,\n  * a query-rewriter agent,\n  * a grader agent,\n  * an orchestrator framework that turns every question into ten LLM calls.\n\n\nEach layer adds plausibility to the demo. None of them fixes the foundation: there is still no way to tell whether the retrieved passages are the right ones, and still no way to explain to a user why a particular page came back.\nThe script we’ll build in the first article fits in about a hundred lines and has no vector database, no framework, and no agents.\nIt takes a PDF and a question, parses, retrieves the top three pages by simple cosine similarity, sends them to an LLM with a Pydantic schema, and returns a structured answer with line citations and a highlighted source PDF.\nThat script is more verifiable and more useful than many of the production systems I’ve seen up close. The gap between the two isn’t prompt engineering, and it isn’t a better retrieval algorithm. It comes from three habits the industry skips: knowing the documents, knowing what the experts already know, and not confusing RAG with machine learning.\nThis series wires those habits into a four-brick pipeline: document parsing, question parsing, retrieval, generation, with an optional PDF annotation step that hands the citation back to the reader.\n![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/image-236-1024x478.png)\n_Four bricks plus PDF annotation, with the data named on every arrow - Image by author_\n## 1. How RAG is used in enterprise\n### 1.1 The 2020 paper: retrieval as context\nIn May 2020, Patrick Lewis and colleagues at Facebook AI Research coined the term in [_Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks_](https://arxiv.org/abs/2005.11401) (Lewis et al. 2020, arXiv preprint). Their abstract names the three failings the architecture was meant to fix, quoted directly:\nPre-trained models “cannot easily expand or revise their memory, can’t straightforwardly provide insight into their predictions, and may produce ‘hallucinations’.” The fix combined a generator (BART) with a dense vector index over Wikipedia, accessed at inference time. The architectural move that mattered: pull a passage from a corpus, hand it to the LLM, let it generate from that context rather than from training-time memory alone.\nThose three failings map cleanly onto the three properties enterprise RAG fights for: corpus freshness, citations, grounded answers. The series is a direct continuation of that 2020 line of thinking, applied to enterprise constraints.\n### 1.2 What “RAG” means in this series\nFor most developers today, “RAG” has narrowed to mean one specific recipe: a vector store, embedding-similarity retrieval, and an LLM at the end.\nThe series will keep using the word, but in its broader original sense: information extraction, information search, and question answering over a corpus of documents.\nThe retrieval mechanism is a design choice the architecture admits, not part of the definition. Many of the enterprise pipelines this series defends do not use a vector store at all; some use it as one channel among several, never as the foundation. When the announcement says “RAG”, read it in that broader sense.\n### 1.3 Extraction comes first in enterprise\nThe popular framing of RAG (the LLM writes a fluid natural-language answer from retrieved context) under-describes what enterprises actually do with it.\nThe bulk of the work is **information extraction** : pulling specific values from documents, with the LLM acting as a structured reader rather than as a writer.\n  * An underwriter needs a coverage amount, a deductible, an effective date.\n  * A compliance officer needs the list of clauses that survive termination.\n  * A paralegal needs the named parties of a contract.\n\n\nThe LLM reads the retrieved passage, identifies the answer, and returns it in a typed schema with line citations. That is extraction, with some light reformatting and cleanup. It is not generation in the creative sense.\nWhere the LLM is allowed to compose new text in enterprise work, it does so over content the system has already extracted and validated. The series defends a sharp separation: **phase one extracts the relevant information with citations, validates it, audits it**. Phase two, on top of phase one’s typed output, may compose a longer narrative (a draft notice, a summary paragraph for a report).\nTwo phases, two LLM calls, two audit surfaces. The audit trail collapses when one LLM call mixes retrieval, extraction, and creative composition. The architecture refuses that conflation.\n### 1.4 The shift from _augmented_ to _grounded_\nThe 2020 paper picked **Augmented** over alternatives like _Grounded_ or _Conditioned_. The word choice carries weight. In the 2020 framework, the generator is free to blend its parametric memory with the retrieved passages. The LLM keeps using what it learned during pre-training and consults the retrieval. Two memories, mixed. _Augmented_ presupposes that something is already there; retrieval adds to it. _Grounded_ would have meant the opposite: the generation rests on the retrieval, anchored to it, and the model is constrained not to stray from what was retrieved.\nEnterprise production inverts that assumption. Every factual claim must be backed by a retrieved passage; the LLM’s parametric memory is exiled from the _factual content_ of the answer and kept only for _procedural_ use: grammar, schema-following, verbatim span extraction, arithmetic on cited values, deduction over retrieved facts. The shift from _augmented_ to _grounded_ is small lexically and large operationally. When the LLM rephrases a retrieved clause into a JSON field `coverage_amount: 50000`, the rephrasing follows English grammar and JSON syntax: that is procedural, and we keep it. When it fills a `valid_until: \"2027-12-31\"` field with a date that is not in the retrieved text, that is factual, and we block it.\nThe series keeps the architecture from the 2020 paper and narrows what the LLM is allowed to do with its parametric memory.\n![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/image-237-1024x413.png)\n_Academic RAG blends stored and retrieved knowledge ; enterprise grounds answers in retrieval only - Image by author_\n### 1.5 Long context isn’t a substitute\nA million-token window does not collapse the enterprise corpus to one prompt. The corpus is thousands to hundreds of thousands of documents, and finding the right one still has to happen before any LLM call. And a long-context answer drawn from a million-token blob cannot tell the user which page backs which claim. RAG with line-level citations does.\n## 2. Why “Enterprise Document Intelligence” rather than “Enterprise RAG”\nOne objection comes up repeatedly when the series is pitched, and it pushes toward the broader name. Two scope claims complete the picture : what “Enterprise” really means as an architectural constraint, and which corpus shape the series handles.\n### 2.1 RAG names one mode of the work, not all of it\nRAG, in its strict sense, is retrieval-augmented question answering. The architecture the series defends covers more than that. Classification at ingestion, field extraction at scale, versioning, SQL aggregation, evaluation, security: several of these are not RAG in any standard sense. The SQL agent of Article 17 isn’t RAG at all; it is the point where retrieval ends and data systems take over. The follow-up volume adds translation, summarization, side-by-side comparison, redaction; these are also not RAG. “Document Intelligence” names the broader work; “RAG” is one of its modes, specifically the question-answering one.\n![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/image-239-1024x521.png)\n_Volume 1: deep on RAG-QA over PDFs. Volume 2: other tasks, same discipline - Image by author_\n### 2.2 “Enterprise” as an architectural constraint\nThe _Enterprise_ qualifier is not a market segment. It is a constraint. The corpus is controlled, not the open web. The expert is in the loop, and the system amplifies what they already know. The audit trail is mandatory because every answer can be challenged. The dispatcher is deterministic because reproducibility matters. Open-domain assistants make different trade-offs. The series is for engineers building inside that constraint, and every architectural choice in it follows from it.\n### 2.3 The shape of the corpus the series handles\nThe series’ main case is a corpus of **homogeneous, independent documents** : a few thousand to a few hundred thousand PDFs of the same type. When the corpus mixes several types, the first move is to classify into groups (Article 15), then run a homogeneous pipeline per group. Each document is read on its own ; the corpus index sits on top of all of them.\nA **case file** (a credit application, a contract renewal, an insurance claim) is a small bundle of heterogeneous PDFs about one entity. The series stays on PDFs throughout, so a handful of small files can simply be concatenated and treated as a single document. This is where the table of contents pays off : several PDFs, each with its own TOC, read like one larger document with nested sections after concatenation, and the retrieval brick (Article 7) already knows how to navigate it. The follow-up volume builds proper case-file routing with per-document-type signals when the bundle gets too varied or too large to glue together.\nThe harder shape is **many case files, many document types per file** : hundreds of cases, each with five to fifty heterogeneous documents inside. The orchestration on top of that exceeds what a single corpus index alone offers. The series names the case for honesty about scope and leaves the full treatment to the follow-up volume ; the primitives built in Parts IV-V carry over.\nIf your archive is one of the homogeneous shapes, the series covers it end to end. If it is case-file shaped, expect this series to take you most of the way, and the follow-up volume to finish the job.\n## 3. What this series is\n**Enterprise Document Intelligence** is a brick-by-brick series for engineers and data scientists building RAG on enterprise documents: contracts, technical reports, regulatory filings, where a wrong answer triggers a regulatory finding, a contract dispute, or a refund to a client. The series focuses on **PDF as the document format** , the dominant form for the documents enterprises actually want to query. Other formats (Word, Excel, PowerPoint, email) need their own parsing and structure logic and are covered by follow-up work.\nThe “amplify the expert” stance translates into concrete architectural choices the series defends, each tied to specific articles:\n  * **Deterministic dispatchers over autonomous agents.** Experts can audit a deterministic flow. They cannot audit an agent that decides on its own which tool to call, which sub-question to issue, and when to stop. The agent saves engineering effort on the demo and pays it back during incidents that can’t be reproduced because the routing was non-deterministic. The series defends a dispatched architecture where every routing decision is explicit, logged, and inspectable. Article 13 builds it.\n  * **Vector stores are a fallback, not a foundation.** Experts already know the keywords. The vector store earns its place when keyword retrieval fails: paraphrase, cross-language, polysemy, “vehicle parked at night” matching “car overnight.” It shouldn’t be where retrieval starts. On most enterprise corpora, structure-first retrieval (TOC, classification, expert keywords) outperforms cosine similarity. Articles 2 and 7 develop the case.\n  * **Expert dictionaries beat better embedding models.** Domain vocabulary is the single most valuable artifact in the system. The synonyms, the disambiguations, the cross-product equivalences (“franchise = deductible”, “ShieldPro Elite = top-tier homeowners plan”) cannot be recovered by an IDF formula or by embedding similarity; they have to be elicited from the people who use the vocabulary every day. Article 6 makes the dictionary the central object of question parsing.\n  * **Rerankers are mostly redundant in enterprise RAG.** They are worth their cost on one narrow shape (large generic candidate pool, no curated pipeline upstream). The architectural moves the series defends (expert vocabulary, structure-aware retrieval, classify-before-retrieve) make them redundant on the questions that matter. Article 2 bis runs the empirical test.\n  * **Refuse the “connect everything to a vector store” pattern.** That pattern is optimized for the hyperscaler’s business model, not the customer’s accuracy. Classify before indexing. Filter before retrieving. Aggregate with SQL when the question is statistical. RAG handles content lookup; SQL handles counting; the corpus index sits in between. Articles 14-17 make this the core of the corpus-scale architecture.\n\n\nBehind those choices sit three positive principles that recur in every article. The work is **pragmatic and expertise-driven** : every choice gets judged on whether it builds on the accumulated knowledge of the people who already understand the documents. The architecture is **pyramidal engineering** : four named bricks (parsing, question parsing, retrieval, generation), each one a handful of named functions with explicit inputs and outputs, so a senior engineer can trace a request end-to-end in minutes. The data is **relational at every brick** : parsing produces tables, question parsing produces tables, retrieval queries them, generation writes a typed row back, never raw strings at any junction.\n![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/image-240-1024x518.png)\n_One PDF in, eight linked tables out. Every later brick reads from these - Image by author_\nThree philosophical positions follow from the above and recur throughout: **embeddings are not magic** (Article 2), **RAG is not machine learning** (Article 3), **evaluation is per-failure-mode, not aggregate** (Article 20).\nThese positions come from building RAG in regulated industries: insurance, legal, financial services. They aren’t the only valid positions. They’re the ones that have held up in production where a wrong answer triggers a refund, a fine, or a lawsuit.\n## 4. What’s in the series\n### Part I: What works, what breaks\n_Build the minimal pipeline, watch where it cracks, reframe the discipline, then locate your own case before going further._ Each article sets up the next, so the four can be read in one sitting before tools or frameworks enter the picture.\n![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/image-241-1024x614.png)\n_The 5x5 case grid from Article 4. Place your problem before picking a technique - Image by author_\n  * **Article 1: A Minimal RAG, From PDF to Highlighted Answer.** The whole pipeline in ~100 lines. PDF in, structured JSON out, source lines highlighted on the PDF.\n\n\n  * **Article 2: Embeddings Aren’t Magic.** The predictable failure modes of RAG retrieval: negation, exact values, internal acronyms, topical proximity. Where the minimal version starts to break.\n  * **Article 2 bis (companion): Rerankers Aren’t Magic Either.** Cross-encoder rerankers fix the literal-token traps embeddings collapse, but share the same structural failure modes (negation, exact identifiers, listing, out-of-domain vocabulary). The editorial position: fallback for narrow cases, not a primary stage.\n  * **Article 3: RAG Is Not Machine Learning.** The misconception that costs RAG projects the most. RAG is search plus a generation layer, not a model to train.\n  * **Article 4: Which RAG Technique Fits Which Problem.** Diagnostic step before any technical choice. Position your problem on the 5×5 grid (document complexity × question control), then pick the simplest technique that works.\n\n\n### Part II: The four bricks\n_Parsing → question parsing → retrieval → generation._ The four bricks that carry the rest of the series. What sets the architecture apart from generic RAG: every brick produces **relational structured data** (linked DataFrames, typed rows), never raw strings. The pipeline can be inspected, replayed, and audited at every junction.\n![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/image-242-1024x523.png)\n_Brick 2 mirrors brick 1: one question, one row, satellite tables for keywords and scope - Image by author_\n  * **Article 5: The Rich Output of a Good RAG Parser.** Brick 1: lines, tables, images, columns, TOC, cross-references. Everything lost at parsing cannot be recovered downstream.\n\n\n  * **Article 5 bis (companion): When PyMuPDF Can’t See the Table. Parsing with Azure Document Intelligence.** Same eight DataFrames, second engine. Azure adds native table cells, OCR text inside figures, deterministic captions, and a TOC reconstructed from paragraph roles when no native bookmarks exist. The `parsing_method` column tracks per-row provenance so adaptive parsing can mix fitz and Azure on the same document.\n  * **Article 6: Question Parsing in RAG. Structure Before You Search.** Brick 2: a question is an unstructured input parsed into a relational set of tables, symmetric to document parsing.\n  * **Article 7: Why Embeddings Come Last in Production RAG Retrieval.** Brick 3: retrieval is filtering structured DataFrames, not searching free text. Embeddings are the fallback, not the default.\n  * **Article 8: Generation as Controlled Execution.** Brick 4: typed input (passages plus question), typed output (Pydantic). The schema is the contract; one prompt template per answer shape.\n\n\n### Part III: Pipelines on a single document\n_The whole pipeline assembled from Part II’s improvements, then extended._ Article 1 ran the minimal pipeline end-to-end; Part II then improved each brick in isolation. Article 9 closes that loop: same kind of demo as Article 1, on the same paper, with every Part II improvement wired in together. Articles 10-12 then add specific complexity patterns: adaptive parsing (where generation tells parsing to escalate), cross-references, listing. Article 13 assembles every pattern into the orchestrator, wires the feedback loops that bound iteration, and is where the team’s accumulated wisdom lives.\n![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/image-244-1024x395.png)\n_The 5x5 case grid from Article 4. Place your problem before picking a technique - Image by author_\n  * **Article 9: The Full Pipeline, End-to-End, Putting Part II Together.** Article 1 ran the pipeline minimally. Part II said how each brick can do better, in isolation. This article runs the same kind of demo as Article 1, on the same Transformer paper, with every Part II improvement wired in: richer parsing, expert-keyword question parsing with typo handling, retrieval methods combined (TOC plus keyword plus embedding with score fusion and an optional LLM arbiter), structured generation with the full schema. The gap between minimal and integrated, shown end-to-end on the same questions.\n  * **Article 10: Adaptive PDF Parsing.** Cheap parsing first; advanced parsing only where the question demands it. Adaptive escalation driven by generation feedback.\n  * **Article 11: How RAG Handles Cross-References in Contracts and Standards.** The real challenge of “complex” documents isn’t length, it’s interconnection. Two-hop retrieval that follows references.\n  * **Article 12: When RAG Has to Find All the Answers: Listing Questions.** “What are all the X?” The answer isn’t in one passage, it’s distributed. Sweep, not top-k, with explicit completeness signals.\n  * **Article 13: From One RAG Pipeline to Many: The Composite Pipeline Pattern.** Assembling every pattern into a single working system. The orchestrator and dispatcher are the team’s accumulated wisdom in code; bounded feedback loops, drift detection, and the full audit trail live here too.\n\n\n### Part IV: From one document to a whole archive\n_Naive embedding search over thousands of documents fails. The same four bricks still apply, but each one needs a structural index in front of it._ Article 14 sets the thesis with a minimal corpus pipeline run on five NIST PDFs, the kind of baseline that wastes four out of five LLM calls because nothing filtered the corpus first. Article 15 fixes the input side: a hierarchical cascade of questions populates a relational `corpus_index`, one row per document, columns for the searchable fields. Article 16 formalises the ontology that drives the cascade as five small tables hand-curated by the expert, and explains why a curated relational layer beats an LLM-extracted knowledge graph on every operational axis. Article 17 wires the query side: parse the question, filter the index, run the document-level pipeline only on the candidates the SQL agent returned.\n![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/image-245-1024x407.png)\n_The 5x5 case grid from Article 4. Place your problem before picking a technique - Image by author_\n  * **Article 14: Your RAG works on one PDF. Now make it work on ten thousand.** Part IV thesis. Five failure modes of naive vector RAG at scale, the mirror principle (4 bricks for one doc → 4 bricks for the corpus), a minimal `corpus_qa_baseline` run on five NIST PDFs that shows where the waste is.\n  * **Article 15: From a folder of PDFs to a queryable RAG corpus, one question at a time.** Brick 1 supercharged. A hierarchical cascade of questions populates the `corpus_index` per document, with two execution paths (regex on filename, single-doc pipeline otherwise) and nomenclature normalisation (raw extraction → canonical entity). Real runs on 24 NIST PDFs and 30 arXiv papers.\n  * **Article 16: Why your enterprise RAG needs an ontology, not a knowledge graph.** The keystone. The expert’s knowledge codified as five relational tables (cascade rules, concept keywords, concept relations, concept-to-doctype routing, nomenclature). Wins on auditability, cost, maintenance, freshness, ownership. Three sectors (NIST cybersecurity, arXiv NLP/IR, fictional insurance broker) prove the pattern transfers. Anti-GraphRAG is the consequence, not the slogan.\n  * **Article 17: How RAG answers a question across a corpus: SQL filter first, retrieval second.** Bricks 2-3-4 supercharged. The orchestrator detects intent (column / docs / hybrid), runs the SQL agent or filter-then-retrieve, dispatches generation. Three real runs on the NIST `corpus_index` close the architecture.\n\n\n### Part V: Operating in production\n_The system is built. Now run it for years._ The code architecture that lets several developers work in parallel, the storage layer that holds the replayable artifacts, per-failure-mode evaluation against a curated dataset (no aggregate-accuracy mirages), cost and latency measured as SQL aggregations on the same storage, and the security envelope wrapping all of it. RAG-specific concerns that generic ML-ops and generic security guides don’t address.\n![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/05/image-246-1024x582.png)\n_The four-layer package layout that survives years of evolution. Article 18 draws the function map - Image by author_\n  * **Article 18: Code Architecture for Enterprise RAG: Four Layers and a Function Map.** The package layout that survives years of evolution. Four layers (core, storage, annotation, pipeline) with unidirectional dependencies, one method per script, and the function map that anchors every brick to its dispatcher and sub-functions.\n  * **Article 19: Storage for Enterprise RAG: One Base for Everything You Measure.** Around thirty relational tables in five sub-schemas, anchored on two hash-based identifiers (`file_id`, `question_id`). Long format for storage, wide views for output. The `llm_raw_json` column and the `query_log` table are what evaluation, cost, and audit all read from.\n  * **Article 20: Evaluating Enterprise RAG: Measure the Process, Not the Model.** Per-failure-mode evaluation as a `pandas.groupby` on a results table joined from Article 19’s storage. Aggregate metrics lie ; per-question-type metrics tell the truth.\n  * **Article 21: Cost and Latency in Enterprise RAG: Measuring from the Storage.** Same source tables as Article 20, different aggregations. Tokens, latency, alerts, versioning. Self-hosted Ollama tier-1 benchmark on the broker domain.\n  * **Article 22: Security and Compliance for Enterprise RAG.** Closing chapter. Prompt injection through documents, tenant isolation, GDPR on derived data, audit trail, document-level access control, self-hosted confidentiality boundary : the enterprise-specific layer generic security guides don’t address.\n\n\n### Bonus articles\nEach one is a cross-cutting practical concern that touches several main articles but doesn’t belong inside any single part.\n  * **B01: Spelling Variants in RAG. Why Spell-Check Alone Isn’t Enough.** Forty years of classical spell-correction (Levenshtein, BK-tree, Soundex, SymSpell) handles most single-word typos. Embeddings and LLMs absorb the rest. The practical split for enterprise RAG: spell-correct the question against the corpus vocabulary at parse time; for documents, clean the canonical references once, leave volume noisy and design retrieval around the noise.\n  * **B02: FAQ as RAG. When You Get to Design the Corpus.** A controlled-corpus counterpoint to the rest of the series. Standard RAG assumes you inherit a chaotic corpus; FAQ flips it. Parsing becomes trivial, retrieval doubles as a cache, and few-shot prompting itself becomes a retrieval problem. Closes with the feedback loop that turns the FAQ into a living corpus driven by the question stream.\n  * **B03: When the RAG Says “I Don’t Know”. Justifying the Absence of an Answer.** A confident wrong answer is a bug. A bare “no answer” with no justification is almost as bad. Each of the four bricks owes the user one piece of evidence: what was parsed, which vocabulary was searched, which pages were swept, why nothing matched. The “I don’t know” becomes auditable instead of opaque.\n  * **B04: Tables in PDFs for RAG. Don’t Flatten the Grid.** Tables are where most RAG pipelines silently fail. A linear decision tree across table types does not work because the dimensions cross. The right pattern is four levels of representation (row-as-line in `line_df`, separate `table_df`, columnar with named and typed columns, columnar but heterogeneous), a per-table diagnostic on five orthogonal axes, and a handful of idempotent operations that move tables between levels. Most tables stay at the simplest level; only the few that need it pay the cost of escalation.\n\n\nEach article stands on its own. Each builds on the previous ones in a way that should feel natural: the same minimal pipeline from Article 1 grows into the architecture of Articles 18-19 and the security envelope of Article 22, with every addition motivated by a specific failure observed earlier.\n## 5. Who this is for\n**Engineers building RAG systems on enterprise documents.** Legal, insurance, financial services, regulated industries broadly, anywhere the cost of a wrong answer is measurable. If you’ve shipped a RAG system that worked on demos and broke on real users, this series is for you.\n**Data scientists who feel that ML intuitions don’t quite map to RAG.** They don’t. The series makes the difference clear and actionable.\n**Tech leads making architectural decisions.** When to use a vector database. When not to. When agentic patterns are worth their cost. When they don’t. When to invest in deeper parsing. The series is opinionated on these calls and explains the reasoning.\n## 6. Who this isn’t for\n**Teams without internal experts on the documents.** The series assumes you have, or can get to, the people who already know your corpus:\n  * lawyers who read the contracts,\n  * underwriters who set the deductibles,\n  * compliance officers who track the regulations.\n\n\nAlmost every architectural choice in the series amplifies that expertise. If you’re building open-domain QA on a corpus nobody internal understands, the choices here will not transfer. There are settings where general-purpose retrieval and autonomous agents make more sense; this series is not about those.\n**Researchers on the frontier.** This series is about production engineering, not novel methods. It cites recent research where relevant but doesn’t try to advance it.\n**Anyone looking for a magic framework.** The series is the opposite. It’s about understanding what’s underneath the frameworks well enough to make deliberate choices. Sometimes that means using a framework. Often it means writing a hundred lines of plain code that work better than what the framework gave you.\n## 7. What this series doesn’t cover\nThe series focuses on RAG over **PDF documents** : search and generation for question answering. It doesn’t cover other document formats (Word, Excel, PowerPoint, email), side-by-side document comparison, structured data alongside documents (databases), translation pipelines, large-scale summarization, document generation, or autonomous agents on documents.\nThese are real enterprise needs. They’re left out because they’re operationally different from RAG-on-PDF. Mixing them in produces the confused architectures the series is trying to help readers avoid.\nA follow-up volume, planned for after this one closes, picks up each on its own terms: other document formats (Word / Excel / PowerPoint / email), side-by-side comparison, translation, summarization, structured data alongside documents, document generation. Same engineering discipline, applied to different problem shapes.\n## 8. How to follow the series\nThe articles will publish daily, in order, starting with Article 1: _A Minimal RAG, From PDF to Highlighted Answer_.\nIt builds the entire pipeline in about a hundred lines of Python. It sets up every article that follows by surfacing the questions a working minimal version naturally raises.\nIf you’re building RAG in production and you think the industry’s defaults are wrong, this series is what to do about it.\n## Register Now to Continue Reading\n### Unlock Towards Data Science with a Free Account\nAll articles on Towards Data Science are available to registered users. Create a free account today to access this article and thousands more.\nRegister for freeSign in to your account\n* * *\n![](https://assets.insightmediagroup.io/media/1787657699750_yw6uqg.jpeg)\nWritten By\n## [Angela and Kezhan Shi](https://towardsdatascience.com/author/angela.shi/)\n[See all from Angela and Kezhan Shi](https://towardsdatascience.com/author/angela.shi/)\n[Artificial Intelligence](https://towardsdatascience.com/tag/artificial-intelligence/)[Rag](https://towardsdatascience.com/tag/rag/)\nShare This Article\n  * [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Ftowardsdatascience.com%2Fdocument-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale%2F&title=Enterprise%20Document%20Intelligence%3A%20A%20Series%20on%20Building%20RAG%20Brick%20by%20Brick%2C%20from%20Minimal%20to%20Corpus%20scale)\n  * [](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Ftowardsdatascience.com%2Fdocument-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale%2F&title=Enterprise%20Document%20Intelligence%3A%20A%20Series%20on%20Building%20RAG%20Brick%20by%20Brick%2C%20from%20Minimal%20to%20Corpus%20scale)\n  * [](https://x.com/share?url=https%3A%2F%2Ftowardsdatascience.com%2Fdocument-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale%2F&text=Enterprise%20Document%20Intelligence%3A%20A%20Series%20on%20Building%20RAG%20Brick%20by%20Brick%2C%20from%20Minimal%20to%20Corpus%20scale)\n\n\nTowards Data Science is a community publication. Submit your insights to reach our global audience and earn through the TDS Author Payment Program.\n[Write for TDS](https://towardsdatascience.com/submissions/)\n## Related Articles\n  * [![](https://assets.insightmediagroup.io/media/wp-content/uploads/2017/10/1e_lX4n83tw20Oa2LJQYCQQ.png)](https://towardsdatascience.com/understanding-events-with-artificial-intelligence-12e1ec3c5c9/)\n## [Understanding Events with Artificial Intelligence](https://towardsdatascience.com/understanding-events-with-artificial-intelligence-12e1ec3c5c9/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nWe have come across a lot of client requirements that boil down to using AI to understand events. Some systems need to classify events into...\n[Daniel Shapiro, PhD](https://towardsdatascience.com/author/lemaysolutions/)\nOctober 9, 20177 min read\n  * [![](https://assets.insightmediagroup.io/media/wp-content/uploads/2024/07/0gkdB-X_kmE-I7k2q-scaled.jpg)](https://towardsdatascience.com/enhancing-e-commerce-with-generative-ai-part-1-9e402fb30e7b/)\n## [Enhancing E-Commerce with Generative AI - Part 1](https://towardsdatascience.com/enhancing-e-commerce-with-generative-ai-part-1-9e402fb30e7b/)\n[Deep Learning](https://towardsdatascience.com/category/artificial-intelligence/deep-learning/)\nFrom Data to Product Recommendations\n[Mina Ghashami](https://towardsdatascience.com/author/mina.ghashami/)\nJuly 31, 202417 min read\n  * [![](https://assets.insightmediagroup.io/media/wp-content/uploads/2019/04/1omHJmOcNxlnvfee6Doxcdw.png)](https://towardsdatascience.com/pandas-in-the-premier-league-78f1d0c21b4f/)\n## [Pandas in the Premier League](https://towardsdatascience.com/pandas-in-the-premier-league-78f1d0c21b4f/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nHow can we get started with Pandas for Data Analysis\n[Stephen Fordham](https://towardsdatascience.com/author/stephenfordham/)\nApril 21, 20196 min read\n  * [![](https://assets.insightmediagroup.io/media/wp-content/uploads/2018/12/1ByrK6MDCI5KuhCJj-Pugfw-scaled.jpeg)](https://towardsdatascience.com/double-q-learning-the-easy-way-a924c4085ec3/)\n## [Double Q-Learning the Easy Way](https://towardsdatascience.com/double-q-learning-the-easy-way-a924c4085ec3/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nQ-learning (Watkins, 1989) is considered one of the breakthroughs in TD control reinforcement learning algorithm.\n[Ziad SALLOUM](https://towardsdatascience.com/author/zsalloum/)\nDecember 6, 20185 min read\n  * [![](https://assets.insightmediagroup.io/media/wp-content/uploads/2022/02/0eyn5wKUnyPShp7bs-scaled.jpg)](https://towardsdatascience.com/intuitions-in-high-dimensional-spaces-c22f0441ce19/)\n## [Intuitions in high-dimensional spaces](https://towardsdatascience.com/intuitions-in-high-dimensional-spaces-c22f0441ce19/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nCounter-intuitive geometric properties of high-dimensional spaces\n[Peter Barrett Bryan](https://towardsdatascience.com/author/peterbbryan/)\nFebruary 9, 20223 min read\n  * [![](https://assets.insightmediagroup.io/media/wp-content/uploads/2021/08/1AcYdr0u4A4ACHmStKFd2ow.png)](https://towardsdatascience.com/ai-concepts-and-real-life-36a51f1917ae/)\n## [AI concepts and real life](https://towardsdatascience.com/ai-concepts-and-real-life-36a51f1917ae/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nCapturing the Insights of how Artificial Intelligence concepts are nothing but basic human intellligence.\n[Tejasvi Sharma](https://towardsdatascience.com/author/contacttejasvi/)\nAugust 7, 20214 min read\n  * [![](https://assets.insightmediagroup.io/media/wp-content/uploads/2024/05/17o3xeyqskLBnQLrw5bBJ-w.png)](https://towardsdatascience.com/exploring-llms-for-icd-coding-part-1-959e48b58b9e/)\n## [Exploring LLMs for ICD Coding - Part 1](https://towardsdatascience.com/exploring-llms-for-icd-coding-part-1-959e48b58b9e/)\n[ChatGPT](https://towardsdatascience.com/category/artificial-intelligence/chatgpt/)\nBuilding automated clinical coding systems with LLMs\n[Anand Subramanian](https://towardsdatascience.com/author/anand.subu10/)\nMay 16, 202417 min read\n  * [![](https://assets.insightmediagroup.io/media/wp-content/uploads/2026/01/cdp_title_image_y1.jpeg)](https://towardsdatascience.com/evaluating-multi-step-llm-generated-content-why-customer-journeys-require-structural-metrics/)\n## [Evaluating Multi-Step LLM-Generated Content: Why Customer Journeys Require Structural Metrics](https://towardsdatascience.com/evaluating-multi-step-llm-generated-content-why-customer-journeys-require-structural-metrics/)\n[Large Language Models](https://towardsdatascience.com/category/artificial-intelligence/large-language-models/)\nHow to evaluate goal-oriented content designed to build engagement and deliver business results, and why structure matters.\n[Diana Schneider](https://towardsdatascience.com/author/diana.schneider/)\nJanuary 22, 202611 min read\n  * [![](https://assets.insightmediagroup.io/media/wp-content/uploads/2021/11/0qtCP3Yhc0w_XEZ8L.jpg)](https://towardsdatascience.com/end-to-end-machine-learning-project-telco-customer-churn-90744a8df97d/)\n## [End-to-end machine learning project: Telco customer churn](https://towardsdatascience.com/end-to-end-machine-learning-project-telco-customer-churn-90744a8df97d/)\n[Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/)\nAnalyzing IBM telecommunications data (Kaggle dataset)\n[Amanda Iglesias Moreno](https://towardsdatascience.com/author/amandaiglesiasmoreno/)\nNovember 23, 202119 min read\n\n\n  * [YouTube](https://www.youtube.com/c/TowardsDataScience)\n  * [X](https://x.com/TDataScience)\n  * [LinkedIn](https://www.linkedin.com/company/towards-data-science/)\n  * [Threads](https://www.threads.net/@towardsdatascience)\n  * [Bluesky](https://bsky.app/profile/towardsdatascience.com)\n\n\n[](https://towardsdatascience.com/)\nYour home for data science and AI. The world's leading publication for data science, data analytics, data engineering, machine learning, and artificial intelligence professionals.\nSubscribe to Our Newsletter[Write For TDS](https://towardsdatascience.com/submissions/)•[About](https://towardsdatascience.com/about-towards-data-science-d691af11cc2f/)•[Advertise](https://contact.towardsdatascience.com/advertise-with-towards-data-science)•[Privacy Policy](https://towardsdatascience.com/privacy-policy/)•[Terms of Use](https://towardsdatascience.com/website-terms-of-use/)\n© Insight Media Group, LLC 2026•[The New Stack](https://thenewstack.io)•[roadmap.sh](https://roadmap.sh)•[Creator Network](https://insightmediagroup.io/creator-network)\n####  Recommended Articles \nClose\n  * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607686/image?etag=1782161464448&width=500&height=500) How Relevance Models Foreshadowed Transformers for NLP ](https://towardsdatascience.com/how-relevance-models-foreshadowed-transformers-for-nlp/ \"How Relevance Models Foreshadowed Transformers for NLP\")\n  * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607639/image?etag=1781250125848&width=500&height=500) Javascript Fatigue: HTMX Is All You Need to Build ChatGPT — Part 1 ](https://towardsdatascience.com/javascript-fatigue-you-dont-need-js-to-build-chatgpt/ \"Javascript Fatigue: HTMX Is All You Need to Build ChatGPT — Part 1\")\n  * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607930/image?etag=1782124566054&width=500&height=500) The Subset Sum Problem Solved in Linear Time for Dense Enough Inputs ](https://towardsdatascience.com/subset-sum-problem-solved-in-linear-time-for-dense-enough-inputs/ \"The Subset Sum Problem Solved in Linear Time for Dense Enough Inputs\")\n  * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/3660/image?etag=1780176246070&width=500&height=500) Does Your Company Have a Data Strategy? ](https://towardsdatascience.com/does-your-company-have-a-data-strategy-e8944dbec4ae/ \"Does Your Company Have a Data Strategy?\")\n\n\n",
  "body_base_path": "attachments/b5c9287f2048/pages/",
  "body_markdown_path": "attachments/b5c9287f2048/pages/archived-body.md",
  "local_html": "attachments/b5c9287f2048/pages/archived-body.html",
  "body_source": "prior_capture"
}