A Survey of Large Language Models

なぜこの論文を紹介するか

下記理由から本論文をピックアップした

  • 案件でLLMを利用したいとの要望を受け、最近のLLMの流れをおさらいしておきたいと思ったため

論文の内容

導入:Introduction

Pre-trained Model (PLM)のサーベイは十分な量があるが、LLMのサーベイは多くないため、本論文を執筆した

LLMは以下の3点でPLMと異なる

  • LLMはそれまでの小規模PLMでは解けなかったタスクを解けるようになっている
  • LLMはAI開発/利用の方向性を変える
    • LLMではプロンプト経由での開発/利用する
    • 人はLLMの挙動を理解し、LLMが理解できる形式にタスクを変換する必要がある
  • LLMの開発は研究とエンジニアリングの境界を曖昧にする
    • LLMの開発には大規模なデータ処理や分散処理のスキルが必要になるため、研究者はエンジニアと一緒に仕事をするか、エンジニアリングスキルを身につける必要がある

ChatGPTとGPT-4の登場により、汎用人工知能Artificial General Inteligence(AGI)の実現の可能性が出てきた。(GPT-4等のLLMを初期のAGIと位置付ける論文もある。)下記はGPT-4を開発したOpenAIのAGI開発のロードマップである。

openai.com

LLMの急激な発展により、下記のような変化が起きている

  • 自然言語処理(NLP)の分野の研究はLLMが汎用的なタスクソルバーとして考え、LLMをどう利用するかという方向にシフトしてきている
  • 情報検索(IR)の分野では、既存のサーチエンジンをAIチャットボットベースの検索で置き換える試みが進んでいる(New Bingなど)
  • Computer Vision(CV)の分野ではChatGPTのような視覚-言語情報のマルチモーダルモデルの研究が進んでいる。(GPT-4はすでにマルチモーダル)

これらのLLMによりもたらされる現実世界のアプリケーション開発環境にもたらされる変化はMicrosoftOfficeのCopilot機能のような形で、よりよい形で影響を与え始めている

これらの進展と影響とは裏腹にLLM自体は下記のような点で問題がある

  • PLMが解けない周辺タスクをLLMがなぜ、どのようにして解けるようになったかは明らかになっていない
  • アカデミアで十分な性能を発揮するLLMを学習することは、LLMに要求される膨大な計算資源の観点から難しい(そのため上記の原因究明も難しい)
  • 人に害を与えるような偽情報等を出力しないように、人の価値観等をモデルに反映するのが難しい

まだまだ課題はあるものの、LLMの研究/開発のためにはもっと人々からの興味関心を惹く必要がある。そこで、本論文ではLLMへの基礎的な理解を促すために下記の観点から論文のレビューを実施した。

  • Pre-training:優秀なLLMを作るためにどう事前学習するか
  • Adaptation tuning:事前学習済みLLMをどう有効にチューニングするか
  • Utilization:どうLLMを利用してタスクを解くか
  • Capacity evaluation:どのようにLLMの能力を評価するか

概要:Overview

LLMの背景

Large Language Models(LLM)は、GPT-3、PaLM、Galactica等の大量データで大量のパラメータを学習したモデルを指す。現状のLLMはTransformerのmulti-head attentionレイヤーを多く積み重ね、事前学習では通常の言語モデルと同じ目的関数を利用するという点は共通している。異なる点はモデルのサイズ、事前学習データ、利用計算リソースといった点ぐらい。

LLM独自の能力

LLMではそれまでの比較的サイズの小さいモデルではみられない能力が確認されている。ここでは下記の3つの能力について紹介する。

  • In-context learning
    • モデルに指示やタスク実行例を提示された場合に、テストデータに対して期待される結果を追加の学習や勾配更新なしに実現することができる
  • Instruction following
    • 自然言語で表現されている様々なタスクが混じったマルチタスクデータセットを用いてファインチューニングすることにより、LLMは指示の形式で記述された未見のタスクに関しても良いパフォーマンスをすることが確認されている。この能力により、指示をチューニング(Instruction Tuning)することで明確な例をモデルに提示しなくとも、新しいタスクに対する指示に関しても従うことができる。
  • Step-by-step reasoning
    • 比較的小規模なモデルでは、解決に複数ステップのロジックが含まれるような算数の文章題を解くといったタスクを苦手としていた。しかし、LLMではプロンプトを用いることでステップ単位でのタスク解決を実行することにより、タスクを解けるようになった

LLMの発展に寄与した主要技術

現在のLLMが実現するにあたり、重要となった•なりそうな技術を紹介する。

  • Scaling
    • LLMが独自の能力を発揮するにあたり、必要になるモデル/データ/計算リソースサイズをバジェット制約の元で最適化する研究が近年進んでいる
    • 事前学習データの質が重要になるため、データ収集/クレンジングが重要になる
  • Training
    • LLMではモデルサイズが大きいので分散学習が必須。分散学習最適化のFrameworkとしてDeepSpeedやMegatron-LMや、lossのスパイクを避けるためのmixed precision training等の技術が利用されている
  • Ability eliciting
    • LLMの能力を引き出すためには、適切なInstructionの設計やin-context learning戦略の設計が必要になる。例としては下記のようなものがある
      • chain of thoughtのような思考過程をプロンプトに含める戦略
      • Instructionにタスクの詳細を含める戦略
  • Alignment tuning
    • LLMはモデルの性質上、人にとって有害な情報を生成してしまう可能性がある。これを防ぐために、人の価値観(無害、誠実、便利)にモデルを合わせる必要がある。この実現に向けた取り組みとして、下記のようなものがある
      • InstructGPTによる、Reiforcement Learning with Human in the Loop(RLHL)を活用した人の価値観に合せるためのチューニング
  • Tool manipulation
    • LLMはテキスト情報をベースとして作成されたため、テキストで表現されていないタスクや学習以後に新しく追加された知識に関するタスクは苦手。これらを回避するために、ChatGPTが外部のツールを利用するといったことが検討されている

GPT系モデルの進化の系譜

GPTを会話タスク方面に最適化したChatGPTの成功により、ChatGPTやGPT系モデルへの関心が高まっている。そこで、本節ではGPT系モデルの進化の系譜を紹介する。

OpenAIのLLM (GPT)に関する研究は下記のステージに分けることができるため、各項目ごとに説明していく。

  1. 初期探索期(Early Exploration)
  2. 性能向上期(Capacity Leap)
  3. 性能強化期(Capacity Enhancement)
  4. 目標達成期(The Milestone of Language Models)

1.初期探索期(Early Exploration)

言語モデルを活用した知的システムの構築のアイデアは、OpenAIにおいてかなり早い段階から模索されていた。Transformer登場後は、Transformerを利用したGPT-1とGPT-2を開発したが、それ以前にもRNNを用いた試みがなされていた。

  • GPT-1
    • 2017年のGoogleからのTransformer発表を受け、OpenAIのチームは自前の言語モデルにこの新しいアーキテクチャを適用し、2018年にGPT-1(Generative Pre-trained Transformer)を発表した
    • GPT-1はDecoderのみのTransfomer系生成モデルをベースとしており、非タスク依存学習を実現するために、下記を組み合わせたアプローチをとっていた
      • 教師なし事前学習
      • 教師ありのファインチューニング
    • このアプローチが以降のGPT系モデルに共通する中心的なアプローチとなっていった
  • GPT-2
    • GPT-1のアプローチを踏襲した上で、モデルのパラメータ数を1.5Bまで大幅に増やし、WebTextデータで学習したモデル
    • GPT-2では明示的な教師データを用いたファインチューニングをせずに、教師なしの言語モデリングのみでタスクを解く方法を探索し、マルチタスク学習で用いられていた確率モデルの考え方を導入した

      • p(output | input, task)の事後確率を予測するためのinput、output、taskを統一的に表現する情報として自然言語文が利用できると考えたとのこと
      • これにより、全てのタスクは自然言語処理の領域で解けるようになると考えた

        “Since the (task-specific) supervised objective is the same as the unsupervised (language modeling) objective but only evaluated on a subset of the sequence, the global minimum of the unsupervised objective is also the global minimum of the supervised objective (for various tasks)”

    • (汎用モデルの思想はこの辺りから実装に反映され初めている感じな気がする)

2.性能向上期(Capacity Leap)

GPT-2は「教師なしのマルチタスク学習モデル」を意図して開発されたが、教師ありのファインチューニングがされたSoTAモデルと比較するとパフォーマンスはよくなかった。GPT-2をベースとして、モデルを学習済みモデルと同程度までスケールさせたGPT-3を開発した。

  • GPT-3
    • 2020年に発表されたGPT-3は、GPT-2をベースとしてパラメータ数を175Bまで大幅に増やしたモデル
    • このモデルでLLMをfew-shot もしくはzero-shotで用いることにより、in-context learningの性質(適切な指示を与えることで、タスクに関する情報を学習時に与えなくとも、タスクを解けるようになる性質)が確認された
      • in-context learningにより事前学習とLLMの利用が同じ言語モデリングパラダイムにまとめられることが示唆された(GPT-2で想定していたこと)
    • GPT-3はNLPのタスクで優秀な成績を残したのみならず、本来なら特別なドメイン適用が必要なタスクに対しても優秀な成績を収めた
    • この成功によりGPT-3はPLM→LLMへの遷移における重要なランドマークとして考えられるようになった

3.性能強化期(Capacity Enhancement)

OpenAIではGPT-3の性能をさらに強化するために、コードデータでの学習と感覚との突合に取り組むようになった

  • コードデータでの学習
    • GPT-3では複雑なロジックが必要になるプログラムの補完や、算数の文章題を解くといったタスクを苦手としていた
    • これを解決するために、Githubのコードデータを用いた学習を実施したCodexをリリースしたところ、複雑なプロブラムの補完や算数の文章題を解くといったタスクでパフォーマンスが大幅に改善した
    • また2022に紹介された文章とコードの埋め込みにcontrastive lossを用いるアプローチにより関連するタスクについても性能改善が確認された
    • アップデートされたGPT-3.5は、このコードデータで学習されたモデルをベースとして確証されたことで、大幅な性能改善が確認された
      • このことから、複雑なロジックに関する性能改善にはコードデータでの学習が重要になることが明らかになった
  • 感覚との突合(Human Alignment)
    • モデル出力の人の感覚との突合は2017年からOpenAI内で課題として認識されており、解決に取り組んでいた

      openai.com

    • これを実現するための技術開発として下記のような研究が次々と発表されていった

      • 2017年:人によるannotationを活用した嗜好比較(preference comparisons)

        arxiv.org

      • 2017年:強化学習の方策最適化方法Proximal Policy Optimization(PPO)の提案

        arxiv.org

    • 2020年にはこれら手法を利用したGPT-2のチューニングが実施され、2022年にはInstructGPTが提案されGPT-3モデルで感覚との突合が実施された

      arxiv.org

    • これらの結果、GPT-3の指示に従う性能が改善するとともに、人にとって有害な情報出力(偽情報など)が軽減するといった改善が確認された

      • OpenAIでの感覚との突合に関するアプローチについては下記にまとめられている

      openai.com

4.目標達成期(The Milestone of Language Models)

これまでの探索の結果、OpenAIはChatGPTとGPT-4というマイルストーンになる製品がリリースされた

  • ChatGPT
    • 2022年11月にOpenAIはGPT-3.5とGPT-4をベースとする会話モデルChatGPTをリリースした

      openai.com

    • ChatGPTは基本的にはInstructGPTの手法を利用したものだが、会話により最適化されたものになっているとのこと

      • 具体的な違いとしては、人の生成した会話データがInstructGPTで利用したデータに追加されているとのこと
    • ChatGPTは人とのコミュニケーションで優れた性能を発揮している。
      • 広大な知識ベースの整理
      • 数学の文章題を解くといった複雑なロジックを含むタスクの解決
      • 複数ターンの対話でのコンテキストの把握
      • 人にとっての有害な出力抑制
    • また、ChatGPTのプラグイン機能が提供されたことにより既存アプリケーション等への統合が進んでいる
    • ChatGPTは現在、AIの歴史上で最も進んだChatbotであるため、多くの影響をAIの研究に与えるだろう
  • GPT-4
    • 2023年3月にOpenAIは文章入力の他に、画像等のマルチモーダルデータが入力としてサポートされたGPT-4した。
    • 多くのタスクで、GPT-3.5と比較して大幅な性能改善が確認されている

      arxiv.org

    • 特に6ヶ月に及ぶRLHFにより、安全性は大きく改善しているとのこと

      https://cdn.openai.com/papers/gpt-4.pdfcdn.openai.com

    • モデルを改善するための新しい技術としては下記を導入している

      • read teaming
        • 有害な出力生成を抑えるための手法
      • predictable scaling
        • モデル学習時の計算インフラ最適化

LLMは急激に進展したものの、まだまだ偽情報を生成してしまうといった課題が解決したわけではないので、利用には注意が必要。

リソース:Resources of LLMs

LLMsで利用されている/利用可能なリソースを紹介する

モデル

モデルの変遷は下記の通り

モデルの変遷

各モデルの概要は下記の通り

モデルの概要

API

Open AIはAPIとしてChatGPTやGPT-4を利用できる環境を提供している

openai.com

データソース

LLMを作成する上で頻繁に利用されているデータソースは下記のとおり

データソース

ライブラリ

  • Transformers
    • Huggingfaceが開発したTransformer系モデル構築に利用可能なPythonライブラリ
  • DeepSpeed
    • Microsoftが開発したPytorchモデルの最適化ライブラリ
  • Megatron-LM
  • JAX
  • Colossal-AI
    • HPC-AI Techが開発した大規模モデルの学習効率化ライブラル
  • BMTrain
    • OpenBMBが開発した大規模モデルの学習効率化ライブラリ
  • FastMoE
    • Mixture of Expert(MoE)モデルのための学習効率化ライブラリ

事前学習:Pre-training

大規模なコーパスを用いた事前学習により、LLMは基本的な言語理解/生成能力を獲得する。この時、下記が重要になる

データの質と量

LLMの能力はデータに依存しているため、事前学習で能力の高いモデルを生成するたには、高い質のデータを大量に集める必要がある。このためにこの節では下記内容について紹介する

  • 事前学習用データの収集と前処理
  • 事前学習データがLLMの性能に与える影響

事前学習用データの収集と前処理

能力の高いLLMを開発するためには、さまざまなソースの自然言語データを用いるのが肝要。実際、多くのLLMではさまざまなデータソースを混ぜて利用している。

データソース割合

利用されるデータには下記のようなものがある

  • 一般テキストデータ
    • Webpageデータ
      • ウェブページをcrawringしたデータCommonCrawlなど。情報の質にばらつきがあるため、不要データのフィルターや前処理が重要
    • 会話文データ:
      • QAタスクのPublicなPushShift.io、Reddit corpusやSNS上の複数人による会話データ。話者を特定するために、会話のツリー化が重要。これにより、会話をさらにサブツリーに分解していくことができる。
      • 会話文データをLLMの学習データに含めすぎると、ユーザからの指示を会話の起点と捉えられ、適切な回答を得られなくなるという副作用がある
    • 本データ
      • 本のオープンソースデータとしてはBook3やBookcorpus2データセットが利用される。長文のフォーマルなデータとして利用できるため、言語の文法を学習に役立っていると考えられている。
  • 専門テキストデータ
    • 多言語データ
      • BLOOMやPaLMには122言語が学習データに含まれている。結果、翻訳や多言語要約、多言語QAといったタスクにこれらのモデルは秀でており、対象言語でファインチューニングされたSoTAモデルよりも良い成績を残している
    • 科学文書データ
      • arXivや教科書、数学/科学関連サイト等の情報が用いられている。数学記号や原子配列といった特殊な情報が含まれるため、特殊なトークン化等の前処理が必要になる
    • コードデータ
      • プログラムのQAサイトやGithub等のリポジトリ情報が利用される。自然言語と異なり、厳格なロジックがあるためコードデータを用いることにより、モデルは複雑なロジックのタスクにも対応できるようになった

学習データを揃えたら、続いて適切な前処理で不要な情報や有害な情報を取り除く等の作業が必要になる。

フィルタリングプロセス

  • Quality Filtering
    • 分類機やヒューリスティックなアプローチで質の低いデータを学習データセットから除外する。分類機は良文学習的なアプローチでモデルを作成するが、質の高いデータを除外してしまう可能性が指摘されている。そのため、BLOOMやGopherでは下記のようなヒューリスティックなルールをもとにデータを除外している
      • 言語ベースフィルタ
        • 利用を想定していない言語データは除外する
      • 指標ベースフィルタ
        • 複雑度等の指標をもとに基準を満たさないデータは除外する
      • 統計ベースフィルタ
        • 平均的な文章の長さやシンボル-語比率等の文章に関する統計情報から外れているデータは除外する
      • キーワードベースフィルタ
        • HTMLのタグといったデータを除外する
  • De-duplication
    • 学習データ内部での重複は言語モデルの多様性を減少させ、学習の不安定化につながることが知られている。そのため、データから重複を除外する必要がある。
    • データの重複除外は下記のような粒度で実施される
      • 文レベルの重複 : 単語の繰り返しが多い文の除外
      • 文書レベルの重複 : 単語やn-gramの重複が多い類似内容文書の除外
      • データセットレベルの重複:学習データセットと評価データセット間の重複データ除外
  • Privacy Redaction
    • ウェブのソースから得られたデータには個人情報が多分に含まれるため、これをルールベースで除外する必要がある
  • Tokenization
    • LLMの入力とするためにテキストデータを単語等のトークン単位に分割する処理
    • 既存のTokenizer (GPT-3はGPT-2のtokenizerを流用)を流用することも可能だが、事前学習データのコーパスに合わせたTokenizerは非常に有益であることが知られている
    • 近年のLLMの多くはSentencePieceを利用して、事前学習データのコーパスに合わせたtokenizeをしている。SentencePieceではバイトレベルのByte Pair Encodingにより、トークン化時の情報損失を軽減している

      arxiv.org

事前学習データがLLLMの性能に与える影響

LLMはその規模の大きさから学習を繰り返し実施するのは難しい。そのため、事前学習データのコーパスを十分に精査し、準備しておくことが重要になる。本節では事前学習データの分布や質がLLMの性能に与える影響について下記の観点で議論する

  • Mixture of Sources
    • LLMでは異なる特徴を持つデータソースを混ぜて利用することにより、より汎用的な知識を獲得している。ただ、複数のデータソースを混ぜる場合、データの分布に注意しないと下流タスクの性能に影響が出る可能性がある。
    • Gopherを用いたablation studyでは下記のような結果が報告されている
      • Book関連のデータ比率を増加させることで、長期間の依存関係を補足する能力が向上
      • C4のデータ比率を増加させることでC4の評価セットでの評価が向上
    • 一方で特定ドメインのデータ比率を増加させすぎると汎用性が落ちることが報告されているため、データソースを混ぜる際にはその比率に注意が必要
  • Amount of Pre-training Data
    • LLMのパラメータを増加させるに従い、学習に利用するデータのサイズを増やす必要があることが報告されている
    • また、いくつかのLLMでは事前学習データセットが足りていないために最適な性能が得られていないとの報告もある
    • そのため、研究者は事前学習で利用する質の高いデータセットが十分な量あるかについても注意を払う必要がある
  • Quality of Pre-training Data
    • 事前学習データに重複/有害/ノイズが含まれる場合、性能が劣化することが報告されている
    • LLMを用いた検証(T5, GLaM, Gopher)で行われた検証では、質の高いデータを用いた場合の方が下流タスクを解く際のモデル性能が高いことが確認されている。そのため、質の高いデータを準備することは非常に重要
      • 特にデータの重複はモデルの性能への影響が大きいとのこと

モデルのアーキテクチャ

現在のLLMでは下記のようなアーキテクチャが利用されている

モデルのアーキテクチャ

  • Encoder-Decoder Architecture
    • Transformerを用いて、EncoderとDecoderを作成するアーキテクチャ
      • Encoderではmulti-head self-attention レイヤを積み上げることで潜在空間での表現を獲得する
      • Decoderでは潜在空間での表現に対してcross-attentionを適用し、自己回帰的に出力を生成する
  • Causal Decoder Architecture
    • Caudal Decoderではunidirectional attention maskを利用することで自身以前の情報しか利用できないようにしたアーキテクチャ
      • 入力と出力では同じ構造のDecoderを利用
    • GPT系モデルはCausal Decoderアーキテクチャで設計されているが、GPT-1/2ではGPT-3のようなLLM独自の能力が発揮されることはなかったため、スケールが大きくなることでより有効に働くようになったと考えられる
  • Prefix Decoder Architecture
    • Causal Decoderのマスキング方法を見直し、双方向のattentionをprefix tokenに対して実施し、単方向のattentionを生成部のみ利用するようにしたアーキテクチャ
    • (より汎用的な潜在空間の表現獲得が可能になると思われる)
    • まずはCausal Decoderで学習し、モデルをPrefix Decoderに変換して学習すると効率的とのこと

      www.ogis-ri.co.jp

学習の高速化と最適化

各LLM学習時の設定は下記の通り

学習の最適化

LLMの チューニング: Adaption Tuning of LLMS

事前学習でLLMはさまざまなタスクを解く汎用的な能力を獲得する一方で、特定タスク解決に向けて適応させることができることが報告されている。

適応させる方法としては大きく分類して下記がある。

  • Instruction Tuning
  • Alignment Tuning

Instruction Tuning

Instruction Tuningは事前学習済LLMを、自然言語の形式にフォーマットされたドメイン固有のデータセットを利用してファインチューニングする方法を指す。

Instruction Tuningを実施することにより、LLMは学習データに含まれない未知のデータに対しても高い能力を発揮するようになることが確認されている。

Instruction Tuningを実施するためのデータを集める方法には下記のようなアプローチがある。

インストラクションチューニング

  • Formatting Existing Datasets
    • 既存のデータセット自然言語の形式にフォーマットして入力として利用する方法
    • これらのデータセットを利用してLLMをファインチューニングを実施することで、学習時に未知だった下流タスクに関しても性能が向上することが報告されている
    • これらの情報を効率的に収集するためのクラウドソーシングプラットフォームとしてPromptSouceというサービスなどがあるとのこと
  • Formatting Human Needs
    • PublicなNLPデータセットを用いる方法では、指示の多様性が十分ではない/現実の人の要望と異なる可能性がある
    • OpenAIではこの問題を回避するために、InstructGPTでOpenAI APIで収集した指示を用いる方法を提案した。また、さらに多様性を増加させるために、人手での指示作成を実施した。回答としては、別グループの人で作成した回答情報を利用した。
    • この手法の有用性は周知の通り。

データを作成する際には下記項目に注意すると汎用的な性能を獲得しやすいいとのこと

  • Scaling the instruction
    • 指示タスクタイプ(QA、分類など)を増やすこと
    • 指示タスクのディスクリプションを充実させること
    • 指示タスクのインスタンス数は少量にすること
  • Formatting design
    • どのように指示を自然言語で変換するかが重要
      • タスクのディスクリプションを記載すること
      • タスクの例をDemonstrationとして追加すること
    • Chain of thought のような例をデータセットに混ぜると性能が改善するという報告もある

Instruction Tuningの結果として下記のような結果が報告されている。

  • Performance Improvement
    • 事前学習データと比較して少ない指示データで学習したにも関わらず、Instruction Tuningにより性能改善することが確認されている
  • Task Generalization
    • Instruction tuningはモデルに自然言語の指示全般を理解させることに一役かっているため、実施することにより人からの指示に従いやすくなる

Alignment Tuning

さまざまなタスクでLLMは素晴らしい性能を発揮している一方で、偽情報の生成、不適切な表現などしてしまうという課題もある。これは事前学習でLLMが次の単語を予測するというタスクで学習しているため、人の価値観や嗜好を明示的に考慮できていないことが原因の一つと考えられている。

そこで、LLMの出力と人の価値観と突合するための方法が提案された。ただ、事前学習やInstruction tuningとは異なる基準を導入することになるため、Alignment tuningの結果、汎用性能が一部悪化することが報告されている(alignment tax)

  • Alignment Criteria
    • チューニングの基準はさまざまあるが、大きく分類すると下記のようになる
      • Helpfulness : 人をどれだけ支援できるか
      • Honesty : 偽情報を生成しないか
      • Harmlessness : 出力結果が攻撃的でないか

これらは人の主観的な認識のため、数値化し最適化の対象とすることは非常に難しい。将来性のある方法としては red teamingがある。(これは、マニュアル等を利用してLLMを検査する方法?)

具体的な方法は下記内容を参照のこと

arxiv.org

活用 : Utilization

事前学習とチューニングが終わったモデルはプロンプト経由で利用することができる。典型的なプロンプト方法には下記がある。

  • In-Context Learning
    • プロンプトにタスクの説明やタスクの実行例を自然言語で含める方法
  • Chain of thought prompting
    • In-Context Learningを補強する方法として、ロジックの中間ステップをプロンプトに含める方法

プロンプトテクニック

In-Context Learning (ICL)

適切なタスクの実行例をモデルに提示することで、LLMは追加の学習なしに適切な回答を得ることができる。ただ、タスクの実行性能はモデルに提示する実行例に依存するため、性能をあげるためには適切な実行例を提示する必要がある。

適切な実行例を提示する方法として本節では下記内容を紹介する

  • 実行例の選択
  • 実行例の自然言語フォーマット方法
  • 実行例の提示順序

In-Context learningのより詳しい内容については下記を参照のこと

arxiv.org

実行例の選択

ICLの精度はモデルに提示する実行例に大きく依存する。実行例の選択方法には、下記がある

  • Heuristic approach
    • そのシンプルさと簡易さから、探索的なアプローチがよく利用される
    • k-NN等を利用してタスクに類似した実行例を探す方法(実行例間の比較はなし)や、実行例の多様性を考慮するためにサンプル集合からもっとも代表的な実行例を探す(実行例間の比較あり)方法が提案されている
  • LLM-based approach
    • LLMに実行例の重要度を出力させ、その重要度をもとに実行例を選択する方法や、LLM自体に実行例を生成させる方法が提案されている

実行例の自然言語フォーマット方法

実行例の選択が終わったら、その実行例を自然言語で表現する必要がある。

  • 事前定義済みのテンプレート利用
    • 実行例の質問と回答で変化する部分のみを穴埋めする方法(例.数学文章題の数値部分のみ変えるなど)
  • 回答タスクの説明追加
    • 回答タスクの説明を追加することで、回答性能が改善することが報告されている
    • 回答タスクの説明自体をLLMに事前に生成させることで、説明データを集める労力を軽減する方法も提案されている

実行例の提示順序

LLMは最後の実行例の結果に影響されやすいという性質を持つことが確認されている。そのため、実行例の提示順序が重要になる。

  • 実行例の類似度順
    • タスクとの類似度が近い実行例ほど、実行例を最後に持ってくる
  • その他指標順
    • 情報量など

Chain of thought prompting (CoT)

CoTは複雑な論理構造を持つタスクや、一般常識に関連するタスク等のタスクでLLMの性能を改善するために考えられたプロンプト戦略。

ICLでは入力-出力のペアのみをプロンプトに与えるが、CoTでは最終的な出力結果につながる中間出力をプロンプトに含める。(図7参照)

CoTは下記それぞれの設定のもとで頻繁に利用される。

  • Few-shot CoT
    • Few-shot CoTは実行例を「入力-CoT-出力」として与える方法(「入力-出力」ではないということ)
      • CoT prompt design
        • CoTの多様性を増やすこと(各タスクに対して複数のロジックを記載する等)で性能が改善するということが報告されている。特に複雑なロジックの方がLLMの性能改善につながるとのこと。
        • ただ、↑の場合、データが必要になってしまう。そこでAuto CoTではZero-shot-CoTを活用し、手動データ準備が不要になるようにしている。
      • Enhanced CoT strategies
        • CoTはタスクの背景知識を増やすだけでなく、タスクの検討に利用するロジックの幅を増やすことに利用できる
        • 多くの研究では複数のロジックパスを生成し、正しい回答に紐づくパスを回答の多数決から決めて、決めて利用している。これを活用した提案であるself-consistencyでは、CoTによる性能改善幅をブーストしたことが報告されている
  • Zero-shot CoT
    • Zero-shot CoTは、データを利用せずに「Let’s think step by step」でプロンプトを開始し、最終的な結論を「Therefore, the answer is」というプロンプトで促す方法
    • LLMが一定の規模を超えると、この戦略で性能が大幅に改善することが確認されている

CoTはLLMで初めて確認された能力のため、一定以上の規模のモデル(10B以上のパラメータ数)でのみ有効に働く。また、数学の文章題、一般常識課題、記号推論といったステップごとのロジックが必要なタスクでは有効に働くが、その他の通常タスクで利用すると精度が劣化するという報告もあるため、使い所は慎重に考える必要がある。

機能評価 : Capacity Evaluation

LLM機能の評価で利用されているタスクとデータセットには下記のようなものがある。

評価データセット

  • Language Generation
    • Language Modeling : 次に来る単語(トークン)を予測するタスク
    • Conditional Text Generation : 特定の要求(翻訳、QA、ようやくなど)を満たす文章を生成するタスク。LLMにより高いスコアが得られすぎたため、よりBIG-bench Hard等の難しいデータセットが作られている
    • Code Synthesis:コードを生成するタスク
  • Knowledge Utilization
    • Closed-Book QA : 外部のリソースを利用することなく、特定コンテキスト内で質問に回答するタスク
    • Open-Book QA:外部のリソース利用を許可した上で、質問に回答するタスク
    • Knowledge Completion:欠損している部分の知識を補完するタスク
  • Complex reasoning
    • Knowledge Reasoning : 論理構造と根拠をもとに質問に回答するタスク
    • Symbolic Reasoning : 記号と記号活用ルールをもとに推論するタスク
    • Mathematical Reasoning : 数学課題に回答するタスク

現在評価データとして頻繁に利用されるのは、上記のうちMMLU、BIG-benchとHELM。

  • MMLU:幅広い知識(数学、CS、人文学など)を含む、知識理解の能力を図るために利用されるデータセット
  • BIG-bench:204のタスクを含むLLMの性能を測るために作成されたベンチマークデータセット
  • HELM:16シナリオ7カテゴリの情報に関するLLMの性能を測るために作成されたデータセット

結論と今後の方向性 : Conclusion And Future Directions

本論文では近年のLLMの発展を理解するために、発展に寄与した主要なコンセプトや技術、LLMの利用方法について下記の観点で紹介した。(LLMの対象としてはパラメータ数が10Bを超えるものを対象とした)

  • Pre-training:優秀なLLMを作るためにどう事前学習するか
  • Adaptation tuning:事前学習済みLLMをどう有効にチューニングするか
  • Utilization:どうLLMを利用してタスクを解くか
  • Capacity evaluation:どのようにLLMの能力を評価するか

現在LLMが抱える課題や挑戦、今後の発展の方向性をまとめると下記のようになる

  • Theory and Principle
    • LLMが獲得した能力が、いつ、どのように発現したかは明らかではない。この原因究明に研究コミュニティが取り組むことは次世代のLLM開発のために非常に価値がある
  • Model Architecture
    • スケーラビリティや有効性の観点から現在のLLMではTransformerを活用することがスタンダードとなっている。現在はcontext windowを広げる(GPT-4-32kは32,768tokenをコンテキストとして利用)、より多くの文脈情報を利用することでモデルの性能を改善しているがより効率的なアーキテクチャを模索する必要がある
    • またcatastrophic forgetting等に関しても、データの更新やタスクへの特化を効果的に行えるような既存のアーキテクチャを拡張する柔軟な方法や機構の検討が必要になる。
  • Model Training
    • LLMを何度も学習するのは、計算リソース、学習のコツ、データの質の担保の観点から難しい。そのために下記に取り組む必要がある
      • 学習時に発生した異常の早期検知
      • 計算リソースの最適化
      • 検証に利用可能なオープンソースの学習済みモデルの整備
  • Model Utilization
    • LLMのfine-tuningを実施するのはコストが非常に高いため、LLM活用の際にはプロンプトを利用したIn-Context Learningを活用することが多くなると思われる。プロンプト活用の幅を広げるために、下記課題への取り組みが必要。
      • プロンプトのデザインにかかる人手の削減方法検討
      • 自然言語で表現されていない複雑なタスクのプロンプトデザイン方法の検討
      • 複数回のコミュニケーションを前提としたプロンプト方法の検討
  • Safety and Alignment
    • LLMは人にとって有害な情報を生成してしまうことがある。これをGPT-3/4ではRLHFで軽減することに成功している。ただ、現状のRLHFには多大な人手が必要になる。これを改善するためのフレームワークの検討が必要

今後読みたい論文や資料など

  • LLMについて本論文を記載した研究メンバーがメンテナンスするリポジトリ

github.com

参考資料

  • OpenAIブログポスト

Planning for AGI and beyond Learning from human preferences Our approach to alignment research Introducing ChatGPT https://cdn.openai.com/papers/gpt-4.pdf Product

  • 論文

[1706.03741] Deep reinforcement learning from human preferences [1707.06347] Proximal Policy Optimization Algorithms [2203.02155] Training language models to follow instructions with human feedback [2303.12712] Sparks of Artificial General Intelligence: Early experiments with GPT-4 [1808.06226] SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing [2301.00234] A Survey on In-context Learning [2303.18223] A Survey of Large Language Models

  • その他

GitHub - RUCAIBox/LLMSurvey: The official GitHub page for the survey paper "A Survey of Large Language Models". はじめての自然言語処理 T5 によるテキスト生成の検証 | オブジェクトの広場

機械学習の品質問題(3.2〜3.3)

3.2までは主に入力に対応する出力がわかっている場合に、テストをどう実施するかについて説明がされてきた。3.2以降では、機械学習システムのように入力に対する出力が必ずしもわからないシステムで、どんなテストができるのかについて説明する。  

紹介されている手法は下記の二つ。  

  1. メタモルフィックテスティング  
  2. 統計的なテスティング  

以降、それぞれの方法について見ていく。  

1. メタモルフィックテスティング

概要

メタモルフィックテスティングは3.1.7で説明があった部分オラクルを利用したテスト方法。  

同じく部分オラクルを利用したテスト方法のデザイン多様性では同じ機能仕様を実現した複数のプログラムを利用して出力の一致をとることでテストを実現したのに対して、メタモルフィックテスティングでは一つのSUT (System Under Test)を利用するため、開発コストを下げられるという特徴がある。

メタモルフィックテスティングでは、まず検査対象fの2つの異なる実行結果が満たす関係性Relを満たす様な入力の変換Tを見つけ、この変換Tを用いて新たなな入力を生成する。このとき、元となる入力xと変換して獲得した入力x’で生成した出力の関係性がRelを満たさなかったとき、fに欠陥があるとする。

数式で書くと下記のようにまとめられる。

f:id:okehara_aoi:20210602182634p:plain:w300 f:id:okehara_aoi:20210602182715p:plain:w220

なお、変換Tを用いて生成された新たな入力をフォローアップ・テスト入力と呼ぶ。

わかりにくいので例

三角関数sin(x)を級数展開を利用して近似計算するプログラムを考える。

f:id:okehara_aoi:20210602182733p:plain:w200

ここでは上記を利用して得られた、有限の多項式をプログラム化してsin(float x)とする。 通常テストする場合、三角関数が持つ周期性を利用して、x=0, π/2, π, 3π/2, 2πを入力とし、それぞれ出力に0, 1, 0, -1, 0を期待するテストが考えられる。ただ、これらの境界値を検査したとしても、特徴的な値のみを調べただけのため、テストとしては幾分心許ない。

そこで、メタモルフィックテスティングを利用することでテストに幅を持たせることをかんがえる。

メタモルフィック性(関係性Rel)の例

この例では三角関数の数学的な性質から関係性を求めることができる。例えば、下記の性質が利用できる。

f:id:okehara_aoi:20210602182802p:plain:w200

この性質から変換Tと関係性Relを求めると下記のようになる。

f:id:okehara_aoi:20210602182830p:plain:w300

実際にテストをしてみる

得られた変換Tと関係性Relを利用してテストを実施する。
変換前の初期値としてx_0 = 7π/13と利用すると、変換後のフォローアップ・テスト入力x_1は20π/13になる。こうして得られた入力から関係性Relでえられる正解値は0となる。同様にしてプログラムに入力し得られる値を求め、この値が0にならなければプログラムに欠陥があると判断することができる。

フォローアップ・テスト入力生成について

  • メタモルフィック関係は無数にあるが、適当なものを1つ利用してもいいし、複数利用してもいい。網羅性の基準をもとに判断すればよい

  • メタモルフィック関係から得られた変換関数Tを多重適用するなどして、様々なテスト入力を系統的に自動生成できる。具体的には4.3節で説明する

    どんなところで利用されるか

    入力に対する計算結果の正解値を予め知るのが難しいプログラムに対して適用される

  • 数値計算

  • コンパイラ
  • トランスレータ
  • セキュリティシステム
  • 機械学習ソフトウェア etc

2. 統計的なテスティング

概要

同一の入力データに対して同じ計算結果を得ることができないような確率的振る舞いをするプログラムも、入力と出力を1:1で対応づけることができないため、テストが難しい。
こういったプログラムには下記のようなものがある。

  • サイコロの出目を決めるプログラム (本質的に挙動が確定しないもの)
  • 都市交通の道路混雑状況シミュレータ(時間経過とともに確率変数が変化するもの)
  • 自然界データの解析プログラム  (データ取得の不確かさによるもの) etc

こういったプログラムでは統計的なオラクルを用いることでテストをすることができる。

この方法はプログラムの出力結果を測定値と考えて、データ分析をすることと捉えられる。検査に利用できる統計指標をもとめ、その統計指標が期待通りであるかを検定で確認することでプログラムのテストを実現している。

たとえば、実行結果の集まりが正規分布に従うと仮定でき、期待できる平均値がわかっている場合、t検定を用いて統計的なテスティングを実現できる。

仮説検定

釈迦に説法だとおもうので割愛

ソフトウェアテスティングと仮説検定

統計的なオラクルはソフトウェアテスティングの標準的な教科書の内容を超える新しいテーマらしい。

ただ、基本とする仮説検定にはショフトウェアテスティングと共通する考え方が見られる 仮説検定による議論では、正解に一致して帰無仮説が棄却できなかったとしても欠陥がないと断言しない。この点についてソフトウェア・テスティングも同様で、テストが全て通ったからと言って欠陥がないとはいいきない。

こういった考え方の類似性から、ソフトウェアテスティングに仮説検定を応用するのは自然な流れ。(たぶん、これから流行っていく、と言いたいんだと思う)

所感

機械学習システムまわりで、この辺りをできている人たちはどれくらいいるんだろうか?信頼性の高いシステムを作る上で、この辺りをやっていくのは重要だが、手軽にできる様にならないとなかなか進まない気がする。変換関数を見つけて、データ増やしてくれたりする簡単にできるライブラリとかあるんだろうか?

参考

機械学習システムのためのメタモルフィックテスティング入門 - Qiita

AIプロダクト品質保証ガイドライン2019まとめ - 02 - Qiita

Metamorphic Testing of Machine-Learning Based Systems | by Teemu Kanstrén | Towards Data Science

遺伝的アルゴリズムにおける積み木仮説とスキーマ定理

モチベ

遺伝的アルゴリズムにおける積み木仮説とスキーマ定理の関係性について興味が沸いたので、調べた結果について簡単にまとめた

内容

GAはあまり数学的分析が進んでいないが、積み木仮説とスキーマ定理を用いてその挙動を説明することができる

ここでは積み木仮説とスキーマ定理によるGAの挙動の説明を試みる

積み木仮説は最適解に近い良好な解はその部分構造(積み木)が組み合わさることで生成されるという仮説

この積み木仮説の1手法にスキーマがある

スキーマについて

スキーマとは個体の構成要素である遺伝子の部分集合のことである

遺伝子長5で値に{0, 1}をとる遺伝子のスキーマの例をあげると[1, 0, 1, * , *]のようなものが考えられる

この時 * はワイルドカード記号を示し、{0, 1}のどちらにも一致するものと考える

そのため例のスキーマは[1, 0, 1, 0, 0], [1, 0, 1, 0, 1], [1, 0, 1, 1, 0], [1, 0, 1, 1, 1]の4遺伝子から構成される遺伝子の部分集合となる

スキーマは実体の他に定義長とオーダーという属性をもつ

定義長 :遺伝子を左から見て * 以外の値と最後の * 以外の値のビット位置の距離

オーダー:* 以外の値の数

例の[1, 0, 1, * , *]は定義長が2、オーダーが3のスキーマになる

このスキーマを利用して、前の世代から次の世代にどれだけ特定のスキーマが生き残るかを検討するのがスキーマ定理(なので、GAには深く関わりのある定理)

スキーマ定理の考え方

単純なGAを例として、特定のスキーマが次世代にどれだけ生き残るかを考える

変数の定義は下記

f:id:okehara_aoi:20201021201312p:plain <\div>

まず、ベースラインとして交叉や突然変異がない場合を考える

GAのアルゴリズムでは適合率に応じて次世代に残るHを決定するため、次世代に残るHの件数m(H, t+1)はm(H, t) の関数として表せる。適合率の比率により次世代に残る件数が決まるとすると下記のように表せる

f:id:okehara_aoi:20201021201107p:plain <\div>

続いて交叉を考慮に加えた場合を考える

交叉では定義長の間に交叉点が入ることによりスキーマが壊れるため、スキーマが壊れない場合を考える

スキーマが壊れる場合とは、長さlのうち、切断可能な位置はl-1箇所でそのうち定義長δ(H)無いで切断された場合になる

そのため、ランダムに選択された切断位置から表現を失うようなHが発生する確率PはP=δ(H)/(l-1)と表せる。これに交叉が発生する確率p_cの考慮を加えると、表現を失うようなHが発生する確率P_c=p_c*δ(H)/(l-1)と表せる

これらの結果から、スキーマが壊れない場合の確率は1-P_c=1-p_c*δ(H)/(l-1)と表せることがわかる。これを交叉考慮前の式に掛け合わせることで、交叉を考慮したm(H, t+1)を求めることができる

f:id:okehara_aoi:20201021201150p:plain <\div>

※不等号となるのは同じスキーマ H に含まれる値が交叉をしてもスキーマが破壊さ れることがないなどの場合があるため

最後に突然変異を考慮に加えた場合を考える

交叉と同様に突然変異により、スキーマが壊れない場合を考える

スキーマ中の * 以外の要素に突然変異が起きない場合、スキーマは壊れない

これをオーダーO(H)と突然変異率p_mを用いて表すとスキーマが壊れない確率P=(1-P_m)**O(H)と表せる

P_mは通常小さい値なのでPを近似するとP≈ 1-O(H)P_mと表せる

これを交叉考慮の式に加えると下記のようになる

f:id:okehara_aoi:20201021201209p:plain <\div>

この式で表されるm(H, t+1)とm(H, t)の関係性をスキーマ定理という

スキーマ定理に基づくGAの挙動

これを単純なGAに当てはめた時、 p_c >> p_a、δ(H) > O(H) のため式内のO(H)⋅pmはほとんど無視できる

そのため、下記の条件を満たすスキーマHの件数 は指数関数的に増大していくことがわかる

  • 定義長δ(H)が短く

  • 適合度f(H)が全体の平均よりも大きい

これらの条件を満たすスキーマは * 以外の値が部分的に固まっており、適合度が高いスキーマになっている

これは共通点の少ない適合度の高いスキーマが探索対象に増えていくことを示しており、GAにおいて解の探索(適合度の高い解を探すこと)が進むことを示している

参考

【調査報告】スキーマ定理
GAの理論的背景 システムの最適化 - 4.遺伝的アルゴリズム( GA: Genetic Algorithm ) - メタヒューリスティクスとナチュラルコンピューティング

Modeling the Distribution of Normal Data in Pre-Trained Deep Features for Anomaly Detection

モチベ

特定ドメインの良品画像のみを利用して異常検知を実装することが多い中で、オープンなデータセットをうまく使えないかなと悶々としていたら

もはやオープンなデータセット利用を超えて、公開されてる学習済みモデルを利用した異常検知手法が提案されたとの噂を聞いた

精度もめちゃくちゃいいとのこと。しゅごい。

これは確認しないといけないよね、ということでこちらの内容をまとめた

簡単まとめ

どんな研究?

  • ImageNetで学習済みのモデル(ResNet, EfficientNet)から最終レイヤーを除くレイヤーの出力をチャネル単位でGlobalAveragePoolingしたものを入力として利用

  • 各レイヤー、全レイヤーで多変量ガウス分布の母数を学習データから算出、マハラノビス距離を異常度のスコアとして異常画像の検知

  • MVTecADデータセットを用いた異常検知でAUROC95.8±1.2%のSoTAを達成

何がすごいの?

多変量ガウス分布の母数を求める部分以外ではデータにfittingしていないのにSoTAを達成(巨人の肩に乗れる可能性大)

どう使えそう?

  • DNN部分の学習の必要がないので、時間のない時にささっと試せる

  • 新しい画像系の手法の学習済みモデルが出たら、それをささっと流用して異常検知モデルを作れる

使えない場面は?

  • Image単位の手法なので、pixel単位の異常位置を知る必要のあるタスクには利用できない

  • 異常部位を見せることができないため、説明ができない

所感

イメージ単位でブラックボックスな手法で良い場合、この手法を適用してあげれば十分かも

詳細

概要

一般の異常検知タスクには下記の2点の特徴があるため、データセットに大きな偏りがでちゃう

  • 異常の発生はまれ

  • 異常の定義があいまい

結果、異常検知タスクには正常データのみを利用する半教師あり学習でモデルを作ることが多い

ただ、正常データ自体も件数が決して多いとは言えない

こういったタスクにはImageNet等の大規模データベースのデータを用いたモデルを作るのが有効なはずだが、残念ながらこういった方向の研究はあまり進んでいない

本研究の貢献は下記

  • 学習済みのdeepなfeature representationを異常検知タスクで利用できるようにした

  • 正常データのfeature representaionに多変量ガウス分布を当てはめ、そこからのマハラノビス距離を異常度として定義したモデルでMVTecADの異常検知タスクを解いたところ、SoTAを達成

  • feature representationを次元削減したモデルの精度をみることで、feature representationにおいて分散の小さいデータが異常検知タスクにとって重要という知見を獲得

先行研究

本提案の発想の元となった論文はLee et al.の下記論文とのこと

A Simple Unified Framework for Detecting Out-of-Distribution Samples and Adversarial Attacks

この論文では、分類タスクに関する学習済みモデルの予測結果に対してモデルの中間出力のマハラノビス距離をConfidence Scoreとして算出することで、OODやAdversarial Sampleを検知できることを示した

本提案はモデルの中間出力をImageNetで学習済みのモデルの中間出力を変更とすることで、異常検知タスクに転移学習的な要素を組み込めるように拡張したもの

方法

提案手法

  1. ImageNetで学習済みのモデルに学習用正常データを入力し中間出力のfeature representaionを取得

  2. 学習用feature representationに対して多変量ガウス分布を当てはめ母数を算出

  3. 多変量ガウス分布からの距離を異常度の指標として各データに対して異常度を算出し、異常値を判定

中間出力のfeature representationについて

ここではEfficientNet-B0を学習済みモデルとして利用する場合を例として示す

f:id:okehara_aoi:20201014183910p:plain

上図はEfficientNet-B0の構造を簡易的に模した図

本提案では単位構造ごとの中間出力をチャネル単位でGlobalAveragePoolingをとったもの(※論文での記載はないが実装ではそうなってた)をfeature representationとして利用

この時feature representationを入力に近い側からLevelという単位でラベルづけし、各レベルのみを使った場合と全レベルの結果を足し合わせた場合を検討している

※ここではEfficientNet-B0の場合を示したがResNet等を用いた場合も基本的な考え方は一緒

距離を用いた異常度算出について

本論ではユークリッド距離の他にマハラノビス距離を利用しているので、その簡単な説明

マハラノビス距離はxをデータ点、μを平均、Σを分散共分散行列とした時、下記のように表せる

f:id:okehara_aoi:20201014184152p:plain

マハラノビス距離は特徴量の分散と共分散を考慮した指標といえる

異常度をマハラノビス距離(d)で求めるとその閾値は確率的に求められるというメリットがある

特定のd内に正常サンプルが存在する確率pとすると、pは特定距離dでの判別機のTrue Negative Rate(TNR)と見なせ、1-pはFalse Positive Rate(FPR)と見なせる

Mをマハラノビス距離、tを距離の閾値、Fをカイ2乗分布の累積確率密度関数、Dを特長量次元とすると、下記のようにtと累積密度関数の関係式が成り立つ(ガウス分布からサンプルを取得した場合、マハラノビス距離の2乗はカイ2乗分布になることについて興味がある方はこちらからどうぞ)

f:id:okehara_aoi:20201014184228p:plain

これをtに関して解くと

f:id:okehara_aoi:20201014184245p:plain

となるので、与えられたFPRに関して閾値を計算できることがわかる

最終的にこのマハラノビス距離を異常度の指標として用いるが、この有効性は実験で確認しているので説明はそちらで

実験

本論文では下記を目的とした実験を実施

  1. 異常度指標選定とモデルの挙動確認

  2. 学習済みモデルアーキテクチャ選定

  3. 学習済みモデル複雑度の影響確認

  4. 有効な特徴量の性質検証

  5. 閾値の決め方の妥当性検証

  6. 他手法との精度比較

上記実験はMVTecADのデータを利用しており、カテゴリ ごとに5-foldのCVを行っているため結果は、平均と標準誤差(SEM)で記載

1. 異常度指標選定とモデルの挙動確認

異常度として平均値からの距離を利用するのはイメージしやすいが、どのような距離の定義を利用するかについては検討の余地がある

ここでは下記の距離の定義を用いて分類の精度がどう変化するかを確認

  • L2

    • シンプルな平均からの距離
  • Standard Euclidian Distance(SED)

    • 特徴量内の分散を考慮した距離
  • Mahalanobis

    • 特徴量内、特徴量間の分散を考慮した距離
f:id:okehara_aoi:20201014184330p:plain

上図はEfficientNet-B4で各距離指標を用いた場合のAUROC

全てのLevelにおいてマハラノビス距離を用いた場合の精度が圧倒的に良いことが確認できる

この結果を受け異常度の指標としてマハラノビス距離を用いることを決定した

またこの結果より下記の2点が確認できる

  • 高いAUROCを実現していることから、多変量ガウス分布を利用したモデルが妥当であること

  • 異常検知タスクの転移学習では抽象度(Level)の高い特徴量が有用であること

2.学習済みモデルアーキテクチャ選定

EfficientNetの他にResNet-18, 34, 50のアーキテクチャを試したが最良のAUROCで89.0%±3.0%の結果しか得られなかったため、以降EfficientNetをメインで用いることに決定

3.学習済みモデル複雑度の影響確認

EfficientNetにはB0 からB7の種類が存在し、添字の値が大きくなるにつれモデルの複雑度が上がる

この実験では複雑度の変化が精度に与える影響について確認

f:id:okehara_aoi:20201014184426p:plain

上図の結果からB4、B5を頂点とした緩やかな山が形成されていることが確認できる

B5以上の複雑度のモデルで精度が改善しない理由としては、モデルがImageNetに対してオーバーフィットしてしまい、新しいドメインへの適用に適さなくなっていることなどが想定される

この結果を受け、以降はメインのモデルとしてEfficientNet-B4を、複雑度の低いモデルとしてEfficientNet-B0を用いて検証することに決定

4.有効な特徴量の性質検証実験

ここまでの結果からもdeepなfeature representationに対して多変量ガウス分布を転移学習的に当てはめる提案手法が異常検知のタスクに有効であることがわかる

ドメインに依存しないはずのfeature representationがなぜ有効なのだろうか

筆者らは「異常検知タスクにとって重要な特徴は正常データ内で大きく変化しないのではないか」という仮説をたてた

これを検証するために多変量ガウス分布を当てはめる前のfeature representationに対して下記の操作を加えたモデルで精度を検証した

  • PCA : 分散の小さい特徴を除く

  • Negated PCA(NPCA):分散の小さい特徴を残す

f:id:okehara_aoi:20201014184609p:plain

上図より分散の小さい特徴を除いた(PCA)モデルの精度は悪化し、分散の小さい特徴のみを残す(NPCA)モデルの精度は維持されていることがわかる

この結果を受け、筆者らは仮説を立証できたとしている

また、正常データのみから学習する半教師あり学習モデルの精度が事前学習済みの特徴量を利用したモデルの精度に劣る理由もここにあるのではないかとしている

※理解しきれてませんが、AEなどで埋め込みを実施する場合、正常データ中における分散の小さい細かな特徴が切り捨てられてしまうから、うまくいかないと言っているような気がする。。。

検証目的とは別だが、今回の結果より分散の小さい特徴のみを残す方法が異常検知タスクの次元削減に有効な可能性が示唆されたとしている

5.閾値の決め方の妥当性検証実験

前に軽く述べたが、マハラノビス距離を利用すると距離の閾値は与えられたFPRに対して一意に定めることができるはず

与えられたターゲットのFPRを動かした際に、実際のFPRやTPRが想定した挙動を示さない場合、閾値による異常検知ができなくなってしまう。ので、その確認

f:id:okehara_aoi:20201014185056p:plain

※FPRを全Levelを用いたモデルに対して設定するのが難しいため、ここではLevel7で作られたEfficientNet-B0とB4モデルを対象とした。また、データサイズが小さいためかデータのaugmentationを実施した上で実験を実施

上図よりTarget FPRを徐々に減少させることにより、実際のFPRも徐々に減少しており、想定した動きをしていることがわかる(ただ、augmentationを実施しなかった場合はうまくいかなかったそう。この点の検証は今後やっていくそう)

6.他手法との精度比較

MVTecADのデータセットを対象として精度比較を実施

※Pre-Trained Classifierはモデルの上限を知るために、全データを用いた教師あり二値分類問題を解いたものなので、無視して大丈夫

f:id:okehara_aoi:20201014185120p:plain

全カテゴリのAUROC平均で比較すると、当時SoTAだったSPADEと比較して10ポイント近く更新してSoTAを達成したとのこと。

PapersWithCodeで見ると現在のSoTAがDifferNetで94.9%なので、それよりもいいみたい。

めでたし、めでたし!

最後にカテゴリごとの精度を確認

f:id:okehara_aoi:20201014185227p:plain

カテゴリ ごとの結果は上記、PillやScrewと行った小さくて対称性の高いタスクは苦手な感じがありそう

今後の展望

  • 元になるモデルを異常検知タスクに関してfine tuningすることで予測精度のさらなる改善がはかれそう

  • 今回の提案した手法をマルチモーダルな異常検知に応用したい

まとめ

  • 学習済みのdeepなfeature representationを異常検知タスクで利用できるようにした

  • 正常データのfeature representaionに多変量ガウス分布を当てはめ、そこからのマハラノビス距離を異常度として定義したモデルでMVTecの異常検知タスクを解いたところ、SoTAを達成

  • feature representationをPCAにかけ次元削減したモデルの精度をみることで、学習済みモデルに正常データを食わせた結果得られるfeature representationにおいて分散の小さいデータが異常検知タスクにとって重要という知見を獲得

リンク

Modeling the Distribution of Normal Data in Pre-Trained Deep Features for Anomaly Detection
byungjae89/MahalanobisAD-pytorch(論文の実装)
A Simple Unified Framework for Detecting Out-of-Distribution Samples and Adversarial Attacks