この土台は、下の層まで英語優先でできている

訓練データが英語に偏っていることは、誰でも知っています。 言語対応の話で最初に出てくるのがこれで、実際そのとおりです。ただ、これは問題のなかでいちばん面白くない層でもあります。予算がつくのはこの層だけだからです。その下の層には、めったにつきません。

その前提が隠れている五つの場所

• トークナイザー。ラテン文字に合わせて作られているため、他の文字体系は同じ意味により多くのトークンを払う。
• 評価スイート。モデルを出してよいかを決めるのに、圧倒的に英語で書かれている。
• ドキュメントとプロンプトの手引き。英語にしか存在しない尋ね方を教えている。
• エラーメッセージ。利用者がいちばん困っているまさにそのときに英語へ切り替わる。
• 言い伝え。どんな言い回しが効くかという口伝は、他の言語へは移らない。

ひとつずつなら擦り傷です。まとめて効いてくると、誰がこの道具を使えると感じるかが決まります。技術的には多言語でも、英語アプリに翻訳の殻をかぶせただけのように感じられることがあり、利用者は三十秒ほどでその違いに気づきます。

私たちがしていること

言語をロケールファイルではなく、プロダクトの表面として扱っています。 つまり、インターフェースもモデルのふるまいもサポートも、あなたが来たときの言語についていくということ。自分たちの評価も、対応していると言う言語で走らせるということ。英語で走らせてあとから翻訳するのではなく。そして、ラテン文字の外でしか出ない不具合から先に潰すということです。

英語のプロダクトに言語切り替えを付けて出すより遅いやり方です。それでも、つくる価値があるのはこちらだけです。切り替え方式は、いちばん大事な場面で壊れるからです。誰かが自分にとって大切なものを説明しようとしている、その瞬間に。

試験に使われた利用者にとっていちばんよく動く道具は、それ以外のすべてを必ずロングテールと呼ぶようになる。

ここにいる誰も話さない言語では、必ずどこかを間違えます。だから、何を検証したのかを公の場で具体的に書くようにしています。間違いが見える形になるように。影響を受ける人が黙って引き受ける形にならないように。