ai · 1 min read
GraphRAG: When Vector Retrieval Is Not Enough
Graph-augmented RAG combines vector search with Postgres-backed knowledge-graph hops for multi-hop questions that pure vector retrieval misses. Here is how Bhogar ships it today.
BABhogar AI TeamProduct & Engineering
There is a class of questions vector RAG simply cannot answer well: "Which of our customers in healthcare also use AWS and were referenced in last quarter's board update?" Multi-hop reasoning needs structure, and structure needs a graph.
Why it matters
Building a knowledge graph used to mean a 6-month ontology project. LLM-assisted extraction has cut that to days. Bhogar stores entities and relationships in Postgres (`kb_entities` / `kb_relationships`) - not a separate graph database - so the graph stays tenant-scoped beside your vectors.
How Bhogar AI approaches it
Bhogar ships graph-augmented retrieval as an opt-in layer: enable `enable_knowledge_graph` on a KB, LLM extract runs on ingest, hop queries expand seed entities, and RAG search can boost vector hits that match graph entities. Agents also get a real `manage_knowledge_graph` tool backed by the same tables.
- Opt-in LLM entity/relationship extraction on document ingest
- Hop traversal and graph visualization in the Knowledge Graph explorer
- Vector search graph boost when engine plan sets `use_graph`
- Ontology constraints feed extraction types (classes/properties in Portal)
- Per-tenant, per-KB graph isolation in Postgres
What you get
Teams report better recall on multi-hop questions when graph extraction is enabled and kept fresh - without standing up Neo4j or writing Cypher. Formal OWL/Cypher/SPARQL remain on the roadmap.