从需求到上线：一个会话 sticky 争议的完整复盘

阶段一：业务需求与技术矛盾
市场团队要求对比 DeepSeek-V3 与升级版 V4 在客服场景的转化率差异，但提出两个看似冲突的核心需求：
1. 数据科学性要求：流量分配必须完全随机，确保AB测试结果的统计显著性，任何定向分流都会引入偏差
2. 用户体验一致性：同一会话中禁止切换模型版本，避免用户感知到回答风格突变（如V3倾向简短回复，V4偏好详细解释）

经过技术团队与产品部门的3轮会议讨论，确认矛盾本质在于：
- 统计学要求每个请求独立随机（i.i.d）
- 交互设计需要维持会话上下文连贯性
- 最终达成共识：优先保障用户体验，通过技术手段控制数据偏差

阶段二：方案选型与缺陷预判
技术组提出三种实现路径并组织压力测试：

方案A（纯用户级哈希）
• 实现：根据user_id做一致性哈希分配模型
• 优点：零延迟开销，无需状态维护
• 缺陷：
- 用户主动刷新页面会导致模型切换（实测发生概率22%）
- 无法区分同一用户的多会话场景（如同时开多个客服窗口）

方案B（会话级cookie）
• 实现：通过cookie维持会话级绑定，有效期2小时
• 优点：会话连续性保障最好（中断率仅3%）
• 缺陷：
- 每个请求需验证会话状态，增加15ms延迟
- 老用户过度代表问题（长期用户始终停留在旧模型）

折中方案（首次哈希+会话继承）
• 实现：
1. 首次请求按user_id哈希分配模型
2. 通过Redis记录分配决策（TTL=2h）
3. 后续请求优先读取Redis记录
• 改造点：需在API网关层新增版本标记透传逻辑

关键指标实测（生产环境采样7天）
通过10%流量灰度测试收集数据：

方案	会话中断率	P99延迟增幅	数据偏移风险	开发成本
纯用户哈希	22%	0ms	低	1人日
全会话sticky	3%	15ms	高	3人日
折中方案	5%	8ms	中	2人日

阶段三：工程落地难点
实际部署时发现三个关键问题：

1. DeepSeek路由层改造
2. 原有无状态架构需支持版本标记透传

3. 解决方案：

   • 在Nginx层注入X-Model-Version头
   • 同步写入Redis集群（key格式：abtest:{user_id}:{session_id}）
   • 采用CRC32压缩键值长度（减少30%内存占用）

4. 故障回退机制

5. 当sticky会话对应模型实例不可用时：
   • 优先尝试同版本其他实例（重试2次）
   • 最终回退到用户哈希分配（非强制路由）

6. 监控发现回退触发率0.7%，主要发生在模型滚动发布期间

7. 监控埋点优化

8. 区分三类请求的独立指标：
   • 首次分配请求（占总流量42%）
   • 继承会话请求（占55%）
   • 强制回退请求（占3%）
9. 关键发现：继承请求平均token消耗比首次请求高18%，说明长会话用户更倾向深入交流

阶段四：伦理与风控
为避免技术方案引发合规风险，采取以下措施：

• 用户告知机制
- 在对话开场白增加AB测试说明（经法务审核）
- 提供/switch_model指令允许用户主动退出

• 数据纠偏设计
- 强制5%流量始终随机分配（用于校准数据）
- 每日自动检测样本分布（卡方检验p值<0.05时告警）

• 敏感场景熔断
当检测到以下情况时立即解除sticky绑定：
- 讨论医疗/法律等高风险话题（关键词匹配）
- 用户情绪负面（情感分析score<-0.6）
- 单会话超过50轮交互（防数据垄断）

---

技术实现细节

DeepSeek 路由层改造
选择Nginx + Lua脚本方案而非Service Mesh，核心考虑：
1. 性能基准：
- Lua处理单请求平均0.8ms
- Envoy代理方案需3.2ms
2. 关键逻辑流：

graph TD
  A[请求到达] --> B{已有X-Model-Version头?}
  B -->|否| C[按user_id哈希分配]
  C --> D[写入Redis并设置TTL]
  B -->|是| E[验证版本可用性]
  E -->|可用| F[路由到指定模型]
  E -->|不可用| G[降级到哈希分配]

性能优化实践
通过三项措施将额外延迟控制在8ms内：
1. Redis管道化
- 将GET/SET操作合并为Pipeline
- 平均延迟从12ms降至5ms
2. 本地缓存层
- 在Nginx worker内维护LRU缓存
- 命中率85%（有效减少Redis查询）
3. 零拷贝日志
- 使用共享内存缓冲区异步写日志
- 避免同步I/O阻塞请求线程

监控指标体系
搭建分层监控看板：
1. 基础设施层
- Redis集群命中率（警戒线<95%）
- Nginx错误码分布（499/502重点监控）
2. 业务质量层
- 会话完成率（目标>90%）
- 平均对话轮次（V3=4.2轮, V4=5.7轮）
3. 实验有效性层
- 每日模型分布差异（Δ<5%）
- 用户反馈情感分析（V4正面评价+12%）

---

检查清单：你的AB测试是否需要会话一致？

评估前需明确四个维度：
- [ ] 业务特性
是否存在多轮对话强依赖？例如：
• 心理咨询（需保持共情一致性）
• 技术排障（需维持排查逻辑连贯）
• 购物导购（避免推荐策略跳跃）

• [ ] 技术成本
  是否具备以下能力？
  • 会话状态存储（Redis/Memcached）
  • 路由层改造灵活度
  • 延迟预算余量（建议<15ms）

• [ ] 数据风险
  能否应对这些偏差？
  • 老用户样本过代表（需分层抽样）
  • 长会话数据污染（设置轮次上限）
  • 模型冷启动影响（预热期除外）

• [ ] 终止机制
  是否预设退出条件？例如：
  • 关键指标显著退化（t检验p<0.01）
  • 用户投诉率突增（3σ原则检测）
  • 系统资源超负荷（CPU>80%持续5min）

---

边界条件与替代方案

应放弃sticky的场景
1. 短期快闪测试
- 测试周期<48小时
- 单会话平均交互<3轮
- 示例：促销活动话术优化

1. 无状态交互场景
2. 每次问答完全独立

3. 如：天气查询、翻译服务

4. 资源严格受限时

5. 无法承受额外10ms延迟
6. 无冗余Redis集群资源

备选实施方案对比
1. 客户端存储方案
- 优点：零服务端压力
- 缺点：
* 清除浏览器数据导致实验污染
* 无法区分多设备登录

1. JWT轻量会话
2. 优点：无需中央存储

3. 缺点：

   • 模型切换需重新签发令牌
   • 无法实时终止实验

4. 混合渐进方案

5. 实现：
   1. 会话前10轮固定模型
   2. 后续按比例混合响应
6. 适用：教育类场景的渐进式教学

---

最终决策建议
对于大多数对话式AI场景，推荐采用折中的首次哈希+会话继承方案。该方案在用户体验与数据质量间取得平衡，实施时需注意：
1. 设置合理的会话TTL（建议2-4小时）
2. 强制保留小比例随机验证流量
3. 建立实时监控和熔断机制

下一步可针对具体业务场景细化异常处理策略，例如电商客服需特别关注订单号关联的会话连续性保障。