Retrieval-augmented generation, usually shortened to RAG, is one of the most widely used ways to ground an enterprise artificial intelligence system in company data. So when an enterprise AI project stalls, the post-mortem often blames the RAG setup: the embeddings, the chunking, the model. Sometimes the more precise finding is different. The requirements were never written down in the first place. A RAG system, however well built, can only ground its answers in the documents it can reach. Asked about a requirement nobody recorded, the retriever finds nothing, and what happens next is a design choice: a well-designed system can surface the uncertainty or ask for the missing requirement, while a poorly designed one fills the gap with an inference that reads exactly like a grounded fact. Either way, no system can establish stakeholder intent that was never expressed; validating the gap still takes a person. That is a structural limit of grounding, not a product defect, and confusing the two is how teams end up confident, fast, and wrong.
This post separates the three layers of project knowledge a forward deployed engineer actually works with, shows what RAG covers and what it cannot, and ends with a checklist for evaluating any RAG platform against an incomplete requirement set.
The three layers of project knowledge
The first layer is documented facts: contracts, statements of work, bills of material, specifications, historical quotes, process documents, and the email threads that made it into files. This is the layer RAG was built for.
The second layer is conversation context: the pricing rule agreed on a call, the exception a plant manager mentioned during a site visit, the reason a previous vendor was dropped. This context exists, but it lives in people’s heads and meeting rooms, not in the document store a RAG system indexes.
The third layer is unresolved questions: the discount-approval policy nobody has decided yet, the integration owner IT has not named, the acceptance criterion the business team will know when they see it. These requirements do not exist anywhere. They are not missing documents; they are pending decisions.
An FDE’s job, as current role descriptions from firms like Sia and Alltech make explicit, spans all three layers: retrieval and knowledge grounding, integration and adoption, and turning ambiguous business intent into governed, testable delivery. Treating the first layer as the whole job is where projects quietly go wrong.
How RAG works, and what it does well
RAG is genuinely good at its layer. A typical RAG pipeline pairs semantic search technologies with a language model’s output generation. It chunks the document corpus, embeds the chunks in a vector database, retrieves the passages most relevant to the user query, and has the model generate an answer from those passages instead of from whatever it retained from its original training. Point RAG at a well-organized corpus and it will find the relevant clause, summarize the specification, and cite the source with clear attribution. For documented facts this is a real productivity gain, and it is why RAG has become a standard architecture for grounding an enterprise assistant.
But notice what the mechanism is: retrieve, then generate. If the answer was never written down, there is nothing to retrieve. A better embedding model, a larger context window, a fresher vector database, or a knowledge graph layered on top of the knowledge library does not change what the corpus contains. The capabilities of LLMs improve how well you search and present what you have; generation can invent a plausible answer, but it cannot turn an unwritten requirement into a documented one. This ceiling holds whether the stack is a fully-managed service or a hand-rolled vector database behind a language model API.
The confusion is understandable. Grounding an AI assistant in enterprise data visibly reduces hallucination about documented facts, the classic failure of a language model answering from memory, and that improvement reads as “the system understands our business.” A language model with billions of parameters still only knows what was written down in its training data, and the client’s unwritten requirements were never in it. A RAG system understands the written record. The written record is not the business.
A worked example: RAG against an incomplete requirement set (synthetic)
Take a manufacturing enquiry-to-quote process. An RFQ arrives with a drawing package and a bill of material. You point a RAG system at the client’s document store and ask it to prepare the quote.
The documented facts RAG finds: the BOM, two historical quotes for similar assemblies, and the standard terms.
The conversation context RAG misses: during last quarter’s review call, the client agreed that any line item without a current drawing revision gets flagged rather than quoted. Nobody wrote that into a document, so no retrieval step can surface it.
The unresolved question RAG cannot answer: the client’s new discount-approval policy is still undecided. Sales wants one threshold; finance wants another. There is no document because there is no decision yet.
A RAG system without that gap handling, doing its retrieval job perfectly, produces a quote draft that looks complete. The missing pricing rule and the undecided policy are invisible in the output because they were invisible in the input. This example is illustrative, but the pattern is a familiar one: the most dangerous gaps are the ones that leave no hole in the document set.
A delivery workflow handles the same RFQ differently. The BOM and historical quotes come through as source-linked facts, which is the part RAG does well. The drawing-revision rule appears because a consented conversation was captured as project context. The discount policy appears as an open question with a named owner, blocking final sign-off instead of being silently filled in.
The RAG failure mode that matters
The risk with RAG is not that it returns nothing for a given user input. The risk is that it returns a fluent, confident answer built on an incomplete record. For a smart chatbot answering employee questions, that is a minor embarrassment. In a delivery workflow, a quote, a compliance check, or a statement of work, it is a defect with a signature on it.
So the evaluation question for a RAG platform changes. Not “does the system answer our questions?” but “does the system show which layer each part of the answer comes from?”
How to evaluate a RAG platform for delivery work
The checks that matter when evaluating a RAG platform for delivery work, whether you are considering prebuilt ML solutions or a platform like BuLLM, DigiBull AI’s FDE acceleration platform:
- Source separation. Does the system distinguish documented facts from assumptions it generated? Every claim in the output should trace to a retrieved source or be marked as an assumption, with source attribution preserved from the vector database entry to the final answer.
- Gap visibility. Can the RAG system say, for a given user query, that the answer is not in any document it can reach? An explicit unknown is worth more than a plausible answer delivered with absolute confidence.
- Conversation capture. Is there a consented path for decisions made in meetings to become project context, with the same source discipline as documents? We covered this in our post on conversations as project context.
- Decision routing. When a requirement does not exist yet, does it become an open question with a named owner, or does the model quietly fill it in? Scope approval is a workflow problem, not a reminder problem.
- Human gate before action. Is there a review point where a person sees the facts, the assumptions, and the open questions before the output is used?
A platform that passes these checks treats RAG as one layer of a delivery workflow. A platform that fails them treats RAG as the whole product.
Where this leaves RAG
None of this argues against RAG as a technique. It argues for putting RAG in its place. Documented facts should be retrieved, grounded, and cited; that layer should be boring and reliable. Conversation context should be captured deliberately, with consent and source references. Unresolved questions should be made visible and routed to the people who can actually decide them.
Better embeddings and broader training data sources do not change this, because the gap was never in the model. The teams that get enterprise AI delivery right are not the ones with the best RAG search over the first layer. They are the ones whose workflows make the second and third layers explicit, so that the confident, well-cited answer is also a complete one.
Frequently asked questions about RAG limitations
What are the limitations of RAG systems?
The core limitation of RAG is structural: a RAG system can only ground answers in documents that exist and are reachable. If a requirement lives in a conversation, or has not been decided at all, no retrieval pipeline can surface it; the model can still invent an answer, but an inference is not a recovered requirement. Retrieval quality, better semantic search technologies, vector database tuning, and prompt engineering all improve answers about documented facts; none of them creates the missing record.
Is RAG deprecated?
No. RAG remains widely used for grounding a language model in enterprise data, and for documented facts it is still the most practical architecture available. What is deprecated is the idea that RAG alone constitutes an enterprise AI delivery: the workflow around it, conversation capture, decision routing, and human review, is what makes the retrieved answer safe to act on.
What is an enterprise RAG system?
An enterprise RAG system is retrieval-augmented generation pointed at a company’s own corpus rather than the training data sources a model learned from: contracts, specifications, emails, and process documents, usually indexed in a vector database with source attribution back to the original files. The enterprise part is not the index; it is the governance: consent, access control, and a record of which layer each answer came from.
If you are evaluating a RAG platform against a real process, bring the requirement list and mark which entries live in documents, which live in conversations, and which do not exist yet. That map is the fastest honest test of any RAG system. If you would like a second pair of eyes on it, book a working session with our team.
