评测证据：一百二十条用例、九条红队问题与一份证据包

证据不是「我们很重视」，而是一份别人能照着复跑的清单。

一、一句「你们怎么证明」，问住了他

2026 年 8 月，一家连锁客户在采购会上问：「你们换模型的时候，怎么证明回复质量没变差？」周闻手边只有一份三个月前的 50 条评测，还是他自己拿几个问题手测记下来的。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

他没有当场编答案。会后他把评测重做了一遍：扩到 120 条，固定评分口径，每次模型变更都跑一次，结果留档。三个月后，同一家客户再问，他直接发了四页 PDF。

评测的作用不是证明模型好，是证明变化可被看见。 没有基线，任何「没变差」都是感觉；有了基线，改版前后各跑一次，好坏都在表里。

二、一百二十条：按错的方式分，不按功能分

他把评测集按「容易怎么错」分成四类，而不是按功能分。

事实类最多，因为事实错最常见、也最容易判。政策类次之，因为它直接关联赔钱。语气类靠人判，所以要写清「什么算不合格」，否则每次评分都在漂。

拒答类只有 10 条，但最不能省。它测的是「不知道时说不知道」，而这恰恰是模型最不愿意做的事。

每条用例要带三样：输入、期望、判分理由。只有输入和期望，换个人评分就会得出不同结论；加上理由，评分才有共识。

评测集要能被别人复跑。 他给每条用例编号，跑完输出一张表：编号、通过与否、失败原因。客户拿到这张表，可以自己抽几条重跑。

评测集还要有版本。加一条、改一条、删一条都记版本号；否则半年后你无法说明「91.7% 是哪一版测出来的」。

用例不能全靠编。他的来源有三个：真实投诉改写、复核时被拒的回复、红队发现的越界；这三类都是「已经发生过」的错误，比凭空设想的场景更容易复现。

每次失败都要回填一条用例。模型改好了，这条用例仍留着，作为下一版的守门员；只有失败用例会不断累积，评测集才跟得上产品。

三、九条红队问题：不是找 bug，是找边界

评测测的是「常见情况下对不对」，红队测的是「被推着走时会不会越界」。他列了九条。

九条里，第 3、6 条最危险：它们不是「答得不好」，而是「答了不该答的」。这类问题一旦发生，就是数据泄露，不是体验问题。

第 2 条最容易被忽略。知识库里如果混进了带指令的网页文本，模型可能在检索时把它当命令执行；防它的办法不是改进提示，而是清洗入库内容。

红队不需要每次都跑满九条。他的节奏是每季度全跑一次，模型变更时只跑第 1、3、4、6 四条高相关的；全跑一次约 3 小时。

红队记录要写「试了什么、结果如何」，不写「已加固」。 前者可复核，后者只是一句自我评价。

红队问题要能转成评测用例。第 4 条「政策诱导」如果成功过一次，就把那段对话改写成固定用例，放进政策类；这样回归时会自动防住同一个手法。

四、证据包：五份文件，一个压缩包

客户要证据时，他发一个压缩包，里面五份文件。

五份加起来 9 页，够客户看完，也够他一个人维护。证据包不是越厚越好；厚到没人读，等于没交。

系统说明要写「不做什么」。只写能力，客户会默认你什么都能做；写清「不自动执行退款」「不回答法律问题」，边界才是边界。

评测报告要给失败项，不要只给通过率。110 ÷ 120 = 91.7% 这个数字背后有 10 条失败；把 10 条列出来，客户才知道风险在哪。

红队记录要带日期。同一份记录用两年，客户会怀疑你这两年没测过；每季度更新一次日期与结果，成本很低。

变更记录是五份里最容易被跳过的一份。14 次模型变更、3 次回归失败，说明变更不是无风险的；把失败也写进去，反而增加可信度。

复算：
评测集：120 = 事实 60 + 政策 30 + 语气 20 + 拒答 10
占比：60÷120=50.0%；30÷120=25.0%；20÷120=16.7%；10÷120=8.3%
通过率：110 ÷ 120 = 91.7% → 113 ÷ 120 = 94.2%
红队：9 条；季度全跑 1 次 ≈ 3 h
模型变更：14 次/年 × 4.4 h = 61.6 h/年
回归失败：3 ÷ 14 = 21.4%
证据包交付：3 家 × 4 h = 12 h/年

61.6 小时是评测的持续成本，不含建集。建集 40 小时是一次性的，之后每次改版只跑回归；两笔账要分开记，否则会误以为评测很贵。

五、行动清单与复算验收

• 把现有评测扩到至少 100 条，按错误类型分类。
• 每条用例写输入、期望与判分理由。
• 给评测集定版本号，改一条记一次。
• 列九条红队问题，标出最危险的三条。
• 每次模型变更跑一次回归，结果留档。
• 把五份文件做成一个证据包，随客户审查发出。
• 系统说明里写清「不做什么」。
• 每季度更新红队记录日期与结果。

验收标准：任取一次模型变更，都能拿出变更前后的评测结果与失败项。

前四条是「把评测做成可复跑」，后四条是「把结果变成证据」。如果只有一小时，先做第三条：没有版本号的评测，跑多少次都说不清是哪一版。

使用边界与实操验收

评测通过率高不等于安全。 120 条覆盖的是已知错误类型；新类型错误不会因为通过率 94.2% 就不发生。

红队不是渗透测试。 它验证的是产品边界，不是系统漏洞；真正的安全测试属于另一套方法。

证据包不是营销材料。 只写优点、不写失败项的材料，客户看一眼就会起疑；可信度来自「连失败都写」。

评测集要防污染。 用例本身可能包含真实用户对话，要脱敏后再入集；否则评测集成了第二份个人数据。

小样本的通过率不要过度解读。 120 条里差 1 条就是 0.8 个百分点；用它判断趋势可以，判断「是否达标」要谨慎。

本文的数字是教学假设。 120 条、91.7%、14 次变更都是演示口径，换成自己的产品要按实际重算。

关键参考与核验范围

• NIST 生成式 AI 风险画像 ：用于核对评测、红队与变更管理的风险条目。
• OWASP LLM Top 10 ：用于核对提示注入、敏感信息泄露与过度代理的问题分类。
• NIST AI 风险管理框架 ：用于核对测量、监测与文档化的通用流程。

以上链接于 2026-10-27 实测可公开访问；未核验版本、条款更新与适用范围。核验日期：2026-10-27。

范围上只讨论一人产品如何建评测集、做红队与交付证据，不评价任何评测方法的学术效度，也不提供法律意见。

系列导航

• 上一篇：人工复核：每月四百一十次、八点二小时与一条升级路径
• 下一篇：内容与版权：一次相似投诉、四十八小时下架与七个数据来源
• 回到目录：一个人的 AI 合规：六个功能、二十二项供应商条款与一次客户审查
• 相关阅读：一个人给产品加 AI：判据、成本、护栏与验收