agentmemory 真实向量嵌入评测BM25 本地 Embedding 混合检索的量化验证【免费下载链接】agentmemory#1 Persistent memory for AI coding agents based on real-world benchmarks项目地址: https://gitcode.com/GitHub_Trending/age/agentmemory本篇文章围绕 agentmemory 的 benchmark/REAL-EMBEDDINGS.md 评测报告展开完整还原 agentmemory v0.6.0 在 240 条观察记录、30 个会话、20 条带标注查询上的检索质量对比实验纯 grep 全量扫描、BM25-only、BM25 本地向量Dual-stream、BM25 向量 知识图谱Triple-stream四种检索系统的 Recall / Precision / NDCG / MRR 全面对决。读完你可以掌握真实向量嵌入相对关键词检索到底能带来多少可量化的召回提升、为什么本地 EmbeddingXenova/all-MiniLM-L6-v2是零成本默认推荐、以及如何通过环境变量把 agentmemory 从关键词检索切换到语义检索并复现本评测。评测背景为什么关键词检索不够用agentmemory 是一个面向 AI 编码 Agent 的持久化记忆系统。其记忆管线在每条观察observation被摄入时会经历去重、隐私过滤、LLM 压缩为结构化事实facts 概念concepts 叙述narrative然后执行「向量嵌入 → 索引进 BM25 向量」的步骤见 README.md 中的管线示意。搜索时则采用「BM25 Vector GraphRRF 融合」的三流混合检索。但关键词检索有一个众所周知的短板它只能命中字面匹配。当 Agent 事后问「database performance optimization」时纯关键词系统找不到标题为「Fix N1 query in post listing」的记忆——因为两者没有一个词是相同的而人类语义上它们强相关。真实向量嵌入的价值正是让记忆检索从「字面匹配」升级为「语义匹配」。评测设定数据集、对照系统与指标本次评测由 benchmark/real-embeddings-eval.ts 驱动报告由同一脚本自动生成并写回 benchmark/REAL-EMBEDDINGS.md。数据集由 benchmark/dataset.ts 的generateDataset()生成——30 个会话、每会话 8 条观察共 240 条 CompressedObservation外加 20 条带relevantObsIds标注的查询。每条查询带有category分类exact精确匹配、semantic语义匹配、temporal时间、cross-session跨会话、entity实体。数据集内容模拟了一个真实 webapp 项目从脚手架搭建、鉴权、数据库、API、测试到部署运维的完整生命周期观察记录由title、narrative、facts、concepts、files、importance等字段构成。四套对照系统对应评测脚本中的四个阶段系统构造方式源码依据Built-in (grep all)模拟「把全部记忆塞进上下文」的基线逐条观察做子串匹配打分见evalBuiltinGrepBM25-onlySearchIndex 词干化 同义词权重{ bm25: 1.0, vector: 0, graph: 0 }Dual-streamBM25 真实 Xenova 向量权重{ bm25: 0.4, vector: 0.6, graph: 0 }Triple-streamBM25 向量 图谱检索权重{ bm25: 0.4, vector: 0.6, graph: 0.3 }评测指标脚本内实现于 benchmark/real-embeddings-eval.tsRecall5/Recall10Top-K 中相关记忆占全部相关记忆的比例、Precision5、NDCG10排序质量、MRR首个相关结果的倒数排名、平均延迟、以及每次查询返回结果折算的 token 数estimateTokens按字符数 / 4 估算。Head-to-Head真实向量嵌入 vs 关键词检索报告核心结果如下数据来自 benchmark/REAL-EMBEDDINGS.md系统Recall5Recall10Precision5NDCG10MRR平均延迟Tokens/queryBuilt-in (grep all)37.0%55.8%78.0%80.3%82.5%0.44ms19,462BM25-only (stemmedsynonyms)43.8%55.9%95.0%82.7%95.5%0.26ms1,571Dual-stream (BM25Xenova)43.8%64.1%98.0%94.9%100.0%2.39ms1,571Triple-stream (BM25XenovaGraph)43.8%64.1%98.0%94.9%100.0%2.07ms1,571几个关键读数召回是差距所在Recall10 从 grep 的 55.8% 提升到向量增强后的 64.1%而 Recall5 稳定在 43.8%说明前 5 条的结果差异不大向量主要在更深的位置把「语义相关但字面不匹配」的记忆捞了回来。MRR 提升显著从 grep 的 82.5%、BM25-only 的 95.5% 提升到 100.0%——即加入向量后20 条查询的首个相关结果全部排在第一位。Token 成本是数量级差距grep 基线平均每次查询要吞掉 19,462 tokens相当于把 240 条记忆全量灌进上下文而检索式方案仅返回 Top-K每次查询折算约 1,571 tokens节省 92%。这与 README.md 中「agentmemory 约 1,900 tokens比全量加载少 92%」的表述相互印证。延迟代价可忽略向量检索平均 2.39mstriple-stream 因并发图检索反而更快2.07ms相对 grep 的 0.44ms 和 BM25 的 0.26ms对 Agent 会话注入场景完全无感。向量嵌入带来的净收益报告给出了两个量化结论在 BM25 之上叠加真实向量嵌入Recall10 提升 8.2 个百分点55.9% → 64.1%。相对全量加载greptoken 节省 92%1,571 vs 19,462 tokens。这里的核心洞察是BM25 负责精准、向量负责召回。BM25 的词干化 同义词已经能覆盖精确/实体类查询而向量弥补的是语义鸿沟——这是单靠关键词无法达到的。Per-Query 分析向量在哪些查询上赢报告中列出了 Dual-stream真实向量显著优于 BM25-only 的查询查询类别BM25 Recall10Vector Recall10增量How did we set up authentication?semantic25.0%45.0%20.0ppPlaywright test configurationexact50.0%90.0%40.0ppdatabase performance optimizationsemantic0.0%40.0%40.0pptest infrastructure and factoriesexact50.0%80.0%30.0ppPrisma ORM configurationentity14.3%28.6%14.3ppCI/CD pipeline configurationexact20.0%40.0%20.0pp最典型的案例是「database performance optimization」BM25 的 Recall10 是 0.0%即一条相关记忆都找不到。因为数据集中相关记忆的标题是「Fix N1 query in post listing」「Add Redis caching layer for expensive queries」等与查询没有任何共享词。加入向量后Recall10 提升到 40.0%——向量理解到「performance optimization」与「N1 query fix」「eager loading」「caching」之间的语义关联。这正是本报告最有力的论据语义检索解决的是关键词检索的结构性盲区而非边际优化。按类别对比不同查询类型的最优解类别Built-in grepBM25 (stemmed)Real VectorsGraphexact48.0%54.0%72.0%72.0%semantic35.5%33.3%41.9%41.9%cross-session77.8%77.8%77.8%77.8%entity79.0%76.2%79.0%79.0%表格为 Recall10数据来自报告原文。结论分层清晰exact 类查询向量带来最大增益54.0% → 72.0%原因在于精确查询往往是复合短语如「Playwright test configuration」BM25 只能部分命中而向量能整体匹配语义semantic 类查询从 33.3% 提升到 41.9%是向量价值的主战场cross-session / entity 类查询BM25 已能很好覆盖向量增益有限0pp ~ 2.8pp。这也印证了报告 Key Findings 的第 3 条实体/精确查询由 BM25 词干化服务即可向量是锦上添花值得注意BM25 在 entity 类别上反而略低于 grep76.2% vs 79.0%说明词干化对专有名词如 Prisma、Terraform存在过度归并的风险而向量又把它拉了回来——多流融合的意义正在于此。嵌入性能一次性摄入成本系统嵌入耗时模型维度Dual-stream (BM25Xenova)3.1sXenova/all-MiniLM-L6-v2384Triple-stream (BM25XenovaGraph)2.9sXenova/all-MiniLM-L6-v2384嵌入是一次性摄入成本索引完成后搜索为亚毫秒级。评测脚本中嵌入以 32 条为一批调用provider.embedBatch分批进行见 benchmark/real-embeddings-eval.ts 的batchSize 32240 条观察全部嵌入仅需约 3 秒且不需要任何 API key、不产生任何 API 调用费用。关键结论回顾报告总结的四条核心发现语义类查询受益最大真实嵌入带来 8.6pp 的 Recall10 提升最难的查询「database performance optimization」从 BM25 的 0.0% 提升到向量增强后的 40.0%实体/精确查询已被 BM25 词干化良好服务向量增益边际化本地嵌入Xenova无需 API key——零成本、零延迟顾虑。推荐配置开启本地 Embedding报告的最终建议非常明确默认启用本地嵌入——设置EMBEDDING_PROVIDERlocal或安装huggingface/transformers依赖。这能让 agentmemory 获得内置 Agent 记忆系统无法匹敌的语义检索能力。环境变量与权重配置agentmemory 的嵌入配置在 src/config.ts 的loadEmbeddingConfig()与detectEmbeddingProvider()中解析# 强制使用本地嵌入无需任何 API key EMBEDDING_PROVIDERlocal # 可选调整混合检索权重默认值见下 BM25_WEIGHT0.4 VECTOR_WEIGHT0.6EMBEDDING_PROVIDER显式指定提供方可选local、gemini、openai、voyage、cohere、openrouter若未显式设置则按 API key 存在与否自动探测GEMINI_API_KEY→OPENAI_API_KEY→VOYAGE_API_KEY→COHERE_API_KEY→OPENROUTER_API_KEY都没有则返回null系统退化为纯 BM25 检索BM25_WEIGHT默认 0.4、VECTOR_WEIGHT默认 0.6非法或负数时回退默认值且上限截断为 1。评测中 Triple-stream 的图谱权重graphWeight 0.3在 benchmark/real-embeddings-eval.ts 的构造参数中直接传入。Provider 的统一工厂在 src/providers/embedding/index.ts 的createEmbeddingProvider()中每种 provider 都被withDimensionGuard包裹防止「维度不匹配的向量静默写入索引导致记忆不可见」的坑vector-index.ts 的余弦相似度在长度不一致时返回 0 而非抛错守卫在边界拦截。本地嵌入的底层实现EMBEDDING_PROVIDERlocal对应 src/providers/embedding/local.ts 的LocalEmbeddingProvider固定dimensions 384通过huggingface/transformers加载Xenova/all-MiniLM-L6-v2模型首次运行会下载约 80MB 模型文件pipeline 配置{ dtype: q8 }8-bit 量化降低内存占用提取参数{ pooling: mean, normalize: true }均值池化 L2 归一化输出Float32Array向量未安装依赖时抛出清晰提示npm install huggingface/transformers该行为由 test/local-embedding-provider.test.ts 的测试用例锁定。混合检索的融合原理向量与 BM25、图谱如何融合答案在 src/state/hybrid-search.ts 的HybridSearch.tripleStreamSearch()三流并行检索BM25 命中 向量余弦相似度命中 图谱实体检索命中各自产出带排名的结果集RRFReciprocal Rank Fusion加权融合RRF_K 60每条结果按weight * (1 / (RRF_K rank))加权多流同时命中的结果获得AGREEMENT_BONUS 0.05的协同增益会话去重diversifyBySession限制每会话最多 3 条防止单一会话刷屏可选 LLM 重排设置RERANK_ENABLEDtrue后对 Top-20 窗口执行 src/state/reranker.ts 的重排向量检索由 src/state/vector-index.ts 的VectorIndex.search()实现余弦相似度 Top-K序列化时以 base64 存储Float32Array注意处理了 Node Buffer 池切片的「幻影 2048 维度」问题。这一设计与评测结论一致BM25 保精准、向量保召回、图谱提供跨记忆的关系线索三者融合后在 Recall1064.1%、Precision598.0%、MRR100.0%上同时取得最优。如何复现本评测在仓库根目录执行需要先安装依赖# 安装本地嵌入依赖评测脚本首次加载模型需联网下载约 80MB npm install huggingface/transformers # 运行真实嵌入质量评测等价于 npm run eval:real-embeddings 脚本入口 node --import tsx benchmark/real-embeddings-eval.ts脚本依次执行四阶段评测grep 基线 → BM25-only → Dual-stream → Triple-stream每阶段打印 Recall10最后将完整报告写入 benchmark/REAL-EMBEDDINGS.md。评测结果文件与其余基准LongMemEval、质量评估、负载压测的组织方式详见 benchmark/README.md。若模型加载失败脚本会提示先执行npm install huggingface/transformers。小结本次真实嵌入评测为 agentmemory 的混合检索架构提供了清晰的证据链向量嵌入不是可选的锦上添花而是语义检索能力的关键支撑——它把最难的一类查询语义泛化从「完全不可召回」提升到 40% 的 Recall10同时在 240 条记忆规模下把每次查询的 token 成本从 19,462 压缩到 1,571。而这一切通过一行EMBEDDING_PROVIDERlocal即可启用无需任何 API key 与外部服务是一次零成本、可验证、收益显著的升级。本评测全部测量基于 Xenova/all-MiniLM-L6-v2 本地嵌入384 维无 API 调用原始数据与生成脚本见 benchmark/REAL-EMBEDDINGS.md 与 benchmark/real-embeddings-eval.ts。【免费下载链接】agentmemory#1 Persistent memory for AI coding agents based on real-world benchmarks项目地址: https://gitcode.com/GitHub_Trending/age/agentmemory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 agentmemory 真实向量嵌入评测：BM25 + 本地 Embedding 混合检索的量化验证
agentmemory 真实向量嵌入评测BM25 本地 Embedding 混合检索的量化验证【免费下载链接】agentmemory#1 Persistent memory for AI coding agents based on real-world benchmarks项目地址: https://gitcode.com/GitHub_Trending/age/agentmemory本篇文章围绕 agentmemory 的 benchmark/REAL-EMBEDDINGS.md 评测报告展开完整还原 agentmemory v0.6.0 在 240 条观察记录、30 个会话、20 条带标注查询上的检索质量对比实验纯 grep 全量扫描、BM25-only、BM25 本地向量Dual-stream、BM25 向量 知识图谱Triple-stream四种检索系统的 Recall / Precision / NDCG / MRR 全面对决。读完你可以掌握真实向量嵌入相对关键词检索到底能带来多少可量化的召回提升、为什么本地 EmbeddingXenova/all-MiniLM-L6-v2是零成本默认推荐、以及如何通过环境变量把 agentmemory 从关键词检索切换到语义检索并复现本评测。评测背景为什么关键词检索不够用agentmemory 是一个面向 AI 编码 Agent 的持久化记忆系统。其记忆管线在每条观察observation被摄入时会经历去重、隐私过滤、LLM 压缩为结构化事实facts 概念concepts 叙述narrative然后执行「向量嵌入 → 索引进 BM25 向量」的步骤见 README.md 中的管线示意。搜索时则采用「BM25 Vector GraphRRF 融合」的三流混合检索。但关键词检索有一个众所周知的短板它只能命中字面匹配。当 Agent 事后问「database performance optimization」时纯关键词系统找不到标题为「Fix N1 query in post listing」的记忆——因为两者没有一个词是相同的而人类语义上它们强相关。真实向量嵌入的价值正是让记忆检索从「字面匹配」升级为「语义匹配」。评测设定数据集、对照系统与指标本次评测由 benchmark/real-embeddings-eval.ts 驱动报告由同一脚本自动生成并写回 benchmark/REAL-EMBEDDINGS.md。数据集由 benchmark/dataset.ts 的generateDataset()生成——30 个会话、每会话 8 条观察共 240 条 CompressedObservation外加 20 条带relevantObsIds标注的查询。每条查询带有category分类exact精确匹配、semantic语义匹配、temporal时间、cross-session跨会话、entity实体。数据集内容模拟了一个真实 webapp 项目从脚手架搭建、鉴权、数据库、API、测试到部署运维的完整生命周期观察记录由title、narrative、facts、concepts、files、importance等字段构成。四套对照系统对应评测脚本中的四个阶段系统构造方式源码依据Built-in (grep all)模拟「把全部记忆塞进上下文」的基线逐条观察做子串匹配打分见evalBuiltinGrepBM25-onlySearchIndex 词干化 同义词权重{ bm25: 1.0, vector: 0, graph: 0 }Dual-streamBM25 真实 Xenova 向量权重{ bm25: 0.4, vector: 0.6, graph: 0 }Triple-streamBM25 向量 图谱检索权重{ bm25: 0.4, vector: 0.6, graph: 0.3 }评测指标脚本内实现于 benchmark/real-embeddings-eval.tsRecall5/Recall10Top-K 中相关记忆占全部相关记忆的比例、Precision5、NDCG10排序质量、MRR首个相关结果的倒数排名、平均延迟、以及每次查询返回结果折算的 token 数estimateTokens按字符数 / 4 估算。Head-to-Head真实向量嵌入 vs 关键词检索报告核心结果如下数据来自 benchmark/REAL-EMBEDDINGS.md系统Recall5Recall10Precision5NDCG10MRR平均延迟Tokens/queryBuilt-in (grep all)37.0%55.8%78.0%80.3%82.5%0.44ms19,462BM25-only (stemmedsynonyms)43.8%55.9%95.0%82.7%95.5%0.26ms1,571Dual-stream (BM25Xenova)43.8%64.1%98.0%94.9%100.0%2.39ms1,571Triple-stream (BM25XenovaGraph)43.8%64.1%98.0%94.9%100.0%2.07ms1,571几个关键读数召回是差距所在Recall10 从 grep 的 55.8% 提升到向量增强后的 64.1%而 Recall5 稳定在 43.8%说明前 5 条的结果差异不大向量主要在更深的位置把「语义相关但字面不匹配」的记忆捞了回来。MRR 提升显著从 grep 的 82.5%、BM25-only 的 95.5% 提升到 100.0%——即加入向量后20 条查询的首个相关结果全部排在第一位。Token 成本是数量级差距grep 基线平均每次查询要吞掉 19,462 tokens相当于把 240 条记忆全量灌进上下文而检索式方案仅返回 Top-K每次查询折算约 1,571 tokens节省 92%。这与 README.md 中「agentmemory 约 1,900 tokens比全量加载少 92%」的表述相互印证。延迟代价可忽略向量检索平均 2.39mstriple-stream 因并发图检索反而更快2.07ms相对 grep 的 0.44ms 和 BM25 的 0.26ms对 Agent 会话注入场景完全无感。向量嵌入带来的净收益报告给出了两个量化结论在 BM25 之上叠加真实向量嵌入Recall10 提升 8.2 个百分点55.9% → 64.1%。相对全量加载greptoken 节省 92%1,571 vs 19,462 tokens。这里的核心洞察是BM25 负责精准、向量负责召回。BM25 的词干化 同义词已经能覆盖精确/实体类查询而向量弥补的是语义鸿沟——这是单靠关键词无法达到的。Per-Query 分析向量在哪些查询上赢报告中列出了 Dual-stream真实向量显著优于 BM25-only 的查询查询类别BM25 Recall10Vector Recall10增量How did we set up authentication?semantic25.0%45.0%20.0ppPlaywright test configurationexact50.0%90.0%40.0ppdatabase performance optimizationsemantic0.0%40.0%40.0pptest infrastructure and factoriesexact50.0%80.0%30.0ppPrisma ORM configurationentity14.3%28.6%14.3ppCI/CD pipeline configurationexact20.0%40.0%20.0pp最典型的案例是「database performance optimization」BM25 的 Recall10 是 0.0%即一条相关记忆都找不到。因为数据集中相关记忆的标题是「Fix N1 query in post listing」「Add Redis caching layer for expensive queries」等与查询没有任何共享词。加入向量后Recall10 提升到 40.0%——向量理解到「performance optimization」与「N1 query fix」「eager loading」「caching」之间的语义关联。这正是本报告最有力的论据语义检索解决的是关键词检索的结构性盲区而非边际优化。按类别对比不同查询类型的最优解类别Built-in grepBM25 (stemmed)Real VectorsGraphexact48.0%54.0%72.0%72.0%semantic35.5%33.3%41.9%41.9%cross-session77.8%77.8%77.8%77.8%entity79.0%76.2%79.0%79.0%表格为 Recall10数据来自报告原文。结论分层清晰exact 类查询向量带来最大增益54.0% → 72.0%原因在于精确查询往往是复合短语如「Playwright test configuration」BM25 只能部分命中而向量能整体匹配语义semantic 类查询从 33.3% 提升到 41.9%是向量价值的主战场cross-session / entity 类查询BM25 已能很好覆盖向量增益有限0pp ~ 2.8pp。这也印证了报告 Key Findings 的第 3 条实体/精确查询由 BM25 词干化服务即可向量是锦上添花值得注意BM25 在 entity 类别上反而略低于 grep76.2% vs 79.0%说明词干化对专有名词如 Prisma、Terraform存在过度归并的风险而向量又把它拉了回来——多流融合的意义正在于此。嵌入性能一次性摄入成本系统嵌入耗时模型维度Dual-stream (BM25Xenova)3.1sXenova/all-MiniLM-L6-v2384Triple-stream (BM25XenovaGraph)2.9sXenova/all-MiniLM-L6-v2384嵌入是一次性摄入成本索引完成后搜索为亚毫秒级。评测脚本中嵌入以 32 条为一批调用provider.embedBatch分批进行见 benchmark/real-embeddings-eval.ts 的batchSize 32240 条观察全部嵌入仅需约 3 秒且不需要任何 API key、不产生任何 API 调用费用。关键结论回顾报告总结的四条核心发现语义类查询受益最大真实嵌入带来 8.6pp 的 Recall10 提升最难的查询「database performance optimization」从 BM25 的 0.0% 提升到向量增强后的 40.0%实体/精确查询已被 BM25 词干化良好服务向量增益边际化本地嵌入Xenova无需 API key——零成本、零延迟顾虑。推荐配置开启本地 Embedding报告的最终建议非常明确默认启用本地嵌入——设置EMBEDDING_PROVIDERlocal或安装huggingface/transformers依赖。这能让 agentmemory 获得内置 Agent 记忆系统无法匹敌的语义检索能力。环境变量与权重配置agentmemory 的嵌入配置在 src/config.ts 的loadEmbeddingConfig()与detectEmbeddingProvider()中解析# 强制使用本地嵌入无需任何 API key EMBEDDING_PROVIDERlocal # 可选调整混合检索权重默认值见下 BM25_WEIGHT0.4 VECTOR_WEIGHT0.6EMBEDDING_PROVIDER显式指定提供方可选local、gemini、openai、voyage、cohere、openrouter若未显式设置则按 API key 存在与否自动探测GEMINI_API_KEY→OPENAI_API_KEY→VOYAGE_API_KEY→COHERE_API_KEY→OPENROUTER_API_KEY都没有则返回null系统退化为纯 BM25 检索BM25_WEIGHT默认 0.4、VECTOR_WEIGHT默认 0.6非法或负数时回退默认值且上限截断为 1。评测中 Triple-stream 的图谱权重graphWeight 0.3在 benchmark/real-embeddings-eval.ts 的构造参数中直接传入。Provider 的统一工厂在 src/providers/embedding/index.ts 的createEmbeddingProvider()中每种 provider 都被withDimensionGuard包裹防止「维度不匹配的向量静默写入索引导致记忆不可见」的坑vector-index.ts 的余弦相似度在长度不一致时返回 0 而非抛错守卫在边界拦截。本地嵌入的底层实现EMBEDDING_PROVIDERlocal对应 src/providers/embedding/local.ts 的LocalEmbeddingProvider固定dimensions 384通过huggingface/transformers加载Xenova/all-MiniLM-L6-v2模型首次运行会下载约 80MB 模型文件pipeline 配置{ dtype: q8 }8-bit 量化降低内存占用提取参数{ pooling: mean, normalize: true }均值池化 L2 归一化输出Float32Array向量未安装依赖时抛出清晰提示npm install huggingface/transformers该行为由 test/local-embedding-provider.test.ts 的测试用例锁定。混合检索的融合原理向量与 BM25、图谱如何融合答案在 src/state/hybrid-search.ts 的HybridSearch.tripleStreamSearch()三流并行检索BM25 命中 向量余弦相似度命中 图谱实体检索命中各自产出带排名的结果集RRFReciprocal Rank Fusion加权融合RRF_K 60每条结果按weight * (1 / (RRF_K rank))加权多流同时命中的结果获得AGREEMENT_BONUS 0.05的协同增益会话去重diversifyBySession限制每会话最多 3 条防止单一会话刷屏可选 LLM 重排设置RERANK_ENABLEDtrue后对 Top-20 窗口执行 src/state/reranker.ts 的重排向量检索由 src/state/vector-index.ts 的VectorIndex.search()实现余弦相似度 Top-K序列化时以 base64 存储Float32Array注意处理了 Node Buffer 池切片的「幻影 2048 维度」问题。这一设计与评测结论一致BM25 保精准、向量保召回、图谱提供跨记忆的关系线索三者融合后在 Recall1064.1%、Precision598.0%、MRR100.0%上同时取得最优。如何复现本评测在仓库根目录执行需要先安装依赖# 安装本地嵌入依赖评测脚本首次加载模型需联网下载约 80MB npm install huggingface/transformers # 运行真实嵌入质量评测等价于 npm run eval:real-embeddings 脚本入口 node --import tsx benchmark/real-embeddings-eval.ts脚本依次执行四阶段评测grep 基线 → BM25-only → Dual-stream → Triple-stream每阶段打印 Recall10最后将完整报告写入 benchmark/REAL-EMBEDDINGS.md。评测结果文件与其余基准LongMemEval、质量评估、负载压测的组织方式详见 benchmark/README.md。若模型加载失败脚本会提示先执行npm install huggingface/transformers。小结本次真实嵌入评测为 agentmemory 的混合检索架构提供了清晰的证据链向量嵌入不是可选的锦上添花而是语义检索能力的关键支撑——它把最难的一类查询语义泛化从「完全不可召回」提升到 40% 的 Recall10同时在 240 条记忆规模下把每次查询的 token 成本从 19,462 压缩到 1,571。而这一切通过一行EMBEDDING_PROVIDERlocal即可启用无需任何 API key 与外部服务是一次零成本、可验证、收益显著的升级。本评测全部测量基于 Xenova/all-MiniLM-L6-v2 本地嵌入384 维无 API 调用原始数据与生成脚本见 benchmark/REAL-EMBEDDINGS.md 与 benchmark/real-embeddings-eval.ts。【免费下载链接】agentmemory#1 Persistent memory for AI coding agents based on real-world benchmarks项目地址: https://gitcode.com/GitHub_Trending/age/agentmemory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考