1.  項目背景

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

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

2. 方案落地

經(jīng)過研發(fā)團隊的探討，系統(tǒng)落地的整體時序圖如下：

圖片

整個落地的過程分兩條線并行，產(chǎn)品線主導(dǎo)私域知識庫的建立和問答效果的調(diào)優(yōu)，技術(shù)線則重點放在大模型中臺的開發(fā)上，下面分別闡述兩條線的推進情況：

2.1私域知識庫建立及效果調(diào)優(yōu)

2.1.1 私域知識庫--語料準(zhǔn)備

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

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

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

那么，準(zhǔn)備知識庫語料時我們應(yīng)該注意哪些問題呢？根據(jù)筆者現(xiàn)有項目的經(jīng)驗看，Embedding模型本身有以下特點：

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

圖片

當(dāng)我問“年假”，會出現(xiàn)和年假無關(guān)的語料，且相似度都在0.7以上

針對上述問題和特點，我們準(zhǔn)備語料庫數(shù)據(jù)時，可以從以下幾個方向去優(yōu)化：

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

文本分割示例圖

2.1.2 訓(xùn)練？prompt調(diào)優(yōu)

當(dāng)我們準(zhǔn)備好私域知識庫后，就可以開始我們的訓(xùn)練調(diào)優(yōu)步驟了，針對當(dāng)前應(yīng)用的業(yè)務(wù)場景，要給大模型一個基本的角色設(shè)定（有的地方也叫提示詞）、參數(shù)設(shè)置、私域知識語料、歷史聊天內(nèi)容等等信息，這些組合到一起構(gòu)成一個完整的prompt內(nèi)容。

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

Prompt可以包括以下內(nèi)容：

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

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

提示詞設(shè)定示例

開展針對私域數(shù)據(jù)庫的訓(xùn)練，應(yīng)遵循以下幾個步驟：

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

 1）召回是否準(zhǔn)確：理想的知識庫語料是不是被準(zhǔn)確召回了，這里需要注意的是我們設(shè)置的召回數(shù)量和最低召回分數(shù)，如果目標(biāo)語料排名比較靠后導(dǎo)致沒有召回，則應(yīng)調(diào)整語料中用詞，盡量提高其相似度，或者將排名靠前的語料進行調(diào)整降低其相似度；如果是相似度分數(shù)較低導(dǎo)致沒有召回，則需要優(yōu)化語料中用詞，提高相似度分數(shù)；

2）召回準(zhǔn)確，但是大模型沒有很好的理解并回答：在角色設(shè)定內(nèi)更清晰的描述需求，或者給一些相關(guān)的知識點、示例數(shù)據(jù)等，大模型更善于模仿而不是創(chuàng)造；

3）大模型自由發(fā)揮，說了不該說的話：在角色設(shè)定中強調(diào)要求，并給出應(yīng)該怎么回答的示例；降低GPT溫度參數(shù)，減少其自由發(fā)揮的程度；

4、經(jīng)過優(yōu)化后，再重復(fù)提問之前的badcase，驗證效果直到符合預(yù)期；

召回策略設(shè)置示例

2.1.3 插件迭代，擴展

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

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

插件角色設(shè)定示例

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

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

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

2.2技術(shù)線推進大模型中臺的建立

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

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

各團隊之間的協(xié)作將有助于減少重復(fù)開發(fā)工作，降低對接和熟悉成本，提高業(yè)務(wù)對接的效率。整體而言，這個構(gòu)想有望加速智能AI應(yīng)用在業(yè)務(wù)層面的推廣，并為未來的業(yè)務(wù)擴展提供了靈活性和可擴展性。

系統(tǒng)構(gòu)想的整體架構(gòu)如下：

圖片

本次主要介紹平臺層的設(shè)計和成果，在平臺層的設(shè)計中，主要關(guān)注以下四點：

2.2.1 降低業(yè)務(wù)接入開發(fā)成本，支持業(yè)務(wù)快速落地：

為了實現(xiàn)這一目標(biāo)，我們提供了兩種接入方案，以滿足不同需求：

2.2.1.1 前端直接接入：

這是一種簡化業(yè)務(wù)接入流程的解決方案。當(dāng)業(yè)務(wù)系統(tǒng)沒有特殊需求時，只需引入適當(dāng)?shù)哪_本并進行配置即可。這種方法要適用于各種前端技術(shù)棧，因此我們要求在開發(fā)的過程中使用原生JavaScript以確保兼容性。在這個腳本中要提供一個可定制的懸浮聊天助手按鈕，用戶可以輕松點擊按鈕以展示聊天助手容器，并可以自由拖動按鈕以改變其位置。聊天助手容器通過內(nèi)嵌的iframe加載特定的URL，從而呈現(xiàn)聊天助手的內(nèi)容。

為此關(guān)鍵實現(xiàn)如下：

創(chuàng)建內(nèi)嵌聊天助手容器

創(chuàng)建內(nèi)嵌聊天助手的iframe，并設(shè)置其樣式和源URL。

圖片

圖片

將聊天助手容器和按鈕添加到頁面中。

為懸浮按鈕添加點擊事件，以在點擊時顯示聊天助手容器。

為懸浮按鈕添加拖拽事件，以允許用戶拖動按鈕的位置。

業(yè)務(wù)系統(tǒng)接入代碼

可以看到，各業(yè)務(wù)系統(tǒng)如果使用通用的前端接入，只需要引入腳本，給予業(yè)務(wù)線ID 即可輕松接入使用，幾乎0幾乎成本。

圖片

2.2.1.2 后端接入：

考慮到不同業(yè)務(wù)場景的特殊要求，對于前端需要定制化開發(fā)的特殊情況，我們直接提供了后端API接入方式，以滿足特殊需求，為此，業(yè)務(wù)平臺提供了3大類，11個小類的功能接口來滿足業(yè)務(wù)需要，涵蓋會話服務(wù)，聊天輔助，后臺管理數(shù)據(jù)對接等功能。

圖片

一個前端通過webSocket對接后端會話服務(wù)的示例：

前端會話發(fā)起，直接使用用WebSocket 接入后端服務(wù)，其中businessLineId 代表業(yè)務(wù)線，encryptedData 代表加密過的票據(jù)信息（這個的用途會在后面講到）

圖片

2.2.2 確保業(yè)務(wù)對接過程的安全性

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

2.2.2.1 Token校驗機制：

確保只有經(jīng)授權(quán)的用戶能夠訪問系統(tǒng)資源。為此，我們考慮到未來對接平臺的業(yè)務(wù)系統(tǒng)會有兩種：

第一，公司內(nèi)網(wǎng)的辦公系統(tǒng)接入，這些系統(tǒng)共性是統(tǒng)一接入了sso 登錄平臺，因此考慮到接入的便利性，我們不需要業(yè)務(wù)系統(tǒng)給我們傳遞加密憑證，而是直接對接sso 平臺獲取身份信息，再把票據(jù)寫入到cookie 確保鏈接的合法性，關(guān)鍵實現(xiàn)如下：

01、直接對接sso 平臺獲取當(dāng)前用戶信息

圖片

02、轉(zhuǎn)成加密票據(jù)寫入cookie，以確保每次請求的合法性驗證

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

圖片

提供兩種域名路徑的引入文件：

圖片

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

圖片

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

圖片

第二，外網(wǎng)系統(tǒng)或并未對接sso平臺的系統(tǒng)，則需外圍系統(tǒng)按照約定的加密標(biāo)準(zhǔn)開發(fā)一個加密認證的接口，初始化時給予加密憑證，平臺拿到加密憑證后再驗證合法性，驗證通過后創(chuàng)建加密票據(jù)到cookie中,確保該鏈接的合法性

01、前端業(yè)務(wù)系統(tǒng)加密對接實例：

業(yè)務(wù)系統(tǒng)后端：業(yè)務(wù)系統(tǒng)拿到約定的業(yè)務(wù)線id 和秘鑰后，開發(fā)密文生成程序。

圖片

業(yè)務(wù)系統(tǒng)前端：引入腳本后，頁面初始化對接參數(shù)：

圖片

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

圖片

2.2.2.2 黑名單機制：

由于平臺對外提供的是一個對話服務(wù)，為了防止客戶端強刷或者其它的潛在風(fēng)險，所以平臺提供了一個設(shè)置ip黑名單的功能，可以通過訪問日志查看相關(guān)的風(fēng)險信息，當(dāng)判斷有風(fēng)險時，可以即可把ip 地址加入黑名單，以阻止其訪問。

平臺提供查看系統(tǒng)日志及加入黑名單的界面：

圖片

在用戶建立通信鏈接時驗證其IP是否在黑名單內(nèi)，如果是則拒絕建立鏈接：

圖片

圖片

圖片

2.2.3 可控性和穩(wěn)定性：

為提高系統(tǒng)的可控性和穩(wěn)定性我們本次采用websocket方式實現(xiàn)前后端通信，并且基于redis 來對實現(xiàn)在線用戶的控制，包括建立鏈接，中斷，強制下線控制等。

不廢話，上實現(xiàn)過程代碼：

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

圖片

圖片

• 驗證身份，傳輸消息

圖片

• 消息處理：

圖片

圖片

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

圖片

圖片

• 實時下線功能：引入實時下線功能，以及時處理系統(tǒng)問題，降低因異常情況導(dǎo)致的服務(wù)中斷風(fēng)險。

圖片

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

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

考慮到各個業(yè)務(wù)線的不同的需求，我們提供了豐富的配置功能和統(tǒng)一的數(shù)據(jù)監(jiān)控，管理功能。

2.2.4.1 針對業(yè)務(wù)線配置：

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

圖片

圖片

2.2.4.2 針對業(yè)務(wù)線下知識庫配置：

以實現(xiàn)同一業(yè)務(wù)線下不同功能的切換和統(tǒng)一展示。

圖片

2.2.4.3 數(shù)據(jù)實時統(tǒng)計：

引入實時統(tǒng)計功能，幫助業(yè)務(wù)方監(jiān)控和優(yōu)化系統(tǒng)性能，提供決策支持。

圖片

圖片

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

3. 成果展示

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

圖片

圖片

圖片

4. 結(jié)語

在未來，隨著人工智能技術(shù)的不斷發(fā)展，私域知識庫和大模型中臺將成為企業(yè)智能化轉(zhuǎn)型的重要支撐。我們可以在不同業(yè)務(wù)領(lǐng)域應(yīng)用這些技術(shù)，提高業(yè)務(wù)效率、增強智能決策能力，為員工和客戶提供更好的服務(wù)體驗。同時，隨著大模型技術(shù)的不斷演進，我們也可以升級更多功能，滿足不同業(yè)務(wù)線的特定需求。插件模式的推廣將使大模型變得更加靈活，可以應(yīng)對更多復(fù)雜的場景和問題?？傊接蛑R庫和大模型中臺代表了企業(yè)智能化的未來趨勢，它們將為之家?guī)砀鄼C遇和競爭優(yōu)勢，助力業(yè)務(wù)不斷創(chuàng)新和發(fā)展。

作者簡介

信息系統(tǒng)大模型助手小分隊

■ 效能平臺部-信息系統(tǒng)團隊

■ 簡介

  王冠男：高級系統(tǒng)開發(fā)工程師, 目前主要負責(zé)行政，財務(wù)線相關(guān)系統(tǒng)及大模型業(yè)務(wù)中臺的研發(fā)工作

  孫鵬飛：系統(tǒng)開發(fā)工程師，目前主要負責(zé)招采平臺，匯川平臺，稅務(wù)系統(tǒng)等內(nèi)部系統(tǒng)及大模型中臺會話功能的研發(fā)工作

  王廷軍：系統(tǒng)開發(fā)工程師，目前主要負責(zé)HR業(yè)務(wù)線相關(guān)系統(tǒng)和大模型中臺管理部分的研發(fā)工作

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

徐晨曦：高級產(chǎn)品經(jīng)理，目前主要負責(zé)行政業(yè)務(wù)線，汽車人及大模型中臺的產(chǎn)品規(guī)劃工作

圖片

圖片