AI客服实战：规避风险、选择路径与构建可观测性
承接上文，在我们近两年完成的23个AI项目中，先前已探讨了其中18个属于工作流类型。那么，剩余的5个项目是什么呢？
答案是知识库驱动的AI项目，而在这其中，有3个是标准的简单AI客服系统。
这可能与一些人的直觉相悖。按理说，AI客服不正是最典型的应用场景吗？为何其占比如此之小？答案很直接：因为通常需要部署AI客服的业务环节，往往至关重要，企业不愿在此轻易承担风险。
随之而来的问题是：部署AI客服真的算是一种冒险吗？答案是肯定的，而且风险系数相当高。几乎每一个我经手过的AI客服项目都曾出现过或大或小的事故，无一例外。例如，可以回顾此前的案例分享。
这也解释了为何各公司首先涌现的是工作流类AI应用，而非理论上更应被AI解决的业务核心——客服问题。对于内部工作流AI，即使出错，影响也局限在公司内部；但面向客户的业务一旦出错，就意味着直接的经济损失。
正因为AI客服对稳定性与准确性有着极高要求，所以在架构设计上必须追求高度的可观测性。这引出了当前实现AI项目的两种核心技术路径：AI Max 与 AI Min。
AI Min/Max技术路径解析
近期在授课时，我反复强调一个观点：开发AI应用必须深刻理解模型的边界。这里的“模型边界”衍生出AI应用的两种构建哲学：
- 能用AI就用AI（AI Max）；
- 能不用AI就不用AI（AI Min）。
这三句简单的概括背后蕴含了大量隐性知识，包括RAG技术先驱之一Douwe Kiela的见解：应聚焦于系统的可观测性，而非单纯追求准确性。
在AI项目中，实现100%的准确率几乎是不可能的任务。即便能达到90%或95%，企业当前更关切的是如何应对那缺失的5%或10%——即不准确的部分。当错误发生时，系统该如何处理？
除了基础准确性，关键在于如何管理“不准确”，这就需要可观测性的支撑。必须能够细致评估系统表现，并确保存在完备的审计追踪机制，这在受监管的行业中尤为重要。
而这里所强调的可观测性，主要在 “能不用AI就不用AI” 的模式下才更易实现。其背后体现的是对模型边界的清醒认知：追求完美的准确率并不现实，核心是要清晰知晓错误发生在何处、成因是什么、如何修正，并且能证明整个技术框架是闭环且可重复验证的！
下面，我们通过一个具体案例来阐释何为“AI Max”、何为“AI Min”，以及AI项目的可观测性究竟指什么。
案例详解：从排班系统看技术路径选择
此前因AI课程学员众多，需要一个自动化排班系统。基本需求是：学员在微信群中发布各自的每日空闲时段，由AI自动统计出共同有空的时间，若满足开课条件则自动预约会议。学员在群中的发言示例如下：
A：20.00-22.00有空
B：18-20点没空，其他都可以
C：二十点后可以；
D：下午4点前没空；
E：我随便了，都行；
实际系统还需包含多次提醒、少数服从多数、协调学员调整时间等功能，但核心需求是一个时间匹配算法。正是这个简单的系统，能清晰阐明模型边界的概念。
首先，来看“能用AI就AI”的Max路径：
一、AI Max路径：全量交给模型处理
采用AI Max方案非常简单，直接将所有聊天记录扔给大语言模型，并提示 “请问今天我该安排什么时间上课？” 即可。
模型会直接输出建议的时间段。在简单场景下，“能用AI就AI” 往往是最高效的解决方案，许多智能体（如某些自动化助手）在简单任务中表现确实出色。
接下来，看AI Min路径：
二、AI Min路径：最小化AI使用
所谓最小化AI应用，即仅在不得不使用AI的环节使用。在本案例中，不得不使用AI的环节是关键词提取，亦即语义识别每位学员的空闲时间陈述：
- A：空闲时间段为 20:00 - 22:00。
- 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出现识别失败的情况时，系统能够快速发现并定位问题，从而启动优化流程。
假设出现学员F，给出了一个非常规回答：“戌亥之时，余有暇。”（意为晚上7点到11点有空）。面对这种古文表述，模型很可能无法正确解析，导致排班系统出错。在 “能不用AI就不用AI” 的模式下，由于AI仅负责“提取时间”这一个明确定义的子任务，一旦其输出异常（如输出乱码或无法解析），系统能立刻感知到这个“提取环节”的故障，而非得到一个看似合理但实际错误的时间交集结果。
这种能够被明确识别、定位并进而优化的特性，就是我们所说的模型能力可观测性。
随之而来的最后一个问题是：如何实施优化？
五、优化策略
一旦发现问题，优化方案是清晰的。最直接的方法是将 “戌亥之时，余有暇” 与其对应的时间（19:00-23:00）作为映射对，加入到提示词的示例库中，建立一个古今时间表述的映射关系。
若需更强的泛化能力，则可以启动后续训练，无论是微调（Fine-tuning）还是强化学习（RL），均可达到目的。
以上便是对模型边界这一概念最为简化的阐述。当然，真实业务场景的复杂度会远超此例。
AI客服系统的核心挑战与路径选择
之所以用较大篇幅介绍AI Max/Min技术路径，是因为我所接触的AI客服项目，大多属于严肃业务领域。它们不可能采用AI Max模式，即把知识库完全丢给AI让其自由发挥。实际情况是，每次客服对话得出的关键结论，甚至可能还需要一套**“慢系统”**（如基于规则或人工复核的流程）进行二次校验。
为了让问题更清晰，这里补充几个简单AI客服系统必然会面临的挑战：
- 数据准备：如何整理数据？整理哪些数据？
- 系统监控：如何构建可观测性体系？
- 风险管控：应急机制如何设计？
首先对AI客服的适用场景做一个概括：它最适合高频重复、知识明确且固定、对话长度短、风险可控的业务环节。下面我们逐一展开：
所谓高频重复、知识明确，典型场景包括：常见产品FAQ、标准化流程指引、简单售前咨询、订单物流状态查询等。
这类问题的答案高度固定，真人客服的回答与AI相差无几，但咨询量巨大。因此，完全可以交由AI处理。当然，一旦用户对话跳出预设框架，涉及情感倾诉、纠纷投诉、复杂决策等内容，系统必须能够识别，并策略性地转向专项AI处理或直接转接人工客服。
了解AI技术的同学会知道，AI客服的表现直接受数据质量制约。如果公司内部知识零散或缺乏梳理，那么AI客服的准确率必然难以保障。
因此，与工作流AI不同，简单AI客服的难点往往不在于技术上的“Know-How”，而在于前期繁琐的“数据整理”。并且，数据整理的工作量必须计入整个AI项目的成本。在一个AI客服项目中，数据相关工作占比很可能超过60%。
这里可能有一个反直觉的发现：在实际构建中，知识库词条的设计越是结构化、分类越清晰，AI客服的整体表现就越好。在具体技术实施上，并非必须使用向量数据库，我们仅在特定场景下使用过一次向量库，它并非标配。
AI客服系统实施方法论
基于过往的简单AI客服项目实施经验，我们总结出一套可执行的方法论：
一、构建全局问答映射表
首先，需根据实际业务需求，系统性地梳理数据。核心工作是：明确界定AI需要回答哪些具体问题。
在严格实施中，这些数据应包括：不同问题类型可接受的错误率、响应时长上限以及成本约束。这需要制作一张详细的映射表。例如，此前为AI训练营搭建的售前客服系统，其部分表示例如下：
我的示例场景较为简单，可全部由AI处理。若是稍复杂的客服系统，必须注意在此表中为每个问题设定等级，并明确策略：AI负责处理到哪一步、处理不了的流程应移交至何人，这些都需要清晰设计。
例如，涉及用户重大利益（如投诉、纠纷）、高敏感信息（如账户隐私）、或用户情绪激烈等场景，应设定规则直接转人工，避免让AI强行应对。
二、结构化知识库建设
在全局表确定后，便需要依据用户问题整理结构化的知识库。这是一个需要精心设计的过程，可视为数据工程的入门实践。
方法论是先穷尽枚举，再进行分类归纳。实际上，全局表中需要回答的问题本身就是分类的结果。此阶段的核心是建立标准问题与标准答案之间精确的对应关系（也可以是一对多）。
建立这种对应关系至关重要，因为一些公司出于成本考量，可能会采用经过精调的小模型来部署服务。
在实际操作中，要认识到AI客服的“二八定律”与长尾效应非常显著。因此，初期即使无法解决所有问题也无需焦虑，应优先聚焦解决核心高频问题。
例如，在电商场景中，优先处理物流查询、退换货政策、核心产品咨询等。这也是一种稳妥的工作模式转型过程。
此外，必须确保知识库系统与客服团队负责人（或资深客服）的流程打通。因为为了解决长尾问题或持续优化系统，知识库必然需要不断更新。换言之：
未来可能的情况是：80%的初级客服岗位被自动化取代，而20%的资深客服则转型为数据工程师，负责数据飞轮系统的具体运营。同时，这20%的人员也将作为AI系统失效时的最终兜底保障。
此处特别提一下“数据飞轮”，它主要关注错误回答率和用户对话跳出率。一旦这些指标出现异常，就需要从数据或策略层面进行迭代优化。这要求数据工程师对每日的问答记录进行抽样分析。
三、设计完备的兜底与应急机制
事实上，数据整理完成后，AI客服的主体设计便已基本成型，后续通常不会遇到重大技术卡点。但系统的难点与风险点也随之浮现，以下是几个常见问题：
1. 规则决策树的不可或缺性 对于高风险客服场景，除了模型自身的逻辑，还必须配备一套更快速、更确定的规则逻辑，即前文提到的决策树。只要是涉及风险判断的问答，这套机制必不可少。
2. 基础设施的可靠性考量 在我经历的场景中，云服务提供商也曾出现不稳定情况。因此，若业务确实至关重要，则不能完全依赖单一云服务商。在必要时需启用混合云或多云架构，但这背后的成本与运维复杂度会显著增加。
3. 人为操作失误的预防 如果系统运行依赖人员的特定操作，那么几乎必然会发生事故。例如，系统规定客服人员下班后需手动点击“停止AI客服”按钮。在实际运行中，无论规章制度如何强调，总会有疏忽的客服人员忘记操作。
因此，AI客服的设计必须充分考虑人为干扰因素。如果某些环节必须由人参与，应尽可能将所有关键操作权限收归到统一的管理界面，并进行操作日志记录与二次确认。
结语：从技术炫技到业务务实
此前，我们训练营中一位出身产品经理的AI项目负责人在学习后感慨道：
我终于明白，为何以前看不懂公司里某些程序员的技术方案了。他们在进行技术架构选型时，下意识地采用了AI Max思路：
一个开源方案效果不佳，就换另一个；单智能体不行，就尝试多智能体。把所有热门技术试过一遍后，便得出结论：AI的能力上限即是如此，已无优化空间，只能等待下一代开源技术发布后再来一轮尝试。
我时常感到疑惑，忍不住追问他们如何量化这个所谓的“上限”？是否有可复用的过程方法论？而得到的回答往往是：无法量化、难以沉淀，都是拿别人的开源代码跑一下看看效果。
我总觉得哪里不对，但因缺乏技术深度而无法指摘。现在终于清晰，这条路确实走不通。接下来，应该由我来主导设计技术实现的路径！
这番感慨同样适用于AI客服领域。许多人一提到AI客服，言必称RAG（检索增强生成）。然而，RAG并非解决一切问题的“万能灵药”，它的应用也需分具体场景。正确的实施顺序是：首先深入理解业务，其次梳理清晰的标准作业程序（SOP），然后设计与之匹配的数据框架，最后才是上线运行、收集反馈并持续优化。
不同的业务场景对应不同的SOP及与之配套的数据结构。企图仅凭一项粗暴的通用技术解决所有业务难题，这并非技术上的傲慢，而是方法论上的缺失。
而当我们将重心回归到业务与数据时，技术团队常会提出另一个现实挑战：公司在该业务领域历史上几乎没有数据积累，该怎么办？ 这或许将是另一个需要深入探讨的话题了。