CCF第七屆AIOps國際挑戰賽季軍分享（RAG）

分享CCF 第七屆AIOps國際挑戰賽的季軍方案，從我們的比賽經歷來看，并不會，相反，私域領域問答的優秀效果說明RAG真的很重要

歷經4個月的時間，從初賽賽道第1，復賽賽道第2，到最后決賽獲得季軍，這一路我們團隊收獲了很多實踐經驗，也結識了不少業界的RAG研究者，受益匪淺。應組委會邀請，本文介紹一下我們EasyRAG方案的亮點和實驗結果，歡迎感興趣的朋友批評指正！

開源地址：https://github.com/BUAADreamer/EasyRAG

技術報告：https://github.com/BUAADreamer/EasyRAG/blob/master/assets/技術報告.pdf

PPT：https://github.com/BUAADreamer/EasyRAG/blob/master/assets/PPT.pdf

論文鏈接：EasyRAG: Efficient Retrieval-Augmented Generation Framework for Automated Network Operations

挑戰賽官網：https://competition.aiops-challenge.com/home/competition/1780211530478944282

0.概覽

先簡要介紹背景，本次比賽題目是面向網絡運維領域的私域知識問答，根據LLM的類型分為兩個賽道，賽道一使用可以微調的Qwen2-7B，賽道二調用 GLM-4 API。我們選擇了賽道二，模擬無法微調LLM的場景。

因此，我們的目標是如何在不微調任何模型的前提下，實現較為簡潔的RAG，盡可能達到準確、高效和實用

為了達成這一目標，我們基于llama-index[1]，實現了一套包含查詢改寫、圖像數據處理、分塊策略、元數據利用、密集檢索、稀疏檢索、重排、排序融合、提示詞優化、上下文壓縮、部署的RAG框架，可以靈活地配置自己的RAG流程，方便地應用在自己的私域數據問答中。

初賽RAG流程：塊調優-兩路稀疏/密集檢索粗排-重排-rrf排序融合

復賽RAG流程：塊優化（圖像信息和路徑知識利用）-兩路稀疏檢索粗排-重排-答案迭代優化

在這里插入圖片描述

接下來我們將分別介紹我們在準確性，高效性和實用性方面的實踐和實驗結果，以饗讀者

1.準確性

數據處理流程

zedx文件處理：zedx文件解壓-路徑解析-文檔抽取-保存。
- 關鍵點1：路徑解析中，我們提取了xml文件中的知識路徑（emsplus-安裝與調測-軟件安裝-安裝準備-版本文件準備）和文件路徑（./emsplus/documents/軟件安裝/topics/版本文件準備.html），從而為后續的結合路徑的檢索提供數據支撐
- 關鍵點2：文檔抽取中，我們用bs4提取了html中的文本，同時提取了圖像標題和圖像路徑的一一對應關系，從而方便多模態知識的利用
文本分塊：使用llama-index的Sentence Splitter進行分塊，先利用中文分隔符分割句子，再按照設置的文本塊大小合并多個小塊。
- 關鍵點1：chunk_size和chunk_overlap比較重要，需要精心挑選
- 關鍵點2：節點的node.metadata中的file_path默認為絕對路徑，而句子分割類會利用元數據長度，原始數據放在在不同絕對路徑導致結果差異大，從而使得結果不穩定。因此我們重新實現了分塊類。同時我們也在元數據存儲時，將file_path改為相對路徑，徹底消除絕對路徑帶來的不穩定性。代碼如下

# 原代碼：https://github.com/run-llama/llama_index/blob/8f7cd3e1043da26514ac82fc732cd21bbb4bbe9c/llama-index-core/llama_index/core/node_parser/text/sentence.py#L155C5-L157C62 
def split_text_metadata_aware(self, text: str, metadata_str: str) -> List[str]:metadata_len = len(self._tokenizer(metadata_str))effective_chunk_size = self.chunk_size - metadata_len# 我們的實現：https://github.com/BUAADreamer/EasyRAG/blob/893b3c272b2ce0d8c6cee80f02a171cccded9f96/src/easyrag/custom/splitter.py#L149
def split_text_metadata_aware(self, text: str, metadata_str: str) -> List[str]:metadata_len = len(self._tokenizer(metadata_str))effective_chunk_size = self.chunk_size# 分塊實現：https://github.com/BUAADreamer/EasyRAG/blob/893b3c272b2ce0d8c6cee80f02a171cccded9f96/src/easyrag/custom/transformation.py#L67C1-L71C51
for node in nodes:node.metadata["file_abs_path"] = node.metadata['file_path']file_path = node.metadata["file_path"].replace(self.data_path + "/", "")node.metadata["dir"] = file_path.split("/")[0]node.metadata["file_path"] = file_path

圖像信息抽取：圖像內容提取-圖像過濾
- 例子：有1道題目問的是流程圖（下圖）中POD和VRU的比例，必須解析圖像內容才能予以回答
- 多模態大模型提取內容：
  - glm4v-9b對圖像做caption；提示詞：簡要描述圖像
  - 我們還嘗試了internvl2、gpt4o、claude等多個模型，發現glm4v的效果較好
- 多種規則圖像過濾：
  - 純英文過濾：使用paddleocr提取文字，過濾不含有中文的圖像（純英文圖像的信息可能和文中內容重復或過于復雜）
  - 關鍵詞過濾：標題含有組網圖、架構的復雜圖對問題幫助不大
  - 引用過濾：過濾在文中以特定方式被引用的圖像 (配置如圖 x 所示，文件如圖 x 所示等)，這些圖一般文字已經含有了全部信息

在這里插入圖片描述

RAG流程

查詢改寫：我們嘗試了關鍵詞擴展和HyDE兩種思路，但我們發現直接使用GLM4進行查詢擴展會使得新查詢詞和私域文檔偏差較大，因此在提交方案中沒有采用，詳情參見技術報告
兩路稀疏檢索粗排：基于BM25實現兩路檢索，除了常規的文檔檢索，我們還進行了知識路徑檢索。
- 例子：問題“VNF彈性分幾類？“，VNF 和彈性都可以直接在相關的知識路徑中找到，但在文檔中找不到，此時路徑檢索優勢就很明顯
- BM25分詞：我們發現llama-index對于中文BM25支持較糟糕，因此我們自己實現了基于jieba的中文分詞，相比原實現提點明顯。同時，我們也嘗試了清華的IT詞庫[2]，效果沒有提升
- 停用詞表：使用經典的哈工大停用詞表[3]
密集檢索粗排：基于LLM的embedding模型效果更佳
- 選用阿里的GTE-Qwen2-7B-instruct[4]，在不微調的情況下，此模型在我們的實驗中效果優于bge-v1.5和bce
- 使用qdrant向量數據庫，其官網的docker例子就可以快速部署，簡單高效
- 粗排topk為288
- 索引時將文本塊和文件路徑拼接，再輸入模型得到表征
LLM Reranker 重排：基于LLM的Reranker效果更佳
- 選用智源的bge-reranker-v2-minicpm-layerwise[5]，不微調情況下，此模型效果領先其他bge系列reranker
- 精排topk為6
- reranker推理時將文本塊和知識路徑拼接
多路排序融合：排序融合主要嘗試了naive（去重合并）以及rrf（倒數排序融合）。我們發現重排融合相比粗排融合更有用
- 粗排融合：復賽中我們直接將兩路進行naive融合
- 重排融合：多路分別進行粗排-重排，得到多組文檔集合
  - 生成前融合：多組文檔集合排序融合得到一組文檔集合，輸入LLM
  - 生成后融合：每組文檔集合分別輸入LLM，將多個答案融合。我們嘗試了直接拼接和取最長兩種方式
LLM 回答：簡單問答提示詞最佳
- 我們嘗試了包括CoT提示，以及結構化的markdown提示詞和CoSTAR[6]提示詞，但都沒有超過最原始的官方提供提示詞，然而，考慮到API的波動，此處仍有探索空間，詳情參見技術報告
LLM 答案迭代優化：讓模型逐步關注重要信息
- 我們發現 LLM 對于每個文本塊都會給予一定的注意力，可能會導致 top1 文本塊的有效信息沒有得到充分利用，因此我們設計了兩輪迭代優化，第一輪先基于6個文本塊得到answer1，第二輪將answer1和top1文本塊輸入LLM得到answer2作為最終答案

縮寫描述

這里先對之后實驗表中的一些縮寫做出解釋

在這里插入圖片描述

初賽實驗結果

這里列出我們初賽的提分路徑，主要經歷了3個階段

單路粗排（0-2）
- 官方Baseline跑通（0==>57）
- bge-v1.5實驗（57==>68）
- bm25實驗（68==>69）
單路粗排-精排（3-16）
- 增加基于BERT的重排（69==>73）
- 改為基于LLM的重排模型（73==>77）
- 優化數據處理流程（77==>78）
- 粗排換用bm25或gte-qwen2-7B（78==>81）
- 修改分塊參數（81==>83）
多路融合（17-21）
- 重排后融合（83==>83.5+）

在這里插入圖片描述

復賽實驗結果

由于復賽和初賽評價指標發生了變化，更看重事實正確性，因此稀疏檢索粗排總體更加有效

這里列出我們復賽的提分路徑，主要經歷了5個階段

流程探索（0-4）
- 改為單路稀疏檢索粗排-重排（90==>91.5）
路徑知識利用（5-10）
- 粗排利用文件路徑（91.5==>92.7）
- 重排利用知識路徑（92.7==>93.1）
圖像信息利用（11-12）
- 圖像信息抽取+篩選（93.1==>94.2）
知識路徑檢索（13）
- 加上知識路徑稀疏檢索（94.2==>94.5）
答案迭代優化（14-15）
- 答案整合（94.5==>96+）

在這里插入圖片描述

2.高效性

考慮到實際使用時對速度的要求，我們也實現了一些策略提升推理時延，以下為總的時間開銷比較：

時間開銷：無加速情況下總推理時延為粗排0.2s，重排6s，LLM推理10s
加速時間開銷：加速情況下總推理時延為粗排~0s，重排<4s，LLM推理<8.5s

接下來分別講解三個加速方案

高效稀疏檢索

此部分我們引入了bm25s庫[7]，將稀疏檢索時延降低到可忽略不計，問答效果幾乎無區別
bm25s原理：1.主動索引技術，以空間換時間，在索引時存儲每個token相對于每個文檔的TF并用矩陣存儲，推理時直接將每個詞所在的行取出來；2.高效的scipy矩陣運算

在這里插入圖片描述

高效重排

我們設計了層早退算法，將重排時間降低2s+

動機：我們使用的重排模型bge-reranker-v2-minicpm-layerwise基于LLM設計為可選層模式，即可以選擇較小的層進行推理提高速度。28層效果最佳，一般優于其他層
思路：我們基于簡單query早退，復雜query晚退的思想，設計了類似DeeBERT[8]和FastBERT[9]的動態層早退方法，盡可能逼近原排序效果同時，降低了推理時延
結論：
- 最大相似度閾值選擇算法優于熵閾值選擇算法
- 閾值越大越慢但越準，可根據實際場景選擇相應閾值
- 此處，我們還發現了有意思的一個現象，即選擇算法的比較步驟會帶來無法忽略的開銷，因此我們只在28層之前選擇了三個“斷點”進行閾值判斷，從而盡量做好tradeoff，避免“虛假”優化

在這里插入圖片描述