Island Life

< Big Island | Schemeとunwind-protect >

2016/11/24

Google翻訳と下訳

Google翻訳を下訳に使って手早く技術文書を翻訳してみました、という例:

訳された文章はこちら: Hadoop: Fair Scheduler

おそらくこれからはこういう形のやり方も増えてゆくと思うので試みとして面白い。 同時に、現在の機械翻訳で弱そうなところ(従って、下訳から修正する際に気をつけるべきところ)が 見えてる気がする。「イントロダクション」の節からいくつか例を挙げてみる。

(引用は現時点での訳。徐々にフィードバックを受けて改善されると思うので後で見る時は 変わっている可能性あり)


現訳:

デフォルトでは、フェアスケジューラはスケジューリングフェアネス決定をメモリ上でのみ行います。Ghodsiらによって開発されたDominant Resource Fairnessの概念を使用して、メモリとCPUの両方でスケジュールを設定することができます。

原文:

By default, the Fair Scheduler bases scheduling fairness decisions only on memory. It can be configured to schedule with both memory and CPU, using the notion of Dominant Resource Fairness developed by Ghodsi et al.

"on memory" は典型的にはデータを操作する際にそれがメモリに乗っていることを指し、 「メモリ上で」と訳されることが多い。 けれどもここのonは "base X on Y"、「Yに基づいてXを構築する/Xの基礎にYを置く」 のonであって「メモリにのみ基づいて(スケジューリングの公平性を決定する)」という意だ。

on memoryを場所を示す副詞句と取れば「メモリ上で決定を行う」という解釈も 構文的には可能である。

そちらの解釈が却下される理由は、次の文の意味とのつながりにある。次の文ではメモリとCPUの両方を 考慮してスケジュールすることも可能だと言っている。原文を読む人間は、 最初の文ではっきり意味を確定していなくても、次の文を読んだ段階で

「さっきメモリのみと言っていて、次にメモリとCPUの両方ってのを持ち出して来たんだから、 スケジューリング決定のパラメータとして、メモリのみ、あるいはメモリとCPUの両方、という オプションがあるんだな」

と理解する。

現訳でも内容を良く考えればその解釈に至ることは可能だと思うけれど、 私は一読してわからず原文を読んでしまった。例えばこう書いてあったら 一読で理解できたんではないかと思う。

デフォルトでは、フェアスケジューラはスケジューリングフェアネス決定をメモリのみに基づいて行います。Ghodsiらによって開発されたDominant Resource Fairnessの概念を使用して、メモリとCPUの両方でスケジュールを設定することできます。

原文2文目にalsoは入っていないけれど、元の英文では2文目冒頭にIt can beが来て 別の可能性に言及していることがすぐ分かるのに対し、日本語では「できます」が 2文目末に来てしまうので、「も」を補なうことで流れをわかりやすくできる。


現訳

スケジューラはアプリケーションを「キュー」にまとめ、これらのキュー間でリソースを公平に共有します。

原文

The scheduler organizes apps further into “queues”, and shares resources fairly between these queues.

ここは単文での翻訳としては問題はない。問題は、この前のパラグラフで、

「アプリのキューを形成するデフォルトのHadoopスケジューラとは異なり、(Unlike the default Hadoop scheduler, which forms a queue of apps,)」

と言っている点だ。「アプリのキューを作るデフォルトのスケジューラとは違う」と言っておきながら、 「アプリケーションをキューにまとめ」と来るので読者は混乱する。

先のキューと今出てきた「キュー」は違うものを指していて、原文でクオートされているのも それを強調する意図があるのだろうけれど、もうひとつ、原文では 先に出てきたキューが単数で、後に出てきたキューが複数であることが、 両者が違うものを示すという重要な手がかりになっている。

一般には単数形/複数形は訳出せずに、文脈で示唆するに止めることが多い。 この文でも「これらのキュー間」がすぐ後に来てるから複数形であることは示唆されている。 のだけれど、文脈の流れで数が重要な情報を担っている場合は、陽に訳出してあれば 読者が何度も読み直したり原文に当たったりする必要が減るだろう。

スケジューラはアプリケーションを(複数の|いくつかの)「キュー」にまとめ、~

対照をより強調するために、前パラグラフのデフォルトのスケジューラについて「アプリを一つのキューに並べるデフォルトの…」としておくこともできるだろう。

また、この後に、デフォルトでは"default"という単一のキューが使われると出てくるのだけれど、 それに続けて複数のキューに振り分ける方法がいくつか説明される。 私が訳すとしたら、その流れを示すために 次の文を「デフォルトでは〜単一のキューを共有します、アプリケーションが〜」 といった具合に原文にない接続詞を補うかもしれない。 (原文に無い言葉をどこまで補うべきか、というのは難しい問題だが、 技術文書の場合は読者の想像力に訴えるよりは意味をなるべく明確に伝達する方が優先されるだろうから、 論理の流れを示すような補間はわりと有効だと思う。)


現訳

フェアスケジューラは、すべてのアプリケーションをデフォルトで実行することができますが、configファイルを使用して、実行中のアプリを実行するアプリ数をユーザごとおよびキューごとに制限することもできます。

原文

The Fair Scheduler lets all apps run by default, but it is also possible to limit the number of running apps per user and per queue through the config file.

後半の「実行中のアプリを実行するアプリ」は多分編集ミスだろうけれど、 ここで見たいのは "lets all apps run" の方。 「何もしなければ全部走らせる→configで制限かけることもできる」というのがここの流れだが、 「Aできますが、Bもできます」では並置の印象が強く、原文にある流れが消えているのが 読みづらさの要因だろうと思う。

フェアスケジューラは、デフォルトではすべてのアプリケーションを実行しますが、 configファイルを使用して、同時に実行するアプリ数をユーザ毎やキュー毎に制限することも できます。


現訳

これは、一度に何百ものアプリケーションを送信しなければならない場合や、一度に多数のアプリケーションを実行すると、中間データが非常に多く生成されたり、コンテキスト切り替えが多すぎたりすると、パフォーマンスを向上させるために役立ちます。

原文

This can be useful when a user must submit hundreds of apps at once, or in general to improve performance if running too many apps at once would cause too much intermediate data to be created or too much context-switching.

現訳は一番外側の「これは、〜パフォーマンスを向上させるために役立ちます。」で主語述語の 対応が取れてるように見えるために、校正時にもつい読み流してしまうのかもしれない。けれど 間を良く読んでみると翻訳の日本語で節間のつながりが良く分からなくなっている。 二つめの「すると」は意味的に「役立ちます」にはつながらない。

原文の構造は次の通り:

   useful 
    +- when a user must submit ... at once
    +- (in general) to improve performance
          +- if running too many apps at once would cause
               +- too much intermediate data ...
               +- or too much context switching

when節とto improveの句が並置されている(意味的には、単なる並置というより、 前者を後者で一般化説明していると考える方が良いだろう)。

ということは翻訳文は次のように解釈するのが正しいことになる。

  これは、
     - 一度に何百ものアプリケーションを送信しなければならない場合
     - 一度に多数の〜パフォーマンスを向上させるため
  に役立ちます

翻訳文をこう切れば(接続語の問題を除いては)間違いとは言いきれないが、 自然言語ではネストをうまく表現できないので、人間が今の翻訳を一読すると

   これは、
     - 一度に何百ものアプリケーションを送信しなければならない場合や
     - 一度に多数のアプリケーションを実行する
   と、
     - 中間データが非常に多く生成されたり、
     - コンテキスト切り替えが多すぎたり[するので]、
   パフォーマンスを向上させるために役立ちます。

という具合に読んでしまうのではなかろうか。

これは、木構造をシリアライズするにあたって、語順の違いによって曖昧性が生じてしまう例である。 日本語の場合、枝に分岐した後、述語で合流させないとならないので、切り方が難しい。 接続詞と句読点を工夫したり、主語述語の塊を後ろに持ってくるといった手が使える:

一度に何百ものアプリケーションを送信しなければならない場合、より一般的には、一度に多数のアプリケーションを実行して中間データが非常に多く生成されたりコンテキスト切り替えが多くなりすぎる時の性能を向上させるのに、これは役に立ちます。

あるいは、in general以降が一般化した説明であるという意図を汲んで文を 分割するか:

これは、一度に何百ものアプリケーションを送信しなければならない場合に便利です。 より一般的には、一度に多数のアプリケーションを実行して、中間データが非常に多く生成されたり、コンテキスト切り替えが多くなりすぎる時の性能を向上させるのに役に立つでしょう。


共通点としてなんとなく見えてくるのは、以下の点の弱さだ。

  • 文やパラグラフをまたいだ「流れ」を読者に示すための適切な訳語の選択
  • 翻訳文を読んで読者が頭の中に構造を描けるか、という読者視点からの配慮

機械翻訳がこれら、特に後者に弱いのは致し方ないとも言えるので、 下訳から直してゆく際に翻訳者が特に注意すべき点と考えた方が良いと思う。

翻訳者はなまじ原文を読み込んでいるために、下訳の日本語が少々おかしくても 好意的に解釈して見逃してしまうという危険があるかもしれない。 「流れ」を示す訳語の選択は、時として本当に些細な接続詞や句読点の 違いだったりする。そんな、一見どうでもいいような違いを自信を持って修正できるには、 原文が何を言っているのかを明確に把握している必要がある。 その点で、参照エントリが言うように、機械翻訳を使えるからといって 翻訳者に必要とされる英語力が下がるということは当分は無いだろう。

Tags: 翻訳, 英語

Past comment(s)

shiumachi (2016/11/26 14:14:49):

元記事の著者及び訳者です。 Shiro様のような方にこのような素晴らしい記事を書いていただけるとは、大変恐縮です。また、建設的なご指摘本当にありがとうございます。

おそらく十分ご認識されているとは思いますがあらためて今回の試みの趣旨を説明させていただきますと、新Google翻訳の有効性を検証するために、時間最優先で翻訳を行いました。普段ならもっと丁寧に翻訳やレビューを行っているところもあえてスピード優先で作業を行いました。この作業を通して分かったことについては拙記事に記載した通りですが、その上で以下コメントさせていただければと思います。

まず、訳者である私がコンテキストを理解しすぎていたことが問題であることを強く感じました。例えば「on memory」のくだりは、「CPUもメモリもどちらも利用可能」ということが私の中で当然の知識として存在していたため、私は問題なく読み流してしまっていました。しかし、ご指摘の通り、コンテキストを知らない人にとっては理解しづらい文章となっていました。以後の文についても、「この文章から何かを学び取る」という視点で読んでいなかったために、分かりにくい文章が多くなってしまったかと思います。こうしたレビュー時の視点は今後改善していきます。

queue/queuesについては、単に字面を流し読むだけだと読めてしまっていましたが、少し丁寧に読めばすぐおかしいと気づきますね。ご指摘ありがとうございます。

「実行中のアプリを実行するアプリ」ですが、これは新Google翻訳のバグで、文字を繰り返してしまうときがあるというものと思われます。原因については不明ですが、こちらの記事が参考になります。 http://www.yasuhisay.info/entry/2016/11/23/000000

「〜すると、…のに役立ちます」は、ご指摘の通りです。日本語としておかしいので、これはレビューで見つけるべきものでした。

文やパラグラフをまたいだコンテキストを理解していない理由ですが、現在のGoogle翻訳がWebページ全体の翻訳に対応しておらず、ある程度のサイズのチャンクとして手作業で入力しないと翻訳できないという点にあります。 パラグラフ単位で分割し、あるいはパラグラフが大きい場合はさらに分割して翻訳にかけていたため、全体のコンテキストを踏まえて訳語が生成できていないというご指摘は当然と思います。 今回は実験的な要素が強かったためレビューや校正にはあまり力を入れませんでしたが、実際にはこのあたりの調整に時間を割くことが重要になるかと思います。

いただいたご指摘ですが、もしよろしければQiitaに反映していただけないでしょうか?編集リクエストを送るというボタンがありますので、こちらから反映していただけると大変うれしいです。

shiro (2016/11/26 22:18:57):

はい、shiumachi様の今回の意図は「この方法でどこまでスピードアップできるか」であると思いましたので、Google翻訳の弱点がそのまますり抜けて出てきているのだろうなと思いました。注意すべき点を明確にしたということでも有用な実験だと思います。それと、多分最初に作業した本人は思い込みで見落とすことが必ずあるので、ドラフトとしてこれを出してバザール方式で改善してゆく、という方向はありだと思いました。

文脈の考慮は、それ自体が広義のパターンマッチである以上いずれ機械翻訳も対応するのでしょうが、巷で言われるほど近い話でも無いんじゃないかなと個人的には思っています。見る範囲を広げると急速に考慮すべきオプションが増え、それに対応するために必要な学習データ量も同じだけ増えるからです。例えば複数形が文脈に影響を与えるためそれを訳し分けている例文、というのはそんなに多くないんじゃないかな、とか。

こういう、翻訳に関するメタな議論まで拾ってそれを何らかの形で自動的に翻訳アルゴリズムにフィードバックする仕組みまで作れば、予想以上のペースで進化するかもしれませんが。

shiumachi (2016/11/26 23:21:00):

はい、私も同意見で、文脈を把握した機械翻訳はまだ先の話と思います。shiro様が書かれた通り、機械翻訳で下訳→人の目を増やして文脈のつながりを整える、というのが精度と効率のバランスをとる使い方ではないかと思います。そういう意味では、編集リクエストを出せるQiitaを本実験のプラットフォームに選んだのは正解だったと言えますね。 編集リクエストありがとうございました。フィードバックありがとうございます。反映させていただきました。

Post a comment

Name: