一文说透AI客服：那个很Low、人人能做，但市场想要又要不到的系统
叶小钗约 9 分钟关注公众号，回复666，获取资料
书接上文：
再次回到我们这两年做的23个AI项目，前面说了18个是工作流，那么剩下的5个是什么呢？
答案是知识库类AI项目，而其中又有3个是标准的简单AI客服。
这可能会有些超出大家的认知，按理说AI客服不是最典型应用吗，为什么占比这么小，答案很简单：因为一般会用到AI客服的业务，往往非常重要，公司不会在这里轻易冒险。
那么下一个问题又出现了：AI客服真的算冒险吗。答案是：当然算了，而且是非常的冒险，几乎每个我负责过的AI客服项目，都出了事故，无一例外，或大或小罢了！比如：
那个搞出200万事故的AI项目，今天突然收到了尾款，甲方还想合作？
这也是为什么，各个公司首先爆发的是工作流类AI，而不是AI最应该解决的业务问题AI客服了。
对于工作流AI，反正是用于公司内部，错了就算了，但业务出点问题可就是真金白银了。
正是因为AI客服要求的是稳定及准确，所以从架构设计上一定会追求可观测性，这里涉及了当前实现AI项目的两套技术路径：AI Max 和 AI Min
AI Min/Max
最近在给学员上课的时候，最常说的一句话是：做AI应用一定要了解模型边界！这里所谓模型边界涉及了AI应用的两个流派：
能用AI就用AI； 能不用AI就不用AI；
就简单的三句话还涉及了很多隐性知识，包括RAG 技术的最初开创者之一Douwe Kiela的一些观点：关注可观测性，而非仅仅准确性。
在AI项目中，达到100%的准确性几乎是不可能的。即使能达到90%或95%的准确率，企业现在更关心的是如何处理那缺失的5%或10%——即不准确的部分。当出现错误时该如何应对？
除了基本的准确性要求外，关键在于如何处理不准确性，这就需要可观测性。需要仔细评估系统表现，并确保有适当的审计追踪，尤其是在受监管行业。
而这里所谓的可观测性，只在能不用AI就不用AI的模式下可行，他的背后体现的是模型的边界认知：追求完美准确率不现实，关键是要知道错在哪、为什么错、怎么改！并且能证明技术框架是闭环可重复的！
今天我们就用一个简单案例来解释解释什么是能用AI就用AI，什么是能不用AI就不用AI，什么又是AI项目的可观测性。
案例说明
之前AI课的时候学员过多，需要一个排班系统，大概的需求是：
学员在微信群打出自己每天的空余时间，AI会主动统计大家都有空的时间，如果满足条件就预约会议，学员在群里的聊天信息如下：
A：20.00-22.00有空
B：18-20点没空，其他都可以
C：二十点后可以；
D：下午4点前没空；
E：我随便了，都行；
当然，实际功能会有很多提醒、少数服从多数、协调学员调整时间等功能，但主体需求就是一个时间算法。
非常简单的需求，但就是这么一个简单的系统就能聊清楚什么是模型边界。
首先是能用AI Max的技术路径：
一、能用AI就AI
全部用AI就很简单了，直接一股脑丢给模型加一句“请问今天我该安排什么时间上课”就行：
GPT的回答：
DeepSeek的回答：
如果在简单场景下，能用AI就AI其实是最优解，包括很多智能体如Manus在简单任务里面的表现是非常不错的。
随后就是AI Min：
最小化AI应用
所谓最小化AI应用，就是只在不得不使用AI的地方使用，比如这里不得不使用的地方就是提取关键词，也就是语义识别每个学员的空闲时间：
A：空闲时间段为 20:00 - 22:00（即晚上8点到10点）。 B：18:00 - 20:00 没空，其他时间空闲（即 00:00 - 18:00 和 20:00 - 24:00）。 C：二十点后可以，即 20:00 - 24:00 空闲。 D：下午4点前没空，即 16:00 - 24:00 空闲（下午4点为16:00）。 E：所有时间都空闲（即 00:00 - 24:00）。
拿到空闲时间后，再自己用算法去做实现，这里马上就涉及了另一个问题了：在最小化AI应用的场景里，什么时候需要用AI？
泛化能力
答案很简单，在充满泛化场景的时候需要，比如上面ABCDE的回答，你很难用正则的方法给他匹配出来，类似这种关键词（关键知识）的提取只能依靠AI；
相同的场景是，我要求学员的昵称必须是学号-昵称-城市的格式，但学员一定会做得五花八门，比如就有学号_昵称_城市、城市_学号_昵称、学号昵称@城市等等莫名其妙的排布方式。
这种在学员自己设置后，也只有AI能快速帮他们做更正。
所有类似这种泛化要求较高的往往都必须AI出场，并且AI在这个领域做得挺好的！
那么，什么又是模型能力可观测性呢？
可观测性
答案也非常简单：如果出现了AI识别不了的情况，能很快识别并解决！
比如现在出现一个F，他给的答案比较另类：戌亥之时，余有暇。
类似于这种回答，模型很可能识别不了，那么排班系统就会出问题，这个在能不用AI就不用AI的模式下就可以被识别并优化。
这里的可以被识别且优化就是我们所谓的模型能力可观测。
最后一个问题：如何优化？
如何优化？
如果发现问题要优化就很简单了，最简单的做法是将戌亥之时，余有暇。对应的时间当放到提示词，做一个古文时间与现在时间的映射。
如果要泛化能力强一点就可以启动后训练，可以是微调也可以是RL，都一样。
以上整个就是所谓模型边界最简单的描述，真实场景当然会复杂太多！
AI客服
之所以长篇大论的介绍AI Max/Min技术路径，是因为我所接触的AI客服，都属于偏严肃领域，不可能采用AI Max，将知识丢给AI让他自由发挥的事情是不存在的，甚至每次客服关键结论，还会有一套慢系统去做校验。
这里再补充几个简单AI客服会遇到的问题，大家就很清晰了：
如何整理数据，整理什么数据； 如何构建可观测性； 应急机制；
这里要做一下AI客服的概括性总结，AI客服适用于高频重复、知识明确且固定、对话长度短且风险可控的场景，接下来我们一一做下进一步说明：
这里所谓高频重复、知识明确，比如常见的产品FQA、简单流程指引、简单售前、订单物流等。
这类问题答案非常固定，真人回答的跟AI差不多，但是量特别大，所以完全可以启用AI回答。当然如果用户跳出了咨询框架，聊天内容开始涉及到了情感倾诉、纠纷投诉、复杂决策等，要么有特别的AI、要么就转人工了。
熟悉的同学会了解，AI客服的好坏直接受数据质量的影响，（（如果公司内部没有知识或者知识存储很散乱，那么AI客服表现（准确率）一定会很糟糕。**
所以，与之前工作流不一样的情况出现了，简单的AI客服，其难点不在KnowHow而在数据整理，而且数据整理的工作量需要算在整个AI项目里面，一个AI客服项目，AI占比一定会超过60%！
并且，这里可能有个反常识的情况，我们在实际做AI客服的时候，知识库词条的设计越是结构化、分类越清晰，整个AI客服的表现越好。具体技术实施的时候只用过一次向量库，向量库并不是非用不可。
接下来是具体实施路径：
AI客服方法论
在过往的简单AI客服实施过程中，我们形成了一套简单的方法论：
一、全局表
首先，我们需要根据实际业务需求，整理数据，重点需要关注：（（典型的用户QA问答；
这里说白了就一个事情确定AI到底要回答哪些问题，严格情况下数据要包括：不同问题的可接受错误率和响应时长，可接受成本。这里是需要做出一张表的，比如我之前做的AI训练营售前客服：
我这里的场景是很简单的，全部可以由AI完成，如果是稍微复杂点的客服系统，一定要注意这张表里面要为每个问题做分级，有明确的策略，AI能做哪几步、做不了的移交给谁，要设计清晰。
比如涉及用户重大利益(投诉、纠纷)、高敏感信息(账户隐私)、强烈情绪等场景，应直接转人工，避免让AI硬撑。
二、数据整理
在全局表出来后，就根据用户的问题整理结构化的知识库了，要注意这里是需要设计的，算是数据工程的入门级实践。
这里方法论是先穷举再分类，其实前面全局表中需要回答的问题就是分类的结果，这里讲究的是标准问题和标准答案的一一对应（也可以是一对多的关系）。
这里的对应关系一定要建好，因为一些公司出于成本的考虑，可能会使用训练过的小模型。
在实际做数据整理的时候，要知道AI客服的28原则与长尾效应非常明显，所以初期就算搞不定所有问题也没关系，先聚焦解决最核心的问题就好。
比如电商中的物流查询、退换货、卖货里面的产品咨询等，这样也有个工作模式的重塑过程，会比较稳一点。
其次要特别注意，知识库系统和客服组长一定要打通，因为为解决长尾问题或者持续优化系统，知识库必定会不停更新，换句话说：
80%的客服失业了，20%的客服被提拔成了数据工程师，他们会负责数据飞轮系统的具体实施。并且这20%的人工，会作为AI崩溃时候的兜底使用！
这里特别提一下数据飞轮，其实他关注的是错误回答和跳出率，这两个出现都需要做数据或者策略侧的迭代，这里需要让数据工程师对每日问答进行抽样。
三、兜底
其实，数据整理结束，AI客服就基本设计结束了，接下来不会遇到卡点，但难点/风险点也就来了，这里随便提说几个：
一、决策树
对于一些风险客服，除了模型逻辑，还需要一套更为快速的公式逻辑，也就是前面说的决策树逻辑，只要是风险问答，这个东西就必不可少。
二、混合云
就我遭遇的场景里面云服务器都出现过抽风的情况，所以如果业务确实非常重要，就不能依赖单云服务器，在必要情况下要启用混合云，只不过这背后的成本就很麻烦了...
三、人员错误
如果你系统依赖对人员的管理，那么一定会出事故，比如系统规定不使用后需要点击停止AI客服，在实际运行过程中，无论怎么强调，都一定会有蠢蠢的客服忘记点击。
所以AI客服的设计一定要考虑人员干扰的因素，如果非要用人，将所有的人员操作权限收归到一起。
结语
之前我们训练营一个学员本身是产品出身的AI负责人，他在学了课程后开始感叹：
我终于知道，为什么搞不懂公司那批程序员在做什么了，他们在做技术架构的时候采用的是AI Max思路：
一个开源技术不行就换一个，单智能体不行就换多智能体，全部试过以后就说AI的上限就是这样，没有优化空间了，等新的技术开源了就再来一遍。
我有时候确实好奇，忍不住要问一他们怎么量化上限、有没有过程方法论？这批程序员就说量化不了、沉淀不了，都是别人的东西跑一下就好了。
我总觉得哪里不对，但因为不懂也说不出个所以然，只能听之任之，现在好了，确实不行，老子来给他们设计技术路径！
其实这里的感叹对于AI客服是同样适用的，很多人提到AI客服就是RAG，TMD RAG又不是万能的春药，他的使用也要分场景的。首先得了解业务，其次要梳理SOP，然后要设计数据框架，最后才是上线跑效果拿反馈；
不同的场景会有不同的SOP以及与之匹配的数据结构，如果仅仅想依靠粗暴的技术解决所有的业务问题，这不是傲慢这是傻。
而当我们去着手解决的时候，程序员们又开始抱怨：公司在这个板块历史上根本没撒数据积累啊？这里可能需要后面具体展开聊聊了...
点击上方卡片关注叶小钗公众号，查看下方二维码，添加我个人微信：