无上限长文本翻译的秘密深度解析TranslateBooksWithLLMs的Token分块与重组原理【免费下载链接】TranslateBooksWithLLMsTranslate full-length books and documents with Ollama, OpenAI-compatible, Gemini, Mistral, DeepSeek, Poe or OpenRouter. Preserves formatting. Resumes where you left off. No file size limits.项目地址: https://gitcode.com/gh_mirrors/tr/TranslateBooksWithLLMsTranslateBooksWithLLMs 是一款能翻译整本书的 AI 桌面应用它的核心秘密在于一套Token 分块与重组机制把几百页的长文档切成 LLM 能消化的片段逐块翻译再无损拼回原文。无论你的书有多大翻译过程始终有界、可控、可中断恢复。这篇文章将带你拆解这套机制的三大原理Token 预算分块、上下文桥接和标记化重组。为什么长文本翻译必须分块大语言模型有一个上下文窗口的天花板——一次对话能容纳的 Token 数量是固定的。一本几十万字的小说直接丢给模型要么被截断要么质量崩盘。最粗暴的解法是按字数硬切但这样做会切在句子中间、打散段落模型看到的前后文毫无关联译文就会失忆人名忽男忽女、语气前后矛盾、段落结构错乱。TranslateBooksWithLLMs 的答案是用 Token 计量按自然边界切割切的时候留好接缝标记和上下文桥。原理一基于 Token 计量的软限制分块核心实现位于 token_chunker.py其中的TokenChunker类负责所有分块工作精确计数使用tiktoken的cl100k_base编码统计 Token与主流模型的分词方式一致切出来的块大小对模型刚刚好。软限制策略块并不一定攒满上限才切。当累积量达到上限的80%由 config.py 中的SOFT_LIMIT_RATIO控制时分块器就开始寻找下一个自然边界段落或句子结尾收刀让每块都停在语义完整的位置。三级降级切割段落太大就切成句子识别.!?及多语言句末标点见SENTENCE_TERMINATORS句子还太大、且是多行文本比如一章一行的网络小说就再按行切。递归处理直到每块都装得下。碎片合并小于上限 25% 的零碎块不会单独存在而是并入相邻内容避免产生大量迷你请求拖慢速度、浪费 Token。分块入口函数是 text_processor.py 中的split_text_into_chunks()TXT、EPUB、DOCX 等格式的适配器都通过它获得统一的切块结果。原理二上下文桥接让每块译文记得前后切块必然带来信息损失TranslateBooksWithLLMs 用两招补回来前后文窗口每个分块在送进模型时都附带context_before上一块的结尾段和context_after下一块的开头段。模型虽然只负责翻译main_content但它看得见前后各一句足以保持指代、语气一致。译文链顺序翻译模式下模型还会收到上一块译文末尾的若干词作为行文语境相当于让 AI 接着自己的笔锋往下写跨块的行文风格自然连贯。这套结构在 txt_adapter.py 中被封装为TranslationUnit内容 前文 后文一个翻译单元三位一体。原理三标记化重组切在哪、就在哪拼回去分块时最容易翻车的环节是拼回去如果统一用空行连接所有块那么在段落中间切开的句子重组时会被误加空行凭空造出一个新段落。TranslateBooksWithLLMs 的解法优雅而务实——每个分块在切出时就随身携带一个接缝标记join_with字段记录它当初是用什么分隔符与前一块分开的段落之间切开 → 标记为空行句子之间切开 → 标记为空格行之间切开 → 标记为换行重组时reassembly.py 中的join_translated_chunks()严格按照每块自带的标记拼接。切在哪就在哪拼回去段落结构分毫不差。更贴心的是任何一块翻译失败会自动用原文兜底保证输出文件永远完整旧版检查点缺失标记时则回退到默认空行连接兼容性拉满。对于 EPUB/DOCX 的纯文本模式plain_text_pipeline.py 更进一步分块时记录每块覆盖的源段落索引重组时按索引精确写回超大段落被拆成的多个句子块最终折叠回同一个段落槽位。连模型多写/少写段落的情况都有数量校验 → 整段重试 → 逐段修复的三级保险。质量护栏与断点续传分块翻译还有一层隐性风险模型可能偷懒提前收尾译文长度骤减。txt_adapter.py 中的validate_unit_translation()会比对源文本与译文的 Token 比例低于阈值默认 25%见MIN_TRANSLATION_LENGTH_RATIO就判定疑似跳段并触发重译。配合自动检查点checkpoint系统每翻译若干块就落盘一次进度。翻译中断、断网、限流重启后从最近的检查点继续已完成的块绝不再重复消耗 Token——这正是无文件大小上限承诺的底气不是文件真的不受限而是进度永远可以接力。参数速查如何调整你的分块预算参数默认值作用MAX_TOKENS_PER_CHUNK450每块 Token 硬上限可在 Web UI 运行时热改SOFT_LIMIT_RATIO0.8软限制比例决定提前收刀的位置MIN_TRANSLATION_LENGTH_RATIO0.25译文长度护栏阈值防模型跳段简单原则小模型7B 以下调小MAX_TOKENS_PER_CHUNK如 256~350降低单次推理压力大模型可适度调大如 600~800减少请求次数、加快整书翻译。结语长文本翻译的本质难题是把无限长的任务装进有限的上下文窗口。TranslateBooksWithLLMs 用Token 精确计量 自然边界切割 接缝标记重组 上下文桥接四板斧让每一块都切得干净、翻得连贯、拼得无痕。理解了这套 Token 分块与重组原理你不仅能更聪明地配置分块参数也能看懂绝大多数分块翻译方案的底层逻辑。关键源码索引分块核心src/core/chunking/token_chunker.py重组核心src/core/chunking/reassembly.py纯文本流水线src/core/common/plain_text_pipeline.py参数配置src/config.py【免费下载链接】TranslateBooksWithLLMsTranslate full-length books and documents with Ollama, OpenAI-compatible, Gemini, Mistral, DeepSeek, Poe or OpenRouter. Preserves formatting. Resumes where you left off. No file size limits.项目地址: https://gitcode.com/gh_mirrors/tr/TranslateBooksWithLLMs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/4 7:38:02 · 阅读 1.2k 无上限长文本翻译的秘密：深度解析TranslateBooksWithLLMs的Token分块与重组原理
无上限长文本翻译的秘密深度解析TranslateBooksWithLLMs的Token分块与重组原理【免费下载链接】TranslateBooksWithLLMsTranslate full-length books and documents with Ollama, OpenAI-compatible, Gemini, Mistral, DeepSeek, Poe or OpenRouter. Preserves formatting. Resumes where you left off. No file size limits.项目地址: https://gitcode.com/gh_mirrors/tr/TranslateBooksWithLLMsTranslateBooksWithLLMs 是一款能翻译整本书的 AI 桌面应用它的核心秘密在于一套Token 分块与重组机制把几百页的长文档切成 LLM 能消化的片段逐块翻译再无损拼回原文。无论你的书有多大翻译过程始终有界、可控、可中断恢复。这篇文章将带你拆解这套机制的三大原理Token 预算分块、上下文桥接和标记化重组。为什么长文本翻译必须分块大语言模型有一个上下文窗口的天花板——一次对话能容纳的 Token 数量是固定的。一本几十万字的小说直接丢给模型要么被截断要么质量崩盘。最粗暴的解法是按字数硬切但这样做会切在句子中间、打散段落模型看到的前后文毫无关联译文就会失忆人名忽男忽女、语气前后矛盾、段落结构错乱。TranslateBooksWithLLMs 的答案是用 Token 计量按自然边界切割切的时候留好接缝标记和上下文桥。原理一基于 Token 计量的软限制分块核心实现位于 token_chunker.py其中的TokenChunker类负责所有分块工作精确计数使用tiktoken的cl100k_base编码统计 Token与主流模型的分词方式一致切出来的块大小对模型刚刚好。软限制策略块并不一定攒满上限才切。当累积量达到上限的80%由 config.py 中的SOFT_LIMIT_RATIO控制时分块器就开始寻找下一个自然边界段落或句子结尾收刀让每块都停在语义完整的位置。三级降级切割段落太大就切成句子识别.!?及多语言句末标点见SENTENCE_TERMINATORS句子还太大、且是多行文本比如一章一行的网络小说就再按行切。递归处理直到每块都装得下。碎片合并小于上限 25% 的零碎块不会单独存在而是并入相邻内容避免产生大量迷你请求拖慢速度、浪费 Token。分块入口函数是 text_processor.py 中的split_text_into_chunks()TXT、EPUB、DOCX 等格式的适配器都通过它获得统一的切块结果。原理二上下文桥接让每块译文记得前后切块必然带来信息损失TranslateBooksWithLLMs 用两招补回来前后文窗口每个分块在送进模型时都附带context_before上一块的结尾段和context_after下一块的开头段。模型虽然只负责翻译main_content但它看得见前后各一句足以保持指代、语气一致。译文链顺序翻译模式下模型还会收到上一块译文末尾的若干词作为行文语境相当于让 AI 接着自己的笔锋往下写跨块的行文风格自然连贯。这套结构在 txt_adapter.py 中被封装为TranslationUnit内容 前文 后文一个翻译单元三位一体。原理三标记化重组切在哪、就在哪拼回去分块时最容易翻车的环节是拼回去如果统一用空行连接所有块那么在段落中间切开的句子重组时会被误加空行凭空造出一个新段落。TranslateBooksWithLLMs 的解法优雅而务实——每个分块在切出时就随身携带一个接缝标记join_with字段记录它当初是用什么分隔符与前一块分开的段落之间切开 → 标记为空行句子之间切开 → 标记为空格行之间切开 → 标记为换行重组时reassembly.py 中的join_translated_chunks()严格按照每块自带的标记拼接。切在哪就在哪拼回去段落结构分毫不差。更贴心的是任何一块翻译失败会自动用原文兜底保证输出文件永远完整旧版检查点缺失标记时则回退到默认空行连接兼容性拉满。对于 EPUB/DOCX 的纯文本模式plain_text_pipeline.py 更进一步分块时记录每块覆盖的源段落索引重组时按索引精确写回超大段落被拆成的多个句子块最终折叠回同一个段落槽位。连模型多写/少写段落的情况都有数量校验 → 整段重试 → 逐段修复的三级保险。质量护栏与断点续传分块翻译还有一层隐性风险模型可能偷懒提前收尾译文长度骤减。txt_adapter.py 中的validate_unit_translation()会比对源文本与译文的 Token 比例低于阈值默认 25%见MIN_TRANSLATION_LENGTH_RATIO就判定疑似跳段并触发重译。配合自动检查点checkpoint系统每翻译若干块就落盘一次进度。翻译中断、断网、限流重启后从最近的检查点继续已完成的块绝不再重复消耗 Token——这正是无文件大小上限承诺的底气不是文件真的不受限而是进度永远可以接力。参数速查如何调整你的分块预算参数默认值作用MAX_TOKENS_PER_CHUNK450每块 Token 硬上限可在 Web UI 运行时热改SOFT_LIMIT_RATIO0.8软限制比例决定提前收刀的位置MIN_TRANSLATION_LENGTH_RATIO0.25译文长度护栏阈值防模型跳段简单原则小模型7B 以下调小MAX_TOKENS_PER_CHUNK如 256~350降低单次推理压力大模型可适度调大如 600~800减少请求次数、加快整书翻译。结语长文本翻译的本质难题是把无限长的任务装进有限的上下文窗口。TranslateBooksWithLLMs 用Token 精确计量 自然边界切割 接缝标记重组 上下文桥接四板斧让每一块都切得干净、翻得连贯、拼得无痕。理解了这套 Token 分块与重组原理你不仅能更聪明地配置分块参数也能看懂绝大多数分块翻译方案的底层逻辑。关键源码索引分块核心src/core/chunking/token_chunker.py重组核心src/core/chunking/reassembly.py纯文本流水线src/core/common/plain_text_pipeline.py参数配置src/config.py【免费下载链接】TranslateBooksWithLLMsTranslate full-length books and documents with Ollama, OpenAI-compatible, Gemini, Mistral, DeepSeek, Poe or OpenRouter. Preserves formatting. Resumes where you left off. No file size limits.项目地址: https://gitcode.com/gh_mirrors/tr/TranslateBooksWithLLMs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考