Workbuddy 长文本 API 预切分功能怎么开启？开关位置、单段阈值与重叠窗口分别该怎么配？

Workbuddy 的长文本 API 预切分默认关闭，需要在调用长文档接口之前，先在控制台的长文本处理设置里打开预切分开关，再通过请求参数把单段字符上限与分段重叠窗口传给服务端；短文本请求，以及必须依赖全文一次性推理的任务，不适用这套配置。判断是否开启的条件只有一条：输入长度存在超出模型单次上下文窗口的可能，超出才开，不超出就保持关闭，以减少不必要的分片开销。 预切分是在请求前完成的拆分，并不依赖模型内部的滑动窗口。它在请求体进入推理之前，按配置规则把长文档切成若干片段，逐段送入模型，再把各段结果按原顺序拼回。区别在于上下文是否完整保留：模型自带的窗口截断会直接丢内容，预切分会把内容保留下来，但变成多次调用，因此返回的是分片结果的集合，并非一段文本。 开关入口通常位于控制台的长文本处理或文档解析模块，具体菜单名以 Workbuddy 官方说明为准。进入后一般能看到三个需要填写的项：预切分总开关、单段字符上限、相邻片段重叠字符数。只打开总开关而不填后两项，多数情况下会退回默认分段规则，长表格和带层级的文档容易出现半句截断。 API 侧的关键是让参数真正传到服务端，不能只在前端页面上显示为已开启。常见做法是在请求体里显式声明切分策略字段，并在 SDK 升级后核对字段名有没有被改名；通过自建网关转发的场景，还要确认网关的请求白名单没有把这个字段过滤掉。如果使用的是老版本 SDK，参数可能被直接丢弃，表现出来就是设置页已经打开，但响应仍是单段。 单段字符上限应当按目标模型的上下文窗口留出余量来设定，不要紧贴着上限。余量的作用有两处：一是为系统提示词和输出内容预留空间，二是给重叠窗口留出位置。重叠窗口让相邻片段共享少量尾部文本，防止关键结论正好落在切口处；重叠太小会丢上下文，太大会让重复内容推高 token 消耗。 切分策略要按文档形态选，不能一套规则走完所有场景。结构化程度高的文档按标题层级或分隔符切，能保证每段语义完整；代码和配置文件按语法块切，避免切在函数中间；表格优先整体保留，宁可单段超出上限，也不要拆散行列之间的对应关系。纯语义切分对叙述型长文效果更好，但耗时和不确定性都高于规则切分。 验证预切分是否真正生效，看返回结构里的分片数量比看设置页状态更可靠。正常生效时，响应会带上分片计数、每片字符数或 token 数，以及最终合并后的文本。若分片计数恒为 1，说明请求没有进入切分逻辑；若分片数远高于按字符上限估算的数量，则可能是重叠窗口设得过大，或者分隔符规则过密。 开启后不生效，排查顺序是先看缓存，再看参数，最后看版本。长文本接口常有结果缓存，相同内容重复请求会直接命中旧结果，看起来像没开；其次确认请求里没有另一处参数覆盖了切分配置；最后核对 SDK 与服务端接口版本是否匹配。顺序颠倒会浪费时间，因为缓存造成的假象最容易复现，也最容易排除。 预切分会改变成本结构，但不会必然让总消耗上升。分片后请求次数增加，每次都要重新携带系统提示词，这部分是净增；同时单片内容变短，单次输出更聚焦，重复推导的部分减少。真正推高成本的是重叠窗口和分片数量同时放大，所以在长文档批量处理时，建议先拿少量样本比对分片前后的总 token 再决定参数。 需要跨段推理的任务不适合开预切分，典型的是全文摘要、跨章节比对和整份合同的风险扫描。这类任务依赖片段之间的相互引用，切分后再拼接会丢失指代关系。可用的折中是两层结构：先切分做要素抽取，再对抽取结果做一次汇总调用，把跨段推理放到汇总层完成，而不是指望分片结果自动保持全局一致。 分片后的元数据要保留，否则后续无法定位问题。建议在请求侧记录原文标识、分片序号、切口位置与所用规则版本，返回结果按同一套标识回写。这样出现结论缺失时，能判断是切口切掉了内容，还是合并环节顺序错乱。对需要留痕的业务，分片日志与原文摘要应一并归档，并且不要把带敏感字段的片段写进普通运行日志。 上线前用真实长文档做一轮灰度，比在测试集上调参数更有意义。选覆盖标题、表格、代码三类结构的样本，分别记录分片数、切口是否落在句子中间、合并后是否出现重复段落。参数一旦定稿就写入配置版本号，后续更换模型或调整上下文上限时按版本回溯，避免旧配置在新模型上产生过多分片。