🗞️

今週の生成AI情報まとめ(7/22~7/28)

2024/08/24に公開

こんにちは、ナウキャストでLLMエンジニアをしているRyotaroです。
7/22~7/28で収集した生成AIに関連する情報をまとめています。

※注意事項

内容としては自分が前の週に収集した生成AIの記事やXでの投稿・論文が中心になるのと、自分のアンテナに引っかかった順なので、多少古い日付のものを紹介する場合があります

それでは行きましょう

An evaluation of RAG Retrieval Chunking Methods

RAGのシステムをOSSのモデルを使って精度改善するというもので、EmbeddingとChunking、Rerankingの3つの箇所でいくつかの手法やモデルを試して検証している。

Embedding

MTEBというリーダーボードからトップのEmbeddingモデルを検証

  1. BAAI/bge-small-en-v1.5
  2. BAAI/bge-large-en-v1.5
  3. BAAI/bge-m3
  4. sentence-transformers/all-distilroberta-v1
  5. WhereIsAI/UAE-Large-V1
  6. ColBERT v2

結果は6.ColBERT v2が一番良く、2 番目に優れた方法に比べて平均で約 10% のパフォーマンス優位性を示した。

Chunking

LangChainやLlamaIndexで実装されている5つのSplitterを検証

  1. SentenceSplitter
  2. SentenceWindowNodeParser
  3. SemanticSplitterNodeParser
  4. TokenTextSplitter
  5. RecursiveCharacterTextSplitter (LangChain)

意外なことに、1.SentenceSplitterが一番良い。ベクトル的に類似している=意味が同じというわけではないということが原因とされている。(関連性と類似性が必ずしも一致しないという話はこの文脈でよく話される)

セマンティック評価の利点にもかかわらず、SentenceSplitter が SemanticSplitterNodeParser よりも優れたパフォーマンスを発揮することは、次のことを示唆しています。

  • 文は意味のある情報を含むための非常に自然な粒度レベルであり、
  • 高い意味的類似性の尺度は、意味のある類似性ではなくノイズから生じる可能性があります。

意味的に類似した文のベクトル表現 (単語の重複がない場合) は、文の意味に基づいて予想されるよりも互いに離れていることがよくあります。単語はコンテキストによって異なる意味を持つ場合があり、単語の埋め込みは基本的に単語の「平均的な」意味をエンコードするため、特定のインスタンスではコンテキスト固有の意味が失われる可能性があります。さらに、文の埋め込みは単語の埋め込みの集合体であり、一部の意味をさらに「平均化」します。

その結果、1) 文の境界以外の基準でテキストを分割してチャンキングを行う、2) 固定長 (つまり、基本的に 1 ~ 2 文) ではなく意味の類似性に基づいてテキスト セグメントをグループに結合する、といった操作を行うと、検索パフォーマンスが低下する可能性があります。

Reranking

⁠以下のRerankingモデルを検証

  1. cross-encoder/ms-marco-TinyBERT-L-2
  2. sentence-transformers/all-mpnet-base-v2
  3. BAAI/bge-reranker-base
  4. BAAI/bge-reranker-large
  5. WhereIsAI/UAE-Large-V1

結果はcross-encoder/ms-marco-TinyBERT-L-2-v2が最も速度の点で効率的で、異なるデータセットで一貫して優れたパフォーマンスを発揮した。

データセット モデル チャンカー リランカー MRRR(月次) リコール@10
すべてのデータセット コルバート v2 センテンススプリッター なし + 8% + 12%
ホットポットQA コルバート v2 センテンススプリッター なし 0.3123 0.5051
ホットポットQA WhereIsAI/UAE-Large-V1 センテンススプリッター TinyBERT-L-2-v2 0.2953 0.4257
チーム コルバート v2 センテンススプリッター なし 0.8711 0.9581
チーム BAAI/bge-m3 センテンススプリッター TinyBERT-L-2-v2 0.8286 0.93
チーム BAAI/bge-m3 センテンススプリッター なし 0.8063 0.93
クアック コルバート v2 センテンススプリッター なし 0.2207 0.3144
クアック BAAI/bge-large-en-v1.5 センテンススプリッター TinyBERT-L-2-v2 0.1975 0.2766

⁠結論

すべてのデータセットで RAG 検索を処理するための最も優れた方法は、SentenceSplitter チャンクを使用した ColBERT v2

リランカー モデル TinyBERT はモデル パフォーマンスの改善に最も効率的であることが証明され、より大規模なリランカーよりも優れたパフォーマンスを発揮した。

参考資料:

Prompty

PromptyとはLLMプロンプト管理フォーマットのことで、一つのファイル上でプロンプト管理とLLMによる実行、チューニングが可能となる。MicrosoftがVSCodeの拡張機能を提供しており、ファイル拡張子を.promptyとすれば使える。

以下のような書き方をし、modelの指定、system promptの組み込み、変数組み込みができる。入出力を記録するわけではないので、チャットには対応してない。

---
name: ExamplePrompt
description: A prompt that uses context to ground an incoming question
authors:
  - Seth Juarez
model:
  api: chat
  configuration:
    type: azure_openai
    azure_endpoint: https://<your-endpoint>.openai.azure.com
    azure_deployment: <your-deployment>
  parameters:
    max_tokens: 3000
sample:
  firstName: Seth
  context: >
    The Alpine Explorer Tent boasts a detachable divider for privacy, 
    numerous mesh windows and adjustable vents for ventilation, and 
    a waterproof design. It even has a built-in gear loft for storing 
    your outdoor essentials. In short, it's a blend of privacy, comfort, 
    and convenience, making it your second home in the heart of nature!
  question: What can you tell me about your tents?
---

system:
You are an AI assistant who helps people find information. As the assistant, 
you answer questions briefly, succinctly, and in a personable manner using 
markdown and even add some personal flair with appropriate emojis.

# Customer
You are helping {{firstName}} to find answers to their questions.
Use their name to address them in your responses.

# Context
Use the following context to provide a more personalized response to {{firstName}}:
{{context}}

user:
{{question}}

.vscodeの中に、APIの接続情報を記載する

{
     "prompty.modelConfigurations": [
        {
            "name": "default",
            "type": "azure_openai",
            "api_version": "2023-12-01-preview",
            "azure_endpoint": "https://oai-xxx.openai.azure.com",
            "azure_deployment": "gpt-35-turbo"
        },
        {
            "name": "gpt-4o",
            "type": "azure_openai",
            "api_key": "xxx",
            "api_version": "2024-02-01",
            "azure_endpoint": "https://oai-xxx.openai.azure.com",
            "azure_deployment": "gpt-4o"
        }
    ]
}

⁠実行

実際の画面と出力はこんな感じ。

まずはmodelのAPI設定を行う。.vscodeにあらかじめAPI接続情報入れておき、値を紐づける。

その後右上にある「▶️」を押すことでpromptが実行され、Outputタブで実際の出力結果が出てくる。Readonlyで編集はできない。

これによりpromptの修正 → LLM実行のサイクルが高速で回せるので、promptingが捗る。

参考資料:

PDFからの情報抽出

[論文紹介]: 大規模言語モデルを用いたマイソク PDF からの情報抽出

LLMを用いたPDFからの情報抽出の論文

結論、OCR+GPT-4、OCRでテキスト情報を抽出後,LLMでカテゴリ情報を抽出するのが精度が最も高かったとのこと

OCRにはAzure AI Document Intelligenceを使用

敷金計算などLLMに推論させるのは、LLMならでは
(回答間違ったり、難しさもあるが)

参考資料:

Meta が Llama 3.1 405B を公開(7月23日)

実験的評価では、当社の主力モデルが、GPT-4、GPT-4o、Claude 3.5 Sonnet など、さまざまなタスクで主要な基礎モデルと競合できることが示されている。

Hugging Faceで公開されており、OSSとして利用できる。ただし405Bではかなりのパラメータ数のためスパコン前提。個人が利用するにはハードルが高すぎる。Hugging Chatで一応試すことができる。

基本性能

  • パラメータ数:123B
  • コンテキストウィンドウ:128k
  • MMLU精度:84.0%(事前学習モデル)

⁠比較

  • LLama 3.1 8BはほとんどのベンチマークでGemma 2 9Bを上回る
  • LLama 3.1 70BはほとんどのベンチマークでGPT-3.5 turboを上回る
  • LLama 3.1 405BはほとんどのベンチマークでGPT-4を上回る
  • LLama 3.1 405BはGPT-4 Omni、Claude 3.5 sonnetとほぼ互角

ライセンス条件

  • 微調整したモデルはモデル名の先頭に「Llama」を付けてください条項は残っている
  • 出力を学習に使ってはいけません条項は消えたが、出力または結果を使って学習させたモデルは先頭に「Llama」をつけてくださいね条項になった
  • 「Built with Llama」と目立つように表示してね条項もある

データセット

  • 公開されているソースからの約 15 兆トークンのデータで事前トレーニング 微調整データには、公開されている指示データセットと、2,500 万を超える合成生成された例が含まれる

参考資料:

OpenAI: SearchGPTを公表(7/25)

SearchGPTというPerplexityとほぼ同じ機能がOpenAIから発表された。

ChatGPTとは別で会話型検索ができるAIとなる。今のところはwaitlist形式で順次使えるようなるそう。(自分も8/4時点でまだ使えるようにはなっていない。)

スクレイピングにあたって、OpenAI は、次の robots.txt タグを使用して、ウェブマスターがサイトとコンテンツが AI とどのように連携するかを管理できるようにしているそう。

参考資料:

RAG vs LongContext (LC)

論文紹介:[2407.16833] Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach

Google DeepMindはRAGとロングコンテキストを包括的に比較する研究を行い、RAGはLongContextに比べて性能が劣ると結論付けたそう。一方、RAGの方が圧倒的に安価であり、コンテクストの量が多くなると優位性が出る。なので、両者をうまく使い分けるSelf-Routeを考案し、高コスパを実現した。

SELF-ROUTEは、LLM自身の判断でクエリをRAGかLLMにルーティングすることで、LLMに匹敵する性能を大幅に低いコストで実現できる。具体的には以下の2ステップからなる。

  1. RAG-and-Routeステップ: クエリと検索された情報をLLMに提示し、クエリに答えられるかどうかを判断してもらいます。答えられる場合は、RAGを使用して回答を生成します。

  2. 長文コンテキスト予測ステップ: RAG-and-Routeステップでクエリに答えられないと判断された場合、LLMに完全なコンテキストを提示して回答を生成してもらいます。

この方法により、大部分のクエリはRAG-and-Routeステップで処理できるため、計算コストを大幅に削減できる。著者らの実験では、Gemini-1.5-Proを使用した場合、82%のクエリがRAG-and-Routeステップで処理可能であることが示されました。

参考資料:

⁠プロンプトテクニック集

  • 出力に対して「これを60点として100点の解答をください」と指示する。
  • 最後に「CoTで解説して」と入れる。
  • アイデア出しの際に「ラテラルシンキングで深く深く考えて新たな地平を開拓して」と入れる
    • 現実的なアイデア出しの際はさらにこれを入れる「仮説と反証のプロセスで解像度の高いアイディアを出して」

参考資料:

Discussion