As part of the MOTIVATE XR project, the Sopra Steria team bet on small, on-premise models, and that turned out to be the safest choice as well as the cheapest one.
A Question that Can't Afford a Wrong Answer
A maintenance technician stands in front of a piece of industrial equipment, tablet in hand. The service manual for this machine runs to hundreds of pages: procedures, torque values, safety warnings, exploded diagrams. The technician has one question: “Which components does this procedure involve?”
Today, that question means scrolling, searching keywords, cross-referencing part numbers, or increasingly, asking a chatbot. And that is where the problems start. In maintenance, a confident but wrong answer is worse than no answer at all. A chatbot that invents a torque value or skips a safety notice creates a safety risk.
This is one of the challenges we set out to solve in the MOTIVATE XR project: how do you build an AI assistant that answers questions from a company’s own technical documentation, accurately and traceably, without ever making things up?
Our answer was not a bigger model, but a smaller one used in a smarter way.
Why the Obvious Solution Was Off the Table
The obvious solution today is to send the documentation and the question to a large cloud-hosted model. For our industrial partners, that path is effectively closed, for three very practical reasons.
- Data sovereignty. Technical maintenance documentation is often sensitive: it may fall under export controls or confidentiality agreements, or a company may simply not want to send its proprietary know-how to a third-party server. The AI has to run on infrastructure the organisation controls.
- Cost predictability. Usage-based pricing on frontier models makes budgeting difficult for a tool meant to be used all day, every day, by whole teams. A solution running on owned hardware has a cost curve the finance department can plan around.
- Modest hardware. “On-premise” in a factory or a workshop usually means a machine with a reasonable GPU, not a datacenter. That rules out the heavyweight models and points to compact ones. In our case, we use models in the 8-billion-parameter class, the kind that fit on a single consumer-grade GPU.
So the constraints were clear: small model, local deployment, sensitive documents. The remaining question was an engineering one, and in part a design one.
Small Model, Big Job: Decompose Instead of Scale Up
Asking a small model to “read 600 pages and answer accurately” in one go is a recipe for hallucination. The model’s attention is finite; the more it must juggle at once, the more it starts to fill gaps with plausible invention.
What we found instead is that a small model is very reliable when you only ask it to do one narrow job at a time.
So instead of one giant prompt, we built a pipeline: a chain of small, sharply defined stages, each a separate call to the model. A simplified view:
- Understand the question. Follow-up questions are rarely self-contained. “And what about the images?” only makes sense in context. A first step rewrites each follow-up into a standalone question, using only the bare minimum of the conversation history needed to resolve “this procedure” or “the second one.”
- Look things up, step by step. The model doesn’t receive the documentation directly. It asks for it through a set of well-defined tools, one call at a time, deciding after each result what to fetch next.
- Take notes, immediately. Every raw lookup result is condensed into a short note the moment it arrives, keeping only what matters for the question. The context never grows with the number of lookups.
- Write the answer. Only once the notes are judged sufficient does a single writing pass compose the response.
- Verify, mechanically. A final pass, pure code with no AI involved, removes anything the system can prove is wrong.
If this reminds you of how a thoughtful person works (rephrase the question, look things up one at a time, jot down notes, then write), that is intentional. The next section looks at why this matters.
Looking Things Up Like a Human Would
The documentation our chatbot serves isn’t stored as flat text. During ingestion, it’s transformed into a knowledge graph: a structured network of procedures, steps, components, tools, safety notices and illustrations, connected by their relationships. You can think of it as the equipment’s organised memory rather than a pile of pages.
This is what makes the “think like a human” behaviour possible. When a technician needs to know which components a procedure step touches, they don’t read the manual cover to cover. They do something like this: find the right procedure in the index, open it to the steps, then follow the references to each component’s description.
Our chatbot does exactly the same thing. To answer a question about components, it first looks up the list of procedures to identify the right one, then fetches that procedure’s steps, then retrieves each component’s description. The AI navigates the graph the way a person navigates a well-organised workshop manual (index first, details second), and each of those lookups is a tool call the system can log, verify, and show to the user.
Two details matter here. The lookups are complete: when a procedure has thirty-nine steps, the system reads all thirty-nine. Paging through results is handled by the software, never left to the model, which would lose track. The model is also never trusted to skip steps: if a question clearly requires the content of a procedure and the model tries to answer from the title alone, the pipeline opens the procedure itself, deterministically, before the model gets the chance to improvise it.
The Golden Rule: Never Invent
All of the architecture above serves one principle: the system prefers to say “I didn’t find it” rather than make something up.
In practice, this took work at every level of the design, because a language model’s default behaviour, when it lacks information, is to produce something plausible. We fenced that tendency in with several layers:
- Notes are copied, not paraphrased. When the pipeline extracts facts from a lookup result, it is instructed to copy numbers, units, step numbers and warnings character-for-character. A torque value is not something you want reworded.
- An empty result is a failure, not an invitation. If a lookup comes back empty, the system records that explicitly (“this search returned nothing”) and that fact travels through the rest of the pipeline. The model is explicitly instructed that an empty result is not a licence to write from general knowledge.
- The writer is told to admit gaps. When only partial material was retrieved, the answer must say so in plain language and stop. Two honest sentences beat a fabricated procedure.
- The final check is not an AI at all. The last stage of the pipeline is ordinary, deterministic code. It holds a ledger (computed from the lookups themselves) of exactly what was and wasn’t retrieved, and it strips from the draft anything the ledger disproves. What the system knows it has is the one fact that must never be hallucinated, so we never ask a model to judge it.
The result is a chatbot that is honest about its own limits. When it answers, every claim can be traced back to a source in the documentation, and sources are returned alongside the answer so the technician can verify. When it can’t answer, it says so.
What It Looks Like in Practice
The screenshots in this section were produced against mock manuals written for the occasion our partners’ documentation is confidential, so every procedure, part number and document name shown here is fictional.
Above, a technician asks which lubricant to use when installing an engine, and everything the assistant does to answer stays visible. Rather than replying from memory, it works through its tools one call at a time (search the documents, open the relevant procedure, check its tooling list), each call logged with its timing, then composes a structured answer from what it gathered: a table of application points, a caution the manual insists on, an illustration embedded inline, and the exact documents, sections and pages it relied on so the technician can verify every claim at a glance.
What We Learned
Building this taught us a lesson that extends well beyond maintenance manuals: for many real-world applications, architecture matters more than model size.
A small model, running on-premise, inside a carefully decomposed pipeline, with deterministic guardrails where they matter most, can deliver something a much larger model often doesn’t: predictable, verifiable behaviour, on hardware the organisation already owns, at a cost it controls, over documents that never leave its walls.
In industrial maintenance, where the next user of the chatbot might be a technician with cold hands, a noisy environment, and a safety-critical job to finish, that trade-off is not a compromise. It is the point of the design.
Author
Sopra Steria
Lucas Colomines (b. 1997) holds a Master’s degree in Computer Vision and Machine Learning. His work spans a diverse range of optimisation challenges, including quantum computing, Rag systems, mathematical modeling, and computer vision. He has contributed to projects involving advanced algorithmic design and applied research, with a focus on bridging theoretical models and real-world applications.
