What a RAG assistant needs before it can read your engineering documents

, 7 min read

A retrieval-augmented generation assistant answers a question in two steps. First it searches your documents for the passages most likely to contain the answer. Then a language model writes the answer from those passages. When the answer is wrong, the cause is almost always the first step: the right passage was never found.

That makes the work before the model more important than the model. Here is what has to be in place for plant documents.

1. Know which documents you have

Start with an inventory: licensor manuals, design basis, operating procedures, equipment data sheets, vendor manuals, inspection reports. For each, note the format, whether it is the current revision, and who may see it. An assistant that answers from a superseded revision is worse than none, so the index must follow your document control, not a copy of a shared drive.

2. Get real text out of every page

Text-based PDFs and office files are straightforward. Scanned pages need text recognition, and its quality decides everything downstream. Check a sample of pages by eye: tables broken into single words, merged columns and misread units will all be retrieved as nonsense. Drawings such as P&IDs carry most of their meaning in symbols and lines, which text recognition alone does not capture; set expectations accordingly.

3. Split documents the way engineers read them

Documents are split into passages before indexing. Splitting every few hundred words cuts a table from its heading and a limit from its condition. Splitting along the document's own structure, by section and table, with the section title kept on each passage, gives the search something meaningful to match.

4. Search by meaning and by exact terms

Vector search finds passages with similar meaning, which handles questions phrased differently from the manual. It is weak on exact identifiers: equipment numbers, tag names, units and model codes. Engineers ask about exactly those. Combining vector search with keyword search, and merging the two result lists, is what makes answers dependable for plant questions.

5. Require a source for every answer

The assistant should show the document, revision and section behind each answer, and say plainly when it found nothing. An answer without a source cannot be checked, and an engineer should not act on what cannot be checked.

6. Agree an evaluation set before go-live

Collect real questions from the engineers who will use it, with the correct answer and where it is found. Run them after every change to the documents, the splitting or the model. Track how often the right passage is retrieved, not only whether the final answer reads well. This turns "it seems good" into a number you can defend.

7. Keep it inside the network

Licensor manuals and design documents are usually confidential. Open-weight language models now run well on a single workstation-class GPU, which keeps documents and questions on site. Running the embedding model separately, for example on the CPU, keeps indexing from slowing down answers.

Where to start

Pick one document family that engineers search often and that is in good text condition, write twenty real questions for it, and build the assistant against those questions. Widen the scope only when it answers them reliably with sources.

Document assistant package Read the case study