1. 背景
最近比較忙(也有點茫),本qiang~想切入多模態大模型領域,所以一直在潛心研讀中...
本次的更新內容主要是響應圖譜問答整合LLM專案中反饋問題的最佳化總結,對KBQA整合LLM不熟悉的客官可以翻翻之前的文章《LLM應用實戰:當KBQA整合LLM》、《LLM應用實戰:當KBQA整合LLM(二)》。
針對KBQA整合LLM專案,該系列文章主要是透過大模型來代替傳統KBQA的相關功能元件,實現知識圖譜問答,以及如何針對問答效果、多輪對話、響應時間等最佳化工作總結,是妥妥的乾貨篇,感興趣的客官可以持續關注!
本次的主要最佳化點在於如下:
1. 響應時間
專案的驗收標準是流式首字的響應時間在3s內,而當前服務的平均響應時間在5s-7s之間,不符合專案驗收標準。
2. 多輪對話
由於當前多輪對話中的指代消解、預設實體或概念對齊均由大模型處理,由於基座大模型的不穩定性,存在偶現的多輪對話中的物件指代錯誤的情況。
2. 響應時間最佳化
2.1 響應時間統計
基於前文展示的流程圖,針對每個節點進行單次響應時間的統計,結果如下:
模組 |
耗時 |
圖譜初始化 |
558ms(僅第一次會耗時) |
候選schema召回 |
49ms |
對齊prompt呼叫LLM完整響應時間 |
2800ms |
對齊校準 |
15ms |
對話prompt呼叫LLM首字響應時間 |
1800ms |
可以發現兩次呼叫大模型的響應時間耗時基本都在3s,因此重點對LLM呼叫環節進行最佳化。
最佳化方案包括三方面:prompt長度縮減、LLM輸出結果簡化、使用量化版LLM。
2.2 prompt長度縮減
經過分析比對,不同文字長度,LLM的首字響應時間差別較大,尤其是增加安全機制的非公開LLM。
原因也眾所周知,LLM推理過程是基於前文預測下一個token,縱然增加了KV快取機制、FA2機制,較長的prompt首字響應時間必然大於較短prompt,因此可以針對prompt長度進行縮減,以提高LLM首字響應時間。
由於專案中對齊prompt的平均字元長度為5000字左右,且需要等待LLM全部輸出結果後,方才進行後續流程,因此本次最佳化重點最佳化對齊prompt中的示例部分。
提供的fewshot示例大概40+條,且大部分示例和使用者當前問題不相關,因此將fewshot示例向量化進行儲存,當使用者提問時,基於語義相似度將問題與fewshot示例進行pk,篩選出語義相似的10條示例作為對齊prompt中的fewshot,以達到縮減prompt長度的效果。
實驗結果表明,將40條fewshot減小為10條,響應時間提高0.8s左右。
對話prompt沒有進行最佳化,因為對話prompt不需要等待全部結果輸出,只需要首字響應並流式輸出即可。
2.3 LLM輸出結果簡化
LLM輸出結果越長,輸出全部結果的時間就越長,所以針對對齊prompt的輸出長度也做了一些最佳化,雖然響應時間提升不高。
原始對齊prompt呼叫LLM的輸出如下:
(屬性-等於-體重)且(屬性值-等於-最大);(屬性-等於-食性)且(屬性值-等於-肉食性);(概念-等於-恐龍)
主要最佳化點在於:
1) 屬性、實體、概念、屬性值分別用“P”, “E”, “C”, “V”表示
2) 屬性、實體、概念中三元組刪除“等於”
3) 屬性值中的等於用“eq”代替
4) 且、或分別用“&”, “|”表示
因此最佳化後的LLM輸出結果如下:
(P-體重)&(V-eq-最大);(P-食性)&(V-eq-肉食性);(C-恐龍)
2.4 大模型量化
先前使用的非量化版的LLM,更換了INT 8量化版的LLM後,LLM的首響及完整響應時間有了質的提升。
其中對齊prompt完整輸出結果由先前的2.8s提升至1.6s,對話prompt的首響時間由1.8s提升至0.6s。
由於使用的是私有化部署的量化版,中間沒有安全稽核機制,再加上量化的有效推理,所以響應時間提升非常明顯。
2.5 思考
經過上述三方面的最佳化後,平均響應時間2.1s-2.9s之間,滿足專案的驗收標準。但引入的問題還是需要進一步驗證。如prompt輸入長度縮減、LLM輸出結果長度縮減、切換量化版LLM是否引入問答準確性的降低呢?
針對該問題,基於先前整理的測試集,進行測試驗證,準確率層面效果基本保持不變,說明以上最佳化方法有效!
3. 多輪對話效果最佳化
3.1 示例
怎麼辨認慈母龍 |
它有啥能力 |
分佈在那些地方? |
海百合是百合麼? |
那它分佈在哪裡? |
上述示例為多輪問答,在測試驗證中,執行10次該多輪問答,其中會出現2次”那它分佈在哪裡?”中的”它”指代到了”慈母龍”,而非正確的”海百合”,因為對齊prompt呼叫LLM後,輸出了“(E-慈母龍)&(P-分佈區域)”原因當然可以歸咎於LLM的基礎能力不足,但如何進行最佳化呢?
嘗試了兩種方案:a. 對齊prompt中增加歷史參考內容;b. 當前問題與歷史問題透過LLM比較,判定是否二者存在關聯性。
3.2 歷史參考內容
想法也非常簡單,LLM直接針對歷史的問題和答案進行總結,大機率會存在指代不清的問題,那麼如果將歷史的問題以及對應指代的實體或概念作為參考項,提供給LLM,那麼LLM就多了一層參考,進而可以提高指代的準確性。
歷史參考內容引入到對齊prompt部分內容如下:
第一個問題prompt, 歷史輸入為空,ref也為空 |
歷史輸入: ```
```
現在回答: in: 怎麼辨認慈母龍
out: |
第二個問題prompt, 存在第1個問題及實體,當前問題的參考ref為”慈母龍” |
歷史輸入: ``` in: 怎麼辨認慈母龍 ref: 慈母龍 ```
現在回答: in: 它有啥能力 ref: 慈母龍 out: |
第三個問題prompt, 存在第1,2個問題及實體,當前問題的參考ref仍為”慈母龍” |
歷史輸入: ``` in: 怎麼辨認慈母龍 ref: 慈母龍 in: 它有啥能力 ref: 慈母龍 ```
現在回答: in: 分佈在那些地方? ref: 慈母龍 out: |
第四個問題prompt, 存在第1,2,3個問題及實體,當前問題的參考ref也為”慈母龍”,即將之前的實體繼續帶入下一輪,大模型會根據當前問題,結合歷史輸入,進行實體抽取 |
歷史輸入: ``` in: 怎麼辨認慈母龍 ref: 慈母龍 in: 它有啥能力 ref: 慈母龍 in: 分佈在那些地方? ref: 慈母龍 ```
現在回答: in: 海百合是百合麼? ref: 慈母龍 out: |
第五個問題prompt, 存在前四個問題及實體,ref當前為”海百合” |
歷史輸入: ``` in: 怎麼辨認慈母龍 ref: 慈母龍 in: 它有啥能力 ref: 慈母龍 in: 分佈在那些地方? ref: 慈母龍 in: 海百合是百合麼? ref: 海百合 ```
現在回答: in: 那它分佈在哪裡? ref: 海百合 out: |
這樣即使是20輪以上的問答,LLM也能根據當前ref進行分析比較,保障當前問題描述的實體或概念
3.3 當前問題與歷史問題關聯性分析
理論上透過引入歷史參考內容可以有效解決多輪對話中的指代消解問題,但由於LLM本身泛化能力問題,偶爾會出現ref引入錯誤的情況,例如,上述第二個問題,當前的ref引入為”海百合、慈母龍”,如何針對該問題進行最佳化呢?
原因可能是歷史問題存在多個時,大模型偶爾無法按照指令針對歷史問題進行語義分析,因此可以將當前問題與歷史中最後一次出現實體或概念的問題進行關聯性分析,比較是否描述的是同一個物件,進而基於分析結果,將ref中的內容進一步約束。即,如果當前問題與歷史最後一次出現的問題的實體相關時,則引入歷史的實體,否則不引入歷史實體。
舉個例子說明下,”怎麼辨認慈母龍”和”分佈在那些地方?”存在關聯性(預設第二個問題不存在實體,自動引用前一個問題的實體),則ref為”慈母龍”,而”怎麼辨認慈母龍”和”海百合是百合麼?”不相關,則ref中只保留”海百合”。
關聯性分析也是透過prompt呼叫LLM實現,對應的prompt內容如下:
你是一個關於自然博物館的多輪對話的識別器,主要用於識別當前問題與歷史問題是否在討論同一個或一組物件,以便進一步區分多輪對話的邊界,請參考如下要求和示例進行輸出: 1. 輸出只能包含"是", "否",禁止輸出其他內容; 2. 一定要結合歷史的問題,與當前問題進行語義層面分析與比較,判斷當前問題是否有歷史的問題是否在討論同一個或一組物件,如存在指代消解等; 3. 如果輸出為"是",表示當前問題與歷史問題存在關聯性,則表示二者共同; 4. "q"表示問題,"a"表示輸出; 5. 如果當前問題存在"它"或"它們",表示存在指代情況,則輸出"是"; 6. 如果當前問題沒有明確任何詢問的物件,表示預設使用歷史討論的物件,輸出"是"; 7. 如果當前問題存在具體的詢問物件,且與歷史問題不存在指代問題,則輸出"否";
示例如下: ``` 示例 q: 怎麼辨認慈母龍 q: 有啥能力? a: 是 示例 q: 怎麼辨認慈母龍 q: 分佈在那些地方? a: 是 示例 q: 怎麼辨認慈母龍 q: 海百合是百合麼? a: 否 示例 q: 海百合是百合麼? q: 那它分佈在哪裡? a: 是 示例 q: 霸王龍的體長? q: 樑龍有何生活習性? a: 否 ```
現在請根據上述要求及示例,針對以下問題進行關聯性分析: q: {} q: {} a: |
4. 總結
一句話足矣~
本文主要是針對KBQA方案基於LLM實現存在的問題進行最佳化,主要涉及到響應時間提升最佳化以及多輪對話效果最佳化,提供了具體的最佳化方案以及相應的prompt。
讀者可以按照這套方案進行其他KBQA的構建嘗試,如有問題,可私信溝通。