RAG for Manufacturing: Ask Your Own SOPs, Prints and Records
Can AI answer floor questions from your own SOPs, prints and quality records? What to load first, what to leave out, where to run it, and how to trust it.
An operator at machine 4 needs the torque spec for the flange on part 8842-A. The SOP is somewhere on the shared drive, and the person who knows where is on the other shift. Manufacturing RAG is the fix for that walk: a knowledge base your floor can ask in plain language, which returns the answer along with the exact page of the exact SOP it came from.
RAG stands for retrieval-augmented generation. In plain words, it finds the passages in your own documents that answer a question, then has an AI model write the answer from those passages and show you where each part came from. Manufacturing RAG is that, pointed at a shop's SOPs, work instructions, prints, quality records, and ticket history, and tuned for the questions operators, engineers, and quality staff actually ask. It is not a chatbot, and it is not an internal search bar that returns 40 results.
That only works if the SOP it cites is the current one. In a regulated shop that is a document control problem before it is a search problem.
Most of what you will read about RAG online is demos over Wikipedia or over a company's Notion. Neither looks like a manufacturer's documents. This post covers what changes when the documents are SOPs, prints, quality records, and ticket history and the users are on the floor: what to load first, what to leave out, where to run it, and how to make the answers trustworthy enough that people keep using it.
What manufacturing RAG is
RAG combines 2 steps: a search step that pulls the most relevant passages from your documents for a given question, and a writing step where a language model composes an answer from those passages, with citations back to the source.
For manufacturing, the useful specifics are:
- The documents are operational, not general knowledge. Your SOPs, prints, work instructions, quality holds, MRB reports, ticket history, and vendor documentation.
- The users are hands-on. Operators at a workstation, engineers debugging a QA hold, quality staff preparing for an AS9100 audit.
- The questions are specific and repetitive. "Which lot had the QA hold in June?" "What is the setup for part X on machine 4?" "Which SOP covers alarm code 3172?"
- The stakes are physical. A wrong answer breaks a part, fails an audit, or hurts someone.
The stakes are why made-up answers are a dealbreaker for manufacturing RAG. Generic assistants that "sound right" get people fired in manufacturing. Sourced answers with visible citations to the original document are non-negotiable.
What to load first
The order matters. Load the highest-signal documents first. The list, ranked by return on effort:
1. SOPs and work instructions
The highest-return set. Every operator asks SOP questions. Most SOPs are PDFs or Word docs that nobody remembers where to find. Load them all, tag them by department and by machine, and the operator can ask in plain language.
Gotcha: SOP version drift. If you load all 4 revisions of the same SOP without marking which one is current, the system will happily return the outdated one. Mark the current revision when you load it.
2. Technical drawings and prints
Prints are the hardest documents to load. They are visual and dense, and the answer to "what's the tolerance on this feature" is often a callout on the drawing, not searchable text.
The approach that works today: have the system read the drawing as an image as well as its text, and keep the part number, revision, and change history alongside it. When someone asks "what changed in rev C of part 8842-A," the system can return the drawing and point to the changed section.
Gotcha: bad text recognition (OCR) on hand-annotated old prints. Budget for a cleanup pass. Not every print is worth loading.
3. Quality records and MRB reports
Manufacturing questions often span history. "Have we seen this defect on this vendor's material before?" means searching quality holds across years. RAG over structured quality records can answer it.
Combine them with your ERP's lot and vendor data for the strongest results. This is where GraphRAG starts to matter, because the question crosses from one kind of record to another (more on that below).
4. Ticket history and CAPA records
Every corrective and preventive action your team has ever documented is worth keeping findable. Most of it lives in a ticketing system nobody wants to search. Load it, tag it by machine and by defect type, and it becomes a "have we seen this before" system.
5. Vendor documentation and material data sheets
PDFs from suppliers that nobody reads until something breaks. Load them once, and the answer to "what's the shear strength of the adhesive from vendor X" is a question you ask instead of a Slack thread.
6. Know-how from senior operators
The hardest and highest-value set. Nobody writes this down. It lives in the head of the shift lead who has been on the floor 22 years. Capture it before they retire.
Approach: 30-minute recorded interviews on specific topics, transcribed, tagged, and loaded. This is expensive and slow. It is also often the difference between a RAG system that works and one that mostly returns SOP text.
What to leave out
The instinct is to dump everything in and let the search sort it out. This produces bad results. Skip these:
- Email threads. Long, low signal, full of "let me get back to you." Load specific decisions or attachments, not the threads themselves.
- Slack history. Same problem, worse. The signal is in the decisions that came out of Slack, not the Slack itself.
- Meeting recordings. Unless you have a transcript with speaker labels and topic markers, the transcript is mostly noise.
- Marketing collateral. Your own or your vendors'. It is written by someone who has never been on your floor.
- Superseded SOPs. If a rev is superseded, either leave it out or mark it plainly as historical so the system never offers it as the current one.
- Executive dashboards and BI exports. Totals and averages do not answer operator questions.
Where to run it
Manufacturing RAG can run in 3 places. In descending order of preference for most manufacturers:
Which one fits is a question of who controls your data before it is a technical one. Manufacturing data sovereignty covers the 4 things that decide it.
On-premise (Mac Mini cluster or GPU box)
The strongest position for protecting your IP. Your prints, your part numbers, and your process data never leave the plant. Open-weight models (Llama 3.3, Qwen 2.5, DeepSeek) run credibly on a 4-node Mac Mini M4 Pro cluster, or on a single RTX 4090 for smaller workloads. For heavier loads, a dedicated GPU workstation sits in the server closet.
Trade: you carry the running cost. Someone on your team, or the partner who built it, has to keep the models patched and the search index healthy.
Your own cloud account (AWS, Azure, GCP)
Same models, running in your account. Data never touches a third party's cloud. You pay for what you use.
Trade: you are still on a big cloud provider's hardware. For ITAR-controlled data, check that your account meets the residency requirement (AWS GovCloud, Azure Government).
Vendor-hosted (Anthropic, OpenAI, hosted RAG services)
Fastest to stand up. Highest quality models. Worst story for keeping your data in your hands. Your prints and process data pass through somebody else's cloud.
Trade: acceptable for non-sensitive documents (marketing materials, public vendor docs). Not acceptable for prints, part masters, or anything under ITAR.
How to make the answers usable
Getting the search right is half the problem. Getting the answer into a form an operator can use is the other half.
Sourced answers only
Every answer must cite the source document with page and section. If the operator cannot check the citation, they cannot trust the answer. Systems that answer without citations get ignored on the floor fast.
"I don't know" is a valid answer
Set the system up to say "I could not find this in the documents" instead of making up an answer. Operators respect a system that admits what it does not know. They stop using a system that lies to them once.
Answers in the operator's vocabulary
If your prints say "flange" and your operators call it "collar," the system needs to know both. Build a synonym list when you load the documents. Every shop has its own pairs, and the list is longer than people expect.
Answer at the workstation, not in a browser
An operator at a machine is not going to a browser. Options: a tablet mounted at the workstation, a kiosk with a barcode scanner (scan the part, get the SOP), or a voice interface (ask it hands-free). Pick the one that fits your floor.
What manufacturing RAG is worth
The return questions we get most, and how to measure each one in your own shop before anything is built, so the before and after are your numbers rather than a vendor's:
- Time to answer a floor SOP question. Today it means finding the SOP, then finding the section, or finding the person who knows. Time a week of those questions now, then time the same questions once the system is in.
- Setup quality on parts run less than monthly. The "which specs matter" question that used to need a senior operator gets a sourced answer. Track setup errors on those parts before and after.
- Audit prep time. AS9100 or ISO audits need evidence assembled quickly. RAG over quality records shortens the hunt for that evidence. Count the hours the last audit took.
- Onboarding time for new operators. The "how does this work here" learning curve shortens when the operator can ask and get a sourced answer instead of interrupting the shift lead.
Where GraphRAG comes in
Standard RAG answers questions inside a single document. Some manufacturing questions span several kinds of records: "which vendor supplied the raw material for the lots that had the QA hold in June, and had we seen that defect from them before?"
That question needs a map of how parts, lots, vendors, orders, and QA events connect to each other (a knowledge graph), not just a document search. When those connections matter, GraphRAG is the right tool. Manufacturing RAG and GraphRAG are complementary, not competing. RAG vs knowledge base covers how to tell which problem your shop has first.
Questions we get
How much does a first manufacturing RAG system cost?
A first build scoped to one document type (usually SOPs) runs $25k to $60k for the build and initial setup, plus a few hundred dollars per month to run on hardware in the plant, or a few thousand in a cloud account. Adding prints, quality records, and tickets is incremental.
How long to first useful answer?
4 to 8 weeks from the start of the contract, depending on how many documents there are and how much cleanup they need. The first 2 weeks are loading and testing. Weeks 3 to 6 are tuning the search. Weeks 7 and 8 put it in front of real users.
Which model should we use?
On-premise: Llama 3.3 70B or Qwen 2.5 72B for most workloads, Mistral Small where speed matters most. In the cloud: Claude for citation quality, GPT for cost. This changes every quarter, and the answer 3 months from now will be different.
What if our documents are terrible quality?
Common. Budget a cleanup pass. RAG over garbage returns garbage answers with false confidence. If the text recognition on your old prints is 60 percent accurate, no model will recover the meaning. Fix the documents, then load them.
Does this replace an ERP?
No. RAG works alongside the ERP: it makes the ERP's data askable in plain language and opens up the documents around it that ERPs are bad at storing. If you want the ERP itself replaced with something you own, that is what we build: quote to invoice, on one system the shop owns, code and data included. GatorStep, a marine manufacturer, moved off Microsoft and Odoo onto one system in 2.5 months.
What's next?
The right first step is narrowing the scope: pick one document type, one group of users, and one question the system needs to answer well. Then write to Kol with those 3, and we come back with a plan for what to load and how good the answers need to be before anyone relies on them.