Vector databases made similarity search effortless and, in doing so, convinced a generation that retrieval equals embedding lookup. The production answer is almost always hybrid: dense vectors for meaning, lexical search for precision, rerankers for judgment — and a knowledge graph only where relationships are the product.

Each retrieval family fails in a characteristic, complementary way. Dense embeddings find conceptually related text and miss exact identifiers — a product SKU, an error code, a person's name — because they compress semantics and blur tokens. BM25 and friends nail identifiers and miss paraphrase. Graphs answer multi-hop relational questions ("which services owned by team A depend on the library B that just had a CVE?") that no embedding similarity will ever surface, at the cost of maintaining an ontology that rots without governance. Reranking models — cross-encoders reading query and candidate together — fix precision at the top of the funnel but cost too much to run over everything.

The standard production funnel composes them in cost order: hybrid candidate generation (dense + BM25 fused via reciprocal rank fusion), then a cross-encoder rerank of the top ~50, then optional graph expansion for queries that smell relational. Teams report the rerank step alone frequently worth more than the entire choice of vector index — RAG papers consistently show cross-encoder reranking beating index upgrades.

The decision heuristic for graphs: build one when queries are genuinely multi-hop and the graph is maintained by an existing process (code structure, org data), not hand-curated. A stale graph misleads with more confidence than an absent one — provenance and freshness beats completeness.