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

首先來介紹下艦橋平臺(tái)。

(相關(guān)資料圖)

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

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

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

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

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

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

二、知識(shí)體系分類整理

下面來具體介紹第一個(gè)場(chǎng)景，即知識(shí)體系的分類整理。

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

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

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

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

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

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

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

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

事件名可以自動(dòng)生成，無需人工介入。準(zhǔn)確率的提升。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上就是我們上線后的效果，主要有三點(diǎn)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、總結(jié)與展望

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

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

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

我們針對(duì)這個(gè)方向也有一些展望：

會(huì)出現(xiàn)面向大模型復(fù)雜任務(wù)的處理框架。需要有業(yè)務(wù)的想象力，模型能力決定下限，想象力決定上限。六、Q&AQ1：事件聚合過程中的大模型如何選型？

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

Q2：事件聚合的評(píng)估手段有哪些？

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

Q3：知識(shí)整理場(chǎng)景如和終止迭代？

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

關(guān)鍵詞：