みなさん、こんにちは。今日は、私たちの[研究]成果「演繹的に推論するための[学習]：複雑な[関係性の抽出]として[数学の単語問題]を解く」を紹介します。
ByteDance [AI] Labのアランと申します。この研究はテキサス大学オースティン校のジェルイ・リーと[SUTD]のウェイ・ルーとの共同研究です。
まず、私たちが[推論][する]動機についてお話ししたいと思います。
ここでは、段階的な[推論]が役立つ例を示します。
この図は[PaLM][論文]から引用したもので、Few-Shot[学習]シナリオでネットワーク[問題]を解決するためにプロンプトを実行したものです。
左側をご覧いただくと、[質問]と答えだけの例題をいくつか与えても、正しい答えを得られない可能性があることがおわかりいただけると思います。
しかし、もう少し[推論]の説明を与えると、[モデル]は[推論]の説明を予測し、ここでも正しい[予測]を行うことができます。
ですから、[解釈可能]な多段階の[推論]が出力されるのは良いことです。
そして、このような[推論]能力を評価するためには、[数学の単語問題]がわかりやすく適用できると私たちは考えています。
つまりこちらの[問題]設定では、[質問]を考慮して、その[質問]を解決し、数値的な答えを得る必要があります。
ですから、[データセット]には、この特定の[応答]につながる数式も与えられています。
そのため、ある種の仮定もまた、[以前の]研究成果と同じように適用されます。
量の精度がわかっていると仮定します。
また、加算、減算、乗算、除算、指数関数などの基本的な演算子のみを考慮します。
[さらに]、複雑な演算子は、実際にはこれらの基本的な演算子に分解することができます。
ですので、[数学の単語問題]に関する[以前の]研究は、実は、[シーケンス]から[シーケンス]と、[シーケンス]からツリー[モデル]に分類することができるのです。
従来の[シーケンス]から[シーケンス][モデル]は、式を特定の[シーケンス][に]変換し、[生成]するものです。
このモデルは実装するのが非常に簡単であり、さまざまな複雑な[問題]に[一般化する]こともできます。
しかしその欠点は、一般的にそのパフォーマンスが[構築された][モデル]に劣ることと、[予測][の為]の[解釈度]に欠けることです。
しかし実際には、この方向性が[トランスフォーマー][モデル]であるため、依然として根強い人気です。
ツリーベースの[モデル]では、実際にこれらの式をツリー形式で[構成]し、ツリーの世代で順序づけたトラバーサルを行います。
ここでは、量である葉に到達するまで、演算子を[生成]し続けます。
良い点は、実際に[バイナリ]ツリー[構造]が作られることです。最初に演算子を生成し、最後に量を生成するというのは、とても直感に反します。
もうひとつは、繰り返しの計算も含まれていることです。
つまり、この式を見てみると、8×3＋3は2回[生成]されています。しかし、ここでは結果を再利用すべきです。
ですから、これらの問題を段階的かつ[解釈可能]な形で解決する[アプローチ]を提案したいと思います。
なのでたとえば、2番目のステップでは、除数の27を求めることができます。
また、元の[質問]を参照して、関連する内容を見つけることもできます。
これらのステップでは、除数が得られます。
そして、この3番目のステップでは、実際に商を得ることができます。
よろしいでしょうか。そしてこの3つのステップの後、実際に第2ステップの結果を再利用し、4番目のステップの結果を得ることができます。そして最後に、被除数が得られます。
つまり、ここでは単一の演算子や量を[生成]するのではなく、式全体を直接生成するのです。
これにより、プロセスがより正確になります。
そこで、私たちの演繹的な[システム]では、最初に[質問]で提示された数量と、いくつかの定数を初期状態としてスタートします。
式はe、i、j、o、pで表されます。
ここでは、q_iからq_jまでの演算子を実行しますが、そのような式は実際に指示されています。
逆方向を示すため、ここでは[単語]を使った引き算も行います。
これは[関係性の抽出]とよく[類似]しています。
形式的な演繹[システム]では、時間ステップtで、q_iとq_jのペアの間に演算子を適用すると、この新しい式が得られます。
それを次の状態に追加して、新しい数量とします。
これらのスライドは、現在の状態に式を追加し続けた場合の、状態の変化を視覚化したものです。
私たちの[モデル]の実装では、まず[BERTs]またはRobertasによる[事前訓練された言語][モデル]を使用し、[文章]を[エンコード]して、これらの数量的[表現]を取得します。
数量的[表現]が得られたら、[推論]を開始できます。
ここではq_1の例が確認できます。q_2をq_2で割った後にq_3を掛けた[表現]を取得します。
まず、q_1とq_2の単なる[連続]であるペア[表現]を取得し、次に、それを演算子でパラメータ化したフィードフォワードネットワークを適用します。
最後に、式[表現]q_1をq_2で割ったものが得られます。
しかし実際には、[推論]段階では、間違った式になることもあり得ます。
ここで考えられる式はすべて、演算子の[数]の3倍に等しくなります。
良い点は、この[検索]空間を制御するための制約を簡単に追加できることです。
たとえば、この式が許可されていない場合は、[検索]空間でこの式を削除すればいいのです。
2番目のステップでも同じことをしますが、唯一の違いは、量が1つ増えることです。
この量は[以前の]計算式から求められたものです。
最終的には、q_3 × q_4という式を得ることができます。
また、考えられるすべての式の[数]が[以前の]ステップとは異なっていることもわかります。
このような違いがあると、[ビームサーチ]を適用するのが困難になります。なぜなら、2つのステップ間の確率分布が不均衡になるからです。
したがって、この[訓練]手順は[シーケンス]から[シーケンス][モデル]の[訓練]に[類似]しており、各時間ステップでの損失を最適化することになります。
ここでは、このτを用いて、この[生成]プロセスを終了させるべきタイミングを表します。
従来の[シーケンス]から[シーケンス][モデル]ではこれが[語彙][数]であるのに対し、ここでは、空間が時間ステップごとに異なっているところが、[シーケンス]から[シーケンス]と違います。
また、事前[知識]からある種の制約を課すこともできます。
よく使われる[数学の単語問題]の[データセット]、[MAWPS]、Math23K、[MathQA]、[SVAMP]で実験を行いました。
ここでは、[以前の]ベストアプローチと[比較して]結果を手短にご紹介します。
最もパフォーマンスのよい変種はRoberta-DeductiveReasonerです。
実は[ビームサーチ]は使用していません。一方で、[以前の]アプローチはすべて[ビームサーチ]を使用しています。
よろしいでしょうか。最適なアプローチはツリーベースの[モデル]であることが多いです。
全体的に、私たちの推論モデルは、このツリーベースの[モデル]を大幅に上回るパフォーマンスを発揮することができます。
しかし、[MathQA]または[SVAMP]の絶対数はあまり高くないことがわかります。
そこで、[SVAMP]の結果をさらに調査しました。
この[データセット]は困難を伴うものとなっています。作成者が[自然言語処理][モデル]を混乱させるため、[手動で]無関係な[情報]や余分な数量を追加したためです。
私たちの[予測]では、中間値のいくつかが実際には負であることがわかります。
たとえば、これらの[質問]では、「ジェイクはいくつリンゴを持っているか」を尋ねています。
しかし、余分な[情報]があります。たとえば、写真が17枚少ないとか、スティーブンは8枚の写真を持っているなどの情報ですが、これらはまったく無関係です。
そこで、私たちの[モデル]はこのような[予測]を行い、負の値を生成します。
この2つの式のスコアは[類似]していることがわかります。
そこで、負の結果を取り除くことで、この[検索]空間を制限し、[答え]を正しくすることができます。
このような[制約]を設けることで、[モデル]によっては、大きな改善が見られることがわかりました。
たとえば、[BERT]では7ポイント改善し、Robertaベースの[モデル]では2ポイント改善しました。
より優れた[言語モデル]にはより優れた[言語理解]能力があるため、ここでの[数字]はRoberta[の]方が高く、[BERT][の]方が低くなります。
また、これらすべての[データセット]の背後にある困難を分析しようとしました。
ここでは、未使用の数量の[数字]は無関係な[情報]と見なすことができると仮定しています。
ここでは未使用の数量のサンプルの割合を示しています。[SVAMP][データセット]が最も大きな部分を占めています。
ここでは、全体のパフォーマンスも示します。
未使用の数量のないサンプル[の]パフォーマンスは全体的なパフォーマンスよりも高くなります。
しかし、未使用の数量のあるサンプルのパフォーマンスは、全体的なパフォーマンスよりもはるかに悪くなります。
[MAWPS][では]、テストケースがあまり多くないので、この部分は無視します。
最後に、[質問]変動の例を通して[解釈度]を示したいと思います。
ここで、[モデル]は最初のステップで間違った[予測]を行います。
この式は、こちらの[文章]と結びつけることができます。よろしいでしょうか。
この[文章]は[モデル]を誤った予測に導いている可能性があると考えられます。
更に35本を植えると、[モデル]はそれが加算演算子になるべきだと考えます。
[文章]を修正して、梨の木の[数]がリンゴの木の数よりも35本少ないというような表現にするのです。
つまり、[モデル]が正しく[予測]することできるように、より正確な[意味]を伝えるようにするのです。
したがって、この研究は、[解釈可能な]予測が、[モデル]の振る舞いを理解するうえで役立つことを示しています。
研究の結論は、第一に、私たちの[モデル]は極めて効率的だということです。
さらに、[解釈可能]な解答手順を示すこともできます。
また、パフォーマンスを向上させるのに役立つ[制約]として、事前の[知識]を簡単に組み込むことができます。
そして最後に、基礎となるメカニズムは、ネットワーク[問題]を解決する[タスク]だけでなく、段階的な[推論]を伴う他の[タスク]にも適用可能であるということです。
一方で、ある種の制約もあります。
[大規模な][数]の演算子または定数がある場合、メモリの消費量がかなり多くなることがあります。
2つ目は、すでに述べたように、異なる時間ステップ間で確率分布が不均衡であるため、[ビームサーチ]戦略を適用することも非常に困難であることです。
以上で発表を終わります。[質問]を受け付けます。ご清聴、ありがとうございました。
こんにちは。マーストリヒト大学のアントワーヌと申します。
新しい法律条文[取得][の為]の新しい[データセット]について、ジェリーとの共同研究を発表します。
法律に関する問題は、多くの人々の生活について回ります。
しかし、大多数の一般市民は、自分の権利や基本的な法的手続きに関する[知識]をほとんど持ちません。
その結果、多くの立場の弱い市民が、多額の費用を支払って法律の専門家から支援を受ける余裕がなく、保護を受けられず、最悪の場合には、搾取されるがままになっています。
研究はすべて、法律条文[の]効果的な[取得][システム]を開発することによって、人々と法律の間の断絶を埋めることを目的としています。
このような[システム]は、法律に不慣れな方[の為]に、専門的な法的支援サービスを無料で提供することができます。
この研究の主な成果についてお話しする前に、法律条文の[取得]に関わる[問題]について説明します。
たとえば、「守秘義務に違反したらどのようなリスクがあるのか」といった、法律に関するシンプルな[質問]を考えてみましょう。
このとき、[モデル]は、[大規模な]法律体系から関連する法律条文をすべて取得する必要があります。
この[情報取得][タスク]には、独特な課題がいくつか伴います。
第一に、2種類の[言語]を扱うことです。
つまり、[質問]に用いられる普通の[自然言語]と、法律に用いられる複雑な法律[言語]です。
この[言語][分布]の違いのため、[システム]とって関連候補を検索することが困難になります。なぜなら、[自然]な[質問]を法的な[質問]に翻訳して法律[用語]に一致させる、固有の解釈[システム]が間接的に必要になるからです。
さらに、法律は、[ニュース]やレシピなどとは異なり、それだけで[情報]の完全な[ソース]として扱うことができるような、独立した条文が集まったものではありません。
むしろ、全体的な[文脈]の中で考慮して初めて全体的な[意味]を持つ、法律条文の[構造的な]まとまりなのです。つまり、周囲の条文の補足[情報]、条文が属する分野や下位分野、法律[体系]における位置づけをすべて考慮する必要があるのです。
最後に、[取得]作業では多くの場合、短い段落が典型的な[取得]単位となりますが、法律条文は短い段落で構成されてはいません。
条文はときに、最大で6,000[単語]にいたる長い[文章]になります。
[自然言語処理]における[近年の進歩]により、法的判断の[予測]や契約書の自動レビューなど、多くの法的[タスク]での活用に強い関心が集まっています。
しかし、法律条項の[取得]は、[大規模]で高[品質]な[ラベル付き]の[データセット]がないため、ほとんど手つかずのままとなっています。
この研究では、[フランス語]ネイティブの市民を中心とした新しい[データセット]を提示し、法律条文の[取得][タスク][において]、[取得][モデル]が法律の専門家のような効率性と信頼性を実現できるかどうかを調査します。
今回利用したベルギーの法律条文[取得][データセット][BSARD]は、ベルギー市民から寄せられた1,100件以上の法的な[質問]から構成されています。
これらの[質問]のトピックは、家族、住居、お金、仕事、[社会]保障など、[広範囲]にわたっています。
経験豊富な法律家が、ベルギーの法典内の22,600以上の法律条文で構成された[コーパス]から関連する条文を参照し、それぞれの質問に[ラベル付け]を行いました。
それでは、この[データセット]をどのように収集したかについてお話ししましょう。
まず最初に、法律条文の[大規模な][コーパス]を編纂することから始めました。
公に利用可能な32のベルギーの法典を検討し、条文すべてと[対応する]見出しを[抽出]しました。
続いて、関連する法令を参照しながら、法律の[質問]を集めました。
そのために、ベルギーのとある法律事務所と提携しました。その事務所は毎年、法律に関わる個人的な問題[についての]助言を求めるベルギー市民から、約4,000通のメールを受け取っています。
とてもありがたいことに、同事務所のウェブサイトにアクセスできました。サイトでは、経験豊富な法律専門家のチームが、ベルギーで最も一般的な法的問題を扱っています。
私たちは、カテゴリー、サブカテゴリー、そして関連する法律への法的参照文献について[注釈がついた][質問]を数千件集めました。
最後に、私たちは法的な参照を確認し、検討した法典内の条文を参照していない[質問]を除外しました。
残りの参照文献は、私たちの[コーパス]で[対応する]条文IDに照合・変換されました。
最終的には、1,108件の[質問]が残りました。それぞれの質問には、22,633の条文で構成された[大規模な][コーパス]の関連する条文のIDが慎重に[ラベル付け]されました。
さらに、各[質問]には、メインカテゴリーとサブカテゴリーの[連続]が付属しています。
各条文には、法律[体系]における後続の見出しが[続いて]います。
この追加[情報]は今回の研究では使用しませんでしたが、法的[情報取得]または法的な[テキストの分類]に関する[研究][で]今後、役に立つかもしれません。
では、私たちの[データセット]の特徴をいくつか見てみましょう。
[質問]は5～44[単語]の長さからなり、中央値は14[単語]です。
条文はもっと長く、その長さの中央値は77[単語]で、142の条文が1,000[単語]を超えています。
最も長い条文は5,790[単語]にも及びます。
すでに述べたように、[質問]は[幅広い]トピックをカバーしており、家族、住居、お金、司法に関する質問が約85％を占めています。
残りの15％は、[社会]保障、外国人、仕事のいずれかに関係した質問です。
また、ベルギーの32種の法典に由来するため、条文は非常に多様で、[多くの][数]の法的トピックをカバーしています。
これらのベルギーの法典から収集した条文の合計[数]は次のとおりです。
22,633の条文のうち、わずかに1,612の条文だけが、[データセット]の[質問]の1つ以上に関連するものとして参照されています。
また、引用された条文の約80％は、民法典、司法法典、犯罪捜査法典、刑法典のいずれかに由来しています。
一方、32法典のうち18法典は、1つ以上の[質問]に関連すると言及された条文が5つ未満しかありませんでした。
これは、これらの法典が個人や個人に関わる事柄に重きを置いていないという事実から説明できます。
全体として、引用された条文[の]引用[回数]の中央値は2回で、6回以上引用された条文は25％未満でした。
すべての[データセット]を使い、[語彙的]および高密度アーキテクチャなどの[取得]アプローチをいくつかベンチマークしました。
[質問]と条文が与えられた場合、[語彙的]な[モデル]は、[質問]の用語と条文における各用語の[荷重]の和を計算することによって、[質問]と条文のペアにスコアを割り当てます。
標準的なTF-[IDF]とBM25の順位付け関数で実験を行いました。
これらのアプローチの主な[問題]は、[質問]に存在するキーワードが記載された条文だけしか取得できないことです。
この制約を克服するため、[質問]と条文の間の[意味論]的な関係をキャプチャできる、[ニューラル]ベースのアーキテクチャで実験します。
[質問]と条文を高密度の[ベクトル][表現]にマッピングするバイ[エンコーダ][モデル]を使い、[質問]と条文のペア間の関連性スコアは、それらの[埋込み]の[類似性]によって計算します。
これらの[埋込み]は、通常、[単語埋込み][モデル]の出力に対するプーリング操作から生じます。
まず、ゼロショット[評価]設定でのSiameseバイ[エンコーダ]の有効性を研究します。[すなわち]、[事前訓練された][単語埋込み][モデル]が追加の[微調整]なしでそのまま適用されます。
[文脈]に依存しない[テキスト][エンコーダ]、[すなわち][単語2vec]とfastText、そして[文脈]に依存する[埋込み][モデル]、[すなわち]Robertaと、特に[フランス語]のRoberta[モデル]である[CamemBERT]を使用して実験します。
[さらに]、[データセット]に基づいて独自の[CamemBERT]ベースの[モデル]、バイ[エンコーダ]を訓練します。
なお[訓練][の為]に、2種類のバイ[エンコーダ]アーキテクチャを試しています。
1つ目はSiameseで、[質問]と条文をともに[共有]された[ベクトル空間]にマップするユニークな[単語埋込み][モデル]を使用します。2つ目はTwo-Towerで、こちらは[単語埋込み][モデル]を使用して[質問]と条文を別々の[埋込み]空間に[エンコード]します。
平均値、最大値、[CLS]プーリングのほか、類似度計算[の為]の積や[コサイン]も試します。
テストセットのベースラインの結果は次のとおりです。
上は[語彙的][方法]、中央はゼロショット設定で評価したSiameseバイ[エンコーダ]、下は微調整したバイ[エンコーダ]です。
全体として、微調整されたバイ[エンコーダ]は、他のすべての[ベースライン]を大幅に上回ります。
Two-Tower[モデル]は、100％の再現率でSiameseモデルより向上しますが、他の[メトリックス]では似たような結果となっています。
BM25は訓練されたバイ[エンコーダ]を大幅に下回りましたが、そのパフォーマンスは、特有の[ドメイン]の[取得][には]強力なベースラインとなることを示しています。
Siameseバイ[エンコーダ]のゼロショット[評価]については、[情報取得][タスク]に対して最適化せずに[事前訓練された][CamemBERT][モデル]の[埋込み]を直接使用すると、結果が悪くなることがわかり、これは[以前の]調査結果と一致しています。
[さらに]、[単語2vec]ベースのバイ[エンコーダ]がfastTextと[BERT]ベースの[モデル]を大幅に上回っていることから、調整せずそのまま使用する場合、[タスク]レベルや[サブ単語]レベルの[埋め込み]よりも、[事前訓練された][単語]レベルの[埋込み]の方が適切である可能性が示唆されています。
この結果は有望ではありますが、熟練した法律専門家があらゆる[質問]に対して関連する条文すべてを取得し、完璧なスコアを得られることと[比較する]と、改善の余地が多く残されていることを示唆しています。
最後に、私たちの[データセット]の2つの限界について説明します。
第一に、条文の[コーパス]は、ベルギーの法典を考慮した32の法典から収集されたものに限定されており、判決、指令、条例の条文が欠落しているため、ベルギーの法律全体をカバーしているわけではありません。
[データセット]の構築中、収集対象外となったこれらの条文への参照はすべて無視されたため、[質問]によっては、関連する条文の[数]が不完全となりました。
したがって、この[情報]は、残りの関連条文に含まれている[応答]が不完全である可能性があることを意味します。ただし、それでも適切であることは間違いありません。
第二に、すべての法的な[質問]が法令だけで答えられるわけではないことに注意する必要があります。
たとえば、「賃借人が過度な騒音を立てたら、立ち退かせることはできるか」という[質問]を考えてみてください。
この場合、立ち退きが許される騒音レベル具体的に数値化した詳細な[応答]は、法令からは得られない可能性があります。
その代わり、家主はおそらく、判例に頼り、現在の状況に[類似]した前例を見つけるべきでしょう。
たとえば、賃借人が週に二回、午前二時までパーティーをするとします。
[よって]、[質問]によっては、他の質問よりも法律条文の[取得][タスク]に適しています。しかし、あまり適していない[ドメイン]については、今後見極める必要があります。
私たちの研究が関心を呼び起こし、実用的で信頼性のある法律条文[取得][モデル]が開発されるよう願っています。
モデルはすべての人[が]司法を利用しやすくなるのをサポートできるでしょう。
[論文]、[データセット]、法典は、次のリンクで確認できます。ご清聴、ありがとうございました。
こんにちは。私たちの研究、「[VALSE]：特定の[言語的]現象で視覚と[言語のモデル]をテストする[為の][タスク]に依存しないベンチマーク」についてお話しします。
このベンチマークを設定するのに苦労した理由を説明します。
ここ数年、[大量の][イメージ]と[テキスト]のペアで[事前訓練された][トランスフォーマー]ベースの視覚と[言語のモデル]が爆発的に増加しています。
これらの[モデル]はそれぞれ、[視覚的な質問への回答]、[視覚的]な共通[感覚]の[推論]、[イメージ][取得]、[フレーズ]の[教育付け]など、視覚と[言語]の[タスク]において、最先端のモデルです。
ところがあるとき、メッセージを受け取りました。「これらの[タスク]や特定のベンチマークは着実に向上しています。
しかし、[モデル]が実際に何を学習したのかをわかっているでしょうか？
この[イメージ]とこの[文章]を一致[させて]高いスコアを割り当てるとき、視覚と[言語]の[トランスフォーマー]は一体何を理解したのでしょうか？
これ[に]低いスコアを割り当てたときはどうでしょうか？
視覚と[言語のモデル]は正しい点に着目しているのでしょうか？
それとも、[以前の]研究で示されたような[バイアス]に着目しているのでしょうか？」、と。
この[側面]にもっと光を当てるために、私たちはより[タスク]にとらわれない方向性を[提案]し、[言語]と[視覚][様式]の両方に影響を与える特定の[言語的]現象に対する視覚と[言語のモデル]の感度をテストする[VALSE]を導入します。
存在、複数、カウント、[空間][関係]、行為、[実体][共参照]を[対象]にしています。
しかし、視覚と[言語のモデル]がこの現象を捉えたかどうかを検証するには、どうすればよいのでしょうか。
ラヴィ・シェカール氏と共同研究者が以前、[名詞]句のみに、視覚と[言語のモデル]に適用した[手法]と、私たちが[以前の]研究でカウントしたものをフォイリングすればよいのです。
フォイリングとは、基本的に[イメージ]のキャプションを取り、[イメージ]を説明しないようにキャプションを変更してフォイルを生成することを意味します。
存在、複数、カウント、[空間][関係]、行為、[実体][共参照]などの6つの特定部分に焦点を当てて、これらの[フレーズ]変更を行います。そのなかで、複数の興味深いフォイル・インスタンスの作成方法を見出すことができた場合、それぞれの部分が1つ以上の要素で構成されるようにしました。
たとえば、2つの要素がある行為部分の場合、1つは行為[動詞]が異なる行為に変えられ、もう1つは行為者が交換されます。
カウンティングと[共参照]は、複数の要素を持つ部分でもあります。
これらのフォイルは、[イメージ]を記述できないこと、[文法的]であること、有効な[文章]であることを確認しながら作っていきます。
フォイルされたキャプションは元のキャプションよりも可能性が低くなることがあるため、簡単な作業ではありません。
たとえば、不可能ではありませんが、植物[が]人を切る可能性は、人が植物を切るよりも統計的に低く、[大規模な]視覚と[言語のモデル]はこれに気づくかもしれません。
[したがって]、有効なフォイルを得るためには、アクションが必要です。
まず、強力な[言語モデル]を使用してフォイルを[提案]します。
第二に、[自然言語推論]または短い[NLI]を使用して、まだ[イメージ]を記述している可能性のあるフォイルを除外します。なぜなら、フォイルを構築するときには、[イメージ]を記述しないようにする必要があるからです。
これを[自動的に]テストするために、次のような理論的根拠で[自然言語推論]を適用します。
私たちは、[イメージ]を前提とし、そのキャプションを含意された仮定と見なします。
また、キャプションを前提とし、フォイルをその仮定とします。
[NLI][モデル]がフォイルのキャプションを矛盾する、もしくは中立であると予測した場合、これを有効なフォイルの指標とみなします。
[NLI]がフォイルがキャプションに含意されていると予測した場合、それは良いフォイルではありません。なぜなら、伝達性によって[イメージ]について正しい説明が与えられるためです。そのため、私たちはこれらのフォイルを除外します。
しかし、この手順は完璧ではなく、有効なフォイル[の]指標に過ぎません。
[したがって]、有効なフォイルを[生成]する[為の]三つ目の手段として、[VALSE]で使用されている[データ]を検証するために[人間の][注釈者]を採用します。
そして、フィルタリングと[人間による評価]の後、この表に見られる数だけテストインスタンスができます。
なお、[VALSE]は[訓練データ]を提供せず、テスト[データ]のみを提供しています。
これはゼロショットテストのベンチマークであるため、[事前訓練]後の[既存の]視覚と[言語のモデル]の機能を活用するように設計されています。
[微調整]を行っても、[モデル]が[データ]内のアーティファクトまたは[統計的][バイアス]を不正利用できるようになるだけです。
ご存じのように、このような[モデル]はズルや手っ取り早い手段を好みます。
そして、すでに述べたように、[事前訓練]後に視覚と[言語のモデル]がどのような能力を持つかを[評価]することが今回の着眼点です。
[VALSE]において、5つの視覚と[言語のモデル]を使って実験しています。[すなわち]、[CLIP]、[LXMert]、[ViLBERT]、[ViLBERT] 12-in-1、[VisualBERT]です。
最も重要な[評価][メトリックス]のうち2つは、[イメージ]と[文章]のペアを[キャプション]とフォイルに[分類]する際の[モデル]の精度です。
このビデオにとっておそらくより重要な、より寛容なメトリックスである[ペアワイズ]精度を紹介します。これは、[イメージ]と[文章の一致度]のスコアが、正しい[イメージ][テキスト]のペアのほうが、そのフォイルされたペアよりも大きいかどうかを測定するものです。
その他の[メトリックス]とその結果に[ついては]、私たちの[論文]をご一読ください。
ここに示されているのは[ペアワイズ]精度の結果です。他の[メトリックス]から得られた結果と一致しているのは、最高のゼロショット性能が[ViLBERT] 12-in-1によって達成され、[ViLBERT]、[LXMert]、[CLIP]、そして最後に[VisualBERT]がそれに続いているということです。
注目すべきは、存在や[名詞]句のような個々のオブジェクトを中心とした要素が、[ViLBERT] 12-in-oneによってほぼ解決されていることで、[モデル]が[名前付き]のオブジェクトと、そのオブジェクトがイメージ内にあるかどうかを[識別]できることが浮き彫りになっています。
しかし、残りの部分は、[敵対的]なフォイリング設定では、どれも信頼の置ける形で解くことができません。
複数の計数手段から、視覚と[言語のモデル]は、単一のオブジェクトと複数のオブジェクトを区別したり、[イメージ]内でそのようなオブジェクトを数えたりすることが困難であることがわかります。
[リレーション]部分から、[イメージ]内のオブジェクト間の[名前付き]の[空間][関係]を正しく[分類]することが困難であることが分かります。
また、行為部分に見られるように、妥当性[バイアス]によってサポートされていても、行為を区別して参加者を[識別]するのが困難であることがわかります。
[共参照]部分からは、[代名詞]を使用して[イメージ]内の同じオブジェクトへの複数参照を追跡することも、視覚と[言語のモデル]にとって困難であることがわかります。
健全性チェックのため、また、興味深い実験であるため、2つの[テキスト]のみの[モデル]、[GPT]-1、および[GPT]-2をベンチマークして、[VALSE]がこれらのユニモーダル[モデル]によって解決可能であるかどうかを評価します。これは、ここでは[イメージ]を計算せず、正しいキャプションとフォイルされたキャプションの[パープレキシティ]を計算し、最も低い[パープレキシティ]でエントリを予測することで行います。
[共参照]がフォイルより高い場合、フォイルされたキャプションが妥当性バイアスまたは他の[言語的][バイアス]の悪影響を受けている兆候とみなしました。
興味深いことに、場合によっては[テキスト]のみの[GPT][モデル]の方が、視覚と[言語のモデル]よりも世界の妥当性をよりよく捉えていることがわかりました。
つまり、まとめると、[VALSE]は、[言語]構造のレンズを使って、[視覚][グラウンディング]能力を厳しくテストし、コミュニティが視覚と[言語のモデル]を改善するのを支援するベンチマークだということです。
私たちの実験では、視覚と[言語のモデル]は、存在部分によって示されているように、[名前付き]のオブジェクトと、イメージ内にそのオブジェクトがあるかどうかをよく識別します。しかしながら、[言語的]メトリックスを考慮するよう強制されると、[視覚的]シーンの相互依存性と関係性をうまくグラウンディングできないことがわかります。
コミュニティの方々には、視覚と[言語のモデル]による[言語][グラウンディング]の進捗状況を測定する際には、[VALSE]を使用することを強くお勧めします。
さらに、[VALSE]は[データセット]を間接的に評価するためにも利用できます。なぜなら、[訓練]や[微調整]の前後に[モデル]を評価し、[VALSE]がテストする側面で[データセット]により[モデル]が改善されたかどうかを確認できるためです。
もし興味がありましたら、GitHubの[VALSE][データ]をご確認ください。[質問]がありましたら、お気軽にお問い合わせください。
こんにちは、東京大学の亀沢です。
「[RNSum]：コミットログ[要約]による[自動]リリースノート[生成][の為]の[大規模]スケール[データセット]」という[論文]についてお話しします。
この順番で説明します。
まず、この[研究]で取り組んでいる[自動]リリースノート[生成]についてご紹介します。
リリースノートとは、ソフトウェア製品のリリースごとに配布される、変更をまとめた技術的な[文章]です。
この[イメージ]は、vuejsライブラリのバージョン2.6.4[の]リリースノートを示しています。
リリースノートは[オープンソース]開発において重要な役割を果たします。しかし[手動で]準備するのには時間がかかります。
[したがって]、高[品質]のリリースノートを[自動的に]生成できると非常に便利です。
ここでは、リリースノート[自動][生成]に関して、2つの[先行]研究に従います。
ひとつは、2014年にリリースされた[システム]である、[ARENA]です。
このシステムではルールベースの[アプローチ]がとられており、たとえば変更点[エクストラクター]を用いてリリース間の差分から変更点、ライブラリの変更点、および[文章]の変更をすべて抽出し、最終的にそれらを組み合わせるなどしています。
この[システム]の最も大きな特徴は、右上隅の問題[エクストラクター]です。
これは、問題追跡[システム]であるJiraに依存しているため、Jiraを使用しているプロジェクトにしか適用できません。
言い換えれば、GitHub上の多くのプロジェクトでは使用できません。
2つ目はGlyphで、2020年に発表されたばかりのものです。
[インターネット]で公開されており、pip経由でインストールできます。
この[システム]には、単純な[学習]ベースの[テキスト分類][モデル]があり、各[入力]コミットメッセージに対して、[機能]やバグフィックスなどの5つのラベルから選んで、1つを[出力]します。
この[イメージ]は、修正またはバグ修正というラベルを返す使用例です。
Glyphの[訓練用データ]は5,000件程度とかなり少ないものですが、後述の実験でご紹介します。
[テキスト分類][モデル]の性能は高くありません。
私は2つの関連研究を紹介しますが、適用範囲が限られていることと、[データ][リソース]が少ないことがそれらの研究の問題点となっています。
私たちの[論文]ではこれら2つの問題を解決し、[自動的に]高[品質]のリリースノートを生成します。
適用範囲が限られているという[問題]があるため、コミットメッセージだけを[入力]として用い、高[品質]のクラス別の[要約][手法]を[提案]します。
この提案[手法]は、すべての[英語]リポジトリに使用できます。
[データ][リソース]が少ないという2番目の[問題]に[ついては]、GitHub [API]を使用してGitHubの公開リポジトリから[データ]を収集することにより、約8万2000個の[データ]からなる[RNSum][データセット]を構築しました。
次に、[データセット]について説明します。
これは[データ]の例です。
左側はコミットメッセージ、右側はリリースノートです。
リリースノートは、改善や修正などの[ラベルが付け]られています。
コミットメッセージを[入力]として受け取り、[ラベル付き]のリリースノートを[出力]する[タスク]を設定しました。
これは[要約][タスク]と見なすことができます。
[機能]、改善、バグ修正、非推奨の削除および重要な変更の4つのラベルを事前に定義しました。
これらのラベルは[以前の][研究]およびその他の要因に基づいて設定しました。
右下のリリースノートは、左下のリリースノートから[抽出]されたものです。
このとき、事前に設定した4つのラベルを検出する必要があります。
しかし、ラベルは必ずしも各リポジトリと一貫しているわけではありません。
たとえば、改善ラベルには、改善、強化、最適化などが含まれます。
これらの表記のバリエーション[の為]、約30個のラベルの[語彙]リストを用意しました。
これは、リリースノートクラスを検出し、そのクラスのリリースノート[文]として、その後に続くリリース[テキスト]を収集するものです。
次はコミットメッセージです。
コミットメッセージは各リリースに結びついていません。
下の[図]に示すように、現在のリリースがバージョン2.5から19の場合、[以前の]リリースバージョンである2.5から18を識別して差分を取得する必要があります。
これは少し面倒で、リリースのリストを取得して前後を見るだけでは不十分です。
そこで、[ヒューリスティック]マッチングルールを作成し、[以前の]バージョンと以降のバージョンを取得するようにしました。
[データセット][分析]です。
最終的には、7,200件のリポジトリと82,000件のデータが収集されました。
また、リリースノート[トークン]の平均[数]は63であり、これは[要約][タスク]としてはかなり大きな数字です。
また、一意な[トークン]の[数]は8,830,000個と非常に[大規模に]なっています。
これは、リポジトリに存在する一意なクラス名や[メソッド][名]の[数]が[大規模な]ためです。
次に、提案する[手法]について説明します。
クラス単位の[抽出]および[抽象的要約][モデル]は、2つの[ニューラル]モジュールで構成されています。
[BERT]または[CodeBERT]を使用した[分類器]と[BART]を使用したジェネレータです。
まず、[CEAS]は[分類器]を使用して、各コミットメッセージを改善、バグ修正、非推奨などの5つのリリースノートクラスに分類します。
その他として分類されたコミットメッセージは破棄されます。
その後、[CEAS]はジェネレータを4つの[ラベル付き][文章]に個別適用し、各クラスのリリースノートを生成します。
この[タスク]では、コミットメッセージとリリースノートの直接的な対応関係は不明となっています。
[したがって]、[分類器]を訓練するために、各コミットメッセージの最初の10文字を使用して、[入力]コミットメッセージごとにアンケートを再び割り当てました。
私たちは、2つの異なる[手法]によってクラス別[抽象的要約][アプローチ]をモデル化しました。
[CAS]-Singleと名づけた最初の[モデル]は、単一の6対6のネットワークで構成され、単一のリリースノート[テキスト]を生成し、[入力]コミットメッセージの[連結]を与えます。
出力される[テキスト]は、クラス固有の特別なエンドポイントシンボルに基づいてクラス別に分割することができます。
2番目の[手法]は、[CAS]-Multiと呼ばれ、4つの異なる[seq2seq]ネットワークで構成されており、それぞれが固定リリースノートクラスの1つに対応しています。
それでは、実験の説明をします。
5つの[手法]を[比較]しました。[CEAS]、[CAS]-Single、[CAS]-Multi、[クラスタリング]および[先行研究]のGlyphです。
[評価]については、場合によってはリリースノートが複数の[文章]で出力されることもあります。
[文章]の[数]をそのまま計算するのは難しいため、スペースで結合して1つの長い[文]として扱っています。
[システム]が短い[文章]を[出力]すると、[BLEU]にペナルティが科されます。
このペナルティにより、次に説明する実験結果では[BLEU]の値が低くなっています。
最後に、リリースノートが空の場合、[ROUGE]と[BLEU]を計算できないため、特異度も計算します。
リリースノートが空であると仮定した場合、特異度が高いほど、[モデル]が空の[テキスト]を正しく[出力]することを意味します。
結果は次のとおりです。
[データ]には電子メールアドレスやハッシュ値などが含まれているため、これらを除いたクリーンな[データセット]も評価しました。
[CEAS]および[CAS]は[ベースライン]よりも10ポイント以上高い[ROUGE]-Lのスコアを達成しました。
特にクリーンなテストセットでは、提案する[方法]と[ベースライン]のスコア差が20ポイント以上に跳ね上がりました。
これらの結果は、[CEAS]および[CAS]が著しい影響を受けることを示しています。
[CEAS]は、[CAS]よりも高い[ROUGE]-Lスコアを獲得しており、[擬似]ラベルを用いて[分類器]を[訓練]するには、[分類器]とジェネレータを組み合わせると有効であることが示唆されました。
[CEAS]の高いカバー率は、[分類器]が各クラスに関連するコミットメッセージを選択することに集中できるためと考えられます。
[CAS]-Multiは[CAS]-Singleよりも[ROUGE]-Lが高くなる傾向がありました。
つまり、リリースノートのクラスごと[に]異なる[抽象的要約][モデル]を個別に開発することも有効であることが示唆されています。
これはエラー[分析]です。
[CAS][手法]は、[人間の]参照[文章]よりも短い[文章]を出力する傾向があります。
右側の図では、参照された[文章]には3つまたは4つの[文]がある一方、[CAS]には1つしかありません。
この[モデル]が消極的である理由は、[訓練データ]では、[機能]ラベルでは33％しか[文章]がなく、改善ラベルでは40％にしか文章がないためです。
[さらに]、[CAS][手法]では、追加の[情報]がなければ正確なリリースノートを生成することはできません。
右上の例は非常に込み入ったコミットメッセージの例で、[対応する]進行状況や問題を参照しなければ、完全な[文章]を[生成]することはできません。
下の例は、[入力]にある2つのコミットメッセージが関連しており、1つの[文章]に結合すべきであるものの、そうなっていないことを示しています。
最後に、結論です。
リリースノートの[自動][生成][の為]の新しい[データセット]を構築しました。
また、コミットメッセージを入力とその[要約]という[タスク]を定式化し、[英語]で[書かれた]あらゆるプロジェクトに適用できるようにしました。
私たちの実験で提案した[方法]は、[ベースライン]よりも高いカバレッジで、ノイズの少ないリリースノートを生成することが示されました。
GitHubの[データセット]をご確認ください。
ご清聴、ありがとうございました。
こんにちは。アサフ・ハラリと申します。
私たちの[論文]、「微調整した[トランスフォーマー][アーキテクチャ]を用いたFew-shot表形式[データ]強化」を発表します。
[データ]サイエンティストは[データ]を分析し、[データ]の[既存の][機能]を操作することに、主に注力しています。
しかし、それらの[機能]に制限があることもあります。
別の[データ][ソース]を用いて特徴を[生成]することで、実質的な[情報]を追加できる可能性があります。
私たちの[研究]目標は、外部ソースのフリー[テキスト]を使用して[自動]で表形式[データ]を強化することです。
表形式の[データセット]と[知識ベース]があると仮定します。
[知識ベース]のフリー[テキスト]から新しい[機能]を抽出するためには、[エンティティのリンク]と[テキスト][分析]などの[自動]プロセスが必要です。
私たちのフレームワーク[FeSTE]はまさにこの[自動化]プロセスです。
[FeSTE]にフィードされた[データセット]の例を見てみましょう。
この例では、[データセット]は大学[データセット]です。
ランキングの低い大学とランキングの高い大学に分類することを目的とした場合。
[知識ベース]として、[wikipedia]を使用します。
[FeSTE]の最初のフェーズは[エンティティのリンク]です。
各[エンティティ]が[知識ベース]内の[エンティティ]に[リンクされ]ている場合です。この例では大学名が[リンク]されています。
[知識ベース]の[エンティティ]の[テキスト]が[抽出]され、[データセット]に追加されます。
この例では、[テキスト]は[wikipedia]ページの要約です。
次に、[回収された][テキスト]から[機能]を生成または抽出する必要があります。
そのため、[テキスト][分析]を含む特徴[抽出]フェーズが必要になります。
これこそがこの[論文]が新しい部分であり、次のスライドで詳しく説明します。
特徴[抽出]フェーズの後には、特徴[生成]フェーズがあり、[抽出された][機能]を使用して少数の新しい[機能]を生成します。
まず、元の[データセット]のクラス数だけ[機能]を生成します。
この例では、元の[データセット]には2つのクラスがあります。
[FeSTE]は2つの新しい[機能]を生成します。
しかし、[データセット]に5つのクラスがある場合、[FeSTE]は5つの新しい[機能]を生成します。
各特徴は、各クラスの尤度を表しています。
[テキスト]を分析するために、現時点で最先端の[テキスト][分析]である[BERT]、[GPT]、[XLNet]などの[トランスフォーマー]ベースの[言語モデル]を使用します。
しかし、[入力][データセット]を使用して[言語モデル]を訓練できる可能性は低いです。
そこで、[ターゲット][タスク][微調整]がシンプルな[アプローチ]となります。
したがって、特徴[抽出]フェーズでは、[事前学習済み言語][モデル]をダウンロードし、[ターゲット][データセット]上で[言語モデル]を微調整できます。
この例では、[言語モデル]を微調整し、[テキスト]をクラスに分類し、抽象度を低または高のクラスに分類します。
各クラス[の]尤度である[言語モデル]出力を受け取り、新しい[機能]として使用します。
この[アプローチ]の[問題]は、[データセット]に明確な[エンティティ]や[テキスト]がほとんどない可能性があることです。
私たちの実験では、約半数の[データセット]に含まれるサンプル数が400件未満で、最小の[データセット]では[訓練]セットに含まれるサンプルは35件でした。
したがって、[言語モデル]を微調整するには、この[データセット]は効果的ではありません。
しかし、事前に分析された[データセット]については、事前[知識]を活用できます。
複数の[データセット]に対して[FeSTE]を適用するため、nマイナス1の[データセット]を使用してnマイナス1の[データセット]に関する[情報]を収集し、n番目の[データセット]を分析するときにこの[情報]を使用できます。
私たちが提案するのは、[微調整]フェーズをもう1つ追加することです。
予備的な[マルチタスク][微調整]フェーズです。
nマイナス1の[データセット]上で[言語モデル]を微調整する場合。
そして、n番目の[ターゲット][データセット]で[言語モデル]を微調整する際に、もう1つの[微調整]フェーズ、つまり[ターゲット][タスク][微調整]を実行します。
[MTDNN]と呼ばれる最先端の[マルチタスク][微調整]です。
[MTDNN]では、[MTDNN]は[訓練]セットの[タスク][数]のヘッドを維持します。
この例では、[訓練]セットに4つの[タスク]があるので、[MTDNN]は[イメージ]に見られるように4つのヘッドを維持しています。
そして、[訓練]セットからランダムなバッチをサンプリングします。
そして、そのランダムバッチが、たとえば単一の[文章の分類][タスク]に属する場合、最初のヘッドを通るフォワードパスとバックワードパスが実行されます。
ランダムバッチが[ペアワイズ]ランキング[タスク]に属する場合、最後のヘッドを通るフォワードパスとバックワードパスが実行されます。
私たちのシナリオでは、表形式の[データセット]はクラスの[数]が異なります。
そのため、多くの[タスク]があります。
[MTDNN]は、クラス、ヘッド、出力層の[数]を維持しました。
そして[さらに][MTDNN]は、新しい[タスク]を持つ新しい[データセット][の為]に新しいヘッドを初期化する必要があります。
私たちの[アプローチ]は、[タスク]再構築[微調整]と呼ばれ、私たちの[アプローチ]である[タスク]再構築[微調整]では、複数ヘッドを維持するのではなく、[分類][問題]ごとに各[データセット]を[文章]に再構築します。これは2つのクラスの[タスク]です。
例を見てみましょう。
これは、[エンティティ]、[機能]、[テキスト]、およびクラスで構成される[入力][データセット]です。
そして、[テキスト]を低または高に[分類]する[タスク]を再構築し、[テキスト]、抽象度およびクラスを新または偽に分類するタスクとします。
また[言い換えれば]、[言語モデル]を訓練し、抽象度とクラスを、抽象度とクラスに、その抽象度がそのクラスに属すか否かを分類するようにしたのです。
この場合、ラベルの[ベクトル]は常に2つのクラスで構成されます。
これは、再構築した[微調整][アプローチ][の為]の[アルゴリズム]です。
それでは、フレームワークの全体像を見てみましょう。
[データセット]が[FeSTE]にフィードされました。
その後、[FeSTE]は[エンティティのリンク]フェーズを実行します。
[知識ベース]から[テキスト]が抽出されます。この例では[wikipedia]ページの要約です。
それから[タスク]を[ペアの][文章の分類][タスク]として再構築します。
新しい[タスク]と各クラスの出力尤度に[言語モデル]を適用しました。
そして、[言語モデル]は既に予備の[マルチタスク][微調整]を使用してnマイナス1個の[データセット]で微調整されています。
次に、[言語モデル]の出力[ベクトル]を、クラスの[数]だけ新たに[生成された]特徴として使用します。
フレームワークを評価するために、17個の表形式の[分類][データセット]を使用しています。これらは、サイズ、[機能]、バランス、[ドメイン]、および初期パフォーマンスが異なります。
[知識ベース]として[wikipedia]を使用しています。
[FeSTe]を16個の[データセット]に対して訓練し、17個目の[データセット]に適用するという、1つ抜きでの[評価]として実験を設計しました。
また、各[データセット]を4つのフォールドに分割し、4分割フォールド交差検証を適用します。
次に、新しい[機能]を生成し、5つの[評価][分類器]を使用して評価します。
実験には、[BERT]ベースアーキテクチャを使用しています。
実験[の]結果は次のとおりです。
フレームワークを[ターゲット][データセット]の[微調整]、[ターゲット][タスク]の[微調整]、[MTDNN]予備の[微調整]と比較していることがおわかりいただけると思います。
再構築された[微調整]が、最高の結果とパフォーマンスを[達成する]ことができました。
[MTDNN]は、[ターゲット][データセット]の[微調整]に対して2％の改善を達成している一方で、
私たちの[アプローチ]は6％の改善を達成しました。
小さな[データセット]を見ると、[MTDNN]のパフォーマンスが低下し、予備的な[マルチタスク][微調整]フェーズが1.5％に減少することがわかります。
しかし、私たちのパフォーマンスは[ターゲット][タスク][微調整]と単独で[比較して]、11％に増加しました。
まとめる[と]、私たちの実験で[FeSTE]は35個のサンプルから少量のショットに濃縮することができます。
また、1つのアーキテクチャ[で]すべての[タスク]と[データセット]を扱えます。
そして、[モデル]のヘッドを維持します。
しかし、再構築フェーズが追加されます。
訓練セットを増やし、[意味論]的[意味]を持つ[ターゲット]値を必要とするので、それを[言語モデル]にフィードし、[文章ペア][分類][問題]に利用することができます。
ご清聴、ありがとうございました。