12 min read
—
A partner at a mid-market fund asks the firm's AI assistant a simple question: who are the ultimate beneficial owners of Fund III's portfolio companies? The assistant returns a clean, confident list of eight. Three of them are wrong. Nobody notices until an LP asks the same question in a meeting.
That failure is the entire argument for caring about knowledge graph vs vector database, and it is not a failure of the model. The language model is fine. The retrieval is what broke. The ownership answer lives in the relationships between a limited partner, a fund, an offshore holding vehicle, and a portfolio company, and the system the firm used to find it was built to match similar text, not to follow a chain of ownership.
Here is the short version, for readers new to the debate. A vector database retrieves information by finding text that is semantically similar to your query. A knowledge graph retrieves information by traversing explicit relationships between entities. For private equity data, where the answer usually lives in the connections rather than in any single document, that difference decides whether the answer is right. For the wider context on where this fits, our guide to AI knowledge graphs for private equity covers the ground; this piece is about why one retrieval method hallucinates on your data and the other does not.
In this article:
How vector RAG works, where it is genuinely good, and the exact point it breaks on PE data.
What GraphRAG does differently, and what the accuracy research actually shows.
A head-to-head comparison, plus five PE queries where graph retrieval wins.
The two ways to build it, and how to get there without a graph database or a data-engineering team.
How vector RAG works, and where it breaks down
Vector-based retrieval is good at a specific job and bad at a different one, and most disappointment with it comes from using it for the second. Retrieval-augmented generation (RAG) is the technique of feeding a large language model (LLM) relevant source material at query time instead of relying on what the model memorised in training. The vector-database version does this by turning text into numbers and matching on similarity.
The mechanics, kept short
Your documents get chopped into chunks. Each chunk becomes an embedding, a fixed-length vector that captures its rough meaning. When you ask a question, your question becomes a vector too, and the system returns the chunks whose vectors sit closest to it. In plain terms: your confidential information memorandum, your diligence questionnaire, and your board minutes all become numbers, and the model retrieves the numbers nearest to your query. No graph traversal, no relationships, just proximity in a high-dimensional space. If you want the mechanism in full, our explainer on what RAG is covers it, and IBM's overview of retrieval-augmented generation is a clean primer.
Where vector RAG genuinely excels
Do not strawman vector search. For unstructured document questions it is fast, cheap, and often the right tool. Ask "find every memo that flags ESG risk" or "summarise what the last three research notes said about pricing," and semantic similarity does exactly what you want across large volumes of unstructured data. Most firms already run something like this, and for that class of question they should keep it. The generative AI use cases in finance that work well today are mostly this shape: read a document, answer a question about that document.
The structural blind spot: why relational PE data breaks embeddings
The blind spot is not a bug you can tune away. It is what an embedding is. Compressing a fund's ownership structure into a fixed-length vector is lossy by design, and the first thing it loses is the path. The chain from a limited partner, through a Cayman holding vehicle, into Fund III, and down to a portfolio company does not survive the trip into a single number.
So multi-hop questions fail. To answer "is this portfolio company ultimately owned by LP X," the system has to traverse four relationships in order. Similarity search cannot walk a path. It finds documents that are about ownership, not the ownership itself, and when the model is handed a pile of on-topic chunks that do not actually contain the answer, it fills the gap. That is where the confident, wrong list of beneficial owners comes from. Ask "who are the co-investors on our last three deals," and vector RAG retrieves the deal documents and then invents plausible co-investor names, because the co-investment relationship is not written in any one chunk. The hallucination is not random. It is the predictable output of asking a similarity engine a relationship question.
Getting private equity data right takes two things vector search lacks
The model gets your data wrong for two reasons, and neither is the model. It cannot follow the relationships in your data, and it has no memory of your firm. Fix one without the other and you still miss.
The first gap is relationships. The information that decides a PE question usually lives in the connections between entities, a company, its executives, the funds above it, the co-investors beside it, and not inside any single document. Retrieval that respects those relationships answers an ownership question by following the actual connections rather than guessing from text that happens to read similarly. This is not a fringe claim. Independent research on financial data, including a 2025 study on graph-based retrieval for finance and Microsoft Research's GraphRAG work and its method paper, has measured meaningfully fewer hallucinations when retrieval is built around relationships instead of similarity. On a fifty-million-dollar cap table, that gap is the difference between a defensible answer and a confident wrong one.
The information a PE firm relies on lives in the connections between funds, companies, and people, not in any single document a similarity search can retrieve.
The second gap is memory, and it is the one most tools ignore. A standard retrieval setup is stateless. It answers today's question from today's documents and remembers nothing: not the 400 companies you screened last year, not why you passed on 392 of them, not the sector view a partner built over a decade. For a fund, the value is cumulative. The firm that can ask "have we seen this management team before, and what did we conclude" holds an edge the firm starting from a blank prompt does not, and a system with no memory throws that edge away every session.
A firm reviews dozens of companies for every deal it closes. Without a memory, the ones it passes on leave nothing behind for the next screen.
Those two gaps, relationships and memory, are the real problem. The retrieval method is the easy part, and the part everyone can read a paper about. Building and keeping a living record of everything your firm has seen, resolved, queryable, and defensible, is the hard part. It is a product problem, not a prompt.
Knowledge graph vs vector database: the head-to-head
Put the two side by side and the decision stops being ideological and starts being about what kind of question you are asking. Neither wins everywhere. They win at different things, and a PE firm asks both kinds of question in the same afternoon.
Dimension | Vector database (RAG) | Knowledge graph (GraphRAG) |
|---|---|---|
Retrieval method | Semantic similarity | Graph traversal |
Best-suited data | Unstructured text, large document volumes | Entities and the relationships between them |
Multi-hop queries | Cannot traverse; tends to hallucinate | Deterministic and traceable |
Explainability | Low: it found similar text | High: it followed this path, A to B to C |
Engineering to set up | Low: embed and store | High if you build it yourself; low with a purpose-built platform |
PE accuracy | Strong for document search, weak for relational queries | Strong for relational queries |
Best PE use | CIM Q&A, research search, news monitoring | Cap tables, fund structures, board networks, deal relationships |
The verdict fits in one sentence. If your AI questions are about relationships rather than documents, a knowledge graph is meaningfully more accurate, and on PE data most of the questions that matter are about relationships.
Explainability is the row that gets underweighted, and for a regulated firm it should not be. When a vector system returns an answer, the honest account of how it got there is that it found some similar text. When a graph returns one, it can show the path it walked: this limited partner, into this fund, through this vehicle, into this company. That difference is invisible on a research query and decisive on anything that ends up in an investment committee memo, where a figure is only as trustworthy as the source behind it.
Retrieval method is one axis of a larger choice. A single-document Q&A tool and an end-to-end platform that resolves relationships across a whole portfolio are solving different problems.
Five private equity questions vector search gets wrong
The abstract case is settled. Here is the concrete one: five questions a deal team actually asks, why similarity search gets each wrong, and what a relationship-aware system returns instead. None of them is exotic. They are the job.
1. Cap-table ownership chains
The question: what is LP X's ultimate economic interest in a portfolio company, net of fees and carry. Vector search fails because the answer is spread across a subscription agreement, a holding-vehicle structure, and a shareholders' agreement, in three different formats, and no chunk holds the whole chain. A system that understands the ownership chain follows it, LP X into Fund III, through the holding vehicle, into the company, and returns the path with the economics attached. The path is the answer, and it is auditable.
2. Cross-fund sector exposure
The question: what is our total exposure to a given sector across Funds I, II, and III as a share of invested capital. Vector search can retrieve documents that mention the sector, but it cannot aggregate across three fund structures at once. A relationship-aware system follows each fund down to its portfolio companies, filters by sector, and sums the invested capital. What was a spreadsheet reconciliation becomes a question, which is the same shift that makes portfolio monitoring tractable at fund scale.
3. Board and governance conflicts
The question: do any of our portfolio-company directors also sit on a competitor's board. Vector search cannot connect "Person X is a director in this annual report" with "Person X is a director in that one," because the inference lives between two documents, not inside either. A system that holds the relationships surfaces every person on the board of both a portfolio company and a competitor, in one pass, which is exactly the connection similarity search is blind to.
4. Deal-network and referral mapping
The question: which advisors introduced our three best deals, and what else are they working on that we have not seen. Deal provenance sits in email threads, intro memos, and NDA registers, and no single chunk holds the advisor-to-deal-to-outcome relationship. A system that keeps those relationships follows the trail from each advisor to the deals they introduced and the outcomes that followed, ranked. That turns document search into proactive sourcing intelligence.
5. Due-diligence contradiction detection
The question: do the revenue figures agree across the memorandum, the management accounts, and the audited financials. Similarity search retrieves the relevant passages but cannot compare numbers across documents for a contradiction, because it has no structure to hold the ground truth against. A system that keeps each document's figures against the others flags the mismatches directly. The finance study behind these numbers found that structuring the data this way cut contradiction-detection complexity from quadratic to near-linear. It is the reliability floor under practical AI due diligence, and V7's AI due diligence agent runs the document side of it.
Build the infrastructure yourself, or give your firm a memory
The honest answer to "which one" is that a serious firm needs both kinds of retrieval: similarity search for the document questions, and relationship-aware retrieval for everything else. The decision that actually matters is not the technique. It is whether you assemble and maintain the machinery yourself or adopt a platform whose job is to be your firm's memory.
The build-it-yourself route is real, and for a few firms it is the right call. You stand up the infrastructure, design the schema, wire a pipeline from your documents, and keep all of it fed as new deals arrive. It is a data-engineering program measured in quarters, it carries a cold-start problem because nothing works until it is built, and the maintenance never ends. A large firm with a dedicated data team and a multi-year roadmap can make that pay. For most funds it is where the initiative quietly dies, because the firm wanted answers, not another system to run.
V7 Context Graph is the other route, and the name is worth being precise about: knowledge graph is the general category this whole comparison has been about, while Context Graph is V7's specific product, its own implementation of that category rather than a generic graph database. It is the firm's memory, built from the documents you already have: every company evaluated, every deal considered, every general-partner relationship, held in one place and queryable in plain language. It treats the same company, named three different ways across a memorandum, a filing, and a portfolio report, as one company, so a question draws on everything the firm knows rather than a fraction of it. When a new memorandum arrives, the screening agent works from the Context Graph instead of a blank prompt, surfacing the firm's prior view of the sector and the reason it passed last time.
Two things separate this from a smarter search box. Every answer traces back to the exact sentence or cell it came from, which is what lets a figure survive an investment committee.
Each figure here is stamped with the document it came from and when it was pulled. That citation is the traceability a vector search cannot offer, because similarity search has no notion of which chunk is ground truth.
And the record is persistent: the knowledge that used to leave when an analyst left the firm stays, and every document processed sharpens the next screen. The advantage is not a retrieval trick a competitor can copy in a weekend. It is your firm's own accumulated context, which no one else has and no one else can rebuild. The output is not a file, either. Context Graph is the operational layer where the team reviews and acts, with structured results flowing onward to a CRM or an existing system through an API or connector when the workflow calls for it.
How V7 Go handles finance workflows, from DDQ completion to CIM extraction, with every answer traceable to its source and held in the firm's Context Graph.
Context Graph in use: the firm's funds, companies, and relationships in one place, answering across everything it has seen rather than a single document.
Strip away the vocabulary and the choice is not really between two databases. It is between a system that guesses at your firm's relationships and one that can show you the path. On a research note, a guess is cheap. On a cap table, it is not.
The practical move is not to pick a side. It is to match the retrieval method to the question: vector search for the document work, graph retrieval for anything relational, and a build path that does not put a data-engineering project between you and your first answer. Start with the query that has burned you, the ownership chain the model got wrong, and work outward from there.
If you want to see it on your own documents, V7 runs a working session built around your data: your cap tables, your fund structures, your deal history, resolved into a Context Graph and queried live. That is the next step, and it takes about the length of a partner meeting.
What is the difference between a knowledge graph and a vector database?
A vector database stores text as numerical embeddings and retrieves information by semantic similarity, returning the passages whose meaning is closest to your query. A knowledge graph stores entities and the relationships between them explicitly, and retrieves information by traversing connection paths. The distinction matters most when the answer lives in relationships rather than in any single passage. For ownership structures, organisational charts, and deal networks, a knowledge graph is more accurate because it can follow a chain of connections. For unstructured document search, such as summarising a memorandum or searching research notes, a vector database is faster and simpler to deploy. Most private equity teams end up using both, matched to the type of question being asked.
+
What is GraphRAG and how does it work?
GraphRAG combines a knowledge graph with retrieval-augmented generation. When a large language model receives a query, GraphRAG traverses the knowledge graph to retrieve the relevant entities and the relationships between them, then passes that structured context to the model alongside any retrieved documents. Because the model reasons over an explicit relationship path rather than a set of loosely similar text chunks, its answers on relational questions are more accurate and, importantly, traceable: you can see which nodes and edges produced the result. Microsoft Research published the canonical GraphRAG work, and independent studies on financial data have measured meaningful reductions in both hallucination rate and token consumption compared with conventional retrieval-augmented generation.
+
Can knowledge graphs reduce LLM hallucinations?
Yes, particularly on relational questions where conventional retrieval tends to fail. A 2025 study on finance data, presented at the GenAIK workshop, found that graph-based retrieval reduced hallucinations by 6% and token usage by 80% compared with conventional retrieval-augmented generation. The mechanism is straightforward: hallucinations often occur when a model is handed documents that are about a topic but do not contain the specific relationship being asked for, so it fills the gap. A knowledge graph supplies the actual relationship path instead of leaving the model to infer it. For private equity, where a wrong ownership percentage or board relationship can feed an investment decision, that accuracy improvement is material rather than cosmetic.
+
Do I need a vector database if I have a knowledge graph?
In most private equity deployments, yes, because the two handle different retrieval tasks. A knowledge graph is strongest on relational queries: cap tables, fund structures, board networks, and the connections between entities. A vector database is strongest on unstructured document search: summarising a confidential information memorandum, searching across research notes, or monitoring news. Treating the choice as either-or usually leaves gaps. The most effective systems use a hybrid architecture, routing document questions to vector search and relationship questions to graph retrieval. The practical challenge is building the graph half without a long infrastructure project, which is why document-indexed approaches that extract relationship structure from existing files have become the common route for firms without a data-engineering team.
+
What is multi-hop reasoning in AI?
A graph database, such as Neo4j, ArangoDB, or Amazon Neptune, is infrastructure: the system that stores and queries graph-structured data using languages like Cypher or Gremlin. A knowledge graph is the semantic layer: the representation of entities, relationships, and domain knowledge. A knowledge graph is often stored in a graph database, but it does not have to be. Document-indexed approaches build the relationship structure directly from existing documents and resolve relationships at query time, which delivers graph-equivalent retrieval without standing up and maintaining a separate graph database. The distinction matters for private equity firms weighing how to build, because it separates the capability they want, relationship-aware retrieval, from the infrastructure they may not want to operate.
+
What is the difference between a knowledge graph and a graph database?
Go is more accurate and robust than calling a model provider directly. By breaking down complex tasks into reasoning steps with Index Knowledge, Go enables LLMs to query your data more accurately than an out of the box API call. Combining this with conditional logic, which can route high sensitivity data to a human review, Go builds robustness into your AI powered workflows.
+
Casimir is a seasoned tech journalist and content creator specializing in AI implementation and new technologies. His expertise lies in LLM orchestration, chatbots, generative AI applications, and computer vision.
