Why industrial documentation is a surprisingly good AI use case
Manufacturing organisations accumulate a huge amount of technical knowledge: operating procedures, equipment manuals, electrical drawings, validation documents, change records, troubleshooting notes, alarm matrices, software descriptions and lessons learned from years of maintenance work.
The problem is not normally the absence of information. The problem is retrieval. An engineer may know that a setting exists somewhere in a 180-page manual, but locating the correct revision under time pressure can be difficult. The same is true for an experienced engineer trying to remember which previous change fixed a similar issue.
Retrieval-Augmented Generation, usually shortened to RAG, is attractive because it separates two jobs that are often confused. Search retrieves relevant source material. The language model turns that material into a useful explanation. The model is not expected to know the factory by memory.
The basic architecture
A practical industrial RAG system usually contains five stages: ingestion, document processing, indexing, retrieval and response generation.
- Ingestion: manuals, PDFs, procedures, tickets and other approved documents enter the system.
- Processing: text, tables, headings and metadata are extracted. Revisions and document ownership are preserved.
- Indexing: content is stored in a search index or vector database together with metadata.
- Retrieval: a user question is converted into a search request and the most relevant chunks are selected.
- Generation: the language model drafts an answer based only on the retrieved evidence.
This seems straightforward until the first production document arrives with two columns, a scanned diagram, a revision history and a footer containing an obsolete part number. Industrial RAG is therefore as much a document-engineering problem as an AI problem.
Chunking is not a trivial implementation detail
General-purpose RAG examples often split documents into fixed token lengths. That is rarely ideal for technical documentation. A 900-token chunk can easily contain half of one procedure and half of another.
A better approach is structure-aware chunking. Keep a procedure step with its heading. Keep an alarm description with the equipment reference it belongs to. Keep a table header attached to the rows it describes. Preserve page numbers, document IDs, revision information and section hierarchy as metadata.
For example, a piece of text might carry metadata such as document ID, revision, equipment family, plant area, page number and effective date. The model can then answer not only what does this procedure say? but also which revision does it come from?
Hybrid retrieval usually makes more sense than vector search alone
Industrial vocabulary contains many short identifiers that semantic embeddings do not always handle perfectly. A question containing a part number, PLC module code or alarm ID can benefit from exact lexical matching, while a broader question may benefit from semantic retrieval.
A robust design therefore uses hybrid retrieval: combine keyword search with vector similarity, filter by metadata, then rerank the candidates. In a controlled environment, access control should happen before generation rather than after it.
Suppose an engineer asks about an obsolete machine. The search layer should be able to distinguish current documentation from archived revisions. A language model that receives conflicting documents cannot reliably resolve the conflict simply because it sounds fluent.
Citations are a design requirement, not decoration
Industrial users should be able to inspect the source of an answer. A system that says “according to the manual” without identifying the manual is not much better than a normal chatbot.
Each generated response should make the supporting documents obvious: title, document number, revision and page or section where practical. This changes the role of the AI from oracle to assistant. Engineers can challenge the answer, open the source and make a decision.
It also gives the system a useful failure mode. When retrieval returns nothing trustworthy, the application can say that it could not find supporting documentation. That is much safer than encouraging the model to fill the gap from general language patterns.
Where access control becomes important
Industrial documentation is rarely uniform in sensitivity. Some manuals are public. Other documents may contain security architecture, process parameters, proprietary formulas or validated procedures. A RAG system must preserve the permissions attached to the source documents.
One of the easiest mistakes is to create a central vector store containing everything and then assume the chat interface will somehow enforce document permissions. The safer architecture carries document-level access metadata into the retrieval layer and filters the candidate set before the LLM sees the content.
Evaluation should look like an engineering test, not a demo
A RAG system should be tested against a representative question set created by real engineers. Measure retrieval accuracy, answer grounding, citation correctness and the rate of unsupported statements.
Test difficult cases deliberately. Ask questions where two revisions conflict. Ask about a document that does not exist. Ask for a value that is only present in a table. Ask a question involving a deprecated component. The quality of a RAG system is often revealed by what it does when the evidence is incomplete.
A sensible first implementation
Start with a controlled document family, such as a machine manual library or a standard operating procedure repository. Make document ownership and revision rules explicit. Build retrieval first. Only then add a polished conversational interface.
The value of RAG in a factory is not that people can chat with a PDF. The value is that technical knowledge becomes easier to find while remaining anchored to controlled source material. That is a much more useful proposition, and it fits the way engineers already work.
Document retrieval is a controlled engineering component
One of the easiest ways to make a RAG system unreliable is to treat the search index as a generic folder of text. Technical documents have ownership, status and lifecycle. A machine manual can be obsolete even when it is factually correct. A procedure can be superseded without being technically wrong. The retrieval layer therefore needs to understand document state.
For an engineering user, “current” should mean more than the document with the newest upload timestamp. Store revision number, approval status, effective date and equipment scope as structured metadata. Search can then filter the candidate set before the language model generates anything.
Tables and drawings need special handling
Many industrial facts live in tables: torque values, alarm limits, I/O assignments, calibration intervals and spare-part numbers. If a document-processing pipeline extracts only the surrounding paragraphs, the most useful information can be lost. Tables should be parsed as structures and linked back to the page where they appeared.
Drawings introduce another problem. A P&ID or electrical schematic may contain little searchable prose but a large amount of operational meaning. Where the use case requires it, store references to drawing identifiers, pages and equipment codes so the retrieval system can at least guide the engineer to the authoritative source.
RAG should know when it is wrong
There should be a deliberate abstention behaviour. If retrieval finds weak or conflicting evidence, the system should say so. In an industrial setting, a concise statement such as “I found two revisions that disagree; please review the current controlled copy” is much more valuable than a confident paragraph assembled from both.
Measure retrieval before polishing the chat interface
Create a benchmark of real questions from automation, maintenance and quality teams. Score whether the correct document and section were retrieved. Only after retrieval is dependable should the team spend significant effort on conversational polish. A beautiful answer cannot rescue poor evidence selection.