Step 5 Preview 的上下文窗口没有一个可以靠猜确定的固定值：同名版本在不同后端、不同部署参数、不同网关配置下，能看到的行为都可能不一样。可靠做法是先用长度梯度文本试探，再在请求日志里找截断点或长度报错，确认实际被接受的最大输入长度；然后在同一份长文上分别跑“整篇传入”和“按粒度分段传入”，看跨段问答的细节是否丢失；最后按测试结果定分段长度和重叠窗口。整篇传入适合总长度明显低于截断点、且问题依赖全文关系的场景；分段传入适合超长文档，但必须用重叠窗口补回段落边界处的信息。

不要去问一个别人报的“最大 token 数”然后直接套用。先用长度梯度测试文本确认本环境实际接受的输入长度，再用两个跨段问答对比整篇与分段的返回完整度，用日志记录输入长度、是否截断、有无长度错误。分段时给相邻块留出重叠窗口，重叠部分至少覆盖一个完整语义单元；如果测试发现关键词被切在块边界，就加大重叠或调整切分位置。这条路径只保证行为可观察、可复现，不保证某个具体上限值。

构造不同长度的测试文本

目的是找到“可能开始被截断”的长度区间，而不是一次就问出精确上限。做法是准备同一份内容结构稳定、语义连续的基础文本，用无意义填充段把它撑到不同长度，依次递增发送，观察返回内容是否变短、是否只回答后半段、是否直接报长度错误。

常见的长度梯度可以这样排（数值只是分层示意，不代表模型上限，具体按环境调整）：

• L1：约 2K 字符，作为明显不会出问题的基线。
• L2：约 8K 字符，覆盖一般中长文档。
• L3：约 16K 字符。
• L4：约 32K 字符。
• L5：约 64K 字符。
• 继续按倍数或加固定增量往上，直到出现截断或长度错误为止。

每次测试都用同一条问题，例如“请说出文档里提到的最小值出现在第几段”，保证问题指代清楚、答案可核对。把每一级的输入字符数、实际发出的请求、返回内容长度记录下来。不要写具体模型上限，只需要标出“这个长度开始出现异常”的区间，后面在日志里进一步确认。

在请求日志里找截断或长度报错

只看返回内容不够，必须看请求日志或网关日志。目标是确认服务端实际接收并处理的输入长度，而不是客户端以为发出去的长度。

打开请求日志、网关访问日志或模型调用日志（不同环境名称不同，按实际部署找），逐条记录以下字段：

1. request_id：本次请求标识，便于和返回内容对齐。
2. input_chars / input_tokens：请求中的输入长度，两个都记更好。
3. http_status 或错误码：有没有长度相关错误。
4. return_finish_reason / truncated：返回是否因为长度被截断。
5. output_length：返回内容的长度，明显偏短就要重点看。

可以先用命令行复盘日志（把日志路径和关键字换成你环境里的实际值）：

grep -i "length\|token\|truncat\|max_input" /path/to/request.log | tail -50

如果日志里出现明确的长度报错，就说明当前长度已经超过服务端接受的输入；如果返回被标记为截断，则输入可能被服务端裁掉了尾部或首部。把每个长度梯度对应的“请求输入长度、是否报错、是否截断”填进记录表，就能确定一个保守可用的输入区间：在这个区间内没有报错且返回完整。

对比整篇传入与分段传入的返回完整度

确认了可接受长度之后，还要判断同一份长文用整篇还是分段更靠谱。方法不是看谁更快，而是看答案有没有丢失细节。

设计两个必须跨段才能答对的问答，分别用两种方式测试：

• 问 A：文档开头提到的某个编号，在后半段对应的名称是什么。
• 问 B：文档中间列出的两个条件，在结尾处的结论里分别属于哪种情况。

测试顺序建议：

1. 先整篇传入，记录返回是否同时覆盖了前半段和后半段信息。
2. 再按固定长度分段传入，每段独立提问，记录每段回答了什么。
3. 把两种方式的结果并排，列出“整篇答对而分段答错”和“分段答对而整篇漏掉”的条目。

如果整篇传入明显更完整，而且输入长度在日志确认的安全区间内，就优先整篇；如果整篇传入开始丢后半段，而分段能答对大部分独立问题，就转分段，并着手处理跨段依赖丢失的问题。

标记跨段依赖问答丢失的位置

分段最大的风险是跨段关系被切断。处理办法是逐段标注，而不是凭感觉判断。

把长文按当前分段策略切开，给每段编号，然后做一张标注表：

• segment_id：段落编号。
• 关键信息：这一段里有哪些实体、条件、编号、结论。
• 依赖关系：本段信息需要哪一段才能完整解释。
• 问答缺失项：问 A 或问 B 时，本段是否提供了必要线索。

标注重点是找出“信息在一段、解释在另一段”的位置。典型如条件分散、结论后置、代词指向上文、编号定义在下文等情况。发现缺失项后，把这些段落对记录下来，它们是接下来加大重叠窗口或调整切分粒度的依据。

确定分段大小和重叠窗口

根据前面的测试结果，选一个不会触发长度报错、又尽量能容纳完整语义单元的分段长度。保守做法是从明显安全的长度往下选，例如日志确认可接受输入在某个区间时，分段长度取该区间的中低值，而不要把分段塞到接近上限。

重叠窗口的作用是让相邻段共享边界信息。通用建议：

• 分段长度：优先按自然段、章节或语义块切，不要按固定字符硬切；如果必须按字符切，选一个能容纳多数完整段落的长度。
• 重叠比例：可以先取分段长度的 10%–20%；如果标注表里跨段依赖多，就提高到 20%–30%。
• 重叠内容：至少覆盖一个完整语义单元，例如一个小节标题加其下第一段，避免把一句完整话和一个关键编号切在两边。

切分后要用同一组问答复测，验证方式固定为：再用问 A 和问 B 跑一遍，确认缺失项减少；再回看请求日志，确认每段输入长度都不触发报错和截断。如果仍有跨段信息接不上，就提高重叠比例或调整切分点，不要靠加大整篇传入硬扛。整个过程以日志和问答结果为准，换了模型、网关或部署参数后，需要重新测一遍。