在這個部落格系列的第一部分中，我們探討了在生成式人工智慧應用中使用敏感資料的風險。這個概述提供了使用非確定性大型語言模型（LLM）處理敏感資料的挑戰基礎，以及如何使用Amazon Bedrock Agents來減輕這些挑戰。接下來的問題可能是在哪裡以及如何在LLM訓練、微調、向量資料庫、代理和工具中使用敏感資料。在這篇文章中，我們將在第一部分的基礎上，進一步討論資料治理。了解資料治理的基礎後，我們將探討如何使用正確的資料授權模型，跨不同資料來源使用敏感資料。最後，我們將討論如何在使用檢索增強生成（RAG）作為架構一部分的生成式AI應用中實施資料授權機制。
LLM的資料治理
在這一節中，我們將更詳細地探討資料治理作為整體資料安全環境的一部分。許多傳統工作負載依賴於結構化資料存儲，例如關聯式資料庫，作為其資料來源。相比之下，當您構建生成式AI應用時，主要的好處之一是能夠從大量結構化（基於架構）和非結構化資料中獲得洞察，包括日誌、文件、倉庫資料和其他資料來源。過去，對非結構化資料的訪問僅限於授權給特定主體的特定應用。在這種架構中，前端應用決定是否授權用戶訪問資料，然後使用單一的AWS身份和訪問管理（IAM）角色訪問後端資料來源，提供對物件存儲、資料倉庫或其他位置的資料訪問。應用的訪問包含授權決策，以允許或拒絕訪問資料或資料的子集。AWS已經實施了與主體身份相關的訪問模式，包括AWS受信任身份傳播和Amazon簡單存儲服務（Amazon S3）訪問授權。
當您希望使用多個資料來源作為應用的一部分時，管理生成式AI應用的資料訪問會帶來挑戰，因為缺乏對資料存在於何處的可見性，以及資料來源中是否包含敏感資料。隨著資料分佈在不同地點、部門和系統，許多客戶不知道他們在每個資料來源中擁有什麼資料。如果您不知道擁有什麼資料，就很難確定授權政策，以管理生成式AI應用對這些資料的訪問，或者資料來源是否應成為生成式AI應用的一部分。從資料治理的角度來看，您需要跨四個不同的支柱來審視這個過程：資料可見性、訪問控制、品質保證和所有權。資料來源是否包含客戶資料？是內部資料嗎？是兩者的結合嗎？您是否需要從資料來源中刪除某些物件或文件，以符合您正在構建的應用的業務目標？如果您在生成式AI應用中有不同的授權級別，誰應被授權訪問這些資料？AWS在這方面提供了服務，包括AWS Glue、Amazon DataZone和AWS Lake Formation，以管理生成式AI應用使用的資料。掌握資料治理是實施我們在本文中討論的資料授權能力的關鍵前提。
那麼，如何安全地將敏感資料整合到您的生成式AI應用中呢？讓我們來看看敏感資料可能存在的不同位置：LLM訓練和微調、向量資料庫、工具和代理。
LLM訓練和微調
生成式AI應用中敏感資料可能存在的第一個位置是LLM本身。大多數基礎模型（FMs）和LLMs是由第三方組織構建和開發的，包括Anthropic、Cohere、Meta和其他模型提供者。在這些模型中，LLMs變得越來越大，訓練於數兆的資料點上，包括常規資料和由其他LLMs創建的合成資料。然而，今天大多數模型提供者不會公開模型使用的資料來源，因為隱私和專有原因。由第三方組織開發的FMs不會在您的私人資料上進行訓練，但如果您是一個大型企業，您可能會使用敏感資料、授權資料和公共資料來訓練自己的LLMs，或者您可能會使用額外的資料來微調現有模型。這允許您選擇在訓練模型時包含哪些資料。
然而，如在第一部分中提到的，LLMs不做資料授權決策，這導致在授予不同主體群體訪問權限時出現挑戰。是您的應用決定是否授權給定的主體調用模型。此外，如果您需要從LLM中刪除資料，今天唯一的方法是重新訓練模型而不包含該資料。雖然微調和提示工程可以影響LLM返回的完成，但訓練資料或微調資料可以返回給任何有權訪問查詢模型的人。因此，如果您選擇微調現有模型，請仔細考慮在訓練期間使用哪些資料。包含在訓練中的專有資料可以被使用該模型進行推理的用戶訪問。您應仔細評估訓練資料，以刪除個人識別信息（PII）或需要額外授權的資料，超出訪問模型本身所需的授權。
值得注意的是，有LLM護欄支持負責任的AI機制。例如，Amazon Bedrock護欄實施從提示和完成中移除某些內容。然而，護欄是非確定性的，專注於過濾有害內容、被拒絕的主題、詞彙過濾或提示和完成中的PII資料。
重要提示：您不應依賴負責任的AI機制，如護欄或內建模型安全機制，來確保您的資料安全，因為它們不使用身份作為過濾的一部分信號。
檢索增強生成（RAG）
生成式AI應用中敏感資料存在的第二個位置是向量資料庫。RAG實現為生成式AI應用提供從您組織的私人資料來源獲取上下文信息的訪問，以提供LLMs的相關、準確和定制的響應。RAG允許您向發送給LLM的提示添加額外的上下文，而不需要使用您自己的資料訓練或微調模型。當您將RAG作為生成式AI應用的一部分使用時，您查詢向量資料庫以查找與主體提示相似的文件或信息塊。從向量資料庫返回的資料將與原始提示一起發送給模型，作為請求的額外上下文。對於AWS服務，我們使用Amazon Bedrock Knowledge Bases和Amazon Q Connectors來實現RAG。
圖1顯示了向量資料庫和模型的RAG運行時執行流程。當用戶查詢應用時，查詢會轉換為嵌入，向量資料庫使用這些嵌入來查找與查詢相似的文件。這些文件或信息塊被發送給LLM，以增強用戶的原始查詢，使LLM能夠生成響應。
圖1：RAG運行時執行流程
為了實現強大的資料授權與RAG，您需要在將額外內容作為提示發送給LLM之前授權資料。這可以在生成式AI應用或向量資料庫中實現。使用RAG時，您在應用中構建自己的授權工作流程，並在不同的粒度級別執行授權。如果您授權訪問向量資料庫本身，則允許有權訪問應用的用戶訪問向量資料庫中的文件。因此，例如，如果您有兩個部門（如財務和人力資源），您可以創建兩個向量資料庫，一個用於財務，一個用於人力資源。擁有財務授權的主體將被允許訪問財務向量存儲，但不能訪問人力資源的，反之亦然。
如果您希望將授權粒度轉移到向量資料庫本身呢？在不同的部署中，如果向量資料庫包含向量資料庫中不同主體群體的文件，向量資料庫的API調用必須包含有關請求主體的群體成員資格的信息。例如，如果人力資源員工有權訪問向量資料庫中的某些文件，生成式AI應用或向量資料庫必須授權主體是否有權訪問返回的資料。您可以使用檢索配置元數據字段作為API調用的一部分，在Amazon Bedrock Knowledge Bases中實現文件級過濾。如下一節中的示例所示，通過元數據過濾，您添加元數據鍵/值對，向量資料庫使用這些對來過濾返回的結果，類似於群體成員資格。由於元數據過濾是API請求的一部分而不是提示，威脅行為者無法使用提示注入來獲得他們無權訪問的資料——授權與傳遞給前端應用的主體身份和傳遞給RAG實現的元數據過濾相關聯。
為了構建安全的RAG實現，重要的是您使用正確的授權和資料治理實現。發送給LLM的資料應僅包括主體有權訪問的資料。LLM和護欄功能是概率性的，因此不應用於做出資料授權決策。
工具
生成式AI應用用於與敏感資料交互的第三種模式是功能或工具調用。使用工具時，LLM不會直接調用工具。相反，當您向LLM發送請求時，您還提供一個或多個工具的定義，這些工具幫助LLM生成響應。如果LLM確定需要工具來為消息生成響應，LLM會響應請求應用調用工具。它還包括傳遞給工具的輸入參數。然後，在生成式AI應用中，應用代表LLM調用工具，例如API、AWS Lambda函數或其他軟體。應用通過將工具的輸出作為提示的一部分提供給LLM，繼續與LLM對話，然後LLM基於新資料生成響應。這個運行時執行流程如圖2所示。
圖2：工具運行時執行流程
雖然LLM決定是否需要工具，但應用程式碼必須對LLM返回的參數進行安全檢查，並對可以調用的工具、工具應具有的權限以及可以採取的行動做出授權決策。傳統的安全機制仍然適用。例如，工具應被沙箱化，以便運行工具的副作用不會影響未來的調用。此外，LLM生成的用於工具的參數應在傳遞給工具之前進行清理，以幫助避免潛在的權限提升或遠程代碼執行問題（有關更多信息，請參閱OWASP LLM十大不當輸出處理）。
如前面提到的其他生成式AI模式一樣，應用也做出工具授權決策。類似於RAG實現，生成式AI應用決定適當的授權實現，包括應用級授權、群組級授權或用戶級授權，或者通過使用身份令牌將該決策傳遞給工具，這是第一部分中代理討論的一部分。通過這些功能，您可以在函數調用實現中使用多種類型的資料集（敏感資料、公共資料）。然而，與今天的API授權決策一樣，生成式AI應用中的授權決策應基於訪問生成式AI應用的主體的身份做出，並在每次調用工具時進行驗證。如前所述，您不應允許LLM決定主體應有的授權級別，因為這可能導致過度代理（有關更多信息，請參閱OWASP LLM應用十大過度代理）。
代理
在上一篇文章中，我們詳細討論的第四種模式是使用代理。在這裡，我們將討論如何使用代理來利用多種不同的資料來源。代理幫助主體根據主體輸入和提供給模型的資料完成多步操作。代理，包括Amazon Bedrock Agents，在LLMs、資料來源（RAG）、軟體應用（工具）和主體對話之間進行協調。使用代理，您選擇代理調用的LLM來解釋提示輸入及其編排過程中的後續提示，包括生成後續步驟。您使用動作配置代理，這些動作可能包括通過額外問題從最終用戶獲取澄清、為API操作調用函數或使用RAG從知識庫中增強查詢的額外相關上下文。這些動作在編排過程中使用，可能需要多個步驟，以回答最終用戶的原始查詢。這些組件被收集起來構建代理進行編排的基本提示，直到主體請求完成，如圖3所示。
圖3：代理運行時執行流程
對於代理和外部資料來源的使用，除了我們之前討論的資料授權決策之外，還有一些其他考量。首先，為了使用正確的資料授權上下文，身份信息需要作為生成式AI API調用的一部分傳遞給代理。使用Amazon Bedrock Agents，這是通過使用工具的會話屬性和向量資料庫的元數據過濾來完成的。您在代理配置中調用不同資料來源時使用這些屬性。
其次，使用代理的目標是為主體執行一項任務。與RAG不同，這些任務可能包括調用API以更改資料或代表最終用戶（主體）採取行動。這與之前討論的其他資料來源不同，資料訪問的實現是資料檢索。使用代理的目標是讓自主編排執行API操作，包括函數的添加、更新和刪除類別。在決定在代理的執行流程中給予主體的授權時，您應該格外小心。使用代理時可以考慮的一個選項是添加驗證步驟。這為主體（用戶）提供了驗證步驟，以驗證代理在更改資料或調用API以使用資料執行操作之前所做的工作。
現在我們已經討論了在生成式AI應用中使用資料的位置和方式，讓我們通過RAG實現的示例來看看。
RAG的資料過濾和授權
假設您是一家企業，希望使用生成式AI應用為內部群體檢索有關政策和歷史信息的信息。對於這個實現，單一的Amazon S3資料來源用於向量資料庫，其中包括財務部門和人力資源部門的文件，作為RAG實現的一部分。對於我們簡化的示例，用戶希望知道他們需要使用的SECRET_KEY。每個部門都有單獨的SECRET_KEY值，只有屬於相應群體的用戶才能訪問。S3桶是Amazon Bedrock知識庫的來源，生成式AI應用在實現中使用。這如圖4所示。
圖4：財務和人力資源用戶訪問生成式AI應用的架構概述
在未實施任何資料授權的情況下，當人力資源用戶查詢生成式AI應用時，使用檢索API調用時，Amazon Bedrock知識庫將返回以下結果。（檢索API調用允許您調用Amazon Bedrock知識庫並將結果發送回生成式AI應用，相比之下，RetrieveAndGenerate API調用將結果與提示一起發送給LLM，而生成式AI應用在LLM響應提示之前看不到知識庫調用的結果。）
aws bedrock-agent-runtime retrieve \
–knowledge-base-id FF6MZUZQMQ \
–retrieval-query text=”What is the SECRET_KEY?”
{
“retrievalResults”: [
{
“content”: {
“text”: “HR SECRET_KEY is HRBOT“
},
“location”: {
“s3Location”: {
“uri”: “s3://amzn-s3-demo-bucket/hr/hr.txt”
},
“type”: “S3”
},
“metadata”: {
“x-amz-bedrock-kb-source-uri”: “s3://amzn-s3-demo-bucket/hr/hr.txt”,
“x-amz-bedrock-kb-chunk-id”: “1%3A0%3A5pe-v5IBdy11OzJ9mB2-“,
“x-amz-bedrock-kb-data-source-id”: “OVJKWTMXQD”,
“group”: “HR”
},
“score”: 0.50864935
},
{
“content”: {
“text”: “Finance SECRET_KEY is FinanceBOT“
},
“location”: {
“s3Location”: {
“uri”: “s3://amzn-s3-demo-bucket/finance/finance.txt”
},
“type”: “S3”
},
“metadata”: {
“x-amz-bedrock-kb-source-uri”: “s3://amzn-s3-demo-bucket/finance/finance.txt”,
“x-amz-bedrock-kb-chunk-id”: “1%3A0%3AvVK-v5IBeX5eb0Bilm5H”,
“x-amz-bedrock-kb-data-source-id”: “OVJKWTMXQD”
},
“score”: 0.4856355
}
]
}
如圖所示，來自知識庫的財務部門（FinanceBOT）和人力資源部門（HRBOT）的SECRET_KEY從相應的S3前綴中返回。然而，為了遵循公司政策，財務部門和人力資源部門不希望部門外的用戶獲得他們無權查看的S3桶中的信息，包括員工的PII資料、未發布的財務資料、內部人力資源政策以及僅供各部門內用戶使用的其他信息。您將如何使用此處描述的正確資料授權來實施此限制？
該解決方案有兩個選擇。首先，您可以創建兩個單獨的向量存儲，一個用於財務，一個用於人力資源。當財務用戶訪問生成式AI應用時，應用將僅從財務向量存儲請求資料，因為用戶無權訪問人力資源向量存儲。當人力資源用戶訪問生成式AI應用時，情況正好相反，應用僅允許訪問人力資源向量存儲。
第二個選擇是使用通用向量存儲，您可能在其中擁有兩個部門的公共資料，此外還有特定群體使用的敏感資料。元數據過濾為生成式AI應用提供了一種在向量存儲本身過濾上下文的方法。當您將元數據作為*.metadata.json文件與S3物件關聯時，您可以在Amazon Bedrock API調用中應用過濾器，以過濾知識庫返回的資料。例如，您可以在S3中將元數據添加到兩個物件（hr.txt和finance.txt），通過在S3桶中添加hr.txt.metadata.json文件和finance.txt.metadata.json文件。當向量資料庫從S3桶中索引時，它將從S3桶中提取元數據，允許您過濾與相應文件相關的元數據。以下是hr.txt.metadata.json文件的示例，以及與檢索API一起使用的vectorSearchConfiguration過濾器。
// hr.txt.metadata.json
{
“metadataAttributes” : {
“group” : “HR”
}
}
// retrieveconfiguration.json
{
“vectorSearchConfiguration”: {
“filter”: {
“equals”: {
“key”: “group”,
“value”: “HR”
}
}
}
}
有了這些元數據文件，您將重新索引知識庫以將元數據與每個文件關聯。當您在API調用中使用過濾器調用知識庫時，您將獲得以下響應：
aws bedrock-agent-runtime retrieve \
–knowledge-base-id FF6MZUZQMQ \
–retrieval-configuration=”file://retrieveconfiguration.json” \
–retrieval-query text=”What is the SECRET_KEY?”
{
“retrievalResults”: [
{
“content”: {
“text”: “HR SECRET_KEY is HRBOT“
},
“location”: {
“s3Location”: {
“uri”: “s3://amzn-s3-demo-bucket/hr/hr.txt”
},
“type”: “S3”
},
“metadata”: {
“x-amz-bedrock-kb-source-uri”: “s3://amzn-s3-demo-bucket/hr/hr.txt”,
“x-amz-bedrock-kb-chunk-id”: “1%3A0%3A5pe-v5IBdy11OzJ9mB2-“,
“x-amz-bedrock-kb-data-source-id”: “OVJKWTMXQD”,
“group”: “HR”
},
“score”: 0.49277097
}
]
}
如您所見，您只收到來自HR文件夾的塊，因為只有hr.txt物件應用了”群組”：”HR”元數據。由於這一點，生成式AI應用可以將這些塊與您的提示一起傳遞給LLM，以便用戶接收SECRET_KEY。您可以在博客文章Amazon Bedrock Knowledge Bases現在支持元數據過濾以提高檢索準確性中找到有關元數據過濾的更多信息。
無論您如何將元數據分配給資料來源中的物件，API調用使用的過濾器是在生成式AI應用做出資料授權決策之後應用的。當用戶登錄生成式AI應用時，應用會驗證用戶的身份，以識別用戶是誰以及用戶所在的部門，這是通過使用OpenID Connect（OIDC）或OAuth2完成的，具體取決於應用。如果您希望生成式AI應用具有強大的授權政策，這一步是必需的。在生成式AI應用驗證用戶後，它將授權用戶並在調用Amazon Bedrock知識庫的API時應用所需的過濾器。值得重複的是，是應用做出資料授權決策，而對知識庫的API調用是授權後的。通過在API中通過安全側信道傳遞元數據而不是提示，這種做法有助於防止威脅行為者和非預期用戶獲得他們無權訪問的資料。
結論
實施正確的資料授權機制是使用敏感資料作為生成式AI應用的一部分時所需的基礎步驟。根據資料在生成式AI應用中的位置，您需要使用不同的資料授權實現，並且沒有一種適合所有情況的解決方案。在本文中，我們探討了如何使用正確的資料授權模型跨這些不同的資料來源使用敏感資料。然後，我們討論了如何通過使用元數據過濾作為生成式AI應用和RAG的一部分來實施資料授權機制。要獲得有關生成式AI安全性的更多信息，請查看AWS安全博客頻道和涵蓋生成式AI的AWS博客文章中的其他博客文章。
如果您對本文有反饋，請在下方的評論部分提交評論。如果您對本文有疑問，請聯繫AWS支持。
Riggs Goodman III
Riggs是AWS的首席合作夥伴解決方案架構師。他目前專注於AI安全和資料安全，為客戶和合作夥伴提供技術指導、架構模式和領導力，以在AWS上構建AI工作負載。在內部，Riggs專注於推動AWS服務團隊的整體技術戰略和創新，以解決客戶和合作夥伴的挑戰。
本文由 AI 台灣 運用 AI 技術編撰，內容僅供參考，請自行核實相關資訊。
歡迎加入我們的 AI TAIWAN 台灣人工智慧中心 FB 社團，
隨時掌握最新 AI 動態與實用資訊！
