自建翻译平台隐藏成本超百万元！

原型搭建容易，实际运用成挑战

在大规模应用时，事情却常常更加复杂。本文将在此背景下探讨为何大多数组织选择混合模式：购买基础设施，构建能够真正使业务不同的能力。

在你的公司内，可能有人已经建立了一个翻译原型。一位工程师在周末使用大型语言模型处理了一些内容，输出结果让人惊讶地流畅，现在这个演示已经在内部传递。或许某位副总裁曾经询问技术团队，是否有更快的方法实现此目标；或许某位热情的开发者在短时间内实现了这个功能。不管怎样，它已经发挥作用。于是你可能开始思考，是否真的需要一个完整的翻译平台。

作为平台供应商，我对此有个不同寻常的观点。团队进行创造是很有意义的。考虑到构建的便捷性，聪明的工程师们进行尝试是合情合理的。问题不在于他们是否应该进行构建，而是在于他们应该构建什么。

对于每个提问的客户，我都会使用一个简单的框架。购买核心设施，构建差异化优势。购置基础设施，然后构建能够真正区分业务的定制部分。专业化的工作流程、专有数据模型、独特内容管道，这是工程师真正创造价值的地方。而不是重新搭建已经存在的生产级基础设施。对于约90%的企业而言，这种混合模式是最合理的。但要理解其中原因，就必须了解当原型与现实相遇时会发生什么。

概览

演示时未能展现的问题

第一阶段总是充满诱惑。短短几天时间，你已经扩展了几种语言，处理了几个内容类型，建立了基本的工作流程。构建这一系统的工程师会兴致昂扬，赞助该项目的高管则倍感欣慰。

第二阶段就是问题出现之时。当你扩展至十种以上语言并加入多种内容类型后，就会开始注意到奇怪的行为。人工智能的流利性就是个陷阱。模型能够生成看似合理的翻译，同时可能使用了错误的品牌术语、忽视法律要求，或误译某个对于特定市场至关重要的术语。在小规模情况下，这些问题不明显。而在生产规模中，这些问题就会积累。

成功会让问题更为严重。如果MVP（最小可行产品）运作良好，后续便会有更多采用。采用之后产生功能请求。这位在三天内构建原型的工程师现在被漏洞、极端情况以及源源不断的请求淹没，而这一切源于一个从未为生产设计的系统。

我们的一位客户形象地描述了这种情况：“每次黑客马拉松后，工程师们都会认为他们可以自己建造翻译引擎。我们每次尝试，每次都回归到购买平台。”

隐性成本的忽视

最常见的反对意见是自建似乎不需要费用。你的本地化团队从其他部门借调了几名工程师，因为没有直接支付他们的费用，所以成本问题未在预算中标明。但是有人在支付这些工资的实际成本。揭示出真实成本让持预算的人迅速改变观点。

如果你真打算建设，需要三到五名员工分布于产品、工程、QA和管理部门。按全负担成本计算，每人费用在15万至20万美元，具体因地域而异。再加上安全、合规、发布管理、基础设施，这一年花费将达45万至100万美金以上，而这还未考虑在成功后接踵而至的功能请求。

将其与平台进行对比。我们的员工约130至140人，涵盖工程、产品、设计和QA领域，并将这笔投资分摊给近4000位客户。我们的平均企业客户支付给我们的费用甚至低于一个工程师的费用。这使得小型内部团队几乎无法通过自建来复制专业平台交付的成果。

这种情况下的治理问题也常被忽视。你不会让工程师设计销售流程或法律工作流程，因为这些领域需要该专业人士的输入。那么为什么会让他们设计翻译系统，其中涉及到你的品牌、法律合规及客户体验呢？“只需调用API”的方法简化了繁复的过程。上下文管理、术语治理、质量基础设施、人工复核路由逻辑、基于角色的访问控制、审计跟踪。人工智能是引擎，但你仍然需要方向盘、底盘及安全气囊。

自建难以复制的优势

从零开始自建时，你将承诺要构建并维护每个集成。你的CMS连接器、设计工具集成、营销自动化链接、代码存储库钩子。每个项目都需要构建、测试以及维护，因为这些上游系统在不断发生改变。这已不再是一次性项目，而是持续扩展的工作范畴。

构建在平台上时，便可加入一个生态系统。例如，在我们的平台上，有不断扩展的技术合作伙伴网络，他们可以构建并维护你无需编写代码就能使用的解决方案。如果需要更换一个AI引擎，随着模型的不断完善，你可以选择自行安装或从生态系统中选择。你是在开放平台上构建，第三方致力于优化你的设置。

DIY方法将你锁定在团队今天构建的内容中，而技术环境发展如此快速，以至于今天的决策在几个月内可能变得过时。生态系统在不断进化。合作伙伴会发布改进内容、新集成不断涌现，而平台会在不需要你工程团队付出精力的情况下不断前进。

五个问题在投入前须问

如果你正在评估自建方案，或者团队中有人已经开始实施这些方案，以下问题可以帮助你判断演示是否能扩展：

创建它的人离开后会发生什么？
大多数内部翻译项目依赖于一、两名兼具AI知识、领域专长以及公司背景的人员。这是一个罕见组合。如果他们离开，项目通常会崩溃。
是否已计算全团队费用，而非仅原型费用？
一个可行演示需要一名工程师一周工作。一个生产系统长期需要三至五人支持，加上随采用而来的功能请求，维护及支持工作。
支付工程师工资的人是否了解这些工程师在忙些什么？
借调工程师对使用他们的团队来说似乎无需费用，但对公司来说并非如此。
你的方案是否能处理30种语言，而不是3种语言？
语言资源匮乏的长尾问题会使DIY方法失效。那些受限的训练数据、降低的准确性以及更多的极端情况。从英语到西班牙语的架构不会自动适用于土耳其语、泰语或越南语。
最优秀的工程师是否正在专注于核心产品而非翻译系统？
每次在翻译系统上的奔跑都意味着无法专注于推动路线图和营收的功能。