HT1072公开知识系统
返回列表总览 ↗
决决策档案2026-08-17 · 决策记录
2026-08-17 · DECISION TRACE

Hindsight 0.9.1 Recall 性能优化评估

保留方案、指标、验证、复盘和治理判断，让结论能够追溯。

2026-08-17记录日期
决策记录记录类型
11章节数

Hindsight 0.9.1 Recall 性能优化评估

  • HTML: https://decision.ht1072.top/2026-08-17-hindsight-091-recall-performance-optimization.html
  • Local HTML: [已移除本地路径]
  • Generated: 2026-08-17T17:03:27+08:00

Hindsight 0.9.1 Recall 性能优化评估：batch 16 是唯一无质量漂移候选

结论

当前唯一值得进入 live canary 的配置是：

HINDSIGHT_API_RERANKER_LOCAL_BATCH_SIZE=16

它保持现有 cross-encoder/ms-marco-MiniLM-L-6-v2 模型、300 候选、graph/temporal/rerank 全部开启；clone 三轮重复中，结果排序逐条完全一致，P50/P95 相比默认 batch 32 改善约 14%/18%。

candidate cap、关闭 graph/rerank、bucket batching、Ettin 17M 均不满足“明显降延迟且质量稳定”的门槛，不建议进入 live。

现场基线

生产已切至 Hindsight 0.9.1，正确 RecallRequest 下单实例热缓存基线：

P50 5.99s
P95 6.95s
P99 6.99s

clone 默认重复基线在不同轮次约为：

P50 6.65–7.01s
P95 7.50–8.33s

绝对值受同机生产负载、CPU 温度和 clone 启停影响；配置比较以同一轮、同一 clone、同一 query 集的相对差异为主。

根因

Hindsight 0.9.1 的 low-budget recall 仍会：

  1. 运行 semantic、BM25、graph、temporal 多路召回；
  2. 合并约 500–700 个候选；
  3. 最多对 300 个候选执行 local cross-encoder rerank。

现场日志中 rerank 300 candidates 通常耗时约 4.5–6.7 秒，占 recall 总耗时绝大部分。

该结论与上游 #3107 的实测一致：对方 13.67 秒 recall 中，cross-encoder 用 12.75 秒，占 93%；PR #3191 因此增加 per-budget candidate cap。

参数矩阵

配置 P50 P95 Top1 一致 Top5 Jaccard 结论
默认 300 6.70s 7.88s 100% 100% 质量基线
rerank cap 250 6.05s 6.91s 100% 71.2% 排序漂移过大
rerank cap 200 4.98s 5.98s 100% 61.9% 不采用
rerank cap 150 3.99s 5.02s 100% 49.0% 不采用
rerank cap 100 3.48s 4.20s 60% 28.5% 不采用
rerank cap 50 2.14s 3.10s 20% 11.9% 不采用
per-source cap 200 7.13s 8.21s 100% 85.0% 无性能收益
per-source cap 150 7.21s 8.11s 100% 78.3% 无性能收益
关闭 graph 6.15s 7.12s 70% 55.4% 不采用
关闭 reranker 0.81s 1.14s 0% 5.4% 严重退化

Bucket batching

官方文档称 length-sorted bucket batching 在部分环境可快 36–54%，且理论上不改变分数。

本机 Linux CPU 实测：

default P50/P95: 6.84s / 7.86s
bucket  P50/P95: 7.02s / 8.00s
排序一致：100%

本机反而慢约 3%，不采用。官方数据不可直接外推到当前 CPU/transformers 组合。

Batch size

同一模型和候选集合：

batch size P50 P95 排序
16 5.86s 6.67s 完全一致
32 7.04s 8.02s 完全一致
64 7.88s 9.08s 完全一致
128 9.31s 10.97s 完全一致

严格三轮重复：

batch16: P50 6.05s / P95 6.86s / P99 7.53s
batch32: P50 7.01s / P95 8.33s / P99 8.42s

机制解释：当前 CPU 上较大 batch 的 padding 与 attention 计算开销高于批处理收益，16 是当前实测最优点。

替换 reranker 模型

测试 cross-encoder/ettin-reranker-17m-v1：

MiniLM-L6 P50/P95: 6.79s / 7.66s
Ettin 17M P50/P95: 4.44s / 4.93s

速度提高约 35%，但中文生产查询的排序漂移明显：

top1 same: 30%
top5 Jaccard: 39.3%
top10 Jaccard: 47.7%

Ettin 模型卡主要为英文评测；其通用英文 MTEB 优势不能外推到本机中文长期记忆，不采用。

TEI 与 GPU

  • 本机 torch.cuda.is_available() = false，无 CUDA/XPU，无法用 Hindsight 自动 GPU 加速。
  • TEI sidecar 可提供服务化 batching/backpressure，但同一 CPU 上不保证单请求更快，并增加进程、端口和内存复杂度。
  • 当前 batch16 已提供无质量漂移收益，TEI 暂不进入第一阶段。

固定质量集边界

20 题 synthetic case-tag bank 的每题候选数小于 200，因此 cap250/200 不会触发；它适合验证答案语义，不适合验证大 bank candidate cap。大 bank 的 top-k overlap 证明 cap 会显著改变排序，但临时关键词评分器因事实时效和 rubric 设计不足已作废，不作为结论依据。

推荐 live canary

应用：

HINDSIGHT_API_RERANKER_LOCAL_BATCH_SIZE=16

保持不变：

reranker model=MiniLM-L6
reranker candidates=300
graph=true
temporal=true
reranking=true

上线门槛：

  1. 修改前备份 [已移除本地路径]；
  2. 重启 Hindsight，预计短暂中断；
  3. health/version/stats 通过；
  4. 用固定 10 查询跑 3 轮，要求 P95 至少改善 10%；
  5. top1/top5/top10 必须与修改前逐条一致；
  6. retain/recall/consolidation/reflect smoke 通过；
  7. 失败则删除该 env 行并重启回滚。

未经用户确认，不执行 live 重启。

证据

[已移除本地路径]
[已移除本地路径]
[已移除本地路径]
[已移除本地路径]
[已移除本地路径]
[已移除本地路径]
[已移除本地路径]