缓存策略探测实验 --- 综合执行方案
📌 摘要
- 目标：确定算优优和移动云的 DeepSeek API 代理的实际缓存机制（前缀匹配 / 内容哈希 / 固定响应 / 混合）
- 方案：三专家协作设计了从信号验证→机制区分→边界映射→鲁棒性测试的五阶段递进式实验流水线
- 预计 API 调用量：~400 次/端点
- 预计总耗时：~42 分钟 + TTL 等待时间/端点
- 最简判定路径：仅需 4 个探针（C + D + A + E）即可在 ~20 分钟内确定缓存策略
- 关键保障：首次在测试方案中引入了 Exact-Minus-1 自动检测、信源切换机制、内容域隔离、Holm-Bonferroni 多重比较校正
🎯 核心结论卡片
| 项目 | 内容 |
|---|---|
| 方案评级 | 🟢 可执行 --- 三专家输出已对齐，工程师可直接按方案实施 |
| 覆盖假设数 | 8 种（H0-H8），含 Bayesian 先验 |
| 探针类别 | 7 大类（A-G），含三级子探针，覆盖全部区分空间 |
| 判定标准 | 量化矩阵 + 三信源（cached_tokens 0.6 / 延迟 0.3 / 计费 0.1) |
| 统计保障 | n≥5, 95% CI, Cohen's d, Holm-Bonferroni, 五级置信度体系 |
| 最强区分探针 | C（后缀微调）+ D（内容重排序），联合可唯一确定 5 种假设 |
1. 各成员核心结论
🔍 产品评审员（实验架构）
- 核心判断 ：test-V4 的根本错误在于未验证信号真实性就直接信任
cached_tokens。本方案将实验重构为五阶段递进流水线，Phase 1（信号验证）是整个实验的入口门控------如果cached_tokens被证伪，后续实验自动切换到延迟信源模式。 - 关键创新：8 种假设空间的 Bayesian 先验建模；内容域隔离作为架构硬约束（零词汇重叠）；三大不可区分假设对的透明度声明；三种结论（内容哈希/前缀/无缓存）对应的测试工具架构重构原则。
🔧 调查员（探针设计）
- 核心判断 ：设计了 7 大类探针（A-G），每类含子探针，覆盖从基线验证到 TTL 衰减的全部维度。核心设计亮点是 DOMAIN_{CATEGORY}_{UUID} 内容域标记机制，完全解决了 test-V4 的跨场景污染问题。最简判定流程仅需 C + D + A + E 四个探针即可在 ~20 分钟内确定缓存策略。
- 关键创新：统一语料库（P1-P5 五个独立段落，各 ~100-120 tokens），所有探针通过组合这些段落构造，既保证了内容可复用性又确保了不同探针的隔离。G 类 TTL 探针使用独立"播种-探测"对，每个时间间隔的用户消息不同，解决了"探测请求重新填充缓存"的历史缺陷。
✅ QA 专家（判定标准）
- 核心判断 ：制定了从原始 API 响应到最终判定结论的完整通路。核心贡献是三张量化判定表（cached_tokens 矩阵 + 响应时间矩阵 + 综合判定矩阵），五级置信度体系，以及 Exact-Minus-1 自动检测函数的完整伪代码。任何工程师拿到这份文档都可以独立判断探针结果。
- 关键创新：置信度分级不是简单的 PASS/FAIL，而是 A→F 五级（A≥95% / B 80-95% / C 60-80% / D<60% / F 无法判定），每级有 8 个硬性条件（p 值、d、n、CV、离群率等）。同时考虑了 8 类边界情况（负载均衡多实例、极短 TTL、max_tokens 干扰、版本漂移等）。
2. 方案核心架构（三专家输出整合）
2.1 五阶段流水线
Phase 0: 信号源盘点 (前置) ← 产品评审员设计
├─ 盘点 cached_tokens / 延迟 / 计费三大信源
└─ 输出：信号清单 + 信噪比预估
↓
Phase 1: 信号真实性验证 (门控) ← QA 专家制定判定标准
├─ 独立性探针：完全无关内容是否也有 cached > 0？
├─ 一致性探针：cached 增长与延迟下降是否同步？
└─ 判定：信源可信 → Phase 2 / 不可信 → 切换信源 → Phase 2
↓
Phase 2: 缓存机制区分 (核心) ← 调查员设计具体探针
├─ C 类探针(后缀微调) → 区分 PREFIX vs HASH
├─ D 类探针(内容重排序) → 区分 HASH 粒度
└─ 分叉到 Phase 3a (HASH) 或 3b (PREFIX) 或 3c (TTL)
↓
Phase 3: 边界映射 (细化) ← 调查员设计具体探针
├─ 3a: HASH 敏感度/序列化格式/长度边界/碰撞概率
├─ 3b: PREFIX 分叉点精度/中断规则/Breakpoint/最小匹配
└─ 3c: TTL 衰减曲线 (独立播种-探测对)
↓
Phase 4: 鲁棒性测试 (收尾) ← 产品评审员设计
└─ 并发写入 / 缓存容量 / 大载荷 / 跨模型隔离 / 异常恢复2.2 假设空间与先验
基于 4 份 test-V4 测试报告，各假设的初始信念：
| 假设 | P(假设) | 关键支持证据 |
|---|---|---|
| H1: 固定响应字段 | 0.45 | exact-minus-1 跨所有场景恒定 |
| H2: 内容哈希缓存 | 0.30 | Report D v4-pro 固定 806 |
| H3: 前缀匹配缓存 | 0.10 | different_system 假阳性与此矛盾 |
| H0: 无缓存 | 0.05 | 与 cached_tokens > 0 矛盾 |
| H4-H8: 其他 | 0.10 | 均匀分配 |
2.3 最简判定流程（仅需 4 个探针，~20 分钟）
1. 探针 C（后缀微调）: cached ≈ PREFIX长度？
├─ 是 → H3 (前缀缓存) 确认 ✓
└─ 否 → 继续
2. 探针 D（内容重排序）: cached > 0？
├─ 是 → H4 (段落哈希) 确认 ✓
└─ 否 → 继续
3. 探针 A（全同请求）: response.id 重复？
├─ 是 → H5 (HTTP响应缓存) 确认 ✓
└─ 否 → 继续
4. 探针 E（不可见字符）: cached ≈ 插入位置？
├─ 是 → H2 变体
└─ 否 → H1 (固定响应) 确认 ✓3. 判定标准速查（来自 QA 专家）
3.1 核心阈值
| 判定项 | 阈值 | 说明 |
|---|---|---|
| 缓存命中（cached_tokens） | C ≥ max(10, 0.05×P) 且 C ≈ C̄（≤2σ） | 量级 + 一致性双条件 |
| 缓存命中（响应时间） | T ≤ 0.33 × T_base | 三次以上测量中位数 |
| Exact-Minus-1 检测 | 所有探针满足 abs(C - (P-1)) ≤ 5 |
自动标记 FIXED |
| 阴性对照阈值（P5） | r > 0.10 → 实验作废 | 跨场景污染检测 |
| 离群值检测 | Modified Z-Score (MAD) ≥ 3.5 | 20%+离群率 → HIGH_VARIANCE |
| 显著性水平 | α = 0.05, Holm-Bonferroni 校正 | 8 探针 → 调整后阈值 |
| 最小迭代次数 | n ≥ 5（推荐 10） | n ≤ 2 标记 INSUFFICIENT_DATA |
3.2 五级置信度体系
| 级别 | 置信度 | 条件 |
|---|---|---|
| A | ≥ 95% | 所有探针一致，p < 0.05 (校正后)，d ≥ 0.8，n ≥ 10，CV < 20%，跨时间/跨 Key 可复现 |
| B | 80-95% | 多数探针一致，p < 0.05 (校正后)，d ≥ 0.5，n ≥ 5，允许 1-2 个可解释异常 |
| C | 60-80% | 部分探针矛盾需额外验证，或 n=5 导致 CI 较宽 |
| D | < 60% | 关键探针矛盾未解决，跨时间不可复现 |
| F | 无法判定 | 双信源均不可靠，或 API 行为随时间显著变化 |
3.3 三级证据权重
| 信源 | 权重 | 获取难度 | 信噪比 |
|---|---|---|---|
cached_tokens 字段 |
0.6 | 直接 | 未知（Phase 1 验证） |
| 响应时间 | 0.3 | 直接（需基线校准） | 中（受网络抖动影响） |
| API 计费数据 | 0.1 | 间接（需 Dashboard 查询） | 高（但获取不稳定） |
4. 探针污染防护（本方案的核心创新）
| 防护层次 | 机制 | 对应 test-V4 缺陷 |
|---|---|---|
| 内容域隔离 | 每个 Phase 使用独立语料领域（如 Phase1=动物学，Phase2=法国历史），词汇零重叠 | #1 CORPUS 重叠、#4 跨场景污染 |
| 探针级 UUID 标记 | 每个探针使用 DOMAIN_{CATEGORY}_{UUID} 唯一前缀，确保缓存键不交叉 |
#5 UUID 前缀不足 |
| Phase 间冷却 | Phase 间 ≥ 3 秒（或 ≥ TTL×2），阴性对照在每 Phase 首位执行 | #4 跨场景污染 |
| TTL 独立播种-探测对 | 每个 TTL 时间点使用独立的播种+探测，而非共享同一播种 | #7 TTL 自填充 |
| 会话隔离检查清单 | 每次 Phase 切换验证：语料域零重叠？API key 是否相同？ | #4 跨场景污染 |
5. 执行计划
5.1 实施顺序
Phase 1: 信号验证 (~15 min)
→ 运行独立性探针(完全无关主题) + 一致性探针(全同请求配对)
→ 判定：cached_tokens 是否可信？
Phase 2: 机制区分 (~20 min)
→ 运行探针 C(后缀微调) → PREFIX 确认？→ YES → 进入 Phase 3b
→ 运行探针 D(内容重排序) → HASH 确认？→ YES → 进入 Phase 3a
→ 运行探针 A(全同请求) → response.id 重复？→ HTTP 响应缓存
→ 运行探针 E(不可见字符) → 最终区分
Phase 3: 边界映射 (~60 min，含 TTL 等待)
→ 3a(HASH) 或 3b(PREFIX) 精细探测 + 3c(TTL 独立播种-探测对)
Phase 4: 鲁棒性 (~30 min)
→ 并发/容量/大载荷/跨模型隔离
总计：~125 分钟 + TTL 最长等待 300s/端点5.2 两个端点独立执行
两个端点（算优优、移动云）完全独立 测试，使用不同 DOMAIN UUID 确保不交叉污染。如果条件允许，使用官方 DeepSeek API（api.deepseek.com）作为校准基准。
6. 后续测试工具重构原则（基于实验结论）
若确认为 HASH（内容哈希缓存）
✓ 删除：所有前缀类场景（prefix_sweep, prefix_truncation, partial_overlap）
✓ 新增：内容复用率监测器
✓ 重构：判定逻辑从"前缀共享比例"改为"内容相似度"
✓ 核心场景精简为 3 个：identical / content_reordered / content_modified若确认为 PREFIX（前缀匹配缓存）
✓ 保留：前缀类场景（但改用 tiktoken 精确计算 token 级分叉点）
✓ 删除：字符级切分方式
✓ 新增：分叉点精度测试、中断与恢复测试
✓ 监控指标：精确到 token 的缓存命中率若确认为 FIXED（无真实缓存）
✗ 整个缓存测试工具废止
✓ 重定位为"API 行为一致性验证器"------持续监控 API 升级后缓存行为是否变化⚠️ 已知局限与风险
| 风险 | 严重度 | 缓解措施 |
|---|---|---|
cached_tokens 完全虚假 |
高 | Phase 1 门控自动检测 + 信源切换机制 |
| 负载均衡多实例独立缓存 | 中 | 双峰分布检测 + 多次迭代 |
| 缓存策略在测试期间动态变化 | 中 | 跨时间段重复核心探针 |
| API 版本漂移 | 低 | 记录 model 版本 + 后续定期回归 |
| 某些 HASH/PREFIX 变体黑盒不可区分 | 低 | 在方案中明确声明这些盲区，接受 F 级置信度 |
📚 成员产出索引
| 文档 | 作者 | 路径 |
|---|---|---|
| 实验架构设计（5阶段+8假设+决策树+风险分析） | gstack-product-reviewer | deliverables/gstack/cache-detection-experiment-architecture-2026-07-09.md |
| 探针测试用例设计（7类探针+具体参数+预期矩阵） | gstack-investigator | probe-design.md |
| 判定标准规范（量化矩阵+统计+置信度+边界情况） | gstack-qa-lead | deliverables/gstack/cache-probe-judgment-criteria-v1-2026-07-09.md |
| 综合执行方案（本文档） | team-lead | deliverables/gstack/cache-detection-final-plan-2026-07-09.md |