客服自动回复的“首条延迟”该压到多少？一次速度与拟人化的取舍

做客服自动回复系统团队最初的指标很朴素把首条回复延迟压短。链路拆完、逐段优化之后我们确实做到了全链路一秒内出话。但上线后的对话数据给出了相反的结论回得太快的对话反而更早终结。这篇是一次速度与拟人化取舍的工程复盘。一、全链路拆解压进一秒在技术上完全可行一套典型的自动回复链路由四段组成每段都有明确的优化空间消息捕获轮询聊天窗口变化拿到有新消息事件。500ms 的轮询间隔意味着平均约 250ms 的等待换成事件驱动监听后可压到 50ms 以内。内容读取只有截图可用时走 OCR一张聊天截图约 300-500ms能直接读控件文本则只需几毫秒这一步的选型差距比换模型还大。LLM 生成带上下文的短回复首 token 通常在 300-800ms换更小的模型、砍 prompt 长度、改流式输出都还有余量。窗口回填模拟键盘输入按 20ms/字符计一条 50 字的回复要 1 秒改成剪贴板粘贴加回车可压到 100ms 以内。逐段做完整条链路一秒内出话在工程上完全可行。这套优化花了两周最后却发现真正的问题不在链路里。二、实测数据秒回是机器特征不是服务质量有位买家 23:47 发来一句这个多少钱能便宜点吗。一秒后他收到一条带完整报价、阶梯价与售后说明的回复。他的下一句是机器人吧这条对话没有再继续。复盘时我们回放了一批同类 case模式相当一致响应在一两秒内、且首条就是完整答案的对话买家发出第二句的比例明显偏低。原因不难理解——真人客服不可能秒回。收到消息、看清问题、想出答案、打字发出这件事存在生理下限秒回等于把我不是人写在对话里。更麻烦的是完整答案本身也在帮倒忙价格、阶梯、售后一次给全买家问一句得到一页内容接话的钩子全被堵死了对话自然就在收到报价这一步结束。后来我们做了对照两个版本各跑数千条真实询盘A 版秒回加完整答案B 版先延迟 8-15 秒、先回一句在的稍等隔几秒再发正式答案统计口径就一条——买家是否发出第二句话。结果 B 版的对话继续率明显更高差距大到不需要显著性检验来说服任何人。买家在等待里完成了一次心理确认对面有人在。而在的稍等恰好还原了真人客服接到消息后的第一反应。三、提速的正道砍工程段而不是压模型这里有一个常见误区值得纠正想让响应更快性价比高的方向往往不是压 LLM 推理延迟——每次调用省一两百毫秒已经非常吃力——而是砍链路里的工程段。模型换代的收益是线性的几十毫秒工程段砍掉的是数量级的等待。同理OCR 换文本读取省几百毫秒剪贴板替换逐字输入省一秒这些不起眼的工程段加起来往往比换任何模型都值钱。以我们自身为例。早期版本里核心逻辑是一个 35000 行的单包结构任何一处改动都要全量重编译一次 164 秒。调延迟参数时改一行等三分钟没人有耐心多试几组所谓调优实际上是在猜。后来把纯逻辑核从工程中拆出单独增量编译同样改一行只要 3.4 秒——164 除以 3.448 倍的差距。改完到验证的循环从泡杯咖啡变成一眨眼调参才真正变成调参。这件事的意义不在编译本身开发迭代速度决定了响应速度优化的上限。改一次配置要等三分钟你只会试一次三秒就能见效你才会把延迟从 500ms、300ms、150ms 一路试下去找到对话继续率的拐点。很多团队的延迟优化做不动瓶颈不在模型而在缺少一条能快速验证的反馈回路。四、最终取舍延迟不是一个数而是一张分层表回到标题的问题首条延迟该压到多少我们的答案是故意不压。首条回复拟人优先保留 8-15 秒的自然延迟并拆成在的稍等加正式回答两段后续消息则尽快回因为对话进行中真人客服也是越聊越快的。策略固化为分层配置latency_policy: # 首条回复拟人优先保留打字与思考时间 first_reply: delay_s: [8, 15] # 随机区间避免固定值 ack_message: 在的稍等 answer_delay_s: [4, 10] # 正式答案再隔一段 follow_up: delay_s: [2, 6] # 对话进行中快但留间隔 long_question_extra_s: [1, 3] # 长问题加读题时间 long_answer: simulate_typing: true # 长回复按字符数模拟输入耗时 cps: 8 # 每秒约 8 字接近真人手速对应到什么该快、什么该慢我们内部用一张表对齐认知环节快 / 慢目标区间理由捕获、读取、生成、回填快一秒内纯机器耗时藏在延迟区间里首条回复慢8-15 秒真人不可能秒回拟人优先对话中的追问快2-6 秒真人越聊越快跟上节奏长答案发出中按字数模拟打字长文本瞬间贴出明显违和这套分层的背后只有一条原则回复节奏对齐真人客服的工作节奏而不是对齐机器的性能上限。机器该快的部分全部压短作为内部耗时藏起来机器不该快的部分——人对人的反应时间——明确保留出来。上线后这套分层没有再动过技术指标上它变慢了业务指标上它活了下来。另外两点经验值得记下。其一延迟区间必须是随机的固定 10 秒和固定 1 秒一样是机器特征真人的响应时间天然带着抖动。其二深夜时段可以适当放宽区间凌晨咨询的买家对人还在不在更敏感一段符合作息的等待反而更像真人在岗。如果只记住一件事那就是秒回不是能力是特征。参考文章延迟分层里用到的报价组织与询盘应答节奏两篇文章有更细的展开微信 AI 客服价格与报价拆解 讲报价内容如何组织售前咨询自动化询价砍价场景的应答策略 讲询价砍价的应答节奏与本文的延迟分层放在同一套策略里看会更完整。