--- title: "Knowledge graph for LLM applications" description: "What a knowledge graph gives an LLM, what it costs to build, and the dimension a plain graph leaves out. Multi-hop questions, provenance, entity resolution, and why time changes the model." canonical: https://past.dev/knowledge-graph-for-llm last-updated: 2026-08-26 --- # Knowledge graph for LLM applications Source: https://past.dev/knowledge-graph-for-llm A knowledge graph gives an LLM typed entities and explicit relationships, so a question needing two or three hops is answered by traversal instead of by hoping the right passages were retrieved together. It is the right structure for multi-hop questions, for provenance and for constraints. What a plain graph does not carry is time: an edge is either present or absent, so a fact that changed leaves two edges and nothing that says which one holds now. Adding a validity window to every edge is what turns a knowledge graph into a memory. ## What is a knowledge graph in an LLM application? Entities as nodes, typed relationships as edges, and a query that walks them. In an LLM application the graph usually sits where a retriever would: the question is turned into a traversal, and the subgraph that comes back becomes the context. The difference from vector retrieval is what the unit of storage is. A vector index stores passages and returns the ones that resemble the question. A graph stores the claim itself, detached from the sentence that expressed it, which is what lets two facts from two documents combine into one answer. ## What a knowledge graph does well - **Multi-hop questions.** Who reports to the person who owns the account that raised this ticket. Similarity search has no mechanism for this: no single passage contains the answer, so no ranking can surface it. - **Provenance.** Every edge can carry the source it came from, which makes an answer auditable rather than plausible. - **Deduplication through identity.** Once two names resolve to one node, everything either name ever said is attached to the same subject. - **Constraints.** A typed schema can refuse a relationship that makes no sense, which catches a class of extraction errors before they reach a reader. - **Explainability.** The answer is a path, and a path can be shown. This is often the reason a regulated team can ship at all. ## What it costs to build A graph over structured records is cheap: you already have the entities and the keys. A graph over prose is not, and this is the part that decides whether the approach works for you. 1. **Extraction.** A model reads each document and proposes entities and relationships. This puts a language model in the write path, so ingestion cost scales with corpus size and the output is not deterministic. 2. **Entity resolution.** The proposed entities have to be matched against what already exists, or the graph fills with near-duplicate nodes. Resolution has to keep running as the graph grows, because the evidence that two names are the same subject often arrives later than both. 3. **Schema.** Either you define an ontology in advance, and pay for every type you failed to anticipate, or you let extraction invent types, and pay in inconsistency. 4. **Maintenance.** New documents contradict old edges. Something has to decide what happens then, and the choice is the whole design. If your corpus is small and static, this is more machinery than the problem needs, and [a vector database](/vector-database-for-rag) will do. ## The missing dimension: time In a plain graph an edge exists or it does not. When the budget moves from 32k to 40k, either you overwrite the edge, and lose the fact that it changed and when, or you add a second edge, and the graph now asserts both values with no way to rank them. The fix is to make time a property of the fact rather than of the document: every edge carries when it started holding and, if it stopped, when it stopped. A superseded fact stays in the graph, marked invalid from a date, so it can still answer what was the budget in March while what is the budget returns one value. This is usually called bi-temporal, because there are two clocks worth keeping. When something became true in the world, and when the system learned it. They differ whenever data is backfilled, which is most of the time in practice, and confusing them is how a system answers a question about last quarter with facts it only learned this week. ## Graphiti and Zep [Graphiti](https://github.com/getzep/graphiti) is an open-source framework for temporal graphs, Apache 2.0, maintained by Zep. It models ingested data as episodes, derives entity nodes and relationship edges from them, and gives facts validity windows: when information changes, the old fact is invalidated rather than deleted, and every derived fact traces back to the episode it came from. It runs on Neo4j, FalkorDB and Amazon Neptune. Zep is the managed product built on that engine, and the team published its architecture as a paper on temporal knowledge graphs for agent memory. If you want to own the graph and run it yourself, Graphiti is the most complete open-source option in this space today, and that is a straightforward recommendation rather than a hedge. past.dev is built on the same premise, that time belongs on the fact. The differences are in surface and operations rather than in principle: an `/answer` endpoint that returns a grounded answer with its evidence, its dollar cost and an explicit `abstained` flag; ingestion that takes raw text plus the timestamp it happened, backdated, with no schema to define first; and a deployment that runs on Postgres with pgvector rather than a dedicated graph database, self-hosted from the same image we run. [past.dev vs Zep](/vs/zep) is the side-by-side. ## Do you need to design an ontology? For a domain graph over records, yes, and it is the valuable part of the work. For a memory over conversations and documents, a hand-built ontology tends to be the thing that stalls the project: the types you anticipate are not the ones your data produces. past.dev does not ask for one. Extraction and resolution run on ingest and the graph is maintained on our side; a custom ontology is available for enterprise deployments where the domain genuinely has one. What you send is text and a timestamp. ## Frequently asked questions ### What is a knowledge graph for an LLM? A store of typed entities and explicit relationships that an LLM application queries by traversal instead of by similarity. It answers multi-hop questions, carries provenance on every edge, and makes an answer explainable as a path. ### Knowledge graph vs vector database: which is better for RAG? Neither dominates. A graph is precise about what was modelled and can combine facts from several documents; a vector index covers everything but justifies nothing. Graphs suit multi-hop questions over entities you can name, vectors suit open-ended questions over prose, and many systems run both. ### Can an LLM build a knowledge graph automatically? It can propose entities and relationships from text, which is how most graphs over prose are built. The hard part is not extraction but what comes after: matching each proposal against what already exists, and deciding what happens when a new document contradicts an old edge. ### What is a temporal knowledge graph? A knowledge graph where each fact carries a validity window, so a superseded fact is marked invalid from a date rather than deleted. It answers what is true now and what was true then from the same store. Bi-temporal graphs keep two clocks: when a fact held in the world, and when the system learned it. ### Do I need Neo4j to use a knowledge graph with an LLM? No. A dedicated graph database is one option, and Graphiti supports Neo4j, FalkorDB and Amazon Neptune. Graphs are also run on Postgres, which is what past.dev does, so a self-hosted deployment needs no database beyond the Postgres it already has. ## Related - [past.dev vs Zep](https://past.dev/vs/zep) - [Vector database vs graph database vs memory](https://past.dev/vector-database-vs-memory) - [What is agent memory?](https://past.dev/what-is-agent-memory) - [How the pipeline works](https://past.dev/docs/memory-api/how-it-works) - [How we measure memory](https://past.dev/benchmarks)