翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon Bedrock ナレッジベースの仕組み Amazon Bedrock のナレッジベースは、検索拡張生成 (RAG) の活用に役立ちます。RAG は、データストアから情報を取得して、大規模言語モデル (LLM) によって生成されるレスポンスを拡張する一般的な手法です。データソースを使用してナレッジベースを設定すると、アプリケーションはナレッジベースに対してクエリを実行し、ソースからの直接の引用、またはクエリ結果から生成される自然なレスポンスによってクエリに答える情報を返すことができます。 Amazon Bedrock ナレッジベースを使用すると、ナレッジベースでのクエリから得られるコンテキストによって強化されたアプリケーションを構築できます。パイプライン構築の面倒な作業から解放され、すぐに使える RAG ソリューションを提供することでアプリケーションの構築時間を短縮できるため、市場投入までの時間を短縮できます。また、ナレッジベースを追加することで、プライベートデータを活用できるようにモデルを継続的にトレーニングする必要がなくなるため、費用対効果も向上します。 以下の図は、RAG がどのように実行されるかを概略的に示しています。ナレッジベースは、このプロセスのいくつかのステップを自動化することで、RAG の設定と実装を簡素化します。 **非構造化データの前処理** 非構造化プライベートデータ (構造化データストアに存在しないデータ) を効果的に検索できるようにするには、データをテキストに変換してから、管理しやすいかたまりに分割するのが一般的です。このかたまり (チャンク) は埋め込みに変換され、元のドキュメントへのマッピングを維持したままベクトルインデックスに書き込まれます。これらの埋め込みは、クエリとデータソースからのテキストの意味上の類似性を判断するために使用されます。以下の図は、ベクトルデータベース用のデータの前処理を示しています。 ![\[検索拡張生成のためにデータを前処理する\]](http://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/images/kb/rag-preprocess.png) ベクトル埋め込みとは、テキストの各チャンクを表す一連の数値です。モデルは、各テキストチャンクをベクトルと呼ばれる一連の数値に変換し、テキストを数学的に比較できるようにします。これらのベクトルは、浮動小数点数 (float32) またはバイナリ数のいずれかです。Amazon Bedrock でサポートされているほとんどの埋め込みモデルは、デフォルトで浮動小数点ベクトルを使用します。ただし、一部のモデルはバイナリベクトルをサポートしています。バイナリ埋め込みモデルを選択する場合は、バイナリベクトルをサポートするモデルとベクトルストアも選択する必要があります。 1 ディメンションあたり 1 ビットしか使用しないバイナリベクトルは、1 ディメンションあたり 32 ビットを使用する浮動小数点 (float32) ベクトルほどストレージにコストがかかりません。ただし、バイナリベクトルは、テキストの表現が浮動小数点ベクトルほど正確ではありません。 次の例は、3 つの表現のテキストを示しています。 **** | 表記 | 値 | | --- | --- | | テキスト | "Amazon Bedrock は、主要な AI 企業や Amazon が提供する高パフォーマンスな基盤モデルを使用します。" | | 浮動小数点ベクトル | [0.041..., 0.056..., -0.018..., -0.012..., -0.020..., ...] | | バイナリベクトル | [1,1,0,0,0, ...] | **ランタイムの実行** 実行時には、埋め込みモデルを使用してユーザーのクエリをベクトルに変換します。次に、ドキュメントベクトルとユーザークエリベクトルを比較して、ベクトルインデックスをクエリしてユーザークエリの検索対象に意味的に類似したチャンクを検索します。最後のステップでは、ベクトルインデックスから取得したチャンクの追加コンテキストがユーザープロンプトに追加されます。その後、追加のコンテキストと共にプロンプトがモデルに送信され、ユーザーへのレスポンスが生成されます。以下の画像は、RAG が実行時にどのように動作してユーザークエリへのレスポンスを補強するかを示しています。 ![\[実行時の検索拡張生成\]](http://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/images/kb/rag-runtime.png) データをナレッジベースに変換する方法、ナレッジベースの設定後にナレッジベースへのクエリを実行する方法、取り込み中にデータソースに適用できるカスタマイズの詳細については、以下のトピックを参照してください。 **Topics** + [データをナレッジベースに変換する](kb-how-data.md) + [Amazon Bedrock ナレッジベースを使用してデータソースから情報を取得する](kb-how-retrieval.md) + [ナレッジベースのカスタマイズ](kb-how-customization.md) # データをナレッジベースに変換する ナレッジベースを作成するには、ナレッジベースがアクセスできるサポートされているデータソースに接続します。ナレッジベースは、ユーザーのクエリに応答したり、取得したデータに基づいて応答を生成したりできるようになります。 Amazon Bedrock ナレッジベースは、テキスト、画像、またはテーブル、グラフ、図、その他の画像を含んだマルチモーダルドキュメントなど、さまざまなドキュメントをサポートしています。*マルチモーダル*データとは、テキストデータとビジュアルデータの組み合わせを指します。非構造化データを含むファイルタイプの例は、テキスト、マークダウン、HTML、PDF などです。 次のセクションでは、Amazon Bedrock ナレッジベースがサポートするデータのタイプと、ナレッジベースを接続できるサービスについて、データのタイプごとに説明します。 ## Unstructured data (非構造化データ) 非構造化データとは、事前定義された構造に強制されないデータを指します。Amazon Bedrock ナレッジベースでは、ナレッジベースに非構造化データを追加するために次のサービスに接続することがサポートされています。 + Amazon S3 + Confluence (プレビュー) + Microsoft SharePoint (プレビュー) + Salesforce (プレビュー) + Web Crawler (プレビュー) + カスタムデータソース (同期せずにナレッジベースにデータを直接取り込むことができます) データソースには、ドキュメントの raw 形式が含まれています。クエリプロセスを最適化するために、ナレッジベースは raw データをデータの数値表現である*ベクトル埋め込み*に変換し、ベクトル埋め込みにも変換されるクエリとの類似性を定量化します。Amazon Bedrock ナレッジベースは、データソースの変換プロセスで次のリソースを使用します。 + 埋め込みモデル – データをベクトル埋め込みに変換する基盤モデル。テキストと画像の両方を含むマルチモーダルデータの場合、Amazon Titan Multimodal Embeddings G1 や Cohere Embed v3 などのマルチモーダル埋め込みモデルを使用できます。 + ベクトルストア – データのベクトル表現を保存するサービス。次のベクトルストアがサポートされています。 + Amazon OpenSearch Serverless + Amazon Neptune + Amazon Aurora (RDS) + Pinecone + Redis Enterprise Cloud + MongoDB アトラス データをベクトル埋め込みに変換するプロセスは、*取り込み*と呼ばれます。データをナレッジベースに変換する取り込みプロセスには、次のステップが含まれます。 **取り込み** 1. データは、選択したパーサーによって解析されます。解析の詳細については、「[データソースの解析オプション](kb-advanced-parsing.md)」を参照してください。 1. データソース内の各ドキュメントは、トークンの数やその他のパラメータによって定義できるデータの細分化である*チャンク*に分割されます。チャンキングの詳細については、「[ナレッジベースのコンテンツのチャンキングの仕組み](kb-chunking.md)」を参照してください。 1. 選択した埋め込みモデルで、データはベクトル埋め込みに変換されます。マルチモーダルコンテンツの場合、画像はビジュアルベクトルとして埋め込まれ、テキストはテキストベクトルとして埋め込まれ、両方のモダリティで検索できます。 1. ベクトル埋め込みは、選択したベクトルストアのベクトルインデックスに書き込まれます。 取り込みプロセスが完了すると、ナレッジベースのクエリを実行する準備が整います。クエリを実行してナレッジベースから情報を取得する方法の詳細については、「[Amazon Bedrock ナレッジベースを使用してデータソースから情報を取得する](kb-how-retrieval.md)」を参照してください。 データソースに変更を加える場合は、変更を同期して、追加、変更、削除をナレッジベースに取り込む必要があります。一部のデータソースでは、ナレッジベースへのファイルの直接取り込みやファイルの削除がサポートされているため、データソースの変更と取り込みを個別のステップとして扱う必要がなくなり、常にフル同期を実行する必要もなくなります。ナレッジベースとそれをサポートするデータソースにドキュメントを直接取り込む方法については、「[変更をナレッジベースに直接取り込む](kb-direct-ingestion.md)」を参照してください。 Amazon Bedrock ナレッジベースには、データの取り込み方法をカスタマイズするためのさまざまなオプションが用意されています。このプロセスをカスタマイズする方法の詳細については、「[ナレッジベースのカスタマイズ](kb-how-customization.md)」を参照してください。 ## 構造化データ 構造化データとは、それが存在するデータストアによって事前定義された形式の表形式データを指します。Amazon Bedrock ナレッジベースは、Amazon Redshift クエリエンジンを使用してサポートされている構造化データストアに接続します。Amazon Bedrock ナレッジベースは、クエリパターン、クエリ履歴、スキーマメタデータを分析して自然言語クエリを SQL クエリに変換するフルマネージドメカニズムを備えています。これらの変換されたクエリは、サポートされているデータソースから関連情報を取得するために使用されます。 Amazon Bedrock ナレッジベースでは、ナレッジベースに構造化データストアを追加するために次のサービスに接続することがサポートされています。 + Amazon Redshift + AWS Glue Data Catalog(AWS Lake Formation) ナレッジベースを構造化データ ストアに接続する場合、データをベクトル埋め込みに変換する必要はありません。代わりに、Amazon Bedrock ナレッジベースは構造化データストアのクエリを直接実行できます。クエリ中、Amazon Bedrock ナレッジベースはユーザークエリを SQL クエリに変換して、ユーザークエリに関連するデータを取得し、より正確な応答を生成できます。データを取得せずに SQL クエリを生成し、他のワークフローで使用することもできます。 例えば、データベースリポジトリには、顧客とその購入に関する情報を持つ次のテーブルが含まれています。 **** | カスタマー ID | 2020 年に購入した金額 | 2021 年に購入した金額 | 2022 年に購入した金額 | 現在までに合計購入金額 | | --- | --- | --- | --- | --- | | 1 | 200 | 300 | 500 | 1,000 | | 2 | 150 | 100 | 120 | 370 | | 3 | 300 | 300 | 300 | 900 | | 4 | 720 | 180 | 100 | 900 | | 5 | 500 | 400 | 100 | 1,000 | | 6 | 900 | 800 | 1,000 | 2700 | | 7 | 470 | 420 | 400 | 1290 | | 8 | 250 | 280 | 250 | 780 | | 9 | 620 | 830 | 740 | 2190 | | 10 | 300 | 200 | 300 | 800 | ユーザークエリが「支出額上位 5 名の顧客の概要を教えてください」というものである場合、ナレッジベースは次を実行する可能性があります。 + クエリを SQL クエリに変換する。 + 次を含むテーブルから抜粋を返す。 + 関連するテーブル列「カスタマー ID」と「現在までの合計購入金額」 + 支出額が最も多い 10 名の顧客の合計購入額を含むテーブル行 + 支出額上位 5 名の顧客と、その顧客が購入した金額を示す応答を生成します。 ナレッジベースでテーブルの抜粋を生成できるクエリのその他の例は次のとおりです。 + 「2020 年の支出額で上位 5 名の顧客」 + 「2020 年の購入額で上位の顧客」 + 「2020～2022 年の購入額で上位 5 名の顧客」 + 「2020～2022 年で最も支出の多い顧客上位 5 名」 + 「合計購入金額が 10 USD 未満の顧客」 + 「支出が最も少ない顧客上位 5 名」 クエリが具体的かつ詳細であるほど、ナレッジベースは正確な情報を絞り込んで返すことができます。例えば、「2020 年の支出額で上位 10 名の顧客」というクエリではなく、「2020 年の顧客について、現在までの合計購入金額が上位 10 名を見つけてください」のほうがより具体的なクエリです。この具体的なクエリは、顧客支出データベーステーブルの列名「現在までの合計購入金額」を参照しており、データを「上位」で並べ替える必要があることも示しています。 # Amazon Bedrock ナレッジベースを使用してデータソースから情報を取得する ナレッジベースの設定後、ナレッジベース内のデータソースをクエリするようにアプリケーションを設定できます。ナレッジベースをクエリするには、以下の API オペレーションを利用できます。 + [https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_Retrieve.html](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_Retrieve.html) – クエリに最も関連性の高いソースチャンクまたはイメージをデータから取得し、レスポンスで配列として返します。 + [https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_RetrieveAndGenerate.html](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_RetrieveAndGenerate.html) – Amazon Bedrock で、`Retrieve` オペレーションと [InvokeModel](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModel.html) オペレーションを結合し、クエリに最も関連性の高いソースチャンクをデータから取得し、自然言語のレスポンスを生成します。データから特定のソースチャンクへの引用も含まれます。データソースにビジュアル要素が含まれている場合、モデルはテキストレスポンスを生成する際にこれらのイメージからのインサイトを活用し、イメージのソース属性を提供します。 + [GenerateQuery](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_GenerateQuery.html) – 自然言語のユーザークエリを構造化データストアに適した形式のクエリに変換します。 `RetrieveAndGenerate` オペレーションは、`GenerateQuery` (ナレッジベースが構造化データストアに接続されている場合)、`Retrieve`、`InvokeModel` を背後で使用して、RAG プロセス全体を実行する複合アクションです。Amazon Bedrock ナレッジベースは、`Retrieve` オペレーションへのアクセスも提供するため、特定のユースケースに合わせて RAG の各ステップを切り離し、カスタマイズできます。 `Retrieve` または `RetrieveAndGenerate` を使用する際に[再ランク付けモデル](rerank.md)を使用して、クエリ中に取得されたドキュメントの関連性を再ランク付けすることもできます。 ナレッジベースのクエリ時にこれらの API オペレーションを使用する方法については、「[クエリとレスポンスを使用してナレッジベースをテストする](knowledge-base-test.md)」を参照してください。 # ナレッジベースのカスタマイズ Amazon Bedrock ナレッジベースは、データソースをナレッジベースに取り込む方法をカスタマイズするオプションを提供しており、データの保存、解析、エンドユーザーへの返答方法を柔軟に選択できます。ナレッジベースの設定時に検討できるカスタマイズオプションの詳細については、次のトピックのいずれかを選択してください。 **Topics** + [ナレッジベースのコンテンツのチャンキングの仕組み](kb-chunking.md) + [データソースの解析オプション](kb-advanced-parsing.md) + [カスタム変換 Lambda 関数を使用してデータの取り込み方法を定義する](kb-custom-transformation.md) + [データソースにメタデータを含めてナレッジベースのクエリを改善する](kb-metadata.md) # ナレッジベースのコンテンツのチャンキングの仕組み Amazon Bedrock では、データを取り込むとき、データ検索を効率化するため、まずドキュメントやコンテンツを管理しやすいかたまり (チャンク) に分割します。それらのチャンクは埋め込みに変換され、分割前のドキュメントへのマッピングを維持したままベクトルインデックス (データのベクトル表現) に書き込まれます。ベクトル埋め込みにすることで、テキストを定量的に比較できるようになります。 **Topics** + [標準のチャンキング](#kb-standard-chunking) + [階層的チャンキング](#kb-hiearchical-chunking) + [セマンティックチャンキング](#kb-semantic-chunking) + [マルチモーダルコンテンツのチャンキング](#kb-multimodal-chunking) ## 標準のチャンキング Amazon Bedrock は、次の標準的なチャンキング方法に対応しています。 **注記** テキストチャンキング戦略は、テキストドキュメントにのみ適用されます。マルチモーダルコンテンツ (オーディオ、ビデオ、画像) の場合、チャンキングはこれらのテキストベースの戦略ではなく、埋め込みモデルレベルで行われます。 + 固定サイズのチャンキング: チャンクあたりのトークン数と重複率を指定することで、目的のチャンクサイズを設定できます。具体的な要件に柔軟に対応できます。チャンク内のトークン数の上限と、連続するチャンク間の重複率を設定できます。 **注記** 解析されたコンテンツ (高度なパーサーを使用したコンテンツや HTML から変換されたコンテンツなど) の場合、Amazon Bedrock ナレッジベースはコンテンツをチャンクして最適な結果が得られるように最適化する場合があります。チャンカーは論理ドキュメントの境界 (ページやセクションなど) を尊重し、最大トークンサイズを大きくしても、これらの境界を越えてコンテンツをマージしません。 + デフォルトのチャンキング: コンテンツを約 300 トークンずつのテキストチャンクに分割します。文の区切りが認識され、文が途切れずに各チャンク内に収まるように処理されます。 ドキュメントをチャンキングしないという選択肢もあります。その場合、各ドキュメントが 1 つのテキストチャンクとして扱われます。チャンキングのアプローチ/戦略として [チャンキングなし] を選択する場合は、前処理として、ドキュメントを別々のファイルに分割しておいてもよいでしょう。ドキュメントのチャンキングを選択しない場合、引用内のページ番号を表示したり、*x-amz-bedrock-kb-document-page-number* メタデータフィールド/属性でフィルタリングしたりすることはできません。 ## 階層的チャンキング 階層的チャンキングでは、情報を子チャンクと親チャンクというネスト構造で整理します。データソースの作成時に、親チャンクと子チャンクのサイズ、各チャンク間で重複するトークンの数を定義できます。検索中は、最初は子チャンクが取得されますが、さらに包括的なコンテキストをモデルに提供するために、より広範な親チャンクに置き換えられます。 小さなテキスト埋め込みの方が精度は高くなりますが、検索の目的は包括的なコンテキストを提供することです。階層的チャンキングのシステムは、取得した子チャンクを適宜親チャンクに置き換えることで、これらのニーズのバランスを図ります。 **注記** 子チャンクは取り込み時に親チャンクに置き換えられるため、返される結果の数は、リクエストされた量よりも少なくなる可能性があります。 S3 ベクトルバケットをベクトルストアとして使用する場合は、階層チャンキングはお勧めしません。チャンキングに多数のトークンを使用する場合 (合計 8,000 個を超えるトークン）、メタデータサイズの制限が発生する可能性があります。 階層的チャンキングのため、Amazon Bedrock ナレッジベースでは 2 つのレベル (チャンキングの深さ) を指定できます。 + 親: 親チャンクの最大トークンサイズを設定します。 + 子: 子チャンクの最大トークンサイズを設定します。 また、チャンク間の重複トークン数も設定します。これは、連続する親チャンク間および連続する子チャンク間で重複するトークンの絶対数です。 ## セマンティックチャンキング セマンティックチャンキングは自然言語処理の手法です。テキストを意味のあるチャンクに分割するので、理解度と情報検索が向上します。単に構文的な構造だけでなく、意味的なコンテンツに焦点を当てることで、検索精度を向上させることが狙いです。関連情報をより高い精度で抽出し、操作しやすくなる可能性があります。 セマンティックチャンキングを設定する場合、次のハイパーパラメータを指定することができます。 + 最大トークン数: 1 つのチャンクに含めるべきトークンの最大数。文の区切りを考慮して設定します。 + バッファサイズ: 特定の文について、埋め込みの作成用に追加される前後の文の数を定義します。例えば、バッファサイズが 1 の場合は、3 つの文 (現在の文、前の文、次の文) を組み合わせて埋め込みます。このパラメータは、各チャンクの境界を判断するために一緒に調べるテキストの量を左右し、その結果、チャンクの粒度と一貫性に影響を及ぼします。バッファサイズを大きくすると、取り込めるコンテキストが増える分、ノイズも生じやすくなります。一方、バッファサイズを小さくすると重要なコンテキストを見逃す可能性がありますが、より正確なチャンキングが保証されます。 + ブレークポイントのパーセンタイルしきい値: 文章間の距離/非類似性のしきい値 (パーセント値)。これを基に文章間の区切り位置が決まります。しきい値が高いほど、文が区別しやすくないと、異なるチャンクに分割されません。しきい値が高いと、チャンク数が少なくなり、通常はチャンクの平均サイズが大きくなります。 **注記** セマンティックチャンキングでは、基盤モデルを使用するため、追加のコストがかかります。データの量によってコストは異なります。基盤モデルのコストの詳細については、「[Amazon Bedrock の料金](https://aws.amazon.com/bedrock/pricing/)」を参照してください。 ## マルチモーダルコンテンツのチャンキング マルチモーダルコンテンツ (オーディオ、ビデオ、画像) の場合、チャンキング動作はテキストドキュメントとは異なります。 + **Nova マルチモーダル埋め込み:** チャンキングは埋め込みモデルレベルで発生します。オーディオとビデオのチャンク期間は 1～30 秒 (デフォルト: 5 秒) に設定できます。ビデオファイルの場合、ビデオにオーディオが含まれている場合でも、ビデオチャンク期間のみが適用されます。オーディオチャンク期間は、スタンドアロンのオーディオファイルにのみ適用されます。 + **Bedrock Data Automation (BDA) パーサー:** コンテンツは最初にテキスト (トランスクリプトとシーンの概要) に変換され、変換されたテキストに標準のテキストチャンキング戦略が適用されます。 **注記** Nova マルチモーダル埋め込みを使用する場合、ナレッジベースで設定されたテキストチャンキング戦略は、音声、動画、画像ファイルではなく、データソース内のテキストドキュメントにのみ影響します。 # データソースの解析オプション 解析とは、未加工データに含まれているコンテンツを理解し、抽出することを指します。Amazon Bedrock ナレッジベースには、取り込み中にデータソースを解析するための以下のオプションがあります。 + **Amazon Bedrock デフォルトパーサー** – .txt、.md、.html、.doc/.docx、.xls/.xlsx、.pdf ファイルなどのテキストファイル内のテキストのみを解析します。このパーサーには使用料はかかりません。 **注記** デフォルトパーサーはテキストのみを出力するため、ドキュメントに図、チャート、テーブル、画像が含まれている場合は、デフォルトパーサーではなく、Amazon Bedrock Data Automation または基盤モデルをパーサーとして使用することをお勧めします。Amazon Bedrock Data Automation と基盤モデルは、ドキュメントからこれらの要素を抽出し、出力として返すことができます。 + Amazon Bedrock ナレッジベースには、.jpeg および .png の画像ファイルに加えて、.pdf ファイル内の図、チャート、テーブルなどのマルチモーダルデータを解析するための以下のパーサーが用意されています。これらのパーサーは、これらの図、チャート、テーブル、画像を抽出し、ナレッジベースの作成時に指定した S3 送信先にファイルとして保存することもできます。ナレッジベースの取得中に、これらのファイルをレスポンスまたはソース属性で返すことができます。 + **Amazon Bedrock Data Automation** – マルチモーダルデータを効果的に処理するフルマネージドサービス。追加のプロンプトを指定する必要はありません。このパーサーのコストは、ドキュメントのページ数や処理される画像の数によって異なります。このサービスの詳細については、「[Amazon Bedrock Data Automation](bda.md)」を参照してください。 + **基盤モデル** – 基盤モデルを使用してマルチモーダルデータを処理します。このパーサーには、データ抽出に使用されるデフォルトのプロンプトをカスタマイズするオプションがあります。このパーサーのコストは、基盤モデルによって処理される入出力トークンの数によって異なります。Amazon Bedrock ナレッジベースのデータの解析をサポートするモデルのリストについては、「[解析でサポートされているモデルとリージョン](knowledge-base-supported.md#knowledge-base-supported-parsing)」を参照してください。 **重要** Amazon Bedrock Data Automation または基盤モデルをパーサーとして選択した場合、.pdf ファイルにテキストのみが含まれていても、選択した方法でデータソース内のすべての .pdf ファイルが解析されます。デフォルトパーサーは、これらの .pdf ファイルの解析には使用されません。お客様のアカウントには、これらのファイルを解析する際に使用した Amazon Bedrock Data Automation または基盤モデルの料金が課金されます。 データの解析方法を選択するときは、次の点を考慮してください。 + データは純粋にテキストなのか、それとも画像、グラフ、チャートなどのマルチモーダルデータが含まれており、それらをナレッジベースでクエリできるようにするのか。 + データの解析方法をモデルに指示するために使用されるプロンプトをカスタマイズするオプションが必要かどうか。 + パーサーのコスト。Amazon Bedrock Data Automation では 1 ページあたりの料金が使用されますが、基盤モデルのパーサーの料金は入出力トークンに基づいて課金されます。詳細については、「[Amazon Bedrock の料金体系](https://aws.amazon.com/bedrock/pricing/)」ページを参照してください。 + ファイルの合計サイズ制限。基盤モデルをパーサーとして使用する場合、すべてのファイルの合計ファイルサイズは 100 GB 以下にする必要があります。 ナレッジベースの解析方法を設定する方法については、「[データソースをナレッジベースと接続する](data-source-connectors.md)」のデータソースの接続設定を参照してください。 # カスタム変換 Lambda 関数を使用してデータの取り込み方法を定義する カスタム変換の Lambda 関数を定義して、ナレッジベースの取り込みプロセスに独自のロジックを挿入できます。 具体的なチャンキングロジックがあり、これが Amazon Bedrock のナレッジベースではネイティブサポートされていない場合があります。その場合は、チャンキングの戦略として [チャンキングなし] を選択し、使用するチャンキングロジックを含む Lambda 関数を指定します。さらに、Lambda 関数によるチャンク化の対象ファイルをナレッジベースが書き込む先の Amazon S3 バケットを指定する必要があります。 Lambda 関数はファイルをチャンキングした後、同じバケットに書き戻し、ナレッジベースで後処理を行えるように参照を返します。オプションで、S3 バケットに保存されるファイルを暗号化するため、独自の AWS KMS キーを指定できます。 **注記** ウェブコネクタを使用する場合、HTML の代わりに Markdown テキストが Lambda に渡されます。 または、チャンクレベルのメタデータを指定し、ナレッジベースにはネイティブサポートされているチャンキング戦略のいずれかを適用させることもできます。この場合、定義済みのチャンキング戦略 (例えば、デフォルトまたは固定サイズのチャンキング) のいずれかを選択すると同時に、Lambda 関数と S3 バケットへの参照を指定します。ナレッジベースは、解析と前処理のチャンク化を行ったファイルを事前定義済みの S3 バケットに保存し、その後、チャンクレベルのメタデータを追加するために Lambda 関数を呼び出します。 チャンクレベルのメタデータを追加した後、Lambda 関数はチャンク化されたファイルを同じバケットに書き戻し、ナレッジベースで後処理を行えるように参照を返します。衝突が生じた場合は、チャンクレベルのメタデータが優先され、ファイルレベルのメタデータが上書きされます。 カスタムのチャンキングに Python Lambda 関数を使用する例については、「[Custom chunking using Lambda function](https://github.com/aws-samples/amazon-bedrock-samples/blob/main/rag/knowledge-bases/features-examples/03-optimizing-accuracy-retrieved-results/advanced_chunking_options.ipynb)」を参照してください。 API およびファイル契約については、以下の構造を参照してください。 **Lambda 関数を使用してカスタム変換を追加する場合の API 契約** ``` { ... "vectorIngestionConfiguration": { "customTransformationConfiguration": { // Custom transformation "intermediateStorage": { "s3Location": { // the location where input/output of the Lambda is expected "uri": "string" } }, "transformations": [{ "transformationFunction": { "transformationLambdaConfiguration": { "lambdaArn": "string" } }, "stepToApply": "string" // enum of POST_CHUNKING }] }, "chunkingConfiguration": { "chunkingStrategy": "string", "fixedSizeChunkingConfiguration": { "maxTokens": "number", "overlapPercentage": "number" } ... } } } ``` **カスタムの Lambda 変換の入力形式** ``` { "version": "1.0", "knowledgeBaseId": "string", "dataSourceId": "string", "ingestionJobId": "string", "bucketName": "string", "priorTask": "string", "inputFiles": [{ "originalFileLocation": { "type": "S3", "s3_location": { "uri": "string" } }, "fileMetadata": { "key1": "value1", "key2": "value2" }, "contentBatches": [{ "key":"string" }] }] } ``` **カスタムの Lambda 変換の出力形式** ``` { "outputFiles": [{ "originalFileLocation": { "type": "S3", "s3_location": { "uri": "string" } }, "fileMetadata": { "key1": "value1", "key2": "value2" }, "contentBatches": [{ "key": "string" }] }] } ``` **で参照されるオブジェクトのファイル形式`fileContents`** ``` { "fileContents": [{ "contentBody": "...", "contentType": "string", // enum of TEXT, PDF, ... "contentMetadata": { "key1": "value1", "key2": "value2" } } ... ] } ``` # データソースにメタデータを含めてナレッジベースのクエリを改善する CSV (カンマ区切り値) ファイルを取り込む場合、ナレッジベースで特定の列をコンテンツフィールドとメタデータフィールドとして扱うことができます。コンテンツ/メタデータファイルのペアは数百または数千にのぼる場合がありますが、その代わりに、単一の CSV ファイルと対応する metadata.json ファイルを用意し、CSV 内の各列をナレッジベースでどのように扱うべきかヒントを提供できるようになりました。 チャンクあたりのドキュメントメタデータフィールド/属性には制限があります。「[Quotas for knowledge bases](https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.html)」を参照してください。 CSV ファイルを取り込む前に、次の点を確認してください。 + CSV が RFC4180 形式であり、UTF-8 でエンコードされている。 + CSV の最初の行に、ヘッダー情報が含まれている。 + metadata.json に指定されているメタデータフィールドが、CSV に列として存在している。 + 次の形式の fileName.csv.metadata.json ファイルを用意する。 ``` { "metadataAttributes": { "${attribute1}": "${value1}", "${attribute2}": "${value2}", ... }, "documentStructureConfiguration": { "type": "RECORD_BASED_STRUCTURE_METADATA", "recordBasedStructureMetadata": { "contentFields": [ { "fieldName": "string" } ], "metadataFieldsSpecification": { "fieldsToInclude": [ { "fieldName": "string" } ], "fieldsToExclude": [ { "fieldName": "string" } ] } } } } ``` CSV ファイルは一度に 1 行ずつ解析され、チャンキング戦略とベクトル埋め込みがコンテンツフィールドに適用されます。Amazon Bedrock ナレッジベースは、現時点では 1 つのコンテンツフィールドに対応しています。コンテンツフィールドはチャンクに分割され、各チャンクに関連付けられているメタデータフィールド (列) は、文字列値として扱われます。 例えば、CSV に「Description (説明)」という列と「Creation\$1Date (作成日)」という列があるとしましょう。説明フィールドがコンテンツフィールドで、作成日が関連するメタデータフィールドです。説明のテキストはチャンクに分割され、CSV の行ごとのベクトル埋め込みに変換されます。作成日の値は日付の文字列表現として扱われ、説明の各チャンクに関連付けられます。 包含/除外フィールドが指定されていない場合、コンテンツ列を除くすべての列がメタデータ列として扱われます。包含フィールドのみが指定されている場合は、指定されたその列のみがメタデータとして扱われます。除外フィールドのみが指定されている場合は、除外列を除くすべての列がメタデータとして扱われます。`fieldsToInclude` と `fieldsToExclude` の両方で同じ `fieldName` を指定した場合、Amazon Bedrock は検証例外をスローします。包含と除外の間で競合が発生した場合は、エラーになります。 CSV 内で空白の行が見つかった場合は無視またはスキップされます。