Add Loom memory-service integration for LongMemEval#2
Open
zlareb1 wants to merge 9 commits into
Open
Conversation
Loom (https://github.com/ClickHouse/loom) is a ClickHouse-backed memory service. This adds loom/run_loom.py, which plugs Loom in at the INDEXING + RETRIEVAL stages (ingest each haystack session via memory.set_from_messages, retrieve via memory.search) and reuses the official reader prompt + the official src/evaluation/evaluate_qa.py judge. It writes a hypotheses JSONL to grade with the existing judge, and reports evidence-session recall@k. The official src/retrieval/run_retrieval.py targets in-process retrievers (BM25/Contriever/Stella/GTE) over a flat corpus and has no hook for an external memory service, which is why this adapter exists. Includes README + requirements; validated end-to-end against a live Loom server. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The dataset is category-ordered, so a bare --limit samples a single question type. --shuffle (deterministic via --seed, default 42) gives a mixed sample for quick partial runs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…nostics Applied before --shuffle/--limit so a single LongMemEval category can be run complete (e.g. all single-session-assistant) for non-noisy per-category recall. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The published memory benchmarks (mem0, Zep) each grade LongMemEval with their own semantic-equivalence judge, not the bare upstream anscheck. Comparing Loom's strict-judge number against their lenient-judge numbers is apples-to- oranges. Add a `fair` judge (default) whose every added rule is one the official prompt OR both competitor graders already apply (meaning-not-wording, superset-correct, more-precise-correct, temporal off-by-one), while excluding mem0-only catch-alls — so it sits in the field's strictness band: no benchmin, no benchmax. Report this single number, like competitors do; keep the upstream strict judge available via --judge-style official for reproducibility. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
evaluate_qa.py grades by semantic equivalence (paraphrase / superset / more- precise correct; temporal off-by-one tolerated), per question type. run_loom.py adds fact-level recall@k (is the gold answer string actually in a retrieved excerpt — the metric that tracks QA, unlike session recall), renders dated history + derived-fact blocks for the reader, and leaves the generative reranker off by default so the number reflects real retrieval latency. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A memory service is judged on more than answer accuracy — token efficiency and search latency are first-class, and recall separates retrieval quality from the reader. run_loom now captures all of them per query: clean serving latency (measured one-at-a-time on the quiesced server after ingest, since the in-run figure is contaminated by concurrent indexing), context-tokens served to the reader, the HyDE recall-fallback firing rate, and a --metrics-out JSON summary. evaluate_qa gains a gpt-5 judge option so accuracy can be graded on the same instrument other platforms publish under. RESULTS.md records the full-500 numbers honestly: accuracy is reader/judge- dominated (recall@200 is 99.6%), token efficiency is a recall/cost knob, and latency is LLM-in-the-loop. On the matched gpt-5 reader+judge instrument Loom is 88.4%. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The latency and token numbers are Loom's own measurements on local hardware: the timed search call includes Loom's read-path planning/HyDE LLMs and a remote embedding RTT, and tokens are chars/4 over a top_k=200 context. Other systems publish search latencies from no-read-time-LLM graph reads and tokenizer counts over curated ~20-item contexts. Make explicit that these are not like-for-like, so the figures aren't misread as a head-to-head ranking; a real comparison needs all systems run through one harness on one machine. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Latency/tokens are Loom's own operational measurements and aren't comparable to other systems' published figures, so they no longer headline the results doc; RESULTS now publishes accuracy (matched gpt-5 reader+judge) + retrieval recall, with latency/token instrumentation still available via run_loom flags. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…accuracy A paired run (one ingest, same 99 questions, gpt-5 reader+judge) shows the fast retrieval budget — pure vector, no read-path query-planning/HyDE LLM — holds accuracy (90.9 vs 88.9, within noise) and fact recall (47/99, identical) while cutting search p50 from ~1000ms to ~140ms. On LongMemEval (recall 99.6%) the LLM-in-loop default does not change what is retrieved, so it is latency without benefit here. Add --retrieval-budget so the fast path is reproducible (the latency phase honors it too), and record the comparison in RESULTS. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds
loom/so a Loom memory service can be benchmarked on LongMemEval.loom/run_loom.py)src/generation/run_generation.pyprompt (replicated)src/evaluation/evaluate_qa.py(run unchanged)run_loom.pyingests each question haystack into Loom (onememory.set_from_messagesper session, concurrent), retrieves viamemory.search, generates an answer with the official reader prompt, and writes a hypotheses JSONL to grade with the existing judge. It also reports evidence-session recall@k.The official
src/retrieval/run_retrieval.pytargets in-process retrievers (BM25/Contriever/Stella/GTE) over a flat corpus and has no hook for an external memory service, which is why this adapter exists (the same pattern other memory products use to plug into LongMemEval).Usage
Validation
Smoke-tested end-to-end against a live Loom server (ingest -> retrieve -> official reader -> official judge runs clean). Details in
loom/README.md.🤖 Generated with Claude Code