テスト ドキュメントとクエリの収集、および準備フェーズでのドキュメント分析の実行が終わったので、次のフェーズはチャンクです。 ドキュメントを分割して、意味的に関連する適切なサイズのチャンク コレクションを作成することは、検索拡張生成 (RAG) 実装を成功させる重要な要因です。 全部のドキュメントまたは大きすぎるチャンクを渡すとコストがかかり、モデルのトークン制限を超える可能性があり、最適な結果が得られません。 クエリに関係のない大規模言語モデルに情報を渡せば、幻覚につながる可能性があります。 ドキュメントのどの部分が関連するもので、どの部分が無関係で無視すべきかを判断する必要があります。
小さすぎるチャンクや、クエリに対処できるだけの十分なコンテキストが含まれていないチャンクを渡すと、良い結果を得られません。 複数のチャンクにまたがって存在する関連コンテキストは、キャプチャされない場合があります。 必要なのは、特定のドキュメントの種類、およびその構造とコンテンツに対して、効果的なチャンク アプローチを実装する技術です。 検討すべきチャンク アプローチはさまざまあり、適用されるドキュメントの種類と構造に応じて、コストへの影響や効果はそれぞれ異なります。
この記事では、さまざまなチャンク アプローチについて説明し、ドキュメントの構造が選択したチャンク アプローチにどのような影響を及ぼす可能性があるかを調査します。
この記事はシリーズの一部です。 概要を参照してください。
チャンクの経済性
全体的なチャンク戦略を決定するときは、テキスト コーパスの品質要件とスループット要件に加えて、予算を考慮する必要があります。 固有のチャンク実装ごとの設計と実装にはエンジニアリング コストがかかり、ドキュメントごとの処理コストはアプローチによって異なります。
ソリューション全体のコストを確認する際に考慮すべき要素を次に示します。
- 固有のチャンク実装の数 - それぞれの固有の実装には、エンジニアリング コストとメンテナンス コストの両方があります。 コーパス内にある固有のドキュメントの種類の数と、それぞれの固有の実装に関わるコストと品質のトレードオフを考慮する必要があります。
- 各実装のドキュメントごとのコスト - チャンク アプローチによっては、チャンクの品質が向上する可能性がありますが、そのようなチャンクを生成するための財務的コストと時間的コストは高くなります。 たとえば、Azure AI Document Intelligence で事前構築済みモデルを使用すると、ドキュメントごとのコストは純粋なテキスト解析実装よりも高くなると思われますが、チャンクは向上する可能性があります。
- 初期ドキュメントの数 - ソリューションを起動するために処理する必要のある初期ドキュメントの数。
- 増分ドキュメントの数 - システムの継続的なメンテナンスのために処理する必要のある新しいドキュメントの数とレート。
チャンク アプローチ
このセクションでは、一般的なチャンク アプローチの概要について説明します。 このリストは、よくある代表的なアプローチの一部であり、すべてを網羅しているわけではありません。 大規模言語モデルの使用を組み合わせて画像のテキスト表現を取得するなど、実装では複数のアプローチを使用できます。
各アプローチには、ツールや関連するコストなどを強調表示する要約された意思決定マトリックスが付属しています。 エンジニアリング作業と処理コストは主観であり、相対的な比較のために含まれています。
文ベースの解析
この単純なアプローチでは、テキスト ドキュメントを完全な文で構成されたチャンクに分解します。 このアプローチのメリットには、実装コストが安いこと、処理コストが低いこと、散文または完全な文で書かれたテキストベースのドキュメントに適用できることなどがあります。 このアプローチの課題は、チャンクごとに思考や意味の完全なコンテキストを捉えられない可能性があることです。 多くの場合、セマンティックな意味をキャプチャするには複数の文をまとめて解釈する必要があります。
ツール: SpaCy 文トークナイザー、LangChain 再帰テキスト スプリッター、NLTK 文トークナイザー
エンジニアリング作業: 低
処理コスト: 低
ユース ケース: 散文または完全な文で記述された非構造化ドキュメントで、ドキュメントのコーパスには個々のチャンク戦略を構築するには多すぎるほどのさまざまな種類のドキュメントが含まれています
例: ユーザー作成コンテンツ (アンケート、フォーラムの投稿、レビュー、メールのメッセージ、小説やエッセイからの自由回答式のフィードバックなど)
固定サイズの解析 (重複あり)
このアプローチでは、決まった文字数またはトークン数に基づいてドキュメントをチャンクに分割し、チャンク間で一部の文字が重複することを許容します。 このアプローチには、文ベースの解析と同じ長所と短所が多数あります。 このアプローチが文ベースの解析よりも優れているのは、複数の文にまたがるセマンティックな意味を持つチャンクを取得できる点です。
チャンクの固定サイズと重複の量を選択する必要があります。 結果はドキュメントの種類によって異なるため、HuggingFace チャンク ビジュアライザーなどのツールを使用して調査分析を行うことをお勧めします。 このようなツールを使用すると、決定に応じてドキュメントがどのようにチャンクされるかを視覚化できます。 固定サイズの解析を使用する場合は、文字数よりも BERT トークンを使用することをお勧めします。 BERT トークンは意味のある言語単位に基づいているため、文字数よりも多くのセマンティック情報を保持します。
ツール: LangChain 再帰テキスト スプリッター、Hugging Face チャンク ビジュアライザー
エンジニアリング作業: 低
処理コスト: 低
ユース ケース: 完全な文または不完全な文を含む散文または非散文で記述された非構造化ドキュメント。 ドキュメントのコーパスには、個別のチャンク戦略を構築するには多すぎるほどさまざまなドキュメントの種類が含まれています。
例: ユーザー作成コンテンツ (アンケート、フォーラムの投稿、レビュー、メールのメッセージ、個人用または研究用のメモやリストからの自由回答形式のフィードバックなど)
カスタム コード
このアプローチでは、カスタム コードを使用してドキュメントを解析し、チャンクを作成します。 このアプローチは、構造が既知のものか推論可能なものであり、チャンクの作成に対して高度な制御を必要とするテキストベースのドキュメントで最も成功しています。 正規表現などのテキスト解析手法を使用し、ドキュメントの構造内のパターンに基づいてチャンクを作成できます。 目標は、長さが同じサイズのチャンクと、コンテンツが異なるチャンクを作成することです。 多くのプログラミング言語では正規表現がサポートされており、中には、よりエレガントな文字列操作機能を提供するライブラリまたはパッケージを備えている言語もあります。
ツール: Python (re、regex、BeautifulSoup、lxml、html5lib、marko)、R (stringr、xml2)、Julia (Gumbo.jl)
エンジニアリング作業: 中
処理コスト: 低
ユース ケース: 構造を推論できる半構造化ドキュメント
例: 特許出願、研究論文、保険証券、スクリプト、および台本
大規模言語モデル拡張
大規模言語モデルを使用してチャンクを作成できます。 一般的なユース ケースは、GPT-4 などの大規模言語モデルを使用して、チャンクとして使用できるイメージまたはテーブルの要約のテキスト表現を生成することです。 大規模言語モデル拡張は、カスタム コードなどの他のチャンク アプローチで使用されます。
ツール: 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 ソリューションの最適化の一環として、保有しているリソースの数、リソースの技術スキル、処理する必要があるドキュメントの量を考慮して、さまざまなチャンク アプローチを試します。 最適なチャンク戦略を達成するには、テストする各アプローチの利点とトレードオフを観察して、ユース ケースに適したアプローチを選択していることを確認する必要があります。