Knowledge Graphs for AI Applications

What Knowledge Graphs Are and How They Work

A knowledge graph is a data structure that represents information as a network of entities (nodes) connected by typed relationships (edges). Each entity is a real-world concept, object, person, technology, or idea. Each relationship describes how two entities are connected. The combination of entity, relationship, and entity forms a triple, the atomic unit of knowledge in a graph.

For example, the statement "Stripe handles payment processing for the checkout service" becomes two entities (Stripe, checkout service) connected by a relationship (handles payment processing for). The statement "the checkout service uses PostgreSQL for order storage" adds another entity (PostgreSQL) and another relationship (uses for order storage). Together, these triples form a small graph that encodes the architecture of a payments system. A query about "database issues affecting payments" can now traverse from payments to checkout service to PostgreSQL, even though the word "payments" never appears in the PostgreSQL documentation.

This traversal capability is what distinguishes knowledge graphs from other data structures. A relational database stores this information in rows and columns, but cannot follow implicit connections without explicit joins that a developer must write in advance. A vector database stores it as embeddings, but the connection between "payments" and "PostgreSQL" only exists if the training data or embedded text mentions both together. A knowledge graph stores the connection explicitly, so it can be traversed regardless of vocabulary overlap.

Knowledge graphs have existed in various forms for decades. Google's Knowledge Graph, launched in 2012, powers the information panels in search results. Wikidata stores over 100 million entities in a public knowledge graph. What has changed recently is the ability to build domain-specific knowledge graphs automatically using LLMs for entity extraction and relationship identification, making the technology accessible to any AI application rather than only to organizations with dedicated knowledge engineering teams.

Why Vector Search Alone Is Not Enough

Vector search works by encoding text into high-dimensional vectors (embeddings) and finding the vectors closest to the query embedding. This approach excels at finding documents that discuss the same topic using similar language. When a user asks "how do I reset my password" and you have a document titled "Password Reset Guide," vector search finds it reliably because the query and the document share vocabulary and semantic meaning.

Vector search fails in three categories that matter for production applications. First, it fails on multi-hop reasoning. When the answer requires following a chain of relationships (user asked about X, which is caused by Y, which is configured in Z), vector search only finds documents semantically similar to X. It cannot follow the chain to Z because there is no vocabulary overlap between the question about X and the documentation about Z. Second, it fails on exact-match queries. When a user asks "what version of React are we using," the answer is a specific string ("18.2.0") in a configuration file. Embedding similarity is weak for exact matches because the semantic distance between "React 18.2.0" and "React version" is noisy in embedding space. Third, it fails on negation and absence. Asking "which services do NOT use authentication" requires reasoning about what is missing from the graph, something that similarity cannot express.

Knowledge graphs address all three failures. Multi-hop queries follow relationship chains through the graph, regardless of vocabulary. Exact-match queries look up entity properties directly. Absence queries check which entities lack a specific relationship type. The trade-off is that knowledge graphs require more infrastructure than vector search (entity extraction, relationship identification, graph storage) and the graph must be maintained as the underlying knowledge changes.

The strongest retrieval systems combine both approaches. Vector search provides broad recall by finding semantically relevant content. The knowledge graph provides precision by following entity relationships to find the specific, connected information that vector search misses. This combination is the foundation of GraphRAG, and it consistently outperforms either approach alone.

GraphRAG: Combining Graphs with Retrieval

GraphRAG is an architecture that augments traditional RAG with knowledge graph traversal. In a standard RAG pipeline, the user's query is embedded, similar chunks are retrieved from a vector database, and those chunks are included in the LLM's prompt as context. In a GraphRAG pipeline, an additional step extracts entities from the query, looks them up in the knowledge graph, traverses their relationships to find connected entities, and retrieves content associated with those connected entities. The graph-retrieved content is combined with the vector-retrieved content, giving the LLM both semantically similar and structurally connected information.

The practical impact is measurable. Microsoft Research's GraphRAG paper (2024) demonstrated that community-based graph summarization improved answer comprehensiveness by 30 to 70% on complex queries compared to standard RAG. Other benchmarks show that adding graph traversal to vector retrieval improves recall from roughly 78% to 91% on multi-hop questions, the category where vector search alone performs worst.

There are two primary approaches to GraphRAG. The first is entity-centric: extract entities from the query, find them in the graph, traverse their immediate relationships, and retrieve the associated content. This is fast (graph lookup plus one or two hops) and works well when the query explicitly mentions known entities. The second is community-based: pre-compute community summaries of densely connected entity clusters, and retrieve the community summaries relevant to the query. This is better for broad, open-ended questions ("tell me about the architecture of the payments system") because it provides thematic overviews rather than individual entity details.

Adaptive Recall implements entity-centric GraphRAG through its graph traversal tool. When a memory is stored, entities and relationships are automatically extracted and added to the knowledge graph. When a memory is recalled, the system identifies entities in the query, traverses their connections using spreading activation (weighted by connection strength and recency), and boosts the retrieval scores of memories connected to activated entities. This happens alongside vector similarity scoring, so the final ranking reflects both semantic relevance and structural connectivity.

Building a Knowledge Graph

Building a knowledge graph involves three stages: entity extraction, relationship identification, and graph storage. Each stage has multiple implementation approaches with different trade-offs in accuracy, cost, and complexity.

Entity Extraction

Entity extraction identifies the meaningful things mentioned in text: people, organizations, technologies, concepts, products, locations, and any domain-specific entities relevant to your application. Traditional approaches use named entity recognition (NER) models trained on specific entity types. Modern approaches use LLMs to extract entities in a single prompt, which handles a broader range of entity types but costs more per extraction.

For most AI applications, LLM-based extraction is the pragmatic choice because it handles domain-specific entities without training data. A prompt like "Extract all entities (people, technologies, organizations, concepts) from this text and return them as a JSON array" works reliably with current models. The trade-off is cost: extracting entities from 10,000 documents with an LLM costs significantly more than running a NER model, but the LLM handles ambiguous and domain-specific entities that NER models miss.

Relationship Identification

Relationship identification determines how extracted entities connect to each other. The simplest approach is co-occurrence: if two entities appear in the same document or paragraph, they are related. This creates a connected graph with minimal effort but produces noisy, untyped relationships. A better approach uses LLMs to extract typed relationships: "Stripe handles payments for checkout" yields a relationship of type "handles payments for" between entities "Stripe" and "checkout." Typed relationships enable more precise traversal because the system can distinguish between "depends on," "is authored by," and "is located in."

The standard representation for relationships is the triple: subject, predicate, object. "Stripe" (subject) "handles payments for" (predicate) "checkout service" (object). Triples compose naturally. Adding "checkout service" "stores data in" "PostgreSQL" extends the graph without modifying existing triples. This composability is why knowledge graphs scale well conceptually, new information extends the graph without restructuring it.

Graph Storage

Graph databases like Neo4j are purpose-built for storing and querying knowledge graphs. They use the property graph model, where nodes have labels and properties, and edges have types and properties. Cypher, Neo4j's query language, makes graph traversal intuitive: MATCH (a)-[:DEPENDS_ON]->(b)-[:USES]->(c) WHERE a.name = 'checkout' RETURN c finds everything that checkout's dependencies use.

For smaller graphs (under 100,000 entities), a relational database with a triples table (subject, predicate, object columns) works fine and avoids the operational complexity of a separate graph database. PostgreSQL with recursive CTEs can handle multi-hop traversal efficiently up to moderate graph sizes. For applications using Adaptive Recall, the knowledge graph is managed automatically as part of the memory system, so you do not need to operate separate graph infrastructure.

Graph Traversal and Spreading Activation

Graph traversal is the process of following relationships from a starting entity to discover connected information. The simplest traversal is a breadth-first search: start at an entity, visit all directly connected entities (depth 1), then visit all entities connected to those (depth 2), and so on. Depth-limited traversal (typically 2 to 3 hops) prevents the explosion of results that occurs in densely connected graphs.

Spreading activation is a more sophisticated traversal strategy borrowed from cognitive science. In the ACT-R cognitive architecture, activating one concept in memory "spreads" activation to related concepts, with activation strength decreasing at each hop. This models how human memory works: thinking about "coffee" activates "morning," "caffeine," and "mug" at varying strengths. Applied to knowledge graphs, spreading activation starts at the entities mentioned in a query, assigns them initial activation values, and then propagates activation through the graph's edges with decay at each step.

The decay factor controls how far activation spreads. A decay of 0.5 means that direct connections receive half the starting activation, two-hop connections receive one-quarter, and three-hop connections receive one-eighth. This naturally prioritizes closely connected information while still surfacing distant but relevant connections. The optimal decay factor depends on the density of your graph: sparse graphs benefit from lower decay (wider spread) while dense graphs need higher decay (narrower spread) to avoid activating everything.

Spreading activation is particularly valuable for ambiguous queries. When a user asks about "performance issues," activation spreads from "performance" to "latency," "throughput," "CPU usage," "database queries," and "caching," weighting each by connection strength. The memories most connected to the activated cluster surface first, even if they do not contain the word "performance." This is the core mechanism that lets knowledge graphs find what vector search misses.

The Triple: Subject, Predicate, Object

The triple is the fundamental unit of knowledge in a graph. Every fact, relationship, and connection is expressed as three parts: a subject (the entity the statement is about), a predicate (the relationship type), and an object (the entity or value the subject is related to). This structure comes from the Resource Description Framework (RDF) standard, which has been used for knowledge representation since the late 1990s.

Triples are powerful because they compose without schema changes. In a relational database, adding a new type of relationship requires altering the schema, adding a column, or creating a junction table. In a knowledge graph, a new relationship type is just a new predicate. You can add "Stripe" "was founded in" "2010" alongside "Stripe" "handles payments for" "checkout" without modifying any existing structure. This flexibility is critical for AI applications where the types of knowledge being stored are not known in advance.

Predicate normalization matters for traversal quality. If one document says "uses" and another says "utilizes" and a third says "depends on," you have three predicates that may represent the same relationship. LLM-based extraction can normalize predicates to a controlled vocabulary, or you can apply synonym resolution after extraction. The goal is a graph where traversal along a relationship type finds all instances of that relationship, not just the ones that happened to use the same word.

Reification extends triples with metadata about the statement itself. "Stripe handles payments for checkout" is a fact, but "as of January 2026, Stripe handles payments for checkout, with confidence 0.9" adds temporal scope and certainty. In practice, reification is implemented by treating the triple as an entity itself and attaching metadata properties. This enables the graph to represent not just what is true, but when it was established, how confident the system is, and what evidence supports it.

Keeping Graphs Accurate Over Time

A knowledge graph that is not maintained degrades in value as the underlying reality changes. Technologies get replaced, team members change roles, services get deprecated, and configurations get updated. Stale graph data does not just fail to help, it actively harms retrieval by surfacing outdated connections that lead to wrong answers.

There are three approaches to graph maintenance, ordered by increasing automation. Manual maintenance requires someone to update the graph when changes occur. This is accurate but does not scale and depends on humans remembering to update the graph. Event-driven maintenance hooks into the systems that produce changes (code commits, configuration updates, documentation edits) and triggers graph updates automatically. This scales but requires integration work. Continuous extraction periodically re-processes source documents and compares the extracted graph against the existing graph, identifying additions, deletions, and modifications. This catches changes that no event triggers, like gradual drift in how teams describe their architecture.

Adaptive Recall uses continuous extraction as part of its memory consolidation process. When memories are consolidated, the entities and relationships mentioned in those memories are re-evaluated. New entities are added to the graph. Entities that no longer appear in any active memory have their connections weakened (but not immediately deleted, since they may still be valid). Contradictory relationships are flagged for resolution. This keeps the graph aligned with the current state of the memory system without requiring manual maintenance.

Confidence scoring adds another layer of maintenance. Each triple in the graph carries a confidence score that reflects how well-supported the relationship is. A relationship mentioned in 10 memories with consistent wording has high confidence. A relationship mentioned once and never corroborated has low confidence. When contradictory evidence appears (a new memory says "checkout now uses Braintree" while the graph says "checkout uses Stripe"), the system reduces confidence on the old triple and adds the new triple at moderate confidence, letting the evidence accumulate before committing to either version.

Cost and Complexity Considerations

Knowledge graphs add infrastructure complexity that vector-only systems avoid. Entity extraction adds an LLM call per document during ingestion. Graph storage adds a database to operate (or a graph layer within your existing database). Traversal adds latency to each retrieval query. These costs are real and should be weighed against the retrieval quality improvements for your specific use case.

For applications where queries are mostly single-topic lookups ("what is our refund policy," "how do I deploy to staging"), vector search handles 90% of cases well and the additional complexity of a knowledge graph may not be justified. For applications where queries involve multi-entity reasoning ("what downstream services are affected if Redis goes down," "which team members have worked on both the payments and authentication systems"), knowledge graphs provide answers that vector search cannot.

The build-versus-buy decision matters here. Building a knowledge graph from scratch requires entity extraction, graph storage, traversal logic, and maintenance pipelines. Each component requires engineering time and operational attention. Using a system that includes graph capabilities as part of its memory architecture (like Adaptive Recall) eliminates the infrastructure burden while providing the retrieval quality benefits. The entities, relationships, and traversal are handled automatically as part of the memory storage and retrieval workflow.

At scale, knowledge graphs become more valuable rather than less. A graph with 1,000 entities and 3,000 relationships provides modest improvement over vector search. A graph with 100,000 entities and 500,000 relationships provides substantial improvement because the density of connections enables multi-hop traversal paths that vector search cannot replicate at any scale. The investment in building the graph pays increasing returns as the knowledge base grows.

Implementation Guides

Building and Querying

Infrastructure and Maintenance

Core Concepts

Fundamentals

Advanced Topics

Common Questions