検索拡張生成 (RAG) の開発と実験の最初のフェーズは、準備フェーズです。 このフェーズでは、最初にソリューションのビジネス ドメインを定義します。 ドメインを定義したら、ドメインに関連するドキュメントとサンプルの質問を収集する並列プロセスを開始します。 手順は相互に関連しているため、並行して実行されます。 質問はドキュメント内のコンテンツで回答可能なものでなければならず、ドキュメントは関連する質問に回答するものである必要があります。 テスト ドキュメントとクエリを収集しながら、ドキュメントの分析を実行して、構造とコンテンツについて理解を深めます。
この記事はシリーズの一部です。 概要を参照してください。
ソリューション ドメインを決定する
このプロセスの最初の手順は、ソリューションまたはユース ケースのビジネス要件を明確に定義することです。 これらの要件は、ソリューションがどのような質問に対処しようとしているのか、どのようなソース データまたはドキュメントがそうした質問の対処に役立つのかを判断するのに役立ちます。 後半の段階で、このソリューション ドメインは埋め込みモデル戦略を通知するのに役立ちます。
代表的なテスト ドキュメントを収集する
この手順では、運用ソリューションで使用するドキュメントを最も適切に表現したドキュメントを収集します。 対象ドキュメントは、定義されたユース ケースに対処し、並行して行われる質問収集フェーズで収集された質問に回答できるものである必要があります。
考慮事項
代表的なものの可能性があるテスト ドキュメントを評価するときは、次の点を考慮してください。
- 妥当性 - ドキュメントは、会話型アプリケーションのビジネス要件を満たす必要があります。 たとえば、銀行業務の実行する顧客を支援する任務を負ったチャット ボットを構築する場合、ドキュメントはその要件に一致している必要があります (銀行口座の開設方法と解約方法を示すドキュメントなど)。 ドキュメントは、並行して行われる手順で収集されるテストの質問に対処できる必要があります。 質問に関連する情報がドキュメントにない場合は、有効な応答を生成できません。
- 代表的 - ドキュメントは、ソリューションで使用されるさまざまな種類のドキュメントを代表するものである必要があります。 たとえば、自動車保険のドキュメントは、医療保険や生命保険のドキュメントとは異なります。 ユース ケースで、ソリューションが 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 は、収集されたドキュメント、関連するテスト クエリ、およびドキュメントからのクエリに対する回答が包括的であり、代表的なものであり、正しいものかどうかを判断するための品質ゲートとして機能する必要があります。
- 質問と回答の本文を定期的に確認して、継続的にソース ドキュメントを正確に反映する必要があります。
ドキュメント分析
ドキュメント分析の目標は、次の 3 つを決定することです。
- 無視または除外するドキュメントの内容
- チャンク単位でキャプチャするドキュメントの内容
- ドキュメントをチャンクする方法
これらの 3 つの決断を下すのに役立つドキュメントの種類を分析するときの、一般的な質問を次にいくつか示します。
- ドキュメントに目次は含まれていますか?
- ドキュメントに画像は含まれていますか?
- 高解像度の画像ですか?
- 画像に含まれているデータの種類は何ですか?
- 画像にキャプションはありますか?
- 画像にテキストは埋め込まれていますか?
- ドキュメントにはグラフがあり、数値が表示されていますか?
- ドキュメントにテーブルが含まれていますか?
- テーブルは複雑ですか (入れ子になったテーブル)、それとも複雑ではありませんか?
- テーブルにキャプションはありますか?
- 複数列のデータまたは複数列の段落はありますか? 複数列のコンテンツを 1 つの列であるかのように解析すべきではありません。
- 段落はいくつありますか? 段落の長さはどれぐらいですか? 段落の長さはほぼ同じですか?
- ドキュメントに含まれる言語、言語バリアント、または方言は何ですか?
- ドキュメントに Unicode 文字が含まれていますか?
- 数値はどのように書式設定されますか? コンマまたは小数点を使用していますか?
- ヘッダーとフッターはありますか? 必要ですか?
- 著作権や免責事項はありますか? 必要ですか?
- ドキュメント内で何が統一され、何が統一されていませんか?
- セマンティックな意味を抽出できるヘッダー構造はありますか?
- 脚注や巻末の注はありますか?
- 透かしはありますか?
- 注釈やコメントはありますか (PDF や Word 文書など)
- ビデオやオーディオなどの他の種類の埋め込みメディアはありますか?
- ドキュメント内に数式/科学的表記はありますか?
- 箇条書きや意味のあるインデントはありますか?
これらの質問に対する回答は、ドキュメント構造の特定、チャンク アプローチの決定、チャンク対象のコンテンツと対象ではないコンテンツの特定に役立ちます。