我們如何建立安全且私密的 Slack AI

編輯備註：本文原先發佈於 Slack 工程部落格。

Slack 一向是較為保守的技術專家；換句話說，將資源投入新類別基礎架構的運用時，我們總是非常嚴謹。自 Slack 於 2016 年首次推出採用機器學習技術的功能起，我們便一貫保持這樣的態度，也在這方面制定了穩定可靠的程序，並編制專業技術團隊。

儘管如此，商用大型語言模型 (LLM) 過去一年來大幅成長的能力仍出乎我們的意料；更讓人矚目的是，LLM 能夠解決使用者最大的痛點。內容太多讀不完？很難找到想要的資料？這些都不再是問題。比起未採用 AI 技術的使用者，90% 採用 AI 的使用者表示他們的生產力有所提升。

不過如同許多其他新技術，我們是否能推出採用 AI 技術的產品，取決於能否找到符合 Slack 嚴謹客戶資料管理標準的實作方式。我們著手建置的不僅是出色的 AI 功能，而是既出色又值得信任的 AI 功能。

生成式模型產業形成的時間還很短，因此大多仍以研究為中心，而非聚焦於企業客戶需求。我們建置新的 Slack AI 架構時，幾乎沒有既有企業級安全防護和隱私權模式可供運用。

為了讓客戶瞭解我們如何建置出 Slack AI，我們改為先建立首要原則。Slack 從自身要求開始著手：維持我們既有的安全防護與合規性產品以及隱私權原則，例如「客戶資料是不可侵犯的」。接著，我們的團隊再透過生成式 AI 的特殊觀點，建立一套新的 Slack AI 原則作為指導方針。

• 客戶資料絕對不會流出 Slack。
• 我們並非使用客戶資料訓練大型語言模式 (LLM)。
• Slack AI 的運作基礎只包含使用者原本就能看見的資料。
• Slack AI 符合 Slack 的所有企業級安全性和合規性要求。

這些原則使我們的架構設計過程更清晰，雖然有時也會帶來更大的挑戰。以下會詳細說明這些原則如何造就今日的 Slack AI。

客戶資料絕對不會流出 Slack

我們面臨的第一個 (或許也是最重要的) 決策，是如何確保在使用頂層基礎模型時，避免客戶資料從 Slack 控管的 VPC 流出。在生成式模型產業中，大多數基礎模型的客戶都是直接呼叫託管服務，除此之外幾乎沒有其他替代做法。

Slack 知道我們無法使用這套方法，因為我們與客戶對資料所有權都有很高的期望，而且 Slack 又擁有 FedRAMP 中等授權，須遵守特定合規性要求，包含不得將客戶資料傳送至我們信任的基礎架構之外。我們希望確保資料不會流出自己的 AWS 虛擬私有雲端 (VPC)，如此一來，我們才能保證第三方無法保留資料或使用這些資料訓練模型。

因此，我們開始尋找有創意的解決方案，以期將基礎模型託管在我們自己的基礎架構上。然而，大部分基礎模型皆為閉源，也就是說，各模型均為其公司的獨家秘技，他們自然不希望將模型交給客戶並部署在客戶的硬體上。

幸運的是，AWS 有一款產品可以在基礎模型供應商與客戶之間擔任可信任的代理程式：AWS SageMaker。只要使用 SageMaker，我們就能將閉源大型語言模型 (LLM) 託管並部署在代管 VPC 上，讓我們得以控制自家客戶資料的生命週期，同時確保模型供應商無法存取 Slack 客戶的資料。如需進一步瞭解 Slack 如何運用 SageMaker，請參閱 AWS 部落格上的這則貼文。

經過一番努力，我們終於能夠使用託管在自家 AWS VPC 的頂層基礎模型，藉此保護我們的客戶資料。

我們並非使用客戶資料訓練大型語言模式 (LLM)

下一項決策也相當關鍵：我們選擇使用現成模型，而非自行訓練或微調模型。Slack 剛開始使用較傳統的機器學習 (ML) 模型 (例如搜尋結果排名) 時，便已制定完善的隱私權原則，包含資料不得外洩給整個工作空間，以及提供使用者與隱私權做法相關的選擇權利。然而，由於目前這個產業和技術仍處於剛剛成形的階段，若使用 Slack 的客戶資料訓練生成式 AI 模型，我們無法對這些做法給予強力保證。

因此，我們選擇採用擷取擴增生成 (RAG)，藉此透過無狀態方式使用現成模型。RAG 能讓您在執行任務時，將一切所需背景資料納入個別要求，以免模型保留任何資料。舉例來說，對頻道產生摘要時，我們會傳送提示給 LLM，其中包含需要摘要的訊息，以及摘要做法的說明。RAG 的無狀態特質能發揮極高的隱私權效益，同時也能具有產品效益。Slack AI 的所有結果皆以貴公司的資料庫為基礎，而非公開網際網路，所以內容會更為精確且切身相關。您不僅能因加入自家專屬個別資料集而受益，還能免除模型保留該資料的風險。

採用 RAG 能縮小可使用的模型範圍。模型必須具備夠大的「背景資料窗口」才能傳入所有您想在任務中使用的資料。此外，您傳送給 LLM 的背景資料越多，要求的速度就會變得越慢，因為模型必須處理更多資料。各位應該能夠想像得到，摘要一個頻道中所有訊息的任務，涉及的資料量有多麼可觀。

這讓我們面臨了一項挑戰：必須找到擁有大型背景資料窗口，且延遲相當低的頂層模型。我們評估了幾個模型，最終找到了十分適合我們第一批使用個案 (摘要和搜尋) 的模型。不過，由於還有改善的空間，我們開始長期進行提示調整，以及將較傳統的機器學習模型與生成式模型鏈結起來，以改進結果。

每次重複執行模型後，RAG 就會變得更快且更容易上手：背景資料窗口不斷擴大，模型彙整透過大型背景資料窗口傳入資料的能力也在不斷成長。我們深信這種方法能夠讓我們達成目標品質，同時確保客戶資料受到應有保障。

Slack AI 的運作基礎只包含使用者原本就能看見的資料

我們的一大核心原則是 Slack AI 只能看見要求使用者所看見的資料。舉例來說，Slack AI 的搜尋功能絕對不會向使用者顯示標準搜尋範圍外的結果，摘要功能也絕不會將使用者閱讀頻道時看不見的內容納入摘要。

為了確保這一點，我們擷取需要摘要或搜尋的資料時，會採用要求使用者的存取控制清單 (ACL)，也會運用我們現有的資料庫，這些資料庫專門用於擷取顯示在頻道或搜尋結果頁面上的資料。

嚴格來說，這一點並不難做到，但需要做出明確選擇。為了保證這一點，最佳方法是以 Slack 的核心功能集為基礎，並重複使用這些功能，同時在最後加上畫龍點睛的 AI 技術。

另外值得注意的是，唯有叫用 Slack AI 的使用者才能看見 AI 產生的輸出，這能讓使用者相信 Slack 是能夠信任的 AI 合作夥伴：只會輸入您能看見的資料，也只有您能看到輸出。

Slack AI 符合 Slack 的所有企業級安全性和合規性要求

沒有 Slack 就沒有 Slack AI，因此我們確實整合了自家所有企業級合規性與安全防護產品，遵照僅使用最低限度資料的原則，並且只在必要期間儲存完成任務所需的資料。

有時根本就沒有最低限度資料。Slack AI 盡可能提供臨時輸出：對話摘要和搜尋答覆都會產生不儲存在磁碟上的時間點回應。

如果無法做到這一點，我們會儘量重複使用 Slack 現有的合規性基礎架構，並在必要之處建立新支援。Slack 許多合規性產品都隨附我們的現有基礎架構，例如加密金鑰管理與國際資料常駐。其他產品則會內建特殊支援，以確保摘要等衍生內容可掌握傳入的訊息。舉例來說，如果訊息因資料遺失保護 (DLP) 遭到埋藏，自該訊息衍生的所有摘要都會失效。這使搭配 Slack AI 使用的 DLP 與其他管理控制項都擁有強大功能：若 Slack 訊息內容已經啟用這些控制項，Slack AI 輸出也會啟用這些控制項。

呼，這段經歷真的很長吧！而且我還沒有提到如何建立提示、評估模型，或處理棘手的需求呢！這些話題就留待日後再敘。不過，我很高興能從安全防護和隱私權開始談起：Slack 希望客戶瞭解我們多麼重視對他們資料的保護，以及我們一路上採取了哪些步驟來保障資料安全。