最近在处理一批压箱底的文档翻译任务时我彻底重构了一遍自己的工作流。手头是7份技术手册和产品规范加起来将近400页里面各种大段说明文字、数学公式、代码清单和参数表格混在一起。一开始想偷个懒用在线翻译工具凑合跑结果第一份文档翻完就傻眼了公式乱掉、术语前后不统一、表格排得面目全非。后来我改成基于大模型API做批量翻译顺手搭了一个叫LLMFanyi的小工具把文档输入、分块、翻译、还原整条链路跑通之后原本要磨一周的活一个晚上就处理完了。这篇文章就是把这套批量翻译方案的选型思路、工程实现、常见坑位完整拆一遍适合需要批量处理外文技术文档、论文和产品说明书的同学参考。1. 先搞懂批量翻译到底难在哪1.1 为什么人工翻译和普通机器翻译都撑不住回到最朴素的场景一份外文技术手册满屏小标题、图表编号、数学公式还有一堆特有的缩写词。人工翻译的质量确实是最好的但瓶颈非常明显——慢、费脑、极其依赖术语一致性。术语一致性这个东西文档越长越要命。前面第二章把某个词翻成处理器后面第四章又变成中央处理单元读者马上就会被绕晕。一个人从头翻译到尾都容易这样更别提多人按章节分工协作每个人各翻各的术语风格很难统一。普通机器翻译又走到另一个极端速度快、成本低但几乎不真正理解上下文。它对公式、代码块、内联标记比如LaTeX的$...$、Markdown里的代码块处理得非常莽要么把公式也强行翻译一遍要么把代码里的变量名改成英文直译甚至直接把标记符号吞掉。更难受的是长句子经常前半句和后半句语义对不上读起来像是被揉成一团的纸。大模型接口的出现算是同时补上了这两块短板它带上下文窗口能理解一段话前后的关系指令跟随能力也强你告诉它公式保持原样、代码不要翻译、术语按对照表来它基本会照做。但大模型API也不是开箱即成的翻译工具。它不会自动把400页文档变成几十个请求发出去更不会帮你处理并发、重试、断点续传这些问题。所以批量翻译真正的难点其实不在翻译这两个字上而是在于怎么设计一套流程把长文档拆成模型能吃进去的一块块内容再把结果安全地拼回来。1.2 批量翻译的公式长什么样我做这个批量翻译工具时把所有问题收敛成了一句话先把脏乱的长文档变成规格统一的中间格式再把它拆成适合模型处理的小块逐块翻译完成后按原顺序合并。这套流程我拆成了四个环节输入清洗、分块调度、模型翻译、还原合并。任何一篇文档的批量翻译都可以套进这四个环节区别只在于每一环的具体做法。输入清洗是第一个容易被忽略的环节。PDF转出来的文本经常带着莫名其妙的换行和空格Word文档里残留各种样式标记不先统一成干净文本后面分块和翻译都会埋坑。我习惯把所有输入统一转成Markdown因为Markdown能用结构化语法表达标题层级、代码块、表格、公式而这些结构正是翻译时需要重点保护的。分块调度是决定质量上限的关键环节。模型有上下文长度限制一次性塞整章内容大概率超限反过来如果把文本按一行一行切上下文完全丢失术语一致性一定会崩。我的处理方法是按标题加自然段落切块单块控制在千字以内同时把前一块译文摘要带进请求给模型续上上下文。模型翻译这步质量主要由提示词决定。一份合格的翻译提示词至少要包含角色设定、翻译规则、术语对照表、输出格式要求。温度参数要调低翻译任务不需要模型自由发挥。还原合并听起来机械但不做的话前功尽弃。核心思路是分块时用占位符保护公式和代码翻译完成后再按标记替换回原始内容。这四个环节组合起来就是我说的批量翻译公式。你可以把它理解成一条流水线脏的原料进来经过四道工序变成干净的成品。每一道工序都能单独调试优化这也是我建议你借鉴整体思路、而不是照抄某一份脚本的原因。2. 工具选型与环境准备模型接口和运行依赖怎么选2.1 模型接口的三项权衡质量、成本、速度选哪家模型接口可以从三个维度来评估。质量方面翻译很吃上下文理解所以优先选指令跟随能力强、支持长上下文的模型接口。我实测下来的感受是能处理较长上下文、又专门做过语言语料优化的模型翻译技术文档时要稳很多术语不容易乱飘。普通在线翻译引擎完全做不到这个程度。成本方面大模型接口按token计费翻译任务的消耗分输入token和输出token。一个粗略的估算方法是1个汉字大约对应0.7到1个token英文则大约3到4个字符对应1个token。跑全量之前先用几页样本估算一下总token量再乘以单价心里就有底了。千万别上来就全量跑否则账单出来会很肉疼。速度方面串行一条条发请求最稳但慢并发能大幅提速但容易触发限流。关键是稳定地压着配额跑而不是一味追求并发数。我一般从并发4到6条开始跑观察错误率和响应耗时再逐步往上加加到自己能接受的抖动水平为止。这三者说白了是个三角要质量好往往价格不便宜要便宜质量可能打折要速度快就得接受并发带来的限流风险。我的折中方案是正式交付走质量优先的接口草稿和初翻走更便宜的备用接口代码不变只改配置项里的模型名。2.2 云端API还是本地推理框架这一步的选择直接决定成本和隐私边界。云端API的好处是零运维、按量付费、有问题不用自己扛。坏处是每次请求都要把文本送出内网如果是内部规范、未公开的技术方案这类敏感文档就不太合适。本地推理框架的好处是数据不出网长期跑大量任务时边际成本低。坏处是你需要一张能打的显卡并且要自己处理模型部署、量化、版本升级这些事。我一开始是纯云端把流程跑通后来量大了才把一部分重复性工作转回本地。如果你是个人使用、量也不大建议先走云端省下的那些钱可能还不够你折腾推理环境的时间成本。2.3 最小运行环境准备到代码层面依赖其实非常轻。只需要Python环境外加两个常见库一个负责发HTTP请求一个负责解析JSON不需要引入重型框架。我搭的项目结构大概长这样LLMFanyi/ ├── config.yaml # 模型名、接口地址、Key、并发数等配置 ├── utils.py # 公共工具函数 ├── translator.py # 翻译主流程 ├── splitter.py # 文档分块与占位符保护 ├── resume.py # 断点续传逻辑 └── output/ # 翻译结果与进度记录配置文件的写法很直白核心字段包括接口地址、模型名称、Key、并发数、温度。这里要特别强调Key千万不要写死在代码里放进配置文件并加入忽略清单避免某天把脚本分享出去时把密钥一起泄漏出去。我在早期吃过这个亏后来养成了习惯所有密钥一律走环境变量或者外部配置。3. 实操过程一个可落地的批量翻译脚本是怎么跑通的3.1 输入清洗先把文档统一成Markdown接到一批文档我做的第一件事不是写翻译代码而是先把格式理干净。常用的转换路径是PDF走解析工具提取文本docx用脚本直接读。但无论哪种方式转换出来的Markdown都要人工抽查几页因为PDF里的多栏排版、页眉页脚、图片旁边的说明文字机器转换后经常错位。清洗阶段我有三条原则一是去掉页眉页脚和多余空行二是在标题、代码块、公式前后补上正确的Markdown标记三是清掉全角空格和行尾杂散空格。这些动作看着小但输入越干净后面分块越省心翻译质量也会更稳定。我见过有人跳过清洗直接切分结果整个表格被拆成碎片翻完根本没法看。3.2 分块与上下文管理怎么切才能保证术语一致分块逻辑可以总结成一句话以自然段落为基本单位不要硬按固定字数切。自然段落在语义上是完整的模型翻译时理解得更好。如果某个段落特别长超过模型窗口再按句子边界做二次切分。上下文管理是术语一致性的关键。我用的是双段落地方式请求体里包含当前块要翻译的内容同时把前一条已译好的译文摘要放到一个上文参考字段里。这样模型能看出这段还是在讲车间调度的事相同术语的处理方式就能延续下来。下面是我用过的分块函数简化版import re def split_blocks(text, max_chars800): paragraphs re.split(r\n{2,}, text.strip()) blocks [] current [] current_len 0 for p in paragraphs: if current_len len(p) max_chars and current: blocks.append(\n\n.join(current)) current [] current_len 0 current.append(p) current_len len(p) if current: blocks.append(\n\n.join(current)) return blocks逻辑很好懂先按空行切出段落再按800字上限把多个段落叠成一个块。块太小请求次数暴增成本上升块太大容易顶到模型窗口上限。800字是我反复试出来的平衡点你可以根据自己的模型窗口调整。这里顺便提醒一句切分时千万小心不要让代码块标记或者公式标记落在块边界上否则后面还原会出问题。3.3 模型接口调用与提示词设计翻译质量的上限接口调用本身没什么好说的无非是把消息组装好发出去拿到返回文本存起来。真正决定翻译质量的是提示词。我用的系统提示词包含四层内容角色设定你是资深技术翻译擅长把外文技术文档译成中文。硬性规则保留公式、代码、编号、表格结构不变术语必须按给定对照表翻译保持原文排版格式。上文参考前一块译文摘要。输出要求只输出译文正文不要解释或补充。请求之前我还会把术语对照表拼进提示词。每一条术语用原词指定译词的格式列出来模型基本会遵守。温度参数设置为0或接近0翻译任务不需要创造性稳定压倒一切。def build_system_prompt(terms, context): term_lines \n.join(f{k}: {v} for k, v in terms.items()) return ( 你是资深技术翻译擅长技术文档翻译。\n 规则公式、代码、编号、表格结构保持原样 术语必须使用以下对照表\n term_lines \n上文参考译文摘要\n context ) messages [ {role: system, content: build_system_prompt(terms, context)}, {role: user, content: block_text} ] payload { model: config[model_name], messages: messages, temperature: 0 }3.4 并发、重试与断点续传批量任务的稳定性批量任务跑到一半断掉是最崩溃的事。所以我的脚本从一开始就带断点续传每翻译完一个块就把结果连带块ID写进本地进度文件。下次启动时先读进度文件跳过已完成块只跑未完成的。这样即使电脑重启、接口报错、进程被杀任务也能接着跑不会一晚上白干。并发用线程池实现但要限制上限。为了不让接口限流我在请求失败时做退避重试第一次失败等3秒第二次等6秒第三次等12秒最多试5次。如果5次依然失败把这个块标记为待人工处理然后继续跑后面的块。这样接口抽风时整个任务也不会卡死最后再集中处理那些没跑成的极少数块。进度文件用JSON格式保存块ID是原文档里的绝对顺序编号这样合并还原时能按顺序恢复不会乱序。3.5 公式和代码的占位符保护让模型看不见不该动的部分承接着标题里公式两个字这里其实是实操中最值钱的一段。翻译技术文档时公式和代码直接出现在文本里模型经常忍不住去改。最简单的办法是分块时先把这些内容换成占位符。比如把E mc^2替换成{{FORMULA_001}}把代码块替换成{{CODE_BLOCK_002}}翻译完成后再替换回来。占位符要设计成一个整体不能拆进上下文里。我的保护逻辑是先用正则匹配出代码块和公式存成列表然后把原文中的匹配区域替换为占位符翻译结束后再按标记从列表里取回原始内容。模型全程看到的都是这个位置是一串看不懂的标记自然就不会乱动。这里给一个精简的示例placeholders re.findall( r(\$\$.*?\$\$|\$.*?\$|.*?), text, re.S ) for idx, ph in enumerate(placeholders): text text.replace(ph, f{{{{FORMULA_{idx}}}}})做这一步时要注意顺序先匹配代码块再匹配行内公式最后再匹配整段公式避免嵌套替换出错。我最初因为顺序反了导致不少公式被代码规则提前吞掉检查返工花了不少时间。4. 常见问题与排查技巧实录4.1 翻译结果出现乱码或格式丢失症状很容易认译文里出现成对的方括号、半个LaTeX标签或者表格整个散掉。排查顺序一般是先看原始块是否干净再检查分块时有没有把标记拦腰切断最后看后处理替换有没有遗漏。大多数情况下问题出在第二步所以我给分块函数加了一道标记完整性检查切出来的每个块所有代码块标记和公式标记必须成对出现否则强制把切分点挪到标记逻辑结束的位置。4.2 术语翻译前后不一致造成这个现象的原因有两个一是块与块之间没有上下文承接二是同一个词在不同位置被模型理解成不同含义。解决办法说来说去还是术语表前置把所有术语对照直接写进系统提示词并明确要求必须严格遵守不允许引入其他译法。再补一个事后校验技巧翻译完成后跑一遍术语校验脚本扫描译文中是否出现术语表之外的同义表达一旦发现就自动标记出来人工复核。经验之谈术语表越早建立返工越少。动手翻译前先通读一遍文档把高频术语和缩写整理成表这笔时间花得相当值。4.3 接口限流、超时与网络异常症状一般是连续发出请求时报限流错误或者超时。处理方法有三个调低并发数、加指数退避重试、在请求之间加固定停顿削峰。我常把后两种结合使用。贴一个重试封装的简化思路import time for attempt in range(config[max_retries]): try: resp http_post(payload) return resp except Exception: if attempt config[max_retries] - 1: mark_manual(block_id) return None wait_time config[base_wait] * (2 ** attempt) time.sleep(wait_time)网络异常不用在代码层面硬撑重试到上限后直接标记人工处理这是保底逻辑。日志一定要打全块ID、失败原因、第几次重试后面排查会省很多力气。4.4 成本超支怎么控制最实用的控费手段是缓存。同一篇文档如果被重复翻译先查缓存命中就直接返回历史结果。批次控制也很关键先跑一个十几页的样本估算出每页消耗的token量和对应费用再决定全量怎么跑。还有一点很多人不知道不要盲目调大输出长度限制。翻译的输出token和输入基本成正比设得过大只会浪费额度。4.5 断点续传里的两个隐蔽坑第一个坑是进度文件写得太频繁会拖慢整体速度。因为每写一次都是磁盘I/O并发场景下频繁写还可能造成文件锁冲突。我的方案是每完成一个块就写一次但不做实时同步刷盘。第二个坑是任务中断后进度文件里可能残留半条写入记录。我的做法是写入时先写完临时文件再改名避免读到残缺JSON导致整个进度崩溃。另外合并结果时也要校验块数量是否等于总块数一旦少了一块说明有块被误标成已完成必须回查进度记录。问题现象优先排查方向乱码与格式丢失译文出现标签碎片、表格散掉分块是否切断标记、后处理是否漏替换术语不一致同一个词有多种译法术语表是否进入提示词、上下文是否连贯限流与超时大量限流错误或超时并发数、重试策略、请求间隔成本超支费用远超出预算缓存命中率、批次样本估算我个人在跑完这批文档后的体会是大模型翻译本身已经不是瓶颈瓶颈几乎都集中在怎么把一批文档安全可靠地送进去再接回来这个工程问题上。批量翻译、公式保护、断点续传这些听起来有点技术感的说法落到地上全是朴素的流程管理。最后再分享一个小经验第一次跑全量之前先挑50到100个块做预热人工翻看质量、记录耗时拿这组数据去估算全量的成本和时间再决定要不要调整并发。这个动作帮我避掉过好几次大返工强烈建议你也试试。