A vector store retrieves text that resembles your query. That is the wrong instrument when the answer depends on how entities connect rather than how they read. Questions like “what is our exposure to anything the Petrov family controls” or “which counterparties sit two hops from a sanctioned issuer” are traversal problems. GraphRAG answers them by walking a graph of issuers, counterparties and ownership.
The failure mode of pure vector RAG in finance is quiet. You ask about a company’s ultimate parent, the retriever pulls three chunks that mention the company by name, and the model summarises them fluently. None of the chunks actually state the ownership chain, because that chain is spread across four filings that never share vocabulary. The model fills the gap. You get a confident answer with a fabricated parent in it, and nothing in the pipeline flagged that the relationship was never retrieved.
Where similarity stops working
Embedding similarity collapses meaning into distance. That is fine for “find documents about interest rate risk” and useless for “find the shortest control path between these two funds.” A few concrete cases where we stop reaching for the vector index:
- Indirect exposure. Direct holdings are a lookup. Exposure through a chain of intermediate holding companies is a graph walk, and the depth is not known in advance.
- Beneficial ownership. Ultimate beneficial owner is defined by control thresholds accumulated along paths. You cannot compute it from any single document, and you cannot embed your way to it.
- Counterparty contagion. “Who is affected if this issuer defaults” is a reachability query over guarantee, parent and lending edges.
- Circularity and conflicts. Cross-holdings and related-party structures are cycles in the graph. Similarity search has no concept of a cycle.
The common thread is that the unit of retrieval is a path or a neighbourhood, not a passage. A store that only knows how to rank passages by cosine distance has no way to represent, let alone return, the thing you need.
Building the graph that GraphRAG retrieves over
The retrieval quality of a GraphRAG system is set almost entirely upstream, by the graph itself. Two decisions dominate.
First, the nodes have to be resolved before they are useful. If “Meta Platforms”, “Facebook, Inc.” and an LEI end up as three separate nodes, every traversal fragments and the ownership chain breaks at the seams. Entity resolution is the precondition, not an optimisation. The canonical entity from your resolution layer becomes the node; every raw identifier from every feed becomes an alias pointing at it.
Second, the edges have to be typed and dated. A generic “related to” edge is close to worthless. We model distinct relationships and keep their provenance:
- Ownership edges carry a percentage and a direction, so control thresholds can be summed along a path.
- Guarantee, parent-subsidiary and lending edges are separate types, because a contagion query treats them differently.
- Every edge carries valid-from and valid-to dates taken from the filing that asserted it, plus a pointer back to that source document.
That temporal layer is what makes the graph safe to query historically. A backtest that asks about ownership “as of Q2 2024” must traverse only the edges that were live then. Without valid-time on edges, a 2025 restructuring leaks backward into a 2024 answer, and you have manufactured lookahead in the most invisible way possible. Point-in-time correctness in a graph is a property of the edges, not an afterthought in the query.
The graph is not static. Corporate actions rewrite it constantly: a merger folds two nodes into one, a spin-off splits one into two, a change of control flips the direction of an ownership edge. We treat ingestion of corporate actions as a first-class pipeline with its own lineage, so that every structural change to the graph traces to the filing that caused it. When an auditor asks why the system believed entity A controlled entity B on a given date, the answer is an edge with a document reference and a date range, not a vector similarity score.
Retrieval, and why hybrid usually wins
At query time, GraphRAG does the traversal the vector store cannot. A question is decomposed into an anchor (the entity you start from), a relationship pattern, and a depth bound. The retriever walks the graph, collects the relevant subgraph, and serialises it into context the model can read: nodes with their canonical names, edges with their types and dates, and the source references attached.
The subgraph, not a pile of loose passages, is what grounds the generation. Because each edge names its source filing, the model’s answer can cite the actual document that established each link. When the graph contains no path between two entities, the honest output is “no relationship found in the graph as of this date,” and that is a far better answer than a plausible invention.
Almost no real question is purely structural, though. “Summarise our exposure to the Petrov network and explain the nature of each relationship” needs the graph for the network and unstructured text for the nature. So production systems run both retrievers and merge. The graph resolves who connects to whom; the vector index over filings and memos supplies the descriptive detail the edges do not carry. Keep the two indexes reconciled against the same resolved entity set, or you reintroduce the fragmentation the graph was built to remove.
The graph does not remove the need for evaluation. Build an eval set of relationship questions with known answers, including the hard ones: multi-hop control, cyclic holdings, and as-of queries that must respect valid-time. Score retrieval separately from generation, because a correct answer built on the wrong subgraph is luck, and luck does not survive the next corporate action.
FAQ
When should I reach for a graph instead of a vector store?
When the question is about paths and structure rather than resemblance: shared ownership, indirect exposure, ultimate beneficial owner, or who sits between two counterparties. Vector search finds text that looks similar; it cannot count hops.
Do I still need embeddings if I build a knowledge graph?
Usually yes. The graph answers the structural half of the question and the vector index answers the descriptive half. Most production systems run both and merge results.
How do you keep the ownership graph point-in-time correct?
Every node and edge carries valid-from and valid-to dates sourced from the filing that asserted it. A query as of a past date traverses only edges that were live then, so a later restructuring does not leak backward into the answer.