以下对照对应 2026 年 9 月 10 日的固定开发记录。
检索已经找到了相关资料，为什么交给模型的内容仍然缺一部分依据？
在 TraceWise 这轮正文检索对照里，一道关于“图事务响应丢失后怎样恢复”的题给出了很直接的例子：向量排序和重排后的前十条都包含完整依据，但组装为有限长度上下文后，向量基线丢失了必要内容，重排条件则保留了它们。
如果只检查“前十条有没有命中”，这道题会被记为两种策略都成功。如果只看最终分数，又容易把收益全部归因于模型更懂问题。真正影响结果的是一串连续选择：先让资料进入候选，再选出前十条，最后决定哪些文字能留在上下文里。
本文讨论的就是这个问题：在相同候选和上下文预算下，重排具体改善了哪一段，又留下了哪些无法由它解决的缺口？
先把检索任务说清楚
TraceWise 用资料支持知识与关系分析。对这类任务，搜到一个主题相近的段落往往不够。比如恢复任务既需要判断“此前是否已经执行”，也需要知道“当前基线是否变化”；只保留其中一半，后续分析就缺少做判断的条件。
因此，这轮没有把命中任意一个关键词视为完成，而是标出每道题的必要要点和原文依据。每个必要点可以有多组充分支持：任意一组齐全即可；同一组需要几处原文合用，就必须全部保留。评分将命中的原文字符区间合并，重复片段不会重复得分。所有必要点的支持都完整时，该题才记为完整。
这个指标叫作“最终上下文完整包含已声明必要依据”。它回答的是交给后续分析的资料够不够完整，不直接判断生成答案是否正确，也不等于对所有相关段落进行了穷尽标注。
材料共75道正文题，71道支持明确的题参与这个指标，4道歧义诊断题保留在结果中但不进入分母。这是一批AI编写、AI复核且有历史暴露的开发材料，适合发现阶段性损失、比较候选方案；独立人工质量验收仍需另外的材料和门槛。
一次查询，只改变排序
语料复用24份固定资料、432个 Evidence revision 和637个索引片段。8份目标 Markdown 所在的157个原文单元已在库中，其余16份资料保留作为干扰来源，没有为了题目重建一套只有正确答案的索引。
查询向量采用 text-embedding-v4，维度为1024；增强条件采用 qwen3-rerank。重排接口接收查询与候选文档，并返回候选位置及相关性分数。这意味着它可以重新安排已有候选的顺序，却不能把未提供给它的文档加入结果。阿里云文档排序 API说明了这一输入输出契约。
每道题执行一次真实的产品 ASGI 请求，经过实际读取身份、Foundation、Neo4j、SQLite、Qdrant 和在线模型链路。保留原始查询，不做查询扩展；两种条件共享这次请求的30条重排前候选，最终最多取10条，上下文预算固定为8000个 Unicode 字符。
向量基线从相同候选的原始顺序离线构造，增强条件使用重排顺序。这样可以比较排序带来的依据保留变化，但不能比较两套独立请求的端到端耗时。实验使用 Foundation 0.1.0a20.post22 开发候选，尚未切换正式版本或普通默认配置。
不只看最终的12.68个百分点
71道支持题中，30条候选已经完整覆盖64道。这是本轮固定候选的完整支持上限：另7道无论怎样重排，输入里都缺必要材料。
缩减到前十条之后，向量基线有54道完整，重排有61道完整。再经过相同的上下文组装与截断，分别剩51道和60道，完整保留率从71.83%变为84.51%，净增9道，提升12.68个百分点。逐题配对中有9道由不完整变为完整，没有观察到反向变化。
图1：开发对照。每一格都统计71道题中完整保留已声明必要依据的题数。
三层计数让收益有了位置：重排条件在前十条阶段少丢了7道题，最终上下文则比基线多保留9道。排序既影响哪些片段入选，也影响哪些片段优先消耗上下文预算。
开头的恢复题就属于后者：两边前十条都完整，但相同长度限制使最终结果不同。另一道关于长任务中断恢复的题，则在向量前十条阶段已经缺少一个必要点；同池重排把所需支持选入前十条，并保留到了上下文。两种失败不能归为同一个“召回不准”。
剩下11道，不能继续只调重排
重排之后，仍有11道题的最终支持不完整。按最早发生缺失的阶段归类，7道是候选不足，3道是排序损失，1道是上下文截断。分类互斥：如果30条候选已经缺材料，就先归候选缺失，不再同时记成排序失败。
图2：最早缺失阶段决定优先检查位置；三类题数合计11，不重复计数。
这给后续优化设定了不同的问题。候选不足要检查查询表达、可搜索文本和候选预算；候选已有而前十条缺失，要检查排序目标与片段竞争；前十条齐全但上下文不全，要检查组装顺序和截断规则。这些是待验证方向，不是本轮已经获得收益的新策略。
分场景结果同样重要。13道工作流题从5道完整变为7道，58道架构概念题从46道变为53道。总分上升并不意味着工作流资料已经够用：仍有接近一半工作流题没有保留完整支持。当前结果足以支持保留重排候选，却不支持忽略这一弱项。
收益之外，还要保留成本问题
75道题使用75次查询向量请求和75次重排请求，没有重新计算文档向量。服务端报告的用量分别是2247个查询向量 tokens 和1,051,917个重排 tokens。实验记录中的3.751397元是保守预算预留，不是结算账单。
实际 ASGI 时长中位数为6.348秒、最大8.618秒，包含在线模型调用，并复用了文档索引及缓存。由于向量基线是同池离线构造，本轮没有“加重排额外慢了多少秒”的完整请求对照，也没有冷启动、并发或生产延迟结论。
质量收益和运行成本是两个采用条件。一次支持覆盖改善，不能自动替代默认策略变更所需要的延迟、费用与故障处理判断。
当前选择：保留增强，不把它当作总开关
这轮结果支持一个具体选择：正文检索保留向量基础路径，同时保留同池重排作为增强候选。它在这批材料上减少了排序和最终截断造成的完整支持损失，收益位置已经能够复核。
后续若要正式采用，应在未暴露的独立材料上固定验收门槛，并把工作流子集、依据完整性与运行代价一起看。4道诊断题虽然都返回了内容，也不能因此记为正确回答或正确拒答。
对检索系统而言，“相关内容出现过”只是中间状态。更有用的优化问题是：必要资料在什么时候丢了，改变一个组件能否让它留到真正被使用的地方。