A knowledge assistant is only trustworthy if it answers from your approved sources and shows them. Retrieval-augmented generation, RAG, is how that is done: find the passages relevant to the question, hand them to the model, and have it answer from those passages with citations rather than from whatever it remembers. GraphRAG adds a second structure, a graph of the entities in your documents and the relationships between them, and uses it to answer questions that span several documents at once. Most assistants need the first. Some need both. The way to decide is to look at the questions people actually ask.
What RAG does
Documents are parsed, split into chunks that respect their structure, and turned into embeddings, numerical representations of meaning. A question is embedded the same way, the chunks closest to it are retrieved, and the model is instructed to answer only from them and to cite them. Done well, with hybrid retrieval that combines semantic similarity with keyword matching, and with permission filtering so nobody retrieves a document they could not open, RAG answers the large majority of knowledge questions: what does the procedure say, what is the standard for this, what did the contract commit to, what does this fault code mean.
Where it struggles is the question that needs several facts joined together.
What GraphRAG adds
During ingestion, entities are extracted, products, components, parameters, suppliers, clauses, people, and the relationships between them are recorded in a graph: this drive supports that motor; this parameter relates to that fault; this clause depends on that definition. Retrieval then uses the graph as well as the embeddings, following relationships across documents to assemble the context for a multi-hop question.
“Which drives support this motor with that encoder?” is a graph question. So is “which customer agreements carry an obligation that this regulatory change affects?”, and “which components appear in the products with the highest field-failure rate?”. Plain retrieval finds passages that mention the terms; it does not know how the things relate.
Which one you need
| If people mostly ask… | You need |
|---|---|
| “What does the document say about X?” | RAG |
| “Where is the procedure for Y?” | RAG |
| “Which things relate to which?” across documents | GraphRAG |
| “What depends on this?” or “what is affected by that change?” | GraphRAG |
| Questions about a product family with shared components and parameters | GraphRAG |
| Questions about a single policy, contract or manual at a time | RAG |
Start with the question set. In scoping we collect the questions a function actually asks and sort them. If more than a handful are multi-hop, the graph pays for itself; if not, it is cost and complexity for no gain.
What both need
Grounding and citation enforced, so the assistant answers only from approved sources and “I cannot find that” is a valid answer. Permission-aware retrieval. An evaluation set of questions with agreed answers, run on every change. And, above all, good sources: an assistant over sparse, contradictory or out-of-date documentation will faithfully report that it is sparse, contradictory and out of date, which is useful information and not the outcome anyone wanted. The first task of every knowledge-assistant build is deciding what counts as an approved source and who keeps it current.
What we build with
The pipeline is standard: parsing, chunking, embeddings and entity extraction into a vector index and, where needed, a graph; hybrid retrieval; context assembly under the user’s permissions; generation with citations. The vector and graph stores are chosen on the client’s cloud and scale; the model is chosen on the evaluation set. The framework is the same each time; the sources and the questions are what change.
The service is described under knowledge assistants, and the source-readiness work that usually precedes it under data mining and requirements.