anand chakravarty 是機器翻譯團隊中的 set, 在過去2.5年中一直在 microsoft 工作了 8年, 並且是 mt 團隊中的第一個產品測試人員 ("仍在測試 mt:-) 方面很開心")。 今天的嘉賓博客是關於測試翻譯品質的。 

—————————————————————————————————————

在談到驗證翻譯系統的品質時, 首先想到的一點是, 你如何衡量翻譯的品質, 或者準確地衡量翻譯的準確性？使用電腦在人類語言之間進行翻譯是一個幾乎有半個世紀歷史的領域。該領域具有足夠的挑戰性, 即使是目前最好的機器翻譯系統, 也沒有接近獲得完全令人滿意的語言品質。

部分挑戰在於人類為了理解 s分支/書面文本的含義而處理的許多不同的資料點。有語法、解析、語義、上下文、消歧、重新排序, 所有這些, 更多的是, 都進入了對一個句子的理解。而這只是1種語言中的句子。現在考慮應用所有這些方法以另一種語言重建句子, 並使其同樣有意義。

一些例子可能有助於使這一點更加明確。"2 0 0 8年奧運會" 一詞相當明確。同樣, 人們可能會預期 "2008年大選" 一詞指的是美國的總統選舉。不過, 如果使用者來自, 比如加拿大, 更有可能指的是那裡的地方選舉。

一個更一般的, 因此也是更常見的例子, 就是一個像 "音符錯了" 這樣的句子。"注意" 一詞是指資訊性資訊還是音樂術語？正確的翻譯取決於上下文。使用更多的上下文, 您獲得更準確翻譯的機會就會得到提高。然而, 這是有代價的: 系統試圖獲得的上下文越多, 其性能就越慢。明智的運輸決策包括在提高翻譯準確性和向使用者提供可行的翻譯結果之間取得適當的平衡。當然, 兩者都很重要。關鍵是要瞭解你在改進方面的導向方向, 這取決於最終結果對使用者的説明程度。

這變得特別有趣, 當翻譯檔或網頁, 而不是僅僅個別句子。假設已經收到了包含100句句子的網頁的翻譯請求。根據翻譯系統的體系結構, 這些句子都可以轉到一個進程, 也可以分佈在多個進程電腦上。無論哪種方式, 很明顯, 翻譯整頁所需的時間與翻譯句子所需的最長時間成正比。在投入的時間對使用者的時間有害之前, 我們花了多長時間翻譯一個句子？為了追求最佳的翻譯, 我們最終可能會阻止使用者獲得任何資訊來回應他們的翻譯請求。因此, 該系統的效用取決於為平衡語言品質和應用程式性能而作出的決定。

有了微軟翻譯產品, 我們的雙語檢視器還有一個額外的功能, 在公開提供的翻譯產品中是獨一無二的。它支援並行文本突出顯示、同步滾動, 並為頁面呈現漸進式呈現。這將為我們的使用者所看到的內容增加另一層, 並因此為拋光和完成添加另一層。

在未來幾周內, 我們希望為您帶來更多具體領域的細節, 這些領域已經和正在進行測試, 以提供高品質的翻譯系統。請隨時發佈任何問題, 你有這個問題, 你一直想問的東西:-), 在評論部分。