テスト ドキュメントとクエリを収集し、 準備フェーズでドキュメント分析を実行したので、次のフェーズはチャンキングです。 ドキュメントを、それぞれ意味的に関連するコンテンツを含む適切なサイズのチャンクのコレクションに分割することは、検索拡張生成 (RAG) 実装の成功の重要な要素です。 全部のドキュメントまたは大きすぎるチャンクを渡すとコストがかかり、モデルのトークン制限を超える可能性があり、最適な結果が得られません。 クエリに関係のない大規模言語モデルに情報を渡せば、幻覚につながる可能性があります。 関連のある情報を渡し、無関係な情報を削除するプロセスを最適化する必要があります。 この最適化は、効果的なチャンク化と検索戦略を使用して、擬陽性と偽陰性を最小限に抑え、真陽性と真陰性を最大化することで行います。
小さすぎるチャンクや、クエリに対処できるだけの十分なコンテキストが含まれていないチャンクを渡すと、良い結果を得られません。 複数のチャンクにまたがって存在する関連コンテキストは、キャプチャされない場合があります。 必要なのは、特定のドキュメントの種類、およびその構造とコンテンツに対して、効果的なチャンク アプローチを実装する技術です。 検討すべきチャンク アプローチはさまざまあり、適用されるドキュメントの種類と構造に応じて、コストへの影響や効果はそれぞれ異なります。
この記事では、さまざまなチャンク アプローチについて説明し、ドキュメントの構造が選択したチャンク アプローチにどのような影響を及ぼす可能性があるかを調査します。
この記事はシリーズの一部です。 概要を参照してください。
チャンクの経済性
全体的なチャンキング戦略を決定する際には、ドキュメント コーパスの品質とスループットの要件とともに予算を考慮する必要があります。 固有のチャンク実装ごとの設計と実装にはエンジニアリング コストがかかり、ドキュメントごとの処理コストはアプローチによって異なります。 ドキュメントに埋め込まれたメディアやリンクされたメディアがある場合は、それらの要素を処理する経済性を考慮する必要があります。 チャンキングの場合、この処理では通常、言語モデルを使用してメディアの説明を生成し、それらの説明をチャンク化します。 一部のメディアに対する代替アプローチとしては、推論時にメディアをそのままマルチモーダル モデルに渡すというものがあります。ただし、このアプローチはチャンキングの経済性には影響しません。
このセクションでは、画像のチャンク化と全体的なソリューションの両方の経済性を検討します。
画像チャンク経済学
言語モデルを使用して画像の説明を生成し、それをチャンク化するとコストがかかります。 たとえば、Azure OpenAI などのクラウドベースのサービスでは、トランザクションごとに基本料金が請求されるか、前払いのプロビジョニング ベースで料金が請求されます。 画像が大きくなるほどコストも大きくなります。 ドキュメント分析を通じて、チャンクする価値のある画像と無視するべき画像を決定する必要があります。 そこから、ソリューション内の画像の数とサイズを理解し、画像の説明をチャンク化することの価値とそれらの説明を生成するコストを比較検討する必要があります。
処理する画像を決定する 1 つの方法は、 Azure AI Vision などのサービスを使用して、画像を分類したり、画像にタグを付けたり、ロゴを検出したりすることです。 その後、結果と信頼性インジケーターを使用して、画像が意味のある文脈的価値を追加し、処理する必要があるかどうかを判断できます。 Azure AI Vision への呼び出しは言語モデルへの呼び出しよりも安価である可能性があるため、このアプローチはコスト削減につながる可能性があります。 どのような信頼レベルと、どのような分類またはタグがデータに対して最良の結果をもたらすかを判断するには、実験する必要があります。 もう 1 つのオプションは、独自の分類モデルを構築することです。 独自の分類モデルを構築、ホスティング、および維持するためのコストを考慮する必要があります。
もう 1 つのコスト最適化は、 キャッシュアサイド パターンを使用したキャッシュです。 イメージのハッシュに基づいてキーを生成できます。 最初のステップとして、以前の実行または以前に処理されたドキュメントからキャッシュされた結果があるかどうかを確認できます。 そうであれば、その結果を使用できます。 このアプローチにより、分類器や言語モデルを呼び出すコストが削減されます。 キャッシュがない場合、分類子または言語モデルを呼び出すときに、結果がキャッシュされます。 このイメージの今後の呼び出しではキャッシュが使用されます。
これらすべてのコスト最適化プロセスを統合したシンプルなワークフローは次のようになります。
- 画像処理がキャッシュされたかどうかを確認します。 その場合は、キャッシュされた結果を使用します。
- 分類器を実行して、画像を処理する必要があるかどうかを判断します。 分類結果をキャッシュします。 分類ロジックによって指示された場合にのみ続行してください。
- 画像の説明を生成します。 結果をキャッシュします。
全体的なソリューションの経済性
ソリューション全体のコストを確認する際に考慮すべき要素を次に示します。
- 固有のチャンク実装の数 - それぞれの固有の実装には、エンジニアリング コストとメンテナンス コストの両方があります。 コーパス内にある固有のドキュメントの種類の数と、それぞれの固有の実装に関わるコストと品質のトレードオフを考慮する必要があります。
- 各実装のドキュメントごとのコスト - チャンク アプローチによっては、チャンクの品質が向上する可能性がありますが、そのようなチャンクを生成するための財務的コストと時間的コストは高くなります。 たとえば、Azure AI Document Intelligence で事前構築済みモデルを使用すると、ドキュメントごとのコストは純粋なテキスト解析実装よりも高くなると思われますが、チャンクは向上する可能性があります。
- 初期ドキュメントの数 - ソリューションを起動するために処理する必要のある初期ドキュメントの数。
- 増分ドキュメントの数 - システムの継続的なメンテナンスのために処理する必要のある新しいドキュメントの数とレート。
読み込みとチャンキング
論理的には、チャンク化中に、まず何らかの形式でドキュメントをメモリにロードする必要があります。 次に、チャンキング コードはドキュメントのメモリ内表現に対して動作します。 読み込みコードをチャンク化と組み合わせることも、読み込みを独自のフェーズに分離することもできます。 選択するアプローチは、主にアーキテクチャ上の制約と好みに基づいて決定する必要があります。 このセクションでは、両方のオプションについて簡単に説明し、一般的なレコメンデーションをいくつか示します。
ロードとチャンクを分ける
ロードフェーズとチャンキングフェーズを分離することを選択する理由はいくつかあります。 読み込みコードにロジックをカプセル化することもできます。 特に処理時間やコストを節約するためにさまざまなチャンクの組み合わせを試す場合は、チャンク化する前に読み込みコードの結果を永続化する必要がある場合があります。 最後に、プロセスのバルクヘッディングや PII の削除を含むセキュリティ セグメンテーションなどのアーキテクチャ上の理由から、読み込みコードとチャンク コードを別々のプロセスで実行する必要がある場合があります。
読み込みコードにロジックをカプセル化する
読み込みフェーズで前処理ロジックをカプセル化することを選択できます。 これにより、前処理を行う必要がなくなるため、チャンキング コードが簡素化されます。 前処理は、透かし、ヘッダー、フッターなど、ドキュメント分析で無視すると決定したドキュメントの一部を削除したり注釈を付けたりするだけの簡単なものから、ドキュメントの書式を変更するだけの複雑なものまであります。 以下は、読み込みフェーズでカプセル化することを選択できる前処理の例です。
- 無視したい項目を削除するか注釈を付けます。
- 画像参照を画像の説明に置き換えます。 このフェーズでは、LLM を使用して画像の説明を生成し、その説明でドキュメントを更新します。 ドキュメント分析で、画像の周囲に貴重なコンテキストを提供するテキストがあることが判明した場合は、そのテキストを画像とともに LLM に渡します。
- ドキュメントのテキストとは別に処理するために、Azure Data Lake などのファイル ストレージに画像をダウンロードまたはコピーします。 ドキュメント分析で、画像の周囲に貴重なコンテキストを提供するテキストがあることが判明した場合は、このテキストを画像とともにファイル ストレージに保存する必要があります。
- より簡単に処理できるようにテーブルを再フォーマットします。
読み込みコードの結果を永続化する
読み込みコードの結果を永続化することを選択する理由は複数あります。 理由の 1 つは、ドキュメントが読み込まれて前処理された後、チャンク化ロジックが実行される前にドキュメントを検査する機能が必要な場合です。 もう 1 つの理由は、開発中または運用中に、同じ前処理済みコードに対して異なるチャンキング ロジックを実行したい場合があることです。 ロードされたコードを永続化すると、このプロセスが高速化されます。
ロードとチャンクのコードを別々のプロセスで実行する
ロード コードとチャンク コードを別々のプロセスに分離すると、同じ前処理済みコードに対して複数のチャンク実装を実行できるようになります。 この分離により、異なるコンピューティング環境や異なるハードウェアでロード コードとチャンク コードを実行することもできます。 さらに、この設計により、ロードとチャンク化に使用されるコンピューティングを個別にスケーリングできます。
ロードとチャンキングを組み合わせる
ほとんどの場合、ロード コードとチャンク コードを組み合わせると、実装が簡単になります。 個別のロード フェーズでの前処理で実行することを検討する操作の多くは、チャンク フェーズで実行できます。 たとえば、読み込みフェーズで画像の URL を説明に置き換える代わりに、チャンク化ロジックは LLM を呼び出してテキストの説明を取得し、その説明をチャンク化することができます。
画像を参照するタグを持つ HTML などのドキュメント形式を使用する場合は、チャンキング コードが使用するリーダーまたはパーサーがタグを削除しないようにする必要があります。 チャンキング コードは画像参照を識別できる必要があります。
推奨事項
チャンク化ロジックを結合するか分離するかを決定する際に考慮すべきレコメンデーションを次に示します。
- ロードとチャンキングのロジックを組み合わせることから始めます。 ソリューションで必要な場合は分離してください。
- プロセスを分離することを選択した場合は、ドキュメントを中間形式に変換しないでください。 そのような操作は損失を伴う可能性があります。
チャンク アプローチ
このセクションでは、一般的なチャンク アプローチの概要について説明します。 このリストは、よくある代表的なアプローチの一部であり、すべてを網羅しているわけではありません。 大規模言語モデルの使用を組み合わせて画像のテキスト表現を取得するなど、実装では複数のアプローチを使用できます。
各アプローチには、ツールや関連するコストなどを強調表示する要約された意思決定マトリックスが付属しています。 エンジニアリング作業と処理コストは主観であり、相対的な比較のために含まれています。
文ベースの解析
この単純なアプローチでは、テキスト ドキュメントを完全な文で構成されたチャンクに分解します。 このアプローチのメリットには、実装コストが安いこと、処理コストが低いこと、散文または完全な文で書かれたテキストベースのドキュメントに適用できることなどがあります。 このアプローチの課題は、チャンクごとに思考や意味の完全なコンテキストを捉えられない可能性があることです。 多くの場合、セマンティックな意味をキャプチャするには複数の文をまとめて解釈する必要があります。
ツール: SpaCy 文トークナイザー、 LangChain 再帰テキスト スプリッター、 NLTK 文トークナイザー
エンジニアリング作業: 低
処理コスト: 低
ユース ケース: 散文または完全な文で記述された非構造化ドキュメントで、ドキュメントのコーパスには個々のチャンク戦略を構築するには多すぎるほどのさまざまな種類のドキュメントが含まれています
例: アンケート、フォーラム投稿、レビュー、電子メールメッセージ、小説、エッセイからの自由形式のフィードバックなどのユーザー生成コンテンツ
固定サイズの解析 (重複あり)
このアプローチでは、決まった文字数またはトークン数に基づいてドキュメントをチャンクに分割し、チャンク間で一部の文字が重複することを許容します。 このアプローチには、文ベースの解析と同じ長所と短所が多数あります。 このアプローチが文ベースの解析よりも優れているのは、複数の文にまたがるセマンティックな意味を持つチャンクを取得できる点です。
チャンクの固定サイズと重複の量を選択する必要があります。 結果はドキュメントの種類によって異なるため、HuggingFace チャンク ビジュアライザーなどのツールを使用して調査分析を行うことをお勧めします。 このようなツールを使用すると、決定に応じてドキュメントがどのようにチャンクされるかを視覚化できます。 固定サイズの解析を使用する場合は、文字数よりも BERT トークンを使用することをお勧めします。 BERT トークンは意味のある言語単位に基づいているため、文字数よりも多くのセマンティック情報を保持します。
ツール: LangChain 再帰テキスト スプリッター、 Hugging Face チャンク ビジュアライザー
エンジニアリング作業: 低
処理コスト: 低
ユース ケース: 完全な文または不完全な文を含む散文または非散文で記述された非構造化ドキュメント。 ドキュメントのコーパスには、個別のチャンク戦略を構築するには多すぎるほどさまざまなドキュメントの種類が含まれています。
例: アンケート、フォーラム投稿、レビュー、電子メールメッセージ、個人または研究メモやリストからの自由形式のフィードバックなどのユーザー生成コンテンツ
カスタム コード
このアプローチでは、カスタム コードを使用してドキュメントを解析し、チャンクを作成します。 このアプローチは、構造が既知のものか推論可能なものであり、チャンクの作成に対して高度な制御を必要とするテキストベースのドキュメントで最も成功しています。 正規表現などのテキスト解析手法を使用し、ドキュメントの構造内のパターンに基づいてチャンクを作成できます。 目標は、長さが同じサイズのチャンクと、コンテンツが異なるチャンクを作成することです。 多くのプログラミング言語では正規表現がサポートされており、中には、よりエレガントな文字列操作機能を提供するライブラリまたはパッケージを備えている言語もあります。
ツール: Python (re、 regex、 BeautifulSoup、 lxml、 html5lib、 marko)、 R (stringr、 xml2)、 Julia (Gumbo.jl)
エンジニアリング作業: 中
処理コスト: 低
ユース ケース: 構造を推論できる半構造化ドキュメント
例: 特許出願、研究論文、保険証券、スクリプト、および台本
大規模言語モデル拡張
大規模言語モデルを使用してチャンクを作成できます。 一般的なユース ケースは、GPT-4 などの大規模言語モデルを使用して、チャンクとして使用できるイメージまたはテーブルの要約のテキスト表現を生成することです。 大規模言語モデル拡張は、カスタム コードなどの他のチャンク アプローチで使用されます。
ドキュメント分析セクションの画像部分 で、画像の前または後のテキストがいくつかの質問に答えるために必要であると判断した場合は、この追加のコンテキストを大規模言語モデルに渡す必要があります。 この追加のコンテキストによってソリューションのパフォーマンスが向上するかどうかを判断するために実験することが重要です。
チャンク化ロジックによって画像の説明が複数のチャンクに分割される場合は、各チャンクに画像の URL を含めるようにしてください。 各チャンクに画像 URL を含めると、特にエンド ユーザーがその URL を介してソース画像にアクセスする機能を必要とするシナリオや、推論時に生の画像を使用するシナリオでは、画像が提供するすべてのクエリに対してメタデータが返されるようになります。
ツール: Azure OpenAI、 OpenAI
エンジニアリング作業: 中
処理コスト: 高
ユース ケース: イメージ、テーブル
例: テーブルとイメージのテキスト表現を生成し、会議、スピーチ、インタビュー、またはポッドキャストからの文字起こしを要約します
ドキュメント レイアウト分析
ドキュメント レイアウト分析のライブラリとサービスは、光学式文字認識 (OCR) 機能とディープ ラーニング モデルを組み合わせて、ドキュメントの構造とテキストの両方を抽出します。 構造要素には、ヘッダー、フッター、タイトル、セクション見出し、表、図などがあります。 目的は、ドキュメントに含まれるコンテンツに、より適切なセマンティックな意味を持たせることです。
ドキュメント レイアウト分析ライブラリとサービスでは、ドキュメントの構造とテキストの両方のコンテンツを表すモデルが公開されます。 モデルと対話するコードは引き続き記述する必要があります。
Note
Azure AI Document Intelligence は、ドキュメントをサービスにアップロードする必要のあるクラウドベースのサービスです。 このようなサービスにドキュメントをアップロードすることが、セキュリティとコンプライアンスの規制で許可されていることを確認する必要があります。
ツール: Azure AI Document Intelligence ドキュメント分析モデル、 ドーナツ、 レイアウト パーサー
エンジニアリング作業: 中
処理コスト: 中
ユース ケース: 半構造化ドキュメント
例: ニュース記事、Web ページ、履歴書
事前構築済みのモデル
Azure AI Document Intelligence など、さまざまなドキュメントの種類に利用できる事前構築済みモデルを提供するサービスがあります。 特定のドキュメントの種類 (米国税務 W-2 フォームなど) に対してトレーニングされているモデルもあれば、より幅広いジャンルのドキュメントの種類 (請求書など) を対象としているものもあります。
ツール: Azure AI Document Intelligence の事前構築済みモデル、 Power Automate インテリジェント ドキュメント処理、 LayoutLMv3
エンジニアリング作業: 低
処理コスト: 中/高
ユース ケース: 事前構築済みモデルが存在する構造化ドキュメント
具体例: 請求書、領収書、健康保険カード、W-2 フォーム
カスタム モデル
事前構築済みモデルが存在しない高度に構造化されたドキュメントの場合は、カスタム モデルの構築が必要になる場合があります。 このアプローチは、高度に構造化されたイメージやドキュメントに効果的であるため、テキスト解析手法を使用するのが困難になります。
ツール: Azure AI Document Intelligence カスタム モデル、 Tesseract
エンジニアリング作業: 高
処理コスト: 中/高
ユース ケース: 事前構築済みモデルが存在しない構造化ドキュメント
例: 自動車の修理と整備のスケジュール、学業成績証明書、記録、技術マニュアル、運用手順、メンテナンス ガイドライン
ドキュメントの構造
ドキュメントの構造の規模はドキュメントによって異なります。 行政フォームのような一部のドキュメント (W-2 米国税務文書など) は、複雑でよく知られている構造を持っています。 その真逆に、自由形式のノートのような非構造化ドキュメントがあります。 ドキュメントの種類に対する構造の程度は、効果的なチャンク アプローチを決定する出発点として適しています。 絶対厳守のルールはありませんが、このセクションでは、従うべきガイドラインをいくつか説明します。
図 1. チャンク アプローチはドキュメント構造に適合します
構造化ドキュメント
構造化ドキュメント (固定形式のドキュメントとも呼ばれます) には、定義済みのレイアウトが用意されています。 これらのドキュメント内のデータは固定の場所にあります。 たとえば、日付や顧客の姓は、同じ固定形式のすべてのドキュメントで同じ場所にあります。 固定形式のドキュメントの例には、W-2 米国税務文書があります。
元のドキュメントが手書きだったり、レイアウト構造が複雑だったりすると、固定形式のドキュメントは、元のドキュメントをスキャンしたイメージである可能性があるため、基本的なテキスト解析アプローチでは処理が難しいことがあります。 複雑なドキュメント構造を処理する一般的なアプローチは、機械学習モデルを使用してデータを抽出し、可能な場合は、そのデータにセマンティックな意味を適用することです。
例: W-2 フォーム、保険カード
一般的なアプローチ: 事前構築済みモデル、カスタム モデル
半構造化ドキュメント
半構造化ドキュメントには、W-2 フォームのような固定形式やスキーマはありませんが、形式またはスキーマに関する一貫性は確保されています。 たとえば、すべての請求書が同じレイアウトになっているわけではありませんが、一般的にスキーマには一貫性があります。 請求書には invoice number や何らかの形式の bill to または ship to の名前と住所、その他データが記載されていることが予想されます。 Web ページの場合、スキーマに一貫性がない場合がありますが、周囲のテキストにセマンティックな意味を追加するために使用される body、 title、 H1、 p などの構造要素やレイアウト要素は似ています。
構造化ドキュメントと同様、複雑なレイアウト構造を持つ半構造化ドキュメントは、テキスト解析での処理が困難です。 これらのドキュメントの種類では、機械学習モデルが適切なアプローチです。 請求書、契約、医療保険のようにスキーマが一貫している特定のドメインには、事前構築済みモデルがあります。 事前構築済みモデルが存在しない複雑な構造の場合は、カスタム モデルの構築をご検討ください。
例: 請求書、領収書、Web ページ、マークダウン ファイル
一般的なアプローチ: ドキュメント分析モデル
推論された構造体
ドキュメントによっては、構造はあってもマークアップで記述されていないものがあります。 これらのドキュメントの場合、構造を推論する必要があります。 次の EU 規制ドキュメントは、その良い例です。
図 2. 推論された構造を示す EU 規則
ドキュメントの構造を明確に理解でき、それに関する既知のモデルがないため、カスタム コードを記述できると判断できます。 このようなドキュメント形式では、この種類の異なるドキュメント (作業中のもの) の数によっては、カスタム モデルを作成する作業が保証されない場合があります。 たとえば、コーパスがすべて EU 規制または米国の州法の場合、カスタム モデルが適切なアプローチである可能性があります。 この例の EU 規制のように、1 つのドキュメントを使用している場合、カスタム コードのほうがコスト効率が高くなる場合があります。
例: 法律文書、スクリプト、製造仕様
一般的なアプローチ: カスタム コード、カスタム モデル
非構造化ドキュメント
構造がほぼまったくないドキュメントに適したアプローチは、文ベースまたは固定サイズ (重複あり) のアプローチです。
例: ユーザー作成コンテンツ (アンケート、フォーラムの投稿、またはレビュー、メールのメッセージ、および個人用または研究用のメモからの自由回答形式のフィードバックなど)
一般的なアプローチ: 文ベースまたは境界ベース (重複あり)
実験
それぞれのチャンキング アプローチに最適なものがリストされていますが、実際には、どのアプローチもどのドキュメント タイプにも適している可能性があります。 たとえば、文ベースの解析は高度に構造化されたドキュメントに適している場合もあれば、カスタム モデルが非構造化ドキュメントに適している場合もあります。 RAG ソリューションを最適化するには、保有するリソースの数、リソースの技術スキル、処理する必要があるドキュメントの量を考慮して、さまざまなチャンキング アプローチを試してみる必要があります。 最適なチャンク戦略を達成するには、テストする各アプローチの利点とトレードオフを観察して、ユース ケースに適したアプローチを選択していることを確認する必要があります。