13

我们正在寻找可以整合到我们的本地化工作流程中的开源机器翻译引擎。我们正在研究以下选项：

  1. 摩西(C++)
  2. 约书亚（爪哇）
  3. 短语（Java）

其中，Moses 拥有最广泛的社区支持，并已被众多本地化公司和研究人员试用。我们实际上倾向于基于 Java 的引擎，因为我们的应用程序都使用 Java。你们中是否有人在工作流程中使用过 Joshua 或 Phrasal。你能和他们分享你的经验吗？或者，就其提供的功能和易于集成而言，Moses 是否远远领先于这些。

而且，我们要求引擎支持：

  1. 特定领域的训练（即它应该为输入数据所属的每个领域维护单独的短语表）。
  2. 增量训练（即避免每次我们希望使用一些新的训练数据时都从头开始重新训练模型）。
  3. 并行化翻译过程。
4

2 回答 2

5

很多事情都在向前发展，所以我想就这个主题进行更新，并将之前的答案留在那里以记录进度。

特定领域的培训：如果您的数据来自各种来源并且您需要针对子领域进行优化，则领域适应技术会很有用。根据我们的经验，没有单一的解决方案始终表现最佳，因此您需要尝试尽可能多的方法并比较结果。Moses 邮件列表中有一封邮件列出了可能的方法：http ://thread.gmane.org/gmane.comp.nlp.moses.user/9742/focus=9799various 。以下页面还概述了当前的研究： http: //www.statmt.org/survey/Topic/DomainAdaptation

增量培训：在 IWSLT 2013 上有一个有趣的演讲：http ://www.iwslt2013.org/downloads/Assessing_Quick_Update_Methods_of_Statistical_Translation_Models.pdf它表明当前的增量方法（1）使您的系统离线，因此您没有真正的“实时更新” " 你的模型 (2) 的表现优于全面再培训。看来问题还没有解决。

并行化翻译过程：moses 服务器落后于 moses-cmd 二进制文件。所以如果你想使用最新的功能，最好从 moses-cmd 开始。此外，社区没有兑现承诺永远不会发布 1.0 版本:-)。事实上，您可以在这里找到最新版本（2.1）：http: //www.statmt.org/moses/?n=Moses.Releases

于 2014-02-07T10:17:34.650 回答
5

我认为这个问题最好在 Moses 邮件列表 (moses-support@mit.edu) 上提出。那里有很多人使用不同类型的系统，所以你会得到一个客观的答案。除此之外，这是我的输入：

  • 关于 Java：MT 系统是用哪种语言编写的并不重要。无意冒犯，但您可以放心地假设，即使代码是用您熟悉的语言编写的，如果没有更深入的 MT 知识，也很难理解。所以你正在寻找的是接口。Moses 的 xml-rpc 工作正常。
  • 关于机器翻译系统：寻找最好的结果，忽略它所用的编程语言。结果在这里：matrix.statmt.org。使用您的 MT 系统的人对输出感兴趣，而不是对您的编码偏好。
  • 关于整个企业：一旦您开始提供 MT 输出，请确保您可以快速适应它。MT 正在迅速转向以 MT 系统为核心（而非唯一）组件的流水线流程。所以专注于可维护性。在理想情况下，您可以将任何 MT 系统连接到您的框架。

以下是有关您的功能请求的一些输入：

  • 特定领域的培训：您不需要该功能。通过使用客户特定的数据培训，您可以获得最佳 MT 结果。
  • 增量训练：参见基于流的统计机器翻译
  • 并行化翻译过程：您必须自己实施。请注意，大多数 MT 软件纯粹是学术性的，永远不会达到 1.0 的里程碑。如果多线程服务器可用（Moses）当然会有所帮助，但即便如此，您仍需要大量的利用代码。

希望这可以帮助。如果您还有任何问题，请随时 PM 我。

于 2012-10-09T08:45:34.307 回答