日本語データ
なぜ日本語データはAIにとって難しいのか
英語を前提に組まれたNLPパイプラインの前提を崩す、日本語の7つの性質。そしてそれぞれについて、アノテーションガイドラインが下さなければならない判断。
このページは、日本語のデータセットの仕様を書く立場にあり、これから何を決めさせられるのかを見極めようとしている方に向けて書いています。
壊れ方は、エラーではなく沈黙です
日本語のデータセットは、派手に壊れることがめったにありません。同じ問いに対する二つの妥当な答えを、あたかも同じ答えであるかのように記録することで壊れます。あるアノテーターは社名のエンティティに 株式会社 を含め、別のアノテーターは外す。ある書き起こし担当者は ありがとう と書き、別の担当者は 有難う と書く。ある評価者は それはちょっと難しいです を難易度の説明と読み、別の評価者は拒否と読む。パイプラインは何も異議を唱えません。その不整合が、そのままモデルの学ぶ内容の一部になります。
日本語のアノテーション業務が、作業量よりも仕様の記述に支配されるのはこのためです。以下に挙げる難しさのほとんどには、唯一の正解がありません。あるのは、選び、書き出し、そのあと1万回まったく同じように適用しなければならない解だけです。その選択を明示的に行う小さなチームは、行わない大きなチームに勝ちます。
以下は、当社がプロジェクトの冒頭で一つずつ確認していくリストと、それぞれが迫る判断です。あえて具体的に書いています。これらは、当社が実際にお客様にお尋ねする質問です。
要点
- 文字体系
- 漢字・ひらがな・カタカナ・ローマ字の4種類が同時に使われ、1つの文の中に共存することも多い。
- 語の境界
- ありません。分割は形態素解析器が生成するもので、解析器どうしの結果は一致しません。
- 丁寧さ
- 文法上、必ず選択を迫られます。文末はすべて社会的な関係を表します。
- 主語
- 日常的に省略され、文脈から補われます。数文前が指示対象ということもあります。
- 実務上の帰結
- 日本語データの欠陥の多くは、アノテーターのミスではなく、決めていない判断です。
難しさ
英語前提の想定を崩す7つの性質
いずれもデータセットの癖ではなく、言語そのものの性質です。日本語のプロジェクトである限り、必ず現れます。
同時に使われる4つの文字体系
漢字・ひらがな・カタカナ・ローマ字同じ語を漢字でも、ひらがなでも、カタカナでも、ローマ字でも書けて、4つとも1つの文に現れることがあります。卵、たまご、タマゴ は同じ語で、含みが違います。コンピュータ と コンピューター は1文字違いで、どちらも標準的な表記です。
当社の対応 正規化ルールで、頻出語の表記を列挙し、それ以外の既定を定め、長音と全角・半角の扱いを固定します。以降のことは、すべてその文書から派生します。
語の切れ目のない表記
分かち書きがない日本語のテキストは切れ目のない文字列です。語の境界は形態素解析器が生成するもので、MeCab、Sudachi、Juman++ は同じ文を違うように分割します。一方に合わせて付けたスパンは、他方には整列しないことがあります。
当社の対応 アノテーション前に解析器と辞書を固定し、スパンは文字オフセットで保持してトークナイザーの変更に耐えるようにし、トークンの途中で終わるスパンがないことを検証します。
文法が強制する丁寧さの選択
敬語日本語の文法は、ほぼすべての文で丁寧さの選択を迫ります。尊敬語 は相手を立て、謙譲語 は自分を下げ、丁寧語 は中立的な丁寧さの水準です。正しい選択は内容ではなく、関係によって決まります。
当社の対応 プロダクトの接点ごとに既定の文体を一つ選び、例外を列挙し、レビューでは文体を独立した基準として採点します。内容は良いが文体が誤っている応答が通らないようにするためです。
主語・目的語の省略
主語省略・ゼロ代名詞日本語は、文脈から復元できるものをすべて省きます。単独で書かれた応答は、しばしば誤った指示対象に結びつきます。マルチターンの対話では、本来の指示対象が数ターン前にあることもあります。
当社の対応 会話はターン単位ではなく、まとまりとしてアノテーションしレビューします。指示対象が本当に復元できない場合は、推測するのではなく、その項目の欠陥として扱います。
断りの文法としての婉曲表現
断りの婉曲表現拒否は、難しさや事情についての説明として表されることがよくあります。それはちょっと難しいです は断りです。ちょっと考えさせてください も、多くの場合は断りです。字義どおりに読むと、意味が反転します。
当社の対応 拒否のカテゴリと意図した強さを実例とともに定義し、拒否は否定語を含むかどうかではなく、日本語話者がそれを拒否と読むかどうかで採点します。
複数の正しい読みを持つ固有名詞
固有名詞の読み漢字で書かれた日本語の人名や地名には、読みが複数あることがよくあり、どれが正しいかは規則ではなくその個人についての事実です。東海林 はショウジとも トウカイリンとも読み、どちらも実在する姓です。
当社の対応 読みは推定せず、独立したフィールドとして取得し、出典に照らして確認します。確認できない読みは、最も多い読みを選ぶのではなく、未確認として記録します。
一般的な日本語とは異なる専門分野の文体
専門用語・文体法務、税務、医療、行政の日本語には、独自の語彙、文構造、慣用表現があります。契約条項や税務の説明が正しい書き方になっているかを判断するには、日常的な日本語が流暢なだけでは足りません。
当社の対応 データが書かれている文体に合わせてアノテーターを選びます。下される判断が言語的なものではなく専門的なものである場合は、ドメイン専門家を入れます。
実例
一つの言葉に、5つの意味
以下の言葉は、ありふれていて、丁寧で、きわめてよく使われます。5つの読みのどれが当てはまるかは、周囲の状況だけで決まります。そしてその状況こそ、アノテーションガイドラインが供給しなければならない情報です。
大丈夫です。
Daijōbu desu.
一つの言葉に、いくつもの意味。
各項目にカーソルを合わせると、その意味が選ばれる文脈が表示されます。
ホームページで使っているものと同じ例です。日本語アノテーションで難しいのは語彙ではなく文脈である、という点を最も端的に示す例なので、ここにも置いています。
仕様
着手前に書き出しておく価値のある判断
書き出さなければ、以下はすべて、データに触れる人それぞれが暗黙に、しかもばらばらに決めることになります。
- 頻出語をどの文字種で書くか。そして、一覧にない語の既定ルール。
- 数字をアラビア数字にするか漢数字にするか。助数詞、日付、金額、時刻の書き方。
- スパンの境界を定義する基準となる、形態素解析器と辞書。
- 株式会社 のような法人格の接頭辞・接尾辞を、組織のスパンに含めるか外すか。
- 複合名詞に対する最長一致・最短一致の方針と、入れ子を認める範囲。
- 既定の丁寧さの水準、その例外、そして正しい拒否とはどういうものか。
- 全角・半角の正規化。何を変換し、何をそのまま保つか。
- 和暦の日付をどう記録するか。西暦への変換値を併記するかどうか。
- 本当に曖昧な項目をどうするか。フラグを立てるか、エスカレーションするか、除外するか。
用語集
日本語のアノテーションガイドラインに出てくる用語
日本語のデータ仕様書で出会う語彙を、アノテーション業務での実際の使われ方に沿って定義しています。
- 敬語
- 尊敬・謙譲・丁寧の各形を含む、日本語の敬意表現の体系全体。使うかどうかは任意ではなく文法上の必須であり、そのためすべての文が社会的な立ち位置を表します。
- 尊敬語
- 話題にしている相手を高める表現。顧客、取引先、目上の人について使い、自分については使いません。
- 謙譲語
- 聞き手に対して、話し手または話し手側を下げる表現。日本のビジネスコミュニケーションで、自分の行為を述べるときの標準です。
- 丁寧語
- 主に ですます の文末で示される、素直な丁寧さの水準。日本語で一般消費者向けのAI出力の既定として、最もよく使われます。
- 分かち書き
- 語と語のあいだに空白を入れて書くこと。日本語では標準的ではなく、そのため分割はテキストから読み取るのではなく、形態素解析器に生成させる必要があります。
- 形態素解析器
- 日本語テキストを形態素に分割し、品詞を付与するツール。MeCab、Sudachi、Juman++ がよく使われ、結果が常に一致するわけではありません。
- ふりがな・ルビ
- 漢字の上や横に小さく組まれ、読みを示すかな。本文ではなく読みの注記なので、アノテーション済みテキストでは独自の表現方法が必要です。
- 送り仮名
- 活用を示すために漢字の後ろに書くかな。同じ語に複数の書き方が認められることが多く、表層の揺れの一般的な原因になります。
- 表記ゆれ
- 表記の揺れ。同じ語が、コーパスの中で異なる文字種や綴りで現れること。仕様が定まっていない日本語データセットで、最もよくある欠陥です。
- 全角・半角
- 全角と半角の文字形。A と A はほとんど同じに見えて別の文字なので、正規化を明示的に定める必要があります。
- 助数詞
- 数に付く助数詞。数える対象の種類によって変わり、読みも不規則なため、とくに音声データで問題になります。
- ゼロ代名詞
- 文脈から復元しなければならない、省略された主語や目的語。日本語では広く見られ、生成テキストで指示対象を取り違える原因になります。
- 旧字体
- 改定前の字体の漢字。古い文書、登記記録、一部の人名に今も残ります。人物や登記された法人を特定する場合は、正規化せずそのまま保持しなければなりません。
- 和暦
- 令和6年 のような、元号に基づく日本の年表記。公的文書や帳票でよく使われ、同じページに西暦と並んで現れることも多くあります。
よくあるご質問
日本語データについて
初めて日本語のデータセットを構築するチームからのご質問。
プロンプトやタスクの発想については、翻訳は妥当な足場になります。応答についてはそうではありません。翻訳された日本語は、英語の文構造、英語の丁寧さの前提、英語の書式習慣を引き継ぎ、それを学習したモデルの日本語を、ネイティブは「翻訳調」と評します。さらに翻訳では、日本語にしか存在しない現象、つまり敬語の一貫性、間接的な拒否、表記の揺れを生み出せません。それこそが、教えようとしている振る舞いそのものです。
文体、拒否の強さ、語用論的な意味が関わるものについては、ネイティブの判断は「あればなお良い」ものではありません。それはちょっと難しいです が断りとして読めるかどうかは、その文がネイティブの聞き手にどう届くかという事実であり、非常に上級の非ネイティブでも、正しく分析しながら強さを見誤ることがあります。仕様が十分に細かい機械的なタスクであれば、上級レベルで足りることも多くあります。
ラベルがスパンである限り、効きます。解析器が違えば境界の置き方も違うため、ある分割に合わせて付けたスパンが、別の分割ではトークンの内側に落ち、BIOタグはそれを黙って動かします。タグ形式と並べて文字オフセットを保存しておくことが、あとからトークナイザーを変えても再アノテーションせずに済む条件です。
1件あたりで見れば、たいていは高くなります。仕様の記述量が多く、アノテーターの母数が小さく、二人目のネイティブによるレビューを要するタスクが多いためです。これを相殺するのは、よく仕様の定まった日本語データは1件あたりの効きが大きいという点です。モデルが学んでいるものの大きな部分は一貫した文体であり、一貫性は量ではなく仕様によって達成されるからです。
実データのサンプルです。雑だとお考えの部分も含めてお送りください。あわせて、それに対してモデルに何をさせたいかの説明を。それだけあれば、上に挙げた判断の草案を書き、小さなパイロットにアノテーションし、妥当な二人のアノテーターの判断が分かれる箇所をお見せできます。それが、仕様に何が欠けているかを知る最速の方法です。
日本語データ
難しいのは仕様です。そこから始めてください。
データサンプルと、モデルにさせたいことをお送りください。ガイドラインが下すことになる判断と、それを検証するパイロットをお返しします。
データをご共有いただく前にNDAを締結します。パイロットの要件定義は無料です。