# RAG用ドキュメントの準備：プロンプトを変える前に情報源を整える

接続済みのナレッジベースや公開ヘルプサイトからドキュメントを集め、RAG用にインデックス化する前に、テキスト抽出、バージョン、チャンクの境界を確認します。

Canonical page: https://beeuni.ai/blog/ja/prepare-documents-for-rag

ナレッジベースのアシスタントが古い規定を引用したり、表の一部を回答から落としたりする。Beeuniは元の文書を読み、古いコピーやテキスト抽出の誤りを見つけ、検索インデックスに使う修正版を用意できます。配送ガイドを例に、何を確認し、どのファイルを書き出すかを説明します。

検索拡張生成（RAG）は、ドキュメントから関連する文章を探し、質問に答えるモデルに渡す仕組みです。この文章の単位はチャンクと呼ばれ、検索しやすいよう小さく分けて用意します。Beeuniエージェントは、接続済みのナレッジベースや公開ヘルプサイトからドキュメントを集め、テキストを抽出し、スクリプトでチャンクを整理できます。アプリケーション側では、選んだツールでインデックス化と検索を行います。

## ナレッジベースの保管場所から収集する

公開ヘルプサイトの場合は、エージェントに開始URLと対象にするセクションを指定します。関連リンクをたどって記事のテキストを保存し、開けなかったページを報告するよう依頼しましょう。非公開ドキュメントの場合は、サービスに接続し、対象のコレクションへのアクセス権を付与します。非公開のURLを知っているだけでは、ページを読めるとは限りません。

各ページやドキュメントの参照先、タイトル、取得日時、情報源にバージョン情報がある場合はその情報を記録したマニフェストを用意します。リポジトリのコミットを使えば、ドキュメントのスナップショットを特定できます。常に更新されるヘルプページでは、別途コピーを保存する必要があるかもしれません。エージェントは、前回のインポート内容とこの一覧を比較し、次のエクスポートを準備する前に、変更、削除、新規発見の各ページを特定できます。

## アプリケーションが間違えた質問から始める

元のドキュメントで、その質問への回答になる文章を探します。そのページと抽出されたテキスト、検索で返されたチャンクを比べてください。これにより、抽出の問題と検索の問題を切り分けられます。正しい文章がモデルに届いている場合は、回答にどう反映されたかを調べます。

| 見えている問題 | 確認すること | 変更すること |
| --- | --- | --- |
| 単位のない数値 | 表の見出しと隣接するセル | 見出しと単位を該当する行と一緒に保持する |
| 古い規則に基づく回答 | ドキュメントのバージョンと適用開始日 | 旧版のテキストを除くか、バージョンによる絞り込みを明示する |
| 文の途中で切れている | エクスポートしたテキストのチャンク境界 | 可能であれば、セクションや段落の境界で分割する |
| 検索結果に繰り返し表示されるナビゲーション | ヘッダー、フッター、ページメニュー | 内容のある注記を削除せず、繰り返される定型文を除く |
| 該当する文章が見つからない | 抽出範囲と検索結果 | 不足しているテキストを補い、インデックス化と検索を再テストする |

## 表の見出しで回答が変わることがある

配送ガイドに「発送後の営業日数」という見出しの表があり、通常配送の行に「3～5」と記載されているとします。抽出結果が「通常配送：3～5」だけなら、単位と起算点の両方が失われています。するとモデルは、その数字が日数なのか、料金なのか、別の何かなのかを推測しなければなりません。

```
Example of a passage with its context preserved:
Document: Shipping guide
Section: Delivery estimates
Service: Standard
Delivery time: 3–5 business days after dispatch
Source: sample-shipping-guide.pdf, page 2
```

この文章があれば、「発送後、通常配送ではどのくらいかかりますか？」には答えられます。しかし、発送日と該当する暦情報がなければ、「注文した商品は金曜日までに届きますか？」には答えられません。レビューには両方の質問を含めましょう。前者では表が正しく抽出されたかを、後者では情報が不足しているとアプリケーションが認識するかを確認できます。

## 各文章に付随させる情報は？

安定したドキュメントID、タイトル、セクション、可能な場合はページ参照、バージョンまたは適用開始日を保持します。公開ページでは、情報源のURLも残してください。これらのフィールドがあれば、アプリケーションで出典を示し、似た表現の異なるバージョンを区別できます。

どのコレクションにも合うチャンクサイズはありません。短いFAQの回答は、そのまま一つのチャンクにできます。長い手順書は複数に分け、それぞれにセクション見出しを付ける必要があるかもしれません。エージェントにサンプルをエクスポートさせ、元の情報源を開かずにチャンクを読んでみましょう。用語、単位、例外が読んでも理解できる状態かを確認してください。

## エージェントに評価用の質問も作成させられますか？

ドキュメントをもとに質問の候補を作成できます。アプリケーションの評価に使う前に、想定される回答と根拠となる文章を確認してください。複数のセクションをまたぐ質問、古い規則についての質問、コレクション内に回答がない質問も含めましょう。この評価セットは、システムの調整に使う例とは分けておきます。

## 検索結果をたどって問題の原因を突き止める

先ほどの架空の配送ガイドに戻りましょう。現行ガイドには、通常配送は発送後3～5営業日とあり、古いガイドには2～3日と記載されているとします。アプリケーションが「2～3日」と回答しました。質問、返された順に並べた検索結果の文章、それぞれのメタデータ、回答を保存します。これで、どこから古い規則が回答に入り込んだのかを調べられます。

古いガイドだけが表示される場合は、改訂版がインポートされたか、バージョンフィルターによって除外されていないかを確認します。両方のバージョンが表示される場合は、アプリケーションがどちらを選ぶかを調べます。正しい文章が見出しなしで届いている場合は、テキスト抽出かチャンクの境界を修正します。最新の完全な文章がモデルに届いているのに「発送後の営業日」という情報が回答から抜けているなら、回答生成を調べましょう。最後の問題は、コレクションを再抽出しても解決しません。

この記録を評価ケースに紐づけて保存します。変更後は、回答だけでなく検索結果の文章も比較してください。モデルが似た事実をすでに知っていると、もっともらしい回答が検索の失敗を覆い隠すことがあります。次に、ドキュメント固有の規則について質問したときに、問題が表面化するかもしれません。

## 評価用の質問でチャンクサイズを試す

大きなチャンクは手順と例外を一緒に保ちやすい一方、無関係なテキストもプロンプトに入り込みます。小さなチャンクなら事実を見つけやすくなる場合がありますが、その事実が成り立つ条件とは切り離されることがあります。境界部分を補うための重複は役立つこともありますが、ほぼ同じ文章が検索結果の複数の枠を占める可能性もあります。コレクション全体に設定を適用する前に、実際に返される検索結果を確認してください。

レビューした質問ごとに、回答の根拠として十分な文章を記録します。それらがアプリケーションからモデルに渡される検索結果に含まれているか確認してください。無関係な結果や重複した結果も記録します。最終回答は、事実の裏付け、出典の提示、情報不足の認識をそれぞれ分けて評価します。総合スコアだけでは、どの部分が変化したのか把握しにくくなります。

評価用の質問と検索設定は、各エクスポートと一緒に保存します。情報源のテキストを整理して試すときは、まず同じ検索設定を使います。チャンクサイズやランキングを試すときは、情報源のバージョンを固定します。両方を同時に変えると回答が改善するかもしれませんが、どちらが役立ったのか分からなくなります。

## Beeuniから何をエクスポートすればよいですか？

整形済みテキスト、メタデータ付きの文章レコード、情報源のマニフェスト、抽出に失敗した項目の一覧をエクスポートするよう依頼します。それらのファイルをインデックス化パイプラインに取り込みます。

[データセット準備ガイド](/blog/ja/build-ai-training-dataset-jsonl)では、レビュー記録とデータ分割について説明しています。アプリケーションから準備処理を実行する必要がある場合は、[エージェントのバックエンドとしてBeeuniを使う](/blog/ja/use-beeuni-as-your-agent-backend)をご覧ください。