getzep/zep/zep-eval-harness

Trust tier 2
  • community
Source check pending

Checking that the SKILL.md file is still in the repository.

Run and manage the Zep eval harness pipeline — document chunking, user ingestion, document ingestion, evaluation, graph inspection, and results analysis. Use when the user asks to run eval harness scripts, use the Zep eval harness, get terminal commands for eval harness operations, chunk documents, ingest users or documents into Zep, run evaluations, inspect graphs, compare evaluation runs, analyze completeness/accuracy metrics, or work with the eval harness data/config/runs directories. Also triggers on "run the harness", "start ingestion", "run evaluation", "chunk the documents", "compare runs", "analyze results", or any reference to the eval harness pipeline.

Install

npx vskill@latest install getzep/zep/zep-eval-harness

SKILL.md

Zep Eval Harness

An end-to-end evaluation framework for testing Zep's memory retrieval and question-answering capabilities. The pipeline ingests user conversations, telemetry, and documents into Zep knowledge graphs, then evaluates retrieval quality by searching those graphs with test questions and grading the results against golden answers.

The pipeline has four steps:

  1. Chunk documents — split documents and generate LLM-based summaries + contextualizations
  2. Ingest users — create Zep users, add conversations and telemetry to user graphs
  3. Ingest documents — send pre-chunked documents to a standalone Zep document graph
  4. Evaluate — for each test case: search graphs → assess context completeness → generate LLM response → grade answer accuracy
Scope: Single-Shot Retrieval

The harness evaluates single-shot retrieval only. Every test case issues one retrieval from the raw test question through the context endpoint (config/evaluation_config/retrieval_strategy.py), then hands the resulting context block to the response model in a single turn — no second retrieval round, no query reformulation. This mirrors deterministic/programmatic retrieval, not the tool-based pattern where an agent is handed Zep search tools (e.g. search_graph from the Zep MCP server) and decides when and what to search.

That makes the harness a clean instrument for the ingestion and search configuration, but it says nothing about agent tool-use behavior. A tool-based agent may do better (several targeted searches, reformulating after a weak result) or worse (never searching, poorly phrased queries, running out of turns). When reporting results, scope conclusions to the config under test and never present them as a prediction of production agent performance.

Evaluation Metrics

Context Completeness (PRIMARY) — Did Zep retrieve sufficient information to answer the question?

  • COMPLETE: All necessary information present in the retrieved context
  • PARTIAL: Some relevant information, but incomplete
  • INSUFFICIENT: Missing critical information

This is the metric that matters most. It directly measures Zep's retrieval quality — whether the knowledge graph and search surface the right facts, entities, and relationships.

When completeness is low, the key diagnostic question is: does the graph contain the right information but search failed to retrieve it, or is the information missing from the graph entirely? Use zep_graph_inspect.py to examine what's actually in the graph. If the information is there but not retrieved, the issue is retrieval strategy (context character budget, query phrasing). If the information is absent from the graph, the issue is upstream — ingestion, ontology, or custom instructions need adjustment.

Answer Accuracy (SECONDARY) — Did the LLM produce a correct answer from the retrieved context?

  • CORRECT: Answer conveys the same key information as the golden answer
  • WRONG: Answer is missing critical information or incorrect

This measures whether the response model uses the context well. It depends on the LLM and response prompt, not Zep. High completeness + low accuracy means retrieval is working but the response generation needs tuning (better model, better prompt).

Metrics are calculated in aggregate, per-category (based on test case category field), and per-user.

Context Block: the v4 context endpoint

The evaluation script retrieves context via build_context_block() in config/evaluation_config/retrieval_strategy.py. The default strategy calls graph.get_context with MAX_CHARACTERS = 10000, and prepends the user-node summary (fetched once per user via fetch_user_summary — the context endpoint does not include it).

The context endpoint packs relevant edges (facts), nodes (entities), observations, and thread summaries into a pre-assembled context string. It does not include episodes. The character budget controls the volume.

To change retrieval (for example, calls to the v4 search methods for each scope — graph.search_edges, graph.search_nodes, graph.search_episodes, graph.search_observations, and graph.search_thread_summaries — with a page_size and a reranker for each scope), edit build_context_block in that module. That function is the source of truth for the strategy.

All commands run from zep-eval-harness/ using uv run. Depending on the user's request, either run the scripts directly or provide the terminal commands for the user.

Data Folder (data/)

PathPurpose
data/users.jsonArray of user definitions (user_id, first_name, last_name, email, metadata)
data/conversations/{user_id}_{conv_id}.jsonConversation files with messages array (role + content + timestamp)
data/telemetry/{user_id}_*.jsonOptional JSON data ingested as a JSON graph episode
data/documents/*Text/markdown files for the shared document graph
data/test_cases/{user_id}_tests.jsonEval test cases with id, category, query, golden_answer fields

Configuration Folder (config/)

config/
├── constants.py # GEMINI_BASE_URL, POLL_INTERVAL, POLL_TIMEOUT
├── user_ingestion_config/
│ ├── ontology.py # User graph entity/edge types + set_custom_ontology()
│ ├── custom_instructions.py # User custom instructions + set_custom_instructions()
│ └── user_summary_instructions.py # User node summary instructions
├── document_ingestion_config/
│ ├── constants.py # DOCUMENTS_GRAPH_NAME
│ ├── ontology.py # Document graph entity/edge types
│ └── custom_instructions.py # Document custom instructions
├── document_chunking_config/
│ └── constants.py # CHUNK_SIZE, CHUNK_OVERLAP, LLM_CONTEXTUALIZATION_MODEL
└── evaluation_config/
├── constants.py # LLM_RESPONSE_MODEL, LLM_JUDGE_MODEL
├── retrieval_strategy.py # build_context_block() — retrieval + context assembly
└── response_prompt.py # get_response_system_prompt() — AI persona for eval

Scripts

1. Chunk Documents (zep_chunk_documents.py)

Splits documents into chunks and generates LLM summaries + contextualizations. Writes to runs/chunk_sets/.

bash
uv run zep_chunk_documents.py [OPTIONS]
FlagDefaultDescription
--chunk-size Nfrom configOverride character count per chunk
--chunk-overlap Nfrom configCharacters of overlap between consecutive chunks
--concurrency N5Max parallel LLM calls (semaphore)
--resume PATH—Resume interrupted run from chunk set directory
2. Ingest Users (zep_ingest_users.py)

Creates Zep users, adds conversations and telemetry, polls for processing completion. The Zep v4 API gives each user, thread, and graph a UUID. The script stores these UUIDs in the run manifest and uses them for all later calls.

bash
uv run zep_ingest_users.py [OPTIONS]
FlagDefaultDescription
--custom-ontologyoffApply user ontology from config
--custom-instructionsoffApply user custom instructions from config
--user-summary-instructionsoffApply user summary instructions from config
--no-polloffZep processes episodes asynchronously — the API returns immediately but graph extraction happens in the background. By default the script polls until all episodes finish processing. This flag skips that wait.
--graphs ID [ID ...]allIngest only specific user base IDs
3. Ingest Documents (zep_ingest_documents.py)

Reads a chunk set and sends chunks to a standalone Zep document graph.

bash
uv run zep_ingest_documents.py [OPTIONS]
FlagDefaultDescription
--chunk-set N—Use chunk set #N (supports follow mode if still in progress)
--custom-ontologyoffApply document ontology from config
--custom-instructionsoffApply document custom instructions from config
--chunk-size N—Inline mode: chunk + ingest in one step (no reuse)
--no-polloffSame as user ingestion: Zep processes episodes asynchronously, and by default the script polls until complete. This flag skips that wait.
--resume PATH—Resume from checkpoint file
4. Evaluate (zep_evaluate.py)

Searches graphs, generates LLM responses, grades against golden answers. Calculates aggregate, per-category, and per-user metrics.

bash
uv run zep_evaluate.py [OPTIONS]
FlagDefaultDescription
--user-run NlatestWhich user ingestion run to evaluate
--doc-run NnoneWhich document ingestion run to include
--concurrency N15Max parallel test case evaluations (semaphore)
5. Inspect Graph (zep_graph_inspect.py)

Print all entities and facts for any graph.

bash
uv run zep_graph_inspect.py [OPTIONS]
FlagDescription
--user USER_UUIDInspect a user graph (zep_user_uuid from the manifest)
--graph GRAPH_UUIDInspect a standalone document graph (graph_uuid from the manifest)
--include entitiesShow only entity nodes
--include edgesShow only fact edges

Run Artifacts (runs/)

Each pipeline step creates a numbered, timestamped directory with a config snapshot for reproducibility.

DirectoryContents
runs/chunk_sets/{N}_{ts}/chunks.jsonl, meta.json, document_chunking_config_snapshot/
runs/users/{N}_{ts}/manifest.json, user_ingestion_config_snapshot/
runs/documents/{N}_{ts}/manifest.json, document_ingestion_config_snapshot/
runs/evaluations/{N}_{ts}/results.json (with parent_runs referencing user/doc runs), evaluation_config_snapshot/
runs/checkpoints/Temporary resume files, removed on success

Follow Mode

Start document ingestion while chunking is still running — the ingestion script tails the in-progress chunk set JSONL and ingests chunks as they appear:

bash
# Terminal 1
uv run zep_chunk_documents.py --concurrency 10
# Terminal 2 (start immediately, even before chunking finishes)
uv run zep_ingest_documents.py --chunk-set 1 --custom-ontology --custom-instructions

The ingestion script detects "status": "in_progress" in meta.json and polls for new chunks.

Concurrency Guidance

Prefer higher concurrency values to maximize throughput:

  • Chunking: --concurrency 10 to 20 (default 5 is conservative)
  • Evaluation: --concurrency 30 or higher (default 15 is conservative)

All scripts include retry logic with exponential backoff (8 retries, max 5-minute delay) that handles rate limits automatically. If rate limit errors persist, reduce concurrency and retry.

Analyzing Results

Evaluation results live at runs/evaluations/{N}_{ts}/results.json. Each result references its parent user and document runs via the parent_runs field. When asked to analyze or compare runs:

  1. Read the aggregate_scores, category_scores, and user_scores from each results file.
  2. Present comparisons as a table — rows are runs/configs, columns are metrics.
  3. Draw conclusions about which configurations perform better and with what level of certainty (e.g., small test sets = low confidence, large differences = higher signal).
Which Metrics Matter

Context completeness is the primary metric. It measures whether Zep retrieved sufficient information to answer the question — this directly evaluates Zep's retrieval quality. A COMPLETE rate of 100% means Zep always surfaces the right facts.

This is the start of the file. Read the full SKILL.md on GitHub.

Security

  • Security scanPassed, 100 of 100Pattern checks on the skill's files.
  • Model reviewPassed

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

Repository stars
4,870
Repository forks
651
7-day trend score
42

Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/getzep/zep/zep-eval-harness/badge)](https://verified-skill.com/skills/getzep/zep/zep-eval-harness)

Something wrong with this skill or its page? Tell us.