來源：之家技術

1. 專案背景

隨著GPT-3.5在2月底的釋出，標誌著智慧化時代的來臨。這個時代為企業帶來了前所未有的機遇和挑戰。資訊系統團隊開始研究如何充分利用這一大型AI模型，以解決內部問題並提高工作效率。與此同時，行政部門也高度關注了GPT的潛力。他們與我們一同探討，是否可以建立一個系統級的客服平臺，以應對日常工作中繁瑣且重複的溝通問題。

在過程中我們留意到，資料應用團隊已經建立了私域知識庫平臺，該平臺具備對接大型模型、文字向量轉換以及召回等功能。因此，透過和資料應用團隊的深入討論，我們認為可以採用私域知識庫的方式來實現基於之家採購業務的客服系統。後期可以快速升級為提供標準服務客服並允許使用者根據業務需求定製自己的語料庫的AI 應用平臺。

2. 方案落地

經過研發團隊的探討，系統落地的整體時序圖如下：

整個落地的過程分兩條線並行，產品線主導私域知識庫的建立和問答效果的調優，技術線則重點放在大模型中臺的開發上，下面分別闡述兩條線的推進情況：

2.1

私域知識庫建立及效果調優

2.1.1 私域知識庫--語料準備

我們日常用到的大模型，如GPT系列、文心一言、訊飛星火等等，設計出來是為了理解和生成自然語言。這種模型的非凡之處在於，它透過分析和學習海量的文字資訊，生成新的、與輸入相關的文字。這種自動文字生成的能力使得GPT模型在解析複雜問題、自動生成報告、最佳化客戶服務等方面表現出色，但是針對企業內部應用場景，企業特有的流程、制度等知識無法灌輸給大模型進行針對性訓練，即便是自研或者私有化部署的大模型，我們企業知識庫的文字量級和大模型本身訓練的資料量級相比，佔比微乎其微，無法直接透過訓練來影響大模型的回答效果。

而私域知識庫則是為了解決上述問題，應運而生的。私域知識庫的基本原理是，將企業內部問答語料、制度、專業文件等資訊進行Embedding向量化，儲存在本地的資料庫中，當使用者提問時，透過Embedding模型將使用者的問題也進行向量轉化，再透過計算知識庫中的向量和問題轉化的向量之間的夾角（通常使用cosin函式），來獲得兩者的餘弦相似度，透過召回策略配置，將前N個相似度大於P的結果，作為本次問答的語料，再加上該場景下本身的角色設定（提示詞），組合成一個完整的prompt內容，推送給大模型進行總結回答。

結合大模型和私域知識庫，企業可以建立一個專業領域的AI助手，該助手可以回答關於公司業務的各種問題，或者根據員工的需求生成報告。這樣的一種方式不僅可以提高企業的工作效率，還可以幫助員工更好地理解和利用企業的資源。

那麼，準備知識庫語料時我們應該注意哪些問題呢？根據筆者現有專案的經驗看，Embedding模型本身有以下特點：

1.可以理解語義，例如生孩子和育兒，在向量化之後的相似度可以在0.8以上；

2.相似度和字數有關，例如制度的字數過多時，會導致和問題的相似度降低；

3.有時會出現兩個完全不相關的語句計算出的相似度確很高，從而影響我們正常的回答效果；這是由於相似度演算法根本原理還是數學的向量之間的夾角，不同的語料轉換向量可能存在偶發的相似，這也和訓練大模型的語料中使用的語法和語義有很大的關係，是我們作為應用方無法直接解決的。

當我問“年假”，會出現和年假無關的語料，且相似度都在0.7以上

針對上述問題和特點，我們準備語料庫資料時，可以從以下幾個方向去最佳化：

1、在有限的字數內，可以冗餘的描述問題和答案，例如生孩子、育兒假、哺乳假等等相關詞彙儘可能多角度的去描述該問題，從而在計算相似度時能更優先召回該答案；但也要注意字數不要過多，否則也會降低相似度；

2、針對大模型普遍存在的“一本正經胡說八道”的問題，如果我們有明確的不想回答的問題，可以準備一下該問題的語料，答案裡可以寫“該問題不方便回答”“對不起，此類問題請諮詢XXX”之類的答案，這樣在使用者問到此類問題時，會根據知識庫中的語料進行一個比較理想的答覆；

3、有些制度等文字過多，我們有兩種方式解決，一種是用遞迴字元文字分割的方式，例如將每500個字分割成一塊，但是這種分割會把一句完整的語句分到兩個語料塊中，所以在分割時我們還會加入重複字數的設定，比如重複字數100字，那麼分塊的時候，第1-500字是第一塊內容，第400-900字是第二塊內容，這樣可以避免一句話或者一段完整的介紹被分割到兩個內容塊中；第二種方式是人工分割，根據實際含義，將一塊完整的內容分割到一起；

4、儘量避免只使用專業性詞語，或對專業詞語要有相應的口語化解釋，因為使用者提問時，大多不是專業使用者，問的問題相對偏口語化，如果語料庫中沒有相應的口語化描述，召回的結果可能不盡人意。

文字分割示例圖

2.1.2 訓練？prompt調優

當我們準備好私域知識庫後，就可以開始我們的訓練調優步驟了，針對當前應用的業務場景，要給大模型一個基本的角色設定（有的地方也叫提示詞）、引數設定、私域知識語料、歷史聊天內容等等資訊，這些組合到一起構成一個完整的prompt內容。

角色設定是指在模型生成輸出之前，向模型提供一段特定的文字提示或引導資訊，以幫助模型更好地理解輸入資料並生成期望的輸出。角色設定可以根據具體的任務和資料集進行定製化，以提高模型的效能和準確性。

Prompt可以包括以下內容：

1、設定基本角色資訊，並提出要求，例如不能幹什麼，或者必須幹什麼；

2、直接提供答案：在某些場景中，可以直接向模型提供期望的答案。例如，問到資料外的問題請回答“對不起，我不知道。”；

3.、提供相關知識資訊：在文字生成場景中，可以向模型提供一些上下文資訊，例如文章的主題、重要的關鍵詞或相關背景知識等，以幫助模型更好地理解輸入資料並生成高質量的輸出。在問答場景下，此部分就是對應我們的私域知識庫召回的內容和外掛中返回的內容（見下文外掛部分詳解）；

4、歷史聊天內容：通常是多輪對話場景下，方便大模型理解上下文聊天內容，從而補全當前使用者的問題，進而更好的去回答；

5、基本引數設定，例如溫度、最大tokens、懲罰係數等等常用的GPT引數；

提示詞設定示例

開展針對私域資料庫的訓練，應遵循以下幾個步驟：

1、定一個基本的角色設定和引數配置；

2、開始測試性提問，並評估回答效果；

3、badcase分析，針對性解決問題：

1）召回是否準確：理想的知識庫語料是不是被準確召回了，這裡需要注意的是我們設定的召回數量和最低召回分數，如果目標語料排名比較靠後導致沒有召回，則應調整語料中用詞，儘量提高其相似度，或者將排名靠前的語料進行調整降低其相似度；如果是相似度分數較低導致沒有召回，則需要最佳化語料中用詞，提高相似度分數；

2）召回準確，但是大模型沒有很好的理解並回答：在角色設定內更清晰的描述需求，或者給一些相關的知識點、示例資料等，大模型更善於模仿而不是創造；

3）大模型自由發揮，說了不該說的話：在角色設定中強調要求，並給出應該怎麼回答的示例；降低GPT溫度引數，減少其自由發揮的程度；

4、經過最佳化後，再重複提問之前的badcase，驗證效果直到符合預期；

召回策略設定示例

2.1.3 外掛迭代，擴充套件

我們使用大模型的過程中，發現無論是提前訓練的語料還是私域知識庫，都是基於歷史資料產生的靜態資訊，我們無法讓大模型回答一些實時性比較強的問題，比如今天天氣怎麼樣？我的報銷單據審批到誰了？等等。有需求就會有解決方案，目前市面上的主流大模型均已支援外掛模式。

所謂外掛模式，就是針對某個場景研發一個系統介面，當使用者問到相關問題時，由大模型（為了更容易理解，我們們可以把他當做一個人）來判斷是否呼叫某個介面，外掛內也要做設定、描述等設定，來要求大模型將自然語音轉化為介面可識別的json等格式，並將介面返回的各個引數拼接成自然語言，再透過prompt給到大模型（這裡的大模型我們可以把他當做第二個人，和之前呼叫外掛的是完全不同的設定）進行總結回答。

外掛角色設定示例

透過外掛模式，我們可以解決更多場景的問題，其中最最有效的外掛，就是對接搜尋引擎，將實時搜尋到的資訊，經過大模型總結成更實用的知識點。之前百度文心一言的釋出會上，就有很好的應用場景，例如讓大模型幫你制定一份出行攻略，他會先去搜尋網上的攻略，然後根據你的要求、交通工具、時間等進行總結歸納，形成你個人定製化的出行計劃，非常實用。而在企業內部應用，我們更多是用到查詢內部系統單據資訊、系統流程打通（例如建立日程、報銷單、請休假申請等等）。

除了外掛模式外，我們還可以反向應用大模型技術，把大模型的使用內嵌到我們業務系統中，例如招聘場景下，當招聘官開啟簡歷的時候，系統呼叫大模型介面自動分析簡歷與JD的匹配程度，給出分析，並給出一些面試建議等。這類應用場景可以不改變原有業務流程習慣，增強補齊原業務中缺失的智慧分析能力。

當然，儘管我們想盡辦法去最佳化我們的知識庫和prompt，還是會出現很多意外情況，例如我們曾經不想讓小助手講笑話，設定裡寫了你是採購小助手，只能回答和採購相關的問題，當我們問他可不可以給我講個笑話時，大模型回答的是：我是採購小助手，不能給你講笑話，但是我可以給你講個採購員的笑話。我們在和大模型“鬥智鬥勇”的過程中，相互成長。

2.2

技術線推進大模型中臺的建立

在專案建設過程中，我們認識到儘管私域知識庫提供了出色的對接機制和文件，但在實際業務對接中，仍需要投入大量開發資源，並且在新業務線接入時，面臨著高昂的開發成本和重複的溝通，學習成本。因此，我們的開發團隊經過深入討論，提出了一個構想，即建立一個全新的業務對接模式，將通用功能進行封裝，形成平臺化。這將使公司內部新業務的接入成本幾乎可以降至零，甚至完全零開發成本。這一舉措將有助於加速智慧AI在業務層面的應用推廣。在與資料應用團隊和雲平臺團隊的深入研討後，我們提出了建立之家大模型中臺的構想，其主要組成部分如下：

1.、雲平臺團隊將負責提供原生API的對接和基礎設施支援。這包括與不同廠商和業務的對接，如ChatGpt、文心一言、科大星火、通義千問等大模型。這種對接可以確保平臺具有廣泛的能力，滿足多樣化的業務需求。

2、資料應用團隊將負責構建私域知識庫，這是整個系統的核心部分。他們還將負責外掛註冊、Prompt（提示語）設定、語言向量召回、引數調教等功能。這些功能可以幫助系統更好地理解使用者需求，提供個性化的回應。

3、資訊系統和前端團隊將承擔業務側功能的封裝工作。將負責建立統一的接入安全策略，處理前端會話服務和使用者互動，以及提供後臺管理功能。這有助於確保系統的穩定性、安全性和業務接入的易用性。

各團隊之間的協作將有助於減少重複開發工作，降低對接和熟悉成本，提高業務對接的效率。整體而言，這個構想有望加速智慧AI應用在業務層面的推廣，併為未來的業務擴充套件提供了靈活性和可擴充套件性。

系統構想的整體架構如下：

本次主要介紹平臺層的設計和成果，在平臺層的設計中，主要關注以下四點：

2.2.1 降低業務接入開發成本，支援業務快速落地：

為了實現這一目標，我們提供了兩種接入方案，以滿足不同需求：

2.2.1.1 前端直接接入：

這是一種簡化業務接入流程的解決方案。當業務系統沒有特殊需求時，只需引入適當的指令碼並進行配置即可。這種方法要適用於各種前端技術棧，因此我們要求在開發的過程中使用原生JavaScript以確保相容性。在這個指令碼中要提供一個可定製的懸浮聊天助手按鈕，使用者可以輕鬆點選按鈕以展示聊天助手容器，並可以自由拖動按鈕以改變其位置。聊天助手容器透過內嵌的iframe載入特定的URL，從而呈現聊天助手的內容。

為此關鍵實現如下：

建立內嵌聊天助手容器

建立內嵌聊天助手的iframe，並設定其樣式和源URL。

將聊天助手容器和按鈕新增到頁面中。

為懸浮按鈕新增點選事件，以在點選時顯示聊天助手容器。

為懸浮按鈕新增拖拽事件，以允許使用者拖動按鈕的位置。

業務系統接入程式碼

可以看到，各業務系統如果使用通用的前端接入，只需要引入指令碼，給予業務線ID 即可輕鬆接入使用，幾乎0幾乎成本。

2.2.1.2 後端接入：

考慮到不同業務場景的特殊要求，對於前端需要定製化開發的特殊情況，我們直接提供了後端API接入方式，以滿足特殊需求，為此，業務平臺提供了3大類，11個小類的功能介面來滿足業務需要，涵蓋會話服務，聊天輔助，後臺管理資料對接等功能。

一個前端透過webSocket對接後端會話服務的示例：

前端會話發起，直接使用用WebSocket 接入後端服務，其中businessLineId 代表業務線，encryptedData 代表加密過的票據資訊（這個的用途會在後面講到）

2.2.2 確保業務對接過程的安全性

為確保系統的安全性，我們引入了以下措施：

2.2.2.1 Token校驗機制：

確保只有經授權的使用者能夠訪問系統資源。為此，我們考慮到未來對接平臺的業務系統會有兩種：

第一，公司內網的辦公系統接入，這些系統共性是統一接入了sso 登入平臺，因此考慮到接入的便利性，我們不需要業務系統給我們傳遞加密憑證，而是直接對接sso 平臺獲取身份資訊，再把票據寫入到cookie 確保連結的合法性，關鍵實現如下：

01、直接對接sso 平臺獲取當前使用者資訊

02、轉成加密票據寫入cookie，以確保每次請求的合法性驗證

為了簡化前端系統的對接工作，所以採用了cookie票據認證的方案，即每次請求時在後端解析cookie 票據以驗證合法性，但是這樣做也帶來一個問題，即要求接入業務系統的根域名和iframe 嵌入中臺助手的根域名必須一致,否則會有跨域讀寫cookie 的問題，但這無形中又會增加前端業務系統的對接成本，所以我們直接提供了兩個引入指令碼路徑，根域名分別為corpautohome.com 和 autohome.com.cn 路徑，各業務系統直接根據自己域名引入不同路徑指令碼即可，全部的適配工作都由平臺端完成，無需業務系統考慮。

提供兩種域名路徑的引入檔案：

在元件渲染時，注入不同的請求路徑：

後端處理，分別寫入不同域下的cookie：

第二，外網系統或並未對接sso平臺的系統，則需外圍系統按照約定的加密標準開發一個加密認證的介面，初始化時給予加密憑證，平臺拿到加密憑證後再驗證合法性，驗證透過後建立加密票據到cookie中,確保該連結的合法性

01、前端業務系統加密對接例項：

業務系統後端：業務系統拿到約定的業務線id 和秘鑰後，開發密文生成程式。

業務系統前端：引入指令碼後，頁面初始化對接引數：

平臺端：根據注入密文去驗證合法性，如果合法，則執行和第一種接入方式相同的方法生成加密票據寫入cookie：

2.2.2.2 黑名單機制：

由於平臺對外提供的是一個對話服務，為了防止客戶端強刷或者其它的潛在風險，所以平臺提供了一個設定ip黑名單的功能，可以透過訪問日誌檢視相關的風險資訊，當判斷有風險時，可以即可把ip 地址加入黑名單，以阻止其訪問。

平臺提供檢視系統日誌及加入黑名單的介面：

在使用者建立通訊連結時驗證其IP是否在黑名單內，如果是則拒絕建立連結：

2.2.3 可控性和穩定性：

為提高系統的可控性和穩定性我們本次採用websocket方式實現前後端通訊，並且基於redis 來對實現線上使用者的控制，包括建立連結，中斷，強制下線控制等。

不廢話，上實現過程程式碼：

1、建立webSocket 通道，自定義配置類，複製所有request 請求屬性，用於後續的使用者身份驗證

2、驗證身份，傳輸訊息

3、訊息處理：

4、限流控制：考慮到有未來有內外網多業務線共同接入，在部署的容器例項有限的情況下為了防止有業務線被強刷的從而影響整體效能風險，所以平臺建設時加入了業務線限流措施，即建立訊息通道時把把建立通道的例項計數，同時在下線或者心跳檢測失敗時做減法，每次新建立連結時判斷當前例項存活數是否達到上限。

5、實時下線功能：引入實時下線功能，以及時處理系統問題，降低因異常情況導致的服務中斷風險。

後臺直接從redis 中移除線上使用者例項，前端webSocket 通訊時，則前端再次發起會話中，到當前用於已經不在redis中，則中斷會話，程式碼參考上面試的使用者下線功能。

2.2.4 通用功能和個性化配置：

考慮到各個業務線的不同的需求，我們提供了豐富的配置功能和統一的資料監控，管理功能。

2.2.4.1 針對業務線配置：

包括圖示配置，歡迎語配置，顯示配置：提供圖示、歡迎語和顯示方式的個性化配置選項，以滿足不同業務的需求和品牌標識。

2.2.4.2 針對業務線下知識庫配置：

以實現同一業務線下不同功能的切換和統一展示。

2.2.4.3 資料實時統計：

引入實時統計功能，幫助業務方監控和最佳化系統效能，提供決策支援。

這些綜合性措施旨在為業務接入平臺的建設提供全面的支援，從而使系統更具可用性、安全性和靈活性，助力業務快速推進。同時，這些功能的引入將使平臺在滿足通用需求的同時，能夠滿足個性化的業務配置。

3. 成果展示

應用對接：基於大模型中臺，我們已經快速建立了APP 和PC 兩端元件，業務上支援了好採小助手，員工助手，倉頡大模型應用，供應商門戶等業務的智慧化應用。

4. 結語

在未來，隨著人工智慧技術的不斷髮展，私域知識庫和大模型中臺將成為企業智慧化轉型的重要支撐。我們可以在不同業務領域應用這些技術，提高業務效率、增強智慧決策能力，為員工和客戶提供更好的服務體驗。同時，隨著大模型技術的不斷演進，我們也可以升級更多功能，滿足不同業務線的特定需求。外掛模式的推廣將使大模型變得更加靈活，可以應對更多複雜的場景和問題。總之，私域知識庫和大模型中臺代表了企業智慧化的未來趨勢，它們將為之家帶來更多機遇和競爭優勢，助力業務不斷創新和發展。

資訊系統大模型助手小分隊-基於好採專案推進大模型應用在之家的快速落地

相關文章