Repository navigation
Headline retrieval numbers describe PostgreSQL; the default SQLite store has no published number #708
Description
Summary
The headline retrieval numbers describe PostgreSQL with the cross-encoder, while the default store is SQLite and has no published number. The README says the retrieval contract is identical on both, and nothing supports it.
Evidence
Measured by an independent audit on 2026-10-10 (main at b4a62b2).
- The README quotes LongMemEval-S Recall@10 97.8 percent and MRR 0.905 (v4.20.0) and 98.2 percent and 0.9167 (v4.14.1), "retrieval only, no LLM". The committed artifacts contain aggregates that match the README but no per-question rows, so the headline cannot be recomputed from them.
benchmarks/reproduce.shneeds Docker and an ephemeral PostgreSQL and takes 32 to 37 minutes per run. - The audit ran the repository's SQLite fallback benchmark script (under
benchmarks/) offline on the first 120 LongMemEval-S questions (70 single-session-user and 50 multi-session only): MRR 0.641 and Recall@10 95.0 percent. That script has no reranker, so it is a bound and not the shipped tool. - On a 30-memory corpus through the real tool path (SQLite, reranker on): Recall@10 100 percent, Recall@3 96.7 percent, MRR 0.78.
Expected
The default path is measured: run the SQLite store through the real tool pipeline (reranker included) in benchmarks/reproduce.sh, publish that number next to the PostgreSQL one, and write per-question rows into the committed artifacts so any reader can recompute the headline. Until then the README states which backend each number describes and drops "identical contract" for retrieval quality.
Activity
docs(readme): name the backend behind the LongMemEval numbers; SQLite…
cdeust commentedon Nov 4, 2026
CI autopilot : l'issue est découpée en trois tranches. La tranche 1 est livrée dans #860 (
Refs #708, commit e0cd6be).Tranche 1 (#860), le texte. Le README dit maintenant que les deux chiffres LongMemEval-S (v4.14.1, v4.20.0) décrivent le store PostgreSQL avec le reranker. La preuve :
benchmarks/reproduce.shlance un conteneurpgvector/pgvector:pg16, et les deux artefacts enregistrentreranker_state: loaded. Le README précise aussi que SQLite n'a pas encore de chiffre publié. Dans le tableau Storage, la ligne « Retrieval contract | identical » devient « Retrieval tool interface | identical », et une nouvelle ligne indique « Published retrieval quality : none yet » pour SQLite.Tranches restantes :
2. Mesurer SQLite par le vrai chemin outil (reranker inclus) dans
benchmarks/reproduce.sh, puis publier le chiffre à côté de celui de PostgreSQL. Il faut un run LongMemEval-S complet (environ 30 minutes, avec téléchargements). Cet environnement ne peut pas le faire : le proxy refuse le téléchargement de torch.3. Écrire des lignes par question dans les artefacts commités pour qu'on puisse recalculer le chiffre affiché.
Note : la PR est ouverte en brouillon. L'API REST ne permet pas de la passer en « ready for review ».
Generated by Claude Code
fixup! docs(readme): name the backend behind the LongMemEval numbers;…
fixup! docs(readme): name the backend behind the LongMemEval numbers;…
docs(readme): name the backend behind the LongMemEval numbers; SQLite…
cdeust commentedon Nov 5, 2026
CI autopilot : tranche 3 livrée dans #886 (
Refs #708, commit 3f60afd).Chaque ligne LongMemEval de
<stem>.queries.jsonlporte maintenantanswer_session_ids,mrretrecall10; la moyenne des lignes d'un run égale le MRR et le Recall@10 publiés (testtests_py/benchmarks/test_longmemeval_journal_rows.py, qui échoue sans le correctif).Reste :
benchmarks/reproduce.shet publier le chiffre. Impossible ici : le proxy refuse le téléchargement de torch, et il n'y a pas de Docker.longmemeval-s.queries.jsonlà côté delongmemeval-s.jsondansbenchmarks/results/repro/au prochain run de release.La PR est en brouillon ; l'API REST ne permet pas de la passer en « ready for review ».
Generated by Claude Code
feat(bench): each LongMemEval journal line carries its gold sessions …
cdeust commentedon Nov 5, 2026
CI autopilot : #708 passe en hold. Les tranches 1 (#860) et 3 (#886) sont livrées. La tranche 2 demande un run que cet environnement ne peut pas faire.
Ce qui bloque (vérifié le 2026-11-05 vers 23 h UTC) :
benchmarks/reproduce.shreviendrait à commiter du code sans reçu.docker pséchoue (/var/run/docker.sockabsent : il n'y a pas de daemon),torchn'est pas installé, et un essai précédent montre que le proxy refuse de le télécharger. Orreproduce.shexige Docker (lignes 469-471), et le reranker exige torch.À décider ou à faire par un humain :
CORTEX_BACKEND=sqlite, reranker chargé). La question à trancher : faut-il l'intégrer àbenchmarks/reproduce.shcomme deuxième cellule, ou en faire un script séparé ?longmemeval-s.queries.jsonl(les lignes par question de feat(bench): each LongMemEval journal line carries its gold sessions and scores (#708, slice 3) #886) est commité à côté delongmemeval-s.jsondansbenchmarks/results/repro/au prochain run de release.Un commentaire de
cdeustou une modification du corps de l'issue lèvera ce hold.Generated by Claude Code