查询分解并不能解决上下文饥饿——它只是转移了问题
内容提要
本文提出“上下文饥饿”概念：多意图查询经分解检索后，打包器按相关性贪心分配固定上下文预算，导致部分子意图虽已检索到证据却被挤出，且召回指标仍显示正常。实验用GitLab文档构建多意图查询，发现默认流程饿死31.1%子意图。按子查询分数预留名额可将覆盖率从68.9%提至89.4%，优于升级检索器。饥饿多导致无依据回答而非沉默。
延伸解读
上下文饥饿：被忽视的分配问题
文章提出“上下文饥饿”概念，指子意图在最终打包的上下文中未获分配，即使其证据已被检索到。默认流程中，打包器按相关性贪心分配固定预算，导致部分子意图被挤出，而召回指标仍显示正常。实验显示，默认流程饿死31.1%的子意图，且饥饿多导致无依据回答而非沉默。
分配策略优于检索器升级
在相同检索器下，改变分配策略（按子查询分数预留名额）将覆盖率从68.9%提升至89.4%，增益20.5个百分点；而升级检索器仅带来12.7个百分点的提升。甚至较弱检索器配合片段评分预留达到84.5%，超过较强检索器配合贪心打包的68.9%。这表明在预算紧张时，分配策略比检索器升级更有效。
位置偏差与主题距离的影响
饥饿在查询位置中呈序列位置曲线：中间位置饥饿率最高（48.0%），首尾较低。片段评分预留可将曲线拉平。此外，跨主题的子意图饥饿率（38.1%）约为同主题（18.3%）的两倍，与直觉相反，因分散查询使重排序器难以一致评分。
实践建议：记录子意图覆盖率
文章建议为每个子意图预留名额，并按子查询分数选择预留片段，而非按原始查询分数。同时，应记录每个多意图请求中零覆盖的子意图数量，因为该指标能完美预测生成结果：当证据进入上下文时，回复100%覆盖该问题；饥饿时，48.1%的回复仍会无依据回答。
Q&A
什么是上下文饥饿？
上下文饥饿是指一个子意图在最终打包的上下文中没有得到任何分配，无论其证据是否被成功检索到。定义关注分配而非检索，因为分配是没人注意的部分。
上下文饥饿和语义稀释、上下文中毒有什么区别？
语义稀释发生在检索时，将多部分问题嵌入为单个向量导致质心落在多个主题之间，证据从未被找到；上下文中毒是关于窗口中存在错误、过时或对抗性内容，污染模型生成。上下文饥饿是缺失问题，由策略而非意外导致。
为什么查询分解不能解决上下文饥饿？
查询分解解决了检索时的语义稀释，但上下文窗口没有增长。分解后，多个结果集竞争固定令牌预算，打包器按相关性贪心分配，没有公平约束，导致部分子意图的证据被挤出。失败从嵌入转移到了打包器。
如何缓解上下文饥饿？
为每个子意图预留一个名额，并按子查询分数选择预留段落，而不是按原始查询分数。将覆盖率从68.9%提升至89.4%，并将分配饥饿从30.6%降至10.1%。
上下文饥饿会导致什么后果？
饥饿大多不会导致沉默，而是产生无依据的回答。当子意图被饿死时，回复有48.1%的概率仍然回答该问题，45.6%的概率明确标记缺口，只有6.3%的概率沉默。
升级检索器和改变分配策略哪个更有效？
改变分配策略更有效。升级检索器将覆盖率从56.2%提升至68.9%（增益12.7点），而改变分配策略在同一检索器上将覆盖率从68.9%提升至89.4%（增益20.5点）。较差的检索器配合更好的分配器可以胜过较强的检索器配合贪心打包器。
什么是令牌每子意图交叉点？
交叉点是指上下文预算除以子意图数量。低于约1000令牌每子意图时，分配策略主导；高于此值时，分配器无关紧要，因为所有内容都能放入。
如何处理依赖性子意图？
可以在分解时标记依赖关系，或运行延迟的第二遍重新检索条件子句。推荐依赖标记，因为第二遍成本高，标记可重用，且未标记的依赖会表现为饥饿子意图，而延迟遍可能产生自信的错误答案。
