Use Graph RAG when relationships are part of the evidence

Vector search is good at finding the right text. It is not good at proving why one record applies to another. That difference is the whole argument for Graph RAG here: when the evidence lives in relationships, similarity alone can get you close but still leave you guessing.

The source’s example is a familiar mess. A vulnerable library shows up in an advisory, a service depends on it, that service maps to a customer environment, and the customer’s contract sets the notification rule. Search can surface the advisory, the service page, and the policy. But unless the system can follow the actual links, it may still confuse one service version with another or attach the wrong customer to the alert.

That is where the graph earns its keep. It turns known relationships into typed edges such as USES, SUPPORTS, and GOVERNED_BY, with source and owner attached. The point is not to copy every paragraph into some second truth database. The point is to keep the relationships explicit, traceable, and constrained so the system can follow only the allowed path and stop when an edge is missing.

The article also draws a sharp line between graph and vector search instead of treating them as rivals. Vector retrieval still does the first job well: finding likely evidence in docs, support pages, and product text. Graph RAG handles the second job: establishing dependency, ownership, entitlement, or policy scope. That distinction matters because a fluent answer can still hide a bad join.

There’s also a practical warning buried in the piece. Moving relationships away from operational data creates another place for staleness, another permission model, and another source of “which copy is current?” headaches. The cleaner approach is to keep the graph close to the records, inspect the exact path, and make the agent admit uncertainty when a required link is missing.