Hindsight 0.9.1 旁路 Clone 高保真回归
- HTML: https://decision.ht1072.top/2026-08-17-hindsight-091-clone-high-fidelity-regression.html
- Local HTML:
[已移除本地路径] - Generated: 2026-08-17T14:28:06+08:00
Hindsight 0.9.1 旁路 Clone 高保真回归:迁移通过但 Reflect 与性能暂不放行
结论
0.9.1 可以从当前生产 0.9.0 的真实 PostgreSQL dump 完成旁路迁移,并通过核心数据功能回归;但暂不建议切生产。
本轮唯一决策:NO-GO for live cutover; keep 0.9.0 production and retain 0.9.1 clone evidence。
主要原因不是迁移失败,而是两个高影响门禁:
- 复杂 Reflect 在生产 0.9.0 与候选 0.9.1 上都撞到服务端
300swall timeout,0.9.1 没有证明能绕过当前luna/Axon tool-call 通道故障; - 在同机并行对照下,0.9.1 recall P50/P95 约
6.92s / 7.81s,生产 0.9.0 约5.43s / 6.38s,候选慢约 27%;该差异可能混入双实例争抢 CPU reranker/embedding,必须先做单实例热缓存复测,不能直接归因于版本代码。
生产服务、生产 bank、生产 cron 和生产配置均未被旁路试验改动。
一、生产基线与隔离边界
现场生产事实:
- API:
0.9.0 - Alembic:
b3e8d1c6f4a9 - bank:
hermes - documents:
997 - memory units/nodes:
11,762 - memory links:
248,175 - pending/failed operations:
0/0 - PostgreSQL:18.1,生产端口
5432 - Hindsight API:
127.0.0.1:8889 - 生产
/health:healthy,database connected - 生产进程 RSS 在本轮观察中约
1.5–1.88GB,systemd MemoryHigh 为2G,这是后续长期稳定性门禁,不是本轮升级结论。
生产 dump:
[已移除本地路径]
size: 36M
sha256: ed0bd5515226f6f1491dcd84dd9a5a562213aecb4df22bd27ec62432b796bcf4
旁路资源:
- clone PostgreSQL:
55437 - clone API:
18895 - clone venv:
[已移除本地路径] - clone bank/data:由生产 dump 恢复,独立数据库
- clone 日志和结果:
[已移除本地路径]
旁路结束时确认:18895、55437 已无监听;生产 8889、5432 仍正常监听;生产 health/version/stats 可回读。
二、候选版本与迁移结果
candidate 使用官方:
hindsight-api-slim==0.9.1
pg0-embedded==0.15.1
Python 3.12
PostgreSQL 18.1
复制生产 0.9.0 venv 后只升级 Hindsight 包,保留 local ML、torch、sentence-transformers、reranker 等重依赖,避免新环境依赖漂移。
pip check 通过,关键包可导入:
hindsight-api-slim 0.9.1
sentence-transformers 5.7.0
transformers 5.15.0
tokenizers 0.22.2
torch 2.13.0
pg0-embedded 0.15.1
迁移链:
b3e8d1c6f4a9
→ d9c1a7b4e2f6 async_operations.serialization_key
→ c4f7a91b2d38 entity_maintenance_queue
迁移成功后 clone 对账:
| 指标 | 生产 dump / 0.9.0 | 0.9.1 clone |
|---|---|---|
| bank | 1 | 1 |
| documents | 997 | 997 |
| memory units/nodes | 11,762 | 11,762 |
| memory links | 248,175 | 248,175 |
| pending/failed | 0/0 | 0/0 |
clone 启动后 migration 新增 entity maintenance queue,随后队列排空;没有发现 pending/processing 堆积。
三、功能回归结果
使用 clone 临时 bank verify-091-20260817-135216,写入 5 条虚构事实,执行精确事实、多跳、时序、consolidation、reflect 和 null metadata 试验。
精确事实
通过:
H091_EXACT_817
recall 返回正确事实,HTTP 200,约 0.404s。
多跳
通过:
Orion 负责人 → 美咲 → UTC+9
recall 返回负责人和时区两条证据,HTTP 200,约 0.558s。
时序更新
通过:
旧值:Helios 暂定首尔
新值:改为东京,首尔作废
recall 将东京的新事实排在首位,同时保留旧值作为历史证据,符合当前 Hindsight 的 temporal 语义,约 0.450s。
Consolidation
通过:
- submit:HTTP 200;
- operation:
completed; - 处理 5 条输入形成 9 个 nodes、28 条 links;
- pending/failed:
0/0。
Reflect
功能结果通过,但速度不通过:
HTTP 200
elapsed: 206.514s
input_tokens: 8,925
output_tokens: 2,093
total_tokens: 11,018
返回正确:
Orion 负责人所在时区:UTC+9
Helios 最新有效部署区域:东京
Null metadata
请求带 metadata: {"nullable": null} 时,0.9.1 API 直接返回 422 Input should be a valid string,没有写入坏数据;随后 recall 仍为 HTTP 200,bank 没有被 wedge。
这说明当前版本具备“入口拒绝坏输入”的安全性,但尚未验证上游 PR #3531 所描述的“写入/读取两端丢弃 null 字段”能力;该 PR 截至本次检查仍未作为已合并能力计入。
临时 bank 删除:HTTP 200,deleted_count=23。
四、生产与 0.9.1 recall 对照
使用生产 hermes bank 与 clone 同一份生产 dump,10 个查询、每个查询 3 轮,结果排序高度一致:
top1 same rate: 100%
top5 Jaccard mean: 92.67%
top10 Jaccard mean: 91.56%
这说明 0.9.1 在本轮没有造成明显的召回排序回归。
但同机并行条件下延迟为:
| 版本 | P50 | P95 | 说明 |
|---|---|---|---|
| 生产 0.9.0 | 5.43s | 6.38s | 与 clone 同机并行 |
| clone 0.9.1 | 6.92s | 7.81s | 与生产同机并行 |
不能直接把 27% 差距归因于 0.9.1。两实例同时使用本地 embedding/reranker,且生产 RSS 约 1.5–1.88GB、clone peak RSS 约 1.8GB,CPU/内存争用会污染结果。下一轮性能微基准必须改成:生产单实例热缓存 → 停 clone → clone 单实例热缓存,分别测 P50/P95/P99。
五、Reflect 双版本对照与根因
同一复杂查询、同一 budget=low、同一 bank 语料:
| 版本 | 结果 | elapsed |
|---|---|---|
| 生产 0.9.0 | HTTP 504,服务端 300s wall | 300.029s |
| clone 0.9.1 | HTTP 504,服务端 300s wall | 300.011s |
生产日志显示:
scope=reflect_tool_call
model=openai/luna
attempt 1/4: Request timed out
attempt 2/4: Request timed out
Wall-clock timeout after 300.0s
因此当前 Reflect blocker 更像是 Axon/luna tool-call 通道或其长请求稳定性问题,而不是 0.9.1 migration 回归。0.9.1 的 split synthesis 在本轮没有绕过该通道故障。
当前不能说 0.9.1 Reflect 比 0.9.0 更差;两边都失败,结论是“候选没有证明修复该 blocker”。
六、m5 延迟口径修正
m5 runner 当时发送了:
{
"max_results": 10,
"include_entities": false,
"include_chunks": true
}
0.9.x OpenAPI 的 RecallRequest 实际支持:
query
types
prefer_observations
budget
max_tokens
trace
query_timestamp
include
tags
tags_match
tag_groups
min_scores
max_results/include_entities/include_chunks 会被 API 忽略,并在日志中明确提示 Unknown parameters ignored。因此,之前把 m5 的延迟归因部分写成“include_chunks=true 增加了服务端成本”不够严谨,应修正为:
- m5 的
max_tokens=1024有效; - 实际 recall 仍按预算映射执行,low budget 为约 100 units;
- 日志显示每次会合并约 500–700 个候选,再对最多 300 个候选运行 cross-encoder reranker;
- 主要耗时在 reranker,而不是无效的 include_chunks 参数。
0.9.1 安装包新增/暴露了可供后续性能微基准验证的开关:
HINDSIGHT_API_RERANKER_MAX_CANDIDATES_LOW
HINDSIGHT_API_RECALL_MAX_CANDIDATES_PER_SOURCE
HINDSIGHT_API_ENABLE_TEMPORAL_RETRIEVAL
HINDSIGHT_API_ENABLE_GRAPH_RETRIEVAL
HINDSIGHT_API_ENABLE_RERANKING
这些开关不能直接改生产。正确顺序是:在 clone 上固定质量 gold,逐项做 reranker candidate cap / graph / temporal / reranking 的延迟—质量 Pareto 测试,再决定是否吸收配置。
七、0.9.1 对本机的实际价值
值得保留并继续关注的改进:
- per-document retain serialization,降低同文档并发追加互相覆盖风险;
- entity maintenance queue,避免实体维护任务直接压在主路径;
- Reflect 减少 retrieval plumbing 返回;
- Reflect 子召回解析 entity names;
- Reflect 注入当前日期,帮助 temporal reasoning;
- bank config 类型校验,减少错误配置把任务链 wedge;
- graph maintenance per-bank 串行化;
- concurrent bank delete 的 vector-index DDL 死锁修复;
- knowledge-base search 在非 native text backend 下的 500 修复;
- async document export 与 transfer/knowledge-page 相关改进。
这些改进证明 0.9.1 不是无价值版本,但它的收益主要是数据完整性、迁移/运维安全和边界修复,并没有在本轮证明“Reflect 稳定性或 recall latency 已解决”。
八、当前 GO/NO-GO
已通过
- 生产 dump 生成并 hash 固定;
- clone PostgreSQL 恢复成功;
- 0.9.1 venv 安装与
pip check通过; - migration 到
c4f7a91b2d38成功; - 结构计数一致;
- health/version/stats 通过;
- 精确事实、多跳、时序、consolidation 通过;
- 结果排序 top1 100%、top5/top10 高度一致;
- null metadata 不会写坏 clone bank;
- clone API/PG 已停止,生产未受影响。
未通过或未充分证明
- 复杂 Reflect:两版本均 300s timeout;
- recall latency:0.9.1 同机并行比生产约慢 27%,单实例热缓存尚未完成;
- null metadata normalization:当前看到的是 API 422,不是 PR #3531 的兼容读取路径;
- 长期 RSS/CPU 稳定性:只完成启动后与本轮短时观察,未完成 24–72 小时。
最终裁决:NO-GO for live cutover。
保留生产 0.9.0,保留 0.9.1 clone 证据;不恢复 clone 常驻,不改生产服务。
九、后续最小动作
- 修正 recall runner,使用真实 OpenAPI 参数;
- 在单实例、热缓存、相同资源条件下测 0.9.0/0.9.1 recall P50/P95/P99;
- 在 clone 对 reranker candidate cap、graph、temporal 开关做质量—延迟 Pareto;
- 若 0.9.1 能在不损伤多跳/时序的情况下明显降低 rerank 成本,再做一次 24 小时 clone 观察;
- Reflect 仍先处理 Axon/luna tool-call 通道,不把加大 timeout 当版本修复。
十、证据路径
[已移除本地路径]
[已移除本地路径]
[已移除本地路径]
[已移除本地路径]
[已移除本地路径]
[已移除本地路径]