AI客服响应时长从50分钟优化到2分半的实战踩坑记录

去年 Q4 我们团队接了个看上去不太性感的任务把客服平均响应时长从 50 分钟压到 3 分钟以内。客服主管给我们看了组数据用户凌晨一点发起售后咨询平均要等将近一小时才收到第一条有效回复。那条工单下面用户已经骂了三轮。我当时的第一反应是这不就是上套 AI 客服的事吗但真的把方案铺开后才发现从能用到响应快之间隔着一整条性能鸿沟。我们上线 3 个月一路把 P95 响应时长从 50 分钟干到 2 分半中间踩了三个大坑每一个都差点让项目回炉重造。这篇就是把这三段踩坑经历完整拆开把根因、排查链路、修复方案和数据变化都摆出来给准备做或正在做 AI 客服的团队当个参考。1. 为什么响应时长会卡在 50 分钟立项前的痛点解剖1.1 传统客服模式的三个死结先交代一下业务背景。我们是一个在线零售平台客服团队 20 多人高峰期一天进线量在 4000 到 6000 通。过去的人工客服流程是用户提交工单客服按队列顺序逐条处理。这个模式有三个绕不开的死结。第一个是人的时间碎片化。客服要同时应对电话、在线聊天、工单系统三个入口处理一件复杂售后可能要来回查订单、查物流、核对聊天记录单条耗时经常超过 10 分钟。一旦进线量上来队列就开始堆积50 分钟的平均响应就是这么堆出来的。第二个是夜间和节假日的人力空白。晚上 10 点到第二天早上 8 点值班人员只有 2 个人遇到大促或突发售后高峰基本处于瘫痪状态。我们统计过深夜时段的响应时长中位数是白天的 8 倍。第三个是回复质量不稳定。同一个退款问题不同客服的话术差异极大经常出现用户问一次、客服答一次、用户再追问、客服再查一次的来回拉扯。这也是响应时长的隐性成本。1.2 我们给响应时长定的硬指标立项前管理层给的指令很模糊就说改善用户体验缩短客服响应时间。但我们知道没有量化标准的优化到最后一定是不了了之。所以在项目启动第一周我们做了一次进线数据的全量复盘定义了三组核心指标。第一组是响应时长分位数P50一半用户在这个时间内收到首次回复、P9595% 的用户在这个时间内收到首次回复、P99。因为 AeP50 平均值容易被极端值拉偏我们坚持用分位数看。上线前的真实数据是 P50 约 23 分钟P95 约 50 分钟P99 直接爆表超过 2 小时。第二组是人工介入率即多少比例的会话最终需要转人工处理。这个指标决定 AI 是不是真的在干活而不是只会机械回复您好已收到您的反馈。第三组是满意度CSATAI 回复后用户给的好评比例。目标定的是上线 3 个月后P95 响应时长进入 3 分钟以内人工介入率降到 40% 以下CSAT 不低于人工客服的 80%。1.3 技术路线选择为什么是自建 RAG 而不是直接买 SaaS当时市面上有不少现成的智能客服 SaaS开箱即用但采购部门一算账按我们 6000 通的日均进线量一年的订阅费够自己养两三个后端开发了。更重要的是客服数据涉及订单信息、用户隐私走第三方 SaaS 在合规上很难过审。所以最后定下的路线是自建一套基于开源大模型 RAG检索增强生成的客服问答系统对接现有的工单系统。大模型负责语义理解和回复生成RAG 负责从企业知识库售后政策、退换货规则、物流说明等里检索出与用户问题匹配的内容再交给大模型组织成自然语言回复。这套路线的核心优势是知识库可实时更新、回复可控、数据不出内网。现在回头看这个选型决定本身是对的但我们在性能预估上过于乐观——这也为后面三个坑埋下了伏笔。2. 上线前的性能基线与容量规划我们以为的快和实际的快不是一回事在正式接入生产环境前我们花了两周做性能基线测试。这里说的性能基线不是简单拿 Postman 调几个接口看看通不通而是把整条链路的每个环节耗时都拆开定出预算再反过来推导需要的机器资源和架构边界。2.1 核心链路拆解与耗时预算我们的 AI 客服系统端到端处理链路可以拆成五个环节接入与预处理用户从 H5 或 App 客服入口提交问题网关鉴权、风控、消息队列投递预算 200ms。会话上下文加载从会话服务里读取该用户的聊天历史、订单信息、用户标签预算 500ms。知识库检索把用户问题向量化从向量数据库中召回与问题相关的知识片段再用重排序模型做相关性打分预算 800ms。大模型生成把检索结果和上下文拼成 Prompt调用部署在内网的生成模型流式返回回复预算 1500ms首 token 时间。工单回写把 AI 回复写入客服工单系统通知用户预算 300ms。五个环节相加理想状态下的 P95 端到端耗时是 3.3 秒。这个数字听起来很美好但别忘了这只是 AI 处理链路的理论耗时。实际业务里还有队列等待、网络抖动、知识库冷启动、模型推理排队等大量不可控因素。2.2 压测工具与容量推算我们当时用了两款工具做压测一款是开源的 locust用来模拟多用户并发会话另一款是 wrk针对 HTTP 接口做短期高并发验证。压测场景分三档日常 100 并发、高峰 500 并发、极端 1000 并发。压测暴露出第一个问题向量数据库和模型的吞吐量完全跟不上。在 500 并发下向量检索 P95 达到 4.2 秒模型推理 P95 更是超过 20 秒整个系统在持续压测 5 分钟后开始大面积超时。当时的结论是需要增加推理服务器节点预算也从原来的 2 台 GPU 扩到 4 台。但真正上线后我们才明白压测环境的数据量是假的——压测时向量库里只有 5000 条测试数据生产环境有 3 万多个知识分块检索延迟完全不是一个量级。这也是我后面要反复强调的一点压测环境一定要贴近生产数据规模否则测出来的基线毫无参考价值。2.3 指标口径统一别让快变得不可验证性能基线定的第二个容易踩坑的地方是响应时长的口径。我们内部曾经争论过到底是从用户点击发送开始算还是从 AI 系统收到消息开始算还是从客服工单里出现第一条 AI 回复开始算口径不统一后面所有数据都白测。最终我们跟客服、产品、技术三方约定用户响应时长 用户发送消息的时刻 - 用户在会话窗口内看到第一条有效回复的时刻。这个口径最接近用户体感也让前后端联调时有一致的参照。所有监控看板都按这个口径出数据。3. 坑一知识库检索性能翻车AI 上线第一周响应时长反而更慢了3.1 第一周的监控数据反常系统按期上线灰度范围是 10% 的进线量。前三天看起来一切正常到了第四天监控大屏上的 P95 响应时长突然从预期的 3 秒以内飙升到 28 秒P50 也到了 11 秒。更尴尬的是对比上线前一周整体客服平均响应时长不降反升——AI 介入的会话比纯人工会话还要慢。整个团队当时是懵的。大模型生成慢可以理解但也不至于 28 秒。我第一反应是模型服务出了问题结果打开 GPU 监控显存占用正常推理服务日志里也没有明显的报错。接着查接入层日志发现大量请求卡在调用知识库检索的环节上迟迟没有把结果返回给下游。3.2 全链路日志定位检索环节吃掉了 80% 的耗时这里要夸一下我们当时坚持做全链路 trace 的决定。每个请求进来都会生成一个 trace_id从网关到检索到大模型到回写每跳都打耗时日志。用 trace_id 把单个慢请求的各个环节耗时拉出来看问题一目了然接入与预处理312ms会话上下文加载456ms知识库检索21.4s大模型生成等待6.8s工单回写289ms检索环节占掉了整条链路的 68%但真正的瓶颈还不止于此。因为检索超时下游的大模型一直在空等很多请求最终走到超时熔断触发降级逻辑又转回人工队列导致人工侧压力反而更大了。整个服务像得了肠梗阻前面堵住后面全饿着。3.3 根因分析三个叠加问题逐层往下挖根因有三个任何一个单独出现都不至于这么严重但叠加在一起就是灾难。第一是知识库切分太粗糙。我们最初为了省事把每篇文档按固定长度 1500 字切块有些大文档直接切成五六块但语义被切断了检索时召回的 Top20 片段里经常只有一半是真正相关的。于是系统做了多次重试和扩大召回范围的操作反而把延迟拉高。第二是向量检索没有走 ANN 索引。团队里有人图省事直接把所有知识分块用 BGE-M3 模型生成向量后用暴力计算余弦相似度的方式存进了向量库。测试环境只有几千条数据时看不出问题生产环境 3 万个分块每次查询都要全量计算一次相似度耗时随数据量线性增长21 秒就是这么来的。第三是缺少缓存层。用户问退货地址是什么运费谁承担这类高频问题时每一次都重新走完整检索链路完全不考虑把答案缓存下来。3.4 修复方案召回缓存 语义分块 ANN 索引升级我们花了一周半做了三项改造。第一项给检索加 Redis 缓存。把问题向量 Top20 召回结果作为 key-value 缓存起来key 是 query 的向量哈希value 是检索结果。命中率在常见问题上能到 40% 左右这些请求直接跳过向量库查询检索耗时降到 10ms 以内。核心代码其实非常简单def search_knowledge(query, top_k20): query_vec embed_query(query) cache_key kb:search: hash_vector(query_vec) cached redis_client.get(cache_key) if cached: return json.loads(cached) result vector_db.ann_search(query_vec, top_ktop_k) redis_client.set(cache_key, json.dumps(result), ex3600) return result第二项重新设计知识库切分策略。不再用固定字符长度而是按文档的章节结构切分标题、段落、列表各为一个候选块再通过一个简单的重叠策略保证上下文连贯性。每条知识块控制在 300 到 500 字语义完整度明显提升。第三项把向量库从暴力检索切到 HNSWHierarchical Navigable Small World索引。HNSW 适合这种千万级以内的稠密向量检索场景召回速度和召回率的平衡比较好。建立索引后单次检索耗时从秒级降到几十毫秒。3.5 修复后的实测数据三项改造上线后我们又做了三天的灰度对比知识库检索 P50从 21.4s 降到 96ms知识库检索 P95从 38s 降到 320ms整条链路 P95从 28s 降到 6.7s高频问题缓存命中率41.6%这个过程给我的教训是AI 客服的瓶颈往往不在AI而在它脚下的数据管道。知识库检索这种不起眼的模块恰恰决定了整个系统能不能跑起来。4. 坑二大模型推理排队效应高峰期一堵全堵4.1 现象提升低谷期正常高峰期曲线呈锯齿形修完检索问题后响应时长有了明显改善但第二个坑紧随而来。观测监控数据时发现一个诡异现象凌晨 2 点到早上 8 点的响应时长非常漂亮P95 在 3 秒左右一到上午 10 点以后就开始恶化P95 冲到 15 秒以上而且曲线不是平滑上升而是锯齿状——一会儿 4 秒一会儿跳到 20 秒再回落再跳升。这种锯齿形曲线在分布式系统里几乎是队列积压的标志性特征。请求不是均匀慢而是一批卡住、后续清空、再卡一批的节奏。我们立刻查了推理服务的请求队列长度和 GPU 利用率结果队列深度在高峰期平均积压了 40 多个请求GPU 利用率却只有 60% 左右。利用率不饱和但队列积压说明问题不在算力不够而在调度策略和单请求占用时间。4.2 根因同步阻塞 单一模型 max_tokens 劝退我们把单个慢请求的完整时间线拉出来发现推理服务一个请求的耗时分布是prefill读取输入 token1.2 秒decode逐字生成输出 token单 token 约 45ms。问题在于我们的 max_tokens 设置成了 1024而客服场景里大部分回复根本不需要 1024 个 token。举个例子用户问发货了没有模型实际需要的回复是您的订单已于今天下午发货物流单号是 SF1234567890预计 3 天内送达一共不到 50 个 token。但因为 max_tokens 设成 1024模型在生成完 50 个 token 后还会继续往下推直到碰到结束符才停止这个过程平均要生成 200 到 300 个 token每个 45ms光 decode 就吃掉 9 到 13 秒。更要命的是所有问题都走同一个 32B 大模型。无论问题是订单号码是什么还是帮我分析一下这个月所有异常退款的原因都占着同一块 GPU 资源。简单问题本来用 7B 模型 1 秒就能出结果结果被塞到 32B 模型的队列里跟着复杂问题一起排队。这就是高峰期一堵全堵的根源。4.3 四件事流式、超时熔断、动态 max_tokens、模型分级路由修复方案总共做了四件事按优先级排序。第一件事是开启流式输出SSE。把原来等模型全部生成完再一次性返回的接口改成先返回第一个 token再边生成边推送。用户端看到的效果是提交问题后 300ms 内出现正在输入的提示1 秒左右开始逐字出现回复。虽然后端总耗时没变多少但用户的感知响应时长大幅下降P95 体验从 15 秒变成了 2 秒以内的首字等待。第二件事是接入层加超时熔断。早期我们的设计是只要模型没返回就不掐断连接导致队列里堆积的请求只能干等。后来改成AI 回复链路总预算 5 秒超过 5 秒直接走降级——把问题转回人工队列同时给用户推一条正在为您转接专业客服的提示。这样即使模型服务抽风也不会无限拖垮用户体感。第三件事是动态 max_tokens。按意图类型给每个请求设定不同的生成上限物流查询、订单状态类上限 64退换货规则、政策咨询类上限 256需要生成多步骤说明的复杂问题上限 512。这个调整直接把单次推理的平均 decode 时长砍掉了 60%。第四件事是模型分级路由。在接入层加了一个意图分类器用轻量级模型实现判断问题的复杂程度后路由到不同规格的生成模型简单问答走 7B 模型复杂推理走 32B 模型。实测简单问题占了总进线量的 70%这部分请求的推理耗时从平均 6 秒降到 1.5 秒。4.4 参数配置参考贴一份我们最终使用的路由配置示例供参考route_rules: - intent_group: [order_query, logistics_query, refund_status] model: qwen2-7b-instruct max_tokens: 64 temperature: 0.1 timeout_ms: 3000 - intent_group: [return_policy, after_sale_rule, product_consult] model: qwen2-7b-instruct max_tokens: 256 temperature: 0.3 timeout_ms: 5000 - intent_group: [abnormal_complaint, multi_step_guide] model: qwen2-72b-instruct max_tokens: 512 temperature: 0.3 timeout_ms: 10000这套配置上线后高峰期推理服务队列深度从 40 降到 5 以内P95 端到端响应时长从 15 秒降到 4.5 秒。这一轮优化的核心思路不是堆 GPU而是让每个请求用最合适的资源、最短的路径、最少的 token 完成任务。5. 坑三多轮会话的上下文雪崩聊得越多系统越慢5.1 现象连续追问四五轮后接口延迟明显上升第二个坑修完后服务整体性能已经达到预期。但我们在做用户访谈时收到一条高频反馈AI 客服在第一轮回复很快但只要用户连续追问几轮回复速度就会肉眼可见地变慢有时候甚至直接超时。我让后端顺手拉了一下会话轮数和响应时长的对应关系数据非常扎心第 1 轮平均响应 1.8 秒第 3 轮变成 3.6 秒第 5 轮直接飙升到 9.7 秒第 7 轮以后基本没有低于 8 秒的。而且这个趋势在 32B 模型上比 7B 模型明显得多。5.2 根因把所有历史对话原样塞进 Prompt当时的多轮会话实现思路很粗暴每次收到用户新消息就把这个会话里所有的历史消息按时间顺序拼接起来连同检索到的知识片段一起塞进 Prompt。这个逻辑在测试环境跑两轮没问题但真实用户会连续追问很多轮历史消息越来越长Prompt 的 token 数从第 1 轮的 800 左右涨到第 6 轮的 6000 多个别极端会话甚至破万。大模型推理的耗时和输入 token 数不是线性关系而是近似二次方的关系——prefill 阶段要处理所有输入 token输入越长首 token 时间越长。加上上下文一长模型还容易分心把之前历史里无关的信息也当成重点回复质量反而下降。更不用说每次请求还要把几 K 的上下文通过网络传给推理服务传输开销也不小。5.3 解决思路滑动窗口 历史摘要 会话回收我们没有直接砍历史记录因为多轮上下文确实是语义理解的基础。我们做了三个动作。第一个是滑动窗口只保留最近 4 轮对话内容作为上下文更早的历史不再拼接进 Prompt。客服场景里绝大多数问题只需要最近一两轮就能理解清楚4 轮已经覆盖了 95% 的场景。第二个是历史摘要如果用户确实聊了很多轮我们把前面超过 4 轮的历史压缩成一段摘要比如用户已确认收货正在处理退款申请。这个摘要在会话空闲时异步生成不走用户请求链路避免额外耗时。第三个是会话回收给每个会话设置 60 分钟的无交互过期时间过期后清空会话上下文下次用户再来时开新会话。核心实现逻辑def build_prompt(session_id, current_query, knowledge): session session_store.get(session_id) recent_rounds session.get_recent_rounds(max_rounds4) summary session.get_summary() if len(session.history) MAX_ROUNDS and not summary: # 异步生成历史摘要当前先丢弃过旧历史 task_queue.enqueue(generate_summary, session_id) return f 会话摘要:{summary} 最近对话: {recent_rounds} 当前问题:{current_query} 参考资料:{knowledge} 5.4 数据变化与体验影响这套改造上线后的数据变化很直观上下文平均 token 数从 8200 降到 1900第 5 轮响应 P50从 9.7 秒降到 2.2 秒第 7 轮响应 P50从 13 秒降到 2.8 秒首 token 时间 P95从 6.1 秒降到 1.2 秒用户侧感知的变化是连续追问时回复速度不再逐轮衰减整个对话过程的节奏感稳定了。我们当时差点因为多轮会话这个看似高级的功能把整条性能拖垮后来才想明白多轮会话的目的是理解用户意图而不是把历史当传家宝一样全背在身上。6. 上线三个月后的数据复盘2 分半是怎么达成的6.1 三个月的分位数指标变化三个坑全部填平后我们把 AI 客服的进线流量从 10% 逐步放大到 100%。下面这张表是去年 Q1 到 Q3 的月度数据汇总指标上线前基线第 1 个月第 2 个月第 3 个月P50 响应时长23 分钟8 分钟45 秒18 秒P95 响应时长50 分钟24 分钟5 分钟2 分 30 秒P99 响应时长2 小时45 分钟12 分钟4 分钟人工介入率100%68%45%35%CSAT 满意度86%81%83%87%这里要说明一个容易产生误解的点标题里说的2 分半是指端到端的 P95 响应时长。这个值并不是纯 AI 推理链路耗时——AI 处理链路本身现在已经稳定在 2 秒以内但加上客服平台工单流转、异常兜底检查、部分场景需要人工复核后再放行端到端就到了 2 分半。从用户体验角度看2 分半内收到一条有效回复和过去等 50 分钟相比完全是两个世界。6.2 链路各环节耗时占比最终版三个月优化完一条消息从用户发出到 AI 回复各环节耗时分布是环节耗时占比接入与预处理180ms10.2%会话上下文加载260ms14.8%知识库检索重排320ms18.2%大模型生成首 token890ms50.6%工单回写110ms6.2%合计1.76s100%模型生成仍然是大头但已经从最初的不可控变成了可控的 1 秒内。知识库检索从 21 秒压到 320ms是进步最大的环节。6.3 遗留问题和下一步方向数据好看不代表没有遗留问题。目前人工介入率还有 35%主要集中在这几类场景用户投诉情绪激烈、问题涉及跨部门协调、需要操作多个系统才能解决的复杂售后。这部分靠当前的 RAG 方案很难完全覆盖。我们下一步的重点有两个方向一个是把人工客服的历史对话记录做二次挖掘把它们转化成新的知识库条目让 AI 越来越懂我们业务里的边缘场景另一个是引入更多主动式服务比如物流异常时 AI 先检测到主动推送处理方案而不是等用户来问。响应时长的优化只是第一步接下来要比拼的是解决问题本身的效率。上线三个月说点实在的做这个项目的过程中有几件事是我现在回想起来依然会觉得当时如果早点明白就好了的。第一件AI 客服的性能优化是一套系统性工程不是换个大模型就能解决。三个坑分别卡在基础设施、推理服务和应用逻辑上任何一个没处理好用户体验都会被打回原形。第二件数据口径和全链路 trace 一定是在项目第一天就要落地的东西。我们后期所有的排查能这么快定位到问题靠的就是这套底子。第三件压测场景必须贴近生产环境的数据规模和分布否则测出来的基线只是自我安慰。其实这个项目最大的收获不是把 50 分钟压到 2 分半而是让团队形成了感知问题、拆解链路、量化验证的做事习惯。AI 客服这个领域发展很快今天用到的模型、框架可能半年后就过时了但只要这套方法在后续任何时候出问题我们都有底气把它拉回正轨。