链载Ai

标题: 赢得企业RAG挑战赛的秘诀 —— 冠军方案剖析与感悟 [打印本页]
作者: 链载Ai    时间: 昨天 18:39
标题: 赢得企业RAG挑战赛的秘诀 —— 冠军方案剖析与感悟

RAG 的魔力在于细节

The magic of RAG lies in the details

Ilya Rice

前不久看到一篇技术博客，是名为Ilya Rice的工程师所著（OS：想念另一位Ilya大佬的第N天），文中记录了作者在一次RAG挑战赛中，尝试过的有效方法，及踩过的坑。
最终获得比赛第一名后，吐露真言，有感而发地说出了做好RAG的秘诀：
「细节」
作者虽不是中土人士，但行文洒脱，读后酣畅淋漓，在鱼龙混杂的技术世界中，在企图复制现成框架一劳永逸的浮躁氛围中，其躬身实践，犹如一股清流。故，不禁展开剖析，作以批注、加深理解，望不至狗尾续貂。
（原文、源码都附在文末）
比赛开始
简单来说，此次赛题就是要构建一套问答系统，来针对提问和100份公司年报进行回答，这100份公司年报是PDF格式，最长的达到一千页，示例如下：
（来自https://github.com/trustbit/enterprise-rag-challenge）

问题类型与评估方式
这些问题可能需要查找多个PDF文档才能够回答，为了让评估结果变得容易，这些问题被分成了4类，即，问数字、问是否、问单个名字、问多个名字。这样看来，评估时只需要“硬匹配”即可，最终总分 = 生成分数 + 检索分数/3

万事开头难 —— 文档解析
现在正式开始实操了，面临的第一个问题就是文档解析，有几个关键点罗列一下：
  1. 解析：作者首先夸奖了IBM的docling工具（比赛由IBM赞助），但肯定不完善，自己重写了一些方法，并用GPU加速
  2. 清洗：写了十几个正则表达式来处理PDF解析错乱的问题，但仍有问题，最终直接用了OCR来做
  3. 表格：公司年报中含有大量表格，由于行列表头和单元格值距离太远导致语义连贯性被打破，进而回答出错，作者花了大量篇幅讲解“表格序列化”是一个很好的思路，但最终没有用
  4. 分块：使用了一种比较常见的Recursive Splitter（递归切分器），参数为300 token + 50 overlap。没有使用高大上的语义切分，“切片的精度对我的检索系统几乎没有影响”……

（作者说了很多大实话，但需要警惕的是，每个场景要解决的问题不尽相同，只是针对比赛的题目，有以上的技术选型和参数。后续重点是分析问题的思路，而不是把以上方案奉为圭臬）
这里只分析一下关于表格的处理问题，为什么“表格序列化”很好但没有使用？先看看为什么需要做表格序列化：通常表格会被按顺序解析为表头、单元格，而单元格中的值和其垂直、水平标题之间相差了成百上千的token，大模型对这类问题的处理效果很差，如下图所示：
（来自：https://abdullin.com/ilya/how-to-build-best-rag/）
把一张大表格转化为若干组独立的块，每个块的语义是紧密关联的，这个思路就是“表格序列化”，比如把上图中的行列转化为：
subject_core_entity:Shareholders'equityinformation_block:Shareholders'equityfortheyearsfrom2012/3to2022/3areasfollows:¥637,422million(2012/3),¥535,422million(2013/3),¥679,160million(2014/3),¥782,556million(2015/3),¥540,951million(2016/3),¥571,983million(2017/3),¥511,242million(2018/3),¥525,064million(2019/3),¥513,335million(2020/3),¥577,782million(2021/3),and¥1,274,570million(2022/3).
使用了“表格序列化”后，作者说“不仅没有提升效果，反而还降低了......在页面上添加更多文本只会降低信噪比”，作者说的“信噪比降低”反映到真实效果上就是：该检索到的表格信息可能可以被检索到，但不该被检索到的表格信息被更大量的检索到了。
不止表格问题，其他问题我们也经常陷入“幸存者偏差”，以为能够针对性解决某类问题，没想到引入了更多的其他问题。归根结底，比赛是看全局分数，是看对所有问题解决的总体得分，但真实世界除了分数，还有哪些因素？

四两拨千斤 —— 检索
还是先罗列要点：
  1. 向量索引使用的是Faiss
  2. 向量模型使用的是text-embedding-3-large
  3. 召回算法使用的是Flat，也就几乎暴力的相似度计算，未使用ANN加速
  4. 混合搜索（向量+BM25）很好，但没用
  5. 没用传统的rerank模型（实在要用，作者推荐jina ai的reranker），而是自己用GPT-4o-mini写了一个LLM reranking算法
  6. 检索到的chunk要关联其所对应的页面（Parent Page Retrieval），因为页面包含的信息更多，上下文语义更丰富

—— 这里细节很多，但面对已经被优化了几十年的“检索”系统，上述提到再多细节都不足为道，下面只表达三点感受：
首先，过往优化检索系统绕不开的一个问题是检索精度和耗时的平衡，也就是希望花更少的时间检索到更全面更准确的内容。不得不先提一下，以上策略都是在比赛环境下诞生，作者选择了一种“四两拨千斤”的方式，直接暴力计算相似度，而没有使用HNSW等高深算法，因为对于100篇文档，暴力计算的耗时是可以接受的，所以无需牺牲检索精度。
另外一点是，为什么不用混合搜索，作者说：“在它的最小实现中，它经常降低检索质量而不是提高检索质量。”我自己的感受是，“混合检索”本身的定位比较尴尬，有点像“多路召回”和“重排序”的合二为一，看作者的表述，继续往这个方向探索收益不大，还不如好好专门研究一下“重排序”。以上两点都体现了避开优化重投入的地方，直击收益高地。
最后就是作者“自创”的LLM重排序算法，其实这个思路很早就有，并且比这个能力还要更强一些。
这里我大胆地挑战一下作者的方案，首当其冲的就是耗时，作者使用30篇候选文档做重排序，如果每篇文档打一次分，那么一条用户请求就要请求30次大模型，看了源码，作者使用了批量评分的思路，假设以3篇文档为一批，那也需要调用10次大模型，这种方法非常依赖模型速度，看文中记录，作者使用的GPT-4o-mini可以达到200万token每分钟，这真的是一个决胜因素。
另外，如果非要使用大模型，只做reranker就太大材小用了，可以作为一个更面向结果的“检索质量评估器”，reranker的缺点是只能评分，不分对错，这一点对于拥有高阶语义判断能力的大模型来说，刚好可以实现，更进一步，可以指导后续流程如何更好地检索。

猛虎与蔷薇 —— 生成
作者针对不同的问题类型写了大量提示词，比如对于数字类问题，模型应该回答"1352000"而非"$1352 (in thousands)"，当然这是为了应付比赛规则和评估准则。另外在前边提到，作者对于模糊的评估准则，和比赛组织者深入讨论后，也都在提示词中进行了大量优化，以指导模型“正确”思考和回答。
除了提示词这一显而易见的优化之外，其他细节点罗列如下：
  1. 模块化拼接提示词：提高灵活度、清晰度
  2. 缩小搜索空间：由于所有的问题都含有“公司名”，所以在一开始对问题中的公司名进行识别，然后查询时，只查询和该公司名相关联的数据表，可以缩小100倍搜索空间，更重要的是准确率有很大提升
  3. 子问题拆解：有些问题涉及多家公司指标的问答，简单的直接检索效果不好，需要将原始问题拆分为多个子问题，逐一检索然后回答
  4. CoT思维链：简单的 Think step by step 是不够的，必须清晰地指导模型如何进行推理。解释推理步骤、目标并提供示例，明确提示模型从不同的角度分析内容
  5. 结构化输出 & 自我修复：使用json模式定义各个字段：推理过程、摘要、引用、最终答案，有些模型没有强制json能力，那么需要“回退机制/自我修复机制”，来让模型修复自己出错的json结构体
  6. One-shot：为每个提示词添加了一个【精心设计】的问答示例对
  7. 模糊问题的指令优化：同前所述，站在模型角度思考问题，对于模糊的问题，需要澄清其隐含含义

—— 以上每一条看似记录流水账，但都值得细细品味，既有猛虎下山式的工程堆叠魄力，又蕴含细嗅蔷薇般的精心雕琢手法，这里再表达三点感受：
第一点是，模型为人服务，人的定义和评估尤为重要，无论是哪种方法，最终都是让模型回答得【好】。
第二点是，在“通用检索”和“通用生成”之外，是对业务的理解。比如作者发现能够通过识别“公司名”来缩小100倍搜索空间，这条策略对于其他场景来说大概率是无用的，但它背后揭示了元数据过滤为搜索带来的增益。
第三点是，细节、细节、细节。CoT如何一步一步思考、One-shot如何设计问答对、模糊问题如何优化指令，都是在上述第1点的指导方针下，精心设计和落地的，需不辞辛苦，深入骨髓，反复测试。

收尾 —— 系统速度与质量
  1. 速度：GPT-4o-mini每分钟200万token，以25个问题为一批进行处理，系统仅用2分钟就完成了全部100个问题（在不同的场景下，有时候我们在平衡速度和质量，有时候我们为了保证一方而牺牲另一方，这是永恒的话题。）
  2. 质量：Llama 3.3 70b仅落后o3-mini几分，即使是小型Llama 8b在整体排名中也超过了80%的参与者（开源小模型为什么能逼近商业大模型，可能和赛题复杂度、精心优化的工程环节有关，辩证看待）

最后的最后，作者坦言：“赢得RAG挑战赛并不是要找到一个神奇的解决方案……RAG的魔力在于细节，你对任务的理解越深入，就越能精准地调整每个组件，即使是最简单的技术，也能让你收益”

Respect ！





欢迎光临 链载Ai (https://www.lianzai.com/) Powered by Discuz! X3.5