售后 Agent 差的不是回答：腾讯云 ADP 把准确率从约 60% 收到 93% 以上

售后 Agent 差的不是回答：腾讯云 ADP 把准确率从约 60% 收到 93% 以上

腾讯云 ADP（Agent Development Platform，腾讯云面向企业的智能体开发平台）团队在 2026 年 8 月 10 日写了一份医疗器械售后助手的生产化记录。文中的 M 项目先做售后客服，接入约 86 万份知识，用标签、多路检索和元数据把助手送进工单系统。团队给出的业务结果是：客户年工单拦截率 60% 以上，并以此为入口，把单一场景扩展到内部探索的 300 多个智能体。对评测来说，这篇的价值不在口号，而在它把「能不能上线」拆成了可回归的准确率、引用、拒答、串型和闭环时限。

为什么 PoC 过了还不敢给客户用

文章把企业级 Agent 的门槛放在「用起来」，而不是 Demo 能答。PoC 阶段常见判断是「差不多能用了」。到现场之后，问题变成四件具体的事：准确率只有 60% 左右；型号容易串；答案缺少引用；边界问题不会拒答，业务侧认为答非所问。项目组因此不敢直接拿去服务客户。作者把这种现象叫做从「深度落地」变成「深度落灰」。

医疗器械售后被写成深水区，原因同时有装机规模、设备安全与服务合规、海量文档、相似型号、频繁改版，以及依赖专家经验的故障诊断。M 项目的产品覆盖全球 190 多个国家，服务国内近 11 万家医疗机构、99% 以上的三甲医院。要推进给 AI 的文档大约 400G，覆盖 500 多个机型、10 余种文件格式。日常答复原先高度依赖原厂研发，每个产线都要有人专门答用户问题。

真实难点被作者从「回答」改写成「在海量知识里找到正确、无误、可追溯的答案」。落地时列出五个难题，后面又单列幻觉：

1. 知识庞杂，检索耗时。 服务手册、技术通知、软件包、案例库、培训资料散在多个平台，口径不一。传统关键词检索往往返回 160 多条候选，一线仍要人工判断，本可自助解决的问题因此转人工。
2. 型号太近。 产品型号和工艺代号是长编码，差异可能只在少数字符。通用模型怎么切分都不稳，极易混淆。
3. 代号和型号是多对多。 不是一对多。一个代号对应多个型号，一个型号也对应多个代号。用代号提问时，型号很容易配错。
4. 版本必须是最新有效版本。 按过期资料维修，可能造成操作错误或合规风险。
5. 权限和语种同时存在。 不同角色能检索和回答的知识范围不同。海外查询可能是葡萄牙语、西班牙语、英语或中文。

此外，幻觉不可接受。助手既对内也对客，答错会直接影响服务质量、设备安全和客户信任。

一期怎么做：五段链路，而不是一次调提示词

FDE（Forward Deployed Engineer，驻场把产品推进到客户生产环境的交付角色）在文中被要求丢掉「每个项目重写一套」的做法。范围从概念验证拉到生产运行，同时看模型效果、知识工程、运营闭环、交付工具和反哺产品。五个环节按顺序是：知识库梳理清洗、知识对接、ADP 检索能力、技术调优、上线治理。

先把两类库洗成可过滤的标签

第一类是技术资料库：服务手册、招标版物料清单、软件包、用户手册、推荐库存清单、技术通知、历史技术通知、视频、案例库、培训资料。规模大、格式多。第二类是诊断知识库：诊断处理方案和套餐类型，结构更清楚，有树状分类和字段。

清洗、结构统一、标签化、去重、命名规范之后进入 ADP 统一知识库。文中给出的库规模是：技术信息服务主库超过 2 万份，综合知识库单库超过 1 万份，服务手册库超过 80 万份，并按产品线、机型和问题分类建多级检索维度。作者明确说，每次提问都在 86 万份材料里轮询，做不到秒级应答。第一步是缩小范围，做结构化检索。

标签跟着资料走，避免跨产品线串线

知识来自 PLM 数字工程、Portal 发布、手工上传，以及 ECR 和用服流程。ADP 知识库被当作检索平台，统一标签，让新增、变更和流程产物持续进检索，而不是上线时导一次。进库前传递的标签包括产品线、机型大类、型号、工艺代号、市场定位，用来挡住不同产品范围的资料互相干扰。作者把标签传递写成型号密集型行业里「会不会跨产品线、跨机型串线」的直接条件。

用元数据把型号从模糊匹配改成可控链路

测试里，已有 badcase 的 10% 以上来自型号太近：不同产品线或机型串线，相似型号的切片被错误召回。缩小范围用的是用户交互和隐藏参数，包括问题类别、机器型号、产品线、工艺大类、工艺代号、市场定位（国内或海外）。这组条件同时缩检索耗时和型号混淆。

产品侧再从 query 抽关键词，把切片所属文档的标签、产品编码、分类、文档标题等元数据放进召回和排序。时间戳也作为元数据参与排序，用来处理文档新旧，也就是客户原先被时效性卡住的那一类错误。整条链路被写成四步：实体抽取、元数据匹配、范围过滤、结果精排。型号识别不再只靠模型「看起来像」。

多路召回、拒答通路和还在规划的学习闭环

资料有十几种文档类型，单路检索盖不住。ADP 把问题分到向量召回、问答召回、拒答召回、图片召回、文本跨模态召回和 Text2SQL。合并顺序是 Merge、RRF 融合、Rerank、合并排序、去重、小找大合并、大 TopN 向量补召，最后给出带来源片段的回复。拒答召回被单独列成一路，对应前面「边界问题不会拒答」的失败模式。

Agentic RAG 已与工作流结合：在原来的 RAG 上加 Agent 链式推理，从非结构化库按结构拉取，再做交叉验证和决策。文中只说与前期方案融合后「检索效果相比之前有明显提升」，没有给出这一步单独的百分点。

定向 badcase 仍然要做。ADP 沉淀了运营排查和 badcase 分析工具，并规划上线 ALHF（Agent Learning from Human Feedback，让应用从人工反馈里学习并生效）。后文产品沉淀里写作 AHLF，指的是同一类闭环，不是另一套已公开的独立基准。

上线之后才开始评：灰度、归因、三天闭环

售后助手从上线当天才进入运营。小范围灰度里，每次对话的点赞、点踩、转人工、引用命中和问题闭环都进入客户与 ADP FDE 的 badcase 链路。迭代顺序固定为五步：问题收集、针对性归因、模型与 RAG 精调、回归验证、语料沉淀。归因后再分流：

• 知识缺失：补资料和标准答案。
• 切片或召回：改切片、关键词、RRF、Rerank 和图谱权重。
• 型号和业务规则：补元数据和映射。
• 表达与边界：改提示词、拒答清单和人工接管策略。

客户项目组与业务一起看 badcase。高频 badcase 纳入 3 天闭环考核，跟踪到验证通过。每一轮留下的不是口头结论，而是标准答案、测试集、知识标签、提示词模板、流程规则和治理方法，给后面的场景复用。

线上数字，以及这些数字不能被读成什么

接入范围包括外部服务小程序、工单系统、Web 和内部工作台，用户从售后工程师、客服、渠道、运维，到代理商和医院客户。

准确率按三个时点给出：早期自建版本约 60%，一轮上线约 83%，运行调优后 93% 以上。检索从人工查找的 10 到 30 分钟缩到秒级。单场景会话 3 万次以上每月，其中约 80% 与工单系统相关。AI 处理的工单占全部工单的 60%。作者据此说，先不把团队重组算进去，助手至少省下原工单投入 60% 的人力。导语里的「年 60%+ 工单拦截率」和后文的「AI 工单占全工单 60%」是两句并列的自述，文章没有给出拦截率的计算公式，不能把它们自动当成同一个指标。

产线原先专人答售后，交付后专家人力被释放；原先接不住专业咨询的外部人员和新员工，可以按助手做标准化服务。业务把点赞、点踩和闭环率放进考核，参与本身又被写成数据质量和可用性的输入。

扩展路径是：营销侧主动来学，自己整合培训、产品说明、售前和海报，启动二期营销服务助手。用户服务侧从这一个助手扩到 ITR、LTC、PLM 和数据分析，内部创新探索达到 300 多个智能体，并用内部创新比赛往更多场景推。300 多个是探索数量，不是 300 个都达到 93% 准确率的生产助手。

反哺到产品和交付，以及本文的限制

产品侧沉淀的是元数据检索增强、复杂实体关系映射、时效性检索、AHLF 闭环优化和检索配置。交付侧露出的工具需求包括知识清洗、调优、切分、评测、测试集管理、badcase 运营和建库运营。作者认为这些工具能降低后续同类项目的人力，但没有给复制项目的工期或人力对照数。

长期机制被写成：每次问题、反馈、转人工和工单闭环都回到知识和产品优化；成熟场景再给下一个场景提供知识框架、流程组件和治理标准。行业外推覆盖消费医疗、医药流通、工业设备、智能终端和冷链物流，条件是产品复杂、型号多、知识量大、答错成本高，且售后依赖检索和专家经验。这是场景判断，不是这些行业已经复测出同样的 93%。

读这篇时需要守住的限制：60%、83%、93% 以上、10 到 30 分钟、秒级、3 万次以上每月、80%、60% 工单占比和 60% 人力，都是平台方转述的项目自述，文中没有第三方复测、没有准确率的标注规范和分母，也没有公开测试集。Agentic RAG 只有「明显提升」，没有单独数字。ALHF 在落地小节仍是「规划上线」，不能写成已经完全自动进化。标题里的「100 步」是修辞，正文没有列出 100 个步骤。

出处：腾讯，腾讯云 ADP 团队，你以为 Agent 能干活了？其实差了 100 步：医疗器械售后 Agent 生产化实战，2026-08-10，https://adp.tencent.com/zh/blog/adp-fde-medical-device-after-sales-agent