The problem
When a line stops, the cost accumulates by the minute, yet root cause analysis often depends on tribal knowledge and manual log diving: the alarm history in one system, work orders in another, shift notes in a notebook, trends in the historian. The evidence exists; finding it is slow. Language-model techniques can help with the finding, if they are applied with care.
What retrieval-augmented generation does
Retrieval-augmented generation (RAG) first searches your own documents and records for the passages relevant to a question, then asks a language model to draft an answer from those passages. The model does not “know” your plant; it summarizes what was retrieved. That distinction is the basis of every guardrail below.
The data it needs
- Alarm and event logs.
- Maintenance work orders and downtime reason codes.
- Operator shift notes and handover logs.
- Process trends and summaries from the historian.
- Equipment manuals, procedures and earlier investigation reports.
Quality decides usefulness. Consistent equipment identifiers, reliable timestamps (see time synchronization) and notes that actually say what happened matter more than the choice of model.
Guardrails
- Cite the evidence. Every claim links to the source record, so the engineer can read it. An answer without sources is not usable.
- Show uncertainty. Rank hypotheses and say when the evidence is thin.
- Read-only. The assistant searches and summarizes. It does not change setpoints, close work orders or act on equipment.
- Respect access rights. Users see only the records they are already allowed to see.
- Keep sensitive data in an approved environment, and log queries for review.
- Keep humans deciding. The aim is a better starting point, not a replacement for expertise.
Evaluate before you trust
Take a set of past incidents whose causes are known. Ask the system the question an engineer would have asked at the time, and check whether it retrieves the right evidence and proposes the right cause. Have the engineers who would use it judge usefulness. Repeat the test when the data or the model changes. Do not rely on impressions or on a demo of a single success.
Where it tends to fail
- Sparse, vague or empty operator notes.
- Inconsistent naming of machines and failure modes across systems.
- Out-of-date manuals that contradict current practice.
- Answers produced without retrieval, which can sound plausible and be wrong.
Start small
Choose one line and one recurring failure type, connect the few sources that describe it and test on history. Pair the work with the loss analysis in the six hidden losses behind OEE, so the questions you ask are tied to where production time is actually lost, and measure data quality first (data quality for time series).