以下对照对应 2026 年 9 月 10 日的固定开发记录。
复杂问题包含多个侧面，让模型先拆成几个小问题，再分别检索，看起来很自然。一个问题同时询问处理条件与异常分支，单次查询可能偏向其中一侧；多路检索似乎能把遗漏补回来。
但查询规划不只是增加几条搜索语句。规划器还可能认为问题不清楚，要求用户先补信息；它也可能改变原问题的查证目标，把未知条件写进子查询。这些选择都发生在真正搜索之前，却直接决定最终有没有资料可用。
TraceWise 在2026年9月9日做过一次固定开发对照。结果是：原问题扩大候选再重排，完整支持111/127道；带本地复核的查询规划组合只有72/127道。低分的主要来源是澄清路由阻断检索，而不是所有拆分查询都失效。把这两件事分开，才能解释为何这版规划没有被采用。
先与一个足够简单的方案比较
这轮复用24份资料的485个原文结构片段、已有1024维文档向量，以及固定140道问题。其中127道有明确支持标签，13道诊断题单列。完整支持的含义是：最终上下文保留所有已标注必要依据；它不是生成答案正确率。材料属于已暴露开发题，没有独立人工gold或留出身份。
对照设置了三种条件。基础方案直接取原问题的前10个片段。宽候选方案仍使用原问题，先取30个，再统一重排。规划方案保留原问题，并在允许拆分时增加最多两条子查询，每路最多10条，稳定去重后最多30条，再用原问题统一重排。
后两种方案共享模型、重排指令和候选上限；所有条件最终最多保留10个片段，上下文预算为8000个 Unicode 字符，包含来源头。候选名额相同并不意味着计算成本相同：规划需要额外生成计划和子查询向量。
规划模型固定为 qwen-plus-2025-07-28，温度0、非思考、单轮JSON输出，不因一次结果不理想而重试。对外发送的是问题文本，不包含标签、答案或原文引用。固定模型身份是为了追溯这次实验，不表示它是所有场景的最佳选择。
整体下降，先问下降发生在哪个决定
最终上下文完整支持计数如下：基础方案102/127，宽候选加重排111/127，规划组合72/127。
图1：固定开发题比较；所有分支最终最多10片段和8000字符。规划列包含是否检索的路由决定。
宽候选相对基础方案净增9道，逐题是11道改善、2道退步。这个收益同时包含扩大候选和重排的作用，不能单独归给其中一个组件。规划组合的明显下降，则需要先回到计划类型。
140个原始计划中，50个选择直接检索，40个选择分侧面检索，50个要求澄清。最后这50个里，有42个属于支持题；按照冻结的执行契约，澄清分支不发出检索，因此上下文为空。
这解释了大量缺失，但不能简单得出“42次澄清全都错了”。资料足以支持一个问题，与用户意图是否已经足够明确，是两个判断。当前标签主要记录原文支持，并没有独立评价每一次澄清是否必要。72/127测量的是包含路由决定的整个策略，而非纯粹的子查询召回效果。
JSON 合法，不保证拆分仍在回答原问题
这次140次生成没有格式解析失败。结构化输出确实让下游能够读取计划类型、子问题等字段，但计划是否保留原意，还需要另外检查。阿里云的结构化输出说明也区分JSON格式与指定结构；业务上的查证目标是否正确，不是仅靠可解析格式就能确定的。
40个拆分计划逐题经过本地AI复核，35个允许执行，5个拒绝。问题包括把查证目标换掉、子查询留下不独立的指代、凭空增加开票请求或税务系统假设，以及误读原题。
这些失败不是因为子查询数量不够。一个子查询即使能找到高度相关的材料，也可能搜的是模型补出来的前提。对有条件的业务问题而言，拆分要保留“在什么条件下”“哪个对象”“是否只是可能”等限定，而不是只留下几个主题名词。
本地复核拒绝执行这五个计划，但它仍是AI判断，不是独立人工语义认证。这两层观察应分开：计划能够被程序消费；部分计划的含义仍不适合直接执行。
只看允许拆分的题，收益也没有超过宽候选
35个允许计划中，34道属于支持题。把这一子集拿出来，基础方案完整24/34，宽候选完整28/34，拆分也是28/34。后两者不仅计数一样，完整与不完整的题号也完全相同。
图2：127道题内的允许拆分子集，不增加独立样本数。两种增强完成同样的28道题。
拆分候选池完整覆盖29道，宽候选池覆盖28道；额外找到的候选支持没有全部留进最终上下文。所以，“拆分比直接Top10多完成4道”是真实观察，但这些题用更简单的宽候选同样完成了。它不足以支持为当前任务默认增加规划步骤。
这个子集也经过计划复核筛选，不能用28/34替代全体规划策略的72/127，再说规划组合没有退步。整体结果反映路由加检索的共同效果，子集结果用于辨认拆分本身还有多少新增价值，两者用途不同。
多一个组件，也多一种失败与成本
生成阶段用了140次成功请求，检索阶段新增70次子查询向量和230次重排请求。两阶段共440次成功请求；这里包含宽候选对照与规划分支的调用，不能把全部都算作规划的边际成本。文档向量和原问题向量复用了既有缓存，缓存的零新增调用也不表示线上长期免费。
更重要的代价是决策复杂度。普通检索需要处理候选缺失和排序损失，规划还加入了是否澄清、怎样拆分、怎样复核以及是否执行的判断。每一层都可能合理，却仍需要端到端结果来决定是否保留。
这轮停止后没有根据失败题继续改提示、调K或扫描路由。当前选择是保留“原问题Top30加重排”为后续验收候选，不采用这版查询规划组合，也不将其下沉为 Foundation 的默认能力。
如果以后再研究规划，首先应分别验证两个问题：澄清判断什么时候确实应阻断原查询；保持条件与指代的拆分，能否在固定预算下优于原问题宽候选。这些是新的可检验假设，还不是已经实现的改进。
这份结果适用到哪里
本轮是原文结构片段上的本地精确余弦与在线模型对照，不是Qdrant产品API吞吐测试，也不是后来 Foundation post22 产品链路的质量复现。后续产品接口同样采用30进10，但候选对象、去重单位与原文坐标不同，不能直接继承这里的分数。
对于这次产品选择，结论已经足够具体：规划组合有明显路由损失，而允许拆分的子集尚未显示超越简单方案的最终收益。以后改变模型、资料、任务或路由契约时，可以重新提出问题；不必把一个未胜出的候选留在默认路径里等待它证明自己。