Knowledge graphs represent entities and the relationships between them; GraphRAG uses those links alongside text retrieval so answers can follow multi-hop paths across people, products, policies, and events. This is useful when a question depends on how things connect, not only which paragraph sounds similar.
Whilst a graph looks complete in a slide, in practice missing or stale edges break the chain. For example, “who owns pricing for account X?” fails if ownership was never synced from CRM. We often recommend graphs only where relationships are maintained as a product — with clear entity rules — and vectors for open-ended semantic lookup.
Vector RAG finds similar passages; graph-augmented retrieval adds explicit relationships so questions can chain across hops — who owns what, which policy applies, which case supports it. Knowledge graphs encode entities and typed edges; vectors still help discover entry points and unstructured proof. Cost is real: entity resolution, ontology discipline, and refresh pipelines matter as much as the query language. Use graphs when the question is relational; keep pure vector paths for open-ended semantic lookup. Wrong or stale edges produce confident multi-hop answers that are simply wrong.