Agent Retrieval
Knowledge Graphs
When graph retrieval justifies its maintenance cost compared with vectors - condensed current practice
Last verified 2026-10-29
Knowledge graphs represent entities and relationships as nodes and edges. They excel at multi-hop reasoning and schema-driven queries, and they are a maintenance commitment - add one only when relationships are explicit and queried often.
When to use a graph
| Use case | Graph? | Why |
|---|---|---|
| Semantic search (synonyms, paraphrasing) | No | Vectors handle this |
| Multi-hop relationships (A → B → C) | Yes | Traversal is the native operation |
| Exact entity lookup by name | No | Index + SQL is simpler |
| Supply chain or org hierarchy queries | Yes | Relationship queries are the point |
| Recommendation (similar items) | No | Vectors are usually better and cheaper |
| Document Q&A | Maybe | Only if relationships genuinely matter to the answer |
GraphRAG versus LightRAG
GraphRAG builds entity communities and traverses them at query time; it is thorough and expensive. LightRAG indexes entities and relationships for more direct retrieval without full community-building. The LightRAG paper (October 2024) reports around 610K+ per query for the GraphRAG baseline against low hundreds of tokens for LightRAG - roughly three orders of magnitude. That is one comparison, on the paper's datasets, models and query mode (community-summary search for GraphRAG), with its own accounting of what counts as a query token. It is not the cost of every graph retrieval path, and it does not compare against the current Microsoft GraphRAG release. Read the paper's table and rerun a comparison on your own corpus before using the ratio to justify a technology choice.
Use GraphRAG when the domain has stable entities, multi-hop reasoning and global summarization across communities matter, and you can maintain entity resolution. Use LightRAG when graph structure helps but full community-building is too heavy, and update speed matters. Use neither first when the corpus is mostly unstructured prose with weak entity relationships - start with hybrid vector retrieval as a simpler baseline, and add a graph only if an shows it falls short.
Implementation shape
// Vector search narrows to candidate entities, then graph traversal expands from them
const nearestEntities = await pgvector.query(
`SELECT id, name FROM entities ORDER BY embedding <-> $1 LIMIT 5`,
[queryEmbedding],
);
const traversed = await neo4j.run(
`MATCH (n:Entity)-[*1..2]-(m:Entity) WHERE n.id IN $ids RETURN DISTINCT m.name, m.type`,
{ ids: nearestEntities.map((e) => e.id) },
);Neo4j is the common enterprise graph database; Memgraph is a self-hosted alternative with a source-available licence (Business Source License). Verify current project status and licensing before adopting either into a production dependency chain.