RAG for Manufacturing: A Knowledge Base Your Shop Floor Can Actually Use

A manufacturing RAG system is a knowledge base your shop floor can actually query in plain language. Not a chatbot. Not an internal search bar that returns 40 results. A system that takes a question like "what is the torque spec for the flange on part 8842-A" and returns the exact page of the exact SOP with the answer.

The generic RAG conversation online is dominated by demos over Wikipedia or over a company's Notion. Neither of those looks like a manufacturer's document corpus. This piece is specifically about what changes when the corpus is SOPs, work instructions, technical drawings, quality records, and ticket history, and when the users are operators, engineers, and quality staff instead of knowledge workers.

What manufacturing RAG is

Retrieval-augmented generation combines two things: a retrieval step that pulls the most relevant chunks of your document corpus for a given question, and a generation step where a language model composes an answer grounded in those chunks with citations back to the source.

For manufacturing, the useful specifics are:

• The corpus is 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 hallucination is 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 ingest

The order matters. Ingest the highest-signal documents first. The list, ranked by return-on-effort:

1. SOPs and work instructions

The highest-ROI corpus. Every operator asks SOP questions. Most SOPs are PDFs or Word docs that nobody remembers where to find. Ingest them all, tag by department and by machine, and the operator can query in plain language.

Gotcha: SOP version drift. If you ingest all 4 revisions of the same SOP without tagging revision status, the system happily returns the outdated one. Mark canonical revs at ingest time.

2. Technical drawings and prints

Prints are the hardest ingestion problem in manufacturing RAG. They are visual, dense, and the answer to "what's the tolerance on this feature" is often literally a callout on the drawing, not a searchable text field.

Modern approach: multimodal embedding of the drawing plus OCR of any text, plus a metadata layer that captures part number, revision, and change history. When someone asks "what changed in rev C of part 8842-A", the system returns the drawing and highlights the changed section.

Gotcha: bad OCR on hand-annotated old prints. Budget for a cleanup pass. Not every print is worth ingesting.

3. Quality records and MRB reports

Manufacturing questions often span history. "Have we seen this defect on this vendor's material before?" is a question that requires searching quality holds across years. RAG over structured quality records is answerable.

Combine with your ERP's lot and vendor data for the strongest results (this is where GraphRAG starts to matter, because the question crosses entity boundaries).

4. Ticket history and CAPA records

Every corrective and preventive action your team has ever documented is a knowledge asset. Most of it lives in a ticketing system nobody wants to search. Ingest it, tag 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. Ingest them once, and the answer to "what's the shear strength of the adhesive from vendor X" is a query instead of a Slack thread.

6. Institutional knowledge from senior operators

The hardest and highest-value corpus. 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 ingested. This is expensive and slow. It is also often the difference between a working RAG system and one that mostly returns SOP text.

What NOT to ingest

The instinct is to dump everything into the vector store and let retrieval sort it out. This produces bad results. Skip these:

• Email threads. Long, low signal, full of "let me get back to you." Ingest 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 90 percent noise.
• Marketing collateral. Your own or your vendors'. It is content-optimized language written by someone who has never been on your floor.
• Deprecated SOPs. If a rev is superseded, either exclude it or explicitly tag it as historical so retrieval never surfaces it as authoritative.
• Executive dashboards and BI exports. Aggregated data does not answer operator questions.

How to deploy it on your infrastructure

Manufacturing RAG has three deployment options. In descending order of preference for most manufacturers:

On-premise (Mac Mini cluster or GPU box)

The strongest posture for IP protection. Your prints, your part numbers, your process data never leave the plant. Modern open-weight models (Llama 3.3, Qwen 2.5, DeepSeek) run credibly on a 4-node Mac Mini M4 Pro cluster or a single RTX 4090 for smaller workloads. For heavier loads, a dedicated GPU workstation sits in the server closet.

Trade: you own the operational cost. Someone at KoldOps or on your team needs to keep the models patched and the vector store healthy.

Your own cloud tenant (AWS, Azure, GCP)

Same models, deployed in your account. Data never touches a third-party cloud. Cost model is pay-per-use inference.

Trade: you are still on hyperscaler infrastructure. For ITAR-controlled data, verify your tenant meets the residency requirement (AWS GovCloud, Azure Government).

Vendor-hosted (Anthropic, OpenAI, hosted RAG-as-a-service)

Fastest to stand up. Highest quality models. Worst sovereignty story. Your prints and process data are transiting somebody else's cloud.

Trade: acceptable for non-sensitive corpora (marketing materials, public vendor docs). Not acceptable for prints, part masters, or anything under ITAR.

How to make the answers usable

Getting the retrieval right is half the problem. Getting the answer to be usable by an operator is the other half.

Sourced answers only

Every answer must cite the source document with page and section. If the operator cannot verify the citation, they cannot trust the answer. Systems that answer without citation fail on the shop floor within a week.

"I don't know" is a valid answer

Tune the system to say "I could not find this in the corpus" instead of hallucinating an answer. Operators respect a system that admits ignorance. 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 layer at ingest time. Most manufacturers have 200 to 500 domain-specific term pairs that matter.

Answer at the workstation, not in a browser

An operator at a machine is not going to a browser. Deployment options: tablet mounted at the workstation, kiosk with a barcode scanner (scan the part, get the SOP), or voice interface (talk to it hands-free). Pick the one that fits your floor.

What manufacturing RAG is worth

The ROI questions we get most:

• Time to answer for a shop floor SOP question: from 8 to 15 minutes (find the SOP, find the section) to under 30 seconds.
• Quality of setup for parts run less than monthly: the "which specs matter" question that used to require pulling a senior operator gets answered in seconds. Setup errors drop.
• Audit prep time: AS9100 or ISO audits need evidence assembled quickly. RAG over quality records collapses evidence assembly from days to hours.
• Onboarding time for new operators: the "how does this work here" learning curve compresses when the operator can ask questions and get sourced answers instead of interrupting the shift lead.

Where GraphRAG comes in

Standard RAG answers questions inside a single document. Some manufacturing questions span entities: "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 knowledge graph, not just a vector store. When entities and their relationships matter (parts, lots, vendors, orders, QA events), GraphRAG is the right tool. Manufacturing RAG and GraphRAG are complementary, not competing.

Questions we get

How much does a manufacturing RAG pilot cost?

A first pilot scoped to one document type (usually SOPs) runs $25k to $60k for build and initial deployment, plus hosting cost of a few hundred dollars per month for on-prem or a few thousand for cloud. Expansion to prints, quality records, and tickets is incremental.

How long to first useful answer?

4 to 8 weeks from kickoff, depending on document corpus size and cleanup required. First 2 weeks are ingest and evaluation. Weeks 3 to 6 are retrieval tuning. Weeks 7 to 8 are deployment to real users.

Which model should we use?

For on-prem: Llama 3.3 70B or Qwen 2.5 72B for most workloads, Mistral Small for latency-sensitive queries. For cloud: Claude for citation quality, GPT for cost. This changes every quarter, and the answer three 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 OCR on your old prints is 60 percent accurate, no model will recover the meaning. Fix the corpus, then ingest.

Does this replace an ERP?

No. RAG augments the ERP by making its data queryable in plain language and by exposing the surrounding document corpus that ERPs are bad at storing. If you want the ERP itself replaced with something you own, that is what OpsBox is for.

What's next?

The right first step is scoping the pilot: pick one document type, one user group, one measurable question the system needs to answer well. Then scope a RAG pilot and we come back with an ingestion plan and a retrieval quality target.