"We tried RAG and it was disappointing" is one of the most common sentences in enterprise AI, and the disappointment is usually real and usually misdiagnosed. The retrieval worked. It returned passages that resembled the question. The problem is that resemblance is not the relationship the question depended on.
What similarity search is good at
Embed your documents, embed the question, return the nearest passages. For a certain kind of question this is excellent: what does our refund policy say about damaged goods has an answer that lives in one place and is worded much like the question.
Most business questions are not that shape.
Is this customer worth escalating? has no passage. The answer is assembled from a support thread, a CRM record, an invoice and a renewal date, four systems that share no vocabulary. Nothing in the ledger is worded like the question. Similarity search returns the support thread, because the support thread sounds most like a customer complaint, and the model answers from a quarter of the evidence while sounding entirely certain.
The missing primitive is identity
The thing that makes the question answerable is knowing that sam@bigco.com in the mailbox, "Sam Lee" on the ticket, contact 0012f in the CRM and "BigCo Ltd" on the invoice are the same two entities: one person, one company.
That is not a similarity judgement. It is an identity judgement, and it either resolves or it does not. Once it resolves, a question about BigCo can start at BigCo and walk outward — its people, its tickets, its invoices, its deals, its renewal — rather than fishing in a pool of text for passages that mention it.
This is what a graph gives you that an index does not: not better recall, but a structure where "everything we know about this company" is a traversal rather than a search.
Three questions that separate them
"What changed?" A vector index stores the current text. Ask what you believed about a deal in July and there is nothing to query — July's version was overwritten in August. A graph that records when each fact was believed, and keeps the old one when a newer one supersedes it, can answer it directly.
"How do you know?" Similarity search returns a passage, and the passage is the evidence, which is fine until the passage was itself a summary of something else. A fact anchored to the system, record id and URL it came from can be checked in one click, and more importantly it can be corrected — you can supersede the fact without re-indexing the document.
"Is this the same thing as that?" Deduplication is hard in an index and structural in a graph. Five tickets asking for SSO are five passages to a vector store. To a graph they are five requests attached to one feature, raised by four customers with a combined ARR you can add up — which is the form the question was actually asked in.
Where similarity still earns its place
None of this means embeddings are the wrong tool. They are the right tool for the step where a question in someone's words has to find its way to the entities and facts it is about, and they are irreplaceable for genuinely fuzzy recall — that thing somebody said about procurement, I think in spring.
The useful architecture uses both, and the order matters. Vector similarity and full-text rank, fused, to find the candidates. Then the graph: pull in the facts attached to any entity the question names, and one hop out from there, because the renewal date lives on the company and the question was about the ticket.
Retrieval gets you to the neighbourhood. The graph is what makes the neighbourhood worth arriving in.
The practical test
Before buying anything in this category, write down the five questions you actually want answered. Then check how many of them have an answer that lives in a single passage in a single system.
If it is most of them, a well-built RAG pipeline will serve you and you should not over-engineer. If it is almost none of them — and in most companies it is almost none of them — then no amount of embedding quality will fix what is missing, because the thing that is missing is the knowledge that two records are the same customer.