正文

项目是什么

这是一个用 KnowMe-Bench 评测团队自研记忆系统的项目。KnowMe-Bench 是一个衡量 Agent 长记忆能力的评测体系，核心方法是用长篇自传体叙事（如《那不勒斯四部曲》）构建“认知流”，通过三层七任务来测评 Agent 的人物理解能力。

我在实习期间负责对记忆系统进行全量测试、打分和错题分析，与研发同事协作完成从测试到优化的闭环。这个项目让我第一次真正直面了 LLM 的能力边界，也让我建立了“检索→总结→推理”的分层诊断方法论。

它在解决什么

团队自研的记忆系统需要和行业竞品（如 MEMOS）进行对比评测，了解各自的优势和短板。但 KnowMe-Bench 的错题量很大（几十到数百道），直接看结果很难定位问题根源。

核心挑战是：怎么从“答错了”推导出“哪里出了问题”？ 是检索没找到关键信息？还是找到了但 Agent 没用上？还是都用上了但推理过程出了错？如果不把这些问题分开，优化就会变成盲人摸象。

它是怎么工作的

整个评测流程大致是这样：

全量测试
  -> LLM 辅助初步分析
  -> 人工筛选和验证
  -> 错误归因（检索/总结/推理）
  -> 产出分析报告
  -> 反馈到系统优化

我和研发同事共同探讨出“检索→总结→推理”的三级诊断框架：

错误类型 定义 典型表现
检索失败 检索结果中没有正确答案的原文证据 召回了不相关的记忆，或关键证据未被召回
总结失败 检索到包含答案的信息，但 Agent 没有纳入考量 证据在检索结果中，但 Agent 的回答没有引用
推理错误 检索和总结都包含正确信息，但最终仍答错 Agent 引用了正确的证据，但推理过程出错

这个框架的价值在于：它把模糊的“答错了”变成了可定位的“哪个环节出了问题”，从而可以针对性优化。

我主要做了什么

我在这个项目里承担的是测试分析和方法论建设的工作，主要做了三类事情。

第一是全量测试和错题分析。 面对几十到数百道错题，我先用 LLM（GPT5.4）辅助初步分析，再人工筛选和整理错误占比。这个过程不是一次性的，而是反复迭代——每次优化后重新测试，看错误分布有没有变化。

第二是建立分层诊断方法论。 “检索→总结→推理”的三级框架不是一开始就有的，而是我和研发同事在反复讨论中逐步形成的。一开始我们对“错误归因”的理解也有分歧，最终通过具体案例的分析达成了共识。

第三是推动系统优化。 分析结果直接反馈到记忆系统的改进：优化了 prompt 设计，调整了记忆总结的触发频率和流程。这是从测试到优化的完整闭环。

产出结果

  • 完成 KnowMe-Bench 测试集全量测试，产出 T2-T5 的系统化错题分析报告
  • 建立“检索→总结→推理”分层诊断方法论，被团队采纳为标准分析框架
  • 分析结论直接优化了记忆系统的 prompt 和记忆总结的触发频率与流程

难点与复盘

这个项目最难的地方，不是分析错题本身，而是发现评测工具本身也有天花板。

用 LLM（GPT5.2）做错题分析时，我发现一个根本性问题：同一份结果并行分析两次，可能得到不同的错误占比。这说明 LLM-as-Judge 本身存在“能力天花板”——如果裁判都无法稳定地理解问题，那它的判断就不可靠。

这个观察引出了一个工程设计哲学：“human-in-the-loop”。LLM 可以帮助完成很多工作，但工作越复杂，错误越隐蔽，因此需要人做决策判断、结果验收，引导 LLM 的工作方向。在实践中，我们的工作流程是：LLM 做初步分析 → 人工筛选和验证 → 最终确认错误归因。这个流程既利用了 LLM 的效率，又保证了分析的可靠性。

另一个重要发现是：检索准确不一定理解准确。从错题分析结果看，检索错误总体占比较高，但难度越高的题（如 T5 回忆线索分析、T6 身身互动），推理错误占比越大。这说明高阶认知任务的瓶颈不在于“找得到”，而在于“想得明白”。这个发现也和 KnowMe-Bench 论文的结论一致：Level III（洞察层）任务即使最好的系统也只有 22.3%，是核心瓶颈。

最后

这个项目对我来说很有价值，因为它让我第一次真正直面了 LLM 的能力边界。之前对 LLM 的理解更多停留在“它能做什么”，这次则深入到“它做不好什么”以及“为什么做不好”。

从“LLM 能回答问题”到“LLM 能稳定地理解人物”，中间的距离不是模型能力的问题，而是信息处理、推理链路和评测方法论的问题。这个项目让我在工程层面对这个问题有了比较完整的体验，也让我对“人在回路”的设计哲学有了更深的理解。

← 返回项目列表