信号一：通过结构
不看总体准确率，看通过结构：常见问题、难例与边界问题各自的通过比例。为什么：总体数字容易被常见问题拉高。怎么做：从业务中分层抽样，每层至少一组题，记录每层通过情况与错误类型，形成可复跑的题库。
信号二：溯源与拒答
回答能否给出来源、超范围问题能否拒答，决定了能不能被业务采信。怎么做：准备一批没有答案或超出范围的问题，观察模型是拒答还是编造；再抽查有答案的问题是否给对出处，两者都要写进测试记录。
信号三：更新周期
制度或工艺变更后，知识多久能进入系统并被正确引用，决定长期可用性。怎么测：选一条刚变更的规定，记录从变更到系统正确回答所用的天数，以及中间需要谁操作、是否需要重新训练，并留档备查。
自测怎么组织
由业务出题、专家定答案、技术跑测试，三方分工。为什么强调业务出题：厂商或技术方出题容易偏向模型强项。怎么做：题目盲评，评分人不知道答案来自哪个模型或配置；边界：自测结论只作试点依据。
边界：测试不等于上线
自测通过只说明在测试集上可用，上线还需要权限、日志、接管与运维机制。怎么做：把自测结论作为试点依据，试点期间继续收集错误案例，形成回归集后再扩大范围，否则评分容易失真，也不能替代试点。
适用与不适用
适合谁
- 正在选型、希望用自家数据验证的企业
- 需要对供应商说法做独立判断的技术团队
- 准备小范围试点、需要独立判断的业务部门
不适合谁
- 没有业务专家可参与定答案的团队
- 期望用一次测试替代上线验收的项目
典型场景
某建筑企业想验证行业模型能否读懂规范条文。技术团队从近两年的图纸审查意见中抽题，业务专家写标准答案，分常见、难例、超范围三层测试。结果显示常见问题表现稳定，难例错误集中在条款交叉引用，超范围问题拒答率偏低，据此缩小了试点范围。
可执行步骤
- 按常见、难例、边界三层抽取真实业务问题，每层各准备一组题目。
- 由业务专家写标准答案，技术方负责跑测、计时与错误分类记录，形成答案底稿。
- 分层记录通过情况与错误类型，不只看总分，便于定位短板与风险。
- 用超范围问题测试拒答表现，同时核对出处引用是否准确、可点开。
- 选一条刚变更的制度，实测从变更到系统正确回答所需的天数与操作人。
常见坑
- 题目由供应商提供，偏向模型强项，测试结论失真，选型被误导，后续很难纠正，付出的是预算与时间。
- 只看总体准确率，忽略难例与边界，上线后问题集中暴露，业务被迫回退，内部信任受损。
- 不测拒答，模型对超范围问题编造答案，业务部门不敢使用，价值无法兑现，验收也难通过。
- 测试通过就全面推广，权限与接管机制尚未建立，出问题难收场，影响面被放大，责任也不清。
自检与验收清单
- 题目是否分层抽取，且全部来自真实业务场景
- 标准答案是否由业务专家逐题确认并签字存档
- 评分是否盲评，并逐条记录错误类型与出现次数
- 拒答表现与出处引用是否单独测试、单独记录
- 知识更新周期是否有实测天数、操作人与记录
常见问题
没有专家怎么定标准答案？
可以先用历史工单里的处理结论作为参考答案，由业务负责人复核。若连可核对的结论都没有，说明该场景尚不具备评测条件，应先积累案例再谈选型，否则评测只是走过场。
测试要跑多少题？
首轮每个层级一组即可，重点是覆盖结构而非数量。难例与边界题最能暴露问题，应优先补足；测试集要版本化，模型或配置变化后复跑同一组题，结果才可比较。
供应商说自己有行业评测，能直接用吗？
可以作为参考，但需要看任务定义与样本构成是否与你的用法一致。最稳妥的是用自己的题目做一次盲测，两者结论差异大时以自测结果为准，并追问差异原因，数据比口径更有说服力。