调用 GPTs 处理超长文本时，上下文窗口、分块重叠与截断参数该怎么调才不丢关键信息？

用 GPTs 处理超长文本时，正确的调法是先把可用输入预算算出来：以模型官方文档标注的上下文窗口为总盘子，减去 max_tokens 预留的输出空间，剩下的才是正文加提示词能占用的上限。max_tokens 在多数接口里约束的是模型输出长度，不负责截断输入，把它当输入阀门是最常见的误用。文本量只有几百字的单轮问答不适用这套流程，直接整段传入即可。 窗口额度与输出预算必须分开设，这是长上下文参数调整的第一条原则。输入超过窗口上限时，接口通常直接返回错误而不是自动截断；输出预算给小了，回答又会在结尾处断句。可执行的做法是先固定一个业务上能接受的最长回答长度并留出余量，再倒推还能放多少正文，而不是先塞满文档再试错。 分块要按语义边界切，不要按固定字数硬切。按段落、标题层级或问答对切分，模型在块内看到的是完整论证；硬切会把一句话劈成两半，后续检索和归纳都会失真。块大小的判断标准是单块能独立读懂：长文摘要把块放大，逐条字段抽取则把块缩小，同一份文档在不同任务下块大小不该相同。 块与块之间要设重叠，重叠量由跨块信息密度决定。跨块的指代、表格续行、条款前后件最容易在边界处丢失，重叠就是给这些信息留缓冲。重叠过大会让输入量成倍上升，并引入重复计数；抽取类任务用小重叠，合同、法规这类前后强关联的文本适当加大重叠，并在合并结果时按块编号去重。 截断策略优先保头保尾，中间段做摘要压缩。系统提示、输出格式要求和用户最新问题属于不可截断区；文档开头通常交代背景与结论，结尾往往是总结，两头都值得保留。中段大篇幅的背景材料可以先用一次低成本调用压成要点，再拼回主请求；只做简单截尾，模型就看不到尾部结论。 该用检索还是塞满长上下文，取决于问题类型。需要从长文里定位某几处事实时，检索召回相关片段命中更准、成本更低；需要通读全文做整体判断、找矛盾、做全局归纳时，才值得动用超长上下文。每个单点问答都把整本文档重传一遍，是最常见也最容易被忽视的浪费。 长上下文请求要把流式、超时和重试三件事一起设。输入越长，首字节和整体耗时越长，非流式请求往往在网关处先超时；开启流式并按增量渲染，超时阈值要覆盖最慢的一次调用。重试必须幂等，否则同一个长请求重复计费、重复写入下游，排查时会误判成模型不稳定。 抽取类任务把 temperature 压低并加结构化输出约束，通常比继续调分块更有效。低 temperature 能减少字段名漂移与漏项，schema 约束让输出稳定可解析，省掉大量后处理。创意归纳类任务可以适度调高，但分块摘要阶段就要统一风格与字段口径，否则合并后的结果会前后不一致。 成本主要由输入 token 决定，长上下文的账单随文本量近似线性增长。同一份长文档被反复提问时，提示词缓存和一次摘要多次复用能明显摊薄单次成本；每次重传全文再加上全量历史，是最贵的用法。评估成本要按每次问答的实际输入 token 数来算，而不是按文档总字数算。 多轮对话的历史不能无限追加，要设滚动摘要与保留窗口。做法是保留最近若干轮原话，把更早的对话压缩成要点并标注轮次；每到约定轮次重新生成摘要，防止摘要本身越滚越大。只靠调大窗口硬撑多轮，延迟和费用会同步上涨，而模型对中段历史的注意力反而下降。 可观测性决定你能不能定位信息是在哪一步丢的。每次请求记录实际输入 token 数、分块编号、是否触发截断或摘要、输出是否被 max_tokens 截尾，出现答非所问时先查这些标记，再怀疑模型能力。没有这层记录，参数调整只能靠猜，换一个模型也无法复现问题。 一条可执行的调参顺序是：先定输出预算，再按语义切块并设重叠，再定截断与摘要规则，最后压 temperature 并加 schema 约束。顺序反过来，先调温度或先换模型，通常解决不了超长文本丢信息的问题。每次只改一个参数并保留同一组对照样本，才能判断这次改动是真的有效，还是碰巧看上去变好了。