买家 A 问的尺码回答发进了买家 B 的窗口或者两个人同时咨询各自的上下文混到了一起。这种事发生一次就够伤信任。串聊通常不是模型认错了人而是系统在会话识别这一环出了偏差——先看成因再定排查顺序最后落到设计上。## 三种成因症状不一样**会话标识复用。**系统给每个会话分配一个标识用来区分这是谁在问。标识取错了比如拿客户昵称当标识、同一客户换了入口后标识没更新两个客户就会落进同一个槽位。**并发写冲突。**两个客户同时说话程序同时处理两条消息共享的上下文没过关后一条把前一条覆盖掉了。**缓存没及时清。**上一轮的内容还留在缓存里新会话开始时没有重置机器就接着别人的上文往下答。**怎么快速区分。标识复用是稳定的一测就复现并发是偶发的两条消息挨得很近才出现缓存问题的特征是重启后正常、跑一段时间又犯。三类分清楚查日志才有方向不然容易把偶发问题当成配置问题反复改。## 排查顺序从最近一次串聊往下查头一步复现。**用两个测试号同时发不同的问题看能不能再现。能稳定复现的问题在标识或者设计上不用往偶发方向想。**第二步查日志里的会话标识。**把两条消息的标识打出来对比标识相同是复用问题标识不同但回答串了就看并发和缓存。**第三步看两条消息的时序。**时间戳挨得越近越要怀疑并发写间隔很久还串基本是缓存没清。**第四步查入口有没有混用。**同一个客户从单聊、群聊、不同应用进来系统有没有当成同一个会话这是标识设计不严的常见来源。**第五步看重启后的表现。**重启就好、过一阵又串说明是状态累积重启也不管用就得回头改标识的生成逻辑。**日志里看不到标识怎么办。说明这一层根本没打日志先把它补上再往下查对着不完整的日志改配置多半是在猜。## 隔离设计的四个要点标识要精确到会话。**用应用、会话、客户这几段组合生成标识别拿客户昵称当标识——昵称会重名也区分不开同一个人在两处的对话。**上下文按会话单独存放。**每个会话一份读完就释放别放在全局变量里这一步做对并发冲突自然少一半。**新会话先清状态。**会话开始、客户换了跟进人、客户被重新加回这几个时刻都要重置上下文避免机器接着旧内容回答。**同一条会话的写操作排队。**先来后到串行处理别让两条消息同时改同一份上下文。**给异常留告警。**会话标识冲突、上下文长度异常增长这类信号能提前报出来比等客户投诉早。**群聊和单聊分开管。群里多人共用一个会话标识要能区分发言人不然同一个群里两个客户的问题也会互相串。## 出过串聊之后怎么收尾先确定影响到谁。**从日志里找出串聊的时间段和涉及的会话把范围圈清楚后面的动作才有针对性。**该更正的就更正。**给受影响的客户发一条说明和正确的回答别当没发生如果串聊内容涉及价格、时效更正就更要紧。**再改设计别只擦表面。**把成因记下来是标识问题、并发问题还是缓存问题对应改哪一处。只把缓存清一遍不解决根因过几天还会再来。**过几天回访一次。**更正之后隔两三天问一句还有没有别的问题确认客户那边没有余留的误解这件事才算收干净。用按会话维度管理上下文和日志的本地方案每条消息的会话标识、上下文变化都能查到串聊排查不用靠猜。## 参考文章- 自动回复的并发与延迟设计- 回复超时与重试的处理方法
