Context Graph overview | Zep Documentation

A Context Graph represents facts, their relationships, the source episodes from which Zep derived them, and how they change over time. Teams use Context Graphs for enterprise knowledge, agent memory, and customer or account context.

Zep uses Graphiti, its open-source temporal graph framework, to derive graph artifacts from episodes. Konig is Zep’s graph database service. You do not need to interact with Graphiti or Konig when you use the Zep service.

What is a Knowledge Graph?

A knowledge graph is a network of interconnected facts, such as “Kendra loves Adidas shoes.” Each fact is a “triplet” represented by two entities, or nodes (“Kendra”, “Adidas shoes”), and their relationship, or edge (“loves”).

Knowledge Graphs have been explored extensively for information retrieval. Zep autonomously builds temporal knowledge graphs, handling changing relationships and maintaining historical context.

Zep builds a Context Graph from text, JSON, messages, and documents. The graph can represent a user, customer, account, project, product, organization, or other business subject.

A user graph is created for a Zep user and integrates with threads and user-specific retrieval. A Context Graph addressed with graph_id stores shared or domain context that is not owned by one Zep user.

Here’s an example of how Zep might extract graph data from a chat message, and then update the graph once new information is available:

Each node and edge contains attributes. Zep stores each fact on an edge and keeps links to its source episodes.

Edge timestamps record when a fact becomes valid or invalid.

Graph Data Structure

Zep’s graph database stores data in three main types:

Entity edges (edges): Represent relationships between nodes and include semantic facts representing the relationship between the edge’s nodes.
Entity nodes (nodes): Represent entities extracted from episodes, containing summaries of relevant information.
Episodic nodes (episodes): Represent source data stored in Zep through chat history or the graph.add endpoint.

Source episodes provide provenance for derived facts and graph artifacts. Provenance identifies the source data. It does not guarantee that a source or a derived fact is correct.

Every entity node reports the episodes that mention it in the episodes field (named episode_uuids in the v4 API). When the node has 100 or fewer live mention episodes, the list holds the complete set, newest first, and episodes_truncated (v4: episode_uuids_truncated) is false. When the node has more than 100, the list holds the newest 100 and the flag is true; read the full set with an episode list call filtered by mentioned_node_uuids.

Working with the Graph

To learn more about interacting with Zep’s graph, refer to the following sections:

How Graph Creation Works: How Zep turns episodes into entities, relationships, and facts in the graph.
Documents: Group episodes of the same source the way threads group messages.
Adding Data to the Graph: Learn how to add business data, documents, JSON, and conversations.
Searching the Graph: Explore techniques for efficiently searching the graph.
Governance: Control access to context and review dashboard and API activity.

These guides will help you use Zep’s knowledge graph in your applications.