2024-05-23 機械学習勉強会
今週のTOPIC[blog] 日本語テキスト埋め込みベンチマークJMTEBの構築Ramp AI agentデータ品質をコード化! LINEヤフーのMLOpsを最適化する "ACP Data Quality" の紹介[リポジトリ] Neovimでcopilot chatやってみた[論文] Beyond Layout Embedding: Layout Attention with Gaussian Biases for Structured Document Understanding[書籍] 機械学習システムデザイン 9章 実現場での継続学習とテストメインTOPICRethinking Search: Making Domain Experts out of Dilettantesサマリーイントロ関連研究Document RetrievalQuestion AnsweringExplicit Knowledge BasesModel-Based Information Retrieval提案手法:Model-Based Information Retrieval既存のLMsを超えたコーパスモデルMulti-Task LearningZero- and Few-Shot LearningResponse GenerationReasoning CapabilitiesArithmetic, Logical, Temporal, and Geographical ReasoningCombining Modalities in a Single Model Leveraging Document and Corpus StructureScaling to Multiple LanguagesOn the Challenges of ScaleIncremental LearningModel Interpretability, Controllability, and Robustness
今週のTOPIC
※ [論文] [blog] など何に関するTOPICなのかパッと見で分かるようにしましょう。
出典を埋め込みURLにしましょう。
@Naoto Shimakoshi
[blog] 日本語テキスト埋め込みベンチマークJMTEBの構築
- SBIの方が6タスク・16データセットで構成されるベンチマークをHuggng Faceで公開。
- 評価のためのコードも公開
- 例えば、クラスタリングだと、、、などを使っているみたい
- ‣
- OSSの中では、検索だと が強く、日本語だけで学習されたモデルの中では が強い
- OpenAIのは全体的にかなり高い性能
- 正規化してコサイン類似度を計算するか、正規化せず単純に内積を取るか、をJMTEBを用いて比較していてClassificationとRetrievalでは明らかに正規化しないほうがいいと結果になっていて面白かった。
- スライドもいい資料でした
@Tomoaki Kitaoka
Ramp AI agent
データ品質をコード化! LINEヤフーのMLOpsを最適化する "ACP Data Quality" の紹介
- データ品質モデルを定義する言語DQMLを開発
- コードで管理し、CICDでデプロイ
- 効果
@Yuta Kamikawa
[リポジトリ] Neovimでcopilot chatやってみた
- 今までneovimでcopilot使う時はコードの提案だけしてもらっていた
- vscodeやIDEみたいにcopilotとchatしながらコーディングしたいと思っていたところよさそうなプラグインを見つけた
- できること
- チャット形式でバッファに開いているコードのレビューやバグの修正など
- できないこと
- cursorエディタのCodebase Answersみたいにプロジェクト全体を参照したチャット
@Shun Ito
[論文] Beyond Layout Embedding: Layout Attention with Gaussian Biases for Structured Document Understanding
- EMNLP2023
- SDU: Structured document understanding
- スキャンした文書やデジタル文書からレイアウト構造やコンテンツを抽出する
- attentionに文書上の位置的な情報を加えたい
- 提案手法 Layout Attention with Gaussian Biases (LAGaBi) では、代わりに極座標による位置関係をattentionのquery-keyスコアに加える
- “report” をqueryとする と、”report” を中心としてトークンの位置関係を極座標で計算し、距離と角度からガウス分布の値を計算 → query=reportのquery-keyスコアに加えてsoftmax計算
- 単に足し算するのではなく、1を引いて重みを掛け合わせた値を足す
- ガウス分布の平均・分散は学習する
- 実験結果
- 関係なさそうな位置にある文字列はスコアが低くなるような重みになっている
@Ryosuke Fukazawa
[書籍] 機械学習システムデザイン 9章 実現場での継続学習とテスト
- 継続学習
- 継続学習というと実運用している環境にサンプルが入力されるたびにモデルを自動更新するということを思い浮かべる人は多いが、実際にそういったことがされているのは稀
- そうなるのは、以下の二つの理由がある
- ニューラルネットワークのモデルではサンプルが入力されるたびに学習すると破局的忘却(catastrophic forgetting)の影響を受けやすくなる
- 訓練が高コストになってしまう
- 実際にはモデルの更新はマイクロバッチにて行われる
- モデル更新のイメージ
- ステートレス学習とステートフル学習
- 継続学習の課題
- 鮮度の高いデータへのアクセスの難しさ
- データウェアハウスからのデータ取得の速度 -> KafkaやKnesisなどのリアルタイム伝送路によって解決
- 各種イベントをつなぎ合わせて作る必要のある天然のラベルの入手の難しさ -> バッチ処理を頑張って作り込んでもいいが、リアルタイム伝送路でラベリングを行えないか工夫を考える
- 人手によるラベル付けがボトルネック -> ラベル付けツールやクラウドソーシングを利用する(今はLLMによってこれを行うという選択肢が増えましたね!)
- 評価の課題
- 頻繁なモデル更新ではその分失敗する機会も増す。モデルが組織的な攻撃や敵対的な攻撃の影響を受けやすくなる
- 対象とするタスクの性質によって、妥当なオンライン評価を下すだけの時間をおく必要がある
- 継続学習の4つのステージ
- ステージ1: 手作業、ステートレス再学習
- 必要に迫れられて頑張ってなんとかするステージ
- ステージ2: 再訓練の自動化
- システムの再訓練プロセスを自動化するスクリプトを作成するステージ
- このステージに到達するための要件:
- このステージの実現可能性は、ワークフローを自動化するスクリプトを書くことができるかどうか、そして、自動化のインフラを構築できるかどうか。スクリプト作成者の力量によるところも大きいが、スケジューラー、データ、モデルストアの3つの要素がこの実現性に大きな影響を与えるのが一般的。
- ステージ3: 自動化、ステートフル学習
- 毎回0からステートレス再学習を行うのは高コスト。頻繁に再学習をするのであれば尚更。それを解決するために前回のチェックポイントから学習を継続できるよう自動更新スクリプトを設定し直すステージ
- このステージに到達するための要件:
- データとモデルのリネージを追跡できるようにすること
- ステージ4: 継続学習
- 固定のスケジュールに依存するのではなく、データ分布がシフトして行くことに向き合うステージ。究極的にはエッジ学習を使うことになる
- このステージに到達するための要件:
- モデルの更新をトリガーする仕組み(パフォーマンス低下やラベル付きデータの総量変化、データ分布の大きなシフトなど)
- 実環境でのテスト
- オフラインでは
- データをテスト用に分割したものを使用してモデルをオフライン評価する古きよき手法
- 過去の特定の期間のデータで予測モデルをテストする手法であるバックテスト
- バックテストを行う際でも、静的なデータセットを用いてモデルを評価することも大事。サニティチェックの一種として
- オンラインでは以下のようなアプローチが挙げられる
- シャドウデプロイ
- A/Bテスト
- カナリアリリース
- インターリービング試験
- バンディット
現行のモデルの更新は後回しになります。現行のモデルを更新するのは次の2つの条件を満たしたときのみです。ひとつは、モデルのパフォーマンスが低下し、恩恵よりも害のほうが目立つようになってしまった場合、もうひとつは、チームにモデルを更新できるだけの余裕がある場合です。モデルは半年ごとに更新されることもあれば、四半期ごとに更新されることもあれば、中には1年も手つかずで放置されていることもあります。
メインTOPIC
Rethinking Search: Making Domain Experts out of Dilettantes
サマリー
- 2021年時点においてLLMなどの技術の進化を受け、従来のindexベースの情報検索の形から脱却し、事前学習済み大規模言語モデルと組み合わせたモデルベースの情報検索への進化の必要性を説いているオピニオンペーパー
- 情報検索に関して様々な観点での議論がなされていてシンプルに面白いのでピックアップ
イントロ
- 従来の情報検索システムは、ユーザーのクエリに対して、コーパス内からひとつまたは複数の関連性の高い文書を提示することに主眼が置かれている。
- 特定のホームページを探したり、ECサイト内でアイテムを探すなどの場面ではこのアプローチが適切であると考えられる。
- 一方、ユーザーが抱いている疑問を解消してくれるような情報を、それも人間の専門家 “expert” が答えてくれるようなものを求めているという場面では最適とは言えない。検索システムはその情報ニーズに直接応えるのではなく、その情報ニーズを満たしうるコンテンツへのリファレンスを提供するのみである。
- このパラダイムでは、ユーザーは検索システムから提示された複数の文書の中から必要な情報を探し出す必要があり、大きな認知負荷がかかる。質問応答システムはこのような背景から研究開発が進んだ。
- 質問応答システムは、ユーザーの質問に対して(そのドメインに詳しい)人間が直接答えているかのような回答を行うことを目的としている。
- 一方、従来の検索システムのように関連文書のリストであったり、文書のスニペット、人間によって作成された回答(QAシステムのコンテンツなど)を返すものがほとんどである。
- これらは従来の検索システムよりも良い体験を提供する可能性がありつつも、カバレッジが限定的であったり、回答の権威性(信頼性や質)が担保されていなかったりと、課題が残されている。
- 近年の大規模言語モデルは高度な言語生成能力を備えており、ユーザーの情報ニーズを直接満たすような回答を生成することができる可能性を有している。
- 一方、あくまで世の中のことを完全に”理解”しているわけではなく、浅い回答をしているだけである。hallucinationも起こしうる。学習したコーパスの中から根拠を示すことも難しい。
- 📝 “dilettantes” という単語が、”expert” の対比として使われていて面白かった。〔芸術や学問の〕素人愛好家 、好事家、うわべだけの知識や技量しか持たない人を指す言葉とのこと。
- 📝 根拠を示す部分は最近ではだいぶ進化していますね。
- 本論文ではこれらの課題を解決するため、従来の情報検索システムと大規模言語モデルのそれぞれの長所を統合し、モデルベースの情報検索システムを構築することを提案している。
- 人間の専門家のように真にそのドメインを”理解”することは難しく、いわゆるAIの領域であるがそこはスコープに入れない。
- ドメインを理解しいているかどうかにかかわらず、ドメインの専門家と同等の回答を生成することができるシステムを目指す。
- そのために、従来の情報検索の大前提とっている、まずはコーパス内でindexを作成し、与えられたクエリから候補となるドキュメント集合を検索し、ドキュメントごとに関連度を計算するという”index-retrieve-then-rank paradigm”が絶対に必要なのかという点に
関連研究
Document Retrieval
機械学習を活用した3つの重要なトピックに言及。
- learning to rank
- 大規模なユーザーの行動データを活用し、より関連性の高い文書を上位に順位付けする。
- neural-based re-ranking
- ニューラルネットワークを用いて文書のスコアリングを行う手法であり、様々なモデルが提案されている。
- representation learning
- クエリや文書の意味を捉えているような分散表現を学習することで、語彙のミスマッチ問題を軽減することを目的としている。
Question Answering
retrieval-based、extractive、generativeなアプローチが存在する。
- retrieval-based
- 質問に関連する文書を検索し、その中から回答を選択する方法。シンプルに質問と文書の関連度を計算する。
- short text matching、paraphrase identification(言い換え表現識別)、entailment detection(含意検出)などが関連技術領域
- extractive
- 質問と文書の関連度を計算するのではく、文書中から回答らしい部分を抽出する方法。
- 結局、抜き出す対象の文章をコーパス内から検索する必要があるため、検索とQAは切っても切れない。
- generative
- 言語モデルを用いて回答を生成する方法。
- 上述の2つのアプローチはコーパス内に正解があることが仮定されていたが、本アプローチはそれに限られない。
Explicit Knowledge Bases
- 構造化された知識を表現するのに適しており、質問応答システムに活用されてきた。
- 実体(entity)の組と、その関係性・述語(predicate)のtripletで表現される。 e.g. (エジソン、電球、発明した)
- 実体をnode, 述語をedgeとしたグラフを生成。元々手作業でめっちゃ頑張っていたが、Webデータから自動で構成する研究も多々。
- 一方、ナレッジベースのカバレッジは限定的であり、ウェブ上の膨大な情報を全て取り込むことは困難である。
- また、ファクトに沿った回答しかできないので、ニュアンスのこもったええ感じの回答をすることはできない。
Model-Based Information Retrieval
- BERTやGPT-3に代表されるように、大規模なテキストデータを用いて事前学習することで、高度な言語生成能力を獲得している。
- 一方、これらのモデルは世界に関する真の理解ができているわけではなく、生成した内容の根拠を示すことができないという課題を有する。
提案手法:Model-Based Information Retrieval
- 従来の検索システム(index-retrieve-then-rank paradigm)の前提を疑い、以下の問いを提示する形で新しい検索システムを考える。
- index という概念を完全に取り除き、コーパスに含まれるすべての情報を効率的・効果的にエンコードする事前学習済みモデルに置き換えられないであろうか?
- 検索とランキング(retrieval and ranking)を区別せず、単一の生成応答に置き換えたらどうなるか?
- 本論文で提案されるモデルベースの情報検索システム(のパラダイム)では、indexはモデルの学習に置き換えられ、retrieveとrankはモデルの推論に置き換えられる。(fig.1)
- 従来の検索システムでも機械学習モデルが使われているが、あくまでindex, retrieve. rankの一部を置き換えているにすぎない。たとえば query understandingやdocument understanding、retrieval、rank用のモデルがそれぞれ存在する。
- 今回提案されている考えでは、すべてが完全にひとつのmodelに置き換えられるというイメージ
- 📝ちなみに提案しているのはこのパラダイム・枠組みのことで、具体的な手法の提案や実験・評価を行っているわけではない。
既存のLMsを超えたコーパスモデル
- 従来のLMsは大変有用ではるが、単語や文と文書の関係性を理解できない。
- ある文書中の “The sky is blue.”という文章単体を正確に理解することはできても、文書との関係性を理解することはできない。(だから “dilettantes” だと)
- 提案するモデル、コーパスモデル(corpus models)は、単語間、文書間、単語-文書間の関係をすべて学習させる。
- 単語(列)を入力として、単語(列)はもちろん、文書も出力できる。単語と文書を入力として、単語や文書を出力できる。
- この性質により、従来の情報検索におけるindexがなくとも “naitively”にドキュメントを検索(およびスコアリング)することができる。
- アイデアベースで手法のちら紹介
- 文書内に文書を表す特殊トークンを挿入する。「<Doc1> This is a sample document. </Doc1>」みたいな。
- 📝それでうまくいくんかいなとは思う。ただ、最近は直接文書IDを生成するようにLMを学習させるみたいなんもあったので、そのうちうまくいくのかな。
- コーパスの文書は超巨大なのでパラメタ数大丈夫なのかという問題や、動的にコーパスが変わる場合の再学習のコストが懸念される。
ここからは、モデルベースパラダイムを実現させるための技術的なトピックがいくつか挙げられる
Multi-Task Learning
- ひとつのモデルで完結させるためには、ひとつのモデルで検索システムに求められる複数のタスクを解く必要がある。
- 入出力にタスクを表すような識別子を入れ込んで学習することで実現しよう、とT5を例に挙げながら簡単に説明
- “docs”という識別子も含まれていることに注目。
Zero- and Few-Shot Learning
- 実際には大規模なデータで学習するの難しいので、zero- or few-shotの枠組みは大切。また、情報検索の複数のタスクはこれらの枠組みに落とし込める。
- アドホック検索はzero-shot、適合性フィードバックはfew-shot。
- 適合性フィードバックが、ユーザーがクエリに対して適合するドキュメントを数例渡してくれるので、それをコンテキストに入れて推論する形であると考えられる。
- 他にも query understandingやdocument understandingも。
Response Generation
- 回答を生成するので、よりユーザーの情報欲求に対して直接的に答えることができる。
- 左が従来の検索システム(ドキュメントのリストを返す)、真ん中が従来のLM(リファレンスがない)、右が提案するコーパスモデル(リファレンスがある)の出力イメージ
- 📝再度のコメントだが、現在はわりとうまくいくケースが増えていますね。
- ドキュメントとの関係を学んだコーパスモデルを作るのではなく、従来のLMと引用タスクを解くモデルを作る方法もあるよねと言及している。
- 📝RAG的な考え方ですかね。ここでは引っ張ってきた文書をもとに回答を生成するのではなく、生成した回答をもとに引用先をみつけにいくみたいな表現がされているように読めるが。
- 回答生成には他にも様々な課題が存在
- 権威性:生成のもととなった文書が信じられるものなのか。
- 透明性:提示された情報の出所をユーザーに公開可能か。
- バイアス:学習データに存在するバイアスをどう扱うか。
- 多様性:質問されたトピックを様々な観点から吟味し回答できるか。
- アクセシビリティ:ユーザーにとって理解しやすい言葉で記載されているか。
Reasoning Capabilities
- 推論能力はモデルのアーキテクチャの工夫などでもいくらでも伸ばせるよねという話。
- ただ、hallucinationには気をつけようねという話。
Arithmetic, Logical, Temporal, and Geographical Reasoning
- 検索エンジンは、ある種の算術計算を扱える。
- シンプルな四則演算はもちろん、ドルからポンドへの通貨の換算やニューヨークからカリフォルニアまでの距離を問うようなものまで。
- 秩序、時間、論理、地理的情報まで求められている。これは難しい。
Combining Modalities in a Single Model
- ドキュメントには様々なメタデータや画像、動画、音声などの形式のメディアコンテンツが含まれる。
- 従来はたとえば画像検索とドキュメント検索は異なるインデックスがなされていたが、これをひとつのモデルで統合して解決できる可能性。
Leveraging Document and Corpus Structure
- ドキュメントには意味のある構造があり、従来の情報検索では活用されている。
- たとえばタイトルやアンカーテキストに登場している単語はそのWebページにとって重要であるとWeb検索時には解釈される。
- 既存のLMはこのような文書の構造を十分に理解し活かしきれていない。
- Webが分かりやすいが、文書ごとに権威性や信頼性は異なる。また、グラフ構造も存在する。
- 従来のWeb検索での活用方法としてはPageRankなどが有名。
- 既存のLMはこれらを活かしきれていない。
- 📝この辺は確かになぁと思った。面白い。
Scaling to Multiple Languages
- 複数の言語をひとつのモデルで扱えるかどうかは課題
On the Challenges of Scale
- モデルサイズや入力文書のコンテキスト長など様々な観点でのスケーラビリティが課題となる。
Incremental Learning
- コーパスは動的なものであり、増えることもあれば減ることもある。
- 毎回すべて学習しなおすことは現実的でなく、オンライン学習やインクリメンタル学習で解決したい。
- 過去の知識を忘れないように新しい知識を学ばせることや、忘れたい知識を正しく忘れさせられるようにする必要がある。
Model Interpretability, Controllability, and Robustness
- 従来の検索システムは動作のメカニズムの透明性が高く、特定のクエリに対する挙動が予測可能であり、テスト・デバッグもしやすい。
- 一方でNN使ったシステムは解釈可能性の課題があり、何か問題があったとしてもモデルを制御して修正するのが困難。
- また、クエリに対するロバスト性も重要な課題。たとえばユーザーが”the”を”teh”とタイポした際に、大きく挙動を変えたくない。
- このようなユーザーの悪意ではなく不運で生まれるものも含む、見慣れないクエリに対する挙動は課題。