![Revisit consent button](../images/body-df29beacd7496220cc94.svg) We value your privacy We 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. Customise Reject All Accept All Customise Consent Preferences ![](../images/body-2159bb67f3de8ad870eb.svg) We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below. The 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 NecessaryAlways Active Necessary 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. * Cookie BCTempID * Duration 10 minutes * Description No description available. * Cookie __cf_bm * Duration 1 hour * Description This cookie, set by Cloudflare, is used to support Cloudflare Bot Management. * Cookie AWSALBCORS * Duration 7 days * Description Amazon Web Services set this cookie for load balancing. * Cookie _cfuvid * Duration session * Description Cloudflare sets this cookie to track users across sessions to optimize user experience by maintaining session consistency and providing personalized services * Cookie li_gc * Duration 6 months * Description Linkedin set this cookie for storing visitor's consent regarding using cookies for non-essential purposes. * Cookie __hssrc * Duration session * Description This 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. * Cookie __hssc * Duration 1 hour * Description HubSpot sets this cookie to keep track of sessions and to determine if HubSpot should increment the session number and timestamps in the __hstc cookie. * Cookie wpEmojiSettingsSupports * Duration session * Description WordPress 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. * Cookie BCSessionID * Duration 1 year 1 month 4 days * Description Blueconic sets this cookie as a unique identifier for the BlueConic profile. * Cookie _octo * Duration 1 year * Description No description available. * Cookie logged_in * Duration 1 year * Description No description available. * Cookie __Secure-YEC * Duration past * Description YouTube sets this cookie to stores the user's video player preferences using embedded YouTube video * Cookie __eoi * Duration 6 months * Description Description is currently not available. * Cookie AWSALBTGCORS * Duration 7 days * Description No description available. * Cookie login-status-p * Duration past * Description Description is currently not available. * Cookie AWSALBTG * Duration 7 days * Description No description available. * Cookie csrf_token * Duration session * Description No description available. * Cookie token_v2 * Duration 1 day * Description Description is currently not available. * Cookie D * Duration 1 year * Description Description is currently not available. * Cookie PHPSESSID * Duration session * Description This 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. * Cookie VISITOR_PRIVACY_METADATA * Duration 6 months * Description YouTube sets this cookie to store the user's cookie consent state for the current domain. * Cookie cookietest * Duration session * Description The cookietest cookie is typically used to determine whether the user's browser accepts cookies, essential for website functionality and user experience. * Cookie __Host-airtable-session * Duration 1 year * Description This cookie is used to enable us to integrate the services of Airtable. * Cookie __Host-airtable-session.sig * Duration 1 year * Description This cookie is used to enable us to integrate the services of Airtable. * Cookie m * Duration 1 year 1 month 4 days * Description Stripe sets this cookie for fraud prevention purposes. It identifies the device used to access the website, allowing the website to be formatted accordingly. * Cookie BIGipServer* * Duration session * Description Marketo 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. * Cookie __cfruid * Duration session * Description Cloudflare sets this cookie to identify trusted web traffic. * Cookie _GRECAPTCHA * Duration 6 months * Description Google Recaptcha service sets this cookie to identify bots to protect the website against malicious spam attacks. * Cookie __Secure-YNID * Duration 6 months * Description Google cookie used to protect user security and prevent fraud, especially during the login process. * Cookie cookieyes-consent * Duration 1 year * Description CookieYes 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. Functional Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features. * Cookie lidc * Duration 1 day * Description LinkedIn sets the lidc cookie to facilitate data center selection. * Cookie brw * Duration 1 year * Description No description available. * Cookie brwConsent * Duration 5 minutes * Description Description is currently not available. * Cookie WMF-Uniq * Duration 1 year * Description Description is currently not available. * Cookie loom_anon_comment * Duration 1 year * Description No description available. * Cookie loom_referral_video * Duration session * Description Description is currently not available. * Cookie VISITOR_INFO1_LIVE * Duration 6 months * Description A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface. * Cookie yt-remote-connected-devices * Duration Never Expires * Description YouTube sets this cookie to store the user's video preferences using embedded YouTube videos. * Cookie ytidb::LAST_RESULT_ENTRY_KEY * Duration Never Expires * Description The 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. * Cookie yt-remote-device-id * Duration Never Expires * Description YouTube sets this cookie to store the user's video preferences using embedded YouTube videos. * Cookie yt-remote-session-name * Duration session * Description The yt-remote-session-name cookie is used by YouTube to store the user's video player preferences using embedded YouTube video. * Cookie yt-remote-fast-check-period * Duration session * Description The yt-remote-fast-check-period cookie is used by YouTube to store the user's video player preferences for embedded YouTube videos. * Cookie yt-remote-session-app * Duration session * Description The yt-remote-session-app cookie is used by YouTube to store user preferences and information about the interface of the embedded YouTube video player. * Cookie yt-remote-cast-available * Duration session * Description The yt-remote-cast-available cookie is used to store the user's preferences regarding whether casting is available on their YouTube video player. * Cookie yt-remote-cast-installed * Duration session * Description The yt-remote-cast-installed cookie is used to store the user's video player preferences using embedded YouTube video. * Cookie cp_session * Duration 3 months * Description Codepen sets this cookie for Help systems found in the website. * Cookie loid * Duration 1 year 1 month 4 days * Description This cookie is set by the Reddit. The cookie enables the sharing of content from the website onto the social media platform. Analytics Analytical 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. * Cookie __hstc * Duration 6 months * Description Hubspot 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). * Cookie hubspotutk * Duration 6 months * Description HubSpot 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. * Cookie _ga * Duration 1 year 1 month 4 days * Description Google 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. * Cookie _ga_* * Duration 1 year 1 month 4 days * Description Google Analytics sets this cookie to store and count page views. * Cookie __Host-psifi.analyticsTrace * Duration 6 hours * Description Description is currently not available. * Cookie __Host-psifi.analyticsTraceV2 * Duration 6 hours * Description Description is currently not available. * Cookie _gh_sess * Duration session * Description GitHub sets this cookie for temporary application and framework state between pages like what step the user is on in a multiple step form. * Cookie YSC * Duration session * Description YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages. * Cookie ajs_anonymous_id * Duration 1 year * Description This cookie is set by Segment to count the number of people who visit a certain site by tracking if they have visited before. * Cookie vuid * Duration 1 year 1 month 4 days * Description Vimeo installs this cookie to collect tracking information by setting a unique ID to embed videos on the website. Performance Performance 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. * Cookie AWSALB * Duration 7 days * Description AWSALB is an application load balancer cookie set by Amazon Web Services to map the session to the target. * Cookie acq * Duration past * Description Description is currently not available. * Cookie acq.sig * Duration past * Description Description is currently not available. * Cookie ptc * Duration 2 years * Description No description available. Advertisement Advertisement 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. * Cookie muc_ads * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to collect user behaviour and interaction data to optimize the website. * Cookie guest_id_marketing * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to identify and track the website visitor. * Cookie guest_id_ads * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to identify and track the website visitor. * Cookie personalization_id * Duration 1 year 1 month 4 days * Description Twitter 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. * Cookie guest_id * Duration 1 year 1 month 4 days * Description Twitter 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. * Cookie bcookie * Duration 1 year * Description LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser IDs. * Cookie __Secure-ROLLOUT_TOKEN * Duration 6 months * Description YouTube 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. * Cookie yt.innertube::nextId * Duration Never Expires * Description YouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen. * Cookie yt.innertube::requests * Duration Never Expires * Description YouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen. * Cookie session_tracker * Duration session * Description This cookie is set by the Reddit. This cookie is used to identify trusted web traffic. It also helps in adverstising on the website. * Cookie edgebucket * Duration session * Description Reddit sets this cookie to save the information about a log-on Reddit user, for the purpose of advertisement recommendations and updating the content. * Cookie did * Duration 1 year * Description Arbor sets this cookie to show targeted ads to site visitors.This cookie expires after 2 months or 1 year. Uncategorised Other uncategorised cookies are those that are being analysed and have not been classified into a category as yet. No cookies to display. Reject All Save My Preferences Accept All Toggle Search[](https://towardsdatascience.com/)Toggle Mobile Navigation [](https://towardsdatascience.com/) Publish AI, ML & data-science insights to a global community of data professionals. Sign in[Submit an Article](https://write.insightmediagroup.io) [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/) * * * [Write For TDS](https://towardsdatascience.com/submissions/) [LinkedIn](https://www.linkedin.com/company/towards-data-science/)[X](https://x.com/TDataScience)Toggle Search [Large Language Model](https://towardsdatascience.com/category/large-language-model/) # Amplify the Expert: A Philosophy for Building Enterprise RAG Enterprise Document Intelligence [Vol.1 #M1] - The thesis behind every architectural choice in this series [Angela and Kezhan Shi](https://towardsdatascience.com/author/angela.shi/) June 26, 202617 min read ![](../images/000.jpg) [Photo](https://www.pexels.com/photo/17619961/) by Thắng-Nhật Trần, via Pexels. This article is a manifesto of [Enterprise Document Intelligence](https://towardsdatascience.com/document-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale/), a series that builds an enterprise RAG system from four bricks: parsing, question parsing, retrieval, and generation. Amplify the expert: the thesis behind every architectural choice in the series. ![](../images/001.png) _where this article fits in the series: a manifesto alongside the numbered spine - Image by author_ 📓 **Runnable notebooks are on GitHub** : [doc-intel/notebooks-vol1](https://github.com/doc-intel/notebooks-vol1). Learn this step by step with the interactive [AI Engineer](https://roadmap.sh/ai-engineer) roadmap. ![](../images/002.png) _The public companion-code repo at doc-intel/notebooks-vol1 - Image by author_ If you have to remember one idea from this series, it is this: enterprise RAG amplifies the expert. It does not replace them. This piece sets down the thesis up front, before the techniques start, because every later article derives from it. Most architectural mistakes in production RAG follow from forgetting this. Once you accept it, the rest of the series stops being a catalog of techniques and starts looking like a coherent argument. ## 1. The thesis in one sentence **This series is about building RAG systems that amplify enterprise experts working with their own documents, not about building general-purpose document intelligence that replaces them.** The premise sounds modest but it changes most architectural choices. The system’s job is to scale judgment that already exists in human form: the lawyer who has read a thousand contracts, the underwriter who reaches for the deductible clause on reflex, the compliance officer who knows which sentence the auditor will ask about. Those people are the source of truth. The system handles volume, finds passages in seconds, compares documents systematically. It does not pretend to be the expert. Every other position the series defends derives from this thesis. Vector stores are a fallback because the expert already knows the keywords. Deterministic dispatchers beat autonomous agents because the expert needs to audit what happened. Expert dictionaries beat fine-tuned embeddings because the expert’s vocabulary is richer than any IDF formula or vector space could capture. ## 2. The gap between two camps **Most enterprises run two parallel realities on the same documents: an opaque vector-store pipeline the IT camp built, and an expert who still searches with Ctrl+F because nothing the IT camp shipped earned their trust. The series sits in the bridge between the two.** ![](../images/003.png) _The two camps and the bridge the series sits in - Image by author_ On the **IT side** , the camp told by vendors and conference talks to chunk every document, push it into a vector store, embed every query, and trust that cosine similarity will find the right passage. They build the system, they run it, and if you ask them precisely why a given chunk came back, very few can answer. The architecture is opaque even to the people who deployed it. On the **expert side** , decades of accumulated reading. Lawyers who have read a thousand contracts. Underwriters who have priced ten thousand policies. Compliance officers who can name the clause an auditor will ask about before the auditor walks in. Ask them how they search a document. The honest answer is almost always the same. They open the PDF, hit Ctrl+F, type a keyword they know works in their corpus, find the passage. If the keyword misses, they go to the table of contents, locate the right section, scan it line by line. That is the retrieval method that decades of expertise has converged on. The gap is not benign. The IT-camp system is opaque even to the people who built it; the expert-camp method is precise but does not scale. The series’s natural move is to bring them together: take the method the expert already trusts (keyword search anchored on real vocabulary, then TOC navigation when keywords miss) and use the LLM to scale it. LLMs are now strong enough that the retrieval stage no longer has to be clever to compensate. The 2022-era reflex of stacking embedding tricks on top of a weak generation model was solving a problem that no longer exists at the same intensity. Retrieval can stay close to the expert’s natural workflow without losing answer quality. Underneath the two camps sits a distinction worth stating plainly. There are two ways to answer a question, and they are not the same operation: * **From the model’s parametric memory.** You write the question, the model answers, one step. That is a chatbot, and for general knowledge it is enough. * **From a document.** Two phases that have to stay apart. First the passage is found, by keyword the way the expert reaches for Ctrl+F, not by handing the model the raw question. Only then is the question answered, against the document rather than against the model’s training. Enterprise work is the second case, and the rest of the series keeps the two phases apart. Mirroring the expert’s method this closely is not cosmetic. The point is not that vector stores are wrong everywhere; the point is that adopting a method the expert cannot recognize, on documents the expert knows by heart, is the fastest way to lose their trust. Without trust, the system does not get used, and a system that is not used has zero value regardless of how impressive its benchmarks look. ## 3. The historical parallel: machine learning ten years ago **RAG is repeating the enterprise ML wave of 2015 to 2020 verbatim. The same vendor-copying reflex, the same generic templates, the same failure modes. What worked then, and what will work for RAG now, is domain-specific work anchored on existing expertise.** ![](../images/body-14fa6ccbb461d0ca5a77.png) _The two enterprise waves share the same shape ten years apart - Image by author_ Between 2015 and 2020, enterprises tried to build ML systems by copying Google, DeepMind, and Facebook. _“Build a model that learns”_ was the slogan. Most enterprise ML projects from that era failed to reach production. Gartner put the figure at around 85% in 2019, and the practitioners who lived through the wave cite numbers in the same range. They failed for the same reasons every time. Enterprise companies do not have Google’s data scale. They do not have research teams. They do not have unlimited compute budgets. They do not have the open-ended use cases that justify general approaches. What ended up working in enterprise ML was domain-specific work. Actuarial forecasting tuned to insurance. Document classification calibrated on internal vocabulary. Risk scoring that exploited the variables domain experts had already identified as predictive. The systems that delivered value were the ones that built on existing expertise, not the ones that tried to learn it from scratch. RAG is repeating this exact pattern. Enterprises copy OpenAI, plug their data into generic managed RAG products, vectorize everything by default. The failure modes are the same as the ML decade: too much generality, not enough domain anchoring, no answer for the cases the benchmarks did not cover. The alternative is the same answer that worked ten years ago. Domain-specific RAG. Codify the expertise that already exists. Use the structure of documents the team already knows. Amplify the expert instead of bypassing them. This parallel matters for two reasons. It gives the argument historical depth (we have seen this movie). And it gives the argument constructive framing (we are not against OpenAI; we are saying the trajectory is known and the alternative is to build for our context, not theirs). ## 4. Where this applies (and where it does not) **The thesis is not universal. Four context properties decide whether this series is your guide. When all four hold, the architecture earns its place; when one is missing, a different stance fits better.** ![](../images/body-28f0b3c760a25c93dbcc.png) _The four conditions for this architecture and the verdict either way - Image by author_ The four properties are: * **The document context is known.** The system is deployed on a specific class of documents whose structure, vocabulary, and conventions are known: insurance contracts, medical records, legal agreements, regulatory filings, financial statements, technical specifications. Domain knowledge is an input to the system, not something to be discovered by it. * **Domain experts exist and are accessible.** The team building the system can talk to the people who use the documents day to day. Those experts know the vocabulary, where each kind of information lives, which keywords retrieve which clauses, which questions matter most. That expertise gets codified into the system rather than guessed at by a generic model. * **The goal is amplification, not replacement.** The expert continues to exist after the system ships. The system helps them handle volumes they could not process manually and find information in seconds instead of fifteen minutes. The stance is technical (current AI cannot reliably replace expert judgment on non-trivial cases) and operational (experts do not want to be replaced, and systems that pretend otherwise get rejected). * **The system must be auditable by the expert.** Retrievals must be traceable, answers must cite their sources, decisions must be explainable, behavior must be reproducible. A system the expert cannot audit is one the expert will not use. These four hold for most enterprise document intelligence work. Insurance brokers, law firms, hospitals, banks, government agencies, any organization where experts work with structured documents under regulatory scrutiny. **Where it does not.** Open-domain QA over the web, consumer chat, exploration of a corpus where no expert exists, settings where the questions are unbounded. There, general-purpose retrieval and autonomous agents make more sense. The trade-off shifts: you sacrifice audit and reproducibility, but you also do not have an expert who would have used either. Those are different problems and the architecture should be different. The series’s stance is defensible precisely because it admits where it does not apply. ## 5. The three founding principles **Amplifying the expert turns into code under three disciplines: choose techniques the expert recognises, build a pyramidal architecture a new engineer can trace in one sitting, and use relational tables (not strings) at every brick junction.** ![](../images/body-3108e15d4ac2a65ca653.png) _The three disciplines and the design test each one carries - Image by author_ * **Pragmatic, expertise-driven.** Every choice is judged on a single criterion: does it build on years of accumulated expertise from the people who already know these documents? If yes, it ships. If not, it is noise. The series has no patience for techniques that ignore the expert’s wisdom in favor of a generic model that re-learns it badly from scratch. Fine-tuning an embedding model on domain data is a fallback when expert vocabulary is unavailable, not a default move when the dictionary could be written in an afternoon by sitting with the underwriter. * **Pyramidal engineering, not a loose collection of tricks.** A production RAG system has to be readable, scalable, and maintainable five years from now. Four clearly named bricks at the top (parsing, question parsing, retrieval, generation), each decomposed into a handful of named functions, each function doing one thing on well-defined inputs and outputs. No orchestration loops (the kind where an LLM chooses the next step until it decides to stop), no hidden state, no _“the LLM figures it out”_. Concrete design test: a senior engineer joining the team should be able to trace a request from input to output by reading code alone, in one sitting, without an oral handoff. If that is not possible, the architecture has failed. Without this clarity, the system rots: every new feature breaks something old, every contributor gets lost, every audit takes weeks. * **Relational data at every brick.** Document data is unstructured, and you cannot do anything with unstructured data. So the series structures it, at every brick, into relational tables. Parsing turns the PDF into a set of linked DataFrames (`line_df`, `page_df`, `image_df`, `toc_df`, `span_df`, `object_registry`). Question parsing turns the user’s question into a relational set too (`question_df` plus satellites). Retrieval becomes a query on those structures. Generation structures its output: a typed Pydantic answer, line-level citations, self-assessment fields. The junctions between bricks are tables, not strings. String-soup at any junction produces half the debugging pain in production RAG. These three are not features. They are the discipline that makes the series’s specific architectural choices defensible across many years and many contributors. ## 6. The four bricks, through this philosophy **The four bricks (parsing, question parsing, retrieval, generation) are common to most RAG architectures. What is specific here is that each one mirrors something the expert does mentally and amplifies it on the axes a manual workflow cannot reach. Every later article in the series develops one of these four ideas in code.** ![](../images/body-13cbc713da29a4f6c57d.png) _Each brick mirrors an expert action and amplifies on one axis - Image by author_ **Parsing** mirrors how the expert scans a document on first read: grasp the topic, find the section list, spot where the numbers live. The parser does that scan once and keeps the result. Everything missed here cannot be recovered downstream, which makes parsing the most important choice in the pipeline. * [Article 5A (what to read in a PDF)](https://towardsdatascience.com/beyond-extract_text-the-two-layers-of-a-pdf-that-drive-rag-quality/): the document’s signals and one-paragraph summary * [Article 5B (the relational data model)](https://towardsdatascience.com/stop-returning-flat-text-from-a-pdf-the-relational-shape-rag-needs/): the linked tables the parser emits (`line_df`, `toc_df`, …) * heavier engines when `fitz` can’t see the structure: [5bis (Azure DI)](https://towardsdatascience.com/when-pymupdf-cant-see-the-table-parse-pdfs-for-rag-with-azure-layout/), [5ter (Docling)](https://towardsdatascience.com/parse-pdfs-for-rag-locally-with-docling-rich-tables-no-cloud-upload/), [5quater (vision)](https://towardsdatascience.com/vision-llms-are-pdf-parsers-too-reading-charts-and-diagrams-for-rag/), [5quinquies (EasyOCR)](https://towardsdatascience.com/parse-scanned-pdfs-for-rag-with-easyocr-free-ocr-gives-you-words-not-a-document/) * [Article 5sexies (image analysis)](https://towardsdatascience.com/making-a-pdfs-images-searchable-for-rag-without-paying-to-read-them-all/): images, searchable * [Article 5septies (TOC reconstruction)](https://towardsdatascience.com/reconstructing-the-table-of-contents-a-pdf-forgot-to-ship-so-rag-can-scope-by-section/): rebuild `toc_df` * Article 10 (adaptive parsing): pick the engine on demand * Article 11 (cross-references): when the answer says _“see Section X”_ **Question parsing** mirrors the Ctrl-F reflex: the expert starts by typing two or three keywords. The brick keeps that and amplifies it on two axes Ctrl-F can’t reach (co-occurrence and expert-dictionary expansion), then splits the question into a retrieval brief and a generation brief that downstream bricks consume separately. * [Article 6a (question parsing thesis)](https://towardsdatascience.com/question-parsing-in-rag-structure-before-you-search/): why a question needs parsing too * [Article 6b (the columns extracted)](https://towardsdatascience.com/what-the-question-parser-extracts-from-a-user-string-keywords-scope-shape-decomposition-clarification/): the five families of columns the parser fills * [Article 6c (dispatch)](https://towardsdatascience.com/dispatching-the-parsed-rag-question-chunk-strategy-model-tier-activations-audit/): columns to routing decisions * [Article 6bis (clarification loop)](https://towardsdatascience.com/when-rag-users-ask-vague-questions-clarify-once-learn-the-default/): one question when the input is too vague **Retrieval** mirrors the triage the expert does after Ctrl-F returns thirty hits: drop the off-topic ones, keep the few worth a second look. The brick does that at scale and keeps three things apart that _“top-k chunks”_ collapses, the anchor (where the match lands), the scope (what goes to generation), and the context (the surrounding the expert reads by reflex). The criterion is _“the set worth a second human pass”_ , not _“top-k by cosine”_. * Article 7 (retrieval): the frame * [Article 7A (retrieval as filtering)](https://towardsdatascience.com/retrieval-is-filtering-not-search-a-mental-model-for-enterprise-rag/): a filter on `line_df` and `toc_df` * Article 7B (anchor detection): parallel detectors, one LLM call at the end * Article 7C (the LLM arbiter): picks the final candidate, with reasons * Article 12 (listing): when the answer is _all_ the matches, not one **Generation** is where the discipline against fabrication lives: a faithful restatement of what the retrieved scope says plus the citation to verify it, never a paraphrase that drifts. The LLM fills a typed Pydantic schema (answer, line citations, `answer_found`, `confidence`, `caveats`) that the expert controls by writing the schema and the prompt. * Article 8a (the answer contract): the typed answer with citations and self-checks * Article 8b (prompt assembly): prompt + schema + trace from a parsed question * Article 8c (validation): the validator and the feedback loop that closes the pipeline * Article 13 (the workflow pipeline): wire the four upgraded bricks into one * Article 9 (the upgraded pipeline): the [Article 1 (minimal RAG)](https://towardsdatascience.com/baseline-enterprise-rag-from-pdf-to-highlighted-answer-enterprise-document-intelligence-vol-1-1/) baseline, upgraded brick by brick Every brick respects the same discipline: structured input, structured output, no string-soup at any junction. That makes the system queryable, auditable, replayable, and joinable across years of accumulated questions and answers. Part IV (Article 14 _the corpus problem_ , 15 _preparing the corpus_ , 16 _ontology_ , 17 _querying the corpus_) shows what the same four bricks become at corpus scale, with a SQL-shaped `corpus_index`, an ontology in five relational tables, and corpus-level QA. Part V (Article 18 _code architecture_ , 19 _storage_ , 20 _evaluation_ , 21 _cost & latency_, 22 _security_) makes the architecture operable across years. ## 7. What follows from the thesis **The series defends six counter-positions against the mainstream RAG playbook. They are not stylistic choices: each one follows mechanically from the thesis once the four context properties hold.** ![](../images/body-046f4fd43dc8597855fe.png) _Six condition-to-consequence rows derived from the four context properties - Image by author_ * If experts know the keywords, the **vector store cannot be the foundation**. It is the fallback for cases where the dictionary missed an alias. * If embeddings are useful for finding synonyms, they are a **discovery tool** whose output goes into the expert dictionary, not a production retriever queried on every call. [Article 2](https://towardsdatascience.com/embeddings-arent-magic-the-predictable-failure-modes-of-rag-retrieval-enterprise-document-intelligence-vol-1-2/) catalogues where embedding similarity wins and where it predictably breaks; [Article 2bis](https://towardsdatascience.com/rerankers-arent-magic-either-when-the-cross-encoder-layer-is-worth-the-cost-enterprise-document-intelligence-vol-1-2bis/) does the same for cross-encoders. * If retrieval is strong because it filters structured DataFrames built from expert vocabulary, the **reranker has no work to do** that the upstream filter has not already done. * If the expert must audit every answer, the **dispatcher must be deterministic and inspectable** , not an autonomous loop. Article 13 (the workflow pipeline) is the brick that holds this discipline. * If the corpus belongs to a specific business with specific documents, **vectorising everything indexes noise** ; structuring at ingestion produces signal that compounds. [Article 3](https://towardsdatascience.com/rag-is-not-machine-learning-and-the-ml-toolkit-solves-the-wrong-problem/) is the argument that _RAG is not machine learning, and the ML toolkit solves the wrong problem_ ; [Article 4](https://towardsdatascience.com/from-regex-to-vision-models-which-rag-technique-fits-which-problem/) maps techniques to problems on two axes (document complexity, question control); [Article 4bis](https://towardsdatascience.com/10-common-rag-mistakes-we-keep-seeing-in-production/) catalogues the ten production mistakes the field keeps repeating. The point of this piece is that these positions are not independent. They are one argument with six visible consequences. ## 8. Sources and further reading This epilogue is the philosophical anchor of the series. The framing of expert judgment as a renewable resource comes from Tetlock and Gardner (_Superforecasting_ , 2015). The tool-as-amplifier philosophy that maps directly to RAG architecture is from Norman (_The Design of Everyday Things_ , 1988). Anthropic’s [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) (Dec 2024) is the industry framing of when workflows win over agents. The classic short paper behind the _amplify-the-expert tiebreaker_ is Bainbridge’s _Ironies of Automation_ (1983): the more advanced the automation, the more the human contribution matters. Agentic patterns where the agent still uses the audited bricks the expert curated are follow-up work. **Same direction as the epilogue:** * Tetlock & Gardner, _Superforecasting: The Art and Science of Prediction_ , 2015. Expert judgment as a renewable resource; the _amplify the expert_ thesis treats domain experts the way Tetlock treats superforecasters. * Norman, _The Design of Everyday Things_ , 1988/2013. Tool-as-amplifier rather than tool-as-replacement; the philosophy applies to RAG architecture the same way it applies to door handles. * Anthropic, [_Building Effective Agents_](https://www.anthropic.com/research/building-effective-agents), December 2024. When LLM agents work and when deterministic workflows win; the decision matrix matches this series’ philosophy. * Carr, _The Glass Cage: How Our Computers Are Changing Us_ , W.W. Norton 2014. Cautionary book on automation that bypasses expert judgment; the broker-corpus stories in the series are concrete instances of Carr’s concerns. * Bainbridge, _Ironies of Automation_ , Automatica 1983. Classic short paper: the more advanced the automation, the more the human contribution matters. The philosophical backing for the amplify-the-expert tiebreaker. **Different angle, different context:** * Bostrom, _Superintelligence: Paths, Dangers, Strategies_ , Oxford University Press 2014. The strongest philosophical case for systems that aim past expert amplification toward full autonomy. The context is long-term AGI; this epilogue handles enterprise document work where experts are accessible and audit is required. * Yao et al., _ReAct: Synergizing Reasoning and Acting in Language Models_ , ICLR 2023 ([arXiv:2210.03629](https://arxiv.org/abs/2210.03629)). Agent reasons and acts without human-curated routing. The context is general-purpose tool-picking; developing this line on top of the audited bricks the expert maintains is follow-up work. **Earlier in the series:** * [Document Intelligence: series intro](https://towardsdatascience.com/document-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale/). What the series builds, brick by brick, and in what order. _Part I: What works, what breaks_ * [Baseline Enterprise RAG, from PDF to highlighted answer](https://towardsdatascience.com/baseline-enterprise-rag-from-pdf-to-highlighted-answer-enterprise-document-intelligence-vol-1-1/). The four-brick pipeline end to end: PDF in, highlighted answer out. * [Embeddings Aren’t Magic: The Predictable Failure Modes of RAG Retrieval](https://towardsdatascience.com/embeddings-arent-magic-the-predictable-failure-modes-of-rag-retrieval-enterprise-document-intelligence-vol-1-2/). Where embedding similarity wins (synonyms, typos, paraphrase), where it predictably breaks (unknown terms, negation, term-vs-answer relevance), and how to use it anyway. * [Rerankers Aren’t Magic Either: When the Cross-Encoder Layer Is Worth the Cost](https://towardsdatascience.com/rerankers-arent-magic-either-when-the-cross-encoder-layer-is-worth-the-cost-enterprise-document-intelligence-vol-1-2bis/). What a cross-encoder adds over bi-encoder embeddings, measured, and when it is worth the latency. * [RAG is not machine learning, and the ML toolkit solves the wrong problem](https://towardsdatascience.com/rag-is-not-machine-learning-and-the-ml-toolkit-solves-the-wrong-problem/). Why chunk-size sweeps and finetuning optimize the wrong thing; route by question type instead. * [From regex to vision models: which RAG technique fits which problem](https://towardsdatascience.com/from-regex-to-vision-models-which-rag-technique-fits-which-problem/). Two axes, document complexity and question control, that pick the technique for each case. * [10 common RAG mistakes we keep seeing in production](https://towardsdatascience.com/10-common-rag-mistakes-we-keep-seeing-in-production/). Ten production mistakes, organized brick by brick, with the fix for each. _Part II: The four bricks_ * [Beyond extract_text: the two layers of a PDF that drive RAG quality](https://towardsdatascience.com/beyond-extract_text-the-two-layers-of-a-pdf-that-drive-rag-quality/). The first half of the parsing brick: the document’s nature, signals, and summary. * [Stop returning flat text from a PDF: the relational tables RAG needs](https://towardsdatascience.com/stop-returning-flat-text-from-a-pdf-the-relational-shape-rag-needs/). The second half of the parsing brick: the relational tables every downstream brick reads. * [When PyMuPDF can’t see the table: parse PDFs for RAG with Azure Layout](https://towardsdatascience.com/when-pymupdf-cant-see-the-table-parse-pdfs-for-rag-with-azure-layout/). The same tables from Azure Layout: native table cells, OCR, paragraph roles. * [Parse PDFs for RAG locally with Docling: rich tables, no cloud upload](https://towardsdatascience.com/parse-pdfs-for-rag-locally-with-docling-rich-tables-no-cloud-upload/). The same tables computed locally with Docling: TableFormer cells, nothing leaves the machine. * [Vision LLMs are PDF parsers too: reading charts and diagrams for RAG](https://towardsdatascience.com/vision-llms-are-pdf-parsers-too-reading-charts-and-diagrams-for-rag/). Vision as a parser: the pictures become searchable text. * [Parse scanned PDFs for RAG with EasyOCR: free OCR gives you words, not a document](https://towardsdatascience.com/parse-scanned-pdfs-for-rag-with-easyocr-free-ocr-gives-you-words-not-a-document/). Where traditional OCR stops: text recovered, structure lost. * [Making a PDF’s images searchable for RAG, without paying to read them all](https://towardsdatascience.com/making-a-pdfs-images-searchable-for-rag-without-paying-to-read-them-all/). The image cascade: filter cheap, classify, describe only what is worth reading. * [Reconstructing the table of contents a PDF forgot to ship, so RAG can scope by section](https://towardsdatascience.com/reconstructing-the-table-of-contents-a-pdf-forgot-to-ship-so-rag-can-scope-by-section/). Rebuilding toc_df when the PDF prints a contents page but ships no outline. * [RAG questions need parsing too: turn the user’s string into briefs for retrieval and generation](https://towardsdatascience.com/question-parsing-in-rag-structure-before-you-search/). The thesis of question parsing: why a user string needs the same parsing as a document, and how it splits into a retrieval brief and a generation brief. * [What the question parser extracts from a user string: keywords, scope, shape, decomposition, clarification](https://towardsdatascience.com/what-the-question-parser-extracts-from-a-user-string-keywords-scope-shape-decomposition-clarification/). The five families of columns the parser reads straight from the user’s question, with the code that fills each one. * [Dispatching the parsed RAG question: chunk strategy, model tier, activations, audit](https://towardsdatascience.com/dispatching-the-parsed-rag-question-chunk-strategy-model-tier-activations-audit/). The decisions the parser makes on top of the user string, using the document’s profile: dispatch, activations, full schema, the audit trail (pipeline_trace.json), and a broker-corpus walkthrough. * [When RAG users ask vague questions: clarify once, learn the default](https://towardsdatascience.com/when-rag-users-ask-vague-questions-clarify-once-learn-the-default/). One focused clarification when the question is too vague, and the default learned from the answer. * [Retrieval is filtering, not search: a mental model for enterprise RAG](https://towardsdatascience.com/retrieval-is-filtering-not-search-a-mental-model-for-enterprise-rag/). Retrieval reframed as filtering on line_df and toc_df: anchors small, context large. * _Anchor detection for RAG: parallel detectors, then one LLM call at the end_ (link to come). Parallel anchor detectors: keyword always, embeddings alongside, one LLM call at the end. * _Letting an LLM pick the right RAG page: the arbiter pattern at the end of retrieval_ (link to come). The LLM arbiter: candidates ranked with reasons, one typed JSON out. * _Context engineering: the pipeline you have been building has a name_ (link to come). Context engineering named: the four bricks emit typed context, Lance Martin’s four strategies map to docintel primitives. ## Register Now to Continue Reading ### Unlock Towards Data Science with a Free Account All articles on Towards Data Science are available to registered users. Create a free account today to access this article and thousands more. Register for freeSign in to your account * * * ![](../images/body-249d024535392fb76067.jpeg) Written By ## [Angela and Kezhan Shi](https://towardsdatascience.com/author/angela.shi/) [See all from Angela and Kezhan Shi](https://towardsdatascience.com/author/angela.shi/) [Editor's Picks](https://towardsdatascience.com/tag/editors-pick/)[Document Processing](https://towardsdatascience.com/tag/document-processing/)[LLM Agents](https://towardsdatascience.com/tag/llm-agents/)[Rag](https://towardsdatascience.com/tag/rag/)[Rag Architecture](https://towardsdatascience.com/tag/rag-architecture/) Share This Article * [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Ftowardsdatascience.com%2Famplify-the-expert-a-philosophy-for-building-enterprise-rag%2F&title=Amplify%20the%20Expert%3A%20A%20Philosophy%20for%20Building%20Enterprise%20RAG) * [](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Ftowardsdatascience.com%2Famplify-the-expert-a-philosophy-for-building-enterprise-rag%2F&title=Amplify%20the%20Expert%3A%20A%20Philosophy%20for%20Building%20Enterprise%20RAG) * [](https://x.com/share?url=https%3A%2F%2Ftowardsdatascience.com%2Famplify-the-expert-a-philosophy-for-building-enterprise-rag%2F&text=Amplify%20the%20Expert%3A%20A%20Philosophy%20for%20Building%20Enterprise%20RAG) Towards Data Science is a community publication. Submit your insights to reach our global audience and earn through the TDS Author Payment Program. [Write for TDS](https://towardsdatascience.com/submissions/) ## Related Articles * [![](../images/004.jpg)](https://towardsdatascience.com/loop-engineering-for-rag-the-small-loops-inside-each-step-the-big-loops-across-the-pipeline/) ## [Loop Engineering for RAG: The Small Loops Inside Each Step, the Big Loops Across the Pipeline](https://towardsdatascience.com/loop-engineering-for-rag-the-small-loops-inside-each-step-the-big-loops-across-the-pipeline/) [Large Language Model](https://towardsdatascience.com/category/large-language-model/) Enterprise Document Intelligence [Vol.1 #13bis] - The four bricks return useful results most of the time. Loop engineering is what the system does the rest of the time: when retrieval misses, when generation fails the schema, when the listing comes back incomplete, when an API call times out. Three control surfaces (trigger, termination, recovery) and one rule that separates a useful loop from a spinning one [Angela and Kezhan Shi](https://towardsdatascience.com/author/angela.shi/) August 17, 202614 min read * [![](../images/005.jpg)](https://towardsdatascience.com/midyear-2025-ai-reflection/) ## [Midyear 2025 AI Reflection](https://towardsdatascience.com/midyear-2025-ai-reflection/) [Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/) Impressions on agentic AI progress and the AI-2027 Jobocalypse scenario [Marina Tosic](https://towardsdatascience.com/author/martosi/) July 16, 20256 min read * [![](../images/006.jpg)](https://towardsdatascience.com/another-article-on-ai-ethics-but-this-time-for-the-masses-c809e09e35e7/) ## [AI Ethics for the Everyday User - Why Should You Care?](https://towardsdatascience.com/another-article-on-ai-ethics-but-this-time-for-the-masses-c809e09e35e7/) [Artificial Intelligence](https://towardsdatascience.com/category/artificial-intelligence/) A beginner's guide to understanding the importance of ethics in artificial intelligence [Murtaza Ali](https://towardsdatascience.com/author/murtaza5152-ali/) January 29, 202513 min read * [![](../images/007.png)](https://towardsdatascience.com/quadrant-analysis-in-tableau-6a3ee42d26ff/) ## [Quadrant Analysis in Tableau](https://towardsdatascience.com/quadrant-analysis-in-tableau-6a3ee42d26ff/) [Data Visualization](https://towardsdatascience.com/category/data-science/data-visualization/) Learn how to analyze data in the form of a dynamic quadrant chart in Tableau. [Parul Pandey](https://towardsdatascience.com/author/pandeyparul/) January 27, 20216 min read * [![](../images/008.jpg)](https://towardsdatascience.com/long-context-isnt-free-i-built-a-safe-prompt-pruning-layer-that-makes-llm-systems-work/) ## [Long Context Isn’t Free — I Built a Safe Prompt-Pruning Layer That Makes LLM Systems Work](https://towardsdatascience.com/long-context-isnt-free-i-built-a-safe-prompt-pruning-layer-that-makes-llm-systems-work/) [Large Language Model](https://towardsdatascience.com/category/large-language-model/) Your prompt doesn't need to remember everything. It needs to remember what still matters. [Emmimal P Alexander](https://towardsdatascience.com/author/emmimalp.alexander/) July 11, 202620 min read * [![](../images/009.jpeg)](https://towardsdatascience.com/less-software-more-design-449175a34e59/) ## [Less Software, More Design](https://towardsdatascience.com/less-software-more-design-449175a34e59/) [Data Science](https://towardsdatascience.com/category/data-science/) Essential design strategies for improving your visualizations [Brian Perron, PhD](https://towardsdatascience.com/author/b-r-i-a-n/) February 15, 20229 min read * [![](../images/010.jpg)](https://towardsdatascience.com/retrieve-one-row-from-a-table-not-the-whole-table-row-level-chunks-for-rag/) ## [Retrieve One Row from a Table, Not the Whole Table: Row-Level Chunks for RAG](https://towardsdatascience.com/retrieve-one-row-from-a-table-not-the-whole-table-row-level-chunks-for-rag/) [Large Language Model](https://towardsdatascience.com/category/large-language-model/) Enterprise Document Intelligence [Vol.1 #7sexies] - The unit of retrieval doesn’t have to be a page or a paragraph. When the corpus carries tables, each body row with its column headers is a chunk in its own right, and it’s often the one row the reader asked about [Kezhan Shi](https://towardsdatascience.com/author/kezhanshi/) August 21, 202613 min read * [![](../images/011.png)](https://towardsdatascience.com/javascript-for-data-analysis-2e8e7dbf63a7/) ## [JavaScript for Data Analysis](https://towardsdatascience.com/javascript-for-data-analysis-2e8e7dbf63a7/) [Data Visualization](https://towardsdatascience.com/category/data-science/data-visualization/) With the web opening new frontiers in collaboration, the web's native language of JavaScript is the best choice for thinking with data. [Mike Bostock](https://towardsdatascience.com/author/mbostock/) May 25, 20214 min read * [![](../images/012.jpg)](https://towardsdatascience.com/three-kinds-of-rag-corpus-and-what-it-costs-to-build-for-the-wrong-one/) ## [Three Kinds of RAG Corpus, and What It Costs to Build for the Wrong One](https://towardsdatascience.com/three-kinds-of-rag-corpus-and-what-it-costs-to-build-for-the-wrong-one/) [Large Language Model](https://towardsdatascience.com/category/large-language-model/) Enterprise Document Intelligence [Vol.1 #14A] - Three questions tell you which shape a document collection has, and each shape wants a different architecture [Angela and Kezhan Shi](https://towardsdatascience.com/author/angela.shi/) August 20, 202617 min read * [YouTube](https://www.youtube.com/c/TowardsDataScience) * [X](https://x.com/TDataScience) * [LinkedIn](https://www.linkedin.com/company/towards-data-science/) * [Threads](https://www.threads.net/@towardsdatascience) * [Bluesky](https://bsky.app/profile/towardsdatascience.com) [](https://towardsdatascience.com/) Your home for data science and AI. The world's leading publication for data science, data analytics, data engineering, machine learning, and artificial intelligence professionals. Subscribe 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/) © Insight Media Group, LLC 2026•[The New Stack](https://thenewstack.io)•[roadmap.sh](https://roadmap.sh)•[Creator Network](https://insightmediagroup.io/creator-network) #### Recommended Articles Close * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607631/image?etag=1781543525510&width=500&height=500) Critical Mistakes Companies Make When Integrating AI/ML into Their Processes ](https://towardsdatascience.com/critical-mistakes-companies-make-when-integrating-ai-ml-into-their-processes/ "Critical Mistakes Companies Make When Integrating AI/ML into Their Processes") * [ ![](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") * [ ![](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") * [ ![](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")