* 大模型上了火山方舟 ：數據唯你可見，唯你所用，唯你所有 *
大模型的發展呈現出追風逐日般的速度，但與之相伴的安全問題，也是頻頻被曝光。
正如此前ChatGPT所曝出的案例中，黑客可以利用漏洞給AI植入虛假記憶，在後續回答中出現誤導信息。
而且還能植入惡意指令，持續獲取用戶聊天數據。
即便開啓新的對話也是無濟于事，簡直就是大寫的“陰魂不散”：
試想這種對話一旦涉及機密的內容，那帶來後果和損失可以說是不敢想象。
可怕，著實是有些可怕。
但反觀國內的大模型玩家，卻似乎鮮有黑客入侵、數據泄露等安全問題的存在。
爲何會如此？
帶著這個疑問，我們找到了大模型服務平台火山方舟的團隊，在與火山引擎智能算法負責人、火山方舟負責人吳迪做了深入交談之後，得到了這樣的答案 ：
這是因爲火山方舟從Day 1 開始就把安全植入基因，把它當作基本的産品功能來實現。
目前我們已經做到了模型和會話等數據全周期都是安全可信的，而且是會話無痕的那種。
一言蔽之，就是你的數據，唯你可見，唯你所用，唯你所有。
那麽火山方舟具體又是如何做到的，我們繼續往下看。
* 火山方舟 ：在我這，會話無痕
傳統的數據安全保護方案，已經不能被套用到AI大模型時代。
這就是目前大模型玩家們在安全方面所面臨的最根本且真實的難題。
因爲傳統的私有化部署方案，多數是屬于數據不動模型動，這種方法難以跟上雲上大模型的快速叠代，且基礎算力的單位成本遠高于公有雲集中調度。
因此，現在更適合的一種方案應當是模型不動數據動，企業需要將數據上傳到雲中，以此來利用最先進的大模型能力。
如何讓用戶充分信任雲上數據的安全性始終是一個難題。
加之在技術層面上，主流的隱私計算技術也無法滿足生産級別性能要求。
例如可用的TEE技術雖然成熟，但保護GPU等異構高算力硬件，是依然在探討和研究中，無法直接大規模用于生産環境；MPC等多方安全計算技術也很難在大模型的吞吐、延遲與大模型的效果之間取得平衡。
而火山方舟的全周期安全方案，卻能直擊上述的痛點，並且很好地提供安全保護的能力。
整體來看，這套方案共分爲四大維度，分別是：
鏈路全加密
數據高保密
環境強隔離
操作可審計
接下來，我們就把整套方案拆分開來，深入到每個維度來看下火山方舟是如何搞安全的。
鏈路全加密
在大模型應用中，數據流轉的每個環節都可能面臨風險，特別是當數據從用戶端發送到雲端進行處理的時候。
對此，火山方舟平台采用了“雙層加密”方案，即在數據傳輸過程中實施網絡層和應用層的雙重加密。
首先是在網絡層，火山方舟使用了HTTPS協議，這就像給數據通道加上了一層防護罩，讓數據在傳輸過程中被安全封裝。
同時，平台還使用了mTLS（Mutual Transport Layer Security，即雙向認證傳輸層安全協議），這可以理解爲“雙保險”，因爲不僅用戶會驗證方舟平台的身份，方舟平台也會反向驗證用戶的身份。
這種方式類似于寄送包裹時不僅需要寄件人和收件人的地址驗證，快遞員還會在每個傳送節點核查包裹是否安全抵達目標地址，確保沒有被篡改。
這一層安全措施有效防止中間人攻擊，即攻擊者試圖在傳輸鏈路中截取或篡改數據的行爲。
然而，僅僅依賴網絡層加密還不足以保證數據絕對安全，因爲如果數據在網絡傳輸中被誤導到錯誤的地址，那麽即便是密文也有可能被破解。
因此，火山方舟還增加了應用層的會話加密，進一步確保數據即便落到不正確的接收端，也無法被解密讀取。
網絡層的加密就像給一個文件加了一層保險盒，而應用層加密就如同再給保險盒上了一把鎖，雙重保險確保即便有人攔截了這個文件，也無從打開它。
在應用層加密中，每個推理實例都被賦予了一個唯一的身份認證證書，類似于每個人都有自己的身份證號。
用戶的數據會使用這個證書的公鑰進行加密，而只有當數據抵達擁有對應私鑰的火山方舟安全沙箱內，才會被解密。
這一設計如同用戶的數據在送達火山方舟之前被打上了獨特的印記，只有持有匹配“鑰匙”的平台安全環境才能將其解密和使用。
這樣一來，平台確保了用戶數據在傳輸中始終處于封閉的“安全通道”中，未經授權的任何人都無法解鎖並查看數據。
數據高保密
這一步驟核心在于如何確保數據在平台的傳輸、使用和存儲過程中始終處于極高的保密狀態。
數據高保密不僅涵蓋了對數據存儲、加密等方面的多重保護，更以沙箱環境爲基礎，確保數據即便在平台內部流轉時也不會暴露給任何未經授權的用戶。
這一保密策略類似于把數據鎖進一個“加密金庫”中，無論是外界的攻擊者還是平台的內部人員都無法直接接觸到未加密的原始數據。
對此，火山方舟采取的策略是 ：從數據上傳之初就以密文形式加密存儲，只有當數據進入沙箱內存時才會被解密。
對于模型訓練，用戶可以通過火山引擎提供的密鑰管理服務（KMS）功能，設置自定義密鑰對數據進行加密，並將數據存儲在用戶自己的TOS（對象存儲服務）內。
這一環節可視作給數據“穿上盔甲”後再送到平台，即便數據被截獲，攻擊者也只能看到加密後的“密文”，無法獲取數據的真實內容。
然後，在平台內部，數據被分配到安全沙箱中並以密文狀態存儲，只有在安全沙箱的內存中才能夠短暫解密以供訓練使用。
通過這一設計，火山方舟平台建立了一個“只有沙箱能讀懂數據”的密鑰體系，確保數據在離開沙箱後始終以密文狀態存在。
這就好比“密鑰控制”，即每一組數據都配有一把“加密鎖”和“解密鑰匙”。
這把鑰匙由用戶控制，只有用戶允許時才能使用。比如當企業客戶需要上傳訓練數據集時，可以事先利用TOS的加密功能對數據進行處理。
然後火山方舟平台將密文數據挂載到安全沙箱環境中，在內存中完成解密後，數據才會被投入訓練系統。
此外，火山方舟平台的數據高保密功能還擴展到了精調模型的存儲和管理環節。
對于每一個完成精調的模型，平台都會以加密的形式存儲在對象存儲或雲文件系統中，確保只有授權用戶能讀取和使用。
同時，爲了保證模型的高效加載和運行性能，火山方舟平台利用GPU加密庫，讓模型在加載和運行過程中能夠直接在 GPU 上完成解密和加密處理。
這種方式極大地提升了數據流轉效率，確保在不犧牲模型推理速度的情況下依然保持數據的高度安全。
在安全沙箱之內，還有一個“任務級隔離”的策略。
在平台上，每個模型任務被劃分爲獨立的“安全隔間”，即使在多租戶並發的情況下，用戶數據之間也不會互相幹擾。
這樣的隔離策略讓每一個任務都像被鎖在自己的“小隔間”中，即便其他租戶發生任何安全事件，也不會影響到當前任務的安全性。
環境強隔離
火山方舟的“環境強隔離”方案，不僅涉及到上述我們提到的任務級隔離，更包括了防止數據泄露、確保安全操作、監控內部流量等方面的多層次措施。
環境強隔離的首要任務是讓每個模型任務擁有一個獨立、隔離的“安全區域”，這一設計類似于給每個任務分配了一個“安全艙”。
在實際操作中，火山方舟爲每個任務使用了隔離容器，確保每個任務實例在一個安全且封閉的容器環境中獨立運行。
爲了達到高安全性，這些容器不僅隔離了彼此的網絡流量，還限制了容器內部的操作權限，防止任務間出現橫向數據傳輸，確保不同任務間的數據不會相互幹擾。
爲了進一步加強任務的隔離性，火山方舟在容器的基礎上設計了一層動態網絡隔離。
這項技術確保每個任務都擁有獨立的、專屬的網絡策略。
具體而言，當一個任務被創建時，系統會自動生成一套動態的網絡配置，適用于該任務的全生命周期；從任務創建到結束，無論任務間是否位于同一雲網絡環境下，它們之間的網絡連接始終被嚴格隔離。
除此之外，火山方舟還爲任務實例部署了容器沙箱技術。容器沙箱技術通過添加多層安全防護，使得容器在隔離性上得到了大幅提升。
此處用到的是一項字節跳動開發的開源技術“VERM Armor”，這項技術爲容器提供了一種實時阻斷威脅的機制，一旦容器檢測到潛在的安全漏洞，就會立即阻止危險行爲的繼續。
在環境強隔離的設計中，火山方舟還確保了關鍵數據的“只讀存取”功能。任務實例在使用模型和數據時僅具備讀取權限，不能對數據進行修改。
此外，火山方舟還部署了可信數據訪問代理系統，進一步加強了數據的隔離性和安全性。
系統不僅能確保數據請求的來源和權限檢查，還能防止容器中的數據未經授權發送到外部環境。
這一設計就像海關檢驗程序，每一個進出任務隔間的數據請求都要經過嚴格審查，任何未經授權的數據傳輸都會被攔截。
這種多層級的防護策略，使得用戶數據即便在任務隔間內部也處于嚴格的監控之下。
操作可審計
這一步驟的核心在于實現“可驗證的安全性”，讓所有涉及數據的操作都能被完整記錄，並在必要時追溯來源。
操作可審計主要通過“審計日志”功能來實現。
每當用戶的數據在平台內被訪問、傳輸、處理或刪除時，系統會自動生成詳細的操作記錄。
這些日志如同“監控錄像”，詳細記錄了操作的時間、操作人、操作內容和操作結果。
就好比“數據使用的完整痕迹”，用戶可以像檢查銀行賬單一樣審查自己的數據是否在未經授權的情況下被訪問或操作。
這種設計不僅提升了數據的安全性，還增強了用戶對平台的信任。
此外，火山方舟的審計日志設計遵循“透明可信”的理念。
用戶可通過方舟控制台隨時查看自己的數據操作日志，了解自己的數據在平台上的流轉情況。
火山方舟還提供了多重驗證機制，用戶可以將平台的操作日志與自己系統的操作記錄相對比，以確保數據處理的真實、准確性。
這種交叉驗證機制類似于“多重備份驗證”，讓用戶更放心地監控數據安全。
同時，火山方舟的審計日志不僅記錄了標准操作，還能夠標記異常操作並自動觸發警報。
如果出現越權訪問或操作不當的情況，系統中的監控指標會立即發生變化。
這一設計如同銀行的“風險預警系統”，任何可疑操作都會在第一時間被標記，用戶能清晰看到平台在安全保護上的責任與能力。
總而言之，在火山平台這裏，數據所到之處，處處都是安全措施。
* 不僅要“Don’t be evil”，更要“Can’t be evil”
在與吳迪的交流過程中，他還特別提及了內部每隔幾天便會上演“火山方舟與藍軍攻防”的安全機制。
這個機制不僅是火山方舟對內部系統進行嚴格檢驗的方式，更是確保平台始終處于最佳防禦狀態的一項重要實踐。
通過這種攻防演練，火山方舟團隊能夠模擬真實的攻擊環境，檢測安全系統的穩健性，及時發現和修補潛在漏洞。
這種演練源自軍隊訓練，藍軍模擬攻擊，火山方舟防守阻止。
藍軍由專業內部團隊組成，模擬密碼破解、權限提升、數據竊取等網絡攻擊，嘗試突破平台防護。火山方舟則負責監測、識別並阻止這些入侵，采取實時監控、迅速響應和修複漏洞等措施。
這種演練包括日常、小型和大型攻防演練。小型演練每月或每兩月一次，大型演練每季度或半年一次，通常聯合外部白帽團隊進行，以模擬更複雜的攻擊場景。
吳迪指出，這種機制幫助團隊不斷發現並修複安全隱患，提升應對真實攻擊的能力。
並且已成爲火山方舟安全體系的重要組成部分，不僅提高了團隊的安全意識和技術水平，也讓用戶感受到平台在安全保障上的持續努力。
在談到衆多環節中哪個才是最重要的，在吳迪認爲，內部人員的操作是安全風險的一個重要根源。
而這也正是我們剛才提到的，火山方舟引入了可信代理和堡壘機的雙重管理機制的原因所在，可以確保所有運維人員的操作都經過嚴格的權限申請並全程錄屏。
吳迪還提出，火山方舟的安全理念正在從“Don’t be evil”向“Can’t be evil”演進。
所謂“Don’t be evil”意味著平台通過可驗證的安全審計結合加密隔離等技術，確保除了用戶之外的任何一方，包括平台內部人員，如果違反數據安全策略，都能夠被第一時間發現並追責。
而“Can’t be evil”則意味著平台將通過進一步的技術手段，使得惡意行爲從根本上不可實施，這包括可信度量技術、以及泌態計算等技術的應用，能夠主動減少攻擊面，並且提升用戶數據隱私保護級別。。
並且火山方舟的安全能力，是從第一天就開始建設，像鋼筋水泥一樣澆築在産品裏，而不是先蓋好房子又裝修。從下面這張圖的時間線中便可一目了然 ：
展望未來，吳迪認爲生成式AI技術的發展速度極爲迅猛，這也給安全防護帶來了前所未有的挑戰。
特別是在多模態生成式AI應用場景中，例如視頻、音頻等多種輸入與輸出模式下，如何在技術複雜性不斷增加的情況下維持高標准的安全性，是未來的重大挑戰之一。
他表示，火山方舟將繼續探索加密硬件技術、跨行業聯合安全方案等新興技術，以確保在技術快速發展和用戶體驗之間實現最佳平衡。
而在我們問及吳迪，在搞安全的過程中，是否有令他印象深刻的故事時，他這樣回答道 ：我們沒有故事，要有故事就成事故了。
總而言之，縱觀火山方舟的整體安全互信方案，是已經做到了“科技道路千萬條，安全第一條”。--- [金磊 發自 : 凹非寺*量子位 : 公衆號 QbitAI/來源 : 量子位]
參考鏈接：
[1]https://www.youtube.com/watch?v=zb0q5AW5ns8&t=3s
[2]https://mp.weixin.qq.com/s/dLY3gH165TbdP4KqTXHXjw
* Claude都能操縱計算機了，吳恩達：智能體工作流越來越成熟 *
受 ChatGPT 強大問答能力的影響，大型語言模型（LLM）提供商往往優化模型來回答人們的問題，以提供良好的消費者體驗。
隨著智能體研究日趨成熟，優化似乎有了新的方向。
人工智能著名學者、斯坦福大學教授吳恩達今天指出：「現在有一種趨勢是優化模型以適應智能體工作流程，這將爲智能體性能帶來巨大提升」，並撰寫一篇博客簡單闡述了這種趨勢。
我們對博客內容進行了不改變原意的編譯、整理，以下是博客內容 ：
繼 ChatGPT 在回答問題方面取得突破性成功之後，許多 LLM 的開發都集中在提供良好的消費者體驗上。因此，LLM 被調整爲回答問題或遵循人類提供的指令。
指令調整指導模型的數據集很大一部分可以爲人類編寫的問題和指令提供更有用的答案，面向 ChatGPT、Claude、Gemini 等等。
但智能體工作負載不同，人工智能軟件不是直接爲消費者生成響應，而是應該在叠代工作流程中 ：
反思自己的輸出；
使用工具；
編寫規劃；
在多智能體環境中進行協作。
主要模型制造商也越來越多地優化用于 AI 智能體的模型。
以工具使用（或函數調用）爲例。
如果 LLM 被問及當前天氣，它將無法從訓練數據中獲取所需的信息。
相反，它可能會生成 API 調用請求以獲取該信息。
甚至在 GPT-4 原生支持函數調用之前，應用程序開發人員就已經使用 LLM 來生成函數調用，通過編寫更複雜的提示來告訴 LLM 哪些函數可用，然後讓 LLM 生成用于確定是否要調用函數的字符串。
在 GPT-4 之後，生成此類調用變得更加可靠，然後許多其他模型本身就支持函數調用。
如今，LLM 可以決定調用函數來搜索信息以進行檢索增強生成 (RAG)、執行代碼、發送電子郵件、在線下訂單等等。
最近，Anthropic 推出了升級版的 Claude 3.5 Sonnet，能像人一樣使用計算機。
這意味著 LLM 原生使用計算機方向向前邁出了一大步，將幫助許多開發人員。
一些團隊還致力于讓 LLM 使用計算機構建新一代 RPA（機器人流程自動化）應用程序。
隨著智能體工作流程的成熟，我看到的是 ：
首先，許多開發人員正在 prompt LLM 來執行他們想要的智能體行爲。這樣可以進行快速、豐富的探索！
在極少數情況下，開發非常有價值的應用程序的開發人員將微調 LLM，以更可靠地執行特定的智能體功能。例如，盡管許多 LLM 本身支持函數調用，但它們是通過將可用函數的描述作爲輸入，然後（希望）生成輸出 token 以請求正確的函數調用來實現這一點的。
對于生成正確函數調用非常重要的任務關鍵型應用程序，針對應用程序的特定函數調用微調模型可顯著提高可靠性。（但請避免過早優化！我仍然看到太多團隊在進行微調，而他們可能應該在采取這種做法之前花更多時間進行 prompt。）
最後，當諸如工具使用或計算機使用之類的能力對開發人員來說似乎很有價值時，主要的 LLM 提供商正在將這些能力直接構建到他們的模型中。
盡管 OpenAI o1-preview 的高級推理對消費者有幫助，但我預計它對于智能體推理和規劃會更有用。
大多數 LLM 都針對回答問題進行了優化，主要是爲了提供良好的消費者體驗，我們已經能夠將它們「移植」到複雜的智能體工作流程中，以構建有價值的應用程序。
爲支持智能體中的特定操作而構建 LLM 的趨勢將爲智能體性能帶來很大提升。我相信，在未來幾年內，在這個方向上將實現巨大的智能體能力提升。---[機器之心報導*編輯 ：小舟/來源 : 機器之心Pro ]
https://www.deeplearning.ai/the-batch/issue-275/
