mergeRangesToThreshold 输出低于 gate 阈值的尾部批次,破坏「列出即可压缩」不变量

[ranxianglei]

来源: ranxianglei/billion-context#847 (ranxianglei/billion-context#847) 分析 持续压缩失败、模型反复提交同一被拒范围 时发现

现象

billion-context #847:模型连续 7 次提交同一范围,每次都被 gate 拒绝(Total compressible content too small (1734 chars across 1 range(s), min 5000)),而 nudge/acp_status 全程把该范围列为可压缩(pendingT1 ≈ 40K 一直存在)。最终 usage 76%→89%,上游流截断。

根因

mergeRangesToThreshold(0.0.74 dist/index.js:2129-2145):把相邻 range 合并到 batchChars >= minChars 为止,但循环结束时无条件 push 尾部残余批次,即使其 batchChars < minChars:

if (batch.length > 0) result.push(mergeBatch(batch));

因此 nudge 的 "Compressible ranges" 列表(recommendNode → recommendedRanges,dist/index.js:~2505-2540,注入点 :3083)会包含压不动的范围。不变量「凡被列为可压缩的范围都一定压得动」被破坏。

加剧因素:viableRanges(chunk-QPVKTDYF.js:387-390)的门槛是 VIABLE_RANGE_MIN_TOKENS = 200 tokens(≈800 chars),与 gate 的 compress.minCompressRange(默认 5e3,chars)单位和数值都不一致——两个门槛、两种单位,消费方无法只靠一个过滤就对齐 gate。

影响

• 模型按列表选范围 → 必然被拒 → 失败调用+错误留在上下文尾部 → 模型模仿重试 → 死循环(#847 实测 7 次/13 分钟)。
• 所有依赖 recommendedRanges 的消费方(nudge、acp_status、preflight 式自动压缩)都被误导。

建议修复

1. 尾部批次若 < minChars:并入前一个批次(允许超阈值),或不输出。
2. 统一门槛:让 viableRanges 与 gate 共用同一阈值与单位(chars),或废弃双门槛之一。
3. 加一条回归测试:recommendedRanges 输出的每个 range 必须满足 gate 的 chars 下限(当前默认配置下必挂)。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 Root cause confirmed against master (8ee1801, v0.0.73) — this is a real invariant violation, not a host-side artifact. Working on a fix now; PR will follow in this thread.

Verification (code path)

1. mergeRangesToThreshold (src/recommend.ts:332-353) flushes a batch once batchChars >= minChars, then unconditionally pushes the residual tail (if (batch.length > 0) result.push(mergeBatch(batch)) at :349-351) even when batchChars < minChars. The doc comment admits it ("A sub-threshold tail batch is still emitted — callers filter by effectiveness separately"), but the primary consumer doesn't filter:
   • recommendNode → recommendation.recommendedRanges (src/compress.ts:598)
   • → NudgeDecision.compressibleRanges (src/compress.ts:1459)
   • → formatRanges (src/nudge-text.ts:73-145) prints every entry verbatim under Compressible ranges (N, oldest first): — no threshold check anywhere on the render path.
2. The apply-side gate (src/compress.ts:278-333) sums real chars over all ranges in one call and rejects below compress.minCompressRange (default 5000 chars, src/config.ts:26). So any listed tail batch < 5000 chars is guaranteed-rejected when submitted alone — exactly the #847 loop (model picks listed range → rejected → error stays in context → retries).
3. Notably, the kernel already encodes the intended invariant elsewhere: pendingByTier (src/compress.ts:1181-1212) filters recommendedRanges by (r.chars ?? r.tokens*4) >= minCompressRange, documented as "so a nudge never offers a range the kernel would atomically reject" (:1174-1180). The range list simply never got the same treatment.

Layer judgment: root cause = unconditional tail emission in mergeRangesToThreshold (plus consumers trusting it blindly). The #847 retry loop is the downstream symptom. Your aggravating factor is also confirmed: VIABLE_RANGE_MIN_TOKENS = 200 tokens (src/viable.ts:9) vs the gate's 5000 chars — two thresholds, two units.

Fix plan (test-first)

1. Enforce the invariant at the source: sub-threshold tail folds into the preceding flushed batch (overshoot allowed); if there is no preceding batch (all content below threshold), emit nothing rather than a guaranteed-rejected range. This heals every consumer at once — nudge text, the public NudgeDecision.compressibleRanges field hosts read directly, the panel, preflight auto-compress. Filtering only at render sites would leave API consumers exposed.
2. On unifying viableRanges: I'm keeping VIABLE_RANGE_MIN_TOKENS as-is. It's a public export with a different job (host-side display heuristic guarding "Summary too short" atomic rejection, per its doc comment), and after fix fix: release workflow grep lookbehind error #1 every recommended range ≥ minCompressRange chars trivially clears 200 tokens, so the mismatch becomes harmless on the recommend path. Documenting this instead of breaking the API — flag if you disagree.
3. Regression tests: unit tests for tail-fold / all-tiny→empty, plus a test asserting every recommendedRanges entry satisfies the gate's char floor under default config (fails before the fix, passes after).
4. Two existing tests in tests/recommend-merge.test.ts assert the current buggy behavior ("tail kept", "trailing flush") — they'll be updated to assert the invariant instead.

中文摘要:根因已核实——mergeRangesToThreshold 无条件输出低于 gate 阈值的尾部批次,而 nudge 渲染路径不做过滤,导致模型按列表选范围必被拒、重试死循环(#847);修复方案是在源头保证每个推荐批次都过 gate(尾部并入前一批次,全低于阈值则不输出),并补回归测试,PR 稍后贴在此。

[ranxianglei]

有结论了吗

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 有结论了:根因已核实,修复实现中,PR 马上贴。

• 根因确认:src/recommend.ts 的 mergeRangesToThreshold 循环结束后无条件 push 尾部残余批次(即使 < minCompressRange),而 nudge 渲染路径(formatRanges)不做任何过滤 → 列表里出现压不动的范围 → 模型照单提交必被 gate 拒(#847 死循环的直接原因)。
• 修复已在分支上改完:mergeRangesToThreshold 现在保证每个输出批次单独都过 gate——尾部并入前一批次(允许超阈值);若前面没有批次(全部内容低于阈值)则不输出。pendingByTier 的过滤保留为防御性冗余。
• 正在更新测试:2 个断言旧行为的用例改为断言新不变量 + 新增回归测试;跑完 typecheck/test/build 就开 PR。

中文摘要:结论=源头修 mergeRangesToThreshold(尾部折叠/不输出),代码已改完,测试收尾中,PR 稍后。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 修复完成,PR 已开:#313

改动(4 文件,+65/−32):

• src/recommend.ts — mergeRangesToThreshold 现在保证每个输出批次单独都过 gate:尾部残余并入前一批次(允许超阈值);前面没有批次(全部内容低于阈值)则不输出。不变量在源头成立,nudge 文本、host 直接读的 NudgeDecision.compressibleRanges、panel、preflight 自动压缩一次性全部修好;pendingByTier 的过滤保留为防御性冗余。
• 测试:新增 3 个用例(尾部折叠 / 全低于阈值→[] / 「每个输出批次单独清 minChars」不变量),已验证在未修复的 master 上全部失败;更新 3 个断言旧行为的用例(recommend-merge ×2、nudge arbitration ×1——pendingT1 从被过滤的 1600 变为折叠后的 2000,并新增断言 nudge 只列出 1 个过 gate 的范围);block-map 的 userMsgs 求和用例 fixture 提到阈值以上保持原意图。
• Pre-flight:typecheck ✓ · 790/790 tests ✓ · build ✓

关于建议 #2(viableRanges 统一门槛):VIABLE_RANGE_MIN_TOKENS = 200 我保持不动——它是公开导出,职责不同(host 侧展示启发式,防 "Summary too short" 原子拒绝),且本修复后任何 ≥ minCompressRange chars 的推荐范围必然远超 200 tokens,单位不一致在 recommend 路径上已无害。如果你更想直接统一/废弃,说一声我再改。

中文摘要:修了 mergeRangesToThreshold 无条件输出低于 gate 阈值的尾部批次的问题(尾部折叠进前一批次、全低于阈值则不输出),「列出即可压缩」不变量现在在源头保证,附回归测试,PR #313 可以 review/合并。