一、業務現狀和背景

首先來介紹下艦橋平臺。

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

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

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

第二部分針對知乎站內的內容生態建設，我們會利用大模型通過自然語言在推薦系統的基礎上宏觀調控內容生態。

第三部分針對業務分析，利用大模型通過自然語言進行數據分析。

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

二、知識體系分類整理

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

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

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

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

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

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

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

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

這套新方案有以下優點：

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

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

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

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

• 繞開max token：先將內容按照max token拆分，形成分類，再進行分類合并。
• 快速處理大量內容：將任務抽象成MapReduce節點，同一stage節點可并發，保障并行度。
• 大模型限速：MapReduce任務是一個通用的task，針對該task的調度隊列進行集群統一限速。

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

三、自然語言轉篩選條件

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

在我們的業務中，業務人員需要根據條件找到用戶和內容。這樣的任務有以下幾個特點：

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

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

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

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

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

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

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

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

在訓練的過程中，我們遇到了訓練速度的問題，我們嘗試調小epoch，在一定程度上解決了這個問題。

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

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

• 降低了使用成本，用戶使用量提升，提高了整體的工作效率。
• 新手友好，很多新同學同坐自然語言轉篩選開始學會使用這一功能，降低了推廣成本。
• 改變了傳統的新標簽、新特征推廣方式，將新標簽上線后對各業務方宣講轉變為自動翻譯成新標簽的形式，提升了溝通效率，降低了協同成本。

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

四、自然語言數據分析

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

這個任務主要面臨以下困難和挑戰：

• 如何將多變的自然語言在當前場景下轉成合適的SQL？
• 如何盡可能地兼容用戶輸入的自然語言？
• 如何保障給負責當前業務的同學看到的一定是當前業務自身的結果？

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

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

用戶查詢會經歷如下的步驟：

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

以上是上線后的業務效果。當然我們也遇到了很多問題，我們也嘗試了各種方法并最終解決了問題。

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

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

• 如何盡可能將查詢和數據源關聯好？

解法：采用產品方案，讓用戶自行選擇用戶需要查詢的數據源。

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

解法：根據用戶反饋補充樣本進行優化。

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

五、總結與展望

最后，做一下總結與展望。

在嘗試用大模型解決業務問題的過程中，我們發現了很多痛點：

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

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

• 會出現面向大模型復雜任務的處理框架。
• 需要有業務的想象力，模型能力決定下限，想象力決定上限。

六、Q&A

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

A：選擇不同的大模型，都調整好 prompt 后，批量跑相同的任務，橫向對比準確率，根據最終的結果，根據結果選擇合適的大模型。

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

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

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

A：根據葉子節點內容數量和最大深度。