论文级 LaTeX 与图片翻译的技术实现与优化

在学术研究与技术传播场景中，翻译英文论文、技术报告或包含复杂排版的文档，一直是一项耗时且容易出错的工作。尤其是带有大量公式、引用、交叉引用、表格、插图的论文，单纯依赖通用文本翻译工具往往难以获得可编译、可阅读的结果。因此，有必要从工程化角度，设计一套面向论文文档的翻译流程，既关注正文翻译质量，也关注图表与排版结构的可用性。

本文不推荐某一款具体翻译产品，而是从通用技术方案出发，讨论如何借助大模型能力、OCR 能力与脚本化后处理，完成论文级 LaTeX 文档及图片内容的翻译。

一、从 Markdown 翻译到 LaTeX 翻译的差异

Markdown 结构简单，通常只包含标题、段落、列表、代码块、链接等基本元素。将 Markdown 内容按行切分后，可以较容易地合并为若干连续片段，再交给大模型进行翻译。这种方式在工程实践中具有较好的可控性，因为 Markdown 的语法对翻译结果的影响较小。

LaTeX 则复杂得多。一个完整的 LaTeX 项目通常由主文件、样式文件、参考文献文件、章节文件、图片资源等组成。正文中穿插着大量命令、环境、标签、引用和数学公式。翻译时不能简单地将整篇内容一次性输入模型，也不能随意破坏命令结构。否则轻则导致编译失败，重则使交叉引用、文献编号、公式编号全部错乱。

因此，更可行的方式仍然是将内容按行或按语义块切分，保持每个请求的上下文长度可控，例如将连续的若干行凑成接近 2000 个字符的片段。这样既能避免单次请求过长导致输出截断，也能减少不同片段之间的格式干扰。翻译完成后再将各片段按原顺序拼接。

二、大模型输出中的前后缀问题与后处理

在实际调用大模型进行批量翻译时，模型输出常常会附带一些固定风格的前缀或后缀。例如“以下是翻译结果：”“翻译如下：”等。这类文本虽然在对话场景中显得自然，但在文档翻译流程中会直接污染 LaTeX 源码。

为了降低这种不确定性，可以采用较低的温度参数，例如将 temperature 设置为 0.1 或更低。较低的温度能够显著减少输出随机性，使模型输出更加稳定和可预测。与此同时，仍然需要编写后处理脚本，对每个片段进行清理。常见做法包括：

1. 去除已知前缀与后缀；
2. 识别并删除仅包含解释性语言的行；
3. 校验片段首尾是否仍保留 LaTeX 命令结构；
4. 对片段级别进行语法完整性检查。

需要强调的是，后处理脚本不应过度依赖固定字符串匹配，而应结合规则与简单状态判断。例如，只有当某行以完整命令环境结束时，才认为该片段可以安全拼接。

三、LaTeX 转义字符的自动修复

LaTeX 对特殊字符有严格的转义要求。典型字符包括下划线 _、美元符号 $、百分号 %、井号 #、与符号 & 等。在普通文本中出现这些字符时，如果没有正确转义，轻则导致编译告警，重则直接报错。

大模型在翻译过程中，虽然能够理解自然语言，但对 LaTeX 语法的细粒度控制并不总是可靠。例如，原文中的 data_center 可能被翻译成 数据中心，这不会产生问题；但如果模型生成了 node_id 这样的内容，则可能导致编译错误。类似地，表格中的 & 用于分隔列，而普通文本中的 & 需要写成 \\&，模型未必能始终正确区分上下文。

针对这类问题，可以构建一个基于上下文的转义修复脚本。该脚本不追求完全理解 LaTeX 语法，而是通过若干启发式规则判断字符是否处于数学环境、表格环境或命令参数中。例如：

• 如果 _ 前后都是普通字母，且不在数学环境中，则需要转义为 \\_；
• 如果 $ 不是成对出现，或明显不属于数学公式边界，则需要转义；
• 如果 & 不在表格环境中，则大概率需要转义。

通过这类规则，可以自动修复大部分因模型输出导致的低级语法错误，大幅降低后续手动排查成本。

四、参考文献与交叉引用的处理

论文翻译中，参考文献是一个容易出现问题的地方。很多文献条目使用 BibTeX 管理，正文中通过 \\cite{key} 引用。翻译过程中，如果模型将引用键名误改或丢失，编译后就会看到满篇的问号。

为了降低这种风险，建议在翻译前对引用命令进行保护。可以在片段切分时，将 \\cite{...}、\\ref{...}、\\label{...} 等命令替换为占位符，翻译完成后再恢复。如果某些引用键被破坏，也可以根据原始的 .bib 文件进行校验，发现不存在的键时自动替换为最相似的正确键名。

此外，不要试图让模型翻译 BibTeX 条目中的作者名、标题等字段。参考文献条目的标准化程度较高，人工翻译或保留原文往往是更稳妥的选择。否则很可能出现标题翻译质量参差不齐、大小写混乱、特殊字符丢失等问题。

五、论文图片翻译的现实困难

论文中的插图通常可以分成两类：一类是架构图、流程图、示意图，其中包含较多文字标注；另一类是实验结果图、曲线图、散点图等，文字较少或基本不含自然语言文本。

许多 PDF 翻译工具在面对整页文档时，能够识别并翻译大段正文，但一旦遇到图内文字，就容易出现错位、遮挡、样式混乱等问题。尤其是架构图，文字块往往位于图形元素之间，翻译后的文本长度可能发生变化，导致覆盖连线、框体或箭头。

因此，更可控的方式是将图片翻译作为独立流程处理。基本思路如下：

1. 将论文 PDF 按页转换为高分辨率图片；
2. 对每一页图片运行 OCR，识别文字区域；
3. 对识别出的文字块进行语言判断；
4. 仅对包含源语言文字的区域进行翻译；
5. 使用翻译后的文字块替换原区域；
6. 将处理后的图片重新嵌入文档。

这种方式的优点是流程清晰、易于批量执行。缺点也很明显：翻译后的文字排版可能不够自然，字体风格与原图不一致，复杂背景下的文字替换容易留下痕迹。

六、OCR 图片翻译的工程化实现

在工程实现中，可以调用通用 OCR 接口或图片翻译接口。这类接口通常会返回文字块的位置、原始文本和翻译文本。对于架构图，可以先检测出所有文字块，再根据目标语言需求决定是否替换。

例如，如果目标是生成中文版本，那么对于识别结果为英文的文本块进行翻译；如果识别结果本来已经是中文，则保留原样。对于实验结果图，如果 OCR 未识别出任何自然语言文本，则直接保留原始图片，避免不必要的处理。

一个简单的伪代码流程如下：

for page_image in pdf_to_images(pdf_path):
    ocr_result = ocr_image(page_image)
    text_blocks = ocr_result.get_text_blocks()
    has_source_text = any(is_source_language(b.text) for b in text_blocks)
    if not has_source_text:
        keep_original_image(page_image)
        continue
    translated_blocks = []
    for block in text_blocks:
        if is_source_language(block.text):
            translated_text = translate(block.text)
            translated_blocks.append((block.region, translated_text))
        else:
            translated_blocks.append((block.region, block.text))
    output_image = replace_text_blocks(page_image, translated_blocks)

这种方式虽然不能完全达到专业美工水平，但在批量处理论文时，可以显著减少人工操作量。对于要求更高的场景，可以进一步对翻译后的文字长度进行自适应缩放，或根据原文字体颜色、背景颜色进行样式匹配。

七、保持 PDF 矢量特性的可能性

将 PDF 转为图片再翻译，会损失矢量特性。翻译后的图片在放大时可能出现模糊，不利于打印或再排版。因此，如果能够直接解析 PDF 中的文字对象、获取其坐标与字体信息，并在原位置替换为翻译后的文本，则可以保持矢量格式。

这种方案在技术上是可行的。PDF 中的文字通常以文本对象的形式存在，配合字体资源和位置矩阵，可以准确定位每一个字符。问题在于，翻译后的文字长度往往与原文本不同，直接替换可能导致字符重叠或超出原有框体。因此需要在替换时进行排版调整，例如缩小字号、调整字间距或扩展文本框。

对于架构图类内容，这种调整难度相对较高，因为文字与图形之间存在复杂的位置关系。对于纯文本段落，则容易得多。目前已有一些通用文档处理能力在向这个方向演进，但要达到完全自动化且排版稳定的效果，仍有较大提升空间。

八、多模态模型带来的后续可能

当前流程依赖 LaTeX 源码。只要论文提供了源码，就可以按照上述方法进行翻译、后处理和编译。这种方式能够保留公式、交叉引用、参考文献等结构化信息，翻译质量也相对可控。

如果未来多模态模型能够直接理解 PDF 版面结构，同时识别正文、公式、表格、图片及图中文字，并在不破坏版式的前提下完成翻译，那么论文翻译的效率将进一步提升。届时，用户可能只需要上传 PDF，即可获得排版良好的目标语言版本，无需再关心源码、转义字符和图片替换等细节。

但在此之前，基于 LaTeX 源码的翻译仍然是一种务实且可靠的选择。通过合理的脚本化处理，可以在半天到一天的时间内完成一篇论文的初步翻译，并获得基本可读、可编译的结果。对于学术交流、技术调研和内部学习等场景，这种方法具有较高的实用价值。