长文档翻译的分段策略与上下文一致性：工程实现拆解

百页级文档的机器翻译，工程难点不在翻译本身，在「一致性」：一个词在第 3 章和第 47 章必须是同一个译法，一个缩写从首次出现起就得固定下来。把整篇文档一次性交给模型做不到这一点——上下文窗口装不下，就算装得下，注意力也会稀释。分段是必然选择，而分段带来四个必须想清楚的工程决策。

决策一：按什么粒度切

按字符数硬切是最差方案——会把句子拦腰斩断，也会把图表注释和正文混进同一段。实践中最稳的粒度是结构单元：按标题层级切到三级，三级之内再按段落合并到目标长度。段落边界天然是语义边界，模型在段间丢失的上下文远小于句间。

一个容易忽略的细节：表格和代码块必须整体成段，绝不能参与段落合并。表格被拦腰切开后的翻译结果基本不可用，而且这种损坏在读回校验时不容易发现——每个单元格看起来都翻译了。

决策二：上下文怎么带

分段翻译最大的代价是每段都「失忆」。两种补偿方式：滑窗法把前一段的末尾 N 句拼进当前段的输入但不翻译（只作上下文），摘要法在每段翻完后生成一句摘要传给下一段。滑窗实现简单、效果直接，是首选；摘要法适合滑窗装不下的超长场景。

滑窗的坑在于窗口内容的截断方式：必须按完整句子截，截半个句子进去反而引入噪声。窗口大小取两到三句即可，更大没有可测的收益。

决策三：术语怎么锁

术语一致性的可靠解法不是靠模型自觉，是靠注入：术语表（源词→固定译法）作为约束随每段输入下发，输出后用确定性校验核对术语命中。这里有个工程要点——术语表要区分「硬约束」和「软建议」：产品名、法规名、机构名是硬约束，输出必须逐字命中校验；一般术语是软建议，只做一致性检查不强制。

术语表本身从哪来？冷启动可以用原文词频加人工圈定：抽取全文高频名词短语（500 词以上文档通常 50~200 个），人工确认译法，一次投入全程受益。

决策四：多章怎么对齐

分章并翻之后要合回去，对齐错误是长文档翻译的最后一类事故：章序错乱、图表错位。可靠做法是翻译前给每个结构单元编全局序号，把序号作为元数据随任务走，合并时按序号重排而不是按返回顺序。返回顺序在任何异步并发的架构里都不可信。

验证方法

四个决策各自给一条验证线：切分质量看「被拦腰对象数」（应为 0）；上下文效果抽样对比带窗与不带窗的指代消解正确率；术语用确定性校验的全篇命中一致率；对齐用合并后的目录比对。四条都过，长文档翻译才算工程可用。