Hermes MemConflict memory-provider benchmark

Hermes MemConflict memory-provider benchmark

为什么重要

这个项目直接面向 Hermes：比较 self-hostable long-term memory providers 在 MemConflict 多会话冲突事实中的检索与使用能力。它不是抽象“记忆系统哪个好”，而是把 provider 放进统一 harness，用同一 dataset、answer model、judge model、top-K、prompt 和 scorer 比较 temporal validity、factual correctness 与 contextual applicability。

机制 / 一阶原理

项目使用 MemConflict Step4_4.jsonl，包含 30 personas、3,750 questions。每个 provider 输出 Model_Answer 与 Retrieved_Memories，共享 scorer 评估答案；headline metric 是按冲突类别均权的 macro answer accuracy。README 中 featured contract v5 固定 qwen3.5-4b answer model、gte-modernbert-base embedder 和 gemma-4-12b judge；BENCHMARK_MATRIX 还要求从 committed summary JSON 读取结果，而不是从 prose 复制数字。

与已有概念的关系

• 补强 Agent-Benchmarks：context provider 本身应被 benchmark，且要固定 dataset、judge、retrieval width、provider config 与 run tag。
• 连接 Context-Engineering：长期记忆的价值要用 held-out conflict cases、supporting evidence hit 和 answer accuracy 证明，而不是凭“记得更多”判断。
• 连接 Harness-Engineering：公平线在 shared harness；provider 暴露的设置可以调，但不能调到数字变好为止。

对 Hermes / llm-wiki 的可执行启发

1. 选择 Hermes memory provider 时，应优先看 macro AA、supporting evidence hit、冲突类别 split 和配置证据，而不是产品叙述。
2. llm-wiki 的向量检索也可借鉴：查询报告应能区分“检索命中正确证据”和“最终回答正确”。
3. 对自我优化文章，避免把 memory/session 状态直接写进长期 memory；长期知识应可追溯到 raw/source/concept。

失败模式 / 边界

结果只比较 featured contract v5 内的配置，不能外推到所有模型、所有 embedder 或所有记忆任务。单一 judge 和小模型 answer path 可能影响绝对分数；因此更适合做 provider 相对诊断和 Hermes 部署候选筛选，而不是通用记忆系统排名。

写入记录

• 2026-08-16 09:00 CST：新增 Hermes MemConflict 来源页，沉淀 memory provider benchmark、shared harness fairness 与 llm-wiki 检索评测启发。