360产品展示网站,哈尔滨个人建站模板,邯郸做网站推广的公司,广东 网站建设分享CCF 第七届AIOps国际挑战赛的季军方案#xff0c;从我们的比赛经历来看#xff0c;并不会#xff0c;相反#xff0c;私域领域问答的优秀效果说明RAG真的很重要
历经4个月的时间#xff0c;从初赛赛道第1#xff0c;复赛赛道第2#xff0c;到最后决赛获得季军…分享CCF 第七届AIOps国际挑战赛的季军方案从我们的比赛经历来看并不会相反私域领域问答的优秀效果说明RAG真的很重要
历经4个月的时间从初赛赛道第1复赛赛道第2到最后决赛获得季军这一路我们团队收获了很多实践经验也结识了不少业界的RAG研究者受益匪浅。应组委会邀请本文介绍一下我们EasyRAG方案的亮点和实验结果欢迎感兴趣的朋友批评指正
开源地址https://github.com/BUAADreamer/EasyRAG
技术报告https://github.com/BUAADreamer/EasyRAG/blob/master/assets/技术报告.pdf
PPThttps://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进行分块先利用中文分隔符分割句子再按照设置的文本块大小合并多个小块。 关键点1chunk_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为6reranker推理时将文本块和知识路径拼接 多路排序融合排序融合主要尝试了naive去重合并以及rrf倒数排序融合。我们发现重排融合相比粗排融合更有用 粗排融合复赛中我们直接将两路进行naive融合 重排融合多路分别进行粗排-重排得到多组文档集合 生成前融合多组文档集合排序融合得到一组文档集合输入LLM生成后融合每组文档集合分别输入LLM将多个答案融合。我们尝试了直接拼接和取最长两种方式 LLM 回答简单问答提示词最佳 我们尝试了包括CoT提示以及结构化的markdown提示词和CoSTAR[6]提示词但都没有超过最原始的官方提供提示词然而考虑到API的波动此处仍有探索空间详情参见技术报告 LLM 答案迭代优化让模型逐步关注重要信息 我们发现 LLM 对于每个文本块都会给予一定的注意力可能会导致 top1 文本块的有效信息没有得到充分利用因此我们设计了两轮迭代优化第一轮先基于6个文本块得到answer1第二轮将answer1和top1文本块输入LLM得到answer2作为最终答案
缩写描述
这里先对之后实验表中的一些缩写做出解释 初赛实验结果
这里列出我们初赛的提分路径主要经历了3个阶段 单路粗排0-2 官方Baseline跑通057bge-v1.5实验5768bm25实验6869 单路粗排-精排3-16 增加基于BERT的重排6973改为基于LLM的重排模型7377优化数据处理流程7778粗排换用bm25或gte-qwen2-7B7881修改分块参数8183 多路融合17-21 重排后融合8383.5 复赛实验结果
由于复赛和初赛评价指标发生了变化更看重事实正确性因此稀疏检索粗排总体更加有效
这里列出我们复赛的提分路径主要经历了5个阶段 流程探索0-4 改为单路稀疏检索粗排-重排9091.5 路径知识利用5-10 粗排利用文件路径91.592.7重排利用知识路径92.793.1 图像信息利用11-12 图像信息抽取筛选93.194.2 知识路径检索13 加上知识路径稀疏检索94.294.5 答案迭代优化14-15 答案整合94.596 2.高效性
考虑到实际使用时对速度的要求我们也实现了一些策略提升推理时延以下为总的时间开销比较
时间开销无加速情况下总推理时延为粗排0.2s重排6sLLM推理10s加速时间开销加速情况下总推理时延为粗排~0s重排4sLLM推理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避免“虚假”优化 高效LLM推理
我们设计了上下文压缩方法将LLM推理时间降低1.5s 动机我们首先尝试了llmlingua但发现使用LLM来做压缩会带来额外开销导致推理时延不升反降节省了token但增加了时间开销。 思路因此我们设计了基于BM25相似度的抽取式压缩方法先分句再取出相似度最高的若干句子按原顺序拼接为压缩后上下文 结论 在效果超越llmlingua的基础上我们的模型可以节省更多token和时间阈值越大越慢但越准可根据实际场景选择相应阈值 3.实用性
扩展性我们测试了单张A800的8并发发现平均推理时延从串行16s降低到了7.5s因此初步验证具有一定的可扩展性
部署难度我们支持了简单的命令行部署和docker批量运行几行命令就可以方便地启动一个Web应用 网络运维问答案例 四大名著问答案例
我们还使用四大名著语料[10]测试了框架能否支持通用的语料问答 4.总结
本次比赛我们以不微调任何模型作为自己的目标并在此前提下利用了各种先进模型搭建我们的pipeline做了充分的消融实验达到了比赛中先进的准确度同时也做了一些高效性和实用性方面的尝试
这初步说明一个结论对于垂直领域RAG精心设计流程挑选sota模型流程调优在初期带来的收益可能要大于微调模型。不过我们相信经过微调后的模型可以让我们的pipeline获得更高的效果。希望这个工作能对RAG社区做出一些贡献欢迎各位大佬批评指正
参考
https://github.com/run-llama/llama_indexhttp://thuocl.thunlp.orghttps://github.com/goto456/stopwordshttps://huggingface.co/Alibaba-NLP/gte-Qwen2-7B-instructhttps://huggingface.co/BAAI/bge-reranker-v2-minicpm-layerwisehttps://towardsdatascience.com/how-i-won-singapores-gpt-4-prompt-engineering-competition-34c195a93d41https://github.com/xhluca/bm25shttps://aclanthology.org/2020.acl-main.204/https://aclanthology.org/2020.acl-main.537/https://github.com/weiyinfu/SiDaMingZhu 文章来源https://www.zhihu.com/question/637421964/answer/61089640105
