智能服务赛道 · OntoCare 本体队

OntoCare

基于本体论与自进化闭环的

经营归因智能客服系统

蒋恩晶 · 叶品驿 · 雷景喻

队长联系：1391648196@qq.com

联系电话：18042474095

01

01 / 我们解决什么问题

售后服务的三个断点

产品越多、规则越复杂，客服越需要一套统一的业务依据。

01

找不准对象

同叫 S1 Pro，可能是两类产品

跨型号知识混用，容易答非所问

02

改不完失败

一次 Bad Case，常靠一次性修补

相似问题再出现，经验难以复用

03

看不见全局

工单逐件处理，问题分散在邮件里

缺少从客诉到经营行动的证据链

我们的回应：双本体约束 → 评测改进闭环 → 可追溯经营归因

02

亮点一 · 本体路线与业务敏捷

业务语义清晰，规则可追溯

Service Ontology 描述业务对象与关系；Decision Ontology 承载 SOP 与动作边界。

传统路线：规则散落代码、API 与 Prompt，业务变化需多处同步。

Service 关联产品 / 订单 / 证据；Decision 表达 SOP 与动作边界。

已建模规则可集中维护；新增接口、产品知识仍需开发与核验。

03

亮点二 · 红蓝对抗与 Bad Case 改进

让失败，推动下一次改进

Persona 对抗发现问题，Judge 定位原因，人工审核修复后回归。

01

红蓝对抗

8 类 Persona · 多轮对抗

→

02

Judge 评估

硬规则 + LLM Judge

→

03

靶向修正

修知识 / 长尾 / 决策规则

→

04

人工审核与回归

人工复核 · 回归后更新

83.8%

历史首轮核心：62 / 74

98.6%

修复后单次：73 / 74

109/110

在线 + 离线复测：各一轮

不同批次硬断言通过率，不等于线上解决率；pass⁸ 未测，保留 U060 失败。

04

亮点三 · 从单点工单到经营复盘

把工单集合变成可核查行动

商家视角：工单聚合 → 模式识别 → 规则匹配 → 建议与溯源。

63

条工单快照

全量样本分析，不代表实时趋势

例一｜X10 Pro：14 条，占样本 22.2%

回看原文与已尝试步骤，安排高频问题核查。

例二｜3212：两条相似故障候选

E25 / E28；源表第 19、28 行。

按型号复现核查，暂不认定共因。

建议可追溯到源行与规则，帮助团队安排下一步复盘。

05

05 / 技术架构 · 当前 Demo

先定范围，再召回证据

离线构建统一业务语义；在线执行受约束检索；失败回流推动持续改进。

当前：Python / Flask + 原生 HTML / JS + JSON / Markdown；模型通过 API 接入。

升级方向：Embedding + 向量检索 / 混合重排；HyperAuto 为集成方案参考，尚未接入。

06

OntoCare · 让售后服务积累为经营能力

回答有据

决策有界 · 改进可验

蒋恩晶｜清华大学 · 方案架构 / 产品 / 路演

叶品驿｜浙江工业大学 · Agent 后端

雷景喻｜南京大学 · Agent 评测 / 前端

当前为演示系统；资金与外部发送等真实动作需审批集成。

07