怎样证明项目有效？

返回 EachOf 项目 目录

项目版本说明

这些问答整合历史设计与实现资料；当前 main 分支 README 以工作包描述建设状态。具体能力、实验数据与设计目标的边界见项目状态与证据。

标准回答

分别验证“机制是否正确”“资料能否找对”“答案是否用对”“任务是否变好”。这四层证据不能相互替代。

四层验证

层次	要验证什么	例子
机制正确性	权限、纠正、撤销和重复提交是否按设计工作	撤销来源后，受控路径不再返回相关内容。
检索质量	能否找回相关资料，排序靠不靠前	相关记忆有没有进入前 5 或前 20。
回答质量	答案是否正确、依据是否有效	回答引用新规则，没有继续引用旧规则。
真实任务收益	使用者是否更快、更准确地继续工作	减少重复交代背景，提高跨会话任务完成率。

先理解三个指标

**Precision@K：**前 K 个结果里，相关结果占多少。示例：返回前 5 条，其中 4 条相关，Precision@5 = 4/5 = 80%。

**Recall@K：**全部应找回的相关资料中，前 K 条找回多少。示例：共 10 条相关资料，前 5 个结果覆盖 4 条，Recall@5 = 4/10 = 40%。某些问答评测用“有没有命中一个正确支持项”作为 recall@K 的查询级定义，必须读具体评测口径。

**MRR：**看第一条相关结果排第几。排第 1 得 1，排第 2 得 1/2，排第 5 得 1/5，再对查询求平均。它关心用户多快遇到第一条相关结果。

为什么指标会“看着进步，实际不可比”

换了数据集、模型、噪声量、K 值或“相关”的判定方式，数字就可能不能直接比较。例如按字符串出现判断相关，会把偶然命中当成功；按完整词覆盖判断，又可能漏掉同义表达。

所以讲任何提升，都要补充：相对哪个基线、在什么样本上、用什么模型、按什么规则、重复了几次。

当前资料怎么讲才准确

过往讨论中的“Precision@5 提升 3.75 个百分点”属于特定受控小样本、相对无衰减基线的结果，不能直接当作当前整体性能结论。本 Wiki 不把它放进默认项目讲述稿。

这次读取的仓库检索调查记录了 LoCoMo 场景下的排序不足，以及相关性判定规则与数据适配带来的评价限制；旧版 precision 与新版 recall 不能放在同一比较中。

推荐口径

“项目已围绕记忆状态、来源和受控读取建立机制；检索质量通过固定数据与模型进行评估。当前评估也暴露了排序和评测适配问题，我会分别定位，不把功能正确等同于检索效果领先。”

一个可执行的演示验证清单

• 在 Space A 写入并确认一条规则，记录来源。
• 授权的 Agent 在新会话查询，检查是否返回该规则及依据。
• 把 30 天改为 7 天，再查询原问题，检查旧答案是否被阻止或替换。
• 撤销来源，再从召回和答案路径检查。
• 用仅能访问 Space B 的身份查询，检查是否隔离。
• 在测试环境重试同一操作，检查没有重复权威记录。

这是建议的验证脚本思路，本次没有执行。报告时附上环境、版本、输入、输出与测试结果，才能称为当次验证证据。

内容来源

• EachOf Wiki · 记忆与上下文 · 原条目 evaluation