放回任务里：RAG、Agent 和 Memory 应该评什么？

答案读着顺，不代表任务做对了。知识库助手可能引用了旧规定，Agent 可能说着“完成了”却没把事情办成，记忆系统也可能认真遵循了一条早已过时的偏好。评估时要看的证据并不一样。下面都用虚构的小例子说明。

RAG：正确、切题、有依据，别只留一个总分

假设商店的政策是“仅支持 7 天内、未拆封的商品退货”。用户说自己已经拆封，问还能不能退。先别急着给回答打一个总分：

再检查资料有没有真的进入最终 prompt：检索命中后，仍可能在重排、拼接或截断时丢掉。检索没找到、找到但没传进去、模型看到了却用错，是三个不同的排查方向。工程实践里的完整错例把这条过程展开了。

引用存在也不等于引用正确。 要看那段话是否真的支持对应断言，而不是只检查有无 citation 标记。

Agent：说“做完了”，不等于真的做完

用户要求：「查两班航班，先别订。」Agent 展示了结果，最后说「已经完成」，但日志里还多了一次 create_booking。

用户已经明确说了“别订”。一旦实际发起订票，就不能因为搜索结果挺有用，再给一个高分把这件事平均掉。

另一个版本没有越权，却声称「草稿已保存」，实际最终状态没有 draft。就应该核对任务状态（task state）：

checks = {
    "no_booking": not any(event["type"] == "create_booking" for event in events),
    "draft_saved": final_state.get("draft_id") is not None,
}

这段只能演示具体规则，真实系统要有可信的事件记录与状态读取。工具返回「受理成功」不一定等于副作用完成；延迟、重试和幂等性也要纳入场景。

LLM judge 可以补充：给用户的失败说明是否诚实、下一步是否可执行、有没有忽略用户限制。每条判断附到相应证据上。运行前重置环境，记录工具错误和最终状态，避免把环境故障当作模型退步。参见 Anthropic 的 agent eval 实践。

Memory / personalization：记住了，不等于该用

旧记忆：「我喜欢短回答。」当前用户：「这次请详细解释推导。」

如果模型仍然只给一句话，不能因为它「使用了记忆」就加分。至少分别看：

• 当前意图：有没有优先遵循这次明确要求？
• 来源与时间：记忆是用户说的，还是模型推测的？是否已被更新？
• 纠正是否生效：用户修正以后，下一轮、下一个 session 是否还在犯？
• 隐私和边界：不该暴露的记忆有没有被不必要地带出来？

长期评估（longitudinal evaluation）要把状态接着往下传。比如用户今天改了偏好，下一次对话是否还会用旧版本？每轮都清空记忆，测不到这个问题。模拟用户可以帮助造压力场景，但模拟器满意，不代表真实用户也满意；造场景和打分若依赖同一个未经验证的偏好模型，也算不上独立验证。

代码：能执行的部分，别只问模型

编译、单元测试、静态检查是有用的第一层。LLM 可以看可读性、需求覆盖、潜在边界案例，但一句「实现正确」代替不了执行。

测试也会有漏项：若仅验证正常输入，一个遇到空列表就崩溃的实现可能全绿。把需求写成测试、加入边界和对抗输入，再让人或 judge 检查测试本身是否漏掉关键约束。安全相关问题不要只靠一个模型批准。

多模态：judge 有没有看到需要看的信息？

截图里有一张价格表，答案读错了一列。若只把 OCR 文本给 judge，而 OCR 丢了行列关系，judge 再强也不知道对应关系。

先确认输入里保留了哪些信息：图片分辨率、裁剪范围、OCR、图文顺序。再分别测试文字、图像、二者同时提供，以及图文冲突。移除图片应影响哪些问题、哪些不该影响，事先说清楚。

这里评的是 judge 的视觉证据使用，不是凭空给模型加一个 multimodal 标签。看不清关键字时允许 unknown；不要把模糊截图硬评成精确事实。

一个结果应该能指回具体部件

retrieval：必要材料没找到
generator：看到了材料，但承诺了错误期限
agent：越过权限，或最终状态没达成
memory：旧偏好覆盖了当前要求
judge：漏判、错误引用、解析失败、无法判断

这些都可能让总分下降，但修法完全不同。分项记录的价值，就是帮我们知道下一步到底改哪里。

接着做：跑一个最小评估流程