从翻译 API 到多语言 Agent：网易有道翻译在 LLM 时代的工程化落地与降本增效实战

在 LLM 时代，网易有道翻译不再只是一个文本进、文本出的 API，而是多语言 Agent 的重要基础设施。无论你是在有道翻译官网体验在线翻译，还是通过有道翻译下载安装桌面端与浏览器插件，亦或把有道翻译 API 接入业务系统，背后都会遇到同一组工程问题：如何把翻译质量、时延、并发与成本同时控制住。

1. 从单点 API 到多语言 Agent

传统翻译 API 的典型链路是：鉴权 -> 语言检测 -> 分句 -> 翻译引擎 -> 后处理 -> 返回。它解决的是单轮、短文本、低上下文问题。进入 LLM 时代后，业务方想要的是多语言 Agent：

• 跨语言客服：识别用户语言，检索知识库，用用户母语回复。
• 会议同传：语音识别、断句、翻译、摘要、行动项抽取。
• 文档本地化：解析格式、术语统一、批量翻译、质量回检。
• 跨境电商：商品标题、详情页、评论、广告文案的风格化翻译。

这时，有道翻译这样的能力不再是单个函数，而是 Agent 可调用的工具之一。网易有道翻译在长期翻译场景中积累的语料、术语、记忆库和部署经验，恰好可以成为多语言 Agent 的底座。

2. 目标架构：分层与可替换

一个可落地的多语言翻译 Agent 通常分为六层：

1. 接入层：API Gateway、鉴权、限流、配额、计费、租户隔离。
2. 预处理层：语言检测、文本清洗、分句、占位符保护、术语预匹配。
3. 路由层：在 NMT、LLM、翻译记忆、术语库、规则引擎之间做动态路由。
4. 执行层：并行调用翻译模型、检索工具、术语服务、格式还原服务。
5. 后处理层：术语校验、风格润色、回译、质量评分、格式回填。
6. 可观测层：Trace、Metrics、Logging、Token 与字符成本核算。

关键原则是：接口稳定，内核可替换。业务方不应该感知今天用的是小模型、明天用的是大模型，而应该通过统一 API 获得稳定结果。

3. 降本增效的核心策略

3.1 分级路由

不是所有请求都值得调用大模型。短句、无上下文、术语明确的请求，优先走 NMT 或翻译记忆；长文本、强上下文、多轮对话、风格要求高的请求，再升级到 LLM。

伪代码示例：

from dataclasses import dataclass

@dataclass
class RouteResult:
    engine: str
    reason: str
    estimated_cost: float

class Router:
    def route(self, text, tenant):
        if tenant.glossary_hit(text):
            return RouteResult('tm+glossary', 'term_hit', 0.0)
        if len(text) < 80 and not tenant.llm_required:
            return RouteResult('nmt', 'short_text', 0.0001)
        return RouteResult('llm', 'context_required', 0.002)

这类路由可以把大量低价值请求挡在大模型之外。实际工程中，路由策略应支持 A/B 测试、灰度和回滚。

3.2 多级缓存

• 精确缓存：对原文、目标语言、租户、术语库版本做哈希。
• 语义缓存：用向量相似度复用近似句子，但必须设置阈值和租户隔离。
• 段落缓存：文档翻译时，段落级缓存比整篇缓存更实用。
• 翻译记忆：企业术语和历史句对是最便宜的翻译资产。

缓存命中率每提升 10%，大模型成本可能下降 20% 以上，同时显著降低 P95 时延。

3.3 批处理、流式与并发控制

LLM 翻译的延迟主要来自首 Token 和生成长度。工程上可以：

• 把长文档切分为段落并并行翻译，再按序合并。
• 对短句做动态批处理，减少请求数，但避免上下文串扰。
• 对交互式场景使用流式输出，让用户先看到部分结果。
• 用信号量、队列和超时控制保护下游模型。

3.4 术语库与翻译记忆优先

LLM 容易在品牌名、产品名、法律条款上产生漂移。企业级方案应先命中术语库和翻译记忆，再让 LLM 处理剩余部分。这样既能保证一致性，也能减少 Prompt 长度，降低 Token 成本。

3.5 质量评估与回退

不是所有 LLM 输出都值得信任。可以引入：

• 轻量打分模型：判断译文是否完整、语言是否正确、术语是否命中。
• 回译相似度：把译文回译到源语言，比较语义差异。
• 规则校验：数字、单位、日期、占位符是否保留。
• 低置信度升级：只有质量不达标时才调用更强模型或人工审核。

4. 多语言 Agent 的工程化落地

多语言 Agent 通常需要一组工具：

• translate：调用有道翻译或有道翻译 API 完成翻译。
• detect_language：语言识别与混合语言处理。
• glossary_lookup：术语查询与强制替换。
• search_knowledge：跨语言 RAG 检索。
• format_restore：Markdown、HTML、XML 格式还原。
• quality_check：质量评分与回译。
• cost_guard：预算控制与超额熔断。

Agent 的执行循环可以设计为：规划 -> 工具调用 -> 观察结果 -> 校验 -> 修正 -> 输出。对于翻译任务，建议把校验放在输出之前，避免把错误译文直接返回给用户。

跨语言 RAG 是一个典型场景：用户用中文提问，知识库是英文。Agent 需要先做查询重写，再检索英文文档，最后用中文回答。此时，网易有道翻译可以承担查询翻译、片段翻译和引用回译，而 LLM 负责推理与组织答案。

5. 可观测性与成本核算

没有度量就没有优化。建议每次请求记录：

• trace_id、tenant_id、源语言、目标语言、字符数、Token 数。
• 路由决策、缓存命中、模型版本、术语库版本。
• 首 Token 延迟、总延迟、错误码、重试次数。
• 质量分、人工反馈、成本金额。

成本核算要细化到租户、业务线和接口。只有把成本摊到每个请求，才能做配额、告警和优化。对于有道翻译这类成熟服务，官网、客户端和 API 的体验可能不同，但企业接入更应关注可观测性与 SLA。

6. 安全、合规与多租户

翻译内容可能包含个人信息、合同、代码和商业机密。工程上需要：

• 传输加密与静态加密。
• 缓存键包含租户 ID，禁止跨租户复用。
• 敏感信息脱敏后再送外部模型。
• 审计日志记录谁在何时翻译了什么类型的数据。
• 数据保留策略与删除机制。

如果你通过有道翻译官网体验功能，或通过有道翻译下载使用客户端，个人场景可以更关注体验；但企业集成有道翻译 API 时，安全与合规必须前置。

7. 一个可落地的演进路线

阶段一：统一翻译网关。封装有道翻译 API、术语库、缓存和限流。
阶段二：智能路由。引入 NMT、LLM、翻译记忆的分级路由。
阶段三：质量闭环。加入自动评分、回译、人工反馈和 A/B 测试。
阶段四：多语言 Agent。把翻译作为工具接入 RAG、客服、会议和文档流水线。
阶段五：成本运营。按租户核算 Token、字符和模型成本，持续优化缓存命中率与路由准确率。

8. 总结

从翻译 API 到多语言 Agent，变化的不只是模型，而是整个工程体系。网易有道翻译在翻译质量、术语、记忆库和产品矩阵上的积累，为多语言 Agent 提供了可靠底座。对于工程师而言，真正有价值的落地路径是：统一接口、分层路由、多级缓存、质量闭环、成本可观测。这样既能利用 LLM 的上下文理解能力，又能避免为每一句话都支付大模型成本，最终实现质量、时延与成本之间的平衡。无论用户从有道翻译官网进入，还是通过有道翻译下载使用客户端，抑或企业调用有道翻译 API，背后都需要这样一套工程化能力。