给200家连锁门店搭一套AI客服系统，实际踩坑记录

去年秋天有个客户找过来，情况挺典型的：他们是一家做中式快餐的连锁品牌，全国有将近200家门店，覆盖20多个城市。之前客服团队10个人，主要处理三类事情——门店查询（用户在哪个城市哪家店最近）、订单投诉（外卖送错了/少了/凉了）、会员问题（积分对不上/优惠券用不了/储值卡退款）。这10个人每天从早上八点忙到晚上十点，高峰期（午晚市）根本接不过来，用户打电话等三分钟是常事。

老板的想法很朴素：能不能做一个AI客服，把80%的重复问题自动处理掉，人工只处理真正复杂的情况？而且不要那种冷冰冰的关键词匹配——用户问"你们那个满30减8的券怎么找不到"，AI应该知道他说的是哪张券，并且能根据他的会员等级和券的有效期给出具体答案。

这篇文章就是关于这个项目从零到上线的完整记录。涉及到的公司信息已经脱敏处理，核心技术细节保留，给有类似需求的朋友做个参考。

一、先搞清楚：哪些问题适合AI处理，哪些必须转人工

项目启动第一周，我们没有写一行代码，而是跟客户的客服主管一起翻了三周的客服聊天记录和电话录音，做了分类统计。结果如下：

数据告诉我们：72%的咨询可以用AI处理，剩下28%需要人工介入。 这个数字超出了客户预期——他本来觉得能覆盖50%就不错了。

同时我们也做了一个重要决定：不要让AI冒充真人。用户一进来就先报身份——"您好，我是小知AI助手，可以帮您查门店、查订单、问会员问题。复杂问题我会帮您转接人工客服。"这个透明的做法后来被证明是明智的——用户对AI的容忍度远高于对"冒充人类的AI"的容忍度。

二、技术方案：RAG + Function Calling + 人工兜底

整体架构分成四层：

用户端（微信公众号/小程序/APP内嵌H5）  
        ↓  
    对话路由层（意图识别 → AI处理 or 转人工）  
        ↓  
    AI处理引擎（RAG知识检索 + Function Calling + LLM生成）  
        ↓  
    数据与服务层（门店DB/订单API/会员系统/优惠券引擎）

2.1 RAG知识库：让AI理解这家企业的"行话"

我们花了最长的时间在知识库的搭建上，因为它直接决定了AI回答的质量底线。

文档收集： 从客户内部收集了以下资料——员工培训手册（SOP）、菜品配方与过敏原清单、食品安全规范、会员政策文档、优惠活动规则、退换货政策。总共大概150份文档，格式五花八门——Word、PDF、在线文档、甚至还有几张拍下来的海报照片。

分块策略： 这是第一个技术决策点。我们测试了三种分块方案：

• 方案A：固定500 token一块 → 召回率高但语义碎片化，经常把同一个政策的上下段切开
• 方案B：固定1000 token一块 → 语义相对完整但有冗余信息
• 方案C（最终采用）：按段落边界分块，单块500-800 token，相邻块保留100 token重叠 → 兼顾语义完整性和检索精度

比如会员等级政策是个表格——不同等级对应不同折扣和积分倍率。固定分块很容易把表头分到一块、内容分到另一块。我们针对表格类文档单独写了解析逻辑，确保一个完整的表格不被切碎。

Embedding模型选型： 测试了三个中文模型在客服场景下的检索效果：

最后选的是bge-large-zh-v1.5，本地部署在客户的GPU服务器上。日均调用量大概2万次，单次检索延迟稳定在30ms以内。成本上比调用OpenAI的Embedding API省了大概70%。

检索调优： 裸用向量检索在几个场景下召回率偏低。用户说"那个满30减8的券怎么用不了"，向量检索可能匹配到跟"券"相关的各种文档，但不一定是那张具体的券。我们加了混合检索——先用Elasticsearch做关键词匹配（"满30减8"），再在向量检索结果中做交叉筛选。加上Reranker二次排序后，Top5召回率从89%提升到了94%。

2.2 Function Calling：让AI不只是"说话"，还能"办事"

这是本项目跟普通AI客服的最大区别。用户不只想"问"，还想"查"和"办"。我们给AI配了以下工具：

// AI可调用的工具函数列表  
const tools = [  
  {  
    name: "queryStores",  
    description: "查询用户附近的门店。参数：city(城市), lat/lng(经纬度)",  
    api: "GET /api/stores/nearby"  
  },  
  {  
    name: "queryOrder",  
    description: "查询用户订单状态。参数：orderId(订单号) or phone(手机号)",  
    api: "GET /api/orders/status"  
  },  
  {  
    name: "queryMember",  
    description: "查询会员积分、等级、优惠券。参数：memberId or phone",  
    api: "GET /api/member/profile"  
  },  
  {  
    name: "queryCoupon",  
    description: "查询用户当前可用的优惠券列表及使用条件",  
    api: "GET /api/coupons/available"  
  },  
  {  
    name: "submitRefund",  
    description: "发起退款申请。参数：orderId, reason, amount",  
    api: "POST /api/refund/create",  
    requiresConfirm: true // 需要用户二次确认  
  }  
]

函数粒度的权衡： 一开始我们把函数拆得很细——查积分是一个函数、查等级是一个函数、查优惠券又是一个函数。结果AI在处理"我账户里还有多少钱"这种复合问题时，需要连续调用三四个函数，响应时间拉长到8-10秒，用户体验很差。

后来改成了粗粒度+智能结果过滤的方式——比如queryMember一次返回积分、等级、优惠券、储值余额四类数据，AI根据用户的问题自动提取需要展示的部分。这样大部分查询只需要一次函数调用，响应时间压缩到3-4秒。

安全底线： 所有涉及用户资产的操作（退款、优惠券核销、储值卡扣款）都需要用户在对话中明确确认，不能在后台静默执行。确认消息带有订单编号、金额等关键信息，而且整个对话记录和函数调用日志全部落库，支持后续审计。

2.3 意图识别与转人工策略

最初我们让LLM在每一轮对话中自己判断"该不该转人工"，做法是在System Prompt里写规则。但线上跑了两周后发现转人工的时机判断不太稳定——有时候AI在明显处理不了的问题上死磕（不断道歉但就是不给转），有时候又在简单问题上过早转人工（用户说"等一下"AI就以为用户不满意了）。

后来改成了规则引擎+LLM判断双保险：

• 规则引擎触发（强制转人工）： 用户主动说"转人工"/"找人工"/"投诉"；连续两轮AI回答后用户未回复但重新输入了新问题（说明AI没解决）；检测到负面情绪关键词（"骗子""投诉""315""食药监"）直接转人工+标记为敏感工单
• LLM判断触发（建议转人工）： AI判断当前问题超出了自己的知识范围或工具能力，在回复末尾加上"这个问题我建议帮您转接人工客服，您看需要吗？"
• 人工客服接管： AI转接时携带对话摘要——用户是谁、前面聊了什么、问题是什么、AI已经尝试了哪些方案。人工客服不用从头问起

上线一个月后的数据：AI自动处理率71%，人工转接率29%。没有一起严重的AI答非所问导致的客诉——这在AI客服项目里属于相当不错的结果。

三、几个踩过的坑

坑一：AI在多轮对话中"失忆"

初期版本只用了一轮对话的历史上下文。用户说"帮我查一下上次那个订单"——AI需要记住"上次那个订单"指的是前面某轮对话中用户提过的订单号。

解决方案：把最近10轮对话的关键信息（订单号、门店名、优惠券编号）抽取出来存入一个结构化的"对话记忆"对象，每次调用LLM时注入。配合Redis做会话级别的缓存，会话过期时间设30分钟（超时自动清除，保护用户隐私）。

坑二：活动期间知识库"过时"

这家连锁品牌几乎每周都有新活动——周一会员日满减、周三新品折扣、周末套餐优惠。活动规则一变，知识库里还是旧版本，AI就开始给用户过期的信息。

解决方案：在客户的活动后台（一个内部运营系统）加了一个Webhook——运营人员发布新活动时，自动触发知识库的增量更新流程：新活动文档解析→分块→向量化→写入向量库，旧活动文档自动标记为过期但不删除（保留历史可查性）。整个流程从活动发布到AI能正确回答新规则，延迟控制在5分钟以内。

坑三：高峰期推理延迟飙升

饭点前后（11:30-13:00，17:30-19:00）咨询量是平时的3-4倍。LLM推理服务（部署在客户的GPU服务器上）在高峰期出现过响应超时——推理延迟从平时的2-3秒飙升到15-20秒，用户那边看起来就是AI"卡住了"。

排查原因：GPU显存瓶颈。高峰期同时有40+个并发推理请求，超出了单卡的处理能力。

解决方案：加了一个请求队列+优先级调度。用户等待超过5秒时自动发送"正在为您查询，请稍候..."的消息缓冲等待感。同时做了推理加速——高频问题（占总量的40%左右）预先计算好Embedding并缓存问答对，命中缓存时直接返回，跳过LLM推理环节，延迟降到200ms以内。

四、上线效果（脱敏数据）

试运行一个月，然后正式上线三个月，拉了几个关键指标：

• AI自动处理率：71%（从最初的55%逐步提升到了71%，提升来自持续的Prompt调优和知识库补充）
• 首次响应时间：1.2秒（相比人工客服的平均28秒，提升超过20倍）
• 用户满意度：84%（通过对话结束后的满意度评分统计，人工客服同期为91%——差距主要来自情感安抚场景，AI在这方面确实比不过真人）
• 人工客服日均处理量下降：58%（从每人日均120+会话降到50左右，客服团队没有裁员，而是把精力转到了高价值投诉处理和会员回访上面）
• 高峰期接通率：从63%提升到96%（这是老板最关心的指标——以前高峰期用户打不进电话干脆就不打了，也不知道因此丢了多少潜在投诉和复购机会）

五、成本结构（大概参考）

这个项目总投入大致如下：

• 一次性开发费用：约28万（包括知识库搭建、对话系统开发、系统对接、测试上线，周期约3个月）
• GPU服务器：约3.5万/年（一台4卡A10服务器，承载日均5000+次对话的推理请求）
• 向量数据库（Milvus）：约1.2万/年（云托管版本，含备份和监控）
• LLM API费用：约8000/月（部分复杂推理场景调用云端API做辅助，大部分推理走本地部署模型）
• 运维与持续优化：约1.5万/月（知识库更新、Prompt调优、新功能迭代）

对比之前10人客服团队的年成本（工资+社保+场地+管理，粗略估算约120万/年），AI客服系统上线后客服团队从10人优化到了5人（专注高价值投诉和会员运营），年成本降到了约60万，加上AI系统的年运营成本约12万，总计约72万/年，相比之前节省了约48万/年。

但我觉得这个ROI数字不是最重要的。更重要的是接通率从63%到96%的跨越——以前高峰期37%的电话打不进来，意味着每天大概有200-300个用户在需要帮助的时候找不到人。这些"失联的抱怨"最后可能变成了差评、退单和流失。AI客服最大的价值不是省了多少钱，是兜住了这37%的服务缺口。

六、给考虑做AI客服的同行几个建议

1. 从人工客服的聊天记录开始，不要凭空设计。花两周时间分析真实对话，你会有两大收获：第一，知道哪些问题是高频的（该优先用AI覆盖）；第二，知道人工客服是怎么回答的（给AI写Prompt时这些真实的回答是最好的参考）。

2. 知识库的质量决定AI的智商。不要把客户给的文档直接扔进向量库就完了。文档需要清洗——去掉页眉页脚、合并跨页的表格、补充文档之间互相引用的交叉链接。这一块我们占用了整个项目30%的时间，但最终的检索准确率很大程度上就是靠这一步撑起来的。

3. 先上线内测，别一开始就全面对外。我们在内部管理后台嵌了一个"AI客服测试通道"，让客服主管和店长们先用了一周。他们反馈了四十多个问题——有些是知识库缺失，有些是Prompt写得太生硬，有些是工具调用逻辑有问题。这些问题如果在公网直接暴露给用户，后果会很糟糕。

4. AI客服不是一次性交付，是持续运营。上线后的第一个月，我们每周更新一次知识库、调整一次Prompt。活动规则变、菜单变、门店变——知识库就要跟着变。建立自动化的知识更新管道，把运营人员纳入到知识维护的闭环里，不是每次更新都找技术团队。

5. 透明度比"拟人化"更重要。用户对"扮演人类的AI"零容忍。一开始就说清楚你是AI、你能做什么、不能做什么、什么时候会转人工——这个诚实的做法在用户满意度上反而加分。

本文案例根据多个实际项目的共性场景综合撰写，具体数据已做脱敏和模糊化处理。

上海如静知华信息科技有限公司（知华科技），专注企业软件外包与定制开发。官网：www.zhuatech.cn