RAG チャンキングフェーズ

2025-04-19

テストドキュメントとクエリを収集し、準備フェーズ中にドキュメント分析を実行した後、次の段階は文書を適切な単位に分割するプロセスです。ドキュメントを適切なサイズのチャンクに分割し、それぞれに意味的に関連するコンテンツを含めるのは、Retrieval-Augmented 生成 (RAG) 実装を成功させるために不可欠です。全部のドキュメントまたは大きすぎるチャンクを渡すとコストがかかり、モデルのトークン制限を超える可能性があり、最適な結果が得られません。クエリに関係のない情報を言語モデルに渡すと、不正確または無関係な応答が発生する可能性があります。効果的なチャンクと検索の戦略を使用して、関連情報を渡し、無関係な情報を削除するプロセスを最適化する必要があります。このアプローチでは、誤検知と偽陰性を最小限に抑え、真陽性と真陰性を最大化します。

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

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

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

チャンキングの経済学

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

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

画像チャンキングの経済学

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

処理する画像を決定する 1 つの方法は、 Azure AI Vision などのサービスを使用して画像を分類したり、画像にタグを付けたり、ロゴ検出を行ったりすることです。その後、結果と信頼性インジケーターを使用して、画像が意味のある文脈的価値を追加し、処理する必要があるかどうかを判断できます。 Vision の呼び出しは、言語モデルの呼び出しよりもコストが低くなる可能性があるため、このアプローチによりコストが削減される可能性があります。データに最適な結果を提供する信頼度レベルと分類またはタグを決定する実験。もう 1 つのオプションは、独自の分類モデルを構築することです。このアプローチを使用する場合は、独自のモデルを構築、ホスト、保守するためのコストを考慮してください。

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

次の単純なワークフローでは、これらすべてのコスト最適化プロセスが統合されています。

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

全体的なソリューションの経済性

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

一意のチャンク実装の数: それぞれの固有の実装には、エンジニアリングとメンテナンスのコストがあります。コレクション内の一意のドキュメントの種類の数と、それぞれの固有の実装のコストと品質のトレードオフを考慮してください。
各実装のドキュメントごとのコスト: チャンクアプローチによっては、チャンクの品質が向上する可能性がありますが、それらのチャンクを生成するための財務コストと時間コストが高くなります。たとえば、Azure AI ドキュメントインテリジェンスで事前構築済みモデルを使用すると、純粋なテキスト解析実装よりもドキュメントごとのコストが高くなる可能性がありますが、チャンクが向上する可能性があります。
初期ドキュメントの数: ソリューションを起動するために処理する必要がある初期ドキュメントの数。
増分ドキュメントの数: システムの継続的なメンテナンスのために処理する必要がある新しいドキュメントの数とレート。

読み込みとチャンキング

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

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

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

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

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

無視する項目を削除または注釈を付けます。
画像参照を画像の説明に置き換えます。このフェーズでは、大きな言語モデルを使用してイメージの説明を生成し、その説明でドキュメントを更新します。ドキュメント分析フェーズで、画像に貴重なコンテキストを提供する周囲のテキストがあると判断した場合は、そのテキストを画像と共に大きな言語モデルに渡します。
ドキュメントテキストとは別に処理されるように、Azure Data Lake Storage などのファイルストレージにイメージをダウンロードまたはコピーします。ドキュメント分析で、画像に貴重なコンテキストを提供する周囲のテキストがあると判断した場合は、このテキストを画像と共にファイルストレージに格納します。
テーブルをより簡単に処理できるように、テーブルを再フォーマットします。

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

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

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

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

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

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

画像への参照を含むタグを持つ HTML などのドキュメント形式がある場合は、チャンクコードで使用されているリーダーまたはパーサーがタグを取り除かないことを確認します。チャンキングコードは画像参照を識別できる必要があります。

推奨事項

チャンクロジックを組み合わせるか分離するかを決定するときは、次の推奨事項を考慮してください。

まず、読み込みとチャンクロジックを組み合わせることから始めます。ソリューションで必要な場合は分離してください。
プロセスを分離することを選択した場合は、ドキュメントを中間形式に変換しないでください。この種類の操作では、データが失われる可能性があります。

チャンキング手法

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

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

文ベースの解析

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

ツール:spaCy 文分割ツール、LangChain 再帰的テキスト分割ツール、NLTK 文分割ツール
エンジニアリング作業: 低
処理コスト: 低い
使用例: 散文や完全な文で構成されている非構造化ドキュメント、および個別の分割戦略が必要な多くの種類のドキュメントが含まれるドキュメントコレクションがあります
例：アンケート、フォーラムの投稿、レビュー、電子メールメッセージ、小説、エッセイからのオープンエンドフィードバックなどのユーザー生成コンテンツ

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

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

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

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

カスタムコード

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

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

言語モデルの拡張

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

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

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

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

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

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

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

注

ドキュメントインテリジェンスは、ドキュメントをアップロードする必要があるクラウドベースのサービスです。セキュリティとコンプライアンスの規制により、そのようなサービスにドキュメントをアップロードできるようにする必要があります。

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

事前構築済みのモデル

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

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

カスタムモデル

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

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

ドキュメントの構造

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

構造化ドキュメント

構造化ドキュメント (固定形式のドキュメントとも呼ばれます) には、定義済みのレイアウトが用意されています。これらのドキュメント内のデータは固定の場所にあります。たとえば、日付や顧客の姓は、同じ固定形式のすべてのドキュメントで同じ場所にあります。固定形式のドキュメントの例として、米国の W-2 税ドキュメントがあります。

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

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

半構造化ドキュメント

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

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

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

推論された構造体

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

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

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

非構造化ドキュメント

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

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

実験

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

次のステップ

チャンクエンリッチメントフェーズ

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