検索拡張生成 (RAG) の開発と実験の最初のフェーズは、準備フェーズです。 このフェーズでは、最初にソリューションのビジネス ドメインを定義します。 ドメインを定義したら、ドキュメント分析の実行、ドキュメントの収集、ドメインに関連するサンプルの質問の収集という並行プロセスを開始します。 手順は相互に関連しているため、並行して実行されます。 ドキュメント分析は、収集する必要があるテスト ドキュメントとテスト クエリを決定するのに役立ちます。 さらに、質問は文書の内容によって回答可能でなければならず、文書は関連する質問に答えなければならないという点で、それらは相互に関連しています。
この記事はシリーズの一部です。 概要を参照してください。
ソリューション ドメインを決定する
このプロセスの最初の手順は、ソリューションまたはユース ケースのビジネス要件を明確に定義することです。 これらの要件は、ソリューションがどのような質問に対処しようとしているのか、どのようなソース データまたはドキュメントがそうした質問の対処に役立つのかを判断するのに役立ちます。 後半の段階で、このソリューション ドメインは埋め込みモデル戦略を通知するのに役立ちます。
ドキュメント分析
ドキュメント分析の目的は、ドキュメント コーパスに関する十分な情報を収集して、次のことを理解できるようにすることです。
- ドキュメントのさまざまな分類 - たとえば、製品の仕様、四半期ごとのレポート、自動車保険契約、健康保険契約などを持っていますか。
- ドキュメントの種類はさまざまです。たとえば、PDF、Markdown ファイル、HTML ファイル、DOCX ファイルなどがあります。
- セキュリティ制約 - たとえば、文書が一般に公開されているかどうか、またはアクセスするために認証と承認が必要かどうかなど
- 文書の構造 - たとえば、文書の長さ、トピックの区切り、文脈上関連のある画像や表形式のデータがあるかどうかなど
次のセクションでは、この情報がロードおよびチャンク化戦略にどのように役立つかについて説明します。
文書の分類
必要なテスト ドキュメントの数を決定するには、ドキュメントのさまざまな分類を理解する必要があります。 分析のこの部分では、保険や金融などの高レベルの分類だけでなく、健康保険と自動車保険の文書などのサブ分類もわかるはずです。 また、サブ分類に異なる構造や内容があるかどうかも理解する必要があります。
目標は、所有しているさまざまなドキュメントのバリエーションをすべて理解することです。 これを理解することで、必要なテスト ドキュメントの数と内訳を決定するのに役立ちます。 実験では、特定のドキュメント分類を過剰に表現したり、過小表現したりすることは避けてください。
ドキュメント タイプ
コーパス内のさまざまなファイル形式を理解すると、テスト ドキュメントの数と内訳を判断するのに役立ちます。 たとえば、四半期レポート用の PDF および Office Open XML ドキュメント タイプがある場合は、ドキュメント タイプごとにテスト ドキュメントが必要です。 ドキュメントの種類を理解すると、それらのファイル形式の処理に適した特定のライブラリなど、ドキュメントの読み込みとチャンク化に関する技術要件を理解するのにも役立ちます。
セキュリティの制約
セキュリティ制約を理解することは、読み込みとチャンク化の戦略を決定する上で非常に重要です。 たとえば、ドキュメントの一部またはすべてに認証、承認、またはネットワークの可視性が必要かどうかを識別する必要があります。 ドキュメントが安全な境界内にある場合は、コードがドキュメントにアクセスできるようにするか、処理コードがアクセスできる場所にドキュメントを安全に複製するプロセスを実装します。
ドキュメントでは、ドキュメントのコンテキストにとって重要な画像や音声などのマルチメディアが参照される場合があることに留意してください。 そのメディアも、ドキュメント自体と同様のアクセス制御の対象となる可能性があります。 そのメディアに認証またはネットワークの見通しが必要な場合は、コードがメディアにアクセスできることを確認するか、そのコンテンツを複製できるアクセス権を持つ事前のプロセスを用意する必要があります。
ワークロードで、異なるユーザーが個別のドキュメントまたはドキュメント セグメントにのみアクセスできるようにする必要がある場合は、チャンキング ソリューションでそれらのアクセス権限をどのように保持するかを必ず理解してください。
ドキュメントの構造
ドキュメントのレイアウト方法やドキュメント内のコンテンツの種類など、ドキュメントの構造を理解する必要があります。 ドキュメントの構造と内容を理解することで、次の判断を下すのに役立ちます。
- ドキュメントに、ノイズの除去、メディアの抽出、再フォーマット、無視する項目への注釈付けなどの前処理が必要かどうか
- 無視または除外するドキュメントの内容
- 文書内の何をキャプチャしたいか
- ドキュメントをチャンクする方法
- 画像、表、グラフ、その他の埋め込みメディアをどのように処理するか
以下は、これらの決定を行う際に役立つ、分類された質問の一部です。
無視してもよい一般的な項目に関する質問
一部の構造要素はドキュメントに意味を追加しない可能性があり、チャンク化時に無視しても問題ありません。 状況によっては、これらの要素によって貴重なコンテキストが追加され、インデックスへの関連性クエリが促進されることもありますが、すべてに当てはまるわけではありません。 以下は、関連性を高めるか、無視すべきかを判断するために評価する必要がある、一般的なドキュメント機能に関するいくつかの質問です。
- 文書には目次が含まれていますか?
- ヘッダーとフッターはありますか?
- 著作権や免責事項はありますか?
- 脚注や巻末の注はありますか?
- 透かしはありますか?
- 注釈やコメントはありますか?
前処理とチャンク化戦略に役立つ質問
ドキュメントの構造に関する次の質問は、ドキュメントを処理しやすくするために前処理する必要があるかどうかを理解するのに役立つ洞察を提供し、チャンキング戦略を通知するのに役立ちます。
- 複数列のデータまたは複数列の段落はありますか? 複数列のコンテンツを 1 つの列であるかのように解析すべきではありません。
- ドキュメントの構造はどのようになっていますか? たとえば、HTML ファイルではレイアウトにテーブルが使用されることがありますが、これは埋め込まれた表形式のデータと区別する必要があります。
- 段落はいくつありますか? 段落の長さはどれぐらいですか? 段落の長さはほぼ同じですか?
- ドキュメントに含まれる言語、言語バリアント、または方言は何ですか?
- ドキュメントに Unicode 文字が含まれていますか?
- 数値はどのように書式設定されますか? コンマまたは小数点を使用していますか? それらは一貫していますか?
- ドキュメント内で何が統一され、何が統一されていませんか?
- セマンティックな意味を抽出できるヘッダー構造はありますか?
- 箇条書きや意味のあるインデントはありますか?
画像に関する質問
ドキュメント内の画像を理解することは、画像処理戦略を決定するのに役立ちます。 どのような種類の画像があるか、処理するのに十分な解像度があるか、画像に必要な情報がすべて含まれているかどうかなどの情報を把握する必要があります。 次の質問は、画像処理の要件を理解するのに役立ちます。
- ドキュメントに画像は含まれていますか?
- 画像の解像度はどれくらいですか?
- 画像にテキストは埋め込まれていますか?
- 価値を付加しない抽象的な画像はありますか? たとえば、アイコンは意味的な価値を追加しない可能性があります。 アイコンのビジュアルは一般にドキュメントの内容とほとんど関係がないため、画像に説明を追加すると実際には悪影響が出る可能性があります。
- 画像と周囲のテキストとの関係は何ですか? 画像にスタンドアロン コンテンツが含まれているかどうか、またはテキスト表現を取得するために大規模な言語モデルに渡すときに使用する必要がある画像の周囲にコンテキストがあるかどうかを判断します。 キャプションは、画像に含まれていない貴重なコンテキストを含む可能性のある周囲のテキストの例です。
- アクセシビリティの説明など、画像の豊富なテキスト表現はありますか?
表、グラフ、その他のリッチコンテンツに関する質問
表、グラフ、その他のメディアにどのような情報がカプセル化されているかを理解すると、その情報を何をどのように処理するかを理解するのに役立ちます。 次の質問は、表、グラフ、その他のメディア処理の要件を理解するのに役立ちます。
- ドキュメントにはグラフがあり、数値が表示されていますか?
- ドキュメントにテーブルが含まれていますか?
- テーブルは複雑ですか (入れ子になったテーブル)、それとも複雑ではありませんか?
- テーブルにキャプションはありますか?
- テーブルの長さはどれくらいですか? 長い表では、ヘッダーをチャンク単位で繰り返す必要がある場合があります。
- ビデオやオーディオなどの他の種類の埋め込みメディアはありますか?
- ドキュメント内に数式/科学的表記はありますか?
代表的なテスト ドキュメントを収集する
この手順では、運用ソリューションで使用するドキュメントを最も適切に表現したドキュメントを収集します。 対象ドキュメントは、定義されたユース ケースに対処し、並行して行われる質問収集フェーズで収集された質問に回答できるものである必要があります。
考慮事項
代表的なものの可能性があるテスト ドキュメントを評価するときは、次の点を考慮してください。
- 妥当性 - ドキュメントは、会話型アプリケーションのビジネス要件を満たす必要があります。 たとえば、銀行業務の実行する顧客を支援する任務を負ったチャット ボットを構築する場合、ドキュメントはその要件に一致している必要があります (銀行口座の開設方法と解約方法を示すドキュメントなど)。 ドキュメントは、並行して行われる手順で収集されるテストの質問に対処できる必要があります。 質問に関連する情報がドキュメントにない場合は、有効な応答を生成できません。
- 代表 - ドキュメントは、ソリューションで使用するさまざまな種類のドキュメントを代表するものである必要があります。 たとえば、自動車保険のドキュメントは、医療保険や生命保険のドキュメントとは異なります。 ユースケースではソリューションが 3 つのタイプすべてをサポートする必要があり、自動車保険のドキュメントが 2 つしかないとします。 あなたのソリューションは、健康保険と生命保険の両方でパフォーマンスが低下します。 バリエーションごとに少なくとも 2 つ必要です。
- 物理的なドキュメントの品質 - ドキュメントは使用可能な形状である必要があります。 たとえば、スキャンされた画像では、使用可能な情報を抽出できない場合があります。
- ドキュメント コンテンツの品質 - ドキュメントのコンテンツは高品質である必要があります。 スペルミスや文法上の誤りがあってはなりません。 大規模言語モデルは、質のよくないコンテンツを使用すると適切に動作しません。
この手順の成功要因は、特定のドメインのテスト ドキュメントを適切に表していることを 質的に確信 していることです。
テスト ドキュメントのガイダンス
- 合成よりも実際のドキュメントを優先します。 実際のドキュメントは、個人を特定できる情報 (PII) を削除するために、クリーニング プロセスを経る必要があります。
- 予測される将来のシナリオを含むあらゆる種類のシナリオを確実に処理するには、合成データを使用してドキュメントを選択的に拡張することを検討してください。
- 合成データを使用する必要がある場合は、実際のデータに可能な限り近づけるように全力を尽くします。
- ドキュメントが、収集途中の質問に対処できることを確認します。
- 文書バリアントごとに少なくとも 2 つのドキュメントが必要です。
- 大規模言語モデルまたはその他のツールを使用すると、ドキュメントの品質の評価に役立ちます。
テスト クエリを収集する
このステップでは、チャンク、検索ソリューション、およびプロンプト エンジニアリングを評価するために使用するテスト クエリを収集します。 これは、代表的なドキュメントの収集と足並みを揃えて行います。クエリを収集するだけでなく、代表的なドキュメントがクエリにどのように対処するかも収集するからです。 両方のサンプル クエリと、それらのクエリに対処するサンプル ドキュメントの部分を組み合わせることで、さまざまな戦略やアプローチを実験しながら、RAG ソリューションのすべての段階を評価できます。
テスト クエリの出力を収集する
このフェーズの出力には、「代表的なテスト クエリを収集する」手順と「代表的なテスト ドキュメントを収集する」手順の両方のコンテンツが含まれます。 出力は、次のデータを含むコレクションです。
- クエリ - 正当なユーザーの潜在的なプロンプトを表す質問。
- コンテキスト - クエリに対処するドキュメントに含まれている実際のすべてのテキストのコレクション。 コンテキストのビットごとに、ページと実際のテキストを含める必要があります。
- 回答 - クエリに対する有効な応答。 応答は、ドキュメントから直接取得したコンテンツであるか、1 つ以上のコンテキストから言い換えられたものである場合があります。
合成クエリの作成
多くの場合、領域の専門家 (SME) が特定のドメインでユース ケースに関する包括的な質問リストをまとめることは困難です。 この課題のソリューションの 1 つは、収集された代表的なテスト ドキュメントから合成の質問を生成することです。 代表的なドキュメントから合成の質問を生成するための実際のアプローチを次に示します。
ドキュメントをチャンクする - ドキュメントをチャンクに分割します。 このチャンク手順では、ソリューション全体に対してチャンク戦略は使用されません。 これは、合成クエリを生成するために使用する 1 回限りの手順です。 ドキュメントの数が妥当な範囲であれば、チャンクを手動で行うことができます。
チャンクごとにクエリを生成する - チャンクごとに、手動で、または大規模言語モデルを使用してクエリを生成します。 大規模言語モデルを使用する場合は、通常、チャンクごとに 2 つのクエリを生成することから始めます。 大規模言語モデルを使用して、回答を作成することもできます。 次の例は、チャンクに対して質問と回答を生成するプロンプトを示しています。
Please read the following CONTEXT and generate two question and answer json objects in an array based on the CONTEXT provided. The questions should require deep reading comprehension, logical inference, deduction, and connecting ideas across the text. Avoid simplistic retrieval or pattern matching questions. Instead, focus on questions that test the ability to reason about the text in complex ways, draw subtle conclusions, and combine multiple pieces of information to arrive at an answer. Ensure that the questions are relevant, specific, and cover the key points of the CONTEXT. Provide concise answers to each question, directly quoting the text from provided context. Provide the array output in strict JSON format as shown in output format. Ensure that the generated JSON is 100 percent structurally correct, with proper nesting, comma placement, and quotation marks. There should not be any comma after last element in the array. Output format: [ { "question": "Question 1", "answer": "Answer 1" }, { "question": "Question 2", "answer": "Answer 2" } ] CONTEXT:出力を確認する - 質問がユース ケースに適切であること、および回答が質問に対処していることを確認します。 この検証は、SME が実行する必要があります。
未対処クエリ
ドキュメントで対処されないクエリを、対処されるクエリとともに収集することが重要です。 ソリューションをテストする場合 (特に大規模言語モデルをテストする場合)、回答できるほど十分なコンテキストを持っていないソリューションがクエリに応答する方法を決める必要があります。 対処できないクエリに応答するアプローチには、次のようなものがあります。
- わからないと応答する
- わからないと応答し、ユーザーが詳細情報を見つける可能性があるリンクを提供する
埋め込みメディアのテストクエリを収集する
テキストの場合と同様に、埋め込まれたメディアを使用して関連性の高い回答を生成する、多様な質問のセットを収集する必要があります。 グラフ、表、スクリーンショットなどの画像がある場合は、すべてのユースケースを網羅する質問を用意してください。 ドキュメント分析セクションの画像部分 で、画像の前または後のテキストがいくつかの質問に回答するために必要であると判断した場合は、テスト クエリにそれらの質問が含まれていることを確認します。
テスト クエリの収集に関するガイダンス
- 実際に顧客から寄せられた質問が収録されており、使用できるシステムがあるかどうかを判断します。 たとえば、顧客からの質問に回答するチャット ボットを構築している場合は、ヘルプ デスク、FAQ、またはチケット発行システムから顧客からの質問を使用できる場合があります。
- ユース ケースに関する顧客または SME は、収集されたドキュメント、関連するテスト クエリ、およびドキュメントからのクエリに対する回答が包括的であり、代表的なものであり、正しいものかどうかを判断するための品質ゲートとして機能する必要があります。
- 質問と回答の本文を定期的に確認して、継続的にソース ドキュメントを正確に反映する必要があります。