生产级AI客服落地：从知识整理、检索优化到成本控制的七层实战

作者把两年做 AI 客服的实践重新整理了一遍：空气小猪最初的目标，是把创始人从每天两三个小时的人工客服里释放出来，他们先自己做了半年客服、攒下真实语料，再让 AI 上场，一路讲到知识整理、回答兜底与成本优化的七层能力。

之前我们连续写过几篇 AI 客服的文章，有的在讲 RAG 怎么做，有的在讲 AI 如何接管业务，还有一篇讲了个不太好解释的问题：AI 已经承接了接近一半的流量，综合成本居然还是比人工高。

这些文章放在一起，其实才能比较完整地说明，一个生产级 AI 客服到底是怎么做出来的、又要如何做优化。

更重要的是：我们可以直观感受到，在最适应于 AI 的客服场景，AI 到底是个什么样的身位、又是如何一步步发展的，这对于其他场景的借鉴意义很大。

我们自己的创业产品空气小猪，目标很简单：把创始人从每天两三个小时的人工客服里释放出来；但另外一个电商陪跑项目，从最初就是带着替代人工的目标出发的，AI 要查订单、改状态、发起售后，要真正接走原来由客服完成的工作。

这两种客服，看起来都是用户问一句，AI 回一句，背后的工作量差距却非常大。

所以今天把这些实践重新整理一下，从简单知识问答开始，一直讲到业务接管、成本和持续迭代。

一、什么时候做 AI 客服

空气小猪是一款基于社交的语言学习 App。从上线之后，客服一直是我们自己在做，每天消耗两三个小时，这种状态持续了半年多。

大家要注意，所有的产品上线，一定都是自己去做客服，你需要最直观去感受：用户哪里用得不爽，卡点在哪里，为什么会产生这些疑问。这些都是产品迭代的重要材料。

期间我们由于太累了，也把客服工作交给过研发人员、也找过兼职客服，但效果并不好。一方面是投入程度不够，另一方面是对产品理念和定位理解不深，经常没办法把用户的问题解释清楚、更多是当成日常工作在打发。

而空气小猪的产品理念和传统语言学习软件有些不一样。很多用户带着背单词、刷题、上课的预期进来，但我们希望重用真实聊天内容，帮他建立一个贴近日常生活的外语环境。客服要反复解释的，除了功能怎么用，还有产品为什么这样设计。

紧接着规律开始出现，时间一长，问题开始大量重复：产品定位、账号登录、翻译、推送、加好友、播客模式，高频问题基本就这些。每天继续人工回答，确实很费时间，也不可持续，于是 AI 开始出场了。

到这里，很多同学会好奇：你们自己就是做 AI 的，为什么不一开始就上 AI 客服？

原因很简单，我们也需要积累原始数据啊。

半年多的真实对话，给我们留下了一批很好的语料。里面有用户的真实问法，也有我们过去的解释方式，等基础问题开始不断重复，构建 AI 客服的时机也就到了。

已有成熟知识和流程的公司，当然没必要等半年，但数据和答案，总要有人先确认。

至于 AI 客服的能力边界，我们给第一版划定的范围也比较简单：产品问题基于知识回答，故障和建议收集后记录，用户闲聊时自然回应，回答不了的问题留下来，后面补知识。

同时要明确哪些事不能做。不能承诺某个功能一定上线，不能承诺用了产品一定达到什么学习效果，也不能在没有依据的情况下强行回答。

AI 客服最致命的，就是一本正经地胡说八道。 用户不会关心这是模型幻觉还是知识库没召回，他只会认为是你们产品给了错误的信息。

所以我们一开始就把原则定好了：宁可少答，也不要乱答。信息没收集够就继续问，超出能力就交给人。

二、知识整理，没法偷懒

很多同学做知识库，最关心的是模型、平台、向量数据库。但真正做过以后就会知道，最耗精力的部分，一定是把知识整理好。

我们之前反复说：数据才是 AI 客服的灵魂。

如果产品知识不全，答案本身就有问题，你在工程上做再多优化，也没办法凭空变出正确答案。

空气小猪的知识来源有两部分：一部分是人工整理的产品知识，包括产品定位、核心理念、功能说明、使用方式、价格、数据安全，还有哪些功能明确不做；另一部分就是历史客服记录。

人工知识比较系统，但不一定覆盖用户真实的问法；客服记录更贴近实际，但内容很散，还会有重复、过期和针对某个用户的特殊处理。两部分需要合起来整理。

当时我们按会话导出数据，每十个会话作为一批，借助 WorkBuddy/Coze 工作流提取有效问答，写入飞书多维表格，再进行去重、合并和人工校验。

但真正费时间的是后面的确认，同一个问题，历史上可能有不同答案；某个功能以前不支持，现在已经上线；客服当时为了解决一个特殊问题，给过一次例外处理，这些都不能不加判断地变成正式知识。

所以，最后一定需要懂产品的人来看，他要知道哪些说法还有效，哪些必须改，哪些只适用于特定情况。能保留来源、适用范围和更新时间，后面处理冲突也会容易很多。

整理知识时，还要提前考虑分块。

我们用 Markdown 按标题组织知识，再根据层级拆成知识块。这里最重要的是，每一块都要能够独立理解。如果答案只有“支持，操作和上面一样”，拆出来以后肯定没法用；如果只写“这个功能暂不支持”，却不知道是哪个功能、哪个版本，也一样有问题。

这里不同团队都会有很多相似的问题，比如一些大聪明为了提高召回率，让模型把一个问题泛化成多个问法，再把“问题一加答案”、“问题二加答案”、“问题三加答案”分别存进去。

看起来覆盖的问法更多了，应该更容易命中吧？

结果用户一问，召回的前几条全是同一个答案，只是问题写得不一样，而且得分还挺高。其他可能有用的知识，反而被这些重复内容挤掉了。

这种情况，如果只看有没有命中，会觉得效果不错；真正把召回结果打开看，才知道知识根本没有找全。

所以，多个问法可以保留，但最好关联到同一条知识。召回后按知识 ID 去重，别让同一份答案反复占位置。

技术实现上，我们当时采用 Python、FastAPI、MySQL 和 FAISS，向量模型用的是千问的 text-embedding-v4。MySQL 保存知识原文、分类、状态和审核信息，FAISS 负责向量检索，两边通过 ID 关联。

知识先入业务数据库，再异步向量化、写入索引，成功后更新状态。真正检索时，先找到向量对应的 ID，再回数据库取原文。原文和检索索引分开，后续替换检索引擎也方便一些。

知识更新后，索引也要跟着更新，否则后台看着改了，AI 用的还是旧答案。

三、有知识，AI 还是错

知识整理完，客服也不会自动变准确。用户说的这句话怎么理解，应该走哪个流程，拿哪些知识来回答，里面依然有很多问题。

我们最初只分产品咨询和闲聊，后来发现不够。用户还会反馈打不开、点不动、收不到通知，或者希望增加某个功能。这些问题不能回一句“谢谢反馈”就结束，需要收集信息、分类记录，交给产品和技术继续处理。

于是一级意图扩展成三类：产品咨询、用户反馈、闲聊。

咨询走知识检索，反馈走信息收集和登记，闲聊保持自然互动。语言学习产品可以适当保留陪伴感，其他严肃业务有没有必要开放闲聊，要看自己的场景。

不过，只给模型三个标签是不够的。我们从产品本身和用户视角分别梳理，再融合出二级分类：产品理念、价格、登录、消息推送、翻译、词卡、播客、故障、功能建议等，给一级意图补上明确的判断标准。

比如“怎样关闭通知”属于使用咨询，“为什么一直收不到通知”就可能是故障反馈。两句话都提到了通知，但后续流程不一样。

还有一个问题是指代。

用户先问“空气小猪是干什么的”，接着问“它怎么用”。直接拿第二句话去检索，很容易找不到，真正要检索的应该是“空气小猪怎么使用”。

所以我们在意图识别之前，增加了指代消解，结合历史对话，把“它”、“这个”、“那个”还原成具体对象。如果前面出现过多个对象，实在判断不出来，就继续问，别替用户猜。

这又涉及上下文应该带多少的问题。

太少，早一点的关键信息丢了；太多，速度慢、Token 消耗大，还会混进一堆无关内容。我们采用的办法是，保留最近几条原始消息，更早的对话异步压缩成摘要，只留下事实、诉求和未解决的问题。

但订单状态、支付结果这些信息，不能只相信摘要，办理业务时还是要查系统。用户上次说没收到退款，不代表现在依然没有到账。

检索不能只靠向量

向量检索擅长找语义相近的内容，比如“对英语有没有帮助”和“能不能提升英语能力”，表达不同，意思相近。

但用户明确问 Memo 词卡、播客模式时，功能名就很重要。只靠语义相近，可能把另一个功能的说明找出来。所以我们加入 BM25，补充关键词匹配，再把两路结果合起来使用。

在此基础上，我们还做过问题泛化，把一句口语化提问改写成几条适合检索的问题，分别查找知识。

不过，路数一多，重复和弱相关内容也会增加。因此还要融合、去重和重排。RRF 主要根据不同列表里的排名融合结果，Reranker 再对候选内容做更细的相关性排序，最后挑出真正需要的知识。

这些组件都有各自的用处，但不是每个问题都需要走一遍。一个很明确的功能查询，直接检索就能回答，没必要先让模型扩写五条问题。步骤增加了，效果不一定更好，调用费用却会实实在在增加。

这里还要补充一下聊一下“置信度”。向量相似度、重排分数和模型自己输出的 confidence，含义并不一样，都不能直接当作答案正确的概率。我们早期使用过 0.5 的阈值，那只是当时的试验设置，换个模型和知识库就需要重新验证。

生成回答要有兜底

知识召回以后，我们会让模型再判断一次：这些资料到底够不够回答用户的问题？

当时在输出里加了一个 useful 字段。知识足够，就正常回答；知识不足，就返回 false，同时把问题送进待处理池，后续补知识。

模型的判断仍然可能出错，但至少回答不了的问题被记录下来了，后面可以复盘。

故障和建议则有另一套处理逻辑。用户建议的功能如果已经存在，就告诉他怎么用；如果不存在，再看是否符合产品方向，是否属于明确不做的范围。可以评估的就登记，但不承诺具体上线时间。

故障也一样，先收集清楚，再创建记录。只有后台确实写入成功，才能告诉用户“已经记录并反馈”，不能只在回复里把这个动作做完了。

四、回答问题 → 完整 SOP

接下来看另一个电商项目。

甲方原本在上海、成都和武汉都有客服团队。上海成本最高，一张工单的综合处理成本达到数十元，一名客服一天大约处理二三十单。团队已经优化过话术、排班和客服系统，人的操作速度基本到了上限。

成都和武汉原本合计有数十名客服，随着业务调整和自动化推进，常驻的一线人员缩减到了个位数。公司希望继续收缩高成本团队，保留一支兜底队伍，让 AI 承接标准化服务。

所以这个项目，从最初就是带着减少人工、甚至替代人工的目标出发的。压力也很直接，不能只做一个展示效果不错的智能问答。

我们期待用户问的是“退货期是多久”，真实用户却会说：“我上周买的商品已经拆封，用了两次感觉有问题，现在还能不能退？”

这时候，光找到退货政策远远不够。

系统要找到具体订单，确认签收时间、商品类别和拆封情况，判断是质量问题还是主观不满意，再根据规则决定继续询问、申请售后，还是转人工。最后还要把动作真正写进售后系统。

一个熟练客服看似只回复了几句话，背后已经完成了信息理解、数据查询、规则判断和系统操作，所以：

要蒸馏这个客服，光上传他过去的聊天记录是不够的。我们还得知道，他为什么查这些信息，为什么这样判断，以及什么时候会把问题交给别人

这也是各种 AI 小工具继续往下发展时，一定会遇到的问题。

AI 帮客服查到了资料，生成了回复，然后呢？客服还是要看一遍，还是要判断，还是要打开后台、填写信息、点击提交。每笔业务依旧要等人操作，整条流程的人效就很难发生根本变化。

所以后续要做的，是把完整 SOP 导入系统，让前后步骤可以接起来。

在这种场景下，我们更倾向于先采用 Workflow。哪些步骤必须做，缺什么信息继续问，满足什么规则才能执行，失败以后去哪里，都由系统显式控制。

模型负责理解用户的复杂表达，程序负责已经明确的条件校验，工具负责查询和执行。不是所有节点都需要让大模型重新思考一遍。

为什么没有直接用 Agent

很多同学可能在疑惑：为什么不用 Agent 模式，现在通用智能体已经这么强了？这里可能是第二个反认知的点：

ReAct 类 Agent 可以根据当前结果，自己判断下一步调用什么工具。这种自主性当然有价值，但路径已经明确的高频客服流程，每次再规划一遍，就会增加调用、延迟和不确定性

也就是，在生产场景下，其实 Agent 的实际使用场景是不太多的。我们会更关心稳定、成本和可控性。业务不需要的自主性，没必要为了追求架构先进硬加上去。真遇到处理路径无法提前确定的任务，再引入有边界的 Agent，也完全来得及。

同样，选择平台还是自己写代码，也要看实际需要。

空气小猪当时考虑过 Dify 等框架，最后选择工程化开发，主要是希望把检索、排序、上下文、日志和系统对接握在自己手里。在 AI Coding 的帮助下，这件事的实现难度也下降了不少。

但自己写代码，并不代表后续没有维护成本。平台能满足就用平台，需要深度定制再写代码，我们用 Coze 清洗会话、自己维护在线客服，就是这样的分工。

五、蜜月期 → AI 独大

电商项目刚启动时，我们也没有直接让 AI 处理售后，先做常见咨询和查询，把答案推荐给客服，由客服选择使用。之后才从 1% 的真实流量开始，小心地尝试直接回复。

这个阶段比较容易看到效果。过去客服要在很多条政策里找答案，现在 AI 几秒钟就能给出建议，客服反馈也不错。

但只要问题涉及具体订单、需要修改信息，或者出现规则之外的情况，系统就开始暴露不足。所以我们保留了人工审核，AI 的回复和处理建议先给客服看，确认后再发送或执行。

这就是典型的 Copilot 模式，也是人与 AI 的蜜月期。

人工每一次接受、修改和驳回，都给我们留下了很有价值的样本。哪些政策有冲突，哪些问题缺数据，哪些建议几乎每次都能用，哪些场景总要重新写，都能从这里看出来。

但问题也来了：过去客服自己判断、自己回复，现在还要先看 AI 的建议，判断靠不靠谱，有问题再修改。AI 表现不稳定时，审核甚至会增加工作量。

所以，AI 上线了，人力成本不但没降，反而又多了一笔 AI 的费用。这个是 AI 项目最危险也最被耻笑的阶段。

积累了一批数据后，我们开始按场景的风险和成熟度放权。已经验证充分、规则明确的场景，进入自动处理白名单；复杂例外和高风险问题，继续交给人工。

AI 也开始获得两类重要能力：查和写。查订单、物流、支付、会员和售后进度；在权限允许的情况下，修改部分信息，调用接口触发业务流程。

放权之前，我们做过人机结果对照：客服照常处理，AI 在背后同步跑一遍，留下日志。这套影子系统是用来验证能力的，真实写操作要隔离，不能人工提交一次售后，AI 又提交一次。

这个阶段的感受很直接：Token 用了不少，效率却没有同步提高。因为人和 AI 都在干活，只不过 AI 干的那一遍，主要还是为了验证。

与此同时，团队关系也变了。之前 AI 帮客服减轻工作，现在开始接走工作，大家对岗位、考核和责任都会有想法。项目负责人会花很多时间解释和协调，这些管理成本，Demo 里是看不见的。

不知道下一步该干什么了

原来我们以为，技术和管理问题处理完，效率就该起来了。结果团队又进入了一段迷茫期：AI 已经做了很多功能，但究竟会什么、不会什么，下一步最值得做什么，反而越来越说不清楚。

于是，我们重新整理场景地图。

售前、售中、售后的分类太粗了，退款进度查询、质量举证、补发申请、地址修改，必须继续拆。每个场景要明确用户意图、前置条件、所需数据、业务规则、工具、风险、成功标准和转人工条件。

这张表一出来，团队才又有了可以共同讨论的东西。本周做哪个场景，缺的是知识还是接口，做到什么程度可以放量，都能说清楚。

几个月下来，按当时的统计，系统覆盖了超过七成的客服场景，承接了接近一半的真实流量。

这里两个数字不能混用。场景覆盖说的是会处理多少类问题，流量接管说的是实际承接了多少请求。至于这些请求最终有多少完全不需要人工、真正解决了，还要继续看自动解决情况。

场景数量也不代表业务量。几十个长尾场景，可能没有一个高频场景的咨询多。所以后面我们优先考虑高频、标准、风险可控，而且做完能真正释放人工的场景。

六、AI 还是比人贵

回到开头那个最反常识的问题：AI 已经干了这么多活，为什么综合成本还是高于人工？

盘一下账单就明白了。

首先是建设费用。产品、研发、知识整理、场景运营、系统接入，这些都要人做。传统客服系统已经运行多年，费用早就摊薄了，AI 客服还在补基础设施，研发投入却是当下实打实在花的。

其次是双重成本。很多场景还在审核和接管阶段，AI 先理解、查询、生成，人工再看一遍。同一张工单同时消耗模型和客服时间，不能因为 AI 参与了，就认为人工已经退出了。

再其次，复杂调用也没有想象中便宜。识别意图、补充信息、选择工具、读取结果、检查风险、生成回复，一笔业务可能调用多次模型。上下文越长，工具越多，重试越频繁，费用越高。

此外，节省的工时还没有完全变成节省的支出。AI 接了部分流量，但排班、外包和人员安排没有相应变化，账上的人工成本就未必下降。剩下交给人工的问题通常还更难，也不能直接按流量比例折算人力。

最后还有持续维护。政策会改，知识会过期，业务会增加新玩法，模型和提示词更新后要重新评测。做成以后，依旧需要一支团队来维护它。

所以我当时陪跑到那个阶段，后面再了解情况：AI 客服的综合成本也没有完全优于人工。

这件事很难圆。项目负责人可以讲长期、讲趋势、讲未来扩展性，但当前成本高，确实就是高。账单里除了客服人力，又加上了产研、运营和 Token。

当然，这不代表项目一定没有价值。客服人数不再严格跟随业务量增长，避免扩招、减少加班、释放关键人员时间，也都是收益。但这些需要分别算，不能全部包装成已经省下来的工资。

要比较，就在业务量和服务质量接近的情况下，把建设分摊、运行、人工兜底和返工一起算进去，最后看每个真正解决的问题花了多少钱。只看一次模型调用的价格，算不清这个账。

七、如何降低成本

那接下来怎么办？从这些问题出发，我会先看整张工单，而不是急着换便宜模型，甚至什么地方应该用贵的模型、什么地方应该用便宜的模型，都是需要设计的。

先把人工的重复动作找出来

用户发一句话，客服看一次；AI 给一个结果，客服确认一次；进入下一个步骤，客服再点一下。如果整条链路都是这样，模型便宜一点，确实省不了多少人工。

对于已经验证充分的场景，需要逐步取消不必要的逐条审核，让系统能够把业务往下推进。高风险问题保留关键确认，但信息收集、数据查询和材料准备，可以先由系统完成。

这里还需要记录任务状态。现在处理哪笔订单，已经收集了什么，缺什么，刚执行过哪个动作，下一步是什么，都要保存下来。否则每次从聊天记录重新理解，既费 Token，也容易重复追问和重复操作。

工具调用同样要检查结果。创建售后超时了，不一定是没创建成功，也可能只是结果没返回。先查清楚再决定是否重试，别让同一笔业务被提交好几次。

把不需要的调用拿掉