The knowledge graph era is reborn with LLMs

Actualizado: 2026-05-03

Knowledge graphs spent a decade in the background: thesis territory, academic niche, a Google internal project nobody else knew how to replicate at scale. In 2025 they’re back in the foreground, and the reason is concrete. LLMs need an anchoring layer to stop hallucinating, to reason over private data without retraining, and to let agents justify their decisions. That layer is, increasingly, a graph.

Key takeaways

• LLMs have collapsed knowledge graph construction cost on two fronts: entity extraction from unstructured text and schema maintenance without a permanent ontologist.
• The four patterns with concrete results are: graph-backbone RAG, reasoning auditability, structured memory for agents, and heterogeneous-source integration.
• Evaluating LLM-generated graphs has no stable benchmarks; each company invents its own metric.
• Neo4j dominates enterprise deployments but its licence complicates at-scale use without paying; DuckDB, Kuzu and Memgraph target the embedded graph case.
• The per-session ephemeral graph is the most interesting pattern for avoiding the hard problem of keeping a global graph up to date.

What changed since 2015

Ten years ago, building an enterprise knowledge graph was a two-year project with a team of ontologists. You defined an exhaustive schema, loaded data through heavy ETL, then served it via SPARQL to three apps nobody used. The problem wasn’t the graph technology; it was the cost of populating and maintaining the schema.

LLMs have collapsed that cost on two fronts. First, extracting entities and relations from unstructured text went from a classical NLP project with mediocre precision to a model call with a well-designed prompt. Second, schema maintenance no longer requires a permanent ontologist: the model proposes relations, a human validates, the graph evolves.

Microsoft published GraphRAG in late 2024 and the community reaction was immediate. What GraphRAG demonstrated wasn’t conceptually new (anchoring generation in graphs is an old idea) but that a modern LLM ingestion pipeline can build, in hours, a dense graph from a corporate corpus. That economic shift opened the door to current adoption.

Patterns working in production

Four patterns are delivering concrete results in companies that deployed them over the past year:

• Graph-backbone RAG. Instead of searching chunks purely by vector similarity, the graph guides retrieval: first it identifies entities relevant to the query, then extracts the subgraph of their neighbourhood and hands the LLM a connected context instead of isolated fragments. For queries requiring you to relate multiple entities, the graph is dramatically better than similarity. It directly complements continuous RAG evaluation practices.
• Reasoning auditability. An agent drawing a conclusion can cite the graph path supporting it. That trace is reproducible and reviewable by a human. For regulated sectors (banking, healthcare, legal) this ability to justify has moved from desirable to requirement.
• Structured memory for agents. Instead of letting the agent accumulate free text in conversational memory that grows unbounded, the agent writes structured facts into a graph. Future queries are deterministic, token cost stays low, and state is debuggable.
• Heterogeneous-source integration. A graph with aliases and reconciliation lets you unify the same entity when it appears with slightly different names in CRM, ERP, helpdesk and emails. That work was expensive before; now the LLM proposes reconciliations and the graph consolidates them.

The barriers still standing

Three real frictions are slowing development:

1. Evaluation is hard. Measuring the quality of an LLM-generated graph has no stable benchmarks. Each company ends up inventing its own metric (edge precision, entity coverage, temporal consistency) and comparing implementations is tricky.
2. Live maintenance. A graph is useful when it reflects reality. If source data changes and the graph doesn’t update, contradictions appear that confuse the LLM more than help. Automating change detection and incremental re-extraction is a problem without a standard solution yet.
3. Technology choice. Neo4j dominates enterprise deployments but its licence complicates at-scale use without paying. TigerGraph and Memgraph compete on query performance. DuckDB with graph extensions, Kuzu and other recent projects target embedded graphs. The choice depends on volume, required latency, and whether the graph is ephemeral (regenerable) or canonical (source of truth).

The case catching my attention

A particularly interesting pattern is the per-session ephemeral graph. Instead of maintaining a canonical corporate graph, the system builds on the fly a small graph covering the current query. For each question, it extracts mentioned entities, loads their neighbourhood from the document store, and generates a working graph with tens or hundreds of nodes. The LLM answers with that bounded context and the graph is discarded.

The advantage: no need to solve the hard problem of keeping a global graph up to date. The downside: each query pays a construction cost. For use cases with repeated questions over a bounded domain, subgraph caching amortises the cost.

My read

The return of the knowledge graph isn’t nostalgia or hype: it’s a concrete answer to the limitations of pure LLMs. The model alone, however good, can’t guarantee consistency between responses separated by weeks, can’t explain why it reached a conclusion, and can’t reason over data it didn’t see in training. The graph covers those gaps.

What strikes me is that this time adoption looks sustainable. In 2015, knowledge graphs were projects that failed because of construction cost. In 2025, the same team that would have needed two years can put a useful graph live in weeks, because the LLM does the heavy extraction work and the human ontologist only defines the minimal schema.

My bet is that in the next twelve months data teams without an explicit graph + LLM strategy will fall behind in cases requiring cross-source reasoning over heterogeneous data. Not because of hype, but because those who have one will answer questions others simply can’t. This structured-memory pattern also feeds the more advanced community MCP servers.