RAGのChunkingとは？（続）LLMのコンテキストウィンドウの制限を理解してチャンク化を検討する

データを分割するチャンク化とは？

チャンク化（Chunking）とは、ドキュメントから抽出したテキスト等のデータを小さな「チャンク（Chunk）」に分割するプロセスです。チャンク化は検索拡張生成（RAG）を適用するときに必要となる処理ですが、そもそもチャンク化が必要な理由は、大規模言語モデル（LLM）のコンテキストウィンドウに制限があるからです。

外部情報としてドキュメント情報をLLMに送信する際、文章内のテキスト等はプロンプトのコンテキストとしてLLMに送信されます。LLMに送信できるテキストの総量は、各LLMプロバイダーが定めるコンテキストウィンドウの上限により制限があります。なので、外部情報のデータ量が多い場合、LLMに全てのテキスト等を一括で送信することができないため、ユーザーの質問に対して文脈的に関連する部分のみを送信する必要があります。

コンテキストウィンドウとは？

大規模言語モデル（LLM）は、人間のように文章を理解し、生成することができます。しかし、LLMには一度に処理できる情報量に限界があります。この限界を「コンテキストサイズ」または「ウィンドウ」と呼びます。コンテキストウィンドウとは、 大規模言語モデル（LLM）が一度に処理できる情報量の限界を示しています。

コンテキストサイズは、「トークン」という単位で表されます。GPT-4のようなLLMのコンテキストサイズは、モデルが一度に処理できる入力トークン（単語や句読点）の最大数を指します。

例えば、GPT-3.5 Turboモデルのコンテキストサイズは4,096トークンです。これは、モデルがテキストを処理または生成する際に、最大4,096トークンの情報を同時に考慮できることを意味します。この「ウィンドウ」内に収まる情報だけがモデルの処理対象となります。

コンテキストサイズが大きいほど、LLMはより長い文章を一度に理解し、処理することができます。 例えば、長い文章を要約したり、質問に答えたり、より複雑なタスクをこなすことができます。
一方で、コンテキストサイズが大きいほど、一般的に、LLMが処理するトークン数によって課金されるこため、コストがよりかかることも念頭においておきたい点です。 また、LLMの処理速度（レイテンシ）は、トークン/秒で決まるため、トークン数が多ければ多いほど処理速度も遅延する可能性が高まります。

チャンク化のメリット・デメリットとは？

大規模言語モデル（LLM）を活用してドキュメントから情報を抽出する際、大きなドキュメントを小さなチャンクに分割する「チャンク化」をそもそも行うかどうかは、慎重に検討すべき事項です。

チャンク化を行わない場合、LLMはドキュメント全体を一度に処理するため、文脈を完全に理解し、最も正確で高品質な回答が生成できる可能性が高まります。さらに、データ抽出、ベクトル化（エンべディング）やベクトル検索エンジンといった複雑な仕組みが不要になるため、開発工数も削減できます。しかし、LLMが一度に処理できる情報量には限界があるため、情報量の多いドキュメントに対応できないというデメリットがあります。また、チャンク化せずにLLMがドキュメント全体を処理するため、コストが高く、処理に時間がかかるという点も考慮が必要です。

一方、チャンク化を行う場合は、LLMの処理範囲に合わせてドキュメントを分割するため、非常にデータ量の多いドキュメントにも対応できます。処理する情報量が少なくなるため、コストを抑え、結果生成までの時間を短縮できるのもメリットです。ただし、データ抽出、ベクトル化（エンべディング）やベクトル検索のエンジンといった追加の仕組みが必要となり、複雑なシステム構築が必要になります。さらに、LLMに適切なチャンクを渡すためのベクトル検索の検索精度は、チャンクサイズやベクトル検索方法など、様々な条件により決定されるため、回答精度を担保するための最適な条件を見つけるには試行錯誤が必要です。

メリット/デメリット	チャンク化しない	チャンク化する
メリット	1. ドキュメントの情報が正確に抽出できていればドキュメントの内容がすべて送信されるため質の高い回答が期待される 2. ベクトルデータベースやエンべディング/ベクトル化などRAGの構築が不要 3. RAGの回答品質を評価する必要がない	1. LLMのコンテキストに制限されず大量なドキュメントから情報を抽出できる 2. 小さくチャンクした情報をLLMに送信するため、コストが抑えれる 3. 小さいチャンクをLLMに送信するため、回答生成が速い
デメリット	1. 量の多い資料に対応できない 2. ドキュメント全体をLLMに送信するため、コストが高い 3. ドキュメント全体をLLMに送信するため、回答生成が遅い	1. 回答の質がRAGの仕組みに依存する品質に依存する 2. RAGの回答生成は、回答の質を左右するレバーが多い（チャンキング戦略、ベクトル検索方法、テキスト抽出、データ整形・加工、プロンプト）

チャンク化は必要かどうかの判断とは？

チャンク化が必要なケースは、大きいドキュメントから情報を抽出する必要がある場合に適しています。例えば、LLMのコンテキストサイズに収まらないほどの長いテキストを扱う場合、チャンク化を行うことで、ドキュメントの小さな部分を順次処理し、必要な情報を効率的に送信できます。高性能なRAGの仕組みを使えば高い回答精度も期待できます。また、コストを抑えたい場合や、回答生成の速度を重視する場合にもチャンク化が有効です。

一方、チャンク化が不要なケースは、比較的小さなドキュメントを扱う場合に適しています。ドキュメント全体をLLMに送信することで、文脈が完全に伝わり、高性能なRAGの仕組みを保有していなくても質の高い回答精度が期待できます。RAGの構築を避けたい場合に適しています。

ChatGPT等LLMのコンテキストウィンドウを比較

LLMのコンテキストウィンドウは徐々にサイズを拡大させている傾向にあります。ChatGPTのコンテキストウィンドウは現在約320ページ分ほどのコンテキストサイズは131,072トークンの許容があり、内容量が多くないドキュメントは十分にLLMに一回で送信できるようになってきています。

ChatGPTのコンテキストウィンドウ

• GPT-3.5 Turbo
  • コンテキストサイズ: 4,096トークン（約4K）
  • チャンクなし（最大ページ数）: 約10ページ
• GPT-4
  • コンテキストサイズ: 8,192トークン（約8K）
  • チャンクなし（最大ページ数）: 約20ページ
• GPT-4 Turbo
  • コンテキストサイズ: 131,072トークン（約128K）
  • チャンクなし（最大ページ数）: 約320ページ

LLMモデル	コンテキストサイズ	最大ページ数
Llama	2,048 (2K)	5ページ
Llama 2	4,096 (2K)	10ページ
GPT 3.5 Turbo	4,096 (4K)	10ページ
GPT 4	8,192 (8K)	20ページ
Mistral 7B	32,768 (32K)	80ページ
GPT 4 Turbo	131,072 (128K)	320ページ
Gemini 1.5 Pro	131,072 (128K)	320ページ
Claude 3 Sonnet	204,800 (200K)	500ページ

*2024年6月時点

コンテキストウィンドウが拡大したらチャンク化は不要になる？

ChatGPTに直接文章全体を送信して回答を生成してもいいドキュメントであれば、コンテキストウィンドウのサイズが拡大することで、チャンク化をせずとも良質な回答を生成することができます。

一方、特定の情報を含むドキュメントをそのまま送信することがセキュリティやプライバシーの観点から問題となる場合があります。以下、コンテキストウィンドウが拡大しても残るLLMの活用課題についてみていきましょう。

1. ドキュメントのサイズ制限

容量の大きなドキュメントや複数のドキュメントを扱う場合、その分だけ計算負荷が高くなり、処理時間も長くなります。これが、現実的な計算資源の制約となり、コンテキストウィンドウのサイズが拡大しても一度に処理できる情報量には限界がでてきます。

2. 多岐にわたる質問への対応

ユーザーの質問がいろんな確度からくると、多くの情報源からのデータを必要とします。適切な情報を提供するためには、複数のファイルからの情報源から適切な情報を検索しLLMに送信する必要があるため、ドキュメントに聞きたい回答があるかどうかわかっていない質問者が存在する場合はいくらLLMのコンテキストウィンドウが拡大してもユースケースと合致しないことが想定されます。

3. リアルタイム性

質問によってはリアルタイムで最新の情報を取得する必要があります。外部の情報源から最新のデータを取得し、リアルタイム性のある回答生成を行うには、LLMのコンテキストウィンドウにドキュメント等をアップロードするのは上記ど同様でユースケースと合致しない可能性があります。

4. 複数の情報源の統合管理

複数の異なる情報源からのデータを統合して回答を生成する必要がある場合、単一の情報源に依存せず、より多角的な視点からの情報をLLMに送信して回答を生成させる必要があります。この時に、LLMに送信した文書の量が多いと適切な回答が得られない可能性があるため、チャンク化した情報ソースをいくつか送信することが適切な場合があります。

コンテキストウィンドウの限界とRAGの重要性

大規模言語モデルは目覚ましい発展を遂げていますが、容量の大きなドキュメントや複数のドキュメントを扱う際には、 コンテキストウィンドウのサイズ という壁に直面します。コンテキストウィンドウとは、モデルが一度に処理できる情報量の上限を指します。たとえコンテキストウィンドウが拡大しても、一度に扱える情報量には限界があり、いくつかの課題が生じます。

コンテキストウィンドウの限界：

• 計算資源の制約: コンテキストウィンドウが大きくなると、それに伴って計算負荷が爆発的に増加し、高性能なハードウェアが必要になります。
• モデルの効率性: 大量の情報を処理するために、より多くの時間とエネルギーを消費し、モデル全体の効率が低下します。
• 情報の関連性: 大量の情報の中から本当に必要な情報を見つけ出すのが難しくなり、ノイズが増えて回答の精度が低下する可能性があります。例えば、数千ページのマニュアルから特定のエラーコードの原因を調べる場合、コンテキストウィンドウの制限により、関連する情報が欠落してしまう可能性があります。
• メモリの制約: 膨大な情報をメモリに保持する必要があるため、メモリ容量が不足する可能性があります。
• リアルタイム性の要求: 処理時間が長くなり、リアルタイムでの応答が難しくなります。

これらの課題を克服するために、Retrieval-Augmented Generation (RAG) が注目されています。RAGは、必要な情報を外部データベースやドキュメントから 動的に取得 し、コンテキストウィンドウに組み込むことで、上記の問題を解決します。例えば、ベクトル検索を用いて、ユーザーの質問に関連性の高い情報を効率的に探し出し、モデルに提供します。

まとめ

コンテキストウィンドウの拡大や、RAGの技術革新は今後も続いていくでしょう。より高度な検索技術や、情報統合技術の発展により、さらに大規模で複雑な情報も効率的に処理できるようになると期待されています。

RAGは、大規模言語モデルの能力を最大限に引き出し、様々な分野での応用を可能にする重要な技術です。今後、ますますその重要性が増していくと考えられます。