元生技のデータサイエンティストのメモ帳

勉強したことの備忘録とか雑記とか

RAGのSurvey論文からRAG関連技術を俯瞰する

大規模言語モデル (LLM) の学習データに含まれない知識（各社の特有の書類など）を踏まえてLLMに回答させる際に最早必須となってきたRAG (Retrieval-Augumented Generation)。

今回はそんなRAGのSurvey論文を元に、RAGの変遷や構成要素、新たに出てきた技術を俯瞰していきます。

Survey論文へのリンクはこちら

arxiv.org

RAGとは

LLMはそれ単体で回答させると、質問によってはハルシネーションや学習時のデータにはなかった情報を生成時に加味できないといった問題から正しくない回答を生成することが多々あります。例えば世間一般に公開されていない自社の就業規則や業務標準についてをChatGPTに質問しても、正しい回答は得られません。

そのような問題への対応としてRAGが使われます。

「LLM単体で適切な回答を生成できないなら、ユーザーの質問を元にデータベースを検索し、その検索結果を基に回答させる」というような方法が取られます。こうすることで、LLMの学習データに情報がない質問に対しても適切に回答できるようになります。

なおこの論文のAbstractではRAGは以下のように説明されており、上記と同様のことが言われています。

Large Language Models (LLMs) showcase impressive capabilities but encounter challenges like hallucination, outdated knowledge, and non-transparent, untraceable reasoning processes. Retrieval-Augmented Generation (RAG) has emerged as a promising solution by incorporating knowledge from external databases. This enhances the accuracy and credibility of the generation, particularly for knowledge-intensive tasks, and allows for continuous knowledge updates and integration of domainspecific information.

Prompt engineering と RAG と Fine-tuning

この手の話をする際によくRAGと比較されるのがPrompt engineeringとFIne-tuningです。
この論文にも「RAG vs Fine-tuning」という節があり、詳しく説明されています。

まずPrompt engineeringについては「モデル固有の能力を活用するためのもの」とされています。例えば「あなたはプロのコピーライターです」とプロンプトの冒頭に付け加えると付け加えない場合より良いキャッチコピーが出力されたり、「小学生にもわかるように説明してください」とプロンプトの冒頭に付け加えると平易な言葉で説明してくれたり、というようなことがここに含まれます。ここではLLMが持っていない知識をプロンプトに入れることは含まれていません。

RAGは「情報取得用に調整した教科書をLLMに与える」と例えられています。質問に回答する際に、カンペを見ながら回答するようなものとも言えます。

一方Fine-tuningは「学生が時間をかけて知識を内面化していくようなもの」とされています。テストに向けて勉強を頑張るようなものと言えます。Survey論文内では「Fine-tuningは特定の構造、スタイル、フォーマットの再現を必要とするシナリオに適している」とされています。具体的にいうと、以下のブログで「LLMの出力を "ござる" 口調や、シェークスピアの文体に調整する」という事例が紹介されており、このような事例が当てはまると思います。

note.com

RAGとFine-tuningの比較において最も気になるのが「どちらの手法が、事前学習にない情報に関する質問に回答できるか」ということだと思います。これに関してはSurvey論文で紹介されているこちらの論文では「教師なしFine-tuningが（Fine-tuning前のモデルと比較して）若干の改善を示す一方で、RAGは、事前学習中に遭遇した既存の知識と全く新しい知識の両方に対して、一貫してFine-tuningのモデルの性能を上回ることを明らかにした」としています。

RAGの方がFine-tuningよりも高い性能を出せるとのことですが、だからといってFine-tuningが不要というわけではありません。Survey論文中でも「RAGとFine-tuningを組み合わせて使用することで、最適なパフォーマンスが得られる場合もある」とされており、後述するModular RAGや下図のようにRetrieverなどのFIne-tuningをRAGと組み合わせることにより、より高度なものにできるとのことです。

RAG の移り変わり

RAGは下図のように "Naive RAG", "Advanced RAG", "Modular RAG" のように変遷してきました。
それぞれの違いを説明していきます。

Naive RAG について

一番左の "Naive RAG" は最も単純な構造で、索引付け (indexing)、検索 (retrieval)、生成 (generation) の3つからなり、"Retrieve-then-Read" とも呼ばれます。単純に「RAG」というと、この方式を思い浮かべる人が多いと思います。

3つの処理を説明します。

索引付け (indexing) ではPDF、HTML、Word、Markdownなどのファイルからプレーンなテキストを抽出し、LLMが受け付けられる長さに分割し、Embeddingモデルでベクトル化などの検索時に役にたつ情報を取得する処理を実施してデータベースに保存します。

検索 (retrieval) ではユーザーからの質問をもとにデータベースを検索し、検索にヒットしたトップ数件をプロンプトに取り込みます。検索方法には全文検索やベクトル検索などあるのですが、Survey論文ではベクトル検索を使うことが前提となっているようです。
（検索方法の違いはそれに特化して紹介しているブログ記事がたくさんあるのでそちらに譲ります。）

生成 (generation) では事前に設定されている固定のプロンプトテンプレートにユーザーからの質問と検索にヒットしたテキストを流し込んで、それをもとにLLMにユーザーからの質問に対する回答を生成させます。

このような処理により、質問に回答するのにLLMの学習データに一切情報がなくても回答できるようになるわけですが、Naive RAGには以下のような欠点があるとされています（元々LLMが内包している問題も含まれます）。

  • 検索の課題
    • 欲しいテキストが検索にヒットするとは限らない
    • 無関係なテキストがかり検索にヒットすることがある
  • 生成の課題
    • 検索結果にないことを生成する (Hallucination)
    • 毒性、偏りの問題
  • 補強 (Augumentation) の課題
    • 異なるソースから検索した結果を統合すると、回答が支離滅裂になることがある
    • 同じような情報が複数ソースから検索にヒットした場合、回答が冗長になることがある

Advanced RAG について

上記のようなNaive RAGの欠点を克服するために改良されたものが "Advanced RAG" とされています。
具体的にはNaive RAGの処理に対して、検索の前処理 (Pre-Retrieval) と後処理 (Post-Retrieval) が追加されています。

まず検索の前処理に関してです。Survey論文内のFig.3を見ると、検索の前処理はユーザーからの質問 (Query) に対する処理のみが対象になっているように見えますが、本文では索引付け (indexing) もここに含まれるとされています。
索引付け (indexing) に対する処理としては、インデックスされるコンテンツの質を高めるために以下のことが行われます。

  • データの粒度の改善
  • インデックス構造の最適化
  • メタデータの追加
  • アライメントの最適化
  • 混合検索

ユーザーからの質問 (Query) に対する処理としては、ユーザーの元の質問をより明確にし検索タスクに適したものにする以下のことが行われます。

  • クエリの書き換え
  • クエリの変換
  • クエリの拡張 （箇条書きで書いた手法の詳細は、後ろの章で詳しく説明します）

続いて検索の後処理に関してです。ユーザーからの質問（クエリ）にうまく回答するには、検索結果とクエリをうまくくっつける必要があります。そのために以下のことが行われます。

  • 検索結果のリランク（並び替え）
  • 検索結果の圧縮 （前処理と同様に箇条書きで書いた手法の詳細は、後ろの章で詳しく説明します）

Modular RAG について

Modular RAGはこれら2つのRAGの手法をさらに進化させ、適応性を汎用性を高めたもの、と表現されています。

Modular RAGは以下に示すようなモジュールを新たに取り込んでいます。

Searchモジュール

SearchモジュールはLLMが生成したコードやクエリを使って検索エンジンやデータベース、ナレッジグラフなど様々なデータソースを直接検索できるようにしてくれます。具体的な手法としてRAG Fusionが紹介されており、元のクエリをLLMに言い換えさせたものを複数生成して複数の検索を実行し、結果をリランクして利用する、ということが可能になります。

Memoryモジュール

MemoryモジュールはSurvey論文内での説明がわかりにくいので、引用されている論文を確認すると以下の説明がありました。

この論文で紹介されているSelf Memoryという手法では、LLMが応答生成時にユーザーからの質問に類似するものを会話履歴から引っ張ってくることでより良い回答を生成できるようになります。RAGで生成したものを下図のMemory sectorに入れておき、以降の生成時にユーザーのクエリに類似するものをMemory sectorから取り出して、それを使ってLLMが回答できるようにしているようです。これにより「会話履歴を全て与えなくても良い」となるのは大きいですね。
論文ではSelf Memoryによって、機械翻訳タスク、テキスト要約、対話生成の3つのタスクで性能改善が見られたとのことでした。

「これまでの会話履歴を検索できるようにする」というのは、RAGの性能向上に役立つそうです。

Routingモジュール

Routingモジュールでは、ユーザーのクエリから多様なデータソースのうちどこから調べるのが最適かをナビゲーションしてくれるとのことです。

Predictモジュール

Predictモジュールでは生成時に参照するコンテキストを検索するのではなく、「LLMで生成する」と説明されています。これによって冗長な情報やノイズを減らしつつ、クエリに対する関連性と正確性が高いコンテキストを生成できるとのことです。

引用されている論文によると、一般的なNaive RAGが"Retrive-then-Read"なのに対してこの手法を"Generate-then-Read"と表現しています。
この手法ではLLMにユーザーのクエリの関連文書を読ませて質問の回答になる部分を要約させ、その要約をもとにクエリに回答させます。論文では下図のクラスタリングベースの手法が最も効果的だったとのことです。 TriviaQAやWebQなどのオープンドメイン質問応答タスクで実験を行い、GenReadが最先端の検索して読むパイプラインを上回ったとのことです。
有効な手法ではありますが、関連文書全体をLLMに読ませる都合上、時間もお金もかかりそうな印象ではあります。

Task Adapterモジュール

Task Adapterモジュールは、ユーザークエリに含まれるタスクに合わせて使用するプロンプトを事前にプールしたものから取得し、プロンプトを動的に変えて処理を実行できるようにしています。

ここで引用されている論文では下図のような構造でユーザーからのInput（クエリ）に応じてプロンプトプールから適切なプロンプトを取得するためのEncoderを学習させる方法が紹介されています。

ここでは下式で算出されるLossでEncoderを学習させているとのことです。

これによって読解やClosed-book QA、言い換え検出などのタスクでゼロショットよりも性能を大きく向上できたと報告されています。また言語推論やコモンセンス推論などのタスクでは限られた改善しか見られなかったとされています。

その他の機能

上記のモジュール以外にもさまざまなRAGの機構が紹介されています。

  • Rewrite-Retrieve-Read:
    強化学習を使ってクエリを書き換えるSLMを学習させ、検索性能向上を図る
    論文
  • Recitation-Augmented Generation:
    LLM内部の知識を引用して回答を生成する
    論文
  • Hypothetical Document Embeddings (HyDE):
    ユーザーのクエリでなくLLMが生成した「仮想的な想定回答」に類似するテキスト探すことで検索性能向上を図る
    論文
  • Demonstrate–Search–Predict(DSP):
    言語モデルと検索モデルを統合し、複雑な問題を小さな問題に分解して処理する
    論文
  • ITER-RET-GEN:
    検索と生成を反復的に行うことで、より関連性の高い知識を取得し、生成結果の精度を向上させる
    論文
  • Forward-Looking Active REtrieval augmented generation (FLARE):
    生成過程で必要な情報を動的に検索することで、言語モデル（LM）の精度とハルシネーションを抑える。生成された用語の確率によって示される生成プロセスの信頼性を監視することによって、タイミング検索を自動化している
    論文
  • Self-Reflective Retrieval-Augmented Generation (Self-RAG):
    検索と自己反省を通じて必要に応じて生成の途中でも検索を行い、生成の品質を高める手法。“reflection tokens”を追加することでこれを実現している
    論文

中でも検索を動的に実施するFLAREやSelf-RAGは、従来の固定的な処理しかできないRAGよりも良い性能が得られるのではないかと感じました。このような柔軟なアーキテクチャを扱い始めると、RAGだけでなくFine-tuningや強化学習などの他の技術との統合が重要になりそうです。

Retrievalについて

この章ではRAGの要、Retrieval (検索) についてが紹介されています。

検索データのソース

データ構造

検索対象のデータの構造は、非構造化データ（テキスト）から半構造化データ（PDFなど）、構造化データ（ナレッジグラフなど）に移り変わってきています。
半構造化データの課題の1つはRAGを頻繁に扱っている人にはお馴染みの問題かと思いますが、テキストの分割処理で表が途中で分割されて意味をなさなくなってしまうことです。もう1つの問題は表データを組み込むとセマンティック検索における類似性が複雑になってしまうことです。
これに関してSurvey論文内ではTableGPTのようなデータベース内のテーブルに対してText-2-SQLクエリを実行するLLMのコード機能を活用するアプローチ紹介されていますが、同時に「これでも最適な解決策とは言えず、研究の余地がある」としています。

構造化データとして紹介されているナレッジグラフ (KG) とRAGを統合した例としては、KnowledGPT や、グラフニューラルネットワークと統合したG-retriever が紹介されています。ナレッジグラフのような構造化データを使用することはRAGの回答の正確性向上には貢献しそうですが、構造化データベースの構築から維持に多大な労力が必要となることが問題になっているそうです。この辺りが手軽に使えればより便利になりそうです。

LLMがモデル内に保有している知識を、LLMが生成したテキストなどを通してRAGに活用する方法も紹介されています。前述のGenerate-then-Read やSelf Memoryの他、Self-knowledge guided retrieval augmentation (SKR) が挙げられています。

検索の粒度

検索にヒットするテキストの単位を長くすると余計な部分が多くて冗長になってしまうが、短くすると説明が途中で途切れて文章の意味が通らなくなってしまうという問題があるため、適切な単位で分割する必要があります。

Suervey論文内では分割の単位として、Token、Phrase、Sentence、Proposition、Chunks、Documentなどが挙げられています。Dense X では「どの単位で分割するのが良いか」を深掘りしており、その論文内ではProposition（命題）単位で区切って検索単位として処理するのが良い、と結論づけられています。個人的にはToken単位の分割しかちゃんとは試したことがなかったため、詳細が非常に気になるお題です。
KGにおいても検索粒度は重要とのことで、エンティティ、トリプレット、サブグラフが含まれるとのことです。

Index最適化

検索indexへのデータ格納時に気をつけるべきことがまとめられています。

Chunking

最も一般的な方法はテキストを一定の長さのtokenごとのchunkに分割することです。

問題となるのは「どれだけの長さごとに分割するか」で、chunkを大きくすると多くの情報を捉えられるもののノイズとなる情報も多くなり、chunkを小さくすると必要な情報を十分に盛り込めません。
また一定の長さでchunkを区切ると文の途中で途切れるため、chunk間でオーバーラップさせる対応が必要である。それでも不十分なことからSmall2Bigという文（small）を検索単位として使用し、前後の文を（big）コンテキストとして生成に使用する手法が提案されているそうです。

メタデータの付与

検索時にフィルタリングや範囲を指定するために、ページ番号、ファイル名、著者名、タイムスタンプなどのメタデータを活用できます。 またタイムスタンプに重みをつけることで、新しい情報を検索にヒットさせやすくする、というようなこともできます。

元のテキストに対して「段落の要約」や「想定QA」を生成して付与するような方法も紹介されています。

Indexの構造化

ファイルに親子関係がある場合、階層化index構造としてそれを活用することでどのchunkを抽出すべきか決める際の役に立つそうです。
またドキュメントの階層構造を構築するのにナレッジグラフを活用する方法も紹介されています。これにより異なる概念やエンティティ間のつながりを明確にし、錯覚の可能性を著しく低減する効果や、情報検索プロセスをLLMが理解できる命令に変換することで、知識検索の精度を高め、LLMが文脈的に首尾一貫した応答を生成できる効果があるそうです。

Survey論文内ではKnowledge Graph Prompting (KGP)という手法というナレッジグラフを活用して多文書質問応答に対応する手法が紹介されています。
RAGにおいて複数の文書から回答を生成したい場面によく出くわすので、詳しく読んでみたい論文です。

クエリ最適化

Naive RAGの課題の1つは、検索性能がユーザーからのクエリに左右されるということです。
ユーザーは常に明確で正確に質問を書いてくれるとは限りません。ユーザーは「何かがわからない」からこそ質問しているわけなので、質問内容が曖昧なことの方が多いのではないかと思います。
また前提なく略語を使うことも、混乱を招く一因となります（法律の文脈では「LLM」は「Master of Laws」になるのだとか）。

この章ではそのような問題への対応策が書かれています。

クエリの拡張

クエリを拡張する（言い換える）ことで、文脈を補強できることがあります。 以下の3つの方法が紹介されています。

  • Multi-Query:
    LLMによるクエリの言い換え
  • Sub-Query:
    複雑な問題を小さくて簡単な問題に分割し、小さい問題に対する回答を1つ1つ作ってから組み合わせて最終的な回答を生成する
    論文
  • Chain-of-Verification(CoVe):
    LLMが自分の生成した回答を検証し、誤りを訂正するプロセスを導入する。回答を検証するプロセスで「回答のチェックポイント」をLLMが設定して検索して確認する方式のため、ここに入れられていると思われる
    論文

クエリの変換

「クエリの拡張」との違いが微妙なところですが、以下の手法が紹介されています。

  • Rewrite-Retrieve-Read:
    強化学習を使ってクエリを書き換えるSLMを学習させ、検索性能向上を図る。「SLMを学習させる」点がクエリ拡張と異なる点か（再出）
    論文
  • Hypothetical Document Embeddings (HyDE):
    ユーザーのクエリでなくLLMが生成した「仮想的な想定回答」に類似するテキスト探すことで検索性能向上を図る（再出）
    論文
  • Step-back Prompting method:
    元のクエリを抽象化し、上位概念の質問をLLMに生成させて回答する。質問の背景知識や必要な物理現象を問うような質問が生成される 論文

クエリのルーティング

クエリによって異なるRAG パイプラインにルーティングすることで、多様なシナリオに対応できるようになります。
そこまで詳しく説明がないですが、以下の2つの方法が紹介されています。

  • Metadata Router:
    クエリからキーワードを抽出し、そのキーワードとチャンク内のメタデータでフィルタリングを実施し、検索範囲を絞り込む手法
  • Semantic Router:
    クエリの意味的な情報をを使って検索範囲を絞り込みます。Survey論文で紹介されているgithubのrepositryを見る限り、事前にRouting先（どんな話題に分類してほしいかと、その例の文章）を先に定義しておいて、Embeddingモデルを使って事前に定義した文章とクエリの類似度から「どの話題に分類するか」を決めているようです

Embedding

ここではEmbeddingによるベクトル化の他、BM25などを使った全文検索やBERT系のモデルを使ったセマンティック検索との組み合わせの話が書かれています。
Embeddingモデルの性能比較に関しては、HuggingfaceのMTEBリーダーボードがおすすめとのことです。

ハイブリッド検索

全文検索やベクトル検索などの比較的計算量の軽い検索方法で絞り込んでから、BERT系のモデルリランクするようなハイブリッド検索が紹介されています。
Survey論文ではあまり詳しく説明されていないので、この辺りは他の詳しいドキュメントをあたるのが良いかと。

EmbeddingモデルのFIne-tuning

法律や医療のように専門用語が多く、事前学習のコーパスと大きく乖離している場合、独自のドメイン特化のデータセットでEmbeddingモデルをFIne-tuningすることが不可欠です。
社内独自の用語が多い場合もここに当てはまるでしょう。

以下のようなEmbeddingモデルのFIne-tuningの手法が紹介されています。

  • Promptagator:
    少数の例からクエリを生成し、それを基にリトリーバーを訓練することで、タスク固有のデータを用いずに高精度な検索を実現
    論文
  • LLM-Embedder :
    報酬の最適化、知識蒸留、タスクごとの微調整、同一バッチ内の負例サンプリングなどの最適化手法を導入し、従来のタスク固有または汎用的なリトリーバーに対して、統一されたEmbeddingモデルを実現
    論文
  • RePlug:
    外部コーパスから関連ドキュメントを検索し、それを言語モデルの入力に追加し、言語モデルのフィードバックを利用して検索モデルをチューニング。言語モデルを教師信号として扱い、特別なクロスアテンションメカニズムを不要に
    論文

Adapter

タスクへのアライメントのためにLLMをFine-tiningするには様々な制約があるので、外部Adapterを組み込むというアプローチが取られることもあります。
以下のような手法が紹介されています。API経由で利用する高性能なLLMを「ブラックボックス」なものとして扱い、オープンソースのモデルをFine-tuningすることで回答の根拠に透明性を持たせようとする手法が多いように見受けられます。

  • Universal Prompt Retrieval for Improving zero-Shot Evaluation (UPRISE):
    ユーザーからのInput（クエリ）に応じてプロンプトプールから適切なプロンプトを取得するためのEncoderを学習させる（再出）
    論文
  • Augmentation-Adapted Retriever (AAR):
    複数のダウンストリームに対応できる、ユニバーサルアダプターを学習させる手法。未知タスクも含め、ゼロショットタスク入力に適したプロンプトを事前に構築されたプロンプトプールから自動的に取得することができる
    論文
  • Pluggable Reward-Driven Contextual Adapter (PRCA):
    Retrieverが検索してきたコンテキストを回答を生成するLLMに渡す際にどう圧縮するかを、「コンテキスト抽出段階」と「報酬駆動段階」の2段階で学習する。文脈抽出段階ではCNN Daily Mail datasetで BART-Large（BERTではない）を事前学習したモデルを使用し、報酬駆動段階では強化学習で最終的な回答がよくなるように学習する。報酬は生成された回答と正解データのROUGE-Lスコアを使用している。検索された情報を改良するAdapterとして紹介されている
    論文
  • Bridging the Gap between retrievers and LLMs (BGM):
    人間にとって有用な情報とLLMにとって有用な情報にギャップがあることを加味して作られた、RetrieverとLLMの間の嗜好のギャップを埋めるための橋渡しモデル。検索結果をLLMが効果的に利用できる形式に変換する
    論文
  • Parametric Knowledge Guiding (PKG):
    オープンソースのモデル (LLaMa 7B) をFIne-tuiningし、ブラックボックスだがより高性能なLLMに渡す情報を適切に加工する
    論文

Generationについて

検索にヒットしたものを全てを回答を生成するLLMのインプットとするのは良くありません。
この章では「検索結果の調整」と「LLMの調整」の2つの観点で改善方法が紹介されています。

検索結果のキュレーション

LLMのインプットとする文章が冗長だと、回答に必要な情報を見失ってしまうことがあることが指摘されています。
こちらの論文 では、gpt-3.5-turbo-0613で長いテキストの最初と最後の情報にばかり注目し、途中の情報をうまく活用できないことが指摘されています。

このことから「検索された文章の処理」が重要となります。

リランキング

検索結果をリランキング（再順位付け）する方法が紹介されています

  • Open-source Large Language Models are Strong Zero-shot Query Likelihood Models for Document Ranking:
    LLaMA-7BやFalcon-7Bを活用したリランキング（ゼロショット）
    論文
  • DiversityRanker:
    検索結果の多様性を高める手法。上位に選択済みのコンテキストの埋め込みの平均との類似度が低いものを順に入れていく
    リンク
  • LostInTheMiddleRanker:
    前述の「LLMが長いテキストの最初と最後の情報にばかり注目してしまう」性質に対応するために、コンテキストの最初と最後に検索結果の上位を入れる手法。 10 個のドキュメントを並べ替える場合、 [1 3 5 7 9 10 8 6 4 2] という順番になる
    リンク

Contextの選別・圧縮

ここではまず、「RAGプロセスでよくある誤解は、できるだけ多くの関連文書を検索し、それらを連結して長い検索プロンプトを形成することが有益であると考えることである」と断言されています。
ここ最近で受け付けられるコンテキスト長が膨大なLLMが出てきており、「検索対象のドキュメントをすべて入れればいいのではないか」という意見を身の回りで聞くようになり違和感を覚えていたのですが、ここでこれだけそのように断言されているのは興味深いです。

過剰なコンテキストはノイズとなりLLMが重要な情報を認識できなくなるので、ノイズを減らすことが重要であり、以下のような手法が紹介されています。

  • LongLLMLingua:
    GPT-2 SmallやLLaMA-7Bのような小さな言語モデル（SLM）を利用し、重要でないトークンを検出して削除し、人間には理解しにくいがLLMにはよく理解できる形に変換する。入力が「∼4x fewer tokens」になったとのこと
    論文
  • Pluggable Reward-Driven Contextual Adapter (PRCA):
    Retrieverが検索してきたコンテキストを回答を生成するLLMに渡す際にどう圧縮するかを、「コンテキスト抽出段階」と「報酬駆動段階」の2段階で学習する。文脈抽出段階ではCNN Daily Mail datasetで BART-Large（BERTではない）を事前学習したモデルを使用し、報酬駆動段階では強化学習で最終的な回答がよくなるように学習する。報酬は生成された回答と正解データのROUGE-Lスコアを使用している。（再出）
    論文
  • RECOMP (Retrieve, Compress, Prepend):
    検索にヒットしたものから関連する文を選ぶ「抽出型コンプレッサー」と検索にヒットした複数の文書から要約を生成する「要約型コンプレッサー」の二つを導入し、ドキュメントを要約して必要な情報のみを抽出する。LLMに渡す検索結果のtoken数を1/10以下にしつつ、同等以上の回答品質が実現できているとのこと
    論文
  • Dense passage retrieval for open-domain question answering:
    BERTを活用したベクトル検索
    論文
  • Filter-Reranker:
    SLMが簡単なサンプルをフィルターし、LLMが難しいサンプルをリランキングする手法。「Fine-tuningしたSLMの方がLLMよりも高性能なタスクはSLMにさせる」という思想で作られている
    論文
  • ChatLaw:
    最終的な答えを生成する前に、LLMに検索にhitしたコンテンツを評価させる手法。法的分野におけるモデルの信頼性と性能を向上できたとのこと。
    論文

FIne-tuning

LLMの使われ方と想定されるデータの特性に基づいてターゲットを絞り込んでFine-tuningすることで、より良い結果を得ることができる。
LLMに知識を追加したり、入手力の形式を調整できる。

  • Retrieval-Augmented Generative Question Answering (R-GQA):
    クエリに類似するQAペアを学習データセットから検索し、それをプロンプトとして使用する。これにより類似したデモンストレーションから推論できるようになっている。
    （この章で紹介されているが、Fine-tuningでなくFew-shot learningである）
    論文
  • Structure Aware Dense Retrieva (SANTA framework):
    構造化データの効果的な検索を実現するために、事前学習でStructured Data Alignment (SDA) とMasked Entity Prediction (MEP) が用いられる。SDAではmask language modelingだけでは不十分な構造化データを理解できるようになるために、contrastive learningを行い構造化データを非構造化データにアラインさせる。MEPでEntityをマスクし、マスクされた部分を埋めるように継続学習を行う
    論文
  • Dual-Feedback Knowledge Retrieval for Task-Oriented Dialogue Systems:
    RetrieverとGeneratorを分離し、Generatorからのフィードバック（ポジティブフィードバック・ネガティブフィードバック）を使ってRetrieverの学習を行う。ポジティブフィードバックは、検索にhitしたそれぞれのエンティティに対応する応答の条件付き生成確率に基づいて算出される（あるEntityと応答の関連性が高ければ、このEntityに対応する応答の条件付き生成確率も高くなる）。ポジティブフィードバックを利用することで、参照応答からGeneratorが学習した知識に基づいて、Retrieverの学習を行える。ジェネレーターの仮説応答からサンプリングしたネガティブサンプル（高い生成確率を示すが質の低い応答、質はBLEUで算出）に基づいてネガティブフィードバックを構築し、正のフィードバックをキャリブレーションする。
    論文
  • Retrieval-Augmented Dual Instruction Tuning (RA-DIT):
    LLM (Generator) とRetrieverを別々にfine-tuningする。LM-ftでは検索で補強されたプロンプトによる命令が与えられたときの正解の尤度を最大にするようにLLMを更新し、R-ftではRetrieverの確率分布とLLMの出力の確率分布との間のKL-ダイバージェンスを最小にするようにRetrieverを更新する（LLMが正解を生成する可能性を向上させるチャンクにより高いスコアを割り当てられるようになる）
    論文

上記の他にGPT-4などの強力なモデルの出力を蒸留するのも効果的と紹介されています。
（https://openai.com/ja-JP/policies/terms-of-use/的に大丈夫か、というのはありますが。。「OpenAIと競合するモデル」の定義次第か。。）

RAGにおけるAugmentationプロセスについて

RAGの標準的な手法は多くの場合一度だけ検索してそれを基に生成するが、これだと限られた情報しか引き出せず、他段階の推論が必要となる複雑な問題に対して不十分となります。ここでは以下の3つの方法が紹介されています。

Iterative Retrival

Iterative Retrivalは最初のクエリとこれまでに生成されたテキストに基づいてデータベースを繰り返し検索するプロセスです。

何度も検索を繰り返すことで、追加の文脈参照を提供し、その後の回答生成の頑健性を高めることが示されています。
こちらの論文では、Iterative Retrieval-Generation Synergy (Iter-Ret Gen) という検索と生成の反復によって大規模言語モデル（LLM）の性能を向上させる手法が紹介されています。
この手法では生成された内容を基に追加の関連情報を検索し、それを次の生成に活用するプロセスを繰り返すことで回答に必要な情報を充実させ応答の質を向上させています。

Recursive Retrieval

Recursive Retrievalでは以前の検索で得られた結果に基づいて、検索クエリを繰り返し改良していきます。
このようなフィードバック・ループを通じて最も適切な情報に徐々に収束させることを目的としています。
具体的な手法としては、以下が紹介されています。

  • Interleaving Retrieval with Chain-of-Thought Reasoning (IRCoT):
    検索と検索結果を基にしたChain of Thoughtによる検索クエリの改善を繰り返す手法。生成されたCoT文が "answer is: "の文字列を持つか、最大ステップ数4に達したら処理を終了する
    論文
  • Tree of Clarifications (ToC):
    あいまいな質問を明確化するための質問の木を再帰的に構築し、回答を生成する手法。有用でない枝を刈り込む仕組みも取り込まれている
    論文
  • Chain-of-Knowledge:
    固定された知識ソースを使用するのではなく、CoKは異なる知識ソースを動的に適応させ、特定のドメインに関連する知識を効果的に取得する。これを実現するために推論準備（関連する知識領域の特定とCoTによる仮の回答生成）、動的知識適応（検索結果を活用した回答の修正）、回答統合の3つの段階からなる
    論文

Adaptive Retrieval

これまでの2つの手法よりも、外部からの知識検索が必要かどうか、いつ検索と生成を停止するかをRAGシステムが自律的に判断できることに重点が置かれています。
ここでは以下のような手法が紹介されています。

  • Forward-Looking Active REtrieval augmented generation (FLARE):
    生成過程で必要な情報を動的に検索することで、言語モデル（LM）の精度とハルシネーションを抑える。生成された用語の確率によって示される生成プロセスの信頼性を監視することによって、タイミング検索を自動化している（再出）
    論文
  • Self-Reflective Retrieval-Augmented Generation (Self-RAG):
    検索と自己反省を通じて必要に応じて生成の途中でも検索を行い、生成の品質を高める手法。“reflection tokens”を追加することでこれを実現している（再出）
    論文
  • AutoGPT:
    個々の行動ステップごとに「思考」、「推論」、「計画」、「批評」を生成することで自己モノローグ行え、簡単な指示といくつかのツールの使用例によって、様々なツールを活用でき、長期的な自己記憶と記憶検索が組み込まれているエージェント。人間からのステップバイステップのガイダンスを必要とせず、目標の定義や道具の説明をするだけでタスクをこなせる
    論文
  • Toolformer:
    言語モデルが直接外部ツールの使用方法を学習できる手法。使わせたいtoolを呼び出すspecial tokenを新たに追加し、事前学習データ内に挿入する（位置の候補は言語モデルに選ばせる）。挿入後「tool有無によって次token予測のlossが一定以上減少したかどうか」を確認し、lossが現象したspecial tokenのみを残し、事前学習に使用する。これにより、言語モデルが文章生成中に必要に応じてtoolを使えるようになる
    論文
  • GraphToolformer:
    ChatGPTによってさまざまなドメインからの入力グラフデータと簡単な手順を含むfew-shotプロンプトにより、外部グラフ推論ツールのグラフ推論 API 呼び出しを含む大規模なプロンプトデータセットに注釈を付けることで、LLMに対してグラフデータに関する推論能力を付与する手法。検索プロセスを明確なステップに分け、LLMが積極的にRetrieverを使用し、Self-Ask技術を適用し、検索を開始するためにfew-shotプロンプトを使用する。これによりLLMは必要な情報を検索するタイミングを自分で決められるようになる
    論文
  • WebGPT:
    GPT-3モデルをテキストベースのウェブブラウジング環境で行動模倣学習、報酬モデリング、強化学習、およびリジェクションサンプリングを組み合わせてfine-tuningし、GPT-3が検索の実行、リンクのクリック、スクロールなどを実行できるようになる
    論文

タスクと評価

タスクとデータセット

下表のようなタスクとデータセットが紹介されています。

評価指標

どのようなことを評価かによって適している評価指標が異なります。
このSurvey論文では以下の表にまとめられています。

Discussion・今後の課題

RAG VS Long Context

LLMの研究開発が進むにつれ、LLMが入力として受け付けられるtoken数が増加しています。
Gemini 1.5は100万ものtoken処理できることで話題を呼んでいます。

ここまで長大なtokenを入力できるようになると「RAGは本当に必要なのか、検索対象の文書を全て入れればいいのではないか」という議論を呼んでいます。
議論は盛り上がるものの、まだRAGはなくなっていません。というのも「検索対象の文書全てをLLMの入力とする」という行為には以下のデメリットがついてくるからです。

  • 推論速度の低下
    （RAGは検索にhitしたもののみを処理するので、素早く推論できる）
  • 生成ログを見ても「何を基に回答したか」がわからない
    （RAGは検索結果を見れば絞り込める）

一方でこちらの論文によると「コンテキストの拡張はRAGの開発に新たな機会を提供し、より複雑な問題や、回答するために大量の資料を読む必要がある統合的または要約的な質問に対処することを可能にする」とされていて、今後の更なる研究が待たれる話題です。

RAGの頑健性

検索中にノイズや矛盾する情報が存在すると、RAGの出力品質に悪影響を及ぼす可能性があり、この状況は「誤った情報は、全く情報がないよりも悪いことがある」と呼ばれるとのことです。
このような事態への対応として、敵対的または反事実的な入力に対するRAGの耐性を向上させるための研究が盛んになっています。
Survey論文では以下の研究結果や手法が紹介されています。
最後の論文の結果が直感と反しており、更なる研究が待たれます。

  • Chain-of-Note (CoN):
    取得したドキュメントの関連性を評価し、信頼できる情報を特定する手法
    論文
  • Making retrieval-augmented language models robust to irrelevant context:
    自然言語推論（NLI）モデルを用いて不要なコンテキストを識別し、ファインチューニングによってモデルが不要な情報を無視するようにした手法
    論文
  • Knowledge-Augmented Language Model Verification:
    言語モデルが生成する回答を外部のKnowledge baseと照合し、その正確性を評価し、Knowledge baseからの情報を基に、回答を補強または修正する手法
    論文
  • The Power of Noise: Redefining Retrieval for RAG Systems:
    クエリに関連性のない文書が生成結果に与える影響を評価した論文。関連性のない文書を含めると、予想に反して30％以上も精度が向上するとのこと。
    論文

ハイブリッドアプローチ

RAGとFine-tuningの組み合わせは、有力な戦略として浮上しています。
前述のRA-DITのようにLLM (Generator) とRetrieverを別々にfine-tuningする手法のほか、こちらの論文ではSLMが取得された文書の品質を評価し、必要に応じて外部のウェブ検索を利用して情報を補完できるようにFine-tuningするCRAGという手法が紹介されています。

RAGにおけるScaling laws

End-to-EndなRAGモデルやRAGに基づく事前学習済みモデルが出てきていますが、そこにもScaling lawsが成立するのかはまだ不確かとこのSurvey論文内ではされています。
Retro++が「この分野の初期の取り組み」として取り上げられていますが、RAGモデルのパラメータ数はまだまだ小さいとされています。

Production-ReadyなRAG

まずRAGは実用的だが、「LLMによる文書ソースやメタデータの不用意な開示の防止といったデータセキュリティの確保」が解決すべき重要課題と指摘されています。
またRAGにおける重要なツールやライブラリとしてLangChainやLLamaIndexのほか、Flowise AIのようなローコードツールやHayStack、Meltano、Cohere Coralなどが紹介されています。

ソフトウェアプロバイダーやクラウドサービスプロバイダーがRAGを中心としたサービスを拡大していることも紹介されています。
RAGの技術開発においては、以下の方向性があるとされています。

  • 特定の要件に合わせてRAGをカスタマイズ
  • RAGを使いやすくし、最初の学習コストを減らす
  • RAG を最適化して、実稼働環境でのサービス向上

インフラ等の技術スタックの技術革新がRAG技術の促進を促していく点も指摘されています。

Multi-modal RAG

近年テキストの他のmodal（特に画像）を取り込む研究が盛んになっています。
Survey論文内では以下の技術が紹介されています。

Image

  • Retrieval-Augmented CM3 (RA-CM3):
    CLIPを使用したMulti-modal検索と、LAIONデータセットで学習したCM3 Transformerを組み合わせ、取得したドキュメントを用いてテキストと画像の生成する手法
    論文
  • BLIP-2:
    事前学習済みの画像エンコーダと大規模言語モデル（LLM）を用いて、視覚と言語の事前学習を効率化する手法。ゼロショット画像からテキストへの変換を可能にしている
    論文
  • Visualize Before You Write:
    生成するテキストに一貫性を持たせる目的で、テキスト生成前に画像を生成させてそれに基づいてテキストを生成する手法
    論文

Audio と Video

  • Generating Synthetic Speech (GSS):
    End-to-Endの音声翻訳システムの学習のために、SpokenVocabを用いて機械翻訳データを音声データに変換する手法。SpokenVocabは事前に用意した音声辞書から単語ごとに音声スニペットを取得し、それらを結合することで合成音声を生成する。これにより機械翻訳データをその場で音声翻訳データに変換できるようになる
    論文
  • Using External Off-Policy Speech-To-Tex (UEOP):
    オフラインで更新できる1000万単語/フレーズからなる外部メモリを活用して、End-to-Endの自動音声認識モデルを改善する手法
    論文
  • Vid2Seq:
    人手でアノテーションされたデータセットを学習データとしていた従来手法と異なり、ナレーション付き動画を活用することで大規模データセットでの事前学習を可能とした手法
    論文

Code

  • Retrieval-Based Prompt Selection for Code-Related Few-Shot Learning:
    本文を読めていないですが、アブストによると類似するタスクのコードを検索し、ヒットしたものを例としてコード生成時のプロンプトに盛り込むことでコード生成の性能が向上したとのこと
    論文

最後に

今回はRAGのSurvey論文に関してまとめてみました。
最初は「論文1本読むかー」ぐらいの気持ちで始めたのに、Survey論文だけではわからないことを1本引用元まで辿って読んでみたら理解が深まったので「じゃあ他の引用されてる論文も読むかー」と引用元をどんどん辿っていったら、気づけば50本ほど論文を読んでいました。

今回は紹介されている手法をただただ紹介するだけにはなりましたが、ただ列挙するだけでも「こんな手法があったのか」とかなり勉強になりました。
本記事が参考になれば幸いです。

はじめての自作キーボード組み立て（Keyball61）

1ヶ月ほど前に自作キーボードの 沼 世界に足を踏み入れ、苦労しながらも先日Keyball6を完成させることができました！

今回は作成に合わせて揃えたものや完成までに苦労した点をまとめます。

Keyball61を買おうと思ったきっかけ

今までHHKB BTを使っていてそこそこ満足していたのですが、

  • 分割されてないキーボードだと仕事中に取れる姿勢が限られるので、姿勢を楽にする目的で分割キーボードに興味が出てきてた
  • キーボードを新調するなら、トラックボールがセットになってるものが欲しかった

というわけでこの条件に合うキーボードを探したところ、Keyball61と出会いました。

Keyball61は自分で組み立てが必要な自作キーボードなわけですが、関西Kaggler会などの場で自作キーボードの話を聞いていて心理的なハードルが下がっていたことからチャレンジしてみることにしました。

準備編

兎にも角にも必要なものを揃えないと始まりません。
初めての自作キーボード作成だったこともあり、色々買いました。

キーボード本体

「Keyball61を作るぞ！」と決めた時は白銀ラボでも遊舎工房でも売り切れだったので、入荷通知のメールを登録してしばらく待ちました。
数週間かかるのも覚悟しましたが1週間ほどで入荷メールをいただいたので速攻で確保しました。

このブログの執筆時点ではそこそこ在庫があるようです。

shirogane-lab.net

【委託】Keyball61shop.yushakobo.jp

ビルドガイドのもある通りこのキットだけではキーボードは完成しないので、以下のもの用意しました。

道具類

元々家にあったこちらのハンダごてにC型のこて先をつけて作業しました。
20Wほどのものなので昇温に時間がかりますが、LEDのハンダ付け以外は十分こなせます。
後述の温度調整できるものよりもこて先が大きいので部品に熱が伝えやすいのが良き。

太洋電機産業(goot) プリント基板用はんだごて ニクロムヒーター KS-20R 日本製

太洋電機産業(goot) プリント基板用はんだごて ニクロムヒーター KS-20R 日本製

  • 太洋電機産業(goot)
Amazon
太洋電機産業(goot) 替こて先 径4×75㎜ R-48C 日本製

太洋電機産業(goot) 替こて先 径4×75㎜ R-48C 日本製

  • 太洋電機産業(goot)
Amazon

ハンダはこちらの鉛フリーのφ0.8mmのものを使用しました。

akizukidenshi.com

基本は上記のものでハンダ付けを進めていたのですが、ハンダ初心者が熱に弱いLEDを「温度調整できないハンダごて」で「鉛フリーのハンダ」でやるのは無理があったようでLEDをいくつか壊したため、温度調整できるハンダごてを追加で購入しました。
私が買ったものは以下のもので、USB Type-Cで給電できて取り回しが良く、65Wなので昇温が早いので使いやすかったです。
温度調整して以降はLEDが壊れることはほぼなくなったので、LEDのハンダづには温度調整できるハンダごては必須ですね。

https://a.aliexpress.com/_om2ev9a

あとはハンダに必要はハンダごての台やフラックス、フラックス洗浄剤を買ってます。

あとはピンセットや精密ドライバーがなかったのでこちらを購入しました。
必要なものが収納に便利なポーチに入っているので、何かと便利です。

ENGINEER エンジニア マイキット 7点セット KS-01

ENGINEER エンジニア マイキット 7点セット KS-01

  • ENGINEER
Amazon

完成までの道のり

ハンダ付け自体が初めてだったので、結構時間がかかりました。
ハンダ付けし始めたの12/23、完成したのが1/21と1ヶ月ほどかかっています。

（まぁその間に統計検定準1級を受けたり年末年始を挟んでいるので、ずっと作業をしてたわけでもないですが）

慣れていない作業ということもあって色々失敗もしたので、これから作るひとの参考になるよう自分の失敗をつらつら書いていこうと思います。

失敗談1 Key Microのハンダ付け失敗

Key Microをハンダ付けする際に加減がわからず、スルーホールに刺したピンの周りにハンダが貯まらないのでドンドンハンダを足していったのですが、気づくとピンソケットの中にハンダが詰まりまくっていて大変なことになりました。
しかもKey Microの裏表を間違えるという有様。ビルドガイドはちゃんと読もう！

ハンダ吸い取り機を買ったりしてピンソケット取り外しを試みるもなかなかうまくいかず、最終的にはピンソケットをペンチで破壊してKey Microを救出しました。

お高いKey Micro救出のために結構な時間がかかったので「お高い基板じゃなければ諦めて基板ごと書い直す決心がつくのに。。」と思いながら作業したのはいい思い出ですw

失敗談2 ハンダ付けしたLEDが光らない問題

LEDが光らない原因は自分の場合は2パターンあって、「ハンダごての熱でLED自体が壊れてる」か「LEDに異常はないがハンダ付けをミスってる」でした。
どちらかというと後者が多い印象でした。

後者を疑ってハンダ吸い取り線で余分なハンダを吸い取ると復活することが多かったです。
（見た目ではわからなかったが、隣合ったパッドのハンダが繋がってたか？）

それでもダメな時は前者を疑って新しいLEDにすると、だいたい治りました。
LED自体が壊れるのは、温度調整できるハンダごてにしてからはほぼなくなったので、最初から導入しておけばとは思いました。

ちなみに「光らないLED」ができてしまった時の対処としては、こちらのサイトで紹介されている「点灯していない LED の一つ前にある点灯している LED の DIN と、点灯していない LED の DIN をジャンパワイヤーなどで接続する」と良いというのが非常に役立ちました。
この結果から「どこが大丈夫でどこがダメか」の切り分けができるので、トラブルシュートに役立ちます。

kankodori-blog.com

それにしてもTRSケーブルで繋いだら光らなくなったり、突然たまに「玉切れした蛍光灯」みたいな光り方するのはホンマに謎。電気全然わからん。

失敗談3 基盤のパターン破壊

熱で壊してしまったLEDを外す際に銅箔ごと剥がしてしまい、その場所にハンダ付けしても電気が流れないという事態に陥ってしまいました。

色々調べた結果「壊したパターンの場所をジャンパー線で繋ぐ」しかないようだったので、↓のように短く切ったジャンパー線をハンダ付けして事なきを得ました。

見た目がかなりイマイチですが、組み立てて仕舞えば見えない場所なので気にしない方向で。

失敗談4 買った部品の規格が合わない問題

これは色々やらかしました。

端子が太いTRSケーブルを買ってしまったり、

データ通信非対応のUSBケーブルを買ってしまったり、

用意したキースイッチに対応していないキーキャップを買ってしまったり、

MBK Choc Low-Profile Keycapsshop.yushakobo.jp

などなど、無駄な買い物を結構してしまいました。

失敗談5 OLEDにハンダごてが接触

こちらの写真をご覧ください。

OLEDのハンダ付けの際に本体にハンダごてが当たってしまい、OLEDの右下が少し変色しています。
やらかした時はテンションが下がりましたが動作はするのでそのままにしています。
ピンホールのハンダ付けの際のハンダごての向きには注意しないといけなかったですね。

作ってみての感想

そんなこんなで色々苦労しましたが、なんとか完成しました。

使ってみての感想としては、 - 姿勢が楽 - 1箇所で全ての操作が完結するのが最高 - キーマップを色々変更できるので、カスタマイズの幅が広い

特に姿勢は↓の写真のように椅子の肘置きの目の前にキーボードを置いて、肘置きに手首を乗せて操作するスタイルがかなり快適です。
もう猫背にならずに済みます。

ただキーボードの配列が変わった関係で、タイピング速度は落ちました（今は下よりマシです）。

まぁ慣れの問題なので時間が解決してくれるでしょうし、この記事を書いている間にタイピング速度はマシになってきたように感じます。

あとはまだできてないですが、ファームを自分で書き換えてマウスカーソルの速度やスクロールの設定値だったりをカスタマイズするともっと便利になりそうです。
まだまだ未開の地があるので、これからも色々試してみるのが楽しみです。

.

そんなこんなではじめての自作キーボード作成記でした。
ここまでお読みいただきありがとうございます。

統計検定準1級の勉強に役だった書籍まとめ

データ分析 データサイエンティスト

統計検定準1級にに3回目の挑戦で合格できました。

今回は試験を受けるまでに参考にした書籍をまとめます。

公式テキスト類

これは外せないですね。まずこれをやって、全体感を掴みましょう。
ワークブックの方は膨大な範囲を1冊に収めている関係で、1回読んだだけで理解するのはなかなか骨が折れると思います。
私は途中でKaggleのコンペに出たり、スクラムマスターの資格を取ったりと色々他にも手を出しながらだったので、読み終わるのに1年近くかかりました。

ワークブックの内容をある程度理解したら後述の過去問に移って、わからないところが出てきたらこちらのテキストに戻る、ぐらいの進め方が良さそうです。

日本統計学会公式認定 統計検定準1級対応 統計学実践ワークブック

日本統計学会公式認定 統計検定準1級対応 統計学実践ワークブック

  • 学術図書出版社
Amazon

日本統計学会公式認定 統計検定 準1級 公式問題集

日本統計学会公式認定 統計検定 準1級 公式問題集

  • 実務教育出版
Amazon

副読本

基本は上記の流れなんですが、この2冊だけでは理解が難しい部分があります。
ここではそういう部分の理解の助けになった書籍を紹介します。

PRML

2章で共役事前分布や逐次推定の話を、3章からは線形モデルの話を徹底的にやってくれます。
演習の計算は大変ですが、根気よくやり切れば間違いなく実力がつく1冊です。

パターン認識と機械学習 上

パターン認識と機械学習 上

Amazon

アイシアさんの動画

学生時代から線形代数が大の苦手な私ですが、「固有値固有ベクトルがわかると何が嬉しいか」というようなことを順を追ってわかりやすく説明してくれるので、動画のキャッチフレーズの通り「行列の積と和解」を果たすことができました。
線形代数に苦手意識のある方におすすめです。

2級→準1級の大きな違いの1つが「多次元のデータを扱うために行列演算を頻繁に使う」なので、線形代数に慣れ親しんでおくことはかなり重要だと思っています。

youtube.com

入門 機械学習による異常検知

「異常検知」に特化した本書には、統計検定準1級の知識多く用いられます。
基本的な統計解析から始まり、本書の後半では主成分分析や線形回帰モデル、自己回帰モデルなどによる異常検知が丁寧に解説されています。
試験に直接役立てられるわけではないですが、試験勉強を通して得た知識にこういう使い方もあるのかと気づかせてくれる1冊です。
試験に受かってからもう一度ちゃんと読み直したい1冊でもあります。

入門 機械学習による異常検知―Rによる実践ガイド

入門 機械学習による異常検知―Rによる実践ガイド

Amazon

あつまれ統計の森

過去問で行き詰まった際、こちらのサイトの解説にかなりお世話になりました。

www.hello-statisticians.com

私が読んだ本で準1級の範囲に関わっているものはこんなところかなと。
振り返ってみるとワークブック以外で「統計検定のためだけに買った」という本が思いのほか少なかったですね。

もっと試験範囲全体を見渡して様々な書籍を紹介してくれているサイトがあるので、そちらの方が役立つかもしれませんw

試験に受かったものの因果分析あたりは理解が浅いのでもっと勉強したいところです。
良書をご存知の方、教えていただけるとありがたいです。

お読みいただきありがとうございました。

関西Kaggler会 参加レポ

先日参加した関西Kaggler会が楽しかった + 勉強になったので、忘れないうちにまとめておこうと思います。

オープニング

まずはいつもの「始まりの儀式」で開始。
過去の写真と見比べるとすごく参加者が増えましたね！

そしてmgnさんのオープニング。
いい感じに会場を暖めて笑いも引き出すトークは流石です。

「どんどんツートしましょう」ということでこんな仕掛けが。
他のイベントでも使えそうです。

ちなみに関西は「お行儀いい関東と違って笑いも」とのことです。

これは突然イジられるベルーガさん。

どりぃさん発表

まずは会場を提供くださったR3 instituteからどりぃさんが登壇。
素敵な会場を使わせていただき、ありがとうございます。
以下のリンクに会場の詳しい説明や写真があります。

たいちさん発表

ここからKaggleの話、と思いきや自作キーボードの話。

ちなみにこのレポの筆者はHHKBを愛用しています。
HHKBと同じぐらいの出費で自作キーボードの世界に入門できるそうで、かなり興味が湧きました（特に左右分離してるやつ）。

あと「自作キーボードを使うと持ち歩かないといけなくて重いんですが、、」という質問に「なら2つ持てばいい」と食い気味に回答していて、ここでも爆笑がw

ちなみに「持ち運ぶことが気にならなくなるくらい楽しい」とのことです。

ころんびあさん発表

続いてのころんびあさんの発表は「コンペに勝つには」。
こちらはコンペはコンペでもCVPRのお話。

ただ入りが全員で爆笑していただけに、技術の深い話になるとなんか会場が異様に静かに。。
（全員が全員画像のプロじゃないだけに、この辺の塩梅はすごい難しいですね）

結果、結論としては「いい感じに」やるということに。
（以降「いい感じに」「よしなに」が会場で流行り出すw）

ちなみに3D物体検出を「いい感じに」やれるようにはなるには、「とにかく論文読みましょう！」とのこと。
（後どれぐらい論文を読めば「いい感じに」扱えるようになるだろうか）

T88さん発表

こちらは関西Kaggler会に先立って開催されたコミュニティコンペをGPT-4にコードを書かせてみた、というもの。

こちらは「githubのissueにcv改善のアイディアを書けば、GPT-4がコードを書いてくれてcv下がったか確認してくれる」という優れもの。

ちゃんと確認しないと初歩的なミスをしたり、存在しない列名を指定してエラーを出したり、盛大にリークさせたりするものの、最終的にはなんとコミュニティコンペで11位相当スコアだったとのこと。

（このブログの筆者はギリギリでした。ただ私のsubmitは「特定の市の不動産価格を1.3倍する後処理」を入れているので、それを入れない条件で揃えるとGPT-4に負けます）

ronさん発表

お次はパパさんKagglerで社会人博士で出張の多いronさんによる「時間のないKagglerのすすめ」。

「いかに隙間時間でKaggleをするか」がポイントとのこと。

スマホからGPUマシンにアクセスしたり、
子どもを寝かしつけながらスマホでdiscussion読んだり、
スマホでsubmitしたり、

とにかくスマホを大活用してます（キーボードいらないとか言わない）。

関東Kaggler会でも「Redbullは1日1本まで」と言うお話でしたが、こちらでは「RedbullとChilloutを交互に飲む」メソッドが紹介されてました。
（ronさん、お身体は大事にしてください。。）

あと「大自然の中でsubmitするといいスコアが出る」と言うお話でしたが、、

Jackさん発表

お次はJackさんから「Feature Importanceによる特徴量選択とリーク」のお話。

speakerdeck.com

Jackさんは少ないsub数で上位に入ることから「忍者」と呼ばれているそうで。

CV全体でFeature Importanceを平均しちゃうと、バリデーションデータのノイズ情報も入り込んでしまうとのこと。
あとは「全foldで改善しているか」と言う観点も重要だそうで。
その辺りを真面目に見ないことがあるので気をつけたいところです。

くるぴーさん発表

お次は最近Grand Masterに昇格されたくるぴーさんのLLMコンペの話。

実験を高速に回すコツを色々伺えました。

また「❌GPUを止めるな ⭕️思考を止めるな」「信じたアイディアと心中する」など、私含め多くのKagglerに刺ささる名言をいただきました。
（疲れてくると適当にハイパラだけ変えてGPU動かしたりしがち。。）

nejumiさん発表

お次はこの関西Kaggler会に先立って行われたコミュニティコンペを設計くださったnejumiさんから、まさしくコミュニティコンペの話。

speakerdeck.com

ここ数年で、商用利用がOKになったり、Visibilityが制御できるようになったり、Custom Metricが使えるようになったりと、何かと機能が増えて便利になっているようです。
「コンペ設計のポイント」という「開く側」でないとノウハウを積めない貴重なお話も伺えました。
「コンペを開く側」お話はなかなか伺えないので、非常に興味深かったです。

職場の有志とかでコミュニティコンペを開くのも面白そう、と思えるお話でした。

あとチーターは丸わかりらしいですよ！

johannyjm1さん発表

お次はjohannyjm1さんの「Polarsと遅延評価」

筆者は「遅延評価」をちゃんと分かってなかったのですが、"式の評価を「必要になるまで」行わない、サボる仕組みのこと" とのことです。
気になる方は↑の資料が非常にわかりやすいのでそちらをご覧ください。

polarsを使う時は、"df.lazy()" で遅延評価を使いましょう！

あまえびんさんLT

お次はあまえびんさんの「オレオレ開発Kaggle環境」。

speakerdeck.com

筆者はKaggle用のAWS環境を立てる際、これまではAWS推奨のTraning job用のDoeck imageを使ってましたが、ライブラリのバージョンやディレクトリの構成も考えるとKaggleに合わせたイメージを使う方が良さそうです。
今度からそれで開発してみようと思います。

すでに「オレオレ開発Kaggle環境」のユーザーもいらっしゃるようです。

ベルーガさんLT

お次はベルーガさんのLT。
ここはその場限りの話が多かったため、割愛させていただきます。

paoさんLT

最後はpaoさんのLT。
ABEJAさんの紹介や、Kaggleと実務に関して「Kagglerのどんなところが実務の中で役立っているのか」「Kagglerの安心感」などの話でした。

懇親会

夜の懇親会では新しくGMに上られたchunmajinさんとくるぴーさんに運営からお祝いにTシャツのプレゼントがあったり、

抽選会があったり、

コンペの賞の贈呈があったり

とイベントが盛り沢山な上に、普段そうそう会えない方々とお話しすることができ、大盛り上がりの楽しい & 勉強に場でした。

以上、関西Kaggler会 参加レポでした！
少しでも雰囲気をお届けできていたら幸いです。

最後に、このような非常に勉強になりかつ楽しい場を設けていただいた運営の方々、末筆ながら感謝申し上げます。
会場でお話しいただいた方々も、本当にありがとうございました！

なぜ近年AIが活用されるようになったかを考える

近年「AI」という言葉を耳にする機会が増えてきたかと思います。
今回は近年AIがここまで活用されるようになった要因を、デープラーニングがどのように画像分類を行なっているかを紐解いていきます。

AIの歴史

「Artificial Inteligence(AI, 人工知能)」という言葉が初めて登場したのは1956年に開かれた「ダートマス会議」で、そこでAIに関する研究が学術研究の1分野として確立したと言 われています。そこから第一次AIブーム（1950年代後半〜1960年代）、第二次AIブーム(1980年代)を経て、2000年台から第三次AIブームが始まり、現在も続いています1)。
まずは第一次〜第三次AIブームそれぞれを振り返ってみたいと思います。

第一次AIブーム

1956年に開かれた「ダートマス会議」で Artificial Inteligence（人工知能）という言葉が初めて登場し、AIに関する研究が学術研究の1分野として確立しました。
探索木など、「推論」や「探索」の研究が進んで特定の問題を解くことができるようになったことから、注目を集めました。
ただし研究が進んで当時の技術では迷路やパズルのような限定された問題（トイプロブレム）しか解けず、現実世界に存在する複雑な問題が解けないことがわかると、ブームが収束しました。

第二次AIブーム

第二次AIブームは1980年台に始まりました。
知識をいかに表現するかという研究が盛んに進められ、専門家の「知識」をコンピュータに与えることで「エキスパートシステム」が開発できるとして研究が進められました。
知識はIF-THENルールで記述されることが想定され、このルールを大量に貯めておけば最高の専門家の思考過程を再現できると考えられていました。 この試みは研究が進むにつれて以下の問題が明らかになり、期待が失望に変わり、ブームは収束しました。

  • 「常識」など広い範囲の知識を蓄積・管理するのに膨大な労力を要すること
  • 人間が明確に列挙できるルールの多様性が、現実世界の多様性に比べて桁違いに乏しいこと

第三次AIブーム

第三次AIブームは2012年ごろから始まりました。
きっかけは深層学習（ディープラーニング）を活用したAlexNetというアルゴリズムがILSVRC (ImageNet Large Scale Visual Recognition Challenge) という画像に写っているものを分類するアルゴリズムの精度を競うコンペティションで、これまでのtop5エラー率※を大幅に更新したことです。
※アルゴリズムが各写真に写っているものとして予想した上位5つに正解が含まれていない割合

これはインターネットの普及に伴うビッグデータの拡大やコンピュータの演算処理能力の向上によるところも大きいですが、ディープラーニングが「特徴量」と「関数」を自ら習得できるようになったことが大きいです。

次の章ではこの「特徴量」と「関数」に関して説明していきます。

特徴量と関数について

特徴量とは

特徴量とは分析対象データの中の、予測の手掛かりとなる変数のことです。
簡単な例で説明していきたいと思います。

例として以下の様な「気温とアイスの売り上げ個数」のデータ（架空のデータ）がある場合を想像してください。

気温とアイスの売り上げ

データから「気温が上がるとアイスの売り上げ個数が増える」というのが想像できるかと思います。また「気温が高い方がアイスを食べたくなる」という直感に反していないので、前述の「気温が上がるとアイスの売り上げ個数が増える」は理解しやすいかと思います。

気温はアイスの売り上げ個数の予測の手がかりとなるので、気温はアイスの売り上げ個数の特徴量と言えます。

関数とは

先ほどの例で特徴量からアイスの売り上げを予測するには、グラフ上の点のできるだけ近くを通る直線（図の赤線）を引けば可能となります（この直線を引くには最小二乗法などの手法がありますが、ここでは割愛します）。

このように特徴量（気温）から求めたい変数（アイスの売り上げ）を予測する式を「関数」といいます。

ディープラーニングはどのように特徴量と関数を扱っているのか

まずは特徴量をディープラーニングでどのように扱っているかを見ていきたいと思います。
気温とアイスの例で特徴量を考えるのは簡単でした。それはデータがすでに「売り上げ個数」と「気温」という数値データになっているからです。

これに対して「画像に何が写っているか」を判定する場合の特徴量を考えてみましょう。

例えば「画像にリンゴが写っているか」を考えると「赤いか」「丸いか」など言葉として羅列することはできますが、それをコンピュータでも処理できる形で数値化するのは非常に難しいと感じるかと思います。
また例え数値化できたとしてもリンゴ以外のあらゆるものに対応しようとすると、ルールが膨大になるのは想像に難くありません。

この問題に対してディープラーニングではどのように対応しているのでしょうか？
「第三次AIブーム」の節で紹介したAlexNetの1層目の畳み込み層パラメータを図示すると、下図のようになっています2)。
上3列の48個の畳み込み層で境界線に関する特徴を、下3列の48個の畳み込み層で色に関する特徴を抽出していると言われています。

AlexNetで抽出した画像の特徴量

AlexNetでは「畳み込み層」と言われるニューラルネットワークに画像を学習させることで上記のような特徴量を抽出できるようになりました。人が特徴量の抽出方法を1つ1つ教えるようなことはしていません。

このように人が理解できる形では数値化されていないデータ（非構造化データ）から特徴量を抽出する仕組みができたことが大きなブレイクスルーだったと言えます。

「畳み込み層」の仕組みに関しては以下の動画がわかりやすいので、そちらをご参照いただければと思います。

www.youtube.com

次に関数についてです。
ディープラーニングでは前述の畳み込み層などで抽出した特徴量を「全結合層」と呼ばれるニューラルネットワークで処理しています。
全結合層では全ての変数を使った一次関数と非線形な活性化関数を組み合わせた単純な機構（場合によっては全結合層を複数回繰り返して）で、複雑な関数を表現できるようになっています。
これによって特徴量を欲しい出力（画像に何が写っているか、など）

全結合層の仕組みに関してはすでにわかりやすく解説したサイトがたくさんあるので、詳細の説明はそちらを参照いただければと思います。
例えば以下の動画が参考になると思います。

www.youtube.com

このようにディープラーニングでは、画像のような人が理解できる形では数値化されていない非構造化データから特徴量を抽出する方法をデータから学習し、全結合層でその特徴量に対する関数を作って目的とする出力に変換する複雑な関数をシンプルな機構で実現しました。
これこそがデープラーニングがここまで色々なものに適用されるほど高い性能を出せた要因であったのではないかと考えています。

まとめ

本日はデープラーニングがどのように画像分類を行なっているかを紐解くことで、「なぜ近年AIが活用されるようになったか」を考えてみました。
最近流行っている「お絵描きAI」のようなツールはここからさらに技術的な進歩があったので、また別の機会にまとめてみようと思います。

お読みいただき、ありがとうございました。

1) https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h28/html/nc142120.html
2) https://proceedings.neurips.cc/paper/2012/file/c399862d3b9d6b76c8436e924a68c45b-Paper.pdf

技術同人誌出版によせて

9月10日から開催の技術書典13で技術同人誌を出します。 今回はその本に関してを書いていきたいと思います。

techbookfest.org

本の内容

まずは「なぜAI活用に取り組むのか」を説明したあと、Azureとそこで提供されているサービスCognitive Servicesについてを説明し、Cognitive Servicesの「視覚」に関する機能の使い方を紹介しています。

目次は以下の通りです。

  1. ノンプログラマーがなぜ今「AI活用」に取り組むべきなのか
  2. Azureとは
  3. 必ず抑えておきたいセキュリティとコストの話
  4. Azure Cognitive Services について
  5. Azure Cognitive Servicesを使ってみる
  6. おわりに

なぜCognitive Servicesを紹介するのか

いわゆる「第三次AIブーム」以降、主に深層学習を活用した機械学習モデルの性能向上を背景にAI技術活用が進んできました。第三次AIブーム当初は専門家がコーティングしないと活用できませんでしたが2017年に「AIの民主化」が提唱されて以降、ノーコード、ローコードでAI技術を活用できるようなサービスが出てきました。そのようなサービスの1つであるAzure Cognitive Servicesを通じて「今までAIが身近でなかった人にも、自分でAIを触れるようになれば」という思いがあり、本にまとめることにしました。

「第三次AIブーム」が始まってから10年近く経過しAIの活用が進んでいますが、AIが活用されている範囲は限られていると思います。そのような状況を変えていく手段の1つとして、「ITやAIには疎くても、自分がいる業界のことには詳しい人」に「AIが何をできるか」を知ってもらい、その人が詳しい分野にどうAIを活用すると役立つかを想像してもらうのが重要ではないかと考えています。それによって「AIや機械学習に関しては詳しいが、業界に関しては知らない人」だけでは思いもよらないような、面白いAI活用方法が産まれてくるのではないかと思っています。

今回私が書いた本を通じて「AIでこんなことができるんだ」と気づいて、AI活用に興味を持ってくれる方が一人でもいらっしゃれば幸いです。

techbookfest.org

ギリギリ銅メダルを取れたKaggle Feedback Prizeを振り返る

こんにちは。sue124です。

まだ順位は確定してませんがPublic Scoreでギリギリ銅メダル圏内に入れたので、やったことを振り返ってみたいと思います。

Kaggle Feedback Prizeとは

Feedback Prizeのタスクは自然言語処理（NLP）の中でも固有表現抽出（NER）と呼ばれるものです。

具体的にいうと、学生が書いたレポートの中から以下に該当する部分を抽出できる機械学習モデルを作るタスクです。

  • Lead (赤)
  • Position (緑)
  • Evidence (黄)
  • Claim (青)
  • Concluding Statement (マゼンタ)
  • Counterclaim (シアン)
  • Rebuttal (灰)
  • None (無色)

学習データとして与えられている文章にわかりやすく色づけすると、以下のようになります。

f:id:sue124:20220317171112p:plain

学習データから作成した機械学習モデルでテストデータの文章のどこが何に該当するかを予測し、正解と比較した際のmacro F1 scoreで順位が決まります。

評価方法の詳細は以下のリンク先の通りです。

www.kaggle.com

コンペ内でやってみたこと

今回コンペの中でやったことは以下の通りです。

  • Base Lineモデルの改造
  • Threshold微調整
  • R-BERTによるラベル再判定

Base Lineモデルの改良

今回のコンペは1月半ばに当時4位だった方公開したコードがコンペ終了までBase Lineとなっていました。

学習済みモデルの重みも公開されており「Forkしてそのままsubmitすれば同じスコアになる」状態であったため、多くの方がこの方と同じスコアになりました。

このコードのスコア自体が既に高かったですがそのままでメダルが取れるほど甘くはないので、githubで公開されていた学習用のコード（下記リンク）の改造をしました。

github.com

Base LineのモデルはLongfomerの出力層を全結合層に入れている形だったので、過去のコンぺの解法を参考にしながらLongfomerの出力層と全結合層との間にCNNやLSTMを追加したモデルを作りました。

www.ai-shift.co.jp

たったこれだけのことですが他の2つのアプローチがあまり効かなかったのでスコアへの貢献度は高かったです（ほぼこれだけでメダルが取れたと言っても過言ではない）。

後処理の閾値微調整

こちらのdiscussionでBase Lineのコードの後処理の閾値に改良の余地があるらしいことを知りました。

www.kaggle.com

これを見て、自分のモデルのCVの出力結果のnumpy.arrayを保存して後処理の閾値を微妙に変えながらCVのF1 scoreが良くなる閾値を探しました。

ただこれは自分で作ったコードで探索した閾値だとPublic scoreがあまり良くならなかったので、結局以下のコードで紹介されている閾値を使用しました。

[0.690]😄！try better parameters! | Kaggle

R-BERTによるラベル再判定

これはやってみましたがscoreが全く良くならなかったので、不採用とした案です。

きっかけとしては、単語単位での混合行列（下表）を見て「CounterclaimやRebuttalと予測すべきものを相当数Evidenceと誤判定している」という点に気づいたことがきっかけでした。

f:id:sue124:20220318142648p:plain

そこで「Counterclaim、RebuttalとEvidenceは同じような書き方をしているので、その文章の筆者がどういう立場かを考慮しないと判別が難しい」という仮説を立ててみました。 「Evidenceと判定した文章が筆者のPositionと合致するするかどうか」を以下の論文のR-BERTというモデルを使ってみることにしました。

arxiv.org

モデルのアーキテクチャーは下図の通りで、[CLS]と2つのspecial token ($, #) で囲まれた範囲のBERTの出力をAverage Poolingと全結合層で繋いで、2つのspecial tokenで囲まれた単語の関係性を予測するというものです。このモデルで SemEval2010 task 8 relational datasetのタスクでSoTAを達成したとのことです。

f:id:sue124:20220322070647p:plain
R-BERT モデルアーキテクチャー

このR-BERTを参考にして、1つ目のspecial tokenを文章中の「Position」につけて2つ目のspecial tokenを「Evidence」と判定した文章のうちの1文につけて「2つの文章が同じ立場かどうか」を判定するモデルを作成しました。

ただこの節の冒頭に記載した通り、このモデルはうまく機能しませんでした。

「Evidence」と「CounterclaimやRebuttal」の割合が1:1の時はまだいいのですが、実際の問題は上記の混合行列のようにこの割合がだいたい50:1ぐらいです。 このような偏ったデータで分類すると、偽陽性が大量発生してスコアが落ちてしまいました。

もう少し時間があればこのモデルを改良して「Positionを考慮して各単語を再分類する」ようなモデルもできたかもしれませんが、そこまでたどり着くことはできませんでした。

まとめ

今回はKaggle Feedback Prizeでやったことをまとめてみました。

銅メダルは取れましたが今回のコンペはBase Lineのレベルが高くて、自分のアプローチではあまりスコアが伸びなかったのが悔やまれるところです。 上位の方が公開してくれている解法を見て、さらにレベルアップしていきたいと思います。

お読みいただきありがとうございました。