本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Amazon Bedrock 知識庫的運作方式 Amazon Bedrock 知識庫可協助您充分利用檢索增強生成 (RAG) 這項熱門技術，其涉及從資料存放區提取資訊，以增強大型語言模型 (LLM) 產生的回應。當您使用資料來源設定知識庫時，您的應用程式可以查詢知識庫以傳回資訊，以使用來源的直接引述，或從查詢結果產生的自然回應來回答查詢。 透過 Amazon Bedrock 知識庫，您可以建置由查詢知識庫所收到的內容來充實應用程式。透過從繁重的建置管道中抽取出來，並提供現成可用的 RAG 解決方案，以減少應用程式的建置時間，進而加快上市時間。新增知識庫也可提高成本效益，因為不需要持續訓練模型來利用您的私有資料。 以下圖表以圖解方式說明 RAG 的進行方式。知識庫透過自動執行此過程中的幾個步驟，簡化 RAG 的設定和實作。 **預先處理非結構化資料** 若要從非結構化私有資料 (不存在於結構化資料存放區中的資料) 進行有效擷取，常見的做法是將資料轉換為文字，並將其分割為可管理的部分。然後，部分或區塊會轉換為嵌入項目，並寫入向量索引，同時保持與原始文件對應。這些內嵌項用於確定查詢和資料來源的文字之間的語意相似性。下圖說明了向量資料庫資料的預先處理。 ![\[預先處理資料以進行檢索增強生成\]](http://docs.aws.amazon.com/zh_tw/bedrock/latest/userguide/images/kb/rag-preprocess.png) 向量嵌入是代表每個文字區塊的一系列數字。模型會將每個文字區塊轉換為一系列數字，稱為向量，以數學方式比較文字。這些向量可以是浮點數 (float32) 或二進位數字。根據預設，Amazon Bedrock 支援的大多數嵌入模型都會使用浮點向量。不過，某些模型支援二進位向量。如果您選擇二進位嵌入模型，您也必須選擇支援二進位向量的模型和向量存放區。 每個維度只使用 1 位元的二進位向量，其在儲存上的成本低於浮點 (float32) 向量高，其每個維度使用 32 位元。不過，二進位向量在文字表示方面不如浮點向量精確。 下列範例以三種表示顯示一段文字： **** | 代表 | 值 | | --- | --- | | 文字 | 「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/zh_tw/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 知識庫支援各種文件，包括文字、影像或包含資料表、圖表和其他影像的多模態文件。*多模態*資料是指文字和視覺化資料的組合。包含非結構化資料的檔案類型範例為文字、Markdown、HTML 和 PDF。 下列各節說明 Amazon Bedrock 知識庫支援的資料類型，以及您可以針對每種資料類型將知識庫連線到的服務： ## 非結構化資料 非結構化資料是指未強制進入預先定義結構的資料。Amazon Bedrock 知識庫支援連線至下列服務，將非結構化資料新增至您的知識庫： + Amazon S3 + Confluence (預覽) + Microsoft SharePoint (預覽) + Salesforce (預覽) + Web Crawler (預覽) + 自訂資料來源 (允許直接將資料擷取至知識庫，而不需要同步) 資料來源包含文件的原始形式。為了最佳化查詢程序，知識庫會將您的原始資料轉換為*向量嵌入*，此為資料的數值表示，以量化與也轉換為向量嵌入之查詢的相似性。Amazon Bedrock 知識庫會在轉換資料來源的程序中使用下列資源： + 嵌入模型 – 將您的資料轉換為向量嵌入的基礎模型。對於同時包含文字和影像的多模態資料，您可以使用多模態內嵌模型，例如 Amazon Titan 多模態內嵌 G1 或 Cohere Embed v3。 + 向量存放區 – 存放資料向量表示的服務。支援下列向量存放區： + Amazon OpenSearch Serverless + Amazon Neptune + Amazon Aurora (RDS) + Pinecone + Redis Enterprise Cloud + MongoDB Atlas 將資料轉換為向量嵌入的程序稱為*擷取*。將您的資料轉換為知識庫的擷取程序涉及下列步驟： **擷取** 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 | 1000 | | 2 | 150 | 100 | 120 | 370 | | 3 | 300 | 300 | 300 | 900 | | 4 | 720 | 180 | 100 | 900 | | 5 | 500 | 400 | 100 | 1000 | | 6 | 900 | 800 | 1000 | 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) – 將 `Retrieve` 與 Amazon Bedrock 中的 [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 個字符的文字區塊。群集程序遵守句子界限，確保在每個區塊內保留完整的句子。 您也可以為文件選擇無群集。每個文件都會視為單一文字區塊。建議您先將文件分割為不同的檔案，再選擇無群集做為群集方法/策略，以預先處理文件。如果您為文件選擇無群集，則無法檢視引文中的頁碼，也無法依 *x-amz-bedrock-kb-document-page-number* 中繼資料欄位/屬性進行篩選。 ## 階層群集 階層群集涉及將資訊組織成子區塊和父區塊的巢狀結構。建立資料來源時，您可以定義父區塊大小、子區塊大小，以及每個區塊之間重疊的字符數量。在擷取期間，系統一開始會擷取子區塊，但會以更廣泛的父區塊取代它們，以便為模型提供更全面的內容。 小型文本嵌入更為精確，但擷取旨在提供全面的內容。階層群集系統會在適當時以其父區塊取代擷取的子區塊，以平衡這些需求。 **注意** 由於子區塊在擷取期間會被父區塊取代，因此傳回的結果數量可能小於請求的數量。 使用 S3 向量儲存貯體做為向量存放區時，不建議使用階層式區塊。使用大量字符進行區塊處理時 （合計超過 8000 個字符），您可能會遇到中繼資料大小限制。 對於階層群集，Amazon Bedrock 知識庫支援為群集指定兩個層級或以下深度： + 父系：您可以設定父系區塊字符大小上限。 + 子系：您可以設定子區塊字符大小上限。 您也可以設定區塊之間的重疊字符。這是設定連續父區塊和連續子區塊之間重疊字符的絕對數量。 ## 語意群集 語意群集是一種自然語言處理技術，可將文字分割為有意義的區塊，以增強理解和資訊擷取。它旨在透過專注於語意內容而非僅語法結構來提高擷取準確性。透過這樣做，它可以促進更精確的擷取和處理相關資訊。 設定語意群集時，您可以選擇指定下列超參數。 + 字符數量上限：單一區塊中應包含的字符數量上限，同時遵守句子界限。 + 緩衝區大小：對於指定的句子，緩衝區大小會定義要為內嵌建立新增的周圍句子數量。例如，緩衝區大小為 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 會使用每一頁定價，而基礎模型剖析器會根據輸入和輸出字符收費。如需詳細資訊，請參閱 [Amazon Bedrock 定價](https://aws.amazon.com/bedrock/pricing/)。 + 總檔案大小限制。當您使用基礎模型做為剖析器時，所有檔案的總檔案大小不得超過 100 GB。 若要了解如何設定知識庫的剖析方式，請參閱 [將資料來源連結至知識庫](data-source-connectors.md) 中資料來源的連線組態。 # 使用自訂轉換 Lambda 函數來定義如何擷取您的資料 您可以定義自訂轉換 Lambda 函數，將自己的邏輯注入知識庫擷取程序。 您可能有特定的群集邏輯，Amazon Bedrock 知識庫原生不支援。使用無群集策略選項，同時指定包含群集邏輯的 Lambda 函數。此外，您將需要為知識庫指定 Amazon S3 儲存貯體，以寫入 Lambda 函數要群集的檔案。 群集之後，Lambda 函數會將群集檔案寫入相同的儲存貯體，並傳回知識庫的參考以供進一步處理。您可以選擇提供自己的 AWS KMS 金鑰，以加密存放在 S3 儲存貯體中的檔案。 **注意** 如果使用 Web 連接器，則會將 Markdown 文字傳遞給 Lambda，而不是 HTML。 或者，您可能要指定區塊層級中繼資料，同時讓知識庫套用其中一個原生支援的群集策略。在此情況下，選取其中一個預先定義的群集策略 (例如預設或固定大小的群集)，同時提供 Lambda 函數和 S3 儲存貯體的參考。在此情況下，知識庫會在呼叫 Lambda 函數以進一步新增區塊層級中繼資料之前，將已剖析和預先群集的檔案存放在預先定義的 S3 儲存貯體中。 新增區塊層級中繼資料之後，Lambda 函數會將群集檔案寫入相同的儲存貯體，並傳回知識庫的參考以供進一步處理。請注意，區塊層級中繼資料會優先處理，並在發生任何衝突時，覆寫檔案層級中繼資料。 如需使用 Python Lambda 函數進行自訂群集的範例，請參閱[使用 Lambda 函數自訂群集](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 內每個資料欄的提示，而不是擁有數百或數千個內容/中繼資料檔案對。 每個區塊的文件中繼資料欄位/屬性具有限制。請參閱[知識庫的配額](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 檔案會一次剖析一列，並將分塊策略和向量嵌入套用至內容欄位。Amazon Bedrock 知識庫目前支援一個內容欄位。內容欄位會分割為區塊，而與每個區塊相關聯的中繼資料欄位 (資料欄) 會視為字串值。 例如，假設 CSV 具有資料欄 'Description' 和資料欄 'Creation\$1Date'。描述欄位是內容欄位，而建立日期是相關聯的中繼資料欄位。描述文字會分割為區塊，並轉換為 CSV 中每一列的向量嵌入。建立日期值會視為日期的字串表示，並與描述的每個區塊相關聯。 如果未提供包含/排除欄位，則所有資料欄都會視為中繼資料資料欄，但內容資料欄除外。如果只提供包含欄位，則只會將提供的資料欄視為中繼資料。如果只提供排除欄位，則排除資料欄以外的所有資料欄都會視為中繼資料。如果您在 `fieldsToInclude` 和 `fieldsToExclude` 中提供相同的 `fieldName`，Amazon Bedrock 會擲回驗證例外狀況。如果包含和排除之間發生衝突，將導致失敗。 在 CSV 中找到的空白資料列會被忽略或略過。