2026/9/12 16:06:18
FEATURED · 精选文章 
如何把自研记忆系统注册为 MemoryBench provider 并与 Supermemory 对比【免费下载链接】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假设你已经有一个自研的记忆系统或 RAG 系统想把它和 Supermemory 放在同一组问题、同一条 pipeline、同一套 judge 下测出可对比的结果。Supermemory 为此开源了 MemoryBench 框架MIT 许可supermemoryai/memorybench所有 run 都走统一的 checkpointed pipelineINGEST → SEARCH → ANSWER → EVALUATE → REPORT。在这个框架里provider 就是任何能 ingest 会话并回答搜索查询的记忆/RAG 系统Supermemory、Mem0、Zep 是内置 provider而你的自研实现只是又一个 provider——注册之后它会和内置 provider 走完全相同的流程、以完全相同的标准被打分。文档给出两条注册路径让 MemoryBench skill 自动生成 provider 适配器或者自己手写适配器。两条路径都会落到同一套Provider接口和同一组运行命令上。选择注册路径快路径skillMemoryBench 附带一个 Claude Code skillbenchmark-context从读你的代码、生成并注册 provider 适配器到产出对比报告全程自动你不需要写任何 MemoryBench 特定的代码。手写你在 memorybench 仓库里自己实现Provider接口并注册适合想完全掌控适配器逻辑的情况。两条路径都需要拿到 memorybench 代码skill 路径会在其 Setup 阶段把memorybench克隆到./memorybench并安装依赖手写路径则需要你自行获取 memorybench 仓库overview 文档指向 GitHub 上的supermemoryai/memorybench后续所有命令都从该仓库根目录执行且文档中所有命令都通过bun运行。快路径运行 MemoryBench skill在你自己项目的根目录运行不要在 memorybench 目录内部运行——skill 会把框架克隆成子目录并通过相对路径分析你的代码# Run from your project root, not from inside memorybench /memorybench开始动作之前skill 会先问 5 个问题provider 名称你的记忆代码在哪里跑哪个 benchmark可参考 Building a Benchmark 中的内置数据集说明和哪些 provider 对比——Supermemory、Mem0、Zep或无需 API key 的filesystem/rag基线采样多少问题5 道用于快速检查20 道能得到有意义的信号也可以跑全集。随后它按 7 个阶段推进阶段内容1. Setup克隆memorybench到./memorybench并安装依赖2. Discoveryagent 阅读你的记忆代码找出其 init、ingest、search 方法3. Code generation生成实现Provider接口的 provider 适配器适配你的代码4. Registration在框架的 types 和 config 中注册该 provider5. Configuration收集你的 provider、对比 provider 以及 judge 模型的 API key写入.env.local6. Validation先端到端跑一道问题确认 ingest/search 真正可用再开始完整 run7. Benchmark execution跑完整对比并并排报告 accuracy、latency、context-token 结果也就是说skill 路径内置了验证步骤没有先跑通一道问题就不会进入完整 run。手写路径实现 Provider 接口每个 provider 都实现同一个接口memorybench 仓库的src/types/provider.tsinterface Provider { name: string prompts?: ProviderPrompts initialize(config: ProviderConfig): Promisevoid ingest(sessions: UnifiedSession[], options: IngestOptions): PromiseIngestResult awaitIndexing(result: IngestResult, containerTag: string): Promisevoid search(query: string, options: SearchOptions): Promiseunknown[] clear(containerTag: string): Promisevoid }各方法的职责方法职责initialize()用 API key / 配置初始化你的客户端ingest()把 benchmark 会话推入你的系统返回生成的文档 IDawaitIndexing()阻塞到这些文档真正可被检索——同步索引的系统里是 no-op异步索引的系统里是带 backoff 的轮询循环search()执行查询按你系统返回的形状返回结果clear()删除某个containerTag下的所有内容避免不同 run 之间互相污染注册步骤文档示例统一以myprovider作为 provider 名实际替换成你的名称创建src/providers/myprovider/index.ts实现Provider在src/providers/index.ts中注册它把名称加入src/types/provider.ts里的ProviderName在src/utils/config.ts中加入它的配置API key、base URL 等可选如果你的搜索结果在交给答题 LLM 或 judge 前需要自定义格式化就覆盖promptsProviderPrompts。异步索引和自定义 prompt 的完整示例见 memorybench 仓库的src/providers/README.md文档中的链接指向该仓库 main 分支。验证先跑一道问题注册完成后先用单题快速检查确认 ingest/search 真正可用bun run src/index.ts test -p myprovider -b locomo -q question_1 # one question, fast sanity check文档将这条命令标注为 one question, fast sanity check其中question_1是文档示例中的题目 ID。跑通这道题之前不建议直接开始完整 run。完整 run 与 Supermemory 对比验证通过后bun run src/index.ts run -p myprovider -b locomo # full run bun run src/index.ts compare -p myprovider,supermemory,mem0 -b locomo -l 20run让单个 provider 在指定 benchmark 上完整跑一遍compare用逗号分隔的 provider 列表在同一个 benchmark 上做对比——Supermemory 是内置 provider直接写进-p列表即可它会和你的 provider 走同一条 pipeline 被同样打分。文档示例命令中的-l 20对应 skill 里 20 for a real signal 的问题采样量快速检查时也可以只用 5 道。每次 run 都走同一条 checkpointed pipelineINGEST → SEARCH → ANSWER → EVALUATE → REPORT。大数据集的 ingest 可能耗时数小时、API 调用也会失败因此每个阶段独立 checkpointrun 从最后完成的步骤恢复而不是从头开始。正确性判定由可配置的 judge LLM 完成GPT-4o、Claude Sonnet、Gemini Flash 等任选返回{ score: 0 | 1, label: correct | incorrect, explanation: string }。judge 是刻意做到模型无关的——想排除单一评分模型的偏差可以用另一个 judge 重新给同一个 run 打分# Grade a run with a different judge bun run src/index.ts run -p supermemory -b locomo -j sonnet-4读取对比结果报告不会把所有指标压成一个数而是以 MemScore 形式并排报告三项对生产决策真正重要的指标以下为文档示例不是固定预期值MemScore: 86% / 145ms / 1823tok ▲ ▲ ▲ │ │ └─ context tokens sent to the answering model (cost) │ └───────── search latency └─────────────── answer accuracy vs. ground truth三个位置分别是答案准确率judge 分数 0–1 跨所有问题平均并按问题类型细分、搜索延迟每题的 search 与 answer 时间run 内 p50/p95、送进答题模型的 context tokens检索成本的代理指标。文档还给了粗略参考区间源自其在内置 benchmark 上的运行供快速定位量级准确率 80% 属 Excellent, production-ready60%则建议检查检索、prompt 或索引搜索延迟100ms属向量检索级别500ms值得优化。针对某一次具体 run可以bun 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 inspection每次 run 的结果与 checkpoint 存放在data/runs/{runId}/report.json内含按问题类型拆分的准确率、延迟分位数和每题 token 数。文档强调按问题类型拆分的细分通常比总表头数字更有用——比如你的 provider 在 LoCoMo 上强、在 LongMemEval 上弱说明时间/跨会话召回好但稠密检索弱反过来则是相反的情况。这直接指向你接下来要修什么。选择哪个 benchmarkMemoryBench 内置三个数据集覆盖不同的测试重点Benchmark测试内容LoCoMo跨长会话、多 session 对话的事实召回——single-hop、multi-hop、temporal、adversarialLongMemEval跨 session 的长期记忆包括对话中途被更新的知识ConvoMem单个对话内的个性化、偏好学习与指代消解如果三者都不匹配你的实际场景特定领域、用户真实会遇到的流程、想守护的回归可以按 Building a Benchmark 添加自定义数据集——provider、benchmark 和 judge 都是可插拔的包括 Supermemory 在内的所有 provider 会以同样方式跑在你的数据集上。更多细节可回到源文档Adding a Provider、MemoryBench Overview 与 Measuring Results。【免费下载链接】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），仅供参考
如何把自研记忆系统注册为 MemoryBench provider 并与 Supermemory 对比
如何把自研记忆系统注册为 MemoryBench provider 并与 Supermemory 对比【免费下载链接】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假设你已经有一个自研的记忆系统或 RAG 系统想把它和 Supermemory 放在同一组问题、同一条 pipeline、同一套 judge 下测出可对比的结果。Supermemory 为此开源了 MemoryBench 框架MIT 许可supermemoryai/memorybench所有 run 都走统一的 checkpointed pipelineINGEST → SEARCH → ANSWER → EVALUATE → REPORT。在这个框架里provider 就是任何能 ingest 会话并回答搜索查询的记忆/RAG 系统Supermemory、Mem0、Zep 是内置 provider而你的自研实现只是又一个 provider——注册之后它会和内置 provider 走完全相同的流程、以完全相同的标准被打分。文档给出两条注册路径让 MemoryBench skill 自动生成 provider 适配器或者自己手写适配器。两条路径都会落到同一套Provider接口和同一组运行命令上。选择注册路径快路径skillMemoryBench 附带一个 Claude Code skillbenchmark-context从读你的代码、生成并注册 provider 适配器到产出对比报告全程自动你不需要写任何 MemoryBench 特定的代码。手写你在 memorybench 仓库里自己实现Provider接口并注册适合想完全掌控适配器逻辑的情况。两条路径都需要拿到 memorybench 代码skill 路径会在其 Setup 阶段把memorybench克隆到./memorybench并安装依赖手写路径则需要你自行获取 memorybench 仓库overview 文档指向 GitHub 上的supermemoryai/memorybench后续所有命令都从该仓库根目录执行且文档中所有命令都通过bun运行。快路径运行 MemoryBench skill在你自己项目的根目录运行不要在 memorybench 目录内部运行——skill 会把框架克隆成子目录并通过相对路径分析你的代码# Run from your project root, not from inside memorybench /memorybench开始动作之前skill 会先问 5 个问题provider 名称你的记忆代码在哪里跑哪个 benchmark可参考 Building a Benchmark 中的内置数据集说明和哪些 provider 对比——Supermemory、Mem0、Zep或无需 API key 的filesystem/rag基线采样多少问题5 道用于快速检查20 道能得到有意义的信号也可以跑全集。随后它按 7 个阶段推进阶段内容1. Setup克隆memorybench到./memorybench并安装依赖2. Discoveryagent 阅读你的记忆代码找出其 init、ingest、search 方法3. Code generation生成实现Provider接口的 provider 适配器适配你的代码4. Registration在框架的 types 和 config 中注册该 provider5. Configuration收集你的 provider、对比 provider 以及 judge 模型的 API key写入.env.local6. Validation先端到端跑一道问题确认 ingest/search 真正可用再开始完整 run7. Benchmark execution跑完整对比并并排报告 accuracy、latency、context-token 结果也就是说skill 路径内置了验证步骤没有先跑通一道问题就不会进入完整 run。手写路径实现 Provider 接口每个 provider 都实现同一个接口memorybench 仓库的src/types/provider.tsinterface Provider { name: string prompts?: ProviderPrompts initialize(config: ProviderConfig): Promisevoid ingest(sessions: UnifiedSession[], options: IngestOptions): PromiseIngestResult awaitIndexing(result: IngestResult, containerTag: string): Promisevoid search(query: string, options: SearchOptions): Promiseunknown[] clear(containerTag: string): Promisevoid }各方法的职责方法职责initialize()用 API key / 配置初始化你的客户端ingest()把 benchmark 会话推入你的系统返回生成的文档 IDawaitIndexing()阻塞到这些文档真正可被检索——同步索引的系统里是 no-op异步索引的系统里是带 backoff 的轮询循环search()执行查询按你系统返回的形状返回结果clear()删除某个containerTag下的所有内容避免不同 run 之间互相污染注册步骤文档示例统一以myprovider作为 provider 名实际替换成你的名称创建src/providers/myprovider/index.ts实现Provider在src/providers/index.ts中注册它把名称加入src/types/provider.ts里的ProviderName在src/utils/config.ts中加入它的配置API key、base URL 等可选如果你的搜索结果在交给答题 LLM 或 judge 前需要自定义格式化就覆盖promptsProviderPrompts。异步索引和自定义 prompt 的完整示例见 memorybench 仓库的src/providers/README.md文档中的链接指向该仓库 main 分支。验证先跑一道问题注册完成后先用单题快速检查确认 ingest/search 真正可用bun run src/index.ts test -p myprovider -b locomo -q question_1 # one question, fast sanity check文档将这条命令标注为 one question, fast sanity check其中question_1是文档示例中的题目 ID。跑通这道题之前不建议直接开始完整 run。完整 run 与 Supermemory 对比验证通过后bun run src/index.ts run -p myprovider -b locomo # full run bun run src/index.ts compare -p myprovider,supermemory,mem0 -b locomo -l 20run让单个 provider 在指定 benchmark 上完整跑一遍compare用逗号分隔的 provider 列表在同一个 benchmark 上做对比——Supermemory 是内置 provider直接写进-p列表即可它会和你的 provider 走同一条 pipeline 被同样打分。文档示例命令中的-l 20对应 skill 里 20 for a real signal 的问题采样量快速检查时也可以只用 5 道。每次 run 都走同一条 checkpointed pipelineINGEST → SEARCH → ANSWER → EVALUATE → REPORT。大数据集的 ingest 可能耗时数小时、API 调用也会失败因此每个阶段独立 checkpointrun 从最后完成的步骤恢复而不是从头开始。正确性判定由可配置的 judge LLM 完成GPT-4o、Claude Sonnet、Gemini Flash 等任选返回{ score: 0 | 1, label: correct | incorrect, explanation: string }。judge 是刻意做到模型无关的——想排除单一评分模型的偏差可以用另一个 judge 重新给同一个 run 打分# Grade a run with a different judge bun run src/index.ts run -p supermemory -b locomo -j sonnet-4读取对比结果报告不会把所有指标压成一个数而是以 MemScore 形式并排报告三项对生产决策真正重要的指标以下为文档示例不是固定预期值MemScore: 86% / 145ms / 1823tok ▲ ▲ ▲ │ │ └─ context tokens sent to the answering model (cost) │ └───────── search latency └─────────────── answer accuracy vs. ground truth三个位置分别是答案准确率judge 分数 0–1 跨所有问题平均并按问题类型细分、搜索延迟每题的 search 与 answer 时间run 内 p50/p95、送进答题模型的 context tokens检索成本的代理指标。文档还给了粗略参考区间源自其在内置 benchmark 上的运行供快速定位量级准确率 80% 属 Excellent, production-ready60%则建议检查检索、prompt 或索引搜索延迟100ms属向量检索级别500ms值得优化。针对某一次具体 run可以bun 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 inspection每次 run 的结果与 checkpoint 存放在data/runs/{runId}/report.json内含按问题类型拆分的准确率、延迟分位数和每题 token 数。文档强调按问题类型拆分的细分通常比总表头数字更有用——比如你的 provider 在 LoCoMo 上强、在 LongMemEval 上弱说明时间/跨会话召回好但稠密检索弱反过来则是相反的情况。这直接指向你接下来要修什么。选择哪个 benchmarkMemoryBench 内置三个数据集覆盖不同的测试重点Benchmark测试内容LoCoMo跨长会话、多 session 对话的事实召回——single-hop、multi-hop、temporal、adversarialLongMemEval跨 session 的长期记忆包括对话中途被更新的知识ConvoMem单个对话内的个性化、偏好学习与指代消解如果三者都不匹配你的实际场景特定领域、用户真实会遇到的流程、想守护的回归可以按 Building a Benchmark 添加自定义数据集——provider、benchmark 和 judge 都是可插拔的包括 Supermemory 在内的所有 provider 会以同样方式跑在你的数据集上。更多细节可回到源文档Adding a Provider、MemoryBench Overview 与 Measuring Results。【免费下载链接】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），仅供参考 
)
