BioPlayground

一覧へ

「RAGとコンテキスト拡張：ラボのナレッジベースでLLMを強化する」

「なぜLLMはラボの内部データを知らないのか？ 埋め込み検索、チャンキング、ハイブリッド検索、リランキングを使用して、外部の知識をLLMに注入するためのRAGアーキテクチャの原則から実践的な応用までを解説します。」

入門
|
22分
|
検証済み (2026-07)
進捗0/15 (0%)

RAGとコンテキストの拡張：LLMに研究室の知識ベースを追加する

このトピックを修了すると

第7部で作成したドキュメント要約アシスタントには、根本的な制限があります。それは、モデルが研究室の内部データを知らないということです。過去5年間に発表した30本の論文、研究室のWikiにある200のプロトコル、会議でのプレゼンテーションで使用した100のスライドなど、これらはLLMのトレーニングデータに含まれていません。

このセクションでは、この問題を解決するアーキテクチャである**RAG（Retrieval-Augmented Generation）**について説明します。RAGは、外部の知識ベースを作成し、LLMが必要に応じて関連する部分を検索して注入できるようにすることで、質問に答えます。これは、第5部で学んだ埋め込み（embeddings）と第6部で学んだアテンションが、どのように実践で再利用されるかを見るのに最適なポイントです。

LLMの知識が格納される2つの場所

第1部で、LLMを「確率マシン」として理解し、第5部と第6部で、これらのマシンがトレーニングデータから統計的パターンを圧縮して保存し、数十億のパラメータに格納する方法を見ました。この知識がどこに存在するかをさらに詳しく見てみると、2つの場所があります。

1つ目の場所：パラメータ。 これらは、トレーニング中に学習されたものです。GPT-4が「ミトコンドリアは細胞の発電所である」という文を生成できるのは、この文（または類似の文）がトレーニングデータで繰り返し提示され、パラメータに痕跡を残したためです。この知識はモデル自体に組み込まれており、コンテキストとは独立して参照されます。

2つ目の場所：コンテキストウィンドウ。 これは、各呼び出しのプロンプトに含まれる情報です。例としては、第7部のいくつかの例、メンターの名前、およびレビューされている論文のテキストなどがあります。この知識はアテンションを通じてのみ参照されます。モデルが次の単語を予測するとき、アテンションメカニズムはコンテキストの関連部分に焦点を当て、この情報が回答に反映されます。

2つの場所は、完全に異なる特徴を持っています。

パラメータコンテキストウィンドウ
記憶場所モデルの重みプロンプト
更新方法再トレーニング（数週間から数か月）各呼び出し（即時）
容量ほぼ無制限（数十億のパラメータ）制限あり（128K〜1Mトークン）
検証不透明透明（プロンプトを確認できる）
プライバシー危険（トレーニングに含まれている場合、すべてのユーザーに公開される）安全（各呼び出しで隔離される）

LLMに研究室の30本の論文を参照させたい場合、2つの選択肢があります。

  • オプションA： これらの論文でLLMを再トレーニングまたはファインチューニングする。知識をパラメータに埋め込む。
  • オプションB： 各呼び出しで、関連する論文をコンテキストウィンドウに貼り付ける。

オプションAには、数十GBのGPUと数週間のトレーニング時間が必要です。さらに、新しい論文が追加されるたびに再トレーニングする必要があります。オプションBは、即時の更新とトレーニングを必要としません。実際には、ほとんどのアプローチはオプションBに該当します。

問題は、オプションBをどのように実装するかです。30本の論文をコンテキストに含めると、20万トークンを超える可能性があります。さらに、100本または1,000本の論文に拡張された場合、20万トークンのコンテキストモデルでは処理できません。

ここでRAGが登場します。必要な部分のみを検索して、コンテキストに含めます。 各質問について、いくつかの関連する論文または段落を検索し、コンテキストに注入します。

RAGパイプラインのフレームワーク

RAGの全体的な流れ。

text
[準備段階 - 1回のみ]
30本の論文、200のプロトコル、100のスライド
   ↓
チャンキング（段落またはセクションに分割）
   ↓
各チャンクの埋め込みを計算する（第5部の埋め込みモデル）
   ↓
ベクトルデータベースに保存する（埋め込み + 元のテキスト）

[クエリ段階 - 各呼び出し]
ユーザーの質問：「研究室でCRISPR編集効率が低い事例はありましたか？」
   ↓
質問の埋め込みを計算する（同じ埋め込みモデル）
   ↓
コサイン類似度を使用して、ベクトルDBで上位K個のチャンクを検索する
   ↓
取得したチャンクをプロンプトに貼り付ける
   ↓
LLMを呼び出して、回答を生成する

3つのコンポーネントが必要です。埋め込みモデル、ベクトルDB、およびLLMです。最初の2つのコンポーネントは検索を処理し、最後のコンポーネントは生成を処理します。これは、検索 + 生成の組み合わせであるため、RAGという名前になっています。

生物学的なアナロジー：細胞シグナルの統合をリサイクルする。 第6部では、アテンションを「細胞が周囲から関連する情報に焦点を当てる原理」として見てきました。RAGは、この原理をさらに一歩進めます。それは、細胞（LLM）が参照できる隣接する細胞（コンテキスト）を動的に拡張するシステムを追加するようなものです。アテンションがコンテキスト内の情報に焦点を当てる原理であるとすれば、RAGは各時間でコンテキスト自体を再構築する原理です。

チャンク化：チャンクサイズが検索品質に影響します

ドキュメント全体を埋め込むと、意味が1つの埋め込みに詰め込まれすぎて、検索精度が低下します。逆に、単語サイズの小さなピースに分割すると、コンテキストの欠如により、埋め込みは意味をなさなくなります。適切なチャンクサイズが必要です。

一般的なガイドライン:

  • チャンクサイズ: 200〜800トークン（約200〜1000語）
  • チャンク間のオーバーラップ: 10〜20％（境界での情報損失を防ぐため）
  • 段落またはセクションの境界で分割します（文の途中で無理に分割しないでください）

再帰的文字分割器（LangChain / LlamaIndex標準）。まず、大きな区切り記号（段落の境界）を使用して分割し、チャンクが大きすぎる場合は、次の区切り記号（文の境界）を使用して再帰的に分割し、以下同様にします。

python
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""]
)
chunks = splitter.split_text(paper.text)

生物学ドメイン固有のチャンク化:

  • 論文: 各セクション（概要、はじめに、方法、結果、考察）を個別のチャンクにします。セクションヘッダーをチャンクの先頭に追加して（コンテキストを保持するため）。
  • プロトコル: 各ステップを個別のチャンクにします。試薬のリストは、1つのチャンクにします。
  • スライド: 1つのスライド=1つのチャンク。プレゼンターノートがある場合は含めます。
  • 表と図: キャプションをチャンクのヘッダーとして使用します。表のデータは、CSVまたはMarkdown表形式で保持します。

メタデータを添付します: 各チャンクについて、元の論文情報（著者、年、ジャーナル、DOI）をメタデータとして保存します。これは後で回答でソースを表示するために使用されます。

埋め込み検索：第5部からのベクトル空間の再利用

第5部で説明した埋め込み空間が、ここでも再び登場します。今回は、個々の単語の代わりに、ドキュメントチャンク全体の埋め込みを使用します。これはドキュメント埋め込みまたは文埋め込みと呼ばれます。

埋め込みモデル: チャンクを入力として受け取り、ベクトル（通常は512〜4096次元）を出力するニューラルネットワーク。これは、「意味的に類似したチャンクは互いに近いベクトルを持ち、異なるチャンクは互いに遠いベクトルを持つ」ようにトレーニングされます。

主要な埋め込みモデル：

  • OpenAI text-embedding-3: 1つの実用的な標準。small（1536次元）とlarge（3072次元）。API呼び出し。
  • Cohere embed v3: 多言語処理に強く、低遅延。
  • Voyage AI: 最近のベンチマークで上位にランクイン。
  • Sentence-BERTシリーズ: オープンソース。all-MiniLM-L6-v2（384次元）、all-mpnet-base-v2（768次元）など。
  • BGE / E5シリーズ: 優れたオープンソースモデル。優れた多言語サポート。

生物学ドメイン固有: 一般的な埋め込みモデルは、生物学用語（遺伝子名、タンパク質名、省略形）に関しては比較的弱いです。必要に応じて：

  • BioBERT / PubMedBERT: PubMedで事前トレーニングされたBERTシリーズ。文埋め込み用にファインチューニングできます。
  • SPECTER: 論文の引用に基づいてトレーニングされた学術的な埋め込み。
  • 自己ファインチューニング: ラボデータでsentence-transformersをファインチューニングします。最高のパフォーマンスですが、データとトレーニングが必要です。

コサイン類似度は、2つのベクトルの間の類似度を測定するために使用されます。

text
similarity(u, v) = ⟨u, v⟩ / (||u|| · ||v||)

2つのベクトルが同じ方向を向いている場合は1、関連性がない場合は0、反対方向の場合は-1です。埋め込みは通常、正規化された形式（ノルム1）で保存されるため、コサイン類似度は単なる内積になります。これは、第6部の注意スコアの簡略化された形式です。

検索手順:

  1. 埋め込みモデルを使用して質問を埋め込み、質問ベクトルqを取得します。
  2. qとベクトルDB内のすべてのチャンクベクトルの間のコサイン類似度を計算します。
  3. 上位K個のチャンク（例：K = 10）を返します。

何万から何百万ものチャンクに対して各クエリを反復処理するのは遅いため、**近似最近傍探索（ANN）**インデックスが使用されます。**HNSW（階層型ナビゲーション可能な小さな世界）**が標準です。付録A.7を参照してください。

ベクトルデータベース：埋め込みを保存するための倉庫

ベクトルDB: 埋め込み+メタデータを保存し、高速な類似性検索を実行するインフラストラクチャ。主要な選択肢：

  • Chroma: オープンソース、ローカル、軽量。使い始めるのに適しています。
  • Qdrant: オープンソース、実稼働グレード。セルフホスティングとクラウドの両方をサポートします。
  • Weaviate: オープンソース、強力なスキーマ、GraphQLインターフェイス。
  • Pinecone: マネージドサービス、有料。使いやすい。
  • pgvector: PostgreSQL拡張。既存のSQLインフラストラクチャを活用します。
  • Milvus: 大規模、エンタープライズグレード。

実用的なスケール: 30の論文（それぞれ20のチャンクを持つ）は600個のベクトルです。Chromaはローカルでの使用には十分です。100,000の論文（200万のチャンク）には、QdrantやPineconeなどの実稼働グレードのツールが必要です。Chromaから始めて、必要に応じて移行します。

保存形式: 各ベクトルの場合：

json
{
  "id": "paper_2023_smith_chunk_3",
  "vector": [0.024, -0.113, ..., 0.087],  // 1536次元の浮動小数点数
  "content": "In this study, we investigated CRISPR editing efficiency in HEK293T cells...",
  "metadata": {
    "paper_id": "2023_Smith_Nature",
    "section": "Results",
    "authors": ["Smith J", "Lee H"],
    "year": 2023,
    "doi": "10.1038/..."
  }
}

## 密結合 + 疎結合：ハイブリッド検索の力

埋め込み検索（密結合検索）の弱点：それは、**正確な単語マッチング**が苦手なことです。質問に遺伝子名「TP53」が含まれており、ドキュメントにも「TP53」が含まれている場合、埋め込み空間で他の遺伝子名と混同される可能性があります。密結合検索は、遺伝子名、薬名、化学式、方程式などの正確な識別子を特定することが苦手です。

**疎結合検索**は、この弱点を補完します。これは、従来の情報検索手法です。

**BM25（Best Matching 25）**。これは、20年以上にわたり、検索エンジンの標準として使用されてきました。単語の頻度、ドキュメントの長さ、および逆ドキュメント頻度に基づいて関連性を計算します。正確な単語マッチングに優れています。

**ハイブリッド検索**。密結合と疎結合の結果を組み合わせます。

- 各手法を使用して、上位K件の結果を検索します。
- **Reciprocal Rank Fusion（RRF）**を使用して、2つの結果のランキングを組み合わせます。

RRF_score(doc) = Σ_i 1 / (k + rank_i(doc))

text
`k = 60`はデフォルト値です。各手法でのランキングが高いほど、スコアが高くなります。

**実践的なガイドライン**。多くの専門用語や識別子を含むドメイン（生物、医療、法律、特許）では、ハイブリッド検索は、密結合検索単独よりも大幅に優れた結果をもたらします。ハイブリッド検索は、一般的に検索パフォーマンスのベンチマークでより優れた結果を示します。

**最近のトレンド**。**ColBERTやSPLADE**などの学習された疎結合埋め込みが登場しています。これらは、密結合と疎結合の利点を単一のモデルに組み合わせています。最新のベンチマークで最高のパフォーマンスを発揮しています。

---

## 再ランキング：最終フィルターの力

埋め込み検索は高速ですが、**完璧に正確ではありません**。上位10件の検索結果の中に、関連性の低いものが含まれている可能性があります。

**再ランキングモデル**。検索されたK件の候補結果を再評価し、より正確なランキングを提供するモデルです。クロスエンコーダーモデルが標準です。

**双方向エンコーダー vs. クロスエンコーダー**。

- **双方向エンコーダー**（埋め込み検索）：質問とドキュメントを**別々に**埋め込みに変換し、それらの類似度を計算します。高速ですが、2つのテキスト間の相互作用は、単一の類似度スコアに圧縮されます。
- **クロスエンコーダー**（再ランキングモデル）：質問とドキュメントを**まとめて**トランスフォーマーに入力し、直接関連性スコアを計算します。正確ですが、速度は遅いです。

クロスエンコーダーは、2つのテキスト内のすべての単語ペア間の注意を計算するため（#6を参照）、より細かな判断を行うことができます。ただし、計算コストが高いため、すべてのドキュメントを処理することはできません。まず、埋め込みを使用して100件のドキュメントに絞り込み、次にクロスエンコーダーを使用して上位10件を再ランキングする、という2段階のパイプラインが標準です。

**主要な再ランキングモデル**。

- **Cohere Rerank v3**: マネージドAPI。
- **BGE-Reranker**: オープンソース、多言語対応。
- **Voyage Rerank**: ベンチマークでトップのパフォーマンス。

**効果**。上位10件の埋め込み検索結果のみを使用する場合、再ランキングモデルを追加することで、精度が60％から80％に向上することが一般的です。

---

## RAGの限界：どこで失敗するのか

RAGは万能薬ではありません。実際に遭遇する一般的なタイプの失敗。

**限界1：検索が失敗すると、回答も失敗する**。回答がベクトルデータベースにある場合でも、検索が失敗して見つからない場合、LLMはその情報を参照できません。これは、チャンク化が不適切であるか、埋め込みモデルがそのドメインに適していないか、質問が検索システムが理解できる形式で表現されていない場合に発生する可能性があります。→ 対策：**クエリの書き換え**と**複数クエリ検索**。

**限界2：複数のドキュメントからの情報の統合が難しい**。回答が複数のドキュメントにまたがり、統合が必要な場合。たとえば、「過去5年間で私たちの研究室で使用された細胞株のリスト」は、30件の論文の方法セクションを参照してコンパイルする必要があります。個々のドキュメントだけを見て回答することはできません。→ 対策：**エージェント型RAG**と**複数ホップ検索**。

**限界3：引用の正確性**。LLMが取得したドキュメントから回答を作成しても、幻覚を起こし、ドキュメントにない情報を捏造する可能性があります（#11を参照）。検索結果が存在することは、このことに対する完全な保護を保証するものではありません。→ 対策：引用を明示的に要求し、ソースの表示を強制します。

**限界4：否定的な質問**。RAGは、「私たちの研究室でどの細胞株が使用されていないか？」のように、何かの不在を尋ねる質問に対しては苦手です。これは、存在しないものを検索することが不可能であるためです。→ 対策：質問を反転させます。

**限界5：リアルタイムの情報と、検索リポジトリの遅延更新**。ベクトルデータベースはリアルタイムではないため、最新の情報を見逃す可能性があります。→ 対策：段階的な更新とリアルタイムインデックス作成。

## 長文コンテキスト時代におけるRAG：依然として必要ですか？

2024年から2025年にかけて、数百万トークンのコンテキストウィンドウを持つモデル（Gemini 1.5、Claude 3.5、GPT-4.1など）が登場し、議論を呼んでいます。問題は、「コンテキストウィンドウが非常に大きくなった今、RAGはまだ必要なのでしょうか？」ということです。

**RAGが依然として必要である理由**

- **コスト**: 各呼び出しに100万トークンを投入すると、コストとレイテンシーが急増します。RAGは、K個のチャンク（約10,000トークン）のみを投入するため、はるかに安価かつ高速です。
- **精度**: 100万トークンのコンテキストウィンドウがあっても、モデルは「途中で失われる（lost in the middle）」という問題を抱えています。RAGを使用して関連部分のみを投入することで、実際には精度が向上します。
- **スケーラビリティ**: 100万トークンでは1,000件の論文を格納できません。実際には、常にそれ以上の規模になります。
- **監査可能性と透明性**: 質問に答えるために使用されたドキュメントを追跡できます。これは、規制対象の業界にとって不可欠です。

**長文コンテキストの有用性**: 長文コンテキストは、実際にコンテキスト全体を必要とする特定のタスク（例：論文全体の詳細な分析）に最適です。RAGと長文コンテキストは、互いに代替するものではなく、むしろ**補完し合う**ものです。

**ハイブリッドアーキテクチャ**: 一般的な方法として、RAGを使用して100〜1,000個の関連チャンクを抽出し、それらを長文コンテキストモデルに供給します。これにより、RAGの検索能力と長文コンテキストの統合能力を組み合わせることができます。

---

## 生物学への応用シナリオ

### シナリオ1：研究室の論文とプロトコルの知識チャットボット

研究室の30本の論文 + 200のプロトコル + 教授の講義ノートをRAGでインデックス化します。SlackボットまたはWeb UIを通じて質問を投げかけます。

```python
# 準備（一度だけ）
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings

splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
docs = load_lab_documents()  # 論文、プロトコル、ノート
chunks = splitter.split_documents(docs)

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = Chroma.from_documents(chunks, embeddings, persist_directory="./lab_db")

# クエリ（各呼び出しごと）
def ask_lab(question):
    docs = vectorstore.similarity_search(question, k=10)
    context = "\n\n".join([d.page_content for d in docs])
    
    prompt = f"""あなたは、当研究室の資料を参照して質問に答えるアシスタントです。

以下の資料に基づいて質問に答え、回答の中で各証拠のソースを[著者、年、セクション]で示してください。
情報が資料にない場合は、「当研究室の資料には記載されていません」と答えてください。

資料：
{context}

質問：{question}
回答："""
    
    return llm(prompt, temperature=0)

# 使用例
ask_lab("CRISPR編集効率が20％を下回ったケースはありましたか？")

システムプロンプトでソースの明示を強制し、資料外の情報を拒否します。#7のプロンプトルールと組み合わせます。

シナリオ2：臨床試験文献検索アシスタント

特定の疾患または治療に関する臨床試験の結果を包括的に検索します。

  • データソース: ClinicalTrials.gov、PubMed、会議の抄録。
  • チャンク化: 各試験を1つのドキュメントとして扱います。抄録、プロトコル、および結果を個別のチャンクとして扱います。
  • ハイブリッド検索: BM25は、薬名や遺伝子名に対して強力であるため、ハイブリッド検索が不可欠です。
  • リランキング: 臨床的な関連性を判断する精度は、回答の品質にとって重要です。
  • メタデータフィルター: ベクトル検索と、"フェーズ3"、"2020年以降"、"成人のみ"などのフィルターを組み合わせます。

このようなアシスタントは、CROや病院の研究チームで現在導入されています。

シナリオ3：遺伝子とタンパク質の知識QA

BioBERT埋め込み + UniProtおよびEnsemblのデータを使用して、遺伝子QAを行います。

  • 各遺伝子のUniProtページを、複数のチャンク（機能、構造、疾患、PTMなど）に分割します。
  • ドメイン固有の埋め込み（BioBERT）を使用します。
  • ユーザーの質問："TP53と相互作用するキナーゼは何ですか？" → 関連するチャンクを検索 → LLMが要約します。

これは、最近の商業的な生物学ツールの根幹となる技術です（Elicit、Consensusなど）。

主なポイント

  • LLMの知識が存在する2つの場所：パラメータ（組み込み、再トレーニングが必要）およびコンテキストウィンドウ（即時的、有限）。
  • RAGは、外部知識をコンテキストに動的に注入するアーキテクチャです。検索と生成の組み合わせです。
  • パイプライン：チャンク化 → 埋め込み → ベクトルデータベース → 検索 → プロンプト注入 → LLM。
  • チャンク化は、200〜800トークン + 10〜20％のオーバーラップです。セクションの境界を尊重します。
  • 埋め込み検索は、埋め込み空間の自然な拡張です（#5を参照）。コサイン類似度を使用します。
  • ベクトルデータベース - まずChromaから始め、QdrantとPineconeでスケールアップします。
  • ハイブリッド検索（疎 + BM25）は、正確な識別子のマッチングを強化します。RRFと組み合わせます。
  • リランキング（クロスエンコーダー）は、最終的な精度を向上させます。2段階のパイプラインです。
  • 制限事項: 検索の失敗、情報の統合、引用エラー、否定的な質問。
  • 長文コンテキスト時代においても、RAGは有効です。その理由：コスト、精度（「途中で失われる」）、およびスケーラビリティ。

📐 付録 — 専門家向け数学的公式

難易度: 非常に難しい 対象読者: 情報検索、確率、最適化の知識を持つ読者。

A.1 コサイン類似度と内積

2つのベクトル u, v ∈ ℝ^d に対して:

text
cos_sim(u, v) = ⟨u, v⟩ / (||u||_2 · ||v||_2)

ベクトルが正規化されている場合 (||u||_2 = 1)、コサイン類似度は内積と等しくなります。

text
cos_sim(u, v) = ⟨u, v⟩ = Σ_i u_i v_i

アテンションスコアとの関連 (セクション6)。アテンションにおける ⟨Q_i, K_j⟩ も、内積の形をとっています。RAGにおける検索は、概念的にアテンションにおける初期スコア計算と等価です。

A.2 埋め込みモデルのトレーニングにおけるコントラスト学習

Sentence-BERTファミリーで採用されています。類似するペアは近づけられ、類似しないペアは遠ざけられます。

トリプレット損失:

text
L = max(0, ||f(a) - f(p)||^2 - ||f(a) - f(n)||^2 + margin)

a: アンカー、p: ポジティブ（類似）、n: ネガティブ（類似しない）。ネガティブ例は、margin（例：0.5）によってさらに遠ざけられます。

InfoNCE損失 (SimCLRファミリー、業界標準):

text
L = -log[ exp(sim(f(a), f(p)) / τ) / Σ_k exp(sim(f(a), f(k)) / τ) ]

τ: 温度。ミニバッチ内の他の例は、自動的なネガティブ例として使用されます。

A.3 BM25の公式

ドキュメント D、クエリ Q = {q_1, ..., q_n}:

text
BM25(D, Q) = Σ_i IDF(q_i) · TF(q_i, D) · (k_1 + 1) / (TF(q_i, D) + k_1 · (1 - b + b · |D| / avgdl))
  • IDF(q_i) = log((N - n_i + 0.5) / (n_i + 0.5) + 1)。N: ドキュメントの総数、n_i: q_i を含むドキュメントの数。
  • TF(q_i, D): ドキュメント D における q_i の頻度。
  • avgdl: 平均ドキュメント長。
  • パラメータ: k_1 = 1.2~2.0、b = 0.75。

直感: 頻出する単語は、IDFが低くなり、重みも小さくなります。単語がドキュメントに頻繁に出現する場合、TFは高くなります。長いドキュメントは正規化されます。30年間、検索エンジンの標準として使用されてきました。

A.4 リシプロカル・ランク・フュージョン (RRF)

複数の検索方法のランキングを組み合わせます。

text
RRF_score(d) = Σ_{r ∈ R} 1 / (k + rank_r(d))
  • R: 検索方法のセット（例：密ベクトル、疎ベクトル）。
  • rank_r(d): 方法 r におけるドキュメント d のランク（1が最高）。
  • k = 60（経験的なデフォルト値）。

利点: 各方法の絶対的なスコアではなく、ランクのみを使用します。スケールの違いを無視できます。

A.5 クロスエンコーダーによるリランキングの公式

クロスエンコーダーの入力:

text
[CLS] question [SEP] document [SEP]

トランスフォーマー（BERT/RoBERTaファミリー）は、このシーケンス全体に対してアテンション計算を行います。[CLS] トークンの最終的な表現は、線形レイヤーを通過して、関連性スコアが得られます。

text
score = W · h_{CLS} + b

計算コスト: バイエンコーダーは2つのエンコーダーを独立して計算するため、K個のドキュメントを検索する場合、2K 回のエンコーダーの処理が必要です。クロスエンコーダーは、各(Q, D)ペアに対してエンコーダーを処理するため、K 回のエンコーダーの処理が必要ですが、Kが大きい場合ははるかに遅くなります。

実際には、バイエンコーダーで100個のドキュメントを検索し、その後、クロスエンコーダーで上位10個をリランキングするというパイプラインが使用されます。

A.6 HNSWインデックス

階層型ナビゲーブル・スモールワールド。現在、近似最近傍探索の標準として使用されています。

構造: 階層型グラフ。上位層は疎（ノードが少なく、エッジが長い）、下位層は密（ノードが多く、エッジが短い）。検索中、アルゴリズムは上位層を大まかにナビゲートし、その後、下位層で正確な検索を行います。

時間計算量: O(log N) — 正確な検索 O(N) よりもはるかに高速です。

精度: パラメータ（M、ef_construction、ef_search）で調整可能です。通常、95%以上のリコールを維持できます。

メモリ: ベクトル自体 + グラフ構造。グラフのオーバーヘッドは約、ベクトルのサイズの1〜2倍です。

A.7 クエリ書き換え技術

HyDE（Hypothetical Document Embeddings）:

  1. LLMに質問を入力して、「仮説的な回答ドキュメント」を生成します。
  2. これらの仮説的な回答を埋め込み、検索に使用します。

理由: 質問と回答は異なる表現を持ちますが、回答と回答は類似した表現を持ちます。仮説的な回答を使用して検索することで、実際の回答を含むドキュメントとの一致を改善します。

マルチクエリ:

  1. LLMを使用して、質問を複数の方法で書き換えます（異なる表現、異なる角度）。
  2. 各クエリで検索し、結果を組み合わせます。

A.8 長いコンテキストにおける「中央に埋もれる」現象

Liu et al.（2023）によって観察されました。LLMは、長いコンテキストの最初と最後の情報はうまく見つけることができますが、中央の情報を見逃す傾向があります。

精度曲線: コンテキストの位置をx軸に、回答率をy軸にプロットすると、U字型の曲線が得られます。最初/最後は90%、中央は60%。

軽減策:

  • 重要な情報を、コンテキストの最初または最後に配置します。
  • リランキングを使用して、上位のスニペットをコンテキストの最初に配置します。
  • RAGを使用して、コンテキストを関連部分のみに圧縮し、長いコンテキストを使用する代わりに、関連部分のみを使用します。

A.9 RAGの確率的正規化

質問 q、回答 a、ドキュメントスニペット d。

ナイーブベイズの視点:

text
P(a | q) = Σ_d P(a | q, d) · P(d | q)
  • P(d | q): 検索確率（埋め込み類似度）。
  • P(a | q, d): ドキュメントが与えられた場合の回答の確率（LLM）。

フュージョン・イン・デコーダー (FiD)。取得されたK個のドキュメントそれぞれを独立してエンコードし、その後、デコーダーで結合します。RETROとAtlasはこのアプローチを使用します。

Retrieval-Augmented Language Model (RALM)。検索をモデルのパラメータ自体に統合します。RETROとREALM。各トレーニングステップ中に参照します。

A.10 RAGのパフォーマンス指標

検索段階:

  • Recall@K: 正しい回答が上位K個に含まれている割合。
  • Precision@K: 上位K個のうち、実際に関連しているものの割合。
  • MRR（平均逆順位）: 正しい回答の順位の逆数の平均。
  • NDCG（正規化割引累積ゲイン）: ランク付けされた関連性。

生成段階:

  • 忠実性: 回答が取得されたドキュメントに基づいているかどうか。
  • 回答の関連性: 回答が質問に関連しているかどうか。
  • コンテキストの精度/リコール: 取得されたコンテキストに、回答に必要な情報が含まれているかどうか。

ツール: RAGASやTruLensなどのフレームワークは、これらの指標を自動的に測定します。

参考文献

このセクションのすべてのコンテンツ、シナリオ、アナロジー、および図は、BioPlaygroundによって社内で作成されたものであり、以下の参考文献は、概念の学習に役立つ外部リソースです。

  • RAGのオリジナル論文: Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (NeurIPS 2020)
  • Dense Passage Retrieval: Karpukhin et al., "Dense Passage Retrieval for Open-Domain Question Answering" (EMNLP 2020)
  • BM25: Robertson & Zaragoza, "The Probabilistic Relevance Framework: BM25 and Beyond" (2009)
  • Sentence-BERT: Reimers & Gurevych, "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks" (EMNLP 2019)
  • HNSW: Malkov & Yashunin, "Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs" (TPAMI 2020)
  • Lost in the Middle: Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (TACL 2023)
  • HyDE: Gao et al., "Precise Zero-Shot Dense Retrieval without Relevance Labels" (ACL 2023)
  • Fusion-in-Decoder: Izacard & Grave, "Leveraging Passage Retrieval with Generative Models" (EACL 2021)
  • RETRO: Borgeaud et al., "Improving language models by retrieving from trillions of tokens" (ICML 2022)
  • BioBERT: Lee et al., "BioBERT: a pre-trained biomedical language representation model" (Bioinformatics 2020)
  • LangChainのドキュメント: python.langchain.com
  • LlamaIndexのドキュメント: docs.llamaindex.ai
  • Anthropic Contextual Retrieval: anthropic.com/news/contextual-retrieval

第8節では、LLMに外部知識を追加する方法を学びました。第9節では、LLMが独自にツール（検索、計算、API呼び出し）を使用するエージェントパターンについて説明します。

次のテーマ

  • 編 #9 agent-and-tool-use — LLMがツールを呼び出すエージェントパターン。RAGもエージェントのツールのひとつです。
  • 編 #10 context-window-management — コンテキストウィンドウを効果的に管理するための実践的な手法。
  • 編 #11 hallucination-and-alignment — なぜRAGは幻覚を完全に防ぐことができないのか。

💬 質問・コメント

0件のコメント

ログインせずに投稿できます。ゲスト投稿は投稿者自身で編集・削除できません。

0/2000

読み込み中...