在制造业知识问答中,答案附带来源,能够帮助使用者核对依据。但“有引用”只是检查的起点。
假设维修人员查询某台设备的报警处理方法,系统找到了手册,也准确引用了其中的操作步骤。然而,这份手册适用于另一种设备配置,当前设备并不满足操作条件。
这时,引用是真实的,回答却未必适用。
因此,验收AI知识库时,需要分别检查三个问题:资料能否找到、引用是否支持结论、结论是否适用于当前业务条件。
以下以设备维修资料查询为例,介绍一种可操作的测试方法。文中设备和问题均为假设示例,不代表实际项目结果。
只用“对”或“不对”评价答案,往往难以定位问题。可以把一次问答拆成以下检查项:
检查项 | 需要回答的问题 |
|---|---|
资料相关性 | 找到的资料是否对应当前问题? |
版本有效性 | 文件是否现行有效,或适用于当前设备? |
条件完整性 | 型号、配置、工况等必要条件是否齐全? |
引用支持度 | 引用原文是否确实支持回答中的结论? |
权限符合性 | 当前用户是否有权获取这些内容? |
不确定性处理 | 依据不足时,是否追问或提示转人工? |
这些检查项对应不同的故障原因。例如,找到旧版资料可能与版本管理有关;引用正确但结论扩大,可能发生在回答生成环节。两者需要采取不同的修正方法。
假设测试问题是:
“设备A出现E17报警,应该怎么处理?”
准备测试时,应先让业务人员确认:仅凭“设备A”和“E17”,是否足以确定处理方法?
如果同一系列设备存在不同控制器、配置或手册版本,预期回答就不应直接给出操作步骤,而应先确认必要信息。
可以据此设计两条测试:
测试一:条件不完整
输入只有设备系列和报警代码。
检查系统是否询问具体型号、配置或其他必要条件。
测试二:条件完整
补充型号、配置和适用版本。
检查系统是否找到对应资料,并说明建议成立的条件。
这组测试关注的是系统能否识别信息缺口,而不只是能否生成答案。
知识库中保留历史文件,有助于查询旧设备和追溯记录,但也可能造成版本混用。
测试时,可以准备两份存在明确差异的假设文档,例如:
分别使用配置X、配置Y和未提供配置的提问,观察系统是否:
需要注意,发布日期较新的文件不一定适用于所有旧设备。版本选择应结合适用范围,不能只按上传时间排序。
引用检查不能只看链接是否可打开,还要核对回答中的关键判断是否有依据。
例如,原文写的是:
“出现该报警时,检查连接状态。”
如果回答扩展成“该报警一定由连接松动引起,更换部件即可恢复”,就超出了这段原文所能支持的范围。
验收时可以逐项核对:
对于多个来源组合形成的回答,还应检查不同资料是否适用于同一设备和条件。
权限测试应使用不同角色的账号,对同一个问题进行提问。
例如,准备一份仅允许维修团队访问的内部记录,再使用有权限和无权限的账号分别查询。
检查范围不只是文件能否打开,还包括:
测试应在授权环境中使用合适的样本。预期结果应与企业既有访问规则保持一致。
知识库不可能覆盖所有故障。测试集应保留一部分资料没有答案的问题。
这类问题的合格表现,可以是:
不应把所有未给出完整建议的回答都判为失败。相反,没有依据却给出确定步骤,才需要重点排查。
测试记录应足够具体,使修改前后的结果可以比较。
字段 | 记录内容 |
|---|---|
问题编号 | 便于追踪同一测试 |
提问及条件 | 型号、配置、版本等 |
测试账号 | 对应角色和权限 |
预期结果 | 应引用什么、应追问什么或应拒绝返回什么 |
实际回答 | 保留回答及引用 |
问题分类 | 版本、检索、权限、条件缺失等 |
修正与复测 | 采取的调整及复测结果 |
如果需要汇总指标,可以分别统计资料命中、引用支持、权限符合和信息不足时的处理情况。每项统计都应说明样本范围与判断标准,避免只用一个笼统的“准确率”概括所有表现。
制造业AI知识库的验收,需要从“能找到资料”进一步走向“能在正确条件下使用资料”。
在小范围试点中,先验证版本、适用条件、引用和权限,再逐步扩展场景,有助于暴露具体问题,也便于确定后续修正方向。
对于涉及设备安全和现场操作的回答,仍应由具备相应职责的人员依据现行规程确认。知识助手可以辅助资料查询与整理,现场操作责任和审批流程需要保持明确。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。