確保RAG攝取管道：過濾機制

檢索增強生成（RAG）應用程式通過整合外部數據（如下載的文件、網頁抓取和用戶貢獻的數據池）來增強從大型語言模型（LLMs）檢索的響應。這種整合通過為提示添加相關上下文來改善模型的性能。

儘管RAG應用程式是一種強大的方式，可以動態地為LLM的提示添加額外的上下文並使模型的響應更具相關性，但從外部來源納入數據可能會帶來安全風險。

例如，假設你爬取了一個公共網站並將數據納入你的知識庫。由於這是公共數據，你也可能會冒著吸納惡意內容的風險，這些內容可能是由威脅行為者注入到該網站中，目的是利用RAG應用程式的知識庫組件。通過這種機制，威脅行為者可以故意改變模型的行為。

這類風險強調了在RAG系統的設計和部署中需要安全措施。安全措施不僅應在推理時應用（即過濾模型輸出），還應在將外部數據納入RAG應用程式的知識庫時應用。

在這篇文章中，我們探討了一些將外部數據或文檔納入RAG應用程式知識庫的潛在安全風險。我們提出了一些實用的步驟和架構模式，幫助你減輕這些風險。

RAG數據納入工作流程的安全概述

在深入探討減輕納入管道風險的具體措施之前，讓我們先看看一個通用的RAG工作流程，並考慮在保護RAG應用程式時應注意的各個方面。在這篇文章中，我們假設你正在使用Amazon Bedrock知識庫來構建RAG應用程式。Amazon Bedrock知識庫提供內建的強大安全控制，幫助減輕許多安全風險，包括數據保護、訪問控制、網絡安全、日誌記錄和監控、以及輸入/輸出驗證。

在使用Amazon Bedrock知識庫的RAG工作流程中，你擁有以下環境：

一個由Amazon Bedrock服務團隊管理的Amazon Bedrock服務帳戶。
一個AWS帳戶，您可以在其中存儲RAG數據（如果您使用AWS服務作為向量存儲）。
根據您選擇的向量數據庫，可能還有一個外部環境。如果您選擇Pinecone或Redis Enterprise Cloud作為向量數據庫，則會使用AWS之外的環境。

圖1：知識庫數據納入流的可視化表示

查看圖1中顯示的將數據納入知識庫的工作流程，一個納入請求是通過調用StartIngestionJob Bedrock API來啟動的。從那時起：

如果這個請求有正確的IAM權限，它會被發送到Bedrock API端點。
然後這個請求被傳遞到知識庫服務組件。
與請求相關的元數據將存儲在元數據Amazon DynamoDB數據庫中。這個數據庫僅用於列舉和描述數據源及其同步狀態。API調用包括要納入的數據的Amazon Simple Storage Service（Amazon S3）源位置的元數據，以及將用於存儲嵌入的向量存儲。
該過程將開始從Amazon S3中納入客戶提供的數據。如果這些數據是使用客戶管理的KMS密鑰進行加密的，則將使用這些密鑰來解密數據。
當從Amazon S3中讀取數據時，數據塊將被內部發送，以調用Amazon Bedrock中選擇的嵌入模型。數據塊是指從數據源返回的摘錄，當查詢其存儲的向量存儲時返回。使用知識庫，您可以使用固定大小的塊（標準分塊）、分層分塊、語義分塊、用於解析非文本信息的高級解析選項或自定義轉換進行分塊。關於知識庫的分塊的更多信息，請參閱《知識庫的內容分塊和解析如何工作》。
Amazon Bedrock中的嵌入模型將創建嵌入，然後將其發送到您選擇的向量存儲。Amazon Bedrock知識庫支持流行的向量存儲數據庫，包括Amazon OpenSearch Serverless的向量引擎、Pinecone、Redis Enterprise Cloud、Amazon Aurora和MongoDB。如果您沒有現有的向量數據庫，Amazon Bedrock會為您創建一個OpenSearch Serverless向量存儲。此選項僅通過控制台提供，而不通過SDK或CLI提供。
如果需要憑證或密鑰來訪問向量存儲，則可以將其存儲在AWS Secrets Manager中，這樣它們將自動檢索並使用。然後，嵌入將被插入到（或更新到）配置的向量存儲中。
當前正在進行的納入作業的檢查點將暫時存儲在一個瞬態S3桶中，並使用客戶管理的AWS密鑰管理服務（AWS KMS）密鑰進行加密。這些檢查點允許您從先前的成功檢查點恢復中斷的納入作業。Aurora數據庫和Amazon OpenSearch Serverless數據庫均可配置為公共或私有，當然我們推薦私有數據庫。納入數據桶的變更（例如，上傳新文件或新版本的文件）將在數據源同步後反映出來；這種同步是增量進行的。在納入作業完成後，數據將自動清除並在最多8天後刪除。
納入DynamoDB表存儲同步向量存儲所需的信息。它存儲與分塊相關的元數據，以跟蹤底層向量數據庫中的數據。該表用於使服務能夠識別在一次納入作業與另一個納入作業之間需要插入、更新或刪除的分塊。

關於不同環境的靜態加密：

客戶AWS帳戶 – 這些帳戶中的資源可以使用客戶管理的KMS密鑰進行加密。
外部環境 – Redis Enterprise Cloud和Pinecone具有自己的加密功能。
Amazon Bedrock服務帳戶 – S3桶（第8步）可以使用客戶管理的KMS密鑰進行加密，但在Amazon Bedrock的上下文中，第3步和第9步的DynamoDB表僅可以用AWS擁有的密鑰進行加密。然而，Amazon Bedrock管理的表中不包含個人可識別信息（PII）或客戶可識別數據。

在整個RAG納入工作流程中，數據在傳輸過程中進行加密。Amazon Bedrock知識庫使用TLS加密與第三方向量存儲進行通信，前提是提供商允許並支持傳輸中的TLS加密。客戶數據不會在Amazon Bedrock服務帳戶中持久存儲。

對於身份和訪問管理，創建Amazon Bedrock知識庫的自定義服務角色時，遵循最低特權原則非常重要。作為角色權限的一部分，您需要創建一個信任關係，使Amazon Bedrock能夠承擔此角色並創建和管理知識庫。關於所需權限的更多信息，請參閱《為生成AI RAG技術提供安全訪問、使用和實施》。

RAG數據納入管道的安全風險及納入時過濾的必要性

RAG應用程式固有地依賴於基礎模型，這引入了超出傳統應用程序安全防護的附加安全考慮。基礎模型可以分析複雜的語言模式，並根據輸入上下文提供響應，並可能受到惡意事件的影響，例如越獄、數據中毒和反轉。這些特定於LLM的風險在OWASP針對LLM應用程式的前10名和MITRE ATLAS等文件中進行了映射。

對於RAG納入管道特別相關的一個風險，是我們目前看到的最常見風險之一，即提示注入。在提示注入攻擊中，威脅行為者通過將惡意輸入偽裝為合法用戶提示來操縱生成AI應用程式。提示注入有兩種形式：直接和間接。

直接提示注入發生在威脅行為者覆蓋底層系統提示時。這可能使他們能夠通過與不安全的功能和通過LLM訪問的數據存儲進行交互來探測後端系統。在保護生成AI應用程式免受提示注入攻擊方面，這種類型通常是客戶最關注的。為了減輕風險，您可以使用Amazon Bedrock Guardrails等工具來設置LLM完成的推理時過濾。

間接提示注入發生在LLM接受來自外部來源的輸入時，這些來源可能受到威脅行為者的控制，例如網站或文件。當你考慮RAG應用程式的納入管道時，這種注入類型特別重要，因為威脅行為者可能在納入到數據庫的外部內容中嵌入提示注入。這可以使威脅行為者操縱LLM可以訪問的其他系統或向用戶返回不同的答案。此外，間接提示注入可能無法被人類識別。安全問題不僅可能來自LLM基於其訓練數據的響應，還可能來自RAG應用程式可以從其知識庫訪問的數據源。為了減輕這些風險，你應該關注LLM、知識庫和納入RAG應用程式的外部內容之間的交集。

為了讓你更好地理解間接提示納入，讓我們首先討論一個例子。

外部數據源納入風險：間接提示注入的例子

假設一名威脅行為者編寫了一份文檔或向一個網站注入內容。這些內容旨在操縱LLM生成不正確的響應。對人類來說，這樣的文檔可能與合法的文件無法區分。然而，該文檔可能包含一個隱藏的序列，當作為RAG的參考來源使用時，可能會操縱LLM生成不希望的響應。

例如，假設你有一個文件，描述下載公司軟件的過程。該文件被納入到一個LLM驅動的聊天機器人的知識庫中。用戶可以詢問聊天機器人在哪裡找到下載軟件包的正確鏈接，然後通過單擊鏈接來下載該包。

一名威脅行為者可能在文檔中包含第二個鏈接，使用白色文本在白色背景上顯示。這段文本對讀者和下載文檔以存儲在知識庫中的公司是不可見的。然而，當被文檔解析器解析並保存在知識庫中時，它是可見的。這可能導致LLM返回隱藏的鏈接，使用戶下載威脅行為者在其管理的網站上托管的惡意軟件，而不是從預期網站下載合法軟件。

如果你的應用程式連接到插件或代理，以便調用API或執行代碼，則模型可能會被操縱以運行代碼、打開威脅行為者選擇的URL等等。

如果你查看下面的圖2，你可以看到典型的RAG工作流程，以及間接提示注入攻擊如何發生（此示例使用Amazon Bedrock知識庫）。

圖2：RAG工作流程的可視化表示，包括一個通用文件和一個與通用文件看起來完全相同的惡意文件

如圖2所示，對於數據納入（從右下方開始），文件1（合法且未修改的文件）保存在數據源中（通常是S3桶）。在納入過程中，文檔由文檔解析器解析，分割成塊，轉換為嵌入，然後保存在向量存儲中。當用戶（左上方）詢問有關該文件的問題時，來自該文件的信息將作為上下文添加到用戶提示中。然而，你可能擁有一個惡意文件2，它對人類讀者來說完全相同，但包含一個隱藏的字符序列。當此序列插入到發送給LLM的提示中時，它可以影響環境的整體響應。

威脅行為者可能會分析RAG工作流程中的以下三個方面，以創建和放置惡意序列：

文檔解析器是一種設計用來閱讀和解釋文檔內容的軟件。它分析文本並根據預定義的規則或模式提取相關信息。通過分析文檔解析器，威脅行為者可以確定他們如何將隱形內容注入不同的文檔格式中。
文本拆分器（或分塊器）根據內容的主題拆分文本。威脅行為者將分析文本拆分器，以找到隱藏序列的適當注入位置。基於區段的拆分器根據標籤不同區段的標籤來劃分內容，威脅行為者可以在這些標記的塊內放置其隱形序列。基於長度的拆分器將內容拆分成固定長度的塊並重疊（以幫助保持塊之間的上下文）。
提示模板是一種預定義的結構，用於生成特定的輸出或指導與LLM的互動。提示模板決定從向量數據庫檢索的內容如何與用戶的原始提示組織在一起，以形成增強提示。該模板至關重要，因為它影響RAG應用程序的整體性能。如果威脅行為者了解您應用程式中使用的提示模板，他們可以在構建其威脅序列時考慮到這一點。

潛在的緩解方案

威脅行為者可能會將包含精心構建和放置的隱形序列的文檔釋放到互聯網上，從而對納入這些外部內容的RAG應用程式構成威脅。因此，盡可能僅從受信來源納入數據。但是，如果您的應用程式需要使用和納入來自不受信來源的數據，則建議仔細處理這些數據以減輕間接提示注入等風險。為了加強您的RAG納入管道，您可以使用以下緩解技術對RAG納入管道施加額外的安全措施。這些可以單獨或一起實施。

配置您的應用程式以顯示其響應背後的源內容，允許用戶將內容與響應進行交叉引用。這可以使用Amazon Bedrock知識庫通過引用來實現。然而，這種方法並不是一種預防技術。此外，對於複雜內容，它的有效性可能較低，因為這可能要求用戶投入大量時間進行驗證才能有效。
在LLM、外部來源和可擴展功能（例如插件、代理或下游功能）之間建立信任邊界。將LLM視為不受信的行為者，並保持最終用戶對決策過程的控制。這又回到了最低特權原則。確保您的LLM僅訪問其需要訪問的數據源，並在將其連接到外部插件或API時特別小心。
持續評估在保持RAG系統的準確性和可靠性中扮演著至關重要的角色。在評估RAG應用程式時，您可以使用包含提示和目標答案的標記數據集。然而，像RAGAS這樣的框架提出了自動化指標，使得無參考的評估成為可能，減輕了對人類標註的真實答案的需求。實施RAG評估機制可以幫助您發現模型響應和從知識庫檢索的數據中的不規則性。如果您想深入探索如何評估您的RAG應用程式，請參閱《使用Amazon評估檢索增強生成應用程序的可靠性》，該文檔提供了進一步的見解和指導。
您可以手動監控您打算納入向量數據庫的內容，特別是當數據包括外部內容（如網站和文件）時。人類介入可能會對較不複雜的可見威脅序列提供保護。

有關減輕生成AI應用程序風險的更多建議，請參閱OWASP針對LLM的前10名和MITRE ATLAS中列出的緩解措施。

架構模式1：使用格式破壞器和Amazon Textract作為文檔過濾器

圖3：使用格式破壞器和Amazon Textract從文件中刪除威脅序列的潛在工作流程的可視化表示

一個從納入文件中移除潛在威脅序列的潛在工作流程是使用格式破壞器和Amazon Textract。這個工作流程特別關注隱形威脅向量。前面的圖3顯示了一個使用AWS服務的潛在設置，允許您自動化這一過程。

假設您使用S3桶來納入您的文件。您想上傳到知識庫的任何文件最初都會上傳到該桶中。在Amazon S3中的上傳操作會自動啟動一個工作流程，負責處理格式破壞。
格式破壞是一個用於清理和保護文檔的過程，它通過轉換文檔以去除可能的有害元素，如宏、腳本、嵌入對象和其他可能攜帶安全風險的非文本內容。在納入時的過濾中，格式破壞涉及將文本內容轉換為PDF格式，然後轉換為OCR格式。首先，將文本轉換為PDF格式。一個選項是使用AWS Lambda函數將文本轉換為PDF格式。作為示例，您可以通過將LibreOffice中的文件渲染器和PDF生成器放入Lambda函數來創建這樣的函數。此步驟對於使用Amazon Textract處理文件是必要的，因為該服務目前僅支持PNG、JPEG、TIFF和PDF格式。
將數據轉換為PDF格式後，您可以將其保存在S3桶中。將其上傳到S3又可以觸發格式破壞的下一步：將PDF內容轉換為OCR格式。
您可以使用Amazon Textract處理PDF格式的多頁文檔，並檢測標準英文字母和ASCII符號的印刷文和手寫文本。該服務將提取印刷文本、表單和表格，支持英語、德語、法語、西班牙語、意大利語和葡萄牙語。這意味著不可見的威脅向量不會被Amazon Textract檢測或識別，並自動從輸入中刪除。Amazon Textract操作將在API響應中返回一個Block對象給Lambda函數。
為了將信息納入知識庫，您需要將Amazon Textract輸出轉換為知識庫支持的格式。在這種情況下，您將在Lambda函數中使用代碼將Amazon Textract輸出轉換為純文本（.txt）文件。
然後，純文本文件被保存到S3桶中。該S3桶可以用作知識庫的來源。
通過讓創建Amazon S3文件的Lambda函數運行start_ingestion_job() API調用，或在目標桶上使用Amazon S3事件觸發器來配置新Lambda函數，以便當文件上傳到該S3桶時運行，可以自動反映S3桶中的更改到知識庫。同步是增量進行的，因此來自先前同步的更改將被納入。關於管理數據源的更多信息，請參閱《連接到您的知識庫數據庫》。

除了隱形序列外，威脅行為者還可以添加難以分類或過濾的複雜威脅序列。對於大規模手動檢查每個文檔以檢測不尋常內容並不切實際，而且創建準確檢測此類文檔中誤導信息的過濾器或模型也很具挑戰性。

LLMs的一個強大特性是它們可以分析複雜的語言模式。一條可選的路徑是向您的知識庫納入管道添加一個過濾LLM，以檢測惡意或誤導內容、可疑代碼或可能誤導您的模型的無關上下文。

再次強調，威脅行為者可能故意選擇難以分類或過濾且類似正常內容的內容。更強大的通用LLMs為威脅行為者提供了更大的表面，因為它們未經調整以檢測這些特定的嘗試。問題是：我們能否訓練模型以對各種威脅具有魯棒性？目前，尚無明確答案，這仍然是一個高度研究的主題。然而，一些模型針對特定用例。例如，LLamaGuard是Meta的Llama模型的微調版本，它預測14個類別的安全標籤，如選舉、隱私和誹謗。它可以分類LLM輸入（提示分類）和LLM響應（響應分類）中的內容。

對於與過濾納入數據相關的文檔分類，即使是像BERT這樣的小型模型也可以使用。BERT是一種僅編碼的語言模型，具備雙向注意機制，使其在需要深度上下文理解的任務中（如文本分類、命名實體識別和問答）表現出色。它是開源的，可以針對各種應用進行微調。這包括在網絡安全領域的用例，例如電子郵件中的釣魚檢測或檢測提示注入攻擊。如果您在內部擁有資源並且處理需要針對特定威脅進行高級過濾的關鍵應用，考慮微調像BERT這樣的模型，以分類可能包含不良材料的文檔。

除了自然語言文本外，威脅行為者可能還會使用數據編碼技術在文檔中混淆或隱藏不良有效負載。這些技術包括編碼的腳本、惡意軟件或其他有害內容，通過base64編碼、十六進制編碼、摩斯密碼、uucode、ASCII藝術等方法偽裝。

檢測此類序列的一種有效方法是使用Amazon Comprehend DetectDominantLanguage API。如果文檔完全用支持的語言編寫，DetectDominantLanguage將返回高置信度分數，表明缺乏編碼數據。相反，如果文檔包含編碼字符串，例如base64，API將難以對這段文本進行分類，導致低置信度分數。為了自動化檢測過程，如果置信度分數低於某個閾值（例如85%），您可以將文檔路由到人工審查階段。這樣可以減少對潛在惡意編碼數據進行手動檢查的需求。

此外，LLMs的編碼和解碼能力可以幫助解碼編碼數據。各種LLMs理解編碼方案，並可以解釋文檔或文件中的編碼數據。例如，Anthropic的Claude 3 Haiku可以解碼一個base64編碼的字符串，例如TGVhcm5pbmcgaG93IHRvIGNhbGwgU2FnZU1ha2VyIGVuZHBvaW50cyBmcm9tIExhbWJkYSBpcyB2ZXJ5IHVzZWZ1bC4，將其轉換為原始的明文形式：“學習如何從Lambda調用Amazon SageMaker端點非常有用。”雖然這個例子是良性的，但它展示了LLMs檢測和解碼編碼數據的能力，然後可以在納入到向量存儲之前將其刪除。

圖4：在檢測到您的納入文件中存在威脅序列的情況下，觸發人類介入審查的潛在工作流程的可視化表示

在前面的圖4中，您可以看到一個工作流程，顯示如何將上述功能集成到您的文檔處理工作流程中，以檢測納入文檔中的惡意內容：

作為納入點，您可以使用S3桶。要上傳到知識庫的文件首先上傳到這個桶中。在這個圖中，假設文件是.txt文件。
在Amazon S3中的上傳操作會自動啟動AWS Step Functions工作流程。
亞馬遜EventBridge用於觸發Step Functions工作流程。
工作流程中的第一個Lambda函數調用Amazon Comprehend DetectDominantLanguage API，當語言的置信度分數低於某個閾值時，標記文檔，表明文本可能包含編碼數據或其他格式的數據（例如Amazon Comprehend無法識別的語言），這些數據可能是惡意的。
如果是這種情況，該文檔將被發送到Amazon Bedrock中的基礎模型，該模型可以翻譯或解碼數據。
接下來，觸發另一個Lambda函數。這個函數調用SageMaker端點，您可以在該端點上部署模型，例如微調版本的BERT，以將文檔標記為可疑或正常。
如果未檢測到可疑內容，則不進行任何操作，桶中的內容保持不變（無需覆蓋內容，以防止不必要的成本），工作流程結束。如果檢測到不良內容，則該文檔將存儲在第二個S3桶中以供人工審查。
如果沒有，則工作流程結束。

RAG數據納入管道安全的其他考量

在前面的部分中，我們專注於過濾模式和當前建議，以保護RAG納入管道。然而，解決間接提示注入的內容過濾器並不是構建安全RAG應用程序時唯一需要考慮的緩解措施。為了有效保護生成AI驅動的應用程式，負責任的AI考量和傳統的安全建議仍然至關重要。

為了在您的納入管道中調節內容，您可能希望從納入文檔中刪除有毒語言和PII數據。Amazon Comprehend提供內建的有毒內容檢測和PII檢測功能。毒性檢測API可以識別仇恨言論、侮辱和色情內容等類別的內容。此功能對於確保有害或不當內容不會被納入系統特別有用。您可以使用毒性檢測API一次分析最多10個文本段，每個段的大小限制為1 KB。您可能需要在處理之前將較大的文檔拆分成較小的段。有關使用Amazon Comprehend毒性檢測的詳細指導，請參閱Amazon Comprehend毒性檢測。有關使用Amazon Comprehend進行PII檢測和撤回的更多信息，建議參閱使用Amazon Comprehend檢測和撤回PII。

在考慮RAG應用程式時，請記住最低特權原則。考慮您的應用程式擁有的權限，並僅授予其成功運行所需的權限。您的應用程式在上下文中發送數據或代表LLM協調工具，因此這些權限必須有限。如果您想深入了解如何在規模上實現最低特權，建議參閱《在規模上實現最低特權的策略》。這在您的RAG應用程式涉及可能調用API或數據庫的代理時尤為重要。確保您仔細授權，以防止潛在的安全問題，例如對數據庫的SQL注入攻擊。

為您的RAG應用程式開發威脅模型。建議您記錄應用程式中的潛在安全風險，並為每個風險制定緩解策略。2023年Re:Invent的這一會議概述了如何對生成AI工作負載進行威脅建模。此外，您可以使用Threat Composer工具，該工具附帶一個示例生成AI應用程式，以幫助您對應用程式進行威脅建模。

最後，在決定要納入到RAG應用程式中的數據時，請確保對內容的來源提出正確的問題，例如“誰有權訪問和編輯這些內容？”例如，任何人都可以編輯維基百科頁面。此外，評估您應用程式的範圍。RAG應用程式能夠運行代碼嗎？它可以查詢數據庫嗎？如果是這樣，這將帶來額外的風險，因此應謹慎過濾向量數據庫中的外部數據。

結論

在這篇博客文章中，您了解了RAG應用程式的一些安全風險，特別關注RAG納入管道。威脅行為者可能會設計複雜的方法，在網站或文件中嵌入隱形內容。如果沒有過濾或評估機制，這些可能導致LLM生成不正確的信息，或者更糟糕的情況，根據應用程式的能力（例如執行代碼、查詢數據庫等）。這使得在審查內容時很難發現這些威脅。

您學到了某些策略和架構模式，包括過濾機制，以減輕這些風險。重要的是要注意，過濾機制可能無法捕捉到應該從文件中刪除的所有不良內容（例如，PII、base64編碼數據和其他不良序列）。因此，評估機制和人類介入至關重要，因為目前尚無訓練有素的模型能夠檢測這些序列，特別是針對間接提示注入的技術（儘管有些模型專門訓練用於檢測不當語言，但這並不涵蓋所有可能的情況）。

儘管目前沒有完全減輕注入攻擊等威脅的方法，但這些策略和架構模式是第一步，並形成保護應用程序的分層方法的一部分。除了這些，確保定期評估您的數據，考慮讓人類介入，並隨時了解這一領域的進展，例如OWASP針對LLM應用的前10名或MITRE ATLAS。

如果您對這篇文章有反饋，請在下面的評論區提交意見。