RAG チャンキング フェーズ

テスト ドキュメントとクエリを収集し、 準備フェーズ中にドキュメント分析を実行した後、次のフェーズ (チャンク) に移動します。 チャンク化とは、ドキュメントを意味的に関連するコンテンツを含む適切なサイズのチャンクに分割することです。 取得拡張生成 (RAG) の実装を成功させるには非常に重要です。 ドキュメント全体または特大のチャンクを渡そうとすると、コストが高く、モデルのトークン制限に圧倒され、最適な結果が得られない可能性があります。 また、クエリとは無関係な言語モデルに情報を渡すと、不正確または無関係な応答が発生する可能性があります。 プロセスを最適化し、関連情報を渡し、無関係な情報を削除するには、効果的なチャンクと検索の戦略を使用する必要があります。 このアプローチでは、誤検知と偽陰性を最小限に抑え、真陽性と真陰性を最大化します。

チャンクが小さすぎて、クエリに対処するための十分なコンテキストが含まれていないと、結果が低下する可能性があります。 複数のチャンクにまたがって存在する関連コンテキストは、キャプチャされない場合があります。 重要なのは、特定のドキュメントの種類とその特定の構造とコンテンツに対して効果的なチャンクアプローチを実装することです。 適用するドキュメントの種類と構造に応じて、それぞれ独自のコストの影響と効果を持つさまざまなチャンクアプローチを検討する必要があります。

この記事では、さまざまなチャンクアプローチについて説明し、ドキュメントの構造が選択したチャンクアプローチにどのように影響するかを調べます。

この記事はシリーズの一部です。 続行する前に 、概要 をお読みください。

チャンクの経済学を理解する

全体的なチャンク戦略を決定するときは、ドキュメントコレクションの予算、品質、スループットの要件を考慮してください。 それぞれの固有のチャンク実装とドキュメントごとの処理コストの設計と実装には、アプローチによって異なるエンジニアリング コストがあります。 ドキュメントに埋め込みメディアまたはリンクされたメディアが含まれている場合は、それらの要素の処理の経済性を考慮する必要があります。 チャンクの場合、この処理では通常、言語モデルを使用してメディアの説明が生成されます。 これらの説明は分割されます。 メディアによっては、推論を行う際にマルチモーダルモデルにそのまま渡す方法が一つの方法です。 ただし、このアプローチはチャンクングの経済性には影響しません。

次のセクションでは、画像のチャンクの経済性と全体的な解決策について説明します。

画像チャンク処理の経済性を理解する

チャンクするイメージの説明を生成する言語モデルでは、追加コストが発生します。 たとえば、Azure OpenAI サービスなどのクラウドベースのサービスは、トランザクション単位または前払いのプロビジョニング単位で課金されます。 画像が大きくなるほどコストも大きくなります。 ドキュメント分析を使用して、チャンクにとって重要な画像と無視する画像を決定します。 そこから、ソリューション内のイメージの数とサイズを理解する必要があります。 次に、画像の説明をチャンク化する価値を生成コストと比較して評価します。

Azure AI Vision などのサービスを使用して、処理するイメージを決定します。 画像を分類したり、画像にタグを付けたり、ロゴの検出を行ったりすることができます。 結果と信頼度インジケーターを使用して、画像が意味のあるコンテキスト値を追加し、処理する必要があるかどうかを判断できます。 Vision の呼び出しは、言語モデルの呼び出しよりもコストが低くなる可能性があるため、このアプローチによりコストが削減される可能性があります。 データに最適な結果を提供する信頼度レベルと分類またはタグを決定する実験。 また、次の代替手段も検討してください。

• 独自の分類子モデルを構築します。 この方法を使用する場合は、独自のモデルを構築、ホスト、保守するためのコストを考慮してください。

• 言語モデルを使用して、画像の分類とタグ付けを行います。 この方法を使用すると、設計の柔軟性が向上しますが、Vision を使用する場合よりも予測しにくい場合があります。 可能であれば、両方の方法を試し、結果を比較します。

もう 1 つのコスト最適化戦略は、 Cache-Aside パターンを使用してキャッシュすることです。 イメージのハッシュに基づくキーを生成できます。 最初の手順として、前の実行または以前に処理されたドキュメントからキャッシュされた結果があるかどうかを確認します。 そうであれば、その結果を使用できます。 この方法では、分類子または言語モデルを呼び出すコストが不要になります。 キャッシュがない場合は、分類子または言語モデルを呼び出すときに結果をキャッシュします。 このイメージの今後の呼び出しでは、キャッシュが使用されます。

次のワークフローは、これらのコスト最適化プロセスを統合します。

1. 画像処理がキャッシュされているかどうかを確認します。 その場合は、キャッシュされた結果を使用します。

2. 分類子を実行して、画像を処理する必要があるかどうかを判断します。 分類結果をキャッシュします。 分類ロジックで画像が値を追加すると判断された場合は、次の手順に進みます。

3. 画像の説明を生成します。 結果をキャッシュします。

ソリューション全体の経済性を検討する

ソリューション全体のコストを評価するときは、次の要因を考慮してください。

• 一意のチャンク実装の数: それぞれの固有の実装には、エンジニアリングとメンテナンスのコストがあります。 コレクション内の一意のドキュメントの種類の数と、それぞれの固有の実装のコストと品質のトレードオフを考慮してください。

• 各実装のドキュメントごとのコスト: チャンクアプローチによっては、チャンクの品質が向上する可能性がありますが、それらのチャンクを生成するための財務コストと時間コストが高くなります。 たとえば、Azure AI ドキュメント インテリジェンスで事前構築済みモデルを使用すると、純粋なテキスト解析実装よりもドキュメントごとのコストが高くなる可能性がありますが、チャンクが向上する可能性があります。

• 初期ドキュメントの数: ソリューションを起動するために処理する必要がある初期ドキュメントの数。

• 増分ドキュメントの数: システムの継続的なメンテナンスのために処理する必要がある新しいドキュメントの数とレート。

読み込みとチャンク処理を理解する

チャンク中は、まずドキュメントを何らかの形式でメモリに読み込む必要があります。 次に、チャンキング コードはドキュメントのメモリ内表現に対して動作します。 読み込みコードを分割処理と組み合わせるか、別のフェーズで読み込みを実行することができます。 アーキテクチャの制約とユーザー設定に基づいてアプローチを選択します。 次のセクションでは、両方のオプションについて簡単に説明し、一般的な推奨事項を示します。

ロード処理とチャンク処理を分離する

読み込みフェーズとチャンク フェーズを分離する理由はいくつかあります。 読み込みコードにロジックをカプセル化することもできます。 チャンクの前に読み込みコードの結果を保持したい場合があります。特に、さまざまなチャンク順列を試して処理時間やコストを節約する場合です。 最後に、プロセスのバルクヘッドや、個人データの削除を伴うセキュリティセグメント化など、アーキテクチャ上の理由から、読み込みとチャンクのコードを別々のプロセスで実行することができます。

読み込みコードにロジックをカプセル化する

読み込みフェーズで前処理ロジックをカプセル化することを選択できます。 この方法では、プリプロセスを必要としないため、チャンク コードが簡略化されます。 前処理は、ドキュメント分析で無視するドキュメントの一部を削除または注釈付けするのと同じくらい簡単です。 たとえば、透かし、ヘッダー、フッターを削除したい場合があります。 または、前処理には、ドキュメントの再フォーマットなどのより複雑なタスクが含まれる場合があります。 たとえば、読み込みフェーズに次の前処理タスクを含めることができます。

• 無視する項目を削除または注釈を付けます。

• 画像参照を画像の説明に置き換えます。 このフェーズでは、大きな言語モデルを使用してイメージの説明を生成し、その説明でドキュメントを更新します。 ドキュメント分析中に、重要なコンテキストを提供する周囲のテキストが見つかると、テキストと画像を大規模な言語モデルに渡すことができます。

• ドキュメント テキストとは別に処理されるように、Azure Data Lake Storage などのファイル ストレージにイメージをダウンロードまたはコピーします。 ドキュメント分析中に、画像に貴重なコンテキストを提供する周囲のテキストが見つかる場合は、このテキストを画像と共にファイル ストレージに格納できます。

• テーブルをより簡単に処理できるように、テーブルを再フォーマットします。

• 見出し、小見出し、およびその他の構造要素に基づいてドキュメント構造を定義します。 実用的な場合は 、ドキュメント インテリジェンス などのツールを使用して、開発のオーバーヘッドを削減します。 または、外部システムに送信できない機密データがある場合は、Python などのライブラリを使用できます。

読み込みコードの結果を保持する

読み込みコードの結果を保持することを選択する理由は複数あります。 読み込まれて前処理された後、チャンク ロジックが実行される前にドキュメントを検査する機能が必要な場合。 または、開発中または運用環境で、同じ前処理済みコードに対して異なるチャンク ロジックを実行する必要があります。 読み込まれたコードを永続化すると、プロセスが高速化されます。

ロードとチャンクのコードを別々のプロセスで実行する

プロセスを分離すると、同じ前処理されたコードに対して複数のチャンク実装を実行するのに役立ちます。 また、さまざまなコンピューティング環境や異なるハードウェアで、コードの読み込みとチャンクを実行することもできます。 この設計は、読み込みとチャンクに使用するコンピューティングを個別にスケーリングするのに役立ちます。

読み込みとチャンキングを組み合わせる

ほとんどの場合、読み込みとチャンク コードの組み合わせは、より簡単な実装です。 個別の読み込みフェーズで行うことを検討する可能性のある多くの前処理操作は、チャンク フェーズ中に実行できます。 たとえば、読み込みフェーズでイメージ URL を説明に置き換える代わりに、チャンク ロジックで大規模な言語モデルを呼び出してテキストの説明を取得し、説明をチャンクすることができます。

画像への参照を含むタグを含む HTML などのドキュメント形式がある場合は、チャンク コードで使用されるリーダーまたはパーサーがタグを削除しないようにします。 分割コードは、画像参照を識別できる必要があります。

チャンク化に関する推奨事項を検討する

チャンク ロジックを組み合わせるか分離するかについて、次の推奨事項を検討してください。

• まず、読み込みとチャンクのロジックを組み合わせることから始めます。 ソリューションで必要な場合は分離してください。

• プロセスを分離することを選択した場合は、ドキュメントを中間形式に変換しないでください。 この種類の操作では、データが失われる可能性があります。

チャンク化の方法を確認する

このセクションでは、一般的なチャンク方法の概要について説明します。 言語モデルの使用を組み合わせて画像のテキスト表現を取得するなど、実装では複数の方法を使用できます。

要約された意思決定マトリックスは、各アプローチに付随します。 マトリックスでは、ツール、関連するコストなどが強調表示されます。 ここで説明するエンジニアリング作業と処理コストは主観的であり、相対的な比較に含まれています。

固定サイズの解析 (重複あり)

この方法では、固定数の文字またはトークンに基づいてドキュメントをチャンクに分割し、チャンク間の文字の重複を許可します。 このアプローチには、文ベースの解析と同じ長所と短所が多数あります。 文ベースの解析よりもこのアプローチの利点の 1 つは、複数の文にまたがるセマンティックな意味を持つチャンクを取得できることです。

チャンクの固定サイズと重複の量を選択する必要があります。 結果はドキュメントの種類によって異なるため、Hugging Face チャンク ビジュアライザーなどのツールを使用して探索的分析を行うことをお勧めします。 このようなツールを使用して、決定に基づいてドキュメントがどのようにチャンクされるかを視覚化できます。 固定サイズの解析を使用する場合は、文字数の代わりにトランスフォーマー (BERT) トークンからの双方向エンコーダー表現を使用する必要があります。 BERT トークンは意味のある言語単位に基づいているため、文字数よりも多くのセマンティック情報を保持します。

Tools:LangChain 再帰テキスト スプリッター、 Hugging Face チャンク ビジュアライザー
エンジニアリング作業: 低
処理コスト: 低い
ユース ケース: 完全な文または不完全な文で記述された非構造化文章。 ドキュメントのコレクションには、膨大な数の種類のドキュメントがあり、それぞれに個別のチャンク化戦略が必要です。
例： アンケート、フォーラムの投稿、レビュー、電子メール メッセージ、個人用ノート、リサーチ ノート、リストからのオープンエンド フィードバックなどのユーザー生成コンテンツ

セマンティック チャンキング

この方法では、埋め込みを使用して、概念的に似たコンテンツをドキュメント全体にグループ化してチャンクを作成します。 セマンティック チャンクは、コンテンツの件名に近いわかりやすいチャンクを生成できます。 このアプローチのロジックでは、ドキュメントまたは一連のドキュメントを検索し、繰り返しの情報を見つけて、言及やセクションをまとめるチャンクを作成できます。 この方法では、複雑なカスタム ロジックを開発する必要があるため、コストが高くなります。

ツール： カスタム実装。 spaCy などの自然言語処理 (NLP) ツールは、文ベースの解析に役立ちます。
技術的な取り組み： 盛ん
処理コスト: 高い
ユース ケース: セクション全体でトピックの重複があるドキュメント
例： 財務または医療に重点を置いたドキュメント

カスタム コード

この方法では、カスタム コードを使用してチャンクを作成することでドキュメントを解析します。 カスタム コードアプローチは、構造が既知または推論可能なテキストベースのドキュメントに最適です。 カスタム コードアプローチでは、チャンクの作成を高度に制御する必要があります。 正規表現などのテキスト解析手法を使用し、ドキュメントの構造内のパターンに基づいてチャンクを作成できます。 目標は、長さが同じサイズのチャンクと、コンテンツが異なるチャンクを作成することです。 多くのプログラミング言語では正規表現がサポートされており、一部には、よりエレガントな文字列操作機能を提供するライブラリまたはパッケージがあります。

Tools:Python (re, regex, BeautifulSoup, lxml, html5lib, marko), R (stringr, xml2), Julia (Gumbo.jl)
エンジニアリングの取り組み: 中程度
処理コスト: 低
ユース ケース: 構造を推論できる半構造化ドキュメント
例： 特許出願、研究論文、保険契約、スクリプト、およびスクリーンプレイ

言語モデルの拡張

言語モデルを使用してチャンクを作成できます。 たとえば、GPT-4 などの大規模な言語モデルを使用して、画像のテキスト表現やチャンクになるテーブルの概要を生成します。 言語モデル拡張は、多くの場合、カスタム コードなどの他のチャンク アプローチで使用されます。

ドキュメント分析で、画像の前または後のテキストが いくつかの要件の質問に答えるのに役立つと判断された場合は、この追加のコンテキストを言語モデルに渡します。 この追加コンテキストによってソリューションのパフォーマンスが向上するかどうかを調べるには、実験することが重要です。

チャンク ロジックによってイメージの説明が複数のチャンクに分割される場合は、各チャンクにイメージ URL を含めて、イメージが提供するすべてのクエリに対してメタデータが確実に返されるようにします。 この手順は、ユーザーがその URL を介してソース イメージにアクセスしたり、推論時に生画像を使用したりする必要があるシナリオに不可欠です。

ツール:Azure OpenAI、 OpenAI
エンジニアリングの取り組み: 中程度
処理コスト: 高い
ユース ケース: イメージ、テーブル
例： 表と画像のテキスト表現の生成、会議、スピーチ、インタビュー、またはポッドキャストからのトランスクリプトの要約

ドキュメント レイアウト分析

ドキュメント レイアウト分析ライブラリとサービスは、光学式文字認識 (OCR) 機能とディープ ラーニング モデルを組み合わせて、ドキュメントの構造とテキストの両方を抽出します。 構造要素には、ヘッダー、フッター、タイトル、セクション見出し、表、図などがあります。 目的は、ドキュメントに含まれるコンテンツに対して、より優れたセマンティックな意味を提供することです。

ドキュメント レイアウト分析ライブラリとサービスは、ドキュメントの構造コンテンツとテキスト コンテンツを表すモデルを公開します。 モデルと対話するコードは引き続き記述する必要があります。

ツール:ドキュメント インテリジェンス ドキュメント分析モデル、 ドーナツ、 レイアウト パーサー
エンジニアリングの取り組み: 中程度
処理コスト: 中程度
ユース ケース: 半構造化ドキュメント
例： ニュース記事、Web ページ、履歴書

グラフベースのチャンク処理

グラフベースのチャンクは、言語モデルを使用してドキュメント内のキーワードなどのエンティティを検索し、そのリレーションシップに基づいてグラフを作成する反復的なアプローチです。 グラフ作成プロセスをより効率的にするために、段落ベースなどのより簡単なチャンク戦略から始めることができます。 最初のチャンクを作成したら、各チャンクを分析してエンティティとリレーションシップを見つけ、グローバル グラフ構造を構築できます。 チャンクを反復処理するときにグラフを追加できます。

ツール:Microsoft GraphRAG、Neo4J
技術的な取り組み： 盛ん
処理コスト: 高い
ユース ケース: 多様な統計データ
例： スポーツ分析、履歴データ、ドキュメント間で計画外の定量的クエリを必要とするドメイン

事前構築済みのモデル

ドキュメント インテリジェンスなどのサービスには、さまざまな種類のドキュメントに使用できる事前構築済みのモデルが用意されています。 一部のモデルは、米国の W-2 税フォームなどの特定のドキュメントの種類に対してトレーニングされ、他のモデルは請求書などのより広範な種類のドキュメントの種類を対象としています。

ツール:ドキュメント インテリジェンス事前構築済みモデル、 Power Automate インテリジェント ドキュメント処理、 LayoutLMv3
エンジニアリング作業: 低
処理コスト: 中/高
ユース ケース: 事前構築済みモデルが存在する構造化ドキュメント
例： 請求書、領収書、健康保険証、W-2 フォーム

カスタム モデル

事前構築済みモデルが存在しない高度に構造化されたドキュメントの場合は、カスタム モデルの構築が必要になる場合があります。 この方法は、高度に構造化された画像やドキュメントに有効であり、テキスト解析手法の使用が困難になります。

ツール:ドキュメント インテリジェンス カスタム モデル、 Tesseract
技術的な取り組み： 盛ん
処理コスト: 中/高
ユース ケース: 事前構築済みモデルが存在しない構造化ドキュメント
例： 自動車の修理とメンテナンスのスケジュール、学歴、記録、技術マニュアル、運用手順、メンテナンス ガイドライン

文ベースの解析

文ベースの解析は、テキスト ドキュメントを完全な文で構成されるチャンクに分割する簡単なアプローチです。 ここで説明する他の方法がユース ケースに適合しない場合は、このアプローチをフォールバック ソリューションとして使用します。 このアプローチの利点には、実装と処理のコストが低く、散文または完全な文を含むテキスト ベースのドキュメントに適用できる点が挙げられます。 このアプローチの欠点の 1 つは、各チャンクがアイデアや意味の完全なコンテキストをキャプチャしない可能性があるということです。 セマンティックの意味をキャプチャするには、多くの場合、複数の文をまとめる必要があります。

ツール:spaCy 文分割ツール、LangChain 再帰的テキスト分割ツール、NLTK 文分割ツール
エンジニアリング作業: 低
処理コスト: 低い
ユース ケース: 散文または完全な文で記述された非構造化ドキュメント。 ドキュメントのコレクションには、個々のチャンク戦略を必要とする、手に負えないほどさまざまな種類のドキュメントが含まれています。
例： アンケート、フォーラムの投稿、レビュー、電子メール メッセージ、小説、エッセイからのオープンエンドフィードバックなどのユーザー生成コンテンツ

ドキュメントの構造

ドキュメントは構造の種類によって異なります。 政府の形式のような一部のドキュメントには、米国の W-2 税フォームなど、複雑で既知の構造があります。 その真逆に、自由形式のノートのような非構造化ドキュメントがあります。 ドキュメント型の構造の程度は、効果的なチャンクアプローチを決定するための出発点として適しています。 特定の規則はありませんが、このセクションでは、いくつかのガイドラインに従う必要があります。

構造化ドキュメント

構造化ドキュメント (固定形式ドキュメントとも呼ばれます) には、定義されたレイアウトが含まれています。 これらのドキュメント内のデータは固定の場所にあります。 たとえば、日付または顧客ファミリ名は、同じ固定形式を持つすべてのドキュメントの同じ場所にあります。

固定形式のドキュメントは、手入力または複雑なレイアウト構造を持つ元のドキュメントの画像をスキャンすることがあります。 この形式では、基本的なテキスト解析アプローチを使用して処理するのが困難になります。 複雑なドキュメント構造を処理する一般的なアプローチは、機械学習モデルを使用してデータを抽出し、可能であればそのデータにセマンティックな意味を適用することです。

例： W-2フォームと保険証
一般的な方法: 事前構築済みモデルとカスタム モデル

半構造化ドキュメント

半構造化ドキュメントには、W-2 フォームのような固定形式またはスキーマはありませんが、形式またはスキーマに関する一貫性が提供されます。 たとえば、請求書はレイアウトによって異なりますが、一般的にはスキーマが一貫しています。 請求書には、請求書番号、何らかの形式の請求先と配送先の名前と住所、その他のデータが含まれていることが期待できます。 Web ページにはスキーマの一貫性がない場合がありますが、 本文、 タイトル、 H1、 p などの構造要素やレイアウト要素が類似しており、周囲のテキストにセマンティックな意味を追加できます。

構造化ドキュメントと同様に、複雑なレイアウト構造を持つ半構造化ドキュメントは、テキスト解析を使用して処理するのが困難です。 これらのドキュメントの種類では、機械学習モデルが適切なアプローチです。 請求書、契約、医療保険のドキュメントなど、一貫したスキーマを持つ特定のドメインには、事前構築済みのモデルがあります。 事前構築済みモデルが存在しない複雑な構造の場合は、カスタム モデルの構築をご検討ください。

例： 請求書、領収書、Web ページ、および Markdown ファイル
一般的な方法: ドキュメント分析モデル

推論された構造体

ドキュメントによっては、構造はあってもマークアップで記述されていないものがあります。 これらのドキュメントの場合、構造を推論する必要があります。 次の EU 規制ドキュメントは、その良い例です。

ドキュメントの構造を明確に理解でき、それに関する既知のモデルがないため、カスタム コードを記述する必要があります。 このドキュメント形式では、使用するこの種類の異なるドキュメントの数によっては、カスタム モデルを作成する作業が保証されない場合があります。 たとえば、コレクションに EU のすべての規制または米国の州法が含まれている場合は、カスタム モデルが適切なアプローチである可能性があります。 この例の EU 規制のように、1 つのドキュメントを使用する場合、カスタム コードの方がコスト効率が高い場合があります。

例： 法律文書、スクリプト、製造仕様
一般的な方法: カスタム コードとカスタム モデル

非構造化ドキュメント

構造がほとんどまたはまったくないドキュメントに対して、文ベースまたは重複を伴う固定サイズのアプローチが適しています。

例： アンケート、フォーラムの投稿、レビュー、電子メール メッセージ、個人用ノート、リサーチ ノートからのオープンエンド フィードバックなどのユーザー生成コンテンツ
一般的なアプローチ: 重複を含む文ベースまたは境界ベース

実験

この記事では、各ドキュメントの種類に最も適したチャンクアプローチについて説明しますが、実際には、どの方法でも任意のドキュメントの種類に適している可能性があります。 たとえば、文ベースの解析は高度に構造化されたドキュメントに適している場合もあれば、カスタム モデルが非構造化ドキュメントに適している場合もあります。 RAG ソリューションの最適化の一環として、さまざまなチャンクアプローチを試します。 持っているリソースの数、リソースの技術的スキル、処理する必要があるドキュメントの量を検討します。 最適なチャンク戦略を実現するには、各アプローチをテストし、利点とトレードオフを観察して、ユース ケースに最適なアプローチを選択していることを確認します。

次のステップ

関連リソース

• Azure AI 検索でベクトル検索ソリューション用に大規模な文書を分割する方法
• Azure AI 検索の統合データのチャンキングと埋め込み