RAG vs Knowledge Base: Which One Your Shop Is Missing
A knowledge base is your shop's documents. RAG is how someone finds the answer in them. How to tell which one you are missing before you pay for either.
A second-shift operator needs to know which revision of a work instruction is current. The one person who knows is the quality manager, who left at 4. Then a vendor demos an AI that answers questions from documents and cites the page, and it looks like the fix. Before you buy it, know that the demo is 2 things sold as one.
An AI knowledge base is the documents your shop keeps (SOPs, work instructions, prints, inspection records, the know-how somebody finally wrote down) plus a way to ask them a question in plain words and get an answer that names the document it came from. The documents are the knowledge base. RAG, short for retrieval-augmented generation, is the finding part: it pulls the passages that answer the question and has an AI model write the answer from them, with the source attached.
They are not competing options, and treating them as a choice is how shops end up paying for the half they already had. This post covers how to tell which half you are missing, and why buying the wrong one costs a year.
The plain-English version
A knowledge base is the organized body of what your operation knows. It is a thing you own and maintain. Its quality depends on whether the content is current, controlled, and complete.
RAG is a way of finding things. It finds the passages relevant to a question and hands them to a language model, which answers in plain language and cites where it got them. It is a mechanism, not a body of content.
The relationship is simple: RAG is worthless without a knowledge base, and a knowledge base is underused without something like RAG. One is the library. The other is the librarian.
Which one are you actually missing?
| What you experience | What is missing | What to fix first |
|---|---|---|
| The answer exists but nobody can find it fast | The finding (RAG) | RAG over what you have |
| People ask a specific senior person instead of searching | The finding (RAG) | RAG over what you have |
| The SOP is out of date and nobody knows which is current | The knowledge base | Document control first |
| The answer only exists in somebody's head | The knowledge base | Capture it before anything else |
| 2 documents disagree and no one arbitrates | The knowledge base | Decide which is authoritative |
The top 2 rows are finding problems, and they are the good case, because the expensive work is already done. The bottom 3 are content problems, and no search tool fixes them. Putting RAG over a knowledge base with those problems produces a system that answers wrong questions confidently, which is worse than the search bar you had.
The failure mode nobody warns you about
If your documents are not version-controlled, RAG will cite superseded revisions with complete confidence. It has no way to know that revision C was replaced by revision E, unless the effective dates are attached to the content.
In an unregulated setting that is an annoyance. In an AS9100 or ISO 13485 shop it is a quality event: an operator followed a work instruction that was not current, and the system told them to. That is the specific reason we attach revision and effective date when documents are loaded rather than treating them as flat files, and it is the question to ask any vendor demoing this to you.
What the market calls this, and why it matters
You will see the same product sold as an AI knowledge base, enterprise search, a RAG system, or an AI assistant. Mostly the same machinery underneath. The label tells you who the vendor is selling to more than what the thing does.
Worth knowing when you evaluate: "RAG" as a search term is dominated by research papers and code repositories, because it is an engineering term. "AI knowledge base" returns vendors and buying guides. If you are shopping and getting academic results, you are using the engineer's word for it.
The contrarian part: most shops should fix the base first
The demos are all about finding answers, because that demos well. Ask a question, get a cited answer, everyone is impressed. What the demo cannot show you is whether your own documents would hold up, because it runs on the vendor's clean sample data.
In our experience the binding constraint is usually content, not finding. Documents scattered across a shared drive with no owner, 3 versions of the same work instruction, and the one process nobody ever wrote down. That is unglamorous work, and it is the work that decides whether the AI is worth anything.
The good news is that it is not all-or-nothing. Pick the document set where the questions are most frequent, get that controlled, and put RAG over it. A narrow system that is trustworthy beats a broad one that is not.
A 4-question test
1. For your top recurring question, does a single authoritative document exist?
2. Does that document carry a version history and an effective date?
3. If it changed last month, would the floor be working from the new one?
4. Can someone find it today without asking a specific person?
Yes to 1 through 3 and no to 4 means you have a knowledge base and need the finding part. No to 1 through 3 means RAG is premature, whatever any demo showed you.
Questions we get
Can we just use ChatGPT on our documents? For non-sensitive content and casual questions, sometimes. 2 problems for a manufacturer: your documents go to a third party, which is disqualifying for controlled work, and there is no revision handling, so you get confident answers from whatever version was uploaded.
Is RAG the same as enterprise search? Related but not identical. Search returns documents and you read them. RAG returns an answer with citations back to the documents. For a shop floor question asked with gloves on, the difference between 40 results and one cited answer is the whole point.
What about fine-tuning a model on our data instead? Different tool, and usually the wrong one here. Fine-tuning teaches a model style and format. It does not give you current facts, and it cannot cite a source. When your work instruction changes, a fine-tuned model still has the old one baked in.
How does GraphRAG fit? It is the version for questions that span several records, like tracing a nonconformance across a lot, a supplier, and a work order. Most shops do not need it at the start. It earns its cost when the answer lives in the links between records rather than in any one document.
Does this replace our document management system? No, it sits on top. If your DMS is doing version control properly, that is the knowledge base, and you are further along than most.
How long does the content work take? Less than people fear, if you scope it to one document set rather than the whole drive. The realistic pattern is a few weeks to get one high-traffic set controlled, and the gaps surface as questions the system cannot answer, which is a better cleanup list than any audit done up front.
Who owns the knowledge base once it exists? Whoever owns the process it describes, which is usually quality or operations rather than IT. A knowledge base owned by IT drifts, because the people who know when a work instruction changed are not the people maintaining the system.
Where should we start? With the question your people ask most and answer slowest. Get that document set controlled, put RAG over it, and measure whether the answer time actually drops. That is a small first step with a result you can check.
What is next
Run the 4 questions above against your single most-asked question. The answers tell you whether you have a finding problem or a content problem, and those need different budgets.
If it is finding, RAG for manufacturing covers what to load first and where to run it. If it is content, what a controlled record set looks like in an AS9100 shop covers the document side. Or write to Kol with the question your floor keeps asking, and we will tell you which one you have.