Knowledge graph vs RAG: why a chatbot on your manuals is not enough for field service
RAG, short for retrieval-augmented generation, searches your documents and writes an answer from the passages it finds. That works for questions a manual can answer. Most questions on a service call are about one particular unit: what failed here before, what the last technician changed, what the controller logged overnight. A knowledge graph links each unit to its jobs, alarms, parts and manual, so the answer starts from the unit in front of the technician. That is how Kenner (getkenner.com) is built.
In short
- RAG answers from documents. It is quick to set up and good for what the manual says.
- Service questions are mostly about a unit, and the facts sit in several systems, not in one document.
- A knowledge graph links unit, jobs, alarms, parts and manual, so one question can use all of them.
- The practical test: ask about a unit with a history, and ask where each part of the answer came from.
What RAG does well
It is worth being fair to retrieval, because it solved a real problem. Before it, a technician looking for a torque value or an error code scrolled through a PDF on a phone. With RAG they ask in plain words and get the passage back, and pointing a tool at a folder of manuals is quick to do.
If the question is what the manual says, document search is the right tool. Error code tables, wiring conventions, start-up procedures and maintenance intervals are all in documents, and retrieval finds them.
Where document search runs out on a service call
The question is about a unit, not a document
A technician standing at an iced-up display case rarely needs the general theory of defrost. They need to know that defrost on this case ended early last night, that a colleague found the termination sensor reading low on the same case in April, and what tolerance the manual allows for that sensor. Only the last of those is in a manual.
The facts live in different systems
The work orders are in the FSM. The alarms are in the store controller. Parts and stock are in the ERP. The manual is on SharePoint. A passage search treats each of these as separate text. It can find a similar-sounding report, but it has no way to know that the report, the alarm and the manual page all belong to the same piece of equipment.
Similar words are not the same unit
Two job reports can read almost the same and be about different models at different sites, with different causes. Ranking by how alike the wording is will happily return the wrong one. On a service call, the wrong history is worse than none.
It has to say when it does not know
A system that always retrieves something will always answer something. A technician needs the opposite habit: a clear statement of what the answer rests on, and a plain no when there is nothing on record.
What a knowledge graph adds
A knowledge graph stores the links, not just the text. In Kenner’s case: every unit, every job done on it, its alarms, its parts and its manual, linked together.
Take the iced-up case again, an illustrative example from our homepage. Starting from the unit, the graph leads to three things at once:
- Its alarm log: defrost ended at 18 of 35 minutes.
- Its job history: a colleague’s visit in April for the same fault, where the sensor read 11°F low.
- Its manual: the page with the sensor tolerance, plus or minus 2°F.
Put together, that is an answer a senior engineer would give: defrost is ending too early, check the termination sensor first. And each part of it can be shown with its source, so the technician can judge it instead of trusting it blind.
What changes for the technician
- Answers start from the unit. Its own history comes first, then what the manual says.
- Sources are visible. The alarm, the earlier job and the manual page are shown next to the answer.
- It says when it does not know. If there is no earlier job for this fault, that is what it reports.
- Every job teaches it. The report from today’s visit becomes history for the next technician at that unit.
What changes for the service leader
A pile of documents cannot tell you your first-time fix rate. A graph can, because each job is tied to a unit, a fault and a team. That is how Kenner shows first-time fix by team and by fault type, and which faults on which equipment keep bringing technicians back.
It also gives field knowledge a place to live. When a technician finds a fix worth keeping, it is saved for the team and goes into later briefings once a supervisor has approved it. The know-how of your best engineer stops depending on whether they pick up the phone.
Does a graph replace retrieval?
No, and nobody should claim it does. Manuals still matter and still have to be read. The difference is where the reading starts. In a graph the manual is attached to the units it covers, so the page that comes back is for this model, next to what actually happened on this unit.
Five questions to ask any vendor
You do not need to audit anyone’s architecture. Ask for a demo on your own data and try these:
- Ask about a specific unit with a history. Does the answer mention what was done on that unit before, or only what the manual says?
- Ask where each part of the answer came from. Can it point to the job, the alarm and the page?
- Ask something it cannot know. Does it say so, or does it produce a confident paragraph?
- Ask what happens to a finished job. Does today’s fix reach the next technician, and who approves it?
- Ask what it writes back. Does the report land in your FSM, or in another place someone has to copy from?
We built Kenner to pass all five. If you want to see how the alternatives are built, start with Kenner vs ServiceTitan Atlas or ChatGPT for HVAC troubleshooting, or read what Kenner is and how a pilot runs.
Common questions
What is RAG in plain words?
Retrieval-augmented generation. The software searches a set of documents for passages that look relevant to the question, hands them to a language model, and the model writes an answer from them. A chatbot on your manuals is RAG.
What is a knowledge graph in field service?
A map of your service in which things are linked rather than stored as loose text: every unit, every job done on it, its alarms, its parts and its manual. A question about a unit can then follow those links instead of searching for similar wording.
Does Kenner still use our manuals?
Yes. Manuals, bulletins and old reports are read where they are, for example in SharePoint, and your own how-tos in Confluence. In the graph a manual belongs to the units it covers, so the page that comes back is for this model.
How is Kenner different from a chatbot on our manuals?
A chatbot on manuals searches documents and pastes together an answer. Kenner builds a knowledge graph of your service, answers from the unit in front of the technician, shows where each part of the answer came from, and says so when it does not know. Every finished job adds to the graph.