<   2008年 09月 ( 3 )   > この月の画像一覧

なんでも評点:なぜ自動翻訳は使い物にならないのか? ― 翻訳を生業とする立場と経験から分析してみる

えーっと、AI に近いところにおって、
色々思うところがあるわけで、
ちょっと書いてみる。
エンドユーザはこう思っているのかーと、
なかなか興味深いのだが。

まず、なぜ自動翻訳は使い物にならないのか?というタイトルだが、
使い物になるわけがない。

この人も書いているように、
印欧語同士でない翻訳、例えば日英/英日などは、
単語と単語の意味が、ぴったりと対応しているわけではない。
例えば、日本語の「糠雨」と「霧雨」を区別できる英単語はあるだろうか。
アラブの方には、たくさんのラクダをあらわす単語があるらしい。
日本語では多分「○○なラクダ」としか言いようがない。
そして面倒なことに、「糠雨」と「霧雨」はちょっとニュアンスが違う。
糠雨の方が湿度が高くてしっとり感があるが、ベタベタではない。
降るなら春先かな、みたいな。
そこまではさすがに翻訳できない。
翻訳家なら、そのニュアンスも加味して翻訳することができるかもしれない。
そんなわけで、単語と単語の置き換えだけでは、まずうまくいかない。
文脈を解析して、意味を理解した上での置き換えなら、
うまくいくかもしれないが、
現在の技術では、意味解析の実用化はまだ無理。
オントロジーだのセマンティック web だのも、
一時期流行したものの、
現在は、なんか良さそうだけど何に使おうか?という感じ。
実際に動くようになるのは 20 年後くらいじゃないか。
現在使われている形態素解析だって、
実は 20-30 年くらいは研究され続けてきているのだから。

使い物にならない理由として、ほかに挙げられるのは、
チューニングができないということ。
チューニングするには、バイリンガルの協力が不可欠だが、
翻訳家は「精度が上がると自分たちの仕事がなくなる!」と思って、
なかなか協力してくれない。
人間の仕事がなくなるほど精度が上がるなんて、
現在のところはまったく考えられないのだが、
説明してもわかってくれない。
結果、日本語ネイティブがあーでもないこーでもないと、
英語のチューニングをしていたりする。
精度の上がりようがない。
上記リンクの人は理解があるが、
大多数の翻訳家は、この人ほど理解がない。

現在、ホワイトボックステストでも
多分精度は 7-8 割くらいだろうと思う。
ここまでは割とサクサクと来るのだが、実はここからが難しい。
ここから精度を 1% 上げるのに数年かかったりするのだが、
普通の人には「精度が 1% 上がりましたー!」と言っても、
「…で?」と言われるだろう。
企業としても、精度を上げる方向で開発を続けづらい。
ここ 10 年くらいで開発をやめちゃった企業もたくさんある。
こういうのは知識の蓄積でできているので、
一度やめちゃうと、多分もう二度と開発を始められない。
例えば、アメリカは大昔に「機械翻訳なんてクソ」と開発をやめてしまったので、
その分野では、ヨーロッパに大分遅れを取っている。

ま、そんなこんなで、全自動で機械翻訳なんて、まだまだ無理。
できるかも!と思ってる人って結構いるのかな。

上記記事へのツッコミ。
使えない例として、google の翻訳をあげているが、
これは大変にひどい例なので、
例としては如何なものか。
結果から見るに、google のは
統計的手法を主にした機械翻訳なのだろうと思う。
これは学習に食わせるドキュメントの質と量で、格段に差が出る。
forgot なんか入れると、パスワード云々なんて日本語が出ていたので、
食わせているのはきっとマニュアルとか、そういう類の文書。
学習データにあわせて、ニュースよりもマニュアルを入力にしたら、
もうちょっと質が良いものが出力されるかも。
学習に使う文書だが、
日英の対がそろっている文書なんて、実はそうたくさんない。
購入することもできるが、結構お高くてよ。
多分、google のは学習量が足りなすぎ。
他のルールベースのサービスに比較できる品質になるには、
まだ大分お金をかける必要があるが、
翻訳サービスにそれだけの価値を見出すかどうかは、google 次第。
個人的には、全然期待していない。

統計的手法はここ 10 年くらいにホットになったが、
従来のルールベースほど精度が出ないということで、
統計とルールを両方使うほうが良さそう、ということで FA になっている。
ところが、統計的手法のエンジンは比較的簡単に構築できるが、
ルールを記述するのは、
それなりにシステムもルール全体もわかっていないとダメ。
新しくルールを入れたら、別の方がおかしくなった、ということが良くある。
だから、ルールをユーザにカスタマイズさせないのは、そういう理由。
「筆者の構想:完全にプログラミング可能な翻訳システム」の内容が
実現されていないのも、そういう理由による。
作る側は「ユーザは何をしでかすかわからない人」という思想でソフトを作る。
ある程度コンピュータリテラシの高い人を想定してソフトを作ったとして、
それが何本売れるだろう?
それよりは「どんな人でもOK」というソフトを作ったほうが、
明らかに売れる。
たとえ、訳がかなりおかしいとしても、である。

半自動の翻訳機能を人間が操作しながら翻訳出力を生み出すシステムを
目指していれば、もっと使えるものが出来ていた可能性もある。

とあるけれど、実は既に存在する。
汎用性を目指すと帯にもたすきにもならないのは、
開発の人もわかっているので、
分野を特定すれば良いのでは?というのは、誰でも考え付く。
企業としても、いつまで経っても実用化できない開発は続けられないが、
多少でも実用化できれば、開発費が一部でも回収できるかもしれない。
実際、欧州では、天気予報というジャンルに限って、
欧州内の各言語に翻訳するシステムが、大分前から稼動している。
それを日本でもと思うのは当然。
なわけで、実際にある。
でも、企業の中で使われているので、一般の人が知らないだけ。
天気予報じゃなくて、アレとかコレとか。
ちょっと書けないけど。

翻訳メモリに関しては、
翻訳家の間で必須なツールであることは、開発側もわかっている。
しかし、シェアはほぼ TRADOS の寡占状態なので、
TRADOS と提携するのも難しいし、
新規に作った別の翻訳メモリ+翻訳ソフトに
乗り換えてもらうのも難しい。

翻訳家の人の気持ちもわかるんだけど、
色々オトナの事情というのがあるのだよ。

ここまで書いたのは、ちょっと前の AI 業界近所の話。
今はもうちょっと違う状況なのかな。
[PR]
by xiaoxia | 2008-09-25 14:46 | コンピュータ関係 | Comments(0)

カラオケのキーについて

週末と休日の間の22日はお休みにした。
平日にお休みってことで、行きつけのカラオケ屋さんに。
平日の昼間はフリータイムで、
1000円ちょっとで夜8時まで歌い放題なんですわ。
そこでカラオケの話題。

カラオケのキーについて - 教えて!goo

元キーでしか歌えない、という人。
ピアノやってる人じゃないかなーという印象。
ピアノ弾きには固定ドの人が多いので、
キーを変えられると気持ち悪い、と言う人が多い。
楽譜を見る方が覚えやすいとのことなので、
ピアノ弾きである可能性がかなり高いと思う。

ちなみに、ウチのダンナも元キーでないと歌えないらしい。
彼はピアノも弾けないし、楽譜もほぼ読めない。
では何故かというと、どうやら体で覚えているようだ。
体というか、声帯の閉め方というか。
どう考えても出ない音なのに、元がそれなら、それでしか歌えないらしい。
キーを上げ下げすると、声帯の閉め方が変わるので、
あれ?という感じになって、すぐに曲から落ちてしまう。
これも不自由なものだなぁと思う。

というわけで、上記の人の質問なのだが。

1.歌いたい曲があったら何で覚えますか?
原曲を聴くのみ、原曲聴く+歌詞を見る、楽譜・・・etc教えて下さい。


最初は原曲をしばらく聞く。
ここで体に入る曲は、かなり早く覚えられる。
逆に、これで体に入らない曲は、なかなか覚えられない。

次に歌詞を見ながら聞いて、細かい節回しを覚える。
平井堅や元ちとせ、鬼束ちひろなんかは、こぶしやフレージングが細かいので、
そのあたりを注意しながら聞く。

ずっと聞いてもいられないので、このあたりで聞くのをやめて、
別の作業をしたりするのだが、
その間も鼻歌で歌ったりしながら、曖昧な箇所を自分で確認しておく。

翌日にまた原曲を聞いて、
曖昧な箇所を確認。
これで大丈夫なら、カラオケ行っても大丈夫。

楽譜はあんまり関係ないっぽい。
普通にバイオリン弾くときも、かなり耳で弾いているので、
私にとって楽譜は「次にこんなんが来ます」という程度でしかない。
それなら歌詞で間に合う。

2.原曲キー以外にされると急に音痴(?)になったりしますか?


というわけで、元キーでなくてもまったく問題なしだし、
気持ち悪さもないです。
途中で変調しても、割と何とかなる。

3.単純に原曲キーでしか歌えないのってどう思います?


不便だろうなぁと思う。
でも面と向かって「不便だねー」というわけにもいかないので
(ダンナには言うけど)、
「絶対音感あるんだねーすごいねー」と言っておきます。
固定ドの感覚は私にはないから、本当にすごいと思うので。


カラオケ好きのみなさんは、どんな感じでしょうか。
[PR]
by xiaoxia | 2008-09-24 12:30 | | Comments(0)
わかってしまえば、なぁんだってことなのだけど、すごく悩んだので。

php の配列は(見た目は) 2 種類。

hash ぽいものと、array ぽいもの。
// array ぽい
$input_a = array("red", "green", "blue", "yellow");
// hash ぽい
$input_h = array("r"=>"red", "g"=>"green", "b"=>"blue", "y"=>"yellow");


配列から要素を削除する場合、
unset を使いなさいと書かれている。
「php 配列 要素 削除」で検索しても、大体 unset しか出てこない。
マニュアルにはこんな風に。
// 配列の要素の一つを破棄する
unset ($bar['quux']);


これは hash のときに有効なので、以下は有効。
// $input_h['r'] から "red" を取り出せなくなる
unset ($input_h['r']);


じゃ、これは array の方にも有効なんだろうか。
array に見えるものも、
実は中身はインデックスを添え字とした hash になっている。
上に、配列は見た目 2 種類と書いたのはこういうわけで、
実は 1 種類しかない。
つまり以下の 2 つは内部的に等価。
// こんな風に宣言しても
$input_a = array("red", "green", "blue", "yellow");
// 内部では、こんな風に宣言されたのと同じ
$input_a = array(0=>"red", 1=>"green", 2=>"blue", 3=>"yellow");


ってことは、当然 unset で消せる。
// "red" が消える
unset ($input_a[0]);

確かに消えるよ。

しかし、通常 array ぽい宣言をした方は、
順序が保証されていると(頭の中で)思って使うので、
0 から順に値を取り出してみると、
次のようなエラーが出る。
// 値を取り出してみる
for($i=0 ; $i<count($input_a) ; $i++) {
 echo $input_a[$i];
}

PHP Notice: Undefined offset: 0 in test.php on line **


なんでかっつーと、$input_a[0] を消したので、
0 というキーがなくなっちゃって、アクセスできなくなってるのね。
そうなの?と思いつつ、キーを表示してみると、こんな感じ。
// hash キーをカンマ区切りで表示してみる
implode (',', array_keys($input_a));

-> 1,2,3

あらホントに 0 が消えてるわよ。

じゃ、array の場合、キーも値も一緒に消すにはどうしたらいいか。
つまり、値もキーも消して、キーとなっている添え字を詰めて欲しい。
すごく探し回って array_splice を使ってみたら、うまくいった。
// 先頭の要素を 1 つ消す
array_splice($input_a, 0, 1);
implode (',', array_keys($input_a));

-> 0,1,2

おお消えた!
ま、先頭1コなら、通常popを使っちゃうけどね。

なんでこんなことをしたかったのかというと、
3つの要素を持つ配列があって、
その要素が更に配列。
図にすると、こんな感じ。
(ここからは等幅フォントで見てね)

元の配列。
┌─────────┬─────────┬─────────┐
│┌─┬─┬─┬─┐│┌─┬─┬─┬─┐│┌─┬─┬─┬─┐│
││A │B │C │D │││E │F │G │H │││I │J │K │L ││
│└─┴─┴─┴─┘│└─┴─┴─┴─┘│└─┴─┴─┴─┘│
└─────────┴─────────┴─────────┘

各要素の第1要素である A と E と I を比較して、
この配列をソートしたかった。

例えば、上の元の配列から B を unset で削除するとこうなる。
┌─────────┬─────────┬─────────┐
│┌─┬─┬─┬─┐│┌─┬─┬─┬─┐│┌─┬─┬─┬─┐│
││A │  │C │D │││E │F │G │H │││I │J │K │L ││
│└─┴─┴─┴─┘│└─┴─┴─┴─┘│└─┴─┴─┴─┘│
└─────────┴─────────┴─────────┘

第1要素である A E I はそのままだから、
A E I でソートしてもエラーは出ない。

ところが、元の配列から E を unset で削除するとこうなる。
┌─────────┬─────────┬─────────┐
│┌─┬─┬─┬─┐│┌─┬─┬─┬─┐│┌─┬─┬─┬─┐│
││A │B │C │D │││  │F │G │H │││I │J │K │L ││
│└─┴─┴─┴─┘│└─┴─┴─┴─┘│└─┴─┴─┴─┘│
└─────────┴─────────┴─────────┘

ソートするためのキーである第1要素がないので、
A I のところは大丈夫だけど、E があったはずのところところでエラーになる。

なので、E を削除して、更に要素も詰めて、第1要素でソートするためには、
配列は、こうなっていて欲しい。
┌─────────┬───────┬─────────┐
│┌─┬─┬─┬─┐│┌─┬─┬─┐│┌─┬─┬─┬─┐│
││A │B │C │D │││F │G │H │││I │J │K │L ││
│└─┴─┴─┴─┘│└─┴─┴─┘│└─┴─┴─┴─┘│
└─────────┴───────┴─────────┘

このために、 array_splice を使うのね、という話でした。


第1要素がなかったら、次の要素を見る、という風に書いてもよかったんだけど、
それは違うよなぁ、なんか方法あるでしょ常考、という気がしていたのよね。
文字で説明するとややこしいなぁ。

まとめるとこんな感じ。
  • array も hash も中身は hash
  • hash から要素を削除するのは unset
  • array から要素を削除するのは array_splice


こんな簡単なことに数時間悩んでしまった。
なわけで「php 配列 要素 削除」で検索したときに、
array_splice も引っかかったらいいなーと思いつつ、
この記事を書いてみたYO!

LL に限って言えば、
array や hash は、言語によって実装が違うので、
内部がどうなっているか考えながら書かないとなぁ。
つか、この辺がわかると、
その言語の結構な部分が理解できるんじゃないかと思っている。
javascript は object 自体が全部 hash 、とかそういうところ。
かなり言語の特色が出る部分じゃないかと。
[PR]
by xiaoxia | 2008-09-08 12:54 | プログラム言語 | Comments(21)

ダメ女プログラマ&主婦&腐女子&バイオリン弾き


by 小霞