收到一组 AI 推荐截图,很难直接评价服务效果。至少还缺三类信息:问题是怎样选的,没成功的回答有多少,截图中的介绍是否正确。
下面讨论一份验收记录可以包含什么。它是方案建议,不代表已实现的系统。
把平台与问题原文组成一个测试单元,提前约定重复次数、测试时段和判定方法。执行中若修改问题或检索条件,应留下记录,不把新旧结果直接并在一起。
重复测试只是减少依赖单次截图,并不自动保证统计代表性。问题如何选取,仍决定结果能说明多大范围。
建议分别记录品牌是否出现、是否有引用、关键事实是否正确。
例如,品牌出现在答案里,但产品参数错误,不宜只记成成功。网络失败或平台未返回回答,也应单独记状态,不当作一次普通的未提及。
若计算提及率,可将其定义为“提及品牌的有效回答数/有效回答总数”。有效回答的条件须预先确定,失败请求另报数量。事实准确率则应说明检查了哪些事实、如何处理无法判断的项目,避免不同项目使用相同名称却计算不同内容。
记录 | 作用 |
|---|---|
问题原文、平台和时间 | 判断测试条件是否一致 |
完整回答及原始截图 | 防止裁剪改变含义 |
引用页面与访问时间 | 检查引用内容是否支持结论 |
产品事实版本 | 确认用哪个版本判断准确性 |
判定人与意见 | 方便处理有争议的结果 |
涉及账户信息、客户资料时,应脱敏并控制访问,不为追溯而公开敏感信息。
如果模型说错了参数,先查引用页面,再查页面所依据的产品版本。纠正后保留复测记录,报告已解决和仍存在的问题。
不要把复测成功的截图覆盖原失败样本。前后记录都保留,才能知道改了哪里、在哪些测试中观察到变化。观察到改善,也不能仅凭时间先后就证明某一项动作产生了全部效果。
作者实际采用这套方案后,可补充一条脱敏的错误定位过程和复测记录。没有实际记录时,文章应继续以“验收设计”呈现。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。