缓存策略探测实验 — 综合执行方案

📌 摘要

• 目标：确定算优优和移动云的 DeepSeek API 代理的实际缓存机制（前缀匹配 / 内容哈希 / 固定响应 / 混合）
• 方案：三专家协作设计了从信号验证→机制区分→边界映射→鲁棒性测试的五阶段递进式实验流水线
• 预计 API 调用量：~400 次/端点
• 预计总耗时：~42 分钟 + TTL 等待时间/端点
• 最简判定路径：仅需 4 个探针（C + D + A + E）即可在 ~20 分钟内确定缓存策略
• 关键保障：首次在测试方案中引入了 Exact-Minus-1 自动检测、信源切换机制、内容域隔离、Holm-Bonferroni 多重比较校正

🎯 核心结论卡片

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 测试报告，各假设的初始信念：

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 核心阈值

3.2 五级置信度体系

3.3 三级证据权重

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 升级后缓存行为是否变化

⚠️ 已知局限与风险

📚 成员产出索引