文本翻译与文档翻译的区别：逐句准确为什么还不够

评价一次翻译好不好大多数人下意识用的标准是“这句话翻得对不对。这个标准没有错但它只覆盖了任务的一半。另一半——文件本身能不能继续被使用——很少被单独拿出来讨论可它恰恰是让很多翻译结果在实际工作中打折扣的地方。这篇文章想把文本翻译和文档翻译这两件事分开说清楚。一、两个术语的区分先给两个词一个明确的定义避免后面讨论时混着用。文本翻译指的是把一种语言的字符串转换成另一种语言的字符串。输入是文字输出也是文字评价标准是准确、通顺、语境贴合。这是语言模型最擅长、也是过去几年进步最明显的部分。文档翻译指的是把一份文件——PDF、Word、PPT、扫描件——从一种语言的版本变成另一种语言的版本同时保持这份文件原有的组织形式还是那本报告还是那份合同打开之后该有的标题、表格、页码、引用关系都还在可以正常阅读、编辑、交付。区别在哪里文本翻译的对象是句子集合文档翻译的对象是一个带结构的容器。前者做完只能说“字翻完了后者做完才能说文件翻完了。很多场景下用户说“帮我翻译一下这份文件心里想要的其实是后者但拿到的往往只是前者的结果。二、文档中的结构性信息清单要理解两者的差距具体在哪可以把一份文档拆开看列出那些“不属于文字本身但决定文档能不能用的信息标题层级一级标题、二级标题、正文之间的从属关系决定了大纲和目录能不能正常生成。表格行列对应关系、合并单元格、表头与数据的绑定。表格翻译最容易出问题因为单元格内的文字一旦被当成独立句子处理行列结构就没有人维护了。公式理工科文档里常见公式本身通常不需要翻译但公式前后的变量说明、公式编号需要和正文保持对应公式的位置也不能跑到别的段落里。分栏很多报告、论文采用双栏或三栏排版阅读顺序是“先读完左栏再读右栏如果翻译时把分栏当成从左到右的普通文本读取句子顺序会直接错乱。交叉引用正文里“见第 3 章“如图 5 所示这类引用依赖的是章节号、图号在翻译后依然准确对应一旦编号或位置发生偏移引用就会指向错误的内容。图文关系图片、图注、脚注之间的绑定关系。图还在原处图注却漂移到别的页面是最常见也最影响观感的问题之一。这六类信息共同构成了一份文档的“骨架。文本翻译只处理骨架上附着的文字骨架本身谁来维护是文档翻译需要额外解决的问题。三、为什么大模型不等于文档翻译方案这两年大语言模型让翻译的语言质量有了明显提升很多人因此觉得“翻译问题已经解决了。但这个判断混淆了两件事。大模型擅长的是语言层面的转换理解上下文、处理歧义、保持语气和术语的一致性。这些能力直接提升的是文本翻译的质量。但大模型本身的输入输出形式是 token 序列一段文字进去一段文字出来这个过程里并不天然携带“这段文字在页面上的第几栏“这是不是表格的一个单元格这类结构信息。也就是说大模型能力的边界止步于“这句话翻得好不好并不延伸到“这份文件翻完还能不能用。要让模型的输出重新变成一份结构完整的文档需要在模型之外再搭建一层——文档解析和版式重建的能力。这层能力和语言能力是两套不同的技术栈一套做得好不代表另一套也做得好。这也是为什么市面上有些工具译文质量很高但用户拿到手之后还是要花时间重新排版语言这一半做得不错文档这一半没有配套跟上。四、“可用性的四个检验维度与其笼统地说“这份翻译好不好用不如拆成四个具体可以检验的维度逐一去看可读打开文件内容顺序是否符合原文的阅读逻辑段落有没有因为分栏、跨页被打乱。这是最基础的一层如果连顺序都乱了后面几层无从谈起。可编辑拿到的文件是不是一份可以直接在原有软件里继续修改的文件还是一份只能整体复制粘贴、结构已经被破坏的“死文件。可编辑意味着字体、段落样式、表格框架这些属性都还保留在文件里而不是变成图片或纯文本堆叠。可核对如果需要对照原文检查译文准确性是否方便逐段、逐句地找到对应位置。目录能不能跳转、章节编号是否和原文一致都是可核对的具体体现。可交付这份文件能不能不经过额外整理直接发给同事、客户或者用在正式场合。这是四个维度里最贴近实际使用场景的一条也是前面三条共同作用的结果。这四个维度是递进关系可读是底线可交付是终点。多数翻译工具能保证前两条勉强达标第三、第四条往往需要用户自己动手补齐这也是“翻译完之后还要花时间整理这件事的根源所在。五、文档翻译的完整链路把前面的分析串起来一个完整的文档翻译任务实际上需要经过几个相对独立的步骤而不是“输入文字、输出译文这一步就能完成解析文件这是链路的入口任务是把不同格式的原始文件读进系统里转换成程序可以处理的数据形式。PDF、Word、PPT、扫描件的底层编码方式各不相同PDF 本质上是一堆带坐标的绘图指令Word 是带标记语言的树状结构扫描件甚至连文字层都没有需要先过一道 OCR。这一步做得不到位后面所有环节都无从谈起——比如一份扫描件如果文字识别有偏差后面的翻译从源头上就是错的。识别结构在拿到可处理的数据之后系统需要判断页面上每一块内容“是什么这一段是标题还是正文这一块是表格还是普通文本这几行属于左栏还是右栏这张图对应的图注在哪里。这一步的输出不是文字内容而是一份结构地图记录着每个元素的类型、位置和相互关系。识别结构和解析文件常常被混为一谈但其实是两件事解析解决的是“读得进来识别解决的是“读得懂版面后者的难度往往更高因为不同文档的排版习惯千差万别没有统一的规则可以套用。翻译内容在结构地图确定之后才轮到语言转换登场把每一块内容对应的文字单独送去做翻译同时保留它在结构地图里的位置标记确保译文出来之后还能对应回原来的位置。这一步是语言模型发挥作用的环节也是过去几年技术进步最明显的部分但它处理的始终只是内容本身不涉及内容之间的排布关系。重建输出把翻译完成的内容按照识别结构阶段留下的位置标记重新装配回去恢复标题层级、表格框架、图文绑定关系、交叉引用的对应关系最终生成一份可以在常规软件里打开的文件。这一步同样需要处理很多细节比如中文和英文的排版密度不同同样的表格宽度中文译文可能比英文原文更短或更长需要做适当的自适应调整否则表格会出现留白过多或者文字溢出的问题。这四步里翻译内容只是其中一环前后各有两道工序需要独立完成。识别结构做得不够细重建输出就没有依据重建输出做得不够严谨即使前面识别和翻译都准确最终交到用户手里的依然是一份需要二次整理的文件。这也是为什么判断一个文档翻译工具是否合格不能只看译文读起来顺不顺还要看它有没有认真对待解析、识别、重建这几个环节而不是把全部精力都投在翻译内容这一步上。六、LingoMirror 在各环节的对应能力我们在设计 LingoMirror上海比孚时是把上面这条链路当作一个整体去对待的而不是只做中间的翻译环节。在解析和重建这两端我们的核心目标是版式结构保留文档进来之后标题层级、表格的行列关系、图文的绑定关系会先被识别和记录下来翻译完成后再按照这份记录把内容装配回原有的版式里尽量让“翻完的文件和“原来的文件在结构上保持一致而不只是文字内容对应。在输出环节我们坚持给到可编辑输出交付的文件是可以在常规办公软件里直接继续修改的格式而不是只能查看的静态版本。这一点是从“可编辑、“可交付这两个可用性维度倒推回来的产品要求——如果输出的文件不能编辑前面结构保留得再好用户依然要花时间做格式转换或重新录入。这套思路目前主要解决的是“结构不丢失、文件能继续用这个层面的问题复杂版式的完全还原仍然是持续在优化的方向不存在一次性解决所有排版情况的通用方案。结语判断一次翻译是否合格逐句准确是必要条件但不是充分条件。文本翻译解决的是语言问题文档翻译解决的是结构问题两者需要不同的能力去支撑也应该用不同的标准去检验。下次评估一个翻译工具时不妨把“译文准不准和“文件能不能用分开来看这样得到的判断会更接近实际使用体验。