RAG-准确度提升之-前置过滤（3）-A/B测试 T_MULTI / T_MIN / K_MAX微调

目录

• 一、总体原则（先说清楚，避免踩雷）
• 二、实验分层设计（这是关键）
  • 1️⃣ 实验单元
  • 2️⃣ 只做「单变量 + 小范围」实验
    • ❌ 不要这样
    • ✅ 正确方式（推荐顺序）
• 三、具体 A/B 方案设计（可直接用）
  • 阶段 1：T_MIN 主锚点阈值实验
    • 实验桶设计
    • 核心假设
  • 阶段 2：K_MAX 语义发散实验
  • 阶段 3：T_MULTI 微调（成熟后）
• 四、必须采集的数据（没有这些，A/B 是假实验）
  • 1️⃣ 每条 query 的结构化日志
  • 2️⃣ 质量反馈信号（至少一个）
    • 推荐优先级
  • 3️⃣ 聚合指标（实验看这个）
    • 核心 4 个指标（必须）
• 五、怎么用数据“选参数”（非常关键）
  • 决策曲线（你一定要画）
    • 1️⃣ T_MIN vs 成功率
    • 2️⃣ K_MAX vs 错误率
  • 推荐决策规则（可写进 SOP）
• 六、风险控制（生产一定要有）
  • 1️⃣ 熔断规则（自动）
  • 2️⃣ 高风险 query 强制不进实验
  • 3️⃣ 低流量场景延长实验周期
• 七、一个成熟系统会做的事（你已经到这一步了）
  • • 自动参数建议
• 八、一句话总结（你可以直接对内讲）

下面给你一套可以直接在生产落地的线上 A/B 调参方案，不是“实验室方案”，而是不会伤业务、能持续跑、能逼近最优点的工程做法。
我按 架构 → 实验设计 → 数据采集 → 指标 → 决策规则 → 风险控制 六部分讲。

---

一、总体原则（先说清楚，避免踩雷）

1. 只调路由参数，不动模型

   • 只 A/B：T_MULTI / T_MIN / K_MAX
   • MiniLM / RAG / LLM 本身不变
     → 否则因果关系不可解释

2. 不是追求“最高自动化率”

   • 目标是：
     在可接受错误率下，最大化自动化成功率

3. 高风险标签永远不进 A/B

   • 命中 HIGH_RISK_LABELS → 强制 LLM
   • 不作为实验变量

---

二、实验分层设计（这是关键）

1️⃣ 实验单元

A/B 单位：query 级别（不是用户）

hash(query_id) % 100 → 实验桶

避免：

• 用户跨桶
• 会话污染

---

2️⃣ 只做「单变量 + 小范围」实验

❌ 不要这样

同时调 T_MULTI、T_MIN、K_MAX

你会完全不知道哪个参数在起作用。

---

✅ 正确方式（推荐顺序）

阶段 1：固定 K_MAX，调 T_MIN
阶段 2：固定 T_MIN，调 K_MAX
阶段 3（可选）：微调 T_MULTI

---

三、具体 A/B 方案设计（可直接用）

阶段 1：T_MIN 主锚点阈值实验

实验桶设计

Bucket	T_MIN	占比
A（基线）	0.78	60%
B	0.75	20%
C	0.80	20%

T_MULTI = 0.68
K_MAX = 4

---

核心假设

• B：自动化率 ↑，错误率可能 ↑
• C：准确率 ↑，自动化率 ↓

---

阶段 2：K_MAX 语义发散实验

（在阶段 1 选定最优 T_MIN 后）

Bucket	K_MAX	占比
A（基线）	4	60%
B	3	20%
C	2	20%

---

阶段 3：T_MULTI 微调（成熟后）

Bucket	T_MULTI
A	0.68
B	0.66
C	0.70

---

四、必须采集的数据（没有这些，A/B 是假实验）

1️⃣ 每条 query 的结构化日志

{
  "query_id": "uuid",
  "bucket": "A",
  "T_MULTI": 0.68,
  "T_MIN": 0.78,
  "K_MAX": 4,
  "top_sim": 0.81,
  "S_size": 2,
  "labels": ["退款", "售后"],
  "route": "rag | llm | human",
  "answer_type": "auto | llm",
  "latency_ms": 320
}

---

2️⃣ 质量反馈信号（至少一个）

推荐优先级

1. 显式用户反馈

   • 👍 / 👎

2. 隐式行为

   • 是否追问
   • 是否转人工
   • 是否重复提问

3. 业务闭环

   • 销售是否转化
   • 工单是否被退回

---

3️⃣ 聚合指标（实验看这个）

核心 4 个指标（必须）

指标	定义
Auto Rate	RAG 自动回答占比
Success Rate	自动回答后未被否定
Escalation Rate	自动 → LLM / 人工
Error Rate	自动回答被判错

---

五、怎么用数据“选参数”（非常关键）

决策曲线（你一定要画）

1️⃣ T_MIN vs 成功率

T_MIN ↑
  ├─ 成功率 ↑
  └─ 自动化率 ↓

你要找的是：

成功率不再显著提升，但自动化率开始快速下降的拐点

---

2️⃣ K_MAX vs 错误率

K_MAX ↑
  ├─ 自动化率 ↑
  └─ 错误率 ↑（通常是指数）

错误率开始陡增的位置，就是 K_MAX 上限

---

推荐决策规则（可写进 SOP）

在 Error Rate < X% 的前提下，
选择 Auto Rate 最大的参数组合

例如：

Error Rate ≤ 5%

---

六、风险控制（生产一定要有）

1️⃣ 熔断规则（自动）

if error_rate_5min > threshold:
    rollback_to_baseline()

---

2️⃣ 高风险 query 强制不进实验

if label in HIGH_RISK_LABELS:
    skip_ab_test()

---

3️⃣ 低流量场景延长实验周期

• 日活 < 10k
• 实验至少跑 7–14 天
• 否则统计显著性不足

---

七、一个成熟系统会做的事（你已经到这一步了）

自动参数建议

每天离线分析：
  - T_MIN vs 成功率曲线
  - S_size vs 错误率
  - 给出推荐参数

但：

参数是否上线，永远由人确认。

---

八、一句话总结（你可以直接对内讲）

T_MULTI / T_MIN / K_MAX 不是模型参数，而是业务风控阀门。
A/B 的目的不是“调准”，而是找到“在可接受风险下的最大自动化点”。
没有数据采集的调参，都是拍脑袋。

如果你愿意，下一步我可以帮你把这套方案压缩成一页《线上参数实验 SOP》，直接给工程 / 产品 / 运营一起用。