用 BabelDOC 翻译 PDF，用 OneAIFW 防止大模型泄密

很多人使用大模型时会遇到两个很实际的问题。

一个是 PDF（Portable Document Format，可移植文档格式）翻译。论文、说明书、技术白皮书通常有复杂排版，里面混着标题、正文、脚注、公式、图片、表格和图注。普通翻译工具只关心文字，翻译完经常出现段落错位、公式乱码、图表跑偏，文档可读性反而变差。

另一个是隐私泄露。把邮件地址、手机号、密钥、内部会议地点直接发给大模型服务，等于把这些信息交给第三方模型平台处理。哪怕模型回答得很准确，数据边界也已经被打破。

BabelDOC 和 OneAIFW 分别解决这两个问题：

BabelDOC：保留排版的 PDF 翻译工具

BabelDOC 是一个基于 Python 的 PDF 翻译工具。它不是简单地把 PDF 里的文字抽出来翻译成中文，而是尽量理解 PDF 的页面结构，再把翻译后的文本放回对应位置。

PDF 翻译难，主要难在 PDF 本身不是为“重新编辑文本”设计的。很多 PDF 页面本质上是一堆带坐标的对象：某段文字在什么位置、字体多大、图片占多大区域、页脚在哪个坐标。翻译后中文长度和英文长度不一样，如果工具不处理版式，页面很容易乱。

BabelDOC 的处理链路可以理解成这样：

flowchart LR
    A[输入 PDF] --> B[解析页面结构]
    B --> C[提取文本块、坐标和样式信息]
    B --> D[识别图片、表格、公式等非正文区域]
    C --> E[调用大模型翻译文本]
    E --> F[把译文回填到原页面位置]
    D --> F
    F --> G[生成翻译版 PDF]
    F --> H[可选生成双语对照 PDF]

它关心的不只是“这句话翻译成什么”，还包括“这句话原来在页面哪里”。这也是它比普通全文翻译工具更适合处理论文、报告和技术手册的原因。

双语对照模式适合读论文

BabelDOC 支持中英对照输出。阅读英文论文时，这种模式很有用：原文和译文可以放在同一个文档里，遇到术语、公式上下文或者翻译不确定的地方，可以直接对照检查。

双语模式尤其适合这些场景：

翻译质量取决于大模型

BabelDOC 支持 OpenAI API（Application Programming Interface，应用程序编程接口）兼容的模型服务。只要模型服务提供类似 OpenAI 的调用方式，就可以通过模型名、接口地址和密钥接入。

常见选择包括：

• GPT-4o
• DeepSeek
• Qwen

这里的重点是：BabelDOC 负责 PDF 解析、排版保持和文档重组，大模型负责具体翻译质量。模型越擅长长文本、术语和上下文理解，译文越自然。

BabelDOC 上手使用

BabelDOC 主要面向开发者或熟悉命令行的用户，常用方式是 CLI（Command Line Interface，命令行接口）。

如果本机已经安装 uv，可以直接安装：

uv tool install babeldoc

babeldoc --help

也可以从源码运行：

git clone https://github.com/funstory-ai/BabelDOC
cd BabelDOC

uv run babeldoc --help

假设要把 paper.pdf 翻译成简体中文，并使用 DeepSeek 的 OpenAI 兼容接口，可以这样执行：

export DEEPSEEK_API_KEY="sk-你的密钥"

babeldoc \
  --files paper.pdf \
  --openai \
  --openai-model "deepseek-chat" \
  --openai-base-url "https://api.deepseek.com" \
  --openai-api-key "$DEEPSEEK_API_KEY" \
  --lang-out zh-CN

Windows PowerShell 可以用这种方式设置环境变量：

$env:DEEPSEEK_API_KEY="sk-你的密钥"

执行后，BabelDOC 会完成这一组动作：

sequenceDiagram
    participant User as 用户
    participant BabelDOC as BabelDOC
    participant Model as 大模型接口
    participant PDF as 输出 PDF

    User->>BabelDOC: 提交 paper.pdf
    BabelDOC->>BabelDOC: 解析页面结构和文本块
    BabelDOC->>Model: 发送待翻译文本
    Model-->>BabelDOC: 返回译文
    BabelDOC->>BabelDOC: 回填译文并重组版式
    BabelDOC-->>PDF: 生成翻译后的 PDF

如果不想在本机配置环境，也可以使用在线版本：

https://app.immersivetranslate.com/babel-doc/

在线上传更方便，但敏感文档需要谨慎。只要文件上传到网页服务，文档内容就离开了本机；涉密合同、内部报告、未公开论文不适合直接使用在线转换。

BabelDOC 使用时要注意什么

BabelDOC 解决的是“翻译 PDF 时尽量保持版式”，但它不是万能的 PDF 编辑器。实际使用时有几个点需要提前知道。

BabelDOC 最适合处理“文字可提取、排版复杂、需要阅读而不是正式出版”的 PDF。正式出版物、法律文件、合同等场景，仍然需要人工校对。

OneAIFW：给大模型请求加一层隐私代理

OneAIFW 的全称可以理解为 AI Firewall，即 AI 防火墙。它防的不是传统网络攻击，而是防止用户把敏感信息直接发给大模型。

它的核心逻辑很简单：在请求进入大模型之前，先把敏感数据替换成占位符；模型返回结果后，再在本地把占位符换回真实数据。

flowchart LR
    A[用户输入 Prompt] --> B[OneAIFW 检测敏感信息]
    B --> C[替换为占位符]
    C --> D[发送给大模型]
    D --> E[模型返回包含占位符的结果]
    E --> F[OneAIFW 本地还原]
    F --> G[用户看到完整回复]

这里涉及一个常见概念：PII（Personally Identifiable Information，个人可识别信息）。邮箱、手机号、身份证号、银行卡号、地址、精确位置、API 密钥等，都可以归入需要保护的敏感信息。

一个脱敏示例

原始输入可能是这样：

帮我写封邮件给 li_lei@example.com，告诉他下周三的会议改到 Room 303。

OneAIFW 处理后，发给大模型的内容变成：

帮我写封邮件给 __PII_EMAIL_ADDRESS_00000001__，告诉他下周三的会议改到 __PII_LOCATION_00000002__。

大模型返回：

好的，邮件草稿如下：

Dear __PII_EMAIL_ADDRESS_00000001__,

The meeting scheduled for next Wednesday has been moved to __PII_LOCATION_00000002__.

OneAIFW 在本地根据映射表还原：

好的，邮件草稿如下：

Dear li_lei@example.com,

The meeting scheduled for next Wednesday has been moved to Room 303.

大模型实际看到的是占位符，而不是邮箱和会议室。映射关系保存在本地或代理层，不进入模型服务。

可以把它理解成一张临时映射表：

这张表不能被发送给模型，否则脱敏就失去了意义。

OneAIFW 适合放在哪一层

OneAIFW 更像一个“请求代理”或“安全中间层”。如果应用原来是直接调用大模型，现在可以改成先经过 OneAIFW。

flowchart LR
    A[业务应用 / Chat 客户端] --> B[OneAIFW]
    B --> C[OpenAI 兼容模型接口]
    C --> B
    B --> A

典型集成点有两种：

如果仓库提供 OpenAI 兼容代理模式，业务系统通常只需要把模型接口地址从原模型服务改成 OneAIFW 的地址，再由 OneAIFW 配置真正的大模型服务。具体启动命令、配置文件和支持的模型接口，需要以仓库 README 为准。

一个合理的接入检查流程是：

flowchart TD
    A[准备测试 Prompt] --> B[包含邮箱、手机号、密钥等假数据]
    B --> C[发送到 OneAIFW]
    C --> D{模型侧日志是否只出现占位符}
    D -- 是 --> E[检查回复是否正确还原]
    D -- 否 --> F[调整脱敏规则或接入位置]
    E --> G{业务语义是否受影响}
    G -- 是 --> H[为特定字段配置保留或自定义规则]
    G -- 否 --> I[进入小流量试用]

测试时不要用真实隐私数据，应该先构造假邮箱、假手机号、假密钥来验证脱敏效果。

OneAIFW 能防什么，不能防什么

OneAIFW 能减少“无意中把敏感信息发给模型”的风险，但它不是完整的数据安全体系。

它不适合解决这些问题：

部署 OneAIFW 时，一个关键原则是：脱敏要尽量靠近用户输入源，日志和监控要放在脱敏之后。

错误链路：

flowchart LR
    A[用户输入] --> B[记录原始日志]
    B --> C[OneAIFW 脱敏]
    C --> D[大模型]

更安全的链路：

flowchart LR
    A[用户输入] --> B[OneAIFW 脱敏]
    B --> C[记录脱敏日志]
    C --> D[大模型]

两个工具分别适合什么场景

BabelDOC 和 OneAIFW 都和大模型有关，但解决的问题完全不同。

组合使用时的思路

如果要翻译一份包含敏感信息的 PDF，两个工具可以配合使用，但要注意链路设计。

一种更稳妥的流程是：

flowchart TD
    A[原始 PDF] --> B{是否包含敏感信息}
    B -- 否 --> C[BabelDOC 直接翻译]
    B -- 是 --> D[先在本地清理或脱敏 PDF 文本]
    D --> E[BabelDOC 调用大模型翻译]
    E --> F[人工检查译文和排版]

BabelDOC 负责翻译和排版，OneAIFW 负责模型请求前的敏感信息保护。对于 PDF 翻译任务，是否能把 OneAIFW 无缝放进 BabelDOC 调用链，取决于实际接口配置方式。如果 BabelDOC 通过 OpenAI 兼容接口调用模型，而 OneAIFW 也提供兼容代理，那么理论上可以让 BabelDOC 的模型请求先经过 OneAIFW；落地前要用测试文档验证占位符是否会影响翻译质量和版式回填。

选型建议

BabelDOC 的价值在于减少 PDF 翻译后的整理成本。它适合论文、技术报告、手册、白皮书这类“排版重要但仍以阅读为主”的文档。

OneAIFW 的价值在于给大模型调用增加一道隐私边界。它适合企业内部助手、客服系统、研发提效工具、自动邮件生成等场景，尤其适合那些用户可能无意输入邮箱、手机号、Token 或内部地点的应用。

两者都不是“打开就完事”的工具。BabelDOC 需要检查译文和复杂版式，OneAIFW 需要检查脱敏规则、日志链路和占位符还原效果。真正进入生产环境前，至少要做三类测试：

把这两类工具用好，核心不是追求“自动化替代所有人工”，而是把重复劳动和无意泄露降下来：PDF 翻译由工具完成初稿和排版保留，关键内容再人工校对；大模型请求由防火墙先做脱敏，真实敏感值尽量留在本地。