最終更新：2025年10月25日

RAGチャンキング完全ガイド｜精度向上の最新戦略・実装・評価【2025年版】

この記事を読むとRAGの精度を左右するチャンキングの全手法（固定長～Agentic）がわかり、文書タイプに応じた最適な戦略を自信を持って選択・実装・評価できるようになります。

📖 読了 22分｜🎯対象：AI開発者・プロダクトマネージャー・Tech Lead
🛠 難易度：★★★★☆

この記事の結論：RAGの性能はチャンキング戦略に大きく依存します（一説には70%とも）。2025年現在、Late ChunkingやRAPTOR等の先進技術を理解し、文書タイプに応じて最適な手法を選択・評価することが、RAGプロジェクト成功の鍵です。

要点1：基本は「固定長＋オーバーラップ」だが、文脈喪失が課題。
要点2：「Late Chunking」は文脈保持とコストのバランスに優れる2025年の有力技術。
要点3：「RAPTOR」「Parent-Child」「Agentic」など高度な戦略は、文書特性とコストに応じて導入を検討。
要点4：最適な戦略は文書依存。RAGAS等のフレームワークで客観的評価が必須。

→ 最適な手法の選び方は「第5章：実践ガイド」へ、最新技術の詳細は「第2章」「第3章」へ。

Q1. RAGにおけるチャンキングとは何ですか？

A. 大規模な文書を、AI（LLMやエンベディングモデル）が処理しやすい小さな単位（チャンク）に分割するプロセスです。この分割方法がRAGの検索精度や回答品質に直接影響します。

Q2. 2025年で最も注目されているチャンキング技術は何ですか？

A. 「Late Chunking」です。文書全体をエンベディングした後に分割することで、従来手法の弱点だった文脈喪失問題を解決し、コストと精度のバランスが良いとされています。

Q3. 最適なチャンクサイズはいくつですか？

A. 残念ながら「万能なサイズ」はありません。文書タイプやエンベディングモデルに依存するため、512トークン前後から始め、RAGAS等の評価ツールで客観的に評価し調整することが不可欠です。

この記事の著者・監修者　ケニー狩野（Kenny Kano）

Arpable 編集部（Arpable Tech Team）

株式会社アープに所属するテクノロジーリサーチチーム。人工知能の社会実装をミッションとし、最新の技術動向と実用的なノハウを発信している。
役職：(株)アープ取締役。Society 5.0振興協会・AI社会実装推進委員長を務める。中小企業診断士、PMP。著書に『リアル・イノベーション・マインド』

RAGの精度を向上させるチャンク最適化手法

Toggle

序論：RAGの精度を決める「見えない7割」— チャンク分割の罠

要約：「AIの回答が的外れ」— その原因の多くはチャンク分割にあります。近年の研究ではRAG性能の大半がこの工程に依存すると指摘されており、戦略的な最適化が不可欠です。

「なぜAIは私の質問に正しく答えられないのか？」

2025年春、ある大手製薬会社の開発チームは、数千ページに及ぶ研究論文をRAGシステムに組み込みました。最新のGPT-4oを使い、高価なベクトルデータベースを導入し、完璧なはずでした。しかし、研究者からの質問「この薬剤の副作用は何ですか？」に対する回答は、関係ない別の薬剤の情報や、文脈が切れた断片的な説明ばかり。回答精度は期待を大きく下回りました。

これは他人事ではありません。あなたのプロジェクトが、今この瞬間も同じ落とし穴に陥っている可能性は、極めて高いのです。

問題は、最新のLLMでも、高性能なベクトルDBでもありませんでした。犯人は「チャンク分割」—文書を小さな単位に分割する、一見地味なこの工程でした。

近年の研究では、RAGシステムの最終的な性能の大部分が、このチャンキング戦略に依存している可能性が指摘されています。実務家の間では「チャンキングはRAG性能の7割を決める」という格言が広まっているほどです。つまり、どんなに優れたLLMを使っても、チャンク分割が不適切であれば、システムの潜在能力の多くは失われてしまうのです。

この記事では、RAGの精度を根本的に改善するチャンク分割の最適化手法を、2025年10月の最新動向を交えて徹底解説します。特に：

Late Chunking：2025年に急速に普及した革新的手法
RAPTOR / Parent-Child：階層的理解を実現する高度なアプローチ
Semantic Chunking / Agentic Chunking：意味や文脈を考慮した知的分割

これらの技術を理解し実装することで、あなたのRAGシステムは劇的に改善されるでしょう。

第1章：なぜチャンク分割がRAGの成否を握るのか？

要約：チャンク分割は「サイズ」「文脈」「コスト」という３つのジレンマを抱えています。単純な固定長分割では、重要な情報が欠落するリスクが常に伴います。

まず、チャンク分割の本質的な難しさを理解しましょう。

チャンク分割の３つのジレンマ

RAGシステムのチャンク分割には、避けられない三つのジレンマがあります：

サイズの矛盾 (Size Dilemma):
- 大きすぎるチャンク → 無関係な情報まで含み、検索精度（特にRecall）が低下する。LLMが処理すべきノイズが増える。
- 小さすぎるチャンク → 文脈が失われ、断片的な情報しか得られない。LLMが意味のある回答を生成できない。
文脈の分断 (Context Fragmentation):
- 例：「この薬剤は効果的です。ただし、高齢者には投与量を減らす必要があります。」
- この文章を「。」で分割したら？「効果的です」だけが検索され、重要な注意事項（ただし書き）が失われる可能性があります。
コストとの戦い (Cost vs. Completeness):
- 理想的には文書全体の文脈を保持したい。しかし、LLMのコンテキストウィンドウには制限があり、トークン数に応じてAPIコストが発生します。計算速度（レイテンシ）も考慮が必要です。

これらのジレンマがあるため、「万能な」チャンク分割戦略は存在せず、文書タイプやユースケースに応じた最適化が不可欠となります。

製薬会社の失敗から学ぶ（再訪）

冒頭の製薬会社の事例に戻りましょう。彼らは最も単純な「固定長チャンキング」（512トークン、オーバーラップなし）を使っていました。その結果、副作用に関する重要な記述がチャンク境界で分断されてしまいました。

🤔 固定長分割の悲劇

元の文（一部）： 「…この薬剤の主な副作用は頭痛、めまい、[改行]吐き気です。重篤な場合、心臓への影響が報告されています…」

固定長チャンク（512トークン境界が「めまい、」と「吐き気」の間）：

チャンク1: 「…この薬剤の主な副作用は頭痛、めまい、」
チャンク2: 「吐き気です。重篤な場合、心臓への影響が…」

結果： 「副作用は？」という質問に対し、チャンク1しか検索されず（類似度が高いため）、肝心の「吐き気」や「心臓への影響」がユーザーに提示されない、という致命的な問題が発生しました。

この問題を解決するために登場したのが、より文脈を考慮した新世代のチャンキング技術です。

🔍 チェックリスト：あなたのRAGシステムは大丈夫ですか？

□ 回答に無関係な情報が混入していませんか？
□ 重要な注意書きや結論が検索結果に含まれていますか？
□ 代名詞（「それ」「この」）が正しく解決されていますか？

1つでも「いいえ」なら、それは「チャンク分割の問題」かもしれません。

第2章：【2025年最重要】Late Chunking：文脈喪失を克服する

要約：Late Chunkingは「エンベディング後」に分割する逆転の発想で、チャンク間の文脈を保持します。コストと精度のバランスに優れ、2025年の有力な選択肢です。

2024年秋（9月の論文発表）から急速に注目を集め、2025年に入って実装が広がっているのがLate Chunking（レイトチャンキング）です。これは、チャンキングの常識を覆すアプローチで、文脈喪失問題を解決します。

「逆転の発想」が解決した文脈の断絶

従来の常識（Naive Chunking）： 1. 文書を先に分割する → 2. 各チャンクを個別に埋め込む → 3. DBに保存（文脈喪失）
Late Chunkingの逆転の発想： 1. 文書全体（または長文ブロック）を先に埋め込む → 2. その後にチャンク化する（文脈保持）

具体的には、Jina AIの`jina-embeddings-v2`のような長文コンテキスト（8192トークン）対応モデルを使用し、まず文書全体をTransformerで処理します。これにより、各トークン（単語）が文書全体の文脈を理解したベクトルを持ちます。その後、トークンレベルのベクトルを指定のチャンクサイズに分割（例：平均プーリング）します。

具体例で理解する：ベルリンの問題（解決編）

第1章の問題例をLate Chunkingで処理するとどうなるでしょうか。

✅ Late Chunkingによる解決

元の文： 「ベルリンはドイツの首都です。その都市は385万人以上の人口を持ち…」

Late Chunkingのプロセス：

文書全体を長文対応モデルでエンベディング → 各トークンが「ベルリン」の文脈を持つベクトルを獲得。
エンベディング後にチャンク境界で分割。

結果：

チャンク1: ベクトルA（「ベルリン」「首都」の意味を強く持つ）
チャンク2: ベクトルB（「人口」「385万」に加え、「その都市」=「ベルリン」という文脈情報もベクトルに反映されている）

これにより、「ベルリンの人口は？」という検索クエリに対し、チャンク2が非常に高い類似度スコアでヒットするようになります。

なぜLate Chunkingが優れているのか？

代名詞の解決： 「その」「この」「それ」などが何を指すか正確に理解できます。
文脈依存の意味： 「Apple」が「果物」か「会社」か、文書全体から判断できます。
コストパフォーマンス： ColBERTのような超高精度手法（計算コスト大）と、従来手法（低コストだが文脈喪失）の中間に位置し、両者の良いとこ取りができます。AnthropicのContextual Retrieval（LLMで要約生成）と同等の効果を、追加LLMなしで実現できる可能性があります。

実装と注意点

Jina Embeddingsを使えば比較的簡単に実装可能です。（注：2025年10月現在、`jina-embeddings-v3`がリリースされています。v3では性能が更に向上していますが、Late Chunkingの原理は同じです。）

from jina_embeddings import JinaEmbeddings

# Late Chunking対応モデル（例: v2, 最大8,192トークン）
model = JinaEmbeddings('jina-embeddings-v2-base-en') 
# voyage-3 (32k) なども利用可能

# 文書全体を処理
document = "ベルリンはドイツの首都です。その都市は..."

# ここで文書をチャンクに分割する関数を定義 (例: split_into_chunks)
chunks_text = split_into_chunks(document, chunk_size=512) 

# Late Chunkingでエンベディング
# model.encode は内部で文書全体を処理し、指定されたチャンク境界でベクトルを生成
embeddings = model.encode(
    chunks_text, 
    batch_size=32 # 必要に応じて調整
    # late_chunking=True # (JinaEmbeddingsではデフォルト有効の場合あり、要確認)
) 
# 各チャンクのエンベディングが、全体の文脈を保持

重要な注意点：

長文コンテキストモデル（8K+トークン対応）が必須です。標準的なエンベディングモデル（例：512トークン制限）では効果がありません。
2025年10月現在、MilvusなどのベクトルDBやLangChain（実験的サポート）でも対応が進んでいます。実装のハードルは低下しています。

Late Chunking vs Contextual Retrieval

AnthropicのContextual Retrieval（LLMで各チャンクに要約文を生成・付与する手法）との比較研究（2025年）もあります。

（表）Late Chunking vs Contextual Retrieval 比較
手法	長所	短所	コスト
Late Chunking	高効率、実装が容易	8K/32Kトークン制限あり	低
Contextual Retrieval	セマンティック一貫性が最高	計算コスト大（LLM呼び出し多発）	高

実務的な選択指針： 予算制約があり、8K/32K以下の文書なら Late Chunking。予算潤沢で最高精度が必要なら Contextual Retrieval。超長文なら次章の RAPTOR を検討します。

第3章：高度なチャンキング戦略（階層化・AI駆動）

要約：長文や複雑な文書には、階層的に情報を捉えるRAPTORやParent-Child Retrieval、AIが分割を最適化するAgentic Chunkingといった高度な戦略が有効です。

Late Chunkingでも対応が難しい「超長文」や「多様な質問粒度」に対応するため、さらに高度な戦略が登場しています。

RAPTOR：Late Chunkingを超える「木構造」の世界

Late Chunkingのトークン制限（8K/32K）を超える文書（例：10万トークン以上の年次報告書）には、2024年にスタンフォード大学から発表されたRAPTOR (Recursive Abstractive Processing for Tree-Organized Retrieval)が有効です。

RAPTORは、文書を複数の抽象度レベルで理解する「木構造（ツリー）」を構築します。

クラスタリング： 多数の初期チャンク（例：512トークン）を意味的に近いグループにまとめます。GMM（ガウス混合モデル）を使用し、チャンクが複数のクラスタに所属できるようにします（k-meansとの違い）。
要約生成： 各クラスタについて、LLMが要約を生成します。この要約が次の階層の「ノード（チャンク）」となります。
再帰的処理： ステップ1-2を繰り返し、ピラミッド型の階層構造を構築します。

利点：

マルチホップ推論に強い： 複数のトピックにまたがる複雑な質問（例：「起動方法とエラー対処法は？」）に、階層を横断して回答できます。
具体と抽象の両立： 具体的な質問は下位ノード、抽象的な質問は上位ノードで対応。
定量的な改善実績： 論文では従来比20-30%の精度向上が報告されています。2025年にはRAGFlow v0.6.0に統合され、実用性が向上しています。

課題： LLMトークンの大量消費です。要約生成にGPT-4を使うと、1文書あたり$5~$50のコストがかかる場合もあります。軽量モデル（Gemini Flash等）の活用や選択的要約が必須です。

実装ツール： LangChain `RAPTORRetriever`, LlamaIndex `RAPTORPack`, RAGFlow。

Parent-Child Retrieval（親子検索）：精度と文脈の両立

「小さいチャンク（高精度）と大きいチャンク（高文脈）のジレンマ」を解決する、より実践的な手法がParent-Child Retrievalです。

仕組み：
1. 文書を2種類のサイズで分割：検索用の子チャンク（例：400トークン）と、文脈保持用の親チャンク（例：2000トークンまたは段落全体）。
2. 検索は高精度な子チャンクで行う。
3. ヒットした子チャンクのIDから、対応する親チャンクを取得。
4. LLMには、文脈が豊富な親チャンクを渡して回答を生成させる。
利点： 検索精度（小さいチャンク）と回答品質（大きいチャンク）を両立できます。RAPTORよりシンプルで実装しやすいです。
注意点： 2種類のストレージ（ベクトルストア＋ドキュメントストア）が必要です。親チャンクがLLMのコンテキスト上限を超えないよう注意が必要です。

実装ツール： LangChain `ParentDocumentRetriever`.

from langchain.retrievers import ParentDocumentRetriever
from langchain_text_splitters import RecursiveCharacterTextSplitter
# 親チャンク分割 (例: 段落ごと)
parent_splitter = RecursiveCharacterTextSplitter(chunk_size=2000, separators=["\n\n"])
# 子チャンク分割
child_splitter = RecursiveCharacterTextSplitter(chunk_size=400)

retriever = ParentDocumentRetriever(
    vectorstore=vectorstore, # 子チャンクのベクトルDB
    docstore=docstore,       # 親チャンクのKeyValueストア
    child_splitter=child_splitter,
    parent_splitter=parent_splitter,
)
# retriever.add_documents(docs) でデータを追加
# retrieved_docs = retriever.get_relevant_documents("質問文") で親チャンクを取得

Agentic Chunking（AI駆動型）：究極の適応的分割

従来のルールベース（固定長、セパレータ）ではなく、AIエージェント（LLM）自身が文書の内容を理解し、最適な分割方法を動的に決定するのがAgentic Chunkingです。

仕組み： LLMが文書を読み、トピック境界や意味的な一貫性を評価。チャンクサイズを動的に調整し、重要なセクションは大きく、詳細は小さく分割。チャンクにメタデータ（トピック、重要度）も付与します。
利点： 文脈に応じた究極の最適化が可能。法律契約書の「責任条項」だけ詳細に分割するなど、人間が行うようなインテリジェントな分割を実現します。
課題： 計算コストが非常に高い（文書ごとにLLM呼び出し）。リアルタイム処理には不向きで、再現性もLLM依存です。
推奨適用シーン： 高価値文書（法律、医療、金融）のオフライン前処理で、精度がコストよりも圧倒的に重要な場合。

第4章：固定サイズ vs セマンティック：2025年の現実解

要約：最新研究では、多くの場合「固定長＋オーバーラップ」がコスト対効果で最適と示唆されています。セマンティックチャンキングは計算コストが高く、限定的な状況でのみ有効です。

高度な手法が注目される一方、最も基本的な「固定長分割」と「セマンティック分割」のどちらが実用的か、2025年時点での結論が見えてきました。

NVIDIA / 学術研究から得られた衝撃的な結論

2024年後半から2025年にかけて発表されたNVIDIAの大規模ベンチマークやNAACL 2025（自然言語処理のトップカンファレンス）の研究論文は、驚くべき結果を示唆しています。

結論1： 「トークンベース固定長（512トークン、128オーバーラップ）」が多くの実世界のユースケースで最適なパフォーマンス（精度、速度、コストのバランス）を示しました。
結論2： セマンティックチャンキングは、固定長と比較して性能差がほとんど無い場合が多く、むしろ計算コストが35～50倍も高いことが判明しました。
結論3： セマンティックチャンキングの利点が確認されたのは、「高度にトピックが多様なデータセット（例：複数の法律分野が混在する文書群）」という限定的な状況のみでした。

これは、「高度な手法＝常に優れている」という直感に反する結果であり、RAGコミュニティに大きな議論を巻き起こしました。

推奨戦略（2025年版）

これらの最新研究を踏まえた、2025年現在の実践的な推奨戦略は以下の通りです。

💡 チャンキング戦略の選び方（2025年10月）

デフォルトは「固定長＋オーバーラップ」から始める：
- サイズ：512トークン
- オーバーラップ：128トークン (サイズの25%程度)
- 理由：コスト効率、実装容易性、予測可能な性能のバランスが最も良い。
文書特性に応じて調整する：
- 構造化文書（技術マニュアル、APIドキュメント）：Recursive Chunking（セパレータ指定）を試す価値あり。
- 会話ログ、短文集：より小さい固定サイズ（例：256トークン）を検討。
特定の課題があれば高度な手法を検討：
- 文脈喪失（代名詞など）が深刻な問題の場合：Late Chunkingを試す（コスト増）。
- 文書のトピックが極めて多様（法律、医療）：セマンティックチャンキングを試す（高コスト）。
- 超長文、多様な質問粒度への対応が必要：Parent-Child Retrieval または RAPTORを検討（高コスト・高複雑性）。

最重要ポイント： チャンキング戦略単体で完璧を目指すのではなく、エンベディングモデルの品質や、後段のリランキングとの組み合わせで、システム全体の精度を最適化する視点が重要です。

第5章：実践ガイド：意思決定フレームワークと実装Tips

要約：最適な手法は文書タイプ、予算、精度要件で決まります。フローチャートを参考に、まずはベースライン（固定長）から始め、RAGAS等で評価しながら段階的に高度化するのが現実的です。

これまでの情報を基に、あなたのプロジェクトに最適なチャンキング戦略を選択するための実践的なフレームワークを提供します。

意思決定フローチャート

1. 文書の長さと構造は？
- 短文集 (FAQ, ニュース): → チャンキング不要 or 最小限 (文単位)
- 中程度の長さ (〜8K/32Kトークン): → ステップ2へ
- 長文 (32Kトークン超) / 階層構造あり: → RAPTOR / Parent-Child を検討 (高コスト)
2. 文脈依存度と予算は？ (中長文の場合)
- 文脈依存度が高い (代名詞多い, 専門用語):
  - 予算あり → Late Chunking ★推奨★
  - 予算制約あり → 固定長＋大きめのオーバーラップ(25%)で妥協
- 文脈依存度が低い / トピックが極めて多様:
  - 予算あり → セマンティックチャンキング
  - 予算制約あり → 固定長＋オーバーラップ(10-20%) ← 多くの場合はこれで十分
3. 最高精度が必須か？ (コスト度外視)
- Yes → Agentic Chunking (オフライン) / Contextual Retrieval を検討

ケーススタディ：業界別の最適解

ケース1：製薬会社の研究論文 (5-20ページ)
- 課題：具体的副作用と全体的効果の両方に対応したい。精度最優先。
- 推奨：RAPTOR (階層構造で対応) または Late Chunking (32K以内なら)
ケース2：ECサイトのカスタマーサポート (商品説明, FAQ)
- 課題：商品説明の代名詞解決。コスト重視。リアルタイム性。
- 推奨：Late Chunking (低コスト版モデル) または 固定長＋オーバーラップ
ケース3：法律事務所の契約書分析 (50-200ページ)
- 課題：長文。条項検索と全体解釈の両立。精度とコストのバランス。
- 推奨：RAPTOR + キャッシング (重要文書のみ) + セマンティック (その他) のハイブリッド。

実装ロードマップ（3段階アプローチ）

フェーズ1：ベースライン構築（1週間）
- 目標：最小限で動作確認。
- 手法：固定長 (512トークン) + オーバーラップ (128トークン)
- 理由：実装が最も簡単。ベースライン精度を測定。
フェーズ2：精度向上（2～4週間）
- 目標：本番レベルの精度達成。
- 手法：Late Chunking または セマンティックチャンキング を試す。
- 理由：コストと精度のバランスが良い。
- 評価：RAGAS等で定量評価。
フェーズ3：最適化（継続的）
- 目標：ユースケースに最適な手法を選択。
- 手法：必要に応じ Parent-Child や RAPTOR へ移行。
- 理由：実データでのA/Bテスト結果に基づく。

メタデータ戦略：チャンキング時に必ず付与すべき情報

どのチャンキング戦略を採用するにせよ、生成されたチャンクには豊富なメタデータを付与することが極めて重要です。

必須メタデータ例：
- `source`: 元のファイル名やURL
- `page_number`: PDFのページ番号
- `section`: 章や節の見出し
- `chunk_index`: 文書内でのチャンクの連番
- `start_index`, `end_index`: 元文書内での文字/トークン位置
高度なメタデータ例：
- `parent_id` (Parent-Child用)
- `summary` (RAPTOR用)
- `keywords` (ハイブリッド検索用)

これらのメタデータは、検索時のフィルタリング（例：「page_number=5のチャンクのみ検索」）や、LLMへのコンテキスト提供、引用元の表示に不可欠です。

第6章：チャンキング戦略の評価方法

要約：最適なチャンキングは文書依存のため、客観的な評価が必須です。RAGAS等のフレームワークを使い、検索精度（Recall@k, MRR）と生成品質（Faithfulness）で評価します。

どのチャンキング戦略が自分のデータセットに最適かを知る唯一の方法は、評価です。

なぜ評価が必要か？

「最適なチャンクサイズ」や「最適な分割手法」は、文書の性質（構造、言語、トピック密度）、使用するエンベディングモデル、想定される質問の種類によって大きく異なります。理論だけでは決まらず、試行錯誤とデータに基づいた評価が不可欠です。

間接評価：下流タスク（RAG）のパフォーマンスで測る

チャンク単体の「良さ」を直接測るのは困難です。最も実践的なのは、異なるチャンキング戦略を適用した結果、最終的なRAGシステムのパフォーマンスがどう変化するかを測定する「間接評価」です。

評価プロセス：

複数のチャンキング戦略候補（例：固定長512 vs 再帰的512 vs Late Chunking）を用意。
各戦略で同じ文書群を処理し、ベクトルDBを構築。
評価用の質問応答データセット（Ground Truth）を用意。
各ベクトルDBに対し、同じRAGシステム（同じエンベディングモデル、LLM、プロンプト）を実行。
得られた検索結果と生成された回答を、Ground Truthと比較し、以下の指標で評価。

主要な評価指標（RAGASフレームワーク）

オープンソースの評価フレームワークRAGAS (Retrieval-Augmented Generation Assessment)を使うと、以下の主要指標を効率的に測定できます。

検索（Retrieval）の評価：
- Context Precision: 取得したチャンクのうち、本当に質問と関連性のあるものはどれくらいか？（ノイズの少なさ）
- Context Recall: 回答に必要な情報を含むチャンクを、どれだけ見逃さずに取得できたか？（網羅性）
- (補足) Chromaの提案する**IoU (Intersection over Union)**も、取得効率と精度のバランスを見る指標として参考になります。
生成（Generation）の評価：
- Faithfulness (忠実性): 生成された回答は、取得したチャンクの内容にのみ基づいているか？（ハルシネーションのなさ）
- Answer Relevancy (回答関連性): 生成された回答は、元の質問の意図にきちんと答えているか？

これらの指標を比較することで、「どのチャンキング戦略が、我々のデータセットと質問タイプに対して最も効果的か」を客観的に判断できます。

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_recall,
    context_precision,
)

# 評価データセット (質問、正解、RAGの回答、取得したコンテキスト)
dataset_dict = {
    "question": ["What causes...?","How to fix...?"],
    "answer": ["The main cause is...","Follow these steps..."],
    "contexts": [
        ["Chunk text 1...", "Chunk text 2..."], # Strategy A result
        ["Chunk text 3...", "Chunk text 4..."]  # Strategy B result
    ],
    "ground_truth": ["Correct answer 1...", "Correct answer 2..."] 
}
dataset = Dataset.from_dict(dataset_dict)

# RAGASで評価実行
result = evaluate(
    dataset,
    metrics=[
        context_precision,
        context_recall,
        faithfulness,
        answer_relevancy,
    ],
    # llm=my_llm, # 必要に応じて評価用LLMを指定
    # embeddings=my_embeddings # 必要に応じて評価用Embeddingsを指定
)

print(result) 
# {'context_precision': 0.85, 'context_recall': 0.90, ...}

定期的にこの評価プロセスを実行し、チャンキング戦略やパラメータ（サイズ、オーバーラップ）を継続的に改善していくことが、高性能なRAGシステムを維持する鍵となります。