一、業(yè)務(wù)現(xiàn)狀和背景

首先來介紹下艦橋平臺。

艦橋是知乎內(nèi)部的一個運營分析平臺，它主要的場景涉及找人、找內(nèi)容、盯人、盯內(nèi)容、找機會、查問題，它提供的能力包括篩選、打包、分析和監(jiān)控。

在這個過程中，我們是如何和大模型進行結(jié)合的呢？

知乎的業(yè)務(wù)發(fā)展起源于靈感，可以分為外部靈感和內(nèi)部靈感。外部靈感主要是來源于站外的新聞，我們會講站外的新聞根據(jù)知識體系聚合成事件，再根據(jù)事件產(chǎn)出問題，最后基于問題形成討論場，討論會產(chǎn)生站內(nèi)的供用戶消費的內(nèi)容。內(nèi)部靈感主要是來源于站內(nèi)已有的內(nèi)容，對已有的內(nèi)容進行整理、分析、合并和分類。我們把這一部分的工作稱為知識體系整理，也是大模型在艦橋平臺應(yīng)用的第一部分。

第二部分針對知乎站內(nèi)的內(nèi)容生態(tài)建設(shè)，我們會利用大模型通過自然語言在推薦系統(tǒng)的基礎(chǔ)上宏觀調(diào)控內(nèi)容生態(tài)。

第三部分針對業(yè)務(wù)分析，利用大模型通過自然語言進行數(shù)據(jù)分析。

以上就是大模型在艦橋平臺的應(yīng)用場景，這三個場景無論在業(yè)務(wù)上還是在技術(shù)上都具有一定的獨特性和代表性。

二、知識體系分類整理

下面來具體介紹第一個場景，即知識體系的分類整理。

這個場景有兩種業(yè)務(wù)形態(tài)，第一種是事件聚合，傳統(tǒng)的做法是從站外的新聞源獲取新聞，通過聚類的算法進行聚合，再根據(jù)聚類結(jié)果人工新增事件，接著選擇合適的角度基于事件創(chuàng)建問題進而引發(fā)多觀點討論。第二種是沉淀內(nèi)容，我們需要重新整理出對應(yīng)的多級分類樹和對應(yīng)內(nèi)容，結(jié)構(gòu)化已有的知識，讓沉淀的內(nèi)容進一步引起討論。

在用大模型解決以上兩個業(yè)務(wù)需求的時候，我們遇到了很多問題，包括聚類準確性的問題、max token問題、流程復(fù)雜性問題。

我們基于大模型設(shè)計的事件聚合流程如上圖所示，整體分4個階段：

• 新聞提取關(guān)鍵信息并處理成向量。
• 多輪高準聚類直到無法聚類，大模型在這個階段起到的作用是給節(jié)點下的新聞或者事件起名。
• 一輪高召聚類，聚類后，再通過大模型判斷聚類節(jié)點中事件是否相同，如果相同則合并。
• 生成事件-->新聞的最終結(jié)果，交付給業(yè)務(wù)方使用。

將對新聞進行層次聚類替代為對大模型生成的事件進行層次聚類有效地解決了聚不上的case；讓大模型判斷聚在一起的新聞或者事件是否真實是相同的事件并根據(jù)結(jié)果采取相應(yīng)的措施有效地解決了過度聚合的case。

由于已經(jīng)通過層次聚類對節(jié)點下的內(nèi)容進行了分組，所以輸入給大模型的prompt都比較小，這也有效地解決了max token問題。

由于基于大模型去完成整個任務(wù)的流程相對比較困難，我們設(shè)計并開發(fā)了針對該任務(wù)的類似于MapReduce的方案，這也很好地解決了流程復(fù)雜的問題。

這套新方案有以下優(yōu)點：

• 事件名可以自動生成，無需人工介入。
• 準確率的提升。

至于知識整理，我們基于大模型搭建了如上圖所示的流程。整體流程大致可以分成以下幾步：

• 內(nèi)容拆分，確保prompt不超過max token。
• map階段：將每組內(nèi)容生成分類名。
• reduce階段：分類名兩兩合并，直到無法合并。
• 結(jié)果寫入文件，并根據(jù)group by后的數(shù)量決定是否需要遞歸從初始階段開始執(zhí)行，最終將所有文件merge成一個結(jié)果文件。

在這個過程中，我們也會遇到一些問題，具體的解決方法為：

• 繞開max token：先將內(nèi)容按照max token拆分，形成分類，再進行分類合并。
• 快速處理大量內(nèi)容：將任務(wù)抽象成MapReduce節(jié)點，同一stage節(jié)點可并發(fā)，保障并行度。
• 大模型限速：MapReduce任務(wù)是一個通用的task，針對該task的調(diào)度隊列進行集群統(tǒng)一限速。

最終的業(yè)務(wù)效果如上圖所示。這套新流程的優(yōu)點是成本低，0人工介入，全流程自動；它的缺點也比較明顯，就是比較依賴基礎(chǔ)模型自身對內(nèi)容的理解。

三、自然語言轉(zhuǎn)篩選條件

接下來介紹自然語言轉(zhuǎn)篩選條件部分，這部分面向的場景主要是打包、找人、找內(nèi)容。

在我們的業(yè)務(wù)中，業(yè)務(wù)人員需要根據(jù)條件找到用戶和內(nèi)容。這樣的任務(wù)有以下幾個特點：

• 篩選條件很多。
• 不同條件之間的邏輯組合很多。

根據(jù)以上特點，我們選擇采用大模型微調(diào)的方式來完成任務(wù)，早期我們嘗試過純PE的方式來實現(xiàn)，這種方式雖然簡單，但并不能很好地滿足業(yè)務(wù)需求。我們構(gòu)造的微調(diào)數(shù)據(jù)上圖右半部分的表格所示，我們輸入給模型的問答對是分別是表格中的content列和result列。我們有如下數(shù)據(jù)構(gòu)造的思路：

• 階段一：基于原子條件構(gòu)造篩選條件。
• 階段二：將原子條件完成交并差構(gòu)造篩選條件。
• 階段三：使用模糊語句構(gòu)造篩選條件。
• 階段四：構(gòu)造有明顯邏輯錯誤的篩選條件。

完成這個任務(wù)的過程大致可以分為兩個階段，在第一階段，我們迭代了三個版本。

版本一中我們遇到了輸出和輸入毫不想干的問題。主要的原因是基礎(chǔ)模型缺乏邏輯能力。我們將代碼和數(shù)學(xué)題輸入給模型進行訓(xùn)練，這種方式有效地解決了這個問題。

版本二中我們遇到了兩個問題。首先是JSON截斷問題，主要的原因是max token限制，我們嘗試調(diào)大max token，有效地解決了這個問題；其次是存在輸出重復(fù)的問題，主要原因是進入某一個概率后，相同字詞的概率始終最高，我們使用random sample有效地解決了這個問題。

在版本三中我們主要解決了以下問題：

• JSON格式錯誤，我們構(gòu)造了大量的JSON的樣本。
• 存在額外條件，我們嘗試使用隨機條件組合構(gòu)造樣本。
• 大于小于號錯誤，我們用篩選條件隨機生成多種大于小于的樣本。
• 且或非理解錯誤，我們嘗試隨機組合篩選條件構(gòu)造一批樣本。
• 時間區(qū)間理解成時刻，我們嘗試使用多個時間類篩選條件構(gòu)造一批樣本。
• 條件部分缺失，我們嘗試使用隨機條件組合構(gòu)造樣本。

在訓(xùn)練的過程中，我們遇到了訓(xùn)練速度的問題，我們嘗試調(diào)小epoch，在一定程度上解決了這個問題。

經(jīng)歷了第一階段的迭代，基本可以做到線上可用了，但是我們遇到一個非常吊詭的問題，就是必須要保證訓(xùn)練和推薦在一臺機器上，一旦機器有差異，就會出現(xiàn)異常。在第二階段，我們依然有一些優(yōu)化方向。首先是模糊問題構(gòu)造，我們需要構(gòu)造一批類似“高質(zhì)量創(chuàng)作者創(chuàng)作的優(yōu)質(zhì)大模型回答內(nèi)容”的問題，對大模型進行問題；其次，我們需要定向解決用戶實際使用中的case，根據(jù)用戶實際反饋的問題，生成對應(yīng)的樣本進行微調(diào)。

以上就是我們上線后的效果，主要有三點：

• 降低了使用成本，用戶使用量提升，提高了整體的工作效率。
• 新手友好，很多新同學(xué)同坐自然語言轉(zhuǎn)篩選開始學(xué)會使用這一功能，降低了推廣成本。
• 改變了傳統(tǒng)的新標簽、新特征推廣方式，將新標簽上線后對各業(yè)務(wù)方宣講轉(zhuǎn)變?yōu)樽詣臃g成新標簽的形式，提升了溝通效率，降低了協(xié)同成本。

這個方向的待優(yōu)化點是模糊語言，我們還需要持續(xù)在這個方向上進行探索。

四、自然語言數(shù)據(jù)分析

最后一部分介紹自然語言數(shù)據(jù)分析，這一部分主要是AdHoc分析。

這個任務(wù)主要面臨以下困難和挑戰(zhàn)：

• 如何將多變的自然語言在當(dāng)前場景下轉(zhuǎn)成合適的SQL？
• 如何盡可能地兼容用戶輸入的自然語言？
• 如何保障給負責(zé)當(dāng)前業(yè)務(wù)的同學(xué)看到的一定是當(dāng)前業(yè)務(wù)自身的結(jié)果？

我們使用動態(tài)prompt來解決這個問題。我們早期使用純prompt的方法，這種方法并不能很好地解決業(yè)務(wù)需求，主要原因是ads表太寬，會超過max token的限制，另外few shot固定會忽略查詢語句，效果不好。我們也嘗試使用了微調(diào)的方式，但是這個方法對樣本的要求較高，我們用于微調(diào)的樣本的難度較大。最終，我們決定采用動態(tài)prompt的方式來解決問題。主要流程如下：

初始化：將樣本處理成問題、查詢字段、SQL，將問題轉(zhuǎn)成embedding存入FAISS。

用戶查詢會經(jīng)歷如下的步驟：

• 將問題轉(zhuǎn)成embedding并通過MMR找到類似的問題Top10
• 考慮max token限制生成合適的prompt：
• 綠色：去重后的列名
• 淺藍：查詢的例子
• 深藍：本次用戶的問題

以上是上線后的業(yè)務(wù)效果。當(dāng)然我們也遇到了很多問題，我們也嘗試了各種方法并最終解決了問題。

• 早期使用余弦相似，類似的樣例太多，效果不好。

解法：改用MMR通過多樣性避免prompt輸入不夠。

• 如何盡可能將查詢和數(shù)據(jù)源關(guān)聯(lián)好？

解法：采用產(chǎn)品方案，讓用戶自行選擇用戶需要查詢的數(shù)據(jù)源。

• 用戶輸入的自然語言很泛，如何在這種情況下盡 可能準確的滿足用戶需求？

解法：根據(jù)用戶反饋補充樣本進行優(yōu)化。

目前這種方案還是有一些問題的，準確率不足，當(dāng)前由于分析場景還是很靈活多變的，簡單的case表現(xiàn)還行，但一旦復(fù)雜效果就不好了。未來我們會嘗試fine tune，進一步加強在各業(yè)務(wù)場景的表現(xiàn)效果。

五、總結(jié)與展望

最后，做一下總結(jié)與展望。

在嘗試用大模型解決業(yè)務(wù)問題的過程中，我們發(fā)現(xiàn)了很多痛點：

• PE 工作沒有成熟經(jīng)驗，大家都在摸索，摸著石頭過河。
• max token是一個挑戰(zhàn)，需要設(shè)計很多繞行方案。
• prompt幾乎沒有什么最佳實踐，凡事靠試。
• 會有提示注入的問題。
• 大模型比較慢，且這個問題在復(fù)雜場景下會被放大。
• 數(shù)據(jù)量大或者場景復(fù)雜時沒有高效的框架。
• 構(gòu)造微調(diào)的數(shù)據(jù)缺乏通用的方法和工具，需要仔細思考。

我們針對這個方向也有一些展望：

• 會出現(xiàn)面向大模型復(fù)雜任務(wù)的處理框架。
• 需要有業(yè)務(wù)的想象力，模型能力決定下限，想象力決定上限。

六、Q&A

Q1：事件聚合過程中的大模型如何選型？

A：選擇不同的大模型，都調(diào)整好 prompt 后，批量跑相同的任務(wù)，橫向?qū)Ρ葴蚀_率，根據(jù)最終的結(jié)果，根據(jù)結(jié)果選擇合適的大模型。

Q2：事件聚合的評估手段有哪些？

A：拆分情況分別使用大模型和線上已有模型兩者進行 diff，生成 4 * 100條case，人工評估合理性。

Q3：知識整理場景如和終止迭代？

A：根據(jù)葉子節(jié)點內(nèi)容數(shù)量和最大深度。