ONTOCARE · ANKER HACKATHON基于本体论与自进化闭环的经营归因智能客服系统
双本体组织证据与规则，评测连接失败与改进，工单集合形成经营核查线索。
蒋恩晶获奖证书原图。点击图片可放大查看。
这是项目核心架构材料。点击图片，可全屏放大查看节点、连线与动作边界。
用户端推进服务，商家端沉淀证据、草稿与经营核查线索。
用户可以通过文字、故障图片或视频发起求助。系统先将图片和视频采样画面转化为可见现象、型号线索和错误码等文字证据，再结合用户描述进行检索。每轮对话同步更新「猜你想问」和快捷选项，减少反复打字。
面对「S1 Pro 不吸了」等模糊描述，系统结合品类、订单 SKU 与对话信息区分产品，展示带图片、订单号和购买日期的候选卡片。确认后限定知识范围，保留已尝试步骤继续推进排障，并根据情绪调整沟通方式。
回复附带来源引用和可折叠的处理摘要。遇到信息不足、产品冲突或高风险诉求时，系统提示需要补充的证据或人工复核，并整理当前上下文与处理记录，支持后续接管。
商家可以选择已有工单或粘贴邮件正文，系统结合产品、订单、物流、质保与知识生成回复草稿，支持语气调整、多版本生成及多语言翻译。引用随草稿保留，方便核对后使用。
聚合全量工单快照，展示产品工单占比、咨询场景、错误码及知识覆盖情况。点击图表或归因候选，即可查看关联工单、Excel 行号和原始邮件，帮助管理者识别值得优先核查的问题。
商家可以直接询问「这些工单有什么共同特征？」「下一步应该核查什么？」，助手读取本体关联与归因 Trace，生成附带证据链的分析建议。例如：
点击两个本体节点，查看对象关联与规则计算的职责。
业务规则散落在代码、流程和提示词中时，品类与政策变更的影响较难追踪。本项目尝试集中组织业务对象与规则，明确修改位置和回归范围。
采用 Service Ontology + Decision Ontology 分别组织业务实体与服务规则。当前通过 JSON 关系与 Python 规则实现，并以图示说明对象、证据和动作边界。
服务链路按处理顺序组织；设计扩展与当前实现分别注明。
用户发起求助时，支持文本或图片 / 视频输入。若是图片或视频，系统先调用多模态大模型 API，提取可见现象、型号线索、错误码及不确定项，转化为结构化文字描述。这段文字与用户原输入组合，作为精准的 Query 进入主链路。
预先定义业务实体与规则结构，将提供的产品、订单、工单和 SOP 映射为 Service Ontology 与 Decision Ontology，保留来源与行号。当前使用 JSON 数据和 Python 规则；图数据库与向量索引属于后续可评估的扩展。
先澄清产品身份，再按型号限定知识范围；错误码优先精确匹配，一般现象结合关键词与相关度匹配。语义向量召回属于后续设计方向。
将召回证据、用户问题和规则约束组织到生成上下文，调用配置的模型生成回复。服务端检查引用有效性及部分关键业务承诺；检查未通过时回退到资料答复或人工核查。
答案输出给用户后，界面提供点赞与点踩。一旦用户点踩，该条对话轨迹、检索来源、案件状态与 Decision Trace 会被立刻打包，自动打上 Bad Case 标签进入待排查队列。
针对捕获的 Bad Case，系统沿处理链路进行根因定位与靶向修复：
四步改进流程 · 修正后经人工审核与回归。
用 Persona 模拟不同性格买家，与客服 Agent 进行多轮对话，构造带对抗性的测试样例，并与脱敏业务资料分开标识。
结合确定性断言与 LLM-as-Judge 检查业务约束和语义质量；人工复核失败样例并定位原因，保留可回归的测试记录。
根据失败原因修正 FAQ、补充长尾策略或调整业务规则。改动经过人工审核与回归；自动向量降权属于设计方向。
修正后的知识必须通过运营人员人工审核，通过后再写回知识库与 Ontology，形成完整的系统自进化闭环。
按五个步骤组织知识召回；长尾策略与官方知识分别标识。
将订单、客诉工单、经销商和两份 Q&A 作为输入，保留来源文件、Sheet、原始行号及校验信息。知识条目依据发布状态和客户可见状态过滤，作为后续引用与核查的基础。
结合用户描述、SKU、订单及对话状态定位产品。同名或冲突信息未澄清时，先展示候选选项；确认后按产品 PN 限定检索范围，减少跨型号知识混用。
对错误码优先精确匹配；对一般现象使用关键词、同义词和相关度匹配，选取少量适用条目。条件明确的常见问题可命中带来源校验的固定 FAQ，减少重复生成。
常见路径不能覆盖时，检索长尾策略和 Bad Case 修复经验，结合当前证据交给模型组织建议。补充策略与官方产品知识分别标识；没有可靠匹配时继续补充信息或人工核查。
答复附带来源 ID，服务端检查引用有效性和部分业务一致性。新失败经人工审核修复后加入策略与回归测试。当前尚未使用向量检索；后续可在保持产品过滤与来源约束的前提下，评估语义召回、混合检索和重排。
图片 / 视频 → 结构化文字 → Query → 本体与业务规则。
用户上传故障图片或视频后，系统调用多模态大模型 API，提取可见现象、型号线索、错误码及不确定项，生成结构化文字描述。
将多模态提取的文字与用户原输入合并，作为新的 Query 注入业务检索链路，精准触发上述分层召回策略。
识别结果不直接作为认定产品身份或质保资格的唯一凭证，而是强制标记为「待核验」（PROBABLE / UNKNOWN），参与后续与订单 SKU 的交叉核对，确保多模态处理的安全严谨。
按失败环节定位修复方向，并经人工审核验证。
点击任一判断，聚焦对应修复路径。此图展示问题定位与修复的设计流程。
统计由程序计算，结论关联规则，建议可以下钻到原文。
支持产品核查：E25、E28 的两条工单包含 3212 错误码及相似拖布阻塞描述，建议按型号分别检查维护步骤和复现条件，再决定是否提交工程调查。
优化服务流程：针对「只收到配件」等拆单咨询，建议逐件展示包裹与物流记录，并核对客户实际收到的商品。
历史测试按任务集、版本与指标分别列示。
62 / 74 · 硬性断言
73 / 74 · 单轮复测
历史 P50 · 非平均值
产品与业务、系统工程、Agent算法与评测。
清华大学深圳国际研究生院
方案架构 / 产品设计 / 路演答辩浙江工业大学
Agent 后端开发南京大学
Agent 评测 / 前端页面核心功能、实现边界、测试记录和运行方式见公开仓库。
# OntoCare 项目说明 团队作品 · Anker 首届黑客松智能服务赛道冠军。 ## 功能 - 用户端：多模态线索、产品消歧、候选订单、连续排障和来源引用。 - 经营端：邮件草稿、工单可视化和候选归因，支持按规则 ID、Excel 行号与原文追溯。 - 当前采用 JSON 实体关系、Python 规则与型号限定检索；图数据库、向量平台及自动降权不作为已部署能力。 ## 历史测试 - 核心 74 项任务的单轮硬断言通过数：62/74 → 73/74，即 83.8% → 98.6%。 - 完整任务集单轮复测：109/110。 - 746 次非故障注入请求完整回答时延：P50 2.63 秒，P95 9.00 秒；不含浏览器耗时。 - 各项测试口径分开统计，不等同生产解决率或 SLA。 ## 资料 - [源码、运行方式与完整评测](https://github.com/jiangenjing/anker-OntoCare) - [在线原型](https://web-production-195cd.up.railway.app/) - [演示视频](https://jiangenjing.github.io/anker-OntoCare/docs/视频演示.html) - [项目讲解与技术说明](https://jiangenjing.github.io/anker-OntoCare/docs/路演演讲稿-现场原文.html) 真实邮件发送、退款换货和生产系统执行需要外部接口、授权与审批流程。