多模態系統結合文字、影像、聲音等多種資料型別，其安全防護機制設計更需考量資料互動的複雜性。動態防護欄設計允許系統根據情境調整規則，例如優先順序排序或可協商規則，並提供解釋性以增強使用者信任。多模態防護欄能有效過濾有害內容，並確保 UI 元素符合規範，例如 GDPR。基礎模型的更新可透過 RAG 或微調等方式整合新資料，同時需注意避免專有資訊洩露。FhGenie 作為 Fraunhofer 內部 AI 聊天機器人，成功實作了資料保護和低門檻 AI 存取的目標，其無狀態設計和根據 Azure OpenAI 服務的架構，有效防止敏感資訊外洩，並確保 GDPR 合規性。
4.4.2 擴增生成（Retrieval Augmented Generation）
另一個自訂化 FM 的設計選項是擴增生成（RAG），它結合了 FM 和資訊檢索元件，具有存取自訂檔案的能力，例如組織的內部檔案。根據給定的提示，RAG 從知識函式庫中檢索相關的外部資訊，使用向量嵌入（如 Pinecone 和 Milvus）來儲存個人或組織內部的資料。這些嵌入可以用於執行相似性搜尋並啟用與特定提示相關的內部資料的檢索。然後，檢索到的資料用於在輸入 FM 之前增強提示。
RAG 是一種增強 FM 存取和利用大量不儲存在模型本身中的資訊的能力的技術。這可以導致準確性和相關性的顯著改善，以及隨時瞭解最新資訊的能力。RAG 可以應用於廣泛的應用中，例如問答、檔案檢索、內容生成、個人化推薦等。
RAG 的一個方面是可以考慮使用者的個別存取許可權。例如，如果使用者 A 有許可權讀取檔案 X、Y 和 Z，而這些檔案與給定的提示高度相關，那麼這些檔案可以被檢索並用於 A 的提示增強。如果使用者 B 發出相同的提示，但只具有檔案 Y 的存取許可權，那麼 B 的查詢只會使用檔案 Y 進行增強。反映這種個別存取許可權是可能的，但這不是透過微調來實作的，微調通常是使用多個使用者都具有存取許可權的檔案進行的，例如公司內部 AI 聊天機器人的企業內網。
然而，RAG 面臨著多個挑戰。其中一個主要挑戰是確保檢索資訊的品質和相關性。系統必須準確地確定哪些外部資料對提示最相關，以避免引入雜音或誤導資訊。此外，管理和維護一個全面且最新的知識函式庫需要大量資源和基礎設施。此外，還有隱私和資料安全問題，特別是在處理敏感或專有資訊時。
4.4.3 微調（Fine-Tuning）
可以透過一個類別似於訓練機器學習模型的過程將領域特定的資訊新增到 FM 中。使用與所選領域相關的標記資料的訓練資料集進一步訓練 FM，調整 FM 現有的引數。具體過程將取決於 FM 和 FM 提供者的工具。結果具有 FM 的規模，並且可以具有對特定領域的 ML 模型的特異性。使用標記的領域特定資料對 FM 引數進行微調，可以透過完全微調或引數高效微調來完成。
完全微調涉及重新訓練所有引數，但由於 FM 中的引數數量巨大，這通常是不切實際且昂貴的。這個過程需要大量計算資源和長時間的訓練時間。一個替代方案是使用引數高效微調（PEFT）技術，只修改原始引數的一小部分。介面卡模組是附加到預訓練 FM 特定層的小型神經網路模組。在微調期間，只有這些介面卡模組的引數被訓練，而原始 FM 引數保持凍結狀態。這允許模型學習領域特定資訊而不顯著地改變其核心知識。
例如，低秩適應（LoRA）在預訓練 FM 上引入了一個低秩適應層，學習了一個輕量級轉換，以適應預訓練 FM 到新的任務。它透過減少訓練引數數量和降低三倍的計算來實作。
4.4.4 蒸餾（Distilling）
如果需要使用不同的模型架構，通常是一個較小的架構，但透過訓練更改模型權重不可行，蒸餾是一個選項。蒸餾 FM 涉及訓練一個較小、更輕量級的“學生”模型，以模仿較大、更複雜的“教師”FM 的行為，使用知識轉移技術，如知識蒸餾、注意力蒸餾或引數分享。
知識蒸餾涉及訓練學生模型在兩個損失函式上：資料損失和蒸餾損失。資料損失鼓勵學生模型從原始訓練資料中學習，就像教師模型一樣。蒸餾損失鼓勵學生模型模仿教師模型的行為。
4.4.5 安全防護機制
安全防護機制是為了保護 AI 系統，特別是基礎模型（Foundation Model, FM）的行為而設計的。它們可以監控和控制基礎模型和其他元件（如提示、RAG、外部工具）的輸入和輸出，以滿足特定的需求，例如功能性和準確性需求、責任 AI（Responsible AI, RAI）需求等。
安全防護機制型別
- 輸入安全防護機制：應用於使用者輸入的資料，可能的效果包括拒絕或修改使用者提示。
- 輸出安全防護機制：關注基礎模型生成的輸出，可能修改基礎模型的輸出或防止某些輸出傳回給使用者。
- RAG 安全防護機制：用於確保檢索到的資料適當，可能透過基礎模型或其他機制實作。
- 執行安全防護機制：在呼叫外部工具或模型以增強基礎模型能力時，應用於確保被呼叫的工具或模型沒有已知的漏洞，並且只在預期的目標環境中執行，不會產生負面影響。
- 中間安全防護機制：在工作流程執行期間，用於保證每個中間步驟滿足必要的標準。
安全防護機制的關鍵屬性
- 普遍性：安全防護機制應能夠在不同的 AI 模型和系統中普遍適用，並在多變的運作場景下保持有效。
- 可定製性：允許安全防護機制根據特定的佈署需求進行適配。例如，自動駕駛的安全防護機制可能會在某些地區發出警告。
- 可解釋性：安全防護機制應該能夠提供清晰的解釋，讓開發者和使用者瞭解其決策過程和影響。
透過實施這些安全防護機制，AI 系統可以更好地確保其行為的安全性和責任感，從而提高整體的可靠性和信任度。
多模態系統的動態防護欄設計
在多模態系統中，防護欄的設計應該是動態的，可以在執行時學習和適應不同的情境。這意味著防護欄規則可以根據優先順序或情境進行組態，一些規則可以是可協商的。此外，解釋性確保系統使用者可以理解防護欄如何被應用，以建立信任。
為了提供全面性的監控和控制多模態系統（例如，使用文字、影片和音訊的組合），多模態防護欄可以被設計來：
- 防止不適當的多模態輸入被送到基礎模型，無論這些輸入是從使用者還是其他軟體元件或外部工具或模型中來的；
- 防止基礎模型生成不適當的多模態輸出，無論這些輸出是送到使用者還是其他軟體元件或外部工具或模型。
例如，多模態防護欄不僅可以檢測有害語言，也可以檢測有害影像。想象一個未來，UI 是動態生成的；那麼，多模態防護欄可以有效地標記任何未能滿足特定要求的 UI 元素，例如 GDPR 合規性。
更新基礎模型
有許多原因需要基礎模型在正常的完整更新週期之外進行更新。例如，您的基礎模型可以由玄貓更新，您的基礎模型包含您想要保持更新的產品描述，法規變化，您想要保持基礎模型更新等。更新可以透過玄貓、RAG 或微調實作。更新也可以由玄貓明確觸發或自動完成。
新資料也可以以使用者輸入的形式出現。例如，您可能掃描一份檔案並要求對其風格和語法進行反饋。這份檔案可以以某種形式儲存，以便在未來更新中納入。
如果基礎模型將新的輸入整合到其公開可用的模型中，那麼有可能將專有資訊公開給基礎模型的任何使用者。不同的提供商有不同的政策關於使用者資訊的公開可用性。這些政策也可能變化。這關於保持專有資訊私密的擔憂導致了像 FhGenie 這樣的系統的開發。
FhGenie：根據基礎模型的生產系統
為了給出一個根據基礎模型的系統及其架構和開發相關問題的具體例子，我們討論 FhGenie，Fraunhofer 的一個內部 AI 聊天機器人。它已經在生產中使用，並實作了主要設計目標：不洩露內部資料和低門檻存取最先進的 AI。
Fraunhofer-Gesellschaft 是一家領先的應用研究組織，總公司位於德國，約有 30,000 名員工。在當前的生成 AI 浪潮初期，Fraunhofer 意識到需要一個替代公共 AI 聊天機器人的方案，以避免將內部資訊洩露給 AI 實驗室，並使其可供大多數員工使用。前者是顯而易見的：內部、機密和私人資訊不應該出現在不符合合規性要求的資料集中。後者是為了使 Fraunhofer 所有員工（尤其是科學家）能夠體驗到 AI 的最新進展，並瞭解如何在自己的工作中使用它（以提高生產力等），以及如何在自己的研究中結合自己的專業知識與 AI，並在與行業合作的專案中使用 AI（以造福客戶）。
2022 年底和 2023 年初，沒有選擇來實作這些目標。然而，當 Microsoft Azure 開始提供其「OpenAI 服務」時，情況發生了變化，透過這些服務，可以存取 GPT-3.5 和稍後的 GPT-4 和 GPT-4o：提示和上下文可以透過 API 傳送到 LLM，LLM 以「完成」作為回應，以與 ChatGPT 或 Google Gemini 類別似的方式進行。這項服務於 2023 年 5 月在歐洲推出，提供與其他 Microsoft 雲端服務相同的契約保證，關於保密性和 GDPR 合規性。
Fraunhofer 認識到這項服務的潛力，並迅速開發了 FhGenie，一個根據 Azure OpenAI 服務的 AI 聊天機器人。FhGenie 於 2023 年 6 月上線，經過開發、測試和與工會達成共識。幾天內，使用者數量已經增長到數千人。許多公司已經跟進並提供了類別似的工具。
FhGenie 是一個具有典型使用者介面的 Web 應用程式。它連線到 Fraunhofer 的身份和存取管理系統，以便只有授權使用者才能存取。使用者狀態只保留在瀏覽器端的 Web 應用程式中，使長時間對話無需儲存可能敏感的資訊。所有根據雲的元件基本上是無狀態的：只有授權/身份驗證資料和高階別計量資料在通常情況下保留在這些元件中。不尋常的情況是 RAI 過濾器規則違規：如果使用者詢問違反道德或法律界限的問題，請求會被記錄在加密的濫用日誌中。預設版本的規則、過濾器和濫用日誌都是 Azure 服務的一部分。請注意，無狀態設計意味著不會儲存任何可能敏感的資訊。
內容解密
上述內容闡述了多模態系統中動態防護欄的設計原理和實踐，並以 FhGenie 為例，展示了根據基礎模型的生產系統如何實作低門檻存取最先進的 AI 同時保護內部資料不洩露。這些原理和實踐對於構建安全、合規且高效的人工智慧系統具有重要意義。
圖表翻譯
flowchart TD
A[開始] --> B[設計動態防護欄]
B --> C[實作多模態防護]
C --> D[保護內部資料]
D --> E[實作低門檻存取]
E --> F[結束]
此圖表展示了構建安全且高效的人工智慧系統的步驟，從設計動態防護欄開始，實作多模態防護，保護內部資料，最終實作低門檻存取最先進的 AI 技術。
隨著大語言模型(LLM)的普及，企業匯入 AI 應用已成為不可逆的趨勢。本文深入探討了客製化基礎模型的不同策略，包含擴增生成(RAG)、微調、蒸餾等技術，並分析了各自的優缺點及適用場景。 多維比較分析顯示，RAG 適合需要整合外部知識函式庫的應用，微調則更適用於特定領域的模型最佳化，而蒸餾則在模型輕量化和佈署效率上具有優勢。技術限制深析指出，資料安全、隱私保護和模型可解釋性仍是這些技術方案的共同挑戰。
實務落地分析發現，如同 Fraunhofer-Gesellschaft 開發的 FhGenie 案例所示，妥善結合雲端服務和安全防護機制，能有效兼顧 AI 應用普及化與內部資訊安全。匯入 AI 應用時，除了技術選型，更需考量資料治理、許可權控管、以及持續更新等導向，才能發揮 AI 的真正價值。 技術演進預測顯示，未來模型訓練成本將持續下降，客製化基礎模型的門檻也將降低，更多彈性且安全的客製化方案將應運而生。
玄貓認為，企業應積極探索適合自身需求的客製化策略，並建立完善的安全防護機制，才能在 AI 浪潮中取得競爭優勢。 對於資源有限的中小企業，善用雲端服務提供的預訓練模型和客製化工具，將是快速匯入 AI 應用的有效途徑。
