著者注:機械学習モデルがいつ、どのように、なぜ失敗するかを分析することを「エラー分析」と呼びます。科学研究者は、エラー分析を使用してその後の改善方向を選択する必要があります。また、モデルの実際のユーザーも、エラー分析に基づいてモデル展開の多くの詳細を決定する必要があります。エラー分析はその後の行動の方向性に大きな影響を与えるため、エラー分析に偏りがあったり、エラー分析が不完全であったりすると、望ましくない結果をもたらす可能性が高くなります。 NLPタスクのエラー分析の現状 しかし、現在、エラー分析はどのように行われているのでしょうか? 自然言語処理のトップ学術会議である ACL の受理論文を見ると、基本的に次のような説明が見られます。
どうやら、この分野の研究者は皆、同じアプローチを採用しているようです。「私たちは、50~100 個の誤答問題をランダムに選択し、大まかに N 個のグループに分けました。」 (スタンフォード大学 NLP グループの責任者、クリストファー・マニングによるナレーション: 質問応答タスクに関する論文でエラー分析のために 100 個のサンプルを選択するという慣習はおそらく私が考案したものです。当初は 200 個のサンプルを選択したいと思っていましたが、割り当てられた半分を私が実行することはありませんでした) 分析のために不正確なサンプルの一部を選択することは理にかなっているように思えるかもしれません。しかし実際には、このアプローチには大きな問題があります。たとえば、サンプル サイズが 50 ~ 100 では小さすぎ、通常は全体のエラーの 5% しか占めません。このような小さなサンプルサイズでは、実際の誤差分布を表すことはほとんどできません。重大なモデルの問題がエラー分析に使用されたサンプルに反映されておらず(たとえば、チャットアシスタントロボットが特定の文章に対して不適切な応答を返すなど)、修正されていないモデルが実際に展開された場合、結果は間違いなくひどいものになります。 しかし、それだけではありません。サンプルサイズが小さいことは、一般的な慣行における最初の問題にすぎません。 ACL 2019 論文「Errudite: スケーラブルで再現可能、テスト可能なエラー分析」では、著者らが NLP エラー分析における多くの重要な課題を詳細に列挙し、誰もがエラー分析をより正確で、より再現性、スケーラビリティ、テスト性に優れたものにできることを期待して、3 つの原則を提案しました。著者らは、これらの原則を実装し、発見された問題を一つずつ解決することもできるインタラクティブ ツールである Errudite も設計しました。 論文の著者らは、特定のエラー分析プロセスを使用して、少数のサンプルに基づく現在の手動の主観的なエラー分析が曖昧で偏った分析になりやすく、エラーの原因を誤解する可能性がある理由と、Errudite の助けを借りてこれらのエラーを回避する方法を説明した入門ブログも執筆しました。彼らの論文にはさらに多くの例が載っています。 Leifeng.com AI Technology Reviewが紹介ブログの全文をまとめました。 実例から始めましょう 機械読解のベンチマークモデルとしてよく知られている BiDAF (https://allenai.github.io/bi-att-flow/) のエラー分析を行いたいと考えています。このタスクでは、質問とテキストの一部が与えられた場合、機械読解モデルは質問に正しく答えることができるテキストセグメントを見つける必要があります。 SQuAD データセットのこの例では、太字で示されている Murray Gold が 2005 年の Doctor Who スペシャルを執筆しました。 言語理解のための最も重要なテストタスクの 1 つとして、機械読解におけるエラー分析は重要ですが、多くの困難も伴います。研究者は高度なモデルの弱点を見つけて改善したいと考えていますが、モデルの入力 (質問、テキスト段落) と出力 (回答) はどちらも非構造化テキストであるため、データ セットを分析および解釈するために使用できる機能はほとんどありません。 BiDAF は、機械読解タスクを研究する学者には非常に馴染みのあるモデルです。以下で使用されているエラー分析の例はすべて、研究者による BiDAF の実際の分析から得たものです。 この例では、BiDAF は誤った予測を行い、Murray Gold ではなく John Debney (下線部) という答えを出しました。このエラーから一般化して、モデルのパフォーマンスをより包括的に理解できるようになることを期待しています。 このエラーを分析する際、最初に尋ねる質問は、「なぜモデルはこのような間違いをするのか」です。専門家は、ノイズ ワード仮説を提案しました。BiDAF は、さまざまな名前付きエンティティ カテゴリに質問を一致させることに優れていますが、同じタイプの他のエンティティが同時に出現すると、BiDAF は簡単に気を散らされてしまいます。上記の例では、私たちが尋ねた質問は「誰」であり、BiDAF は名前が必要であることを認識し、名前を答えましたが、それは正しい名前ではありませんでした。 この仮説に基づいて、次に問うべき質問は、「このモデルはこのような間違いを頻繁に起こすのか?」です。この仮説の普遍性を探るには、さらに類似したサンプルを研究する必要があります。しかし、上で述べたように、データセット全体を調査する場合、これらの非構造化テキストで利用できる機能が少なすぎるため、研究者は通常、いくつかのエラーサンプルに手動で注釈を付け、それらをさまざまなグループに分類します。 このアプローチの問題点は、さまざまなグループの定義が主観的であり、人によってグループ化の仕方が異なることです。たとえば、別の例では、「いつ」という質問に対する標準的な回答は「大学在学中」ですが、モデルは間違った年である「1996 年」と応答しました。これは、気晴らしの仮説に当てはまる質問だと考える人もいるかもしれません。結局のところ、この質問は時間について尋ねており、モデルによって与えられた回答のタイプ(これも時間)と一致しています。しかし、これは別のエラー カテゴリに属するべきだと考える人もいるかもしれません。結局のところ、標準的な回答である「大学在学中」は、認識可能な名前付きエンティティではありません。エラー例の名前とテキストの説明だけを見ると、そのような違いがあることに気付かないかもしれません。 実際、著者らは、異なるエラー グループを定義するために単純なルールを使用した場合でも、人によってこのばらつきや不一致が生じる可能性があることを発見しました。著者らは、以前に公開されたエラー分析からエラーの種類とその説明を取り、現在の専門家に実験を繰り返すよう依頼しました。著者らがこのグループに割り当てたエラーの数は、最小 13.8% から最大 45.2% まで大きく異なり、手動によるラベル付けの曖昧さをさらに実証しています。 この状況に対処するために、論文の著者らは、誤った推測は明確な説明で正確に定義されなければならないという最初の原則を提案しました。 原則1: 正確性 人間の主観を避けて精度を向上させるために、Errudite はドメイン固有の言語を使用してさまざまなインスタンスを定量化し、説明します。 簡単に言えば、このタスク固有の言語は、強力な属性抽出器のセットを使用し、追加の補助演算子 (属性抽出器、ターゲット、演算子) の助けを借りて特定のエラーを解決します。たとえば、質問の長さを解析し、長さが 20 より大きいことを要求できます。このようにして、研究者は特定のパターンに従って多数のエラー例を客観的かつ体系的にグループ化し、特定のエラーの正確な発生頻度を得ることができます。たとえば、下の図は、この言語を使用した「干渉語仮説」の正確な説明であり、「大学在学中」という例をこのカテゴリから除外できます。 原則2: すべてのデータをカバーする このフィルターをすべての BiDAF エラーに対して実行した結果、「ノイズ ワード仮説」を満たす 192 の例が見つかりました。つまり、標準の回答と誤った回答は同じ名前付きエンティティ タイプを持ち、モデルは誤ったエンティティを返したということです。このような精度の達成に基づいて、タスク固有の言語の使用によってエラー分析の規模も大幅に拡大できることは注目に値します。合計 50 ~ 100 個のエラー サンプルを分析するという一般的な方法と比較して、単一のエラー カテゴリのサンプル サイズは現在 192 個に達します。これにより、サンプリング誤差も減少します。 合計数で見ると、これら 192 個の誤ったサンプルは、すべてのエラーの 6% を占めており、干渉語仮説は検証可能であると思われます。具体的なデータがあれば、エラー分析の説得力も格段に強くなりますよね? しかし、すべてのステップでフィルターを実行し、詳細なグループ化を行った後、実際にはまったく新しい図が見つかります。すべてのサンプルに対して、BiDAF はサンプルの 68% で正しいエンティティを提供できます。標準の回答がエンティティであるサンプルの場合、モデルの精度は 80% に向上します。テキスト内に同じタイプの他のエンティティがある場合、BiDAF の精度は依然として 79% です。正しいタイプのエンティティを予測するように求められた場合、その精度は 88% まで上がり、すべてのサンプルの精度よりもはるかに高くなります。これは、エンティティ タイプが一致し、干渉語が出現する場合でも、モデルのパフォーマンスが全体のパフォーマンスよりも優れていることを意味し、この状況はモデルのパフォーマンスの欠点ではありません。したがって、何かが間違っていることに気付き、まずそれを修正することに決めた場合は、モデルのパフォーマンスが非常に悪い状況を無視している可能性があるため、再考したほうがよいかもしれません。 したがって、このドメイン固有言語は、エラー サンプルがないことを確認するなど、データ セット全体を分析するのに役立ちます。このようなエラー分析はより体系的であり、より大規模にサポートできます。導き出される結論は、少数のサンプルのみを調べて得られる結論とはまったく異なる可能性があります。 次に、2 番目の原則は次のように正式に述べることができます。エラー頻度の分析は、真陽性を含むデータ セット全体に対して実行する必要があります。 原則3: 誤った仮定をテストし、因果関係を検証する これで、ノイズワードのグループ化が確立されました。ただし、エラーと同時にノイズ ワードが存在する場合、必ずしもそのノイズ ワードがエラーの根本原因であるとは限りません。前の例に戻ると、エラーの根本的な原因は干渉語によるものであると単純に推測できますが、複数の推論を行う必要がある場合や、「Doctor Who」と「series」を関連付ける必要がある場合など、他の理由がある可能性もあります。 これにより、私たちが直面している現在の状況の別の問題が浮上します。つまり、エラーの根本原因を効果的に特定することが難しいのです。明確にするために、3 番目の原則が必要です。 原則 3 4 Errudite 氏、論文の著者らは、この質問に答えたいと考えています。これら 192 個のエラーはすべて干渉語によって発生したものでしょうか。検証方法は、関連する仮説的な質問「干渉語がない場合、モデルは正しい答えを出すことができるか」を提起して検証することです。著者らは、書き換えルールと反事実分析を使用して答えを見つけます。 このドメイン固有言語に基づいて、Errudite は特定のルールに従ってグループ内のすべてのインスタンスを書き換えることができます。たとえば、ここでは、干渉語が根本原因であるかどうかを確認するために、テキスト内の干渉語を書き換えルールに従って意味のないプレースホルダー「#」に置き換え、エンティティとして検出されないようにしています。 書き換えが完了したら、モデルに再度予測を行わせます。前の Doctor Who の例では、誤った回答である John Debney が「#」に置き換えられたにもかかわらず、モデルは依然として別の誤った回答である Ron Grainer を返しました。他の妨害要因がまだモデルを混乱させているようです。 グループ内の他のサンプルでは、29% のケースでモデルは同じタイプの別の誤ったエンティティ (別の干渉語) を生成しました。48% のケースではモデルは正しい予測を生成し、これらのサンプルでは干渉語が誤った予測につながりました。残りの 23% では、モデルは以前と同じ予測を生成しました。ただし、これらの文字は「#」に置き換えられたため、モデルの予測結果には実際には意味のないこの「#」文字が含まれます。これは、質問と予測された回答が非常に重複しているため、モデルが実際に実行するのはエンティティの検索ではなく、単純な文字のマッチングに近いためであると考えられます。この反事実的分析から導き出された結論は、単純にグループ化するだけでは得られません。 正確 + 再現可能 + 繰り返し可能 上記のエラー分析プロセスでは、正確なクエリ ステートメントを使用して属性を構築し、グループ化し、書き換えルールを実行する必要があります。 BiDAF を分析した結果、ノイズ ワードがあってもパフォーマンスがそれほど悪くないこと、以前はノイズ ワードが原因だと思っていた問題の一部に実際には別の根本原因があることがわかりました。 さらに、正確なクエリ ステートメントの大きな利点は、他のユーザーと簡単に共有でき、実験結果を再現して、他のモデルや他のタスクに適用できることです。 最後に、論文の著者らは、Errudite ツールは明確で使いやすく、多機能なグラフィカル ユーザー インターフェイスを備えており、ステートメントのデモンストレーションや属性分布図などの実用的な機能を備えているとも述べています。 要点のまとめ よくある(しかし偏った)エラー分析は、
Errudite (改良版) エラー分析
NLPを超えたエラー分析の影響 現在の Errudite 実装 (特にドメイン固有言語部分) は、NLP タスクのみを対象としています。ただし、機械学習システムでは、多くの場合、テキスト以外のデータも処理する必要があります。論文の著者らは、現時点では他の分野への実装の拡大は難しいとしても、3 つの原則は他の分野に適用でき、また適用する必要があると考えています。そうすることで、誰もが正しいモデルを展開し、正しい研究の方向性を深く掘り下げることができるようになるからです。 次の 3 つのポイントをサポートしている限り、これら 3 つの原則に基づいて新しいツールを作成することは難しくありません。
著者らは、Errudite のソフトウェア アーキテクチャは他の NLP タスクへの拡張をサポートできると述べ、NLP 分野のより多くの研究者や開発者が Errudite の開発と拡張に参加することを歓迎しています。そして、他の分野でも同様のツールが登場すれば素晴らしいと思います。 |
<<: MIUI 10の最後の開発バージョンが間もなくリリースされます。MIUI 11も間もなく登場します。
>>: 投資家心理は安定しており、人工知能への資金流入は続いている
以前、AI顔変換ソフトウェアZAOが一夜にして人気を博したことで、サーバーが「満杯になって崩壊」する...
1 クローズドループコンセプトとR&Dクローズドループ私たちは毎日、クローズドループを扱って...
これは、AI テクノロジーが身元調査業界に革命をもたらし、これまで以上に効率的でコスト効率の高いソリ...
現在、Microsoft、OpenAI、GitHub が共同で作成した AI プログラミング支援ツー...
この記事はAI新メディアQuantum Bit(公開アカウントID:QbitAI)より許可を得て転載...
日本は、急速に減少する日本の人口によって引き起こされる問題のいくつかに対処するために、人工知能(AI...
本日、OpenAI は立て続けにツイートを数回送信し、「準備フレームワーク」を大々的に発表しました。...
3年前、ディープラーニングを専攻し、2019年度に入学したばかりのコンピューターマスターが知乎に質問...
AIやビッグデータなどの技術の急速な発展に伴い、関連する知識も普及してきました。数多くのウェブサイ...
「私は今、Miqu が Perplexity Labs の Mistral-Medium と同じモデ...
機械学習の手法を使用して問題を解決する場合、適切なデータを持つことが重要です。残念ながら、生データは...