MemoryBench 报告里的 MemScore 怎么看：准确率、延迟与上下文 token 怎么权衡

MemoryBench 报告里的 MemScore 怎么看准确率、延迟与上下文 token 怎么权衡【免费下载链接】supermemoryMemory and context engine app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory你跑完一次 MemoryBench 基准之后报告会给出类似86% / 145ms / 1823tok的三项数字。这三个数字分别对应回答准确率、搜索延迟和发给回答模型的上下文 token 数它们各自回答一个不同的问题答得对不对、快不快、检索花了多少成本。这篇文章基于 supermemory 仓库中 MemoryBench 的 Measuring Results 文档讲清楚这三个数字是怎么算出来的、文档给出的参考区间是什么以及如何用分题型明细定位该修哪里。前提是你已经有一个 MemoryBench 的运行结果run。如果没有可以先跑一次内置基准例如bun run src/index.ts run -p supermemory -b locomoMemScore 的三个数字各代表什么MemoryBench 的每个问题都走同一条流水线INGEST → SEARCH → ANSWER → EVALUATE → REPORT并且产生两类信号定性判断答案到底对不对由 judge LLM 判定不是字符串匹配定量测量有多快、花了多少 token。报告不会把两者压成一个分数。MemScore 把三项并列展示文档中的示例格式如下文档示例数值不代表任何真实跑分MemScore: 86% / 145ms / 1823tok ▲ ▲ ▲ │ │ └─ context tokens sent to the answering model (cost) │ └───────── search latency └─────────────── answer accuracy vs. ground truth三项的含义在文档的指标表中是这样定义的指标测量内容Accuracyjudge 分数0–1在所有问题上的平均并按题型细分Latency每个问题的搜索时间和答案生成时间按整次运行给出 p50 / p95Context tokens发给回答模型的上下文量是检索成本的代理指标Success rate无错误完成的问题占比失败的问题不计入准确率也不从准确率里扣分注意两点MemScore 中间的ms特指搜索延迟而报告里每个问题其实记录了搜索时间和答案生成时间两个计时按 p50/p95 汇总。另外 success rate 是独立指标——如果某个 provider 在部分问题上直接报错这些错误不会拉低准确率数字需要单独看完成率才能发现。准确率是怎么判出来的正确性由一个 judge LLM文档列出的可选模型包括 GPT-4o、Claude Sonnet、Gemini Flash对比 provider 答案和 ground truth 得出返回如下结构的判定{ score: 0 | 1, label: correct | incorrect, explanation: string }文档特意强调 judge 是可替换的judge-agnostic同一份 run 可以用两个不同的 judge 各判一次检查结果是不是某个评审模型的打分偏差造成的。judge 的 prompt 也会按题型变化时间类问题和拒答类问题的判分方式不同provider 也可以提供自己的 judge prompt。如果你怀疑某个准确率数字受 judge 影响文档给出的核对方式是用另一个 judge 重新判分# Grade a run with a different judge bun run src/index.ts run -p supermemory -b locomo -j sonnet-4文档给出的参考区间文档基于在内置基准上的运行结果给出了两组粗略区间原文标注为 rough bands可作参考不是硬性标准Accuracy文档的读法80%Excellent, production-ready70–80%Good, some room to improve60–70%Adequate, likely needs tuning60%Investigate — retrieval, prompts, or indexing likely need workSearch latency文档的读法100msExcellent (vector-search level)100–300msGood, typical API latency300–500msAdequate for most use cases500msSlow — worth optimizing文档没有给 context token 的参考区间只说明它是检索成本的代理指标。因此权衡时不能只看单侧数字文档里的原话是一个准确率高 2% 但慢 5 倍、上下文 token 贵 3 倍的 provider并不一定更好——MemScore 不替你选权重这个权衡留给你自己按业务约束决定。分题型明细比总分更有用文档指出per-question-type 的拆分通常比头条数字更有用因为它直接告诉你该修什么。以内置基准为例在 LoCoMo 上强、在 LongMemEval 上弱 → 时间线/跨会话回忆好但稠密检索弱反过来 → 结论相反。LoCoMo 覆盖的是跨多会话对话的事实回忆单跳、多跳、时间线、对抗性提问LongMemEval 覆盖跨会话的长期记忆包括对话中途被更新的知识。所以先看总分落在哪个区间再用分题型数据判断短板具体在哪一层。用 CLI 和报告文件核对细节看到可疑数字后文档给出的排查命令命令中的my-run是示例 run ID替换成你自己的 run IDbun run src/index.ts status -r my-run # progress / summary bun run src/index.ts show-failures -r my-run # full context on what got graded wrong bun run src/index.ts serve # web UI at localhost:3000 for visual inspectionshow-failures会给出被判错问题的完整上下文serve启动本地 Web UIlocalhost:3000做可视化检查。所有 run 的结果和检查点存放在data/runs/{runId}/report.json其中包含按题型拆分的准确率、延迟百分位和每题的 token 数——需要核对某道题具体发生了什么时直接查这个文件。如果最终判断是准确率60%或搜索延迟500ms文档给出的方向分别对应去检查检索/prompt/索引以及把延迟优化作为下一步目标具体排查从show-failures的输出开始。下一步当你需要把自己的记忆系统纳入同样的流水线来复现这些数字时参考 Adding a Provider当内置数据集不匹配你的产品场景、想用自己的问题集重跑时参考 Building a Benchmark。框架介绍与内置基准说明见 MemoryBench Overview。【免费下载链接】supermemoryMemory and context engine app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考