GPTs 要处理超长文本上下文，API 侧的 max_tokens、截断策略和温度参数应该怎么调整？

GPTs 本身不提供可直接调整的上下文类 API 参数，超长文本必须在调用侧解决。GPTs 的自定义界面只暴露知识文件、指令和 Actions，真正决定能塞进多少上下文的是那个被调用的接口。所以想突破窗口限制，做法是让 GPTs 通过 Actions 调用你自己的服务，在服务里对请求做 token 预算、截断和参数设置；如果只在上传知识文件、改 Instructions，任何参数调整都不会生效。 调参第一步永远是算 token，而不是先改参数。用与目标模型匹配的分词器在本地预估输入长度，把预算拆成三份：系统指令、检索或压缩后的正文、以及留给输出的空间。中文里一个汉字大致按 0.6 到 1 个 token 估算，标点和英文单词另算；估算不准时宁可多留两成余量，否则收到的是上下文超限报错，而不是被温柔截断后的结果。 max_tokens 限制的是模型输出长度，不是输入长度，这一点最常被搞反。设得过大不会扩大输入窗口，设得过小则长摘录、长结构化输出会被硬截断，出现句子中断或 JSON 不闭合。稳妥做法是按任务类型给上限：摘要和改写类给足输出空间，分类、抽取类收紧到实际需要的一两百 token，把省下的预算留给输入。 解码类参数在长上下文任务里应当偏保守。temperature 建议压到 0.2 至 0.3，top_p 保持默认不再叠加，长文理解需要的是复述与定位而不是发挥。温度调高在长输入上不会提升理解质量，只会让引用原文时出现改写和幻觉。 frequency_penalty 和 presence_penalty 在长文本场景建议归零。这两个参数的设计目标是抑制重复，但长摘录、法规条款、代码这类内容天然重复，惩罚项会迫使模型改写原文。只有在生成式写作、需要避免话术复读时才把它们调成正值。 上下文的可用长度不等于有效注意力长度，关键信息要放两头。长输入存在中间位置信息被忽略的现象，同一段材料放在开头或结尾的召回率明显高于放在中段。落地做法是把角色设定、硬性约束、输出格式放在 system 消息最前面，把这次要问的具体问题追加在最后一条 user 消息里。 超长文本的处理策略只有三类，选错策略比调错参数损失更大。查询针对单点事实，走检索，只把相关片段拼进上下文；查询需要全局结论，走 map-reduce，先分块摘要再合并；查询必须保留完整原文且不能被改写，才考虑滑窗逐段处理，并让相邻窗口重叠若干句子。 对话历史的裁剪要和参数一起调，否则单轮不超限、多轮必然超限。规则是永远保留 system 消息、保留最近若干轮原文，把更早的轮次替换成一段结构化摘要。使用助手类接口时可选的截断策略通常包含自动截断与保留最近消息两种，前者按 token 顺序丢弃，后者保住近期上下文，需要明确设置提示 token 上限，否则默认行为可能不是你要的那一种。 流式输出、前缀缓存和超时是长输入下最容易被忽略的三个工程参数。开启流式可以避免长输入长输出时连接空闲超时；把固定不变的长前缀，比如系统指令、手册、规范，放在请求最前面，可以命中前缀缓存来降低重复计算成本与首 token 延迟；单次请求超时时间要按最长输入重设，并配合指数退避重试。 分块抽取类任务要把块大小、重叠量和合并方式当成参数来调。块太大，单块塞不进预算；块太小，语义被切断导致抽取遗漏。通常让相邻块保留一段重叠文本，再用一次合并调用去重、对齐字段，比一次性塞入整篇文档更稳定，也更容易定位错误出在哪一块。 成本结构与参数直接相关：长上下文任务里输入 token 通常占大头，输出反而是小头。因此降低单价的杠杆不是调温度，而是减少重复输入，包括缓存固定前缀、检索只取相关片段、把已处理过的中间结论固化进摘要。把输入用量和截断点打进日志，才能判断某次调参到底省了钱，还是只是换了种报错方式。 落地顺序建议固定为四步：先量 token，再定截断或检索策略，然后设 max_tokens 与温度、惩罚项，最后压测并记录。反过来先调温度、再发现超限，是最常见的返工路径。任何一次参数调整都应当在固定测试集上对比，而不是凭单次对话的手感判断。