開源機器翻譯引擎？

Question

我們正在尋找一種可以融入我們的本地化工作流程的開源機器翻譯引擎。我們期待在下面的選項：

1. Moses（C++）
2. Joshua（JAVA）
3. Phrasal（JAVA）

其中，摩西具有最廣泛的社會支持，有被許多本地化公司和研究人員嘗試過。我們實際上傾向於基於Java的引擎，因爲我們的應用程序都是用Java編寫的。有沒有人使用Joshua或Phrasal作爲您的工作流程的一部分。你能否與他們分享你的經驗？或者，就其提供的功能和易於集成而言，摩西的方式遠遠超出了這些。

而且，我們要求該引擎支持：

1. 特定於域的訓練（即，它應該保持該輸入數據所屬的每個域單獨短語表）。
2. 增量式培訓（即避免每次我們希望使用一些新的培訓數據時從零開始重新訓練模型）。
3. 平行翻譯過程。

Answer 1

我想這個問題最好在摩西郵件列表（moses-support@mit.edu）上提問。那裏有很多人在使用不同類型的系統，所以你會得到一個客觀的答案。除此之外，以下是我的輸入：

• 對於Java：使用哪種語言編寫MT系統並不重要。沒有冒犯性，但你可以有把握地認爲，即使代碼是用你熟悉的語言編寫的，但如果沒有對MT的更深入的瞭解，就很難理解。所以你正在尋找的是接口。摩西的xml-rpc工作正常。
• 關於MT系統：尋找最佳結果，忽略寫入的編程語言。結果在這裏：matrix.statmt.org。使用您的MT系統的人不希望輸入您的編碼偏好。
• 就整個風險而言：一旦你開始提供MT輸出，確保你可以快速適應它。 MT正在迅速轉向以MT系統爲核心（而不是唯一）組件的管道流程。所以關注可維護性。在理想情況下，您可以將任何MT系統連接到您的框架。

這裏還有你的功能要求輸入信息：

• 特定領域的培訓：你並不需要這個功能。通過使用客戶特定的數據培訓，您可以獲得最佳的MT結果。
• 增量培訓：請參閱Stream Based Statistical Machine Translation
• 並行化翻譯過程：您必須自己實現此功能。請注意，大多數MT軟件純屬學術性，永遠不會達到1.0里程碑。當然，如果有多線程服務器可用（Moses），但即便如此，您仍然需要大量的代碼。

希望這有助於。如果您還有其他問題，請隨時通知我。

Answer 2

很多一直往前走，所以我想給關於這個主題的最新情況，並保留以前的答案有記錄的進展。

特定領域的培訓：如果你的數據是從各種渠道採取的，你需要對一個子域優化域自適應技術是有用的。根據我們的經驗，沒有一個解決方案能夠始終保持最佳性能，因此您需要儘可能多地嘗試並比較結果。摩西郵件列表上的郵件列出了可能的方法：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）的「實時更新」通過全面的重新培訓得到了超越。看來問題還沒有解決。

並行化編譯過程：摩西服務器上的摩西-CMD二進制滯後。所以如果你想使用最新的功能，最好從moses-cmd開始。此外，社區還沒有遵守從不發佈1.0版本的承諾:-)。實際上，你可以在這裏找到最新版本（2.1）：http://www.statmt.org/moses/?n=Moses.Releases