Where teams get stuck with their own documents
You have an archive that holds the answer, and your team still cannot get it out quickly. The contract, the matter, the incident history is all in there, spread across hundreds of files. When the question is broad, like how a supplier relates to three other parties across years of correspondence, ordinary search hands back a handful of snippets that each look relevant and none of which connect.
Plain RAG works by matching text that resembles your question, which is fine when the answer sits in one place. It breaks down on questions that take hours of cross-referencing, because the link you need is never spelled out in any single passage. The work then falls back to a senior staff member holding the connections in their head, which is slow and leaves when they do.
Why buying GraphRAG off the shelf under-delivers
Microsoft GraphRAG is open source and free to download, which is why teams reach for it too early. Cloning the repository is not the hard part. Making it answer your questions reliably is.
The first trap is extraction quality. GraphRAG builds its graph by asking a language model to pull entities and relationships out of every document. On generic settings it will invent a relationship that reads well and is wrong, or split one client across three slightly different names. A graph built on that retrieves confident, incorrect connections, which is worse than a plain search that simply misses, because the answer looks authoritative. The fix is unglamorous, tuning the extraction to your domain language and sampling it against your records until it holds up.
The second trap is treating the graph as a one-off. Your documents change, and a graph that was right in March is stale by June, so it needs a refresh job and a cost model. The third trap is running it everywhere, where on simple lookups GraphRAG adds build time and compute for an answer plain RAG gives for less.
How we deliver it
We connect GraphRAG to your own documents and decisions, because retrieval is only as good as the material behind it. That principle of AI-accessible internal data is the whole point. The graph is drawn from your records, so answers are about your business, not the public web.
- Right-size it first. Before any build we study the questions you need answered. Relationship-heavy or collection-wide questions make GraphRAG a candidate. Simple lookups go to plain RAG.
- Build the graph on a focused slice. We extract entities and relationships from a contained set of your content, tune the extraction to your terms, and sample it against source documents before going wider.
- Stand up local and global search. Local search handles specific lookups, global search over community summaries handles broad questions, and plain retrieval is the fall-back where the graph adds nothing.
- Benchmark against plain RAG. We score GraphRAG against an ordinary RAG baseline on your real questions, so the extra cost is justified by measured gain.
- Set the refresh and guard rails. Answers cite their source nodes, a person reviews high-stakes output, and the graph rebuilds on a schedule you can afford.
How we run the system matters as much as how we build it. We keep the extraction prompts, community settings and retrieval choices under version control, with an evaluation harness that re-scores the graph whenever they change. That is version-controlled prompts and evaluations in GraphRAG terms, and it answers the only question that counts. Did this change make the answers better or worse. When a tweak drops the score, we revert it.
We also build it to run, not to demo. The graph lives in a proper store such as Neo4j that you can query and inspect, hosted in an Australian region, with the refresh, monitoring and access controls of a quality internal platform. A graph that breaks the first time the corpus grows is unfinished work.
When to choose GraphRAG, and when not to
Choose it when your questions are about connections. Investigations, due diligence, complex litigation, fraud analysis and large technical or regulatory libraries are where graph retrieval pays off, because the value is in tracing relationships a person would otherwise chase by hand. Choose it too when you need to make sense of a whole collection, where community summaries do work snippet retrieval cannot.
Do not choose it for everyday lookup. If your team mostly needs one fact from one document, plain RAG is cheaper to build, simpler to maintain and just as accurate. Be wary of the refresh cost too, since a graph over fast-changing content rebuilds often. In practice we often land on a blend, with graph retrieval reserved for the questions that need it, and we tell you which beforehand.
Where GraphRAG fits in our work
GraphRAG is one retrieval technique we build into larger systems. See how it supports AI agents, artificial intelligence grounded in your data, and data insights and analysis across large archives. It earns its keep most often in Professional Services, FinTech and Banking, Insurance and Government.
