検索拡張生成 (RAG) の開発と実験の最初のフェーズは、準備フェーズです。 このフェーズでは、ソリューションのビジネス ドメインを定義します。 ドメインを定義したら、ドキュメントを収集し、ドキュメント分析を実行し、ドメインに関連するサンプルの質問を収集します。 これらの手順は相互に関連しているため、並列で実行します。 たとえば、ドキュメント分析は、収集する必要があるテスト ドキュメントとテスト クエリを決定するのに役立ちます。 質問する質問は、ドキュメント内のコンテンツで回答できる必要があり、ドキュメントは関連する質問に回答する必要があります。
この記事はシリーズの一部です。 概要を参照してください。
ソリューション ドメインを決定する
このプロセスの最初の手順は、ソリューションまたはユース ケースのビジネス要件を明確に定義することです。 これらの要件は、ソリューションが回答する必要がある質問の種類と、それらの質問に回答するのに役立つソース データまたはドキュメントを決定するのに役立ちます。 後のフェーズでは、ソリューション ドメインは埋め込みモデル戦略を通知するのに役立ちます。
ドキュメント分析
ドキュメント分析の目的は、ドキュメント コレクションに関する十分な情報を収集して、次のことを理解することです。
ドキュメントのさまざまな分類。 たとえば、製品の仕様、四半期ごとのレポート、自動車保険契約、または健康保険契約があるとします。
さまざまな種類のドキュメント。 たとえば、PDF、Markdown ファイル、HTML ファイル、DOCX ファイルなどです。
セキュリティの制約。 たとえば、ドキュメントがパブリックにアクセスできるかどうかに応じて、ドキュメントにアクセスするために認証と承認が必要になる場合があります。
ドキュメントの構造。 たとえば、ドキュメントの長さは異なる場合があります。 または、トピックの区切り、コンテキストに関連する画像、表形式のデータが含まれます。
次のセクションでは、この情報を使用して読み込みとチャンクの戦略を選択する方法について説明します。
文書の分類
必要なテスト ドキュメントの数を判断するには、ドキュメントのさまざまな分類を理解する必要があります。 分析のこの部分では、保険や金融などの高レベルの分類について説明する必要があります。 また、医療保険の書類や自動車保険の書類など、サブクラス化についても説明する必要があります。 また、サブクラス化の構造や内容が異なるかどうかを知りたい場合もあります。
目標は、使用しているさまざまなドキュメントバリアントをすべて理解することです。 その後、必要なテスト ドキュメントの数と内訳を決定できます。 実験で特定のドキュメント分類を表す必要はありません。
ドキュメント タイプ
コレクション内のさまざまなファイル形式を理解すると、テスト ドキュメントの数と内訳を判断するのに役立ちます。 たとえば、四半期ごとのレポートに PDF および Open XML ドキュメントの種類がある場合は、それらのドキュメントの種類ごとにテスト ドキュメントが必要です。 ドキュメントの種類を理解することは、ドキュメントの読み込みとチャンクに関する技術的な要件を理解するのにも役立ちます。 これらの技術的要件には、これらのファイル形式を処理できる特定のライブラリが含まれます。
セキュリティの制約
セキュリティ制約を理解することは、読み込みとチャンク化の戦略を決定する上で非常に重要です。 たとえば、ドキュメントの一部またはすべてに認証、承認、またはネットワークの可視性が必要かどうかを識別する必要があります。 ドキュメントがセキュリティで保護された境界内にある場合は、コードがそれらにアクセスできることを確認するか、処理コードのアクセス可能な場所にドキュメントを安全にレプリケートするプロセスを実装します。
ドキュメントは、ドキュメントのコンテキストにとって重要な画像やオーディオなどのマルチメディアを参照する場合があります。 そのメディアも、ドキュメント自体と同様のアクセス制御の対象となる可能性があります。 そのメディアに認証またはネットワークの見通し線が必要な場合は、コードがメディアにアクセスできるか、またはアクセス権を持ち、コンテンツをレプリケートできるプロセスがあることを確認する必要があります。
ワークロードで、異なるユーザーが個別のドキュメントまたはドキュメント セグメントにのみアクセスできるようにする必要がある場合は、チャンク ソリューションでそれらのアクセス許可を保持する方法を理解していることを確認してください。
ドキュメントの構造
レイアウトやドキュメント内のコンテンツの種類など、ドキュメントの構造を理解する必要があります。 ドキュメントの構造と内容を理解することで、次の判断を下すのに役立ちます。
ドキュメントで、ノイズのクリーンアップ、メディアの抽出、コンテンツの再フォーマット、無視する項目の注釈付けなどの前処理が必要かどうか
ドキュメント内のコンテンツを無視または除外するかどうか
キャプチャするドキュメントの部分
ドキュメントをチャンクする方法
画像、表、グラフ、その他の埋め込みメディアをどのように処理するか
以下のセクションでは、これらの決定の一部を行う際に役立つ、分類された質問の一覧を示します。
無視できる項目を決定する
一部の構造要素はドキュメントに意味を追加しない可能性があり、チャンク化時に無視しても問題ありません。 状況によっては、これらの要素によって重要なコンテキストが追加され、クエリのインデックスへの関連性が向上する可能性がありますが、すべてではありません。 一般的なドキュメント機能について次の質問をして、関連性を追加するか無視するかを確認します。
文書には目次が含まれていますか?
ヘッダーまたはフッターはありますか?
著作権や免責事項はありますか?
脚注や巻末の注はありますか?
透かしはありますか?
注釈やコメントはありますか?
前処理とチャンク戦略を決定する
ドキュメントの構造に関する次の質問は、処理を容易にするためにドキュメントを前処理する必要があるかどうかを判断するのに役立ちます。 また、チャンク戦略を選択するのにも役立ちます。
複数列のデータまたは複数列の段落はありますか? 複数列のコンテンツを単一列コンテンツと同じように解析する必要はありません。
ドキュメントの構造はどのようになっていますか? たとえば、HTML ファイルでは、埋め込みテーブル データと区別する必要があるテーブルが使用される場合があります。
段落はいくつありますか? 段落の長さはどれぐらいですか? 段落の長さは似ていますか?
ドキュメントに含まれる言語、言語バリアント、または方言は何ですか?
ドキュメントに Unicode 文字が含まれていますか?
数値はどのように書式設定されますか? コンマまたは小数点を含めますか? それらは一貫していますか?
ドキュメントのどの部分が均一で、どの部分が均一ではないのですか?
セマンティックな意味を抽出できるヘッダー構造はありますか?
箇条書きや意味のあるインデントはありますか?
画像処理の要件を決定する
ドキュメント内の画像を理解することは、画像処理戦略を選択するのに役立ちます。 イメージの種類、処理に十分な解像度があるかどうか、およびイメージに必要なすべての情報が含まれているかどうかを知る必要があります。 次の質問は、画像処理の要件を理解するのに役立ちます。
ドキュメントに画像は含まれていますか?
画像の解像度はどれくらいですか?
画像にテキストは埋め込まれていますか?
価値を付加しない抽象的な画像はありますか? たとえば、アイコンによってセマンティック値が追加されない場合があります。 アイコンの説明を追加すると、通常、アイコンがドキュメントのコンテンツに関連しないため、ソリューションに悪影響を与える可能性があります。
画像と周囲のテキストの関係は何ですか? イメージにスタンドアロン コンテンツがあるかどうか、または言語モデルに渡すときに使用する必要があるイメージの周囲にコンテキストがあるかどうかを判断します。 キャプションは、画像に含まれていない重要なコンテキストを持つ可能性がある周囲のテキストの例です。
画像のアクセシビリティの説明など、豊富なテキスト表現はありますか?
テーブル、グラフ、およびその他のメディア処理要件を決定する
テーブル、グラフ、およびその他のメディアにカプセル化されている情報を理解することは、その処理方法を決定するのに役立ちます。 次の質問は、テーブル、グラフ、およびその他のメディア処理の要件を理解するのに役立ちます。
ドキュメントには数値を含むグラフがありますか?
ドキュメントにテーブルが含まれていますか?
入れ子になったテーブルや非複合テーブルなど、テーブルは複雑ですか?
テーブルにキャプションはありますか?
テーブルの長さ 長いテーブルでは、ヘッダーをチャンク単位で繰り返す必要がある場合があります。
ビデオやオーディオなど、他の種類の埋め込みメディアはありますか?
文書に数式や科学的表記はありますか?
代表的なテスト ドキュメントを収集する
この手順では、ソリューションで使用するドキュメントを最もよく表すドキュメントを収集します。 ドキュメントでは、定義されたユース ケースに対処し、質問収集の並列フェーズで収集した質問に回答する必要があります。
考慮事項
代表的なテスト ドキュメントを評価するときは、次の点を考慮してください。
関連: ドキュメントは、会話アプリケーションのビジネス要件を満たす必要があります。 たとえば、顧客が銀行業務を実行するのに役立つチャット ボットを構築する場合、ドキュメントはその要件を満たす必要があります。 たとえば、銀行口座を開いたり閉じたりする方法がドキュメントに表示されます。 ドキュメントは、並列手順で収集したテストの質問に対処できる必要があります。 ドキュメントに質問に関連する情報がない場合、ソリューションは有効な応答を生成できません。
表現: ドキュメントは、ソリューションで使用されるさまざまな種類のドキュメントを表す必要があります。 たとえば、自動車保険のドキュメントには、医療や生保のドキュメントとは異なる情報が含まれています。 ユース ケースでは、これらの 3 つの保険の種類すべてをサポートするソリューションが必要ですが、自動車保険のドキュメントしかないとします。 あなたのソリューションは、医療および生命保険の運用に対して十分なパフォーマンスを発揮しない可能性があります。 バリエーションごとに少なくとも 2 つのドキュメントが必要です。
物理的なドキュメントの品質: ドキュメントは、使用可能な形である必要があります。 たとえば、スキャンされた画像では、使用可能な情報を抽出できない場合があります。
ドキュメント コンテンツの品質: ドキュメントには高品質のコンテンツが必要です。 スペル ミスや文法エラーを含めることはできません。 品質の低いコンテンツを提供した場合、言語モデルはうまく動作しません。
テスト ドキュメントを正常に収集するには、テスト ドキュメントが特定のドメインを完全かつ正確に表、定性的に自信を持って
テスト ドキュメントのガイダンス
合成ドキュメントよりも実際のドキュメントを選択します。 実際のドキュメントでは、個人データを削除するためにクリーニング プロセスを実行する必要があります。
合成データを使用してドキュメントを選択的に拡張することを検討してください。 このプロセスは、将来の予測シナリオを含め、ドキュメントがあらゆる種類のシナリオを対象にしていることを確認するのに役立ちます。 合成データを使用する必要がある場合は、可能な限り実際のデータに似るように最善を尽くしてください。
ドキュメントで収集した質問に対処できることを確認します。
各伝票バリアントに少なくとも 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, and directly quote the text from the provided context. Provide the array output in strict JSON format as shown in the output format. Ensure that the generated JSON is completely structurally correct, including proper nesting, comma placement, and quotation marks. There shouldn't be a comma after the last element in the array. Output format: [ { "question": "Question 1", "answer": "Answer 1" }, { "question": "Question 2", "answer": "Answer 2" } ] CONTEXT:出力を確認します。 質問がユース ケースに関連していること、および回答が質問に対処していることを確認します。 SME はこの検証を実行する必要があります。
未対処クエリ
ドキュメントがアドレス指定しないクエリと、ドキュメントがアドレス指定するクエリを収集することが重要です。 ソリューションをテストするとき、特に言語モデルをテストする場合は、回答するのに十分なコンテキストがないクエリにソリューションがどのように応答するかを決定する必要があります。 ソリューションが対処できないクエリに応答するために、ソリューションは次のことができます。
回答が不明であることを示します。
回答が不明であることを示し、ユーザーが詳細情報を見つける可能性があるリンクを提供します。
埋め込みメディアのテストクエリを収集する
テキストの場合と同様に、埋め込まれたメディアを使用して関連性の高い回答を生成する、多様な質問のセットを収集する必要があります。 グラフ、テーブル、またはスクリーンショットを含む画像がある場合は、すべてのユース ケースに関する質問があることを確認してください。 ドキュメント分析 ステップの
テスト クエリの収集に関するガイダンス
実際に顧客から寄せられた質問が収録されており、使用できるシステムがあるかどうかを判断します。 たとえば、顧客の質問に回答するチャット ボットを構築する場合、ヘルプ デスク、FAQ、またはチケット システムから顧客の質問を使用できる場合があります。
ユース ケースの顧客または SME は、収集されたドキュメント、関連するテスト クエリ、ドキュメントからのクエリに対する回答が包括的で代表的で、正しいかどうかを判断するための品質ゲートとして機能する必要があります。
質問と回答の本文を定期的に確認して、ソース ドキュメントが引き続き正確に反映されるようにします。
次の手順
関連リソース
Python 用の独自のデータ サンプルを使用してチャットを開始する