8.2.2 长文档、多文档、跨文档问题的上下文应该怎么拼？

先给结论：长文档、多文档和跨文档问题，不该都按“把前几条块直接拼起来”处理。长文档更需要恢复局部结构，多文档更需要来源分组，跨文档问题更需要按子问题或主题对齐。关键不是拼得更多，而是拼得更有层次。

很多系统在这类问题上容易犯同一个错误：

• 不管问题来自一篇文档还是多篇文档，都统一把若干 chunk 直接按分数往下拼

这个策略在简单问答里还能勉强工作，但一旦问题范围变大，就会出现：

• 信息碎
• 结构乱
• 来源混
• 模型不知道哪一段在回答哪一部分问题

一、长文档问题怎么拼

长文档问题的典型特征是：

• 证据集中在一篇文档里
• 但需要跨多个段落或章节
• 单个块通常不够完整

这时上下文组织应该更偏向：

• 恢复章节或局部结构
• 按文档内顺序放置关键片段
• 必要时补相邻块

更稳的做法通常是：

1. 先找出命中的关键块
2. 判断这些块是否集中在同一章节或相邻区域
3. 如果是，就按文档顺序做小范围合并
4. 再把结果送给模型

如果仍然直接堆零散块，模型就很容易：

• 只看到答案片段
• 看不到前置条件和限制
• 不知道这些片段在原文里的关系

二、多文档问题怎么拼

多文档问题的典型特征是：

• 相关证据分布在多篇文档里
• 每篇文档都只回答一部分
• 模型需要综合多个来源

这时最重要的不是把所有块混排，而是：

• 保持来源边界清晰

更稳的上下文组织通常是：

• 先按文档分组
• 每个文档内只保留最关键的若干块
• 再按来源展示给模型

这样做的好处是：

• 模型更容易知道每条证据来自哪
• 不容易把不同文档的内容混成一个连续叙述
• 更适合后续做引用和归因

三、跨文档问题怎么拼

跨文档问题和多文档问题很像，但重点更强地放在：

• 不同来源之间的关系处理

比如：

• 文档 A 给定义，文档 B 给例外，文档 C 给落地步骤
• 新版本文档给主规则，旧公告解释变更原因

这类问题里，如果只是简单按分数堆块，模型很容易：

• 只围绕某一个来源展开
• 把互补关系误当成重复关系
• 漏掉跨文档的因果或条件关系

更稳的做法往往是：

• 先按主题或子问题拆开
• 再在每个子问题下组织不同来源的证据

一个更实用的组织思路

可以把三种情况粗略理解成：

• 长文档：优先恢复文档内部连续性
• 多文档：优先保持来源分组
• 跨文档：优先建立主题对齐关系

一个最小示意

if scope == "long_document":
    context = merge_by_section_and_order(candidates)
elif scope == "multi_document":
    context = group_top_chunks_by_document(candidates)
elif scope == "cross_document":
    context = organize_by_subquestion_and_source(candidates)

这段代码想说明的是：

• 文档范围不同，最终上下文结构就该不同

一个常见误区

很多人会把“长文档、多文档、跨文档”理解成：

• 只是需要更多 token

这不够准确。它们当然常常需要更多预算，但真正更关键的差别在于：

• 这些材料之间的组织关系不同

如果只加预算、不改结构，模型仍然可能答得很乱。

一句话总结

长文档、多文档、跨文档问题的上下文不能按同一种方式拼。长文档要优先恢复局部连续性，多文档要优先保持来源边界，跨文档要优先建立主题或子问题对齐关系。真正高质量的拼接，不是把更多块堆在一起，而是让模型更容易看懂这些块之间的关系。