先理解
刚接触这个知识点
补齐先备概念，读原理与反例，再用自己的话解释为什么。
从核心原理开始 →知识目录选择核心方向与细分内容
理解 → 实现 → 排错 → 取舍
评测样本的独立性与代表性
考察任务采样、失败覆盖、数据泄漏与标注质量。
知识内容核对 2026-10-03 · 原题来源核对 2026-10-02
建议先理解：
RAG 的证据流与故障定位 →幂等、未知结果与任务恢复 →这个知识点，你想学到哪一步？
按当前基础选择起点，也可以依次深入。遇到不熟悉的概念，先回到核心原理；完成后用知识练习检查理解。
知识单元目录
LEARN · PRACTICE · REFLECT
知识学习与个人记录
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 评测样本的独立性与代表性
先理解核心原理
先备概念：训练与测试划分、抽样、任务初态
评测集是对目标任务分布的有限观察。样本相似性、选择过程与环境残留决定分数能推广到哪里，数量增加不能自动补足覆盖缺口。
Demo 选择不是抽样
展示时往往挑最顺利的输入，评测却要包含用户真正遇到的模糊请求、无答案和故障。先按任务风险、难度和频率列出分层，再确定每层的任务、初态和验收；高风险长尾可以单独报告，不必被常见简单题平均掉。
划分单位是信息来源
同一工单的改写、同一文档生成的问答具有共同信息，分到不同集合会让调试过程间接见过测试内容。按原始任务家族、文档或时间段分组，再做划分。即使不训练模型，反复针对保留题改 Prompt 也会形成适配。
样本与环境一起版本化
只有问题文本不足以复现，数据库初态、工具版本、允许权限和参考依据都影响答案。每次尝试清理副作用，避免上次运行写出的文件帮助下一次。新增线上失败先脱敏、确认可复现条件及标注争议；下面的数据治理方案属于教学设计。
用一个问题检查理解
只有 30 条好看的 Demo，如何建立可信的 Agent 评测集？
从真实目标任务和已知失败中分层抽样，覆盖常见、长尾、不可回答、权限拒绝和工具故障。每题定义输入、环境初态、允许动作、验收和证据，固定训练调试集与保留测试集。对脱敏和授权处理后再使用生产样本，避免只挑成功案例。评测集要版本化，并跟踪标注争议与新增失败，而不是不断修改答案让新版本过关。
实现与取舍
先定义代表什么业务
列出用户任务类型、风险、复杂度和实际占比，分别抽取样本。高频简单问题反映整体体验，低频越权写入等高风险任务需要独立门槛，不能被总体平均稀释。收集失败样本时保留触发条件与环境，不只保存最终用户问题。
每题是可执行任务包
记录用户输入、数据快照、工具可用状态、权限、预期产物与禁止动作。开放题可定义多个合法结果或约束集合，不强制某一句参考答案。对标注者给出判定说明，争议题经复核后再用于发布门槛；无法稳定评分的题应先改验收设计。
隔离调试和测量
开发集用于反复调 Prompt，保留测试集限制接触并按版本管理。近似改写和同一业务事件应按组划分，避免同一事件一半进入开发、一半进入测试。任务内容、标准答案、工具初态和评分器都保存版本，才能解释分数变化来自模型还是测试环境。
持续补齐而非只追数字
将线上失败经脱敏、核实后加入回归集，同时保留固定基准观察长期趋势。给出分任务类型的成功率、风险违规、成本和不确定范围。30 条 Demo 可以启动问题发现，但不足以证明复杂生产分布表现；样本量应随业务差异和风险增加。
工程推演
- 场景
- 面试假设：团队展示 30 条成功 Demo，准备接入企业写工具。
- 设计决策
- 加入真实任务分布、故障与权限场景，并建立保留集。
- 验证目标
- 发布依据覆盖任务与风险，不由演示观感决定。
- 适用边界
- 样本规模需按置信要求和风险设计，不把固定题量当质量保证。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层同一问题换个说法能分到测试集吗？
题库划分需要检验文本不同是否仍共享答案信息。
参考解答
通常不能随机拆开。同一语义任务的多种表述要归入同一家族，整体分配到调试集或测试集；若专门测改写稳健性，可在独立协议下比较表述，但不能声称这是全新任务泛化。需同时检查共享文档、实体与对话来源。
沿着这个回答继续深入
第 2 层按文档分组后，测试题仍使用公开框架文档，这算泄漏吗？
父问防止任务复用，继续区分共享背景知识与测试答案泄漏。
参考解答
公开背景知识不自动等于泄漏。关键是调试过程是否利用了测试任务或其答案来改系统。可声明测的是已知文档检索能力，再用未参与调试的任务家族检验变化；不要把公开常识题包装成完全陌生知识的泛化。
沿着这个回答继续深入
第 3 层团队已经看过保留题并据此改过 Prompt，如何恢复可信比较？
父问确定何种信息造成泄漏，子问处理已发生暴露后的补救。
参考解答
把这批题降为回归集，保留其防回退价值；另建未用于调试的测试分组，冻结评价协议后评估。记录旧题暴露时间与修改历史。不能通过改文件名把同样的问题重新叫作保留集，也不需要删除有价值的旧案例。
第 1 层多个合法答案如何标注？
真实任务不一定有唯一输出，需要明确标注对象。
参考解答
标注必需事实、允许动作、禁止状态以及若干合法解法，并记录专家分歧。参考答案是帮助判定的样例，不是措辞匹配模板。若两位标注者对同一约束仍有不同结论，应澄清任务或允许未知，不用投票掩盖题目含糊。
第 1 层线上失败直接入库有什么问题？
为补失败覆盖使用生产数据时，先保证合法性与复现性。
参考解答
原始失败可能含身份数据、密钥或第三方私有正文，也可能依赖已变化的服务状态。先确认使用许可和最小脱敏，保存有边界的环境替身、版本与预期事实；无法复现的记录保留为调查线索，不能直接变成确定真值。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
新用户任务比旧用户更短
改变的条件：线上输入分布改变，而原评测仍以长任务为主。
延伸问题：是否直接用线上成功率替换旧回归？
推导与参考解答
分别保留固定旧集与按新分布抽样的新集，报告各层成功、成本与风险。旧集保护原能力，新集评估现有服务对象。总分变化需说明层权重，防止用户构成改变被误读为算法提升。
保持不变的原理：评测结论依赖任务分布及明确抽样口径。
模型评测共享写入数据库
改变的条件：不同尝试会看到前一次创建的订单或报告。
延伸问题：为什么增加重复次数反而不可信？
推导与参考解答
因为环境不独立，后续尝试可能命中旧结果或受资源竞争影响。为每次运行使用隔离初态和唯一业务空间，清理后验证初态，再比较版本；不能把受污染运行算作独立成功。
保持不变的原理：任务与环境共同构成样本，残留状态不能隐藏。
易错点
- 只选成功案例
- 调 Prompt 时反复看保留集
- 验收标准随模型输出改变
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 知道需要成功、失败和拒答样本。
- 中高级信号
- 能定义环境初态、分组划分与标注复核。
- 资深信号
- 把任务分布、风险门槛和数据版本做成长期机制。
继续做进阶研究实验
让评测读取事件和实际效果
沿同一研究任务的实际检查点、事件和服务方回执，区分运行成功、结果契约和未评分的语义质量。
python3 cli.py memory-put
python3 cli.py submit
python3 cli.py run
python3 evaluate.py
python3 -m unittest discover -s . -p test_lab.py -v保留证据，逐条核对
- 从事件和检查点解释 passed 的各项依据。
- 分别指出 scope、引用、幂等效果和步骤预算的可信观测。
- semantic_support 与 model_quality 是 not_scored，不能把 passed 写成模型质量成绩。
默认使用确定性摘要函数和合成文档；评测真实运行轨迹与机械约束，没有验证真实模型的语义支持。
动手验证 按需完成 · 建议 15 分钟
为企业研究 Agent 设计 12 个评测样本配额，说明各类失败覆盖。
展开验收要求与检查点
- 包含权限与工具故障
- 每题有可判定验收
- 调试与保留集隔离
重点检查
- 按业务与风险分层抽样
- 任务初态和验收可复现
- 防止开发测试泄漏