1.  項目背景

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

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

2. 方案落地

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

圖片

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

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

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

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

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

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

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

• 可以理解語義，例如生孩子和育兒，在向量化之后的相似度可以在0.8以上；
• 相似度和字數有關，例如制度的字數過多時，會導致和問題的相似度降低；
• 有時會出現兩個完全不相關的語句計算出的相似度確很高，從而影響我們正常的回答效果；這是由于相似度算法根本原理還是數學的向量之間的夾角，不同的語料轉換向量可能存在偶發的相似，這也和訓練大模型的語料中使用的語法和語義有很大的關系，是我們作為應用方無法直接解決的。

圖片

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

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

• 在有限的字數內，可以冗余的描述問題和答案，例如生孩子、育兒假、哺乳假 等等相關詞匯盡可能多角度的去描述該問題，從而在計算相似度時能更優先召回該答案；但也要注意字數不要過多，否則也會降低相似度；
• 針對大模型普遍存在的“一本正經胡說八道”的問題，如果我們有明確的不想回答的問題， 可以準備一下該問題的語料，答案里可以寫“該問題不方便回答”“對不起，此類問題請咨詢XXX”之類的答案，這樣在用戶問到此類問題時，會根據知識庫中的語料進行一個比較理想的答復；
• 有些制度等文字過多，我們有兩種方式解決，一種是用遞歸字符文本分割的方式，例如將每500個字分割成一塊，但是這種分割會把一句完整的語句分到兩個語料塊中，所以在分割時我們還會加入重復字數的設置，比如重復字數100字，那么分塊的時候，第1-500字是第一塊內容，第400-900字是第二塊內容，這樣可以避免一句話或者一段完整的介紹被分割到兩個內容塊中；第二種方式是人工分割，根據實際含義，將一塊完整的內容分割到一起；
• 盡量避免只使用專業性詞語，或對專業詞語要有相應的口語化解釋，因為用戶提問時，大多不是專業用戶，問的問題相對偏口語化，如果語料庫中沒有相應的口語化描述，召回的結果可能不盡人意。

文本分割示例圖

2.1.2 訓練？prompt調優

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

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

Prompt可以包括以下內容：

設置基本角色信息，并提出要求，例如不能干什么，或者必須干什么；

• 直接提供答案：在某些場景中，可以直接向模型提供期望的答案。例如，問到資料外的問題請回答“對不起，我不知道。”；
• 提供相關知識信息：在文本生成場景中，可以向模型提供一些上下文信息，例如文章的主題、重要的關鍵詞或相關背景知識等，以幫助模型更好地理解輸入數據并生成高質量的輸出。在問答場景下，此部分就是對應我們的私域知識庫召回的內容和插件中返回的內容（見下文插件部分詳解）；
• 歷史聊天內容：通常是多輪對話場景下，方便大模型理解上下文聊天內容，從而補全當前用戶的問題，進而更好的去回答；
•  基本參數設置，例如溫度、最大tokens、懲罰系數等等常用的GPT參數；

提示詞設定示例

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

• 定一個基本的角色設定和參數配置；
• 開始測試性提問，并評估回答效果；
• badcase分析，針對性解決問題：

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

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

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

4、經過優化后，再重復提問之前的badcase，驗證效果直到符合預期；

召回策略設置示例

2.1.3 插件迭代，擴展

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

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

插件角色設定示例

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

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

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

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

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

• 云平臺團隊將負責提供原生API的對接和基礎設施支持。這包括與不同廠商和業務的對接，如ChatGpt、文心一言、科大星火、通義千問等大模型。這種對接可以確保平臺具有廣泛的能力，滿足多樣化的業務需求。
• 數據應用團隊將負責構建私域知識庫，這是整個系統的核心部分。他們還將負責插件注冊、Prompt（提示語）設定、語言向量召回、參數調教等功能。這些功能可以幫助系統更好地理解用戶需求，提供個性化的回應。
• 信息系統和前端團隊將承擔業務側功能的封裝工作。將負責創建統一的接入安全策略，處理前端會話服務和用戶交互，以及提供后臺管理功能。這有助于確保系統的穩定性、安全性和業務接入的易用性。

各團隊之間的協作將有助于減少重復開發工作，降低對接和熟悉成本，提高業務對接的效率。整體而言，這個構想有望加速智能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 來對實現在線用戶的控制，包括建立鏈接，中斷，強制下線控制等。

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

•  建立webSocket 通道，自定義配置類，復制所有request 請求屬性，用于后續的用戶身份驗證

圖片

圖片

• 驗證身份，傳輸消息

圖片

• 消息處理：

圖片

圖片

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

圖片

圖片

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

圖片

后臺直接從redis 中移除在線用戶實例，前端webSocket 通信時，則前端再次發起會話中，到當前用于已經不在redis中，則中斷會話，代碼參考上面試的用戶下線功能。

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

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

2.2.4.1 針對業務線配置：

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

圖片

圖片

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

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

圖片

2.2.4.3 數據實時統計：

引入實時統計功能，幫助業務方監控和優化系統性能，提供決策支持。

圖片

圖片

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

3. 成果展示

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

圖片

圖片

圖片

4. 結語

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

作者簡介

信息系統大模型助手小分隊

■ 效能平臺部-信息系統團隊

■ 簡介

  王冠男：高級系統開發工程師, 目前主要負責行政，財務線相關系統及大模型業務中臺的研發工作

  孫鵬飛：系統開發工程師，目前主要負責招采平臺，匯川平臺，稅務系統等內部系統及大模型中臺會話功能的研發工作

  王廷軍：系統開發工程師，目前主要負責HR業務線相關系統和大模型中臺管理部分的研發工作

  郭鵬松：前端開發工程師，目前主要負責公司協同辦公，知識庫文檔，和大模型前端交互部分的研發工作

徐晨曦：高級產品經理，目前主要負責行政業務線，汽車人及大模型中臺的產品規劃工作

圖片

圖片