公開ページをMarkdownとメタデータに変換し、S3経由でKnowledge Basesへ取り込む実装例です。標準のWeb Crawlerで足りる場合はそちらを起点とします。 検索対象に何を残すかと、更新・削除をどう同期するかが品質を左右します。取り込み前の加工と検索時のリアルタイム参照を区別して設計することが論点です。 標準クローラーを補う前処理の実装例 AWSは11月2日、Crawl4AIを使ってウェブの情報をBedrock Knowledge Basesへ取り込む手順を公開しました。RAGの回答品質を、取り込む情報の段階から整える内容です。原文はまず、管理されたWeb Crawlerを一般的な公開サイトの出発点としています。そのうえで、本文の領域だけを抽出したい場合や、独自の属性を加えたい場合に追加の前処理を提案しています。Crawl4AIは公開ページからMarkdownと対応するメタデータを作ります。これらをS3へ保存し、Knowledge Basesのデータソースから取り込みます。特定のサイトを定期的に取り込む構成であり、質問のたびに最新のウェブを参照する仕組みではありません。 本文抽出と属性付与を扱うチームが対象 対象は、社外の公開情報を検索できる社内アシスタントや、情報提供サービスを開発するチームと見られます。ナビゲーションなどの共通部分を除き、見出しや表を保って取り込む場面に適します。取得元のURL、取得時刻、文書の種類などを付けることで、検索時の絞り込みにもつなげます。構成例ではEventBridgeが定期的に処理を開始し、ECSのタスクをFargateで動かします。前処理とアップロード後に、取り込みジョブを起動する流れです。取り込み以降の解析や分割、埋め込みと検索はKnowledge Basesが担います。標準のクローラーで目的を満たす場合まで、独自の処理を必須にするものではありません。情報源ごとの加工要件を確かめて、運用する構成を選ぶことになります。 取得範囲と検索品質を一緒に確認する 実務では、許可された取得先とページ数、深さ、間隔を先に決めることが論点になります。サンプルは公開ページを対象とし、認証済みセッションを実装していません。認証が必要なサイトでは、標準クローラーの選択肢を先に評価するよう説明しています。また、本文を残すフィルターは経験的な処理のため、代表的な出力を人が確認する必要があります。取り込めたという事実だけでは、必要な表や条件が残ったとは限りません。原文の構成は文書と属性ファイルを対で保存します。属性の大きさや保存先の設定も、取り込み前に確かめる対象です。定期実行の費用だけでなく、元のページの変更に合わせて抽出規則を直す保守負担も、導入判断に含めることが考えられます。 分割方法は代表的な質問で選ぶ 原文は、データソース接続時に選ぶ分割方法を後から変更できないと説明しています。別の方法へ変える場合は、新しいデータソースが必要です。導入時には代表的なページと質問で検索結果を比較することが判断点になります。元情報の更新と、保存済み文書の更新をどう対応させるかも確認対象です。加工処理を増やす効果は、文書の見た目だけでなく、回答が必要な根拠へ到達できるかで測ることが考えられます。検索結果の鮮度を示す運用も論点になります。