RAG管線的稽核追蹤：歐盟AI法案第30條對檢索系統的要求

歐盟AI法案於2024年8月生效。對於執行檢索增強生成管線並為高風險應用提供資料的企業來說，合規時鐘正在滴答作響。第11、12、13和30條針對技術文件、自動日誌記錄、透明度和註冊提出了具體要求——這些要求不僅適用於生成回應的模型，還適用於決定模型看到什麼的每個上游系統。

如果您的RAG管線攝取文件、對其分塊、嵌入、儲存在向量資料庫中，並為語言模型檢索上下文，那麼每一個步驟現在都在監管範圍之內。問題不是您是否需要稽核追蹤。問題是您今天擁有的稽核追蹤能否經受住合規性評估。

什麼使系統成為「高風險」

歐盟AI法案在附件III中定義了高風險AI系統。該列表包括用於就業和工人管理、信用評分、保險承保、執法、移民和庇護處理、基本服務取得以及司法管理的系統。如果您的RAG管線為這些用例中的任何一個提供資料，第11至13條的全部要求均適用。

分類是基於目的而非技術。為聊天機器人檢索產品常見問題的RAG管線不是高風險的。同樣的管線架構為醫療決策支援工具檢索臨床指南則很可能是高風險的。這種區別很重要，因為高風險系統的文件和日誌記錄要求是詳細的、規範性的且可強制執行的。

企業往往低估了其內部AI工具中有多少符合條件。使用RAG提取職位描述和政策文件來排序候選人的人力資源篩選工具完全屬於附件III的範圍。檢索監管文字以幫助分析師起草提交給金融監管機構報告的合規工具也是如此。

這些條款究竟要求什麼

四個條款構成了RAG管線稽核追蹤義務的核心。

第11條 — 技術文件

第11條要求高風險AI系統的提供者在系統投放市場或投入使用之前編制技術文件。對於RAG管線，這意味著記錄用於攝取的資料來源、分塊和預處理邏輯、嵌入模型及其版本、向量儲存配置、檢索策略（相似度閾值、top-k、重新排序）以及在傳遞給生成模型之前組裝檢索上下文的提示詞範本。

這不是一次性工作。文件必須在系統的整個生命週期中保持更新。每次更換嵌入模型、更改分塊策略或新增資料來源時，技術文件都必須反映這些變化。

第12條 — 記錄保存和自動日誌記錄

第12條要求高風險AI系統的設計和開發具備在系統運作時自動記錄事件（日誌）的能力。對於RAG管線，這轉化為每個階段的日誌記錄：

• 攝取：攝取了哪些文件、何時、由誰、套用了什麼預處理
• 分塊：文件如何拆分、使用了什麼區塊大小和重疊設定、產生了多少區塊
• 嵌入：哪個嵌入模型和版本產生了向量、每批次的時間戳記
• 儲存：向量何時寫入儲存、任何去重或更新操作
• 檢索：對於每個查詢，檢索了哪些區塊、它們的相似度分數、套用了任何重新排序、以及傳遞給模型的最終上下文視窗
• 生成：傳送給LLM的提示詞、收到的回應、以及任何後處理或過濾

日誌必須足以重建系統對任何給定輸出的行為。如果監管機構詢問為什麼檢索了特定的上下文片段——或為什麼沒有檢索——您需要能夠用帶有時間戳記的證據來回答。

第13條 — 透明度和向部署者提供資訊

第13條要求高風險AI系統的設計確保其運作足夠透明，使部署者能夠解釋系統的輸出。對於RAG管線，這意味著最終使用者或部署者必須能夠理解哪些來源影響了特定回應。

這不僅僅是列出檢索到的文件。它要求可追溯性：能夠將回應追溯通過檢索步驟、通過向量儲存、通過嵌入、通過分塊，一直到原始來源文件和對答案有貢獻的特定段落。

第30條 — 在歐盟資料庫中註冊

第30條要求高風險AI系統的提供者和部署者在將系統投放市場之前在歐盟資料庫中註冊該系統。註冊包括系統預期目的的描述、所使用資料的類別以及有關系統效能和限制的資訊。如果您的RAG管線是已註冊高風險系統的元件，其架構和資料來源將成為註冊記錄的一部分。

實用的日誌記錄架構

滿足這些要求需要一種日誌記錄架構，將RAG管線視為一等可稽核系統，而不是附加在推理上的事後補充。

攝取層

進入管線的每個文件都需要一個來源記錄：來源URL或檔案路徑、攝取時間戳記、操作員ID、檔案雜湊值以及套用的任何轉換（OCR、格式轉換、中繼資料提取）。如果文件被更新，系統必須記錄差異——什麼發生了變化、何時以及為什麼觸發了更新。

處理層

分塊和嵌入是大多數RAG管線失去稽核保真度的地方。團隊記錄最終向量但不記錄產生它們的中間步驟。合規的管線記錄每個文件使用的分塊參數、任何清理或標準化前後的原始區塊以及嵌入模型版本及其配置。當重新訓練或更換嵌入模型時，日誌必須捕獲更改前後的狀態。

檢索層

每個檢索操作都產生一條稽核記錄：輸入查詢、搜尋參數、帶分數的候選區塊、任何重新排序或過濾以及向下游傳遞的最終上下文。這是第13條透明度要求最為關鍵的層。日誌必須支援回答這個問題：「對於這個特定輸出，系統考慮了什麼資訊，排除了什麼？」

資料品質層

原始日誌記錄是必要的但不充分的。合規性評估不僅會詢問什麼資料進入了管線，還會詢問資料是否適合其目的。這就是自動化品質檢查成為稽核追蹤一部分的地方——對區塊的相關性進行評分、偵測嵌入分佈中的異常以及標記超出預期參數的文件。

在Ertas中的實現

Ertas在設計時就將這種稽核架構作為基礎層，而不是合規附加元件。管線中的每個轉換——從原始檔案上傳到向量儲存條目——都帶有時間戳記和操作員ID記錄。完整的資料譜系得以保留：可以將任何向量追溯通過其嵌入、其區塊和其來源文件。

品質評分器評估傳入資料並產生成為稽核記錄一部分的品質指標。異常偵測器標記嵌入分佈、區塊長度和來源中繼資料中的統計異常值——提供有記錄的證據，證明管線持續監控資料品質，而不僅僅是在部署時。

當合規性評估要求證明系統的訓練和檢索資料符合品質標準時，這些記錄已經是結構化且可匯出的。Ertas生成的稽核報告直接對映到第11和12條的文件要求，涵蓋資料來源、處理參數、品質分數和檢索日誌。

評估中最可能暴露的常見差距

根據第11至13條的要求，以下是在RAG管線合規性評估中最可能浮出水面的差距：

**嵌入模型沒有版本控制。**如果無法證明在特定日期生效的向量是由哪個嵌入模型版本產生的，就無法重建該時期的系統行為。

**分塊參數未記錄。**許多團隊硬編碼分塊設定，從不記錄。當設定更改時，沒有記錄之前的配置是什麼或更改何時發生。

**檢索日誌缺少否定證據。**記錄檢索到的內容很簡單。記錄被考慮和排除的內容——以及原因——更困難，但第13條的透明度要求要求必須這樣做。

**沒有資料品質文件。**在沒有品質檢查的情況下攝取文件意味著沒有證據表明供給高風險系統的資料是適當的。合規性評估將此標記為系統性差距。

**沒有稽核記錄的手動流程。**如果人工策展人從管線中選擇或移除文件，該決定必須以與自動化操作相同的嚴格性進行記錄。

展望未來

歐盟AI法案對RAG管線稽核追蹤的要求並不含糊。如果您的檢索系統為高風險應用提供資料，您需要在每個管線階段進行自動日誌記錄、與系統變化保持同步的技術文件、讓部署者能夠將輸出追溯到來源的透明度機制，以及證明適合目的的資料品質證據。

將此視為設計約束的組織——從一開始就將稽核追蹤建構到管線架構中——會發現合規很簡單。試圖將日誌記錄改造到現有管線上的組織會發現它昂貴、脆弱且永遠不完整。

該法規並不要求您停止建構RAG系統。它要求您建構RAG系統時確保每一步都有記錄、每個轉換都可追溯、每個輸出都可以解釋。這不僅僅是良好的合規。這是良好的工程。