AI 项目评估报告：基线、对照与失败证据

先确定什么算成功

一个答案看起来流畅，只能说明展示正常。项目验收需要分别检查检索是否找到依据、生成是否引用正确、应拒绝的问题是否拒绝、工具是否完成允许的任务、请求是否正常结束。

保存问题 ID、输入、预期行为、相关文档/片段、身份、难度标签和标注依据。无答案、越权、文档更新和注入输入应单独覆盖。题集变了就建立新版本，不能把新题分数与旧题直接相减。

一份可复核报告的知识点

部分	记录内容	容易误判的地方
运行清单	数据/题集版本、代码 commit、配置、模型和索引、日期	只写框架名，无法复现
基线	关键词/固定工作流/已有系统，固定运行条件	基线被故意设得过弱
检索	标注相关片段、Recall@k、排序、过滤后结果	只量返回数量，没量相关性
答案	正确性、证据支持、引用、合理拒答	把引用存在当引用正确
工具与权限	任务完成、重复操作、拒绝与状态	只检查最终文本，漏掉越权动作
服务与成本	完整请求成功、首字/总延迟、负载、成功任务成本	只测顺利样本或忽略重试
失败	每题结果、分类、根因、修复与复测	只展示最好案例

成本和时延要写单位、测量窗口、样本数与负载；没有实际执行的字段写“未执行”。小样本允许找问题，不能据此保证线上通过率。

比较与归因

先比较同一题集上的基线和候选，再改变一个关键因素，例如只加入 reranker。若同时换模型、切片与提示，收益只能归于整套方案，无法证明其中哪个模块有效。

保留每题成败配对、分组结果与不确定性。由这批固定题得到的平均值，只覆盖该题集；离线配对比较也不等于真实用户流量中的因果收益。重复选优还可能逐渐针对测试集调参，应保留独立验证集。

使用 LLM judge 时，记录评分提示、judge 版本与参数；用人工标注样本核对分歧和偏差。不要让同一模型的自我评分成为唯一事实依据。

项目中的实际小报告

本站 权限与缓存实验 用同一组 10 个顺序场景比较两种缓存策略，预期结果由 fixture 明确指定。4/10 与 10/10 是该实验的匹配数，不能解释为真实 RAG 答案准确率、安全覆盖率或线上收益。

这个例子包含可复现基线、改动、逐项失败和已知边界。完整模型项目仍需要自己的真实输出与指标，不能直接借用本站实验成绩。

练习与验收

使用仓库内的 docs/practice/evaluation-report.md，先写题集、基线、分母和门槛，再执行自己的项目。报告至少保留原始逐题输出、一个失败根因、修复前后同题比较和局限。涉及服务、模型与费用的运行条件要真实填写。

复习问题

1. 为什么 100% 的测试通过率仍可能有未知失败？
2. 应拒绝的问题算成功还是失败，如何定义分母？
3. 同时调整三个模块后，怎样表述结果才不过度归因？

阅读依据与核验

• 04-evaluation/README.md
• project.md

2026-10-08：AI 助手协助原创组织与核对来源；案例、练习与手算的执行状态见正文；不把学习任务视为已完成的模型或线上实验。