編者按：今年以來，大語言模型（LLM）在消費者(2C)市場嶄露頭角，同時也吸引了大量企業的關注。但是直接將這些面向消費者的模型引入企業環境，可能會面臨一些風險。今天我們為大家帶來的這篇文章，作者認為企業環境與消費者環境在資料方面存在著重要的差異，如果不認識到這些差異，面向企業環境的 LLM 專案就可能面臨拖延甚至失敗的風險。

具體來說，作者指出企業資料相比消費者資料，更多是封閉領域的資料、存量資料，涵蓋更多模態，並且受到更嚴格的訪問控制。這些特點可能導致企業環境中的 LLM 應用在檢索準確性、內容生成等方面表現不佳。作者建議企業需要做出與消費者環境不同的設計選擇，例如進行資料切片、訪問控制整合、提示詞引導等，以應對企業資料的獨特性。

這篇文章為我們深刻剖析了面向企業環境的 LLM 應用面臨的資料挑戰，並提供了寶貴的應對思路。作者豐富的一手專案經驗讓這些見解尤為可信與具體。我們也期待後續能看到作者關於如何具體應對這些資料差異的更多建議。相信這篇文章會為開發 To B LLM 的開發者提供良好參考，幫助他們根據企業資料特徵專門定製系統設計方案。

以下是譯文，enjoy！

作者 | Colin Harman

編譯 | 嶽揚

???歡迎小夥伴們加入 AI技術軟體及技術交流群 ，追蹤前沿熱點，共探技術難題~

歡迎來到 Enterprise LLM Pilot Projects（企業級 LLM 試點專案）的時代！（譯者注：這些 Pilot Projects 透過在企業環境中開發和應用 LLM 解決方案來展示其價值，與很多企業為消費者開發 LLM 解決方案的方式和麵臨的挑戰有所不同，因此需要制定合理的策略並注意相關事項。）在 ChatGPT 推出近一年後，很多企業都在謹慎但積極地推進其初期的大語言模型（LLM）專案，旨在展示大模型的價值，併為大規模使用 LLM、擴充套件應用場景提供指導。

老牌企業內部開發或為老牌企業開發這些大模型解決方案，與初創企業為消費者開發大模型解決方案有著本質區別。 然而，絕大多數有關 LLM 專案的建議，都有意無意地從初創企業面向消費者的角度出發。企業環境有其獨特的挑戰和風險，如果不考慮這些差異而盲目地遵循初創企業面向消費者的產品建議，可能會導致專案延遲甚至中止。再展開本文之前，首先要了解"enterprise"是什麼意思。

一個簡單的 provider-user（服務提供商/使用者）矩陣，突出顯示部分（即⭐標註部分）涉及企業，有企業環境獨特的挑戰和風險。

請注意，提供給企業使用者的產品最終可能會提供給終端消費者使用者，例如，提供給金融服務公司供其客戶使用的聊天機器人。

目前，LLM 的內容主要偏向於上述 provider-user（服務提供商/使用者）矩陣中的consumer-user和startup-provider部分，但這種趨勢正在減弱。導致出現這種情況主要是由於受風險投資支援的初創企業和獨立開發者追求快速上市和產品點選量。

那麼，現有的企業級 LLM 專案所接受的指導從何而來？可能會讓你大吃一驚，但確實很少有企業真正完成過 LLM 專案。在這一方面上，很少有像傳統諮詢公司這樣的實體以實際經驗為基礎進行指導，而是提供重新包裝的網路內容。迄今為止，這些企業尚未有足夠的時間積累豐富的實踐經驗，更不用說分享經驗了。雖然也有很多例外，但企業內部未來的 LLM 專家大多仍在忙於自己的第一個專案，而能夠為其他企業提供指導的初創企業數量仍然有限。

作為一家面向企業的軟體供應商，自 2021 年以來，我一直有幸為其他企業開發和實施 LLM 專案（位於上圖 provider/user 矩陣中的 Startup/Enterprise 單元），並克服了一系列獨特的挑戰，成功地完成了多個企業 LLM 專案的整個實施過程。

在本文中，我將分享一些我觀察到的企業級 LLM 專案所涉及的資料與 startup/consumer 專案有所不同的一些最重要的方面，以及瞭解這些差異對於我們的專案來說意味著什麼。瞭解這些差異可以幫助讀者更好地理解和評估自己的專案，消除來自 startup/consumer 視角的資訊偏見，並更好地適應和應用於企業級的LLM專案。

目錄

01 資料型別不同

02 開放領域? VS 封閉領域?

2.1實際案例

2.2 對專案的影響

03 資料規模

04 群體資料? vs 個體資料?

4.1 實際案例

4.2 對專案的影響

05 歷史資料? vs 實時資料?

5.1 實際案例

5.2 對專案的影響

06 多種模態? vs 較少模態?

6.1 實際案例

6.2 對專案的影響

07 資料的一致性和規律性 Data Regularity (? vs ?)

7.1 實際案例

7.2 對專案的影響

08 訪問控制（? vs ?）

8.1 實際案例

8.2 對專案的影響

09 總結

01 資料型別不同

具體而言，本文將重點關注用於 data-backed applications （譯者注：這些應用程式使用資料作為基礎，透過對資料的處理、分析和應用來實現其功能和目標）的資料，這些應用程式涵蓋了大多數面向企業的 LLM 使用場景。不要再侷限於透過總結輸入或透過模型記憶來回答問題的 LLM 使用技巧。 LLM 對資料進行操作所能產生的價值遠遠大於與單獨與 LLM 進行互動所產生的價值。 為了證明這一點，請想象一個完全由 LLM 相關操作組成的應用程式，該程式能夠接收使用者輸入並將其轉化為輸出。現在再想象一下，同樣的系統也可以訪問儲存在模型之外的資料：這種能力是可疊加的，價值也是可疊加的。這些資料可以包括任何型別的資訊：電子郵件、客戶記錄、社交圖譜、程式碼、文件、通話記錄等等...

資料幾乎總是透過資訊檢索發揮作用——應用程式將查詢相關資訊，然後使用 LLM 對其進行解釋。這種模式通常被稱為 RAG（檢索增強生成）。那麼企業級應用和 startup/consumer 應用之間的資料有何不同，這種不同對於我們專案來說意味著什麼呢？

對面向消費者和麵向企業環境的LLM應用背後的資料進行定性分析。

這是一幅卡通圖，因此相對大小是近似值，而且也有許多例外情況。

02 開放領域? VS 封閉領域?

開放領域資料是指涵蓋各種主題，不受特定領域或行業限制的資料。這類資料通常在面向消費者的應用程式或面向公眾的企業產品中處理。相反，封閉領域資料通常出現在企業級應用程式中。封閉領域資料更加專業，針對特定領域，通常包含開放領域資料中沒有的術語、縮略語、概念和關係。

2.1 實際案例：

• 面向企業產品所需資料

• 製藥研發文件 ?

• 電子商務產品清單 ?/?

• 客戶支援記錄 ?/?

• 公司政策 ?

• 季度收益報告 ?

• 面向消費者產品所需資料

• 社交媒體帖子 ?

• 個人財務記錄 ?

• 播客內容記錄 ?/?

• 食譜 ?

• 旅行日記 ?

2.2 對專案的影響

對於 LLM 專案而言，完全忽視封閉領域資料（closed-domain data）可能會使該專案完全失去作用。大多數商業化的大語言模型（LLM）都是基於開放領域資料（open-domain data）進行訓練的，如果沒有封閉領域資料的幫助，這些語言模型將無法正確解釋在它們在訓練中沒有遇到過的術語和主題。向量搜尋中使用的嵌入模型也是如此。例如，許多組織、機構都有大量的首字母縮寫詞彙，這些縮寫詞還是某些概念的主要用語，如果沒有封閉領域資料的幫助，LLM或檢索系統可能無法將這些縮寫詞與它們所代表的概念聯絡起來。

然而，如果其實並不需要封閉領域資料，或存在更簡單的解決方案，就不要被誤導而去進行昂貴的模型再訓練！ 許多看似封閉的領域實際上是開放的。 例如，這些商業化的 LLM 都已經在大量的公共財務資料上進行了訓練，並且它們能夠直觀地理解這些資料，因為儘管金融是一個特殊的領域，但它並不是一個封閉的領域。

? Particular Domain ≠ Closed Domain
? 特定領域 ≠ 封閉領域

即使像醫學和法律這樣的領域也有大量的公共資料，但其子領域往往表現出封閉領域的特性（金融領域也是如此）。 在進行垂直領域大模型的訓練之前，請三思而後行，需要仔細評估是否真正需要這些專案或模型。期待更多關於如何評估領域資料開放性的文章。

對於大多數封閉領域資料，透過查詢封閉領域術語的同義詞或其定義，並將其納入檢索和生成系統（retrieval and generation systems），可以讓專案取得相當大的進展。然而，這需要我們擁有關於同義詞、術語關係或定義的結構化資訊，而這些資訊可能並不容易獲得。如果能夠獲取到這些結構化資訊，這種模式通常是最好、最簡單的解決方案，我們將在後續的文章中探討相關技術。

? Prefer bespoke systems to bespoke models
? 定製系統優於定製模型

總結：

• startup/consumer 應用程式偏向於開放領域資料，使它們非常適合使用現成的商業化LLM和嵌入模型進行向量搜尋。

• 企業級應用，特別是涉及 封閉領域資料的應用程式， 通常需要不同的、更復雜的設計才能提供可接受的效能。

• 首先要評估目標領域資料是開放的還是封閉的，如果是封閉的，則要確定是否存在有關該領域的結構化資訊（同義詞、定義、縮略語等）。

03  資料規模

企業往往比獨立開發者擁有更多的資料。很簡單就能證明這一觀點：企業是員工、客戶/消費者和業務流程的集合，這些都會產生資料，而獨立開發者只是一個個體。 與獨立開發者相比，企業開展專案的時間跨度往往更長，在時間跨度內的資料記錄密度也更高。 我們將資料分為3個維度：

• 群體資料? vs 個體資料?

• 歷史資料? vs 實時資料?

• 多種模態? vs 較少模態?

企業開發的專案往往佔據每個維度的“更多資料”一側。這一點很重要，因為隨著檢索資料量的增加，無用的記錄被認為是有用的可能性也增加，僅僅因為存在更多的無用記錄或“噪聲資料”。

? More data causes less accurate retrieval
? 資料越多，檢索越不準確

此外，與簡單的隨機資料相比，某些型別的資料會產生更多的“噪聲”。這些“噪聲”有時被稱為干擾項，我們將看到它們是如何出現在某些子類別中的。

04 群體資料? vs 個體資料?

企業的每個部門都傾向於處理一組事物：員工、客戶、產品、專案。其中每個單元都可能產生幾條到數百萬條的記錄，應用程式可能需要處理這些記錄。單個消費者可能是這些單元中的一個，因此代表的資料片段較小。 想要了解資料在該維度上的情況，需要了解：它處理的是單個實體還是多個實體？這些實體是否已知，是否可知？

4.1 實際案例

• 面向企業產品所需資料

• 電子商務產品列表?

• 客戶支援記錄?

• 特定客戶的客戶支援記錄?

• 公司的會議記錄?

• 團隊的會議記錄?

• 公司的GitHub儲存庫?

• 初創企業面向消費者產品所需資料

• 個人通話記錄?

• 個人GitHub儲存庫?

4.2 對專案的影響

大多數企業的資料集往往在該維度的資料量超出了正常值，這時，限制應用程式執行的資料規模至關重要。群體級別的資料很容易超過這個限制。即使您的應用程式包含整個群體的資料（entire population’s data），您也可以透過對目標實體（客戶、產品、專案等）進行過濾，在執行時將其轉換為單個實體的資料（unit-level data），從而為構建更簡單、更準確的檢索系統掃清障礙。然而，在某些專案中，如果客戶希望提供未經篩選整理的資料轉儲（例如透過PC硬碟），這應該是不可能的。處理這個問題有幾種方法：

• 在確定專案範圍時，將重點放在支援資料（supporting data）結構良好且能篩選到個體級別的問題上。

• 要求客戶提供 更小或更細分的資料集。

• 如果上述方法都不成功，則應 與專業領域專家協調，確定可以透過哪些實體（客戶、產品、專案等）對資料進行過濾。這可能需要新的資料提取/資料增強和查詢理解過程，但對於大型資料集來說可能至關重要。

如果您在上述方法中都沒有成功，那麼就需要花費大量精力來減少檢索系統中的噪聲資料。對於startup/consumer和企業級應用程式，都應該始終努力減輕檢索系統的負擔，只搜尋相關的資料片段。對於大型企業資料集來說，該步驟是必不可少的。對資料進行切片的方法將在以後的文章中詳細介紹。

05 歷史資料? vs 實時資料?

企業通常喜歡記賬，可能是因為出於保證合規的原因必須保留這些記錄，也可能是因為他們多年來一直在做同樣的工作，積累了大量的文件。顯然，這會導致資料規模出現問題，因為它可能引入噪聲資料，甚至還可能引入一種更具侵略性的噪聲資料：語義高度相似的記錄，如果不加以說明，就會成為檢索和生成系統的干擾因素。 判斷這是否會成為嚴重問題的一種啟發式方法是：資料是否涉及長時間跨度的專案。 下面的這些示例都可以看作是長期執行的專案的一部分（產品開發、專案管理、客戶支援），而消費者示例則與相對短暫的事件相關。當然也有很多例外情況，但這在企業中會是一個更常見的挑戰。

5.1 實際案例：

• 面向企業產品所需資料

• 客戶反饋季度報告?

• 專案報告草稿?

• 產品規格書?

• 季度OKR會議記錄?

• 初創企業面向消費者產品所需資料

• 食譜?

• 旅行日誌?

• 社交媒體帖子?

5.2 對專案的影響

如果專案資料存在多個版本、重複條目或副本，就應該從一開始就計劃解決這個問題。因為這可能會大大增加檢索噪聲，並可能導致生成系統接收到矛盾的或不真實的輸入。一般而言，最好的做法是：

• 對資料進行篩選， 只提供最新的資料給應用程式（如果之前版本的資料記錄也之相關，則該方法不可能實現）。

• 如果第一種方法不能成功實施，可以考慮 採用類似於處理群體級資料的資料切片方法（譯者注：上文提到的）。這種方法可以在生成內容之前幫助獲得更相關的檢索結果。

• 透過提示語（prompting）、小樣本示例（few-shot examples）或微調（fine-tuning），指示生成系統如何處理不同版本、日期和矛盾的記錄。 請注意，這種方法將需要提取版本或日期資訊，並將其傳遞給內容生成器。

• 基於日期的排序：最好避免使用此方法，因為系統可能已經有一個排序系統，而blending ranking signals比聽起來更困難。（譯者注：blending ranking signals是指將多個因素或訊號結合起來，來確定資料的順序。在資料具有多個版本或副本的情況下，這種情況會考慮資料的新鮮度、相關性或質量等因素，以確定其位置。例如，如果一個文件具有多個版本，可以考慮版本的日期、資訊的準確性或與使用者查詢的相關性等因素，對這些因素進行權衡和組合，來確定最終的排序結果。）不過，如果您可以用 relevant/not-relevant filter 來替代或跟進最開始的排序序列，那麼透過日期來排序可能會產生效果。（譯者注：relevant/not-relevant filter 根據預定義的標準或規則，將資料分為相關和不相關的兩個類別，以確定資料是否與特定任務或查詢相關。）

最好的辦法是堅持使用高質量資料，而不是構建複雜的 passive version control （譯者注：其中資料或文件的版本可以在沒有主動使用者干預的情況下自動跟蹤和儲存）或多訊號重排序系統（multi-signal reranking systems），從而完全避免面臨這一挑戰。

06 多種模態? vs 較少模態?

想一想你的應用程式需要支援多少種離散形式的資料？由個人直接生成的資料通常屬於自然語言模態：文字、音訊、影像、影片。在這些模態中，甚至可以進一步細分：文字記錄可能包含電子郵件、程式碼、文件、簡報、網站... 而這些模態的資料可能還巢狀包含其他形式的資料！然後還有關於個人及其行為，以及其他實體（如產品或事件）的資料，這些資料通常以表格和圖表等結構化格式表示。 一般情況下，企業能夠擁有這些多種模態混合的資料，而個人通常只會有意識地儲存和處理這些模態中的一小部分。 想想公司的資料倉儲和個人的iCloud之間的區別。在某些企業場景（如聯合搜尋）中，需要同時處理多種模態，而在其他一些場景中，一次只需要關注一種模態。

6.1 實際案例：

• 面向企業產品所需資料 ?

• 專案啟動報告

• 使用者點選行為資料

• CRM資料

• 產品規格說明書

• 季度OKR會議記錄

• 物業手冊

• 初創企業面向消費者產品所需資料?

• Notion頁面

• 待辦事項列表

• 通話記錄

• 社交媒體帖子

6.2 對專案的影響

從另一個角度看，企業擁有無數細分的資料類別，每個類別中又包含許多條目，而個人消費者的總體類別往往較少，但（正如我們將在下一節看到的）這些類別中的資料種類卻更多。企業擁有多種模態的資料實際上是一種優勢：不同型別的內容可以幫助我們使用資料規模章節（譯者注：本文03節）描述的切片技術來確定檢索範圍，更重要的是， 在解決使用者問題的同時，儘可能縮小解決方案的資料範圍。 一般來說，只對業務場景所需的內容型別進行操作。儘可能將涉及不同模態的業務場景視為不同的專案，並分別解決，然後再組合成一個適用於所有情況的解決方案。

07 資料的一致性和規律性

Data Regularity (? vs ?)

儘管企業可能擁有更多不同模態的內容，但某類內容可能所有內容都相當相似。對於圖和表等結構化資料，這是顯而易見的（因為它們是由一致的業務流程生成的），但對於報告、簡報和通話記錄等人工生成的資料，為什麼企業中的非結構化資料也會如此一致呢？ 這是因為企業乃至整個行業在溝通上都有一定的規範和慣例，而消費者之間的溝通更加多樣化。 例如，銷售電話通常比朋友之間的電話更遵循可靠的流程。

7.1 實際案例：

• 面向企業產品所需資料 ?

• 專案啟動報告

• 使用者點選行為資料

• CRM資料

• 產品規格說明書

• 季度OKR會議記錄

• 物業手冊

• 初創企業面向消費者產品所需資料 ?

• 個人電子郵件

• 通話記錄

• 社交媒體帖子

7.2 對專案的影響

根據專案所面向的使用者群體，可以根據資料的特點和常見模態做出更多的假設，以便更好地處理和運用這些資料。如果您正在構建一個供企業內部使用或用於處理受監管檔案的產品，那麼您對系統需要處理的資料結構是十分確定的。另一方面，如果您正在構建一個能夠被不同企業客戶使用的解決方案，就可能需要靈活地構建解決方案，以處理不同的資料模態，或者根據每個客戶的資料進行調整。LLM 應用程式中可能出現差異的部分幾乎包括所有內容：資料接入、檢索和內容生成。例如：

• 在處理資料時，如果系統只接觸到了有限的示例資料，而沒有涵蓋到所有可能的資料情況，那麼當遇到未知的、陌生的資料時，系統可能無法正確處理，從而導致缺陷的產生。

• 如果文件中的格式與預期不符，分塊過程可能無法正確地將文件分割成合適的塊，從而導致出現檢索缺陷。

對資料瞭解得越多，構建的系統就越簡單可靠。因此，在可以利用這些小技巧的時候就加以利用，在不可以利用的時候就靈活地去設計系統。

08 訪問控制（? vs ?）

在面向消費者和麵向企業的應用程式之間，資料最普通的區別就是誰可以訪問資料。在面向消費者的應用程式中，這通常是簡單明瞭的：使用者可以訪問自己的資料，其他人則不能（管理員除外）。然而，在企業環境中，訪問控制的情況可能變得非常複雜，因為特定資源可能有多個且頻繁更新的訪問組，以及不同層次的訪問許可權。（譯者注：在企業環境中，由於組織結構和業務需求的複雜性，訪問控制的管理變得更加複雜。企業可能有許多不同的資源，例如檔案、資料庫、應用程式等，每種資源可能都需要不同的訪問許可權。為了控制這些資源的訪問，企業通常會建立許多訪問組，每個組代表一組使用者或某一類角色，並分配相應的許可權。這些訪問組可能會頻繁更新，以適應組織架構的變化和業務需求的變化。此外，企業環境中的訪問許可權通常具有不同的層次。不同的使用者或角色根據其工作崗位可能需要不同級別的訪問許可權。）公司員工通常需要訪問某些資料來完成工作，但如果他們離開該崗位，訪問許可權也需要立即撤銷，這種操作十分必要。

8.1 實際案例：

• 面向企業產品所需資料

• 產品線文件 ?

• 人事記錄 ?

• 使用者資料

• 透過經紀人或經紀公司進行的加密貨幣交易 ?

• 旅客在航空公司中的常旅客會員賬號Frequent flyer account ?

8.2 對專案的影響

遺憾但不可避免的是，要想正確實施訪問控制，就無法避免大量的工程設計。 您能為專案做的最好的事情，就是及早認識到這一點，並確保您擁有必要的工程專業知識和客戶資料訪問許可權來解決這個問題。如果適用的話，一定要考慮與資料來源的身份提供者進行整合，並尋找能夠幫助進行整合的框架或工具。（譯者注：在許多面向企業的應用程式中，資料來源通常會有一個身份提供者，用於管理使用者的身份驗證和訪問控制。身份提供者可以是一個單獨的身份驗證系統，也可以是一個整合的身份驗證服務，例如OAuth或LDAP。）不過，關於系統如何處理不同的使用者組，仍有許多決策需要做出，例如：在涉及檢索的系統中，是在檢索之前還是之後對結果進行過濾（這個決策有時稱為 early- vs late-binding ）？

09 總結

希望這篇文章能夠在你開始進行企業級的機器學習專案時提供一些警示和建議，以便你能夠避免一些常見的問題，從而能夠更好地應對挑戰，並取得更好的結果。

END

本文經原作者授權，由Baihai IDP編譯。如需轉載譯文，請聯絡獲取授權。

原文連結：