OntoCare · 路演演讲稿（现场原文）

大家好，我介绍的是 OntoCare：基于双本体与人工审核改进闭环的智能客服原型，支持售后排障与工单集合分析。

项目提供用户端与经营端两个视角，可通过在线系统体验核心服务流程。

用户端支持图片与视频线索提取、产品消歧、候选订单和带引用的回复。历史 746 次非故障注入请求的完整回答时延为 P50 2.63 秒、P95 9.00 秒，测试不含浏览器耗时。

经营端提供邮件辅助草稿、工单可视化看板和候选归因建议；真实邮件发送、退款换货等业务动作需要外部系统接入。

我们从知识组织、业务规则和评测改进三个方面设计服务链路。

① 双本体建模：Service Ontology 组织产品、订单与知识证据，Decision Ontology 组织业务条件和动作边界。当前主链路通过 JSON 实体关系、Python 规则与型号限定检索实现，便于定位知识和规则的修改位置。

② Bad Case 改进闭环：用 Persona 多轮对抗、确定性断言和 LLM-as-Judge 发现失败，再结合证据分析检索、会话状态、规则与表达问题。

• 发现问题：通过对抗样例、用户反馈和评测结果收集 Bad Case。
• 评估与归因：硬断言检查业务约束，LLM-as-Judge 补充语义判断，人工复核失败原因。
• 针对性修复：根据问题补充长尾知识、修正 FAQ、更新规则或代码；修改后进入回归测试。

规则维护：业务条件缺失或不一致时，修订 Decision Ontology 的对应规则并检查影响范围。

• 人工审核与回归：验证修复效果后再更新知识或规则，保留变更与测试记录。

历史核心 74 项任务的单轮硬断言通过率由 83.8%（62/74）提升至修复复测的 98.6%（73/74）；完整任务集单轮复测通过 109/110 项。以上为不同测试集的历史记录，不等于生产问题解决率。

③ 经营归因 Agent：面向 63 条脱敏工单快照，按 RC1–RC4 候选规则组织核查建议，通过 ReadOntology、ReadTrace 连接业务实体、规则 ID、源表行号和工单原文，支持证据追溯。

抗幻觉采用分层约束：先消歧并限定检索范围，再结合证据与规则组织回复；服务端检查关键结论、引用及动作边界。证据不足时追问或转人工，不作无依据承诺。