You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
┌─────────────────────────────────────────────────────────────┐
│ GLOBAL MODE │
│ │
│ All sessions → Single container → All questions search it │
│ │
│ Container: "longmemeval-synap" │
│ ┌──────────────────────────────────────────┐ │
│ │ Session 1 Session 2 ... Session 940 │ │
│ └──────────────────────────────────────────┘ │
│ ↑ Q1 searches ↑ Q2 searches ↑ Q500 searches │
│ │
│ Pro: Fast (one ingestion), cross-session reasoning │
│ Con: Noise from irrelevant sessions can confuse answers │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ ISOLATED MODE │
│ │
│ Each question gets its own container with only relevant │
│ sessions. No cross-contamination. │
│ │
│ Container: "longmemeval-synap_{question_id}" │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Q1: Sess │ │ Q2: Sess │ ... │ Q500: Sess │ │
│ │ 3, 7, 12 │ │ 1, 5 │ │ 8, 44, 201 │ │
│ └────────────┘ └────────────┘ └────────────┘ │
│ │
│ Pro: Clean evaluation, each question sees only its evidence │
│ Con: Slower (N separate ingestions), no cross-session │
└─────────────────────────────────────────────────────────────┘
Phase Details
Phase 1: Ingest
for each session in benchmark:
├─ Format session messages into document
├─ Call provider.ingest(sessions, container_tag)
├─ Track ingestion IDs in checkpoint
└─ Mark turns completed after confirmation
Deduplication: sessions already in checkpoint are skipped on resume.
Batching: sessions sent in batches of 50 (configurable).
Concurrency: provider-specific (e.g., Supermemory: 10 concurrent).
Phase 2: Search
for each question:
├─ Call provider.search(question_text, container_tag, limit=10)
├─ Save results to data/runs/{runId}/results/{questionId}.json
└─ Update checkpoint with result count + duration
Results are saved to disk so answer+evaluate can re-run without re-searching.
Phase 3: Answer
for each question:
├─ Load search results from disk
├─ Build prompt: qa_agent.md + question + ranked context
├─ Call LLM (GPT-4o, GPT-5-mini, Gemini, etc.)
└─ Store hypothesis in checkpoint
System prompt: prompts/qa_agent.md (handles memory vs evidence conflicts,
knowledge updates, counting, preferences, grounding rules).
Phase 4: Evaluate
for each question (in parallel):
├─ judge_single(question, hypothesis, ground_truth)
│ └─ Selects prompt by question type (temporal, preference, etc.)
│ └─ Returns score (0.0-1.0) + explanation
├─ judge_retrieval_quality(question, ground_truth, search_results)
│ └─ LLM evaluates relevance of each retrieved item
│ └─ Computes Hit@K, Precision@K, Recall@K, F1@K, MRR, NDCG
└─ Store all metrics in checkpoint
Phase 5: Report
Aggregates across all questions:
├─ Overall accuracy (correct / total × 100)
├─ Accuracy by question type
├─ Latency stats: min, max, mean, median, p95, p99
│ └─ Per phase: search, answer, evaluate, total
├─ Retrieval aggregates: averaged Hit@K, MRR, NDCG, etc.
└─ Saved to data/runs/{runId}/report.json
Checkpointing
data/
├── runs/{runId}/
│ ├── checkpoint.json # Per-question, per-phase status
│ ├── results/ # Search results saved to disk
│ │ ├── {questionId1}.json
│ │ └── {questionId2}.json
│ └── report.json # Final aggregated report
│
├── ingest-checkpoints/
│ └── {dataset}.json # Global ingest state per provider
│
├── comparisons/
│ └── {compareId}/
│ └── comparison.json # Multi-provider comparison metadata
│
└── leaderboard.json # Submitted benchmark results
Resume flow:
Load checkpoint → identify completed phases per question
Skip completed questions for each phase
Resume from first incomplete question
Atomic writes (tmp + rename) prevent corruption on crash
Judge Prompts
Five specialized prompts selected by question type:
Type
Prompt Strategy
Key Rule
Default
Factual comparison
Score if key facts from gold are present in prediction
Temporal
Lenient on dates
Allow off-by-one day, equivalent date expressions
Knowledge Update
Must track updates
Old value only → max 0.5; must have updated value
Preference
Rubric-based
Does hypothesis correctly apply user preferences?
Adversarial
Reward refusal
Correct behavior = decline to answer; confident answer = 0.0
Retrieval Metrics
Metric
What It Measures
Range
Hit@K
At least one relevant result in top-K
0 or 1
Precision@K
Fraction of top-K that are relevant
0.0–1.0
Recall@K
Fraction of all relevant items found
0.0–1.0
F1@K
Harmonic mean of Precision and Recall
0.0–1.0
MRR
1/rank of first relevant result
0.0–1.0
NDCG
Ranking quality (rewards relevant items higher)
0.0–1.0
Web Dashboard
The Next.js frontend provides:
Page
Purpose
/runs
List all evaluation runs with status, accuracy, filters
/runs/new
Create new run (provider, benchmark, model, isolation mode)
/runs/{id}
Run detail: phase progress, accuracy by type, latency, retrieval
/runs/{id}/questions/{qid}
Question drill-down: ground truth vs hypothesis, context