我要投稿

赢得企业RAG挑战赛的秘诀 —— 冠军方案剖析与感悟

发布日期：2025-05-26 07:45:12 浏览次数： 1594 作者：瀚海方舟

前不久看到一篇技术博客，是名为 Ilya Rice 的工程师所著（OS：想念另一位Ilya大佬的第N天），文中记录了作者在一次RAG挑战赛中，尝试过的有效方法，及踩过的坑。

最终获得比赛第一名后，吐露真言，有感而发地说出了做好RAG的秘诀：

「细节」

作者虽不是中土人士，但行文洒脱，读后酣畅淋漓，在鱼龙混杂的技术世界中，在企图复制现成框架一劳永逸的浮躁氛围中，其躬身实践，犹如一股清流。故，不禁展开剖析，作以批注、加深理解，望不至狗尾续貂。

（原文、源码都附在文末）

比赛开始

简单来说，此次赛题就是要构建一套问答系统，来针对提问和100份公司年报进行回答，这100份公司年报是PDF格式，最长的达到一千页，示例如下：

（来自https://github.com/trustbit/enterprise-rag-challenge）

整体感知1：公司年报PDF相对来说格式比较稳定，既不像Word排版简单，又不像PPT形式多样，还算比较适中的难度，但图表解析、长文理解也是一大难题，免不了在开头的解析环节费一番功夫。
整体感知2：总量100篇文档在索引环节对工程的压力会小很多。真实世界中的文档格式更加多样，文档数量巨大，技术选型和比赛中的方法一定会有较大差异，需要因地制宜，量体裁衣。

问题类型与评估方式

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

整体感知3：比赛显然简化了评估的难度，但就算是如此简单的规则，作者也提到存在大量的歧义、无法明确定义、模棱两可的问题，为此，作者向比赛组织者提出了几十个问题来明确比赛的评估准则。在现实生活中，问题类型远远不止四类，每个人心中对答案的好与坏也不尽相同，那么大模型该怎么做呢？或者除了大模型，还需要什么样的机制来处理？

万事开头难 —— 文档解析

现在正式开始实操了，面临的第一个问题就是文档解析，有几个关键点罗列一下：

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

（作者说了很多大实话，但需要警惕的是，每个场景要解决的问题不尽相同，只是针对比赛的题目，有以上的技术选型和参数。后续重点是分析问题的思路，而不是把以上方案奉为圭臬）

这里只分析一下关于表格的处理问题，为什么“表格序列化”很好但没有使用？先看看为什么需要做表格序列化：通常表格会被按顺序解析为表头、单元格，而单元格中的值和其垂直、水平标题之间相差了成百上千的token，大模型对这类问题的处理效果很差，如下图所示：

（来自：https://abdullin.com/ilya/how-to-build-best-rag/）

把一张大表格转化为若干组独立的块，每个块的语义是紧密关联的，这个思路就是“表格序列化”，比如把上图中的行列转化为：

subject_core_entity: Shareholders' equityinformation_block: Shareholders' equity for the years from 2012/3 to 2022/3 are as follows: ¥637,422 million (2012/3), ¥535,422 million (2013/3), ¥679,160 million (2014/3), ¥782,556 million (2015/3), ¥540,951 million (2016/3), ¥571,983 million (2017/3), ¥511,242 million (2018/3), ¥525,064 million (2019/3), ¥513,335 million (2020/3), ¥577,782 million (2021/3), and ¥1,274,570 million (2022/3).

使用了“表格序列化”后，作者说“不仅没有提升效果，反而还降低了......在页面上添加更多文本只会降低信噪比”，作者说的“信噪比降低”反映到真实效果上就是：该检索到的表格信息可能可以被检索到，但不该被检索到的表格信息被更大量的检索到了。

不止表格问题，其他问题我们也经常陷入“幸存者偏差”，以为能够针对性解决某类问题，没想到引入了更多的其他问题。归根结底，比赛是看全局分数，是看对所有问题解决的总体得分，但真实世界除了分数，还有哪些因素？

四两拨千斤 —— 检索

还是先罗列要点：

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

—— 这里细节很多，但面对已经被优化了几十年的“检索”系统，上述提到再多细节都不足为道，下面只表达三点感受：

首先，过往优化检索系统绕不开的一个问题是检索精度和耗时的平衡，也就是希望花更少的时间检索到更全面更准确的内容。不得不先提一下，以上策略都是在比赛环境下诞生，作者选择了一种“四两拨千斤”的方式，直接暴力计算相似度，而没有使用HNSW等高深算法，因为对于100篇文档，暴力计算的耗时是可以接受的，所以无需牺牲检索精度。

另外一点是，为什么不用混合搜索，作者说：“在它的最小实现中，它经常降低检索质量而不是提高检索质量。” 我自己的感受是，“混合检索”本身的定位比较尴尬，有点像“多路召回”和“重排序”的合二为一，看作者的表述，继续往这个方向探索收益不大，还不如好好专门研究一下“重排序”。以上两点都体现了避开优化重投入的地方，直击收益高地。

最后就是作者“自创”的LLM重排序算法，其实这个思路很早就有，并且比这个能力还要更强一些。

这里我大胆地挑战一下作者的方案，首当其冲的就是耗时，作者使用30篇候选文档做重排序，如果每篇文档打一次分，那么一条用户请求就要请求30次大模型，看了源码，作者使用了批量评分的思路，假设以3篇文档为一批，那也需要调用10次大模型，这种方法非常依赖模型速度，看文中记录，作者使用的GPT-4o-mini可以达到200万token每分钟，这真的是一个决胜因素。

另外，如果非要使用大模型，只做reranker就太大材小用了，可以作为一个更面向结果的“检索质量评估器”，reranker的缺点是只能评分，不分对错，这一点对于拥有高阶语义判断能力的大模型来说，刚好可以实现，更进一步，可以指导后续流程如何更好地检索。

猛虎与蔷薇 —— 生成

作者针对不同的问题类型写了大量提示词，比如对于数字类问题，模型应该回答"1352000"而非"$1352 (in thousands)"，当然这是为了应付比赛规则和评估准则。另外在前边提到，作者对于模糊的评估准则，和比赛组织者深入讨论后，也都在提示词中进行了大量优化，以指导模型“正确”思考和回答。

除了提示词这一显而易见的优化之外，其他细节点罗列如下：

模块化拼接提示词：提高灵活度、清晰度
缩小搜索空间：由于所有的问题都含有“公司名”，所以在一开始对问题中的公司名进行识别，然后查询时，只查询和该公司名相关联的数据表，可以缩小100倍搜索空间，更重要的是准确率有很大提升
子问题拆解：有些问题涉及多家公司指标的问答，简单的直接检索效果不好，需要将原始问题拆分为多个子问题，逐一检索然后回答
CoT思维链：简单的 Think step by step 是不够的，必须清晰地指导模型如何进行推理。解释推理步骤、目标并提供示例，明确提示模型从不同的角度分析内容
结构化输出 & 自我修复：使用json模式定义各个字段：推理过程、摘要、引用、最终答案，有些模型没有强制json能力，那么需要“回退机制/自我修复机制”，来让模型修复自己出错的json结构体
One-shot：为每个提示词添加了一个【精心设计】的问答示例对
模糊问题的指令优化：同前所述，站在模型角度思考问题，对于模糊的问题，需要澄清其隐含含义

—— 以上每一条看似记录流水账，但都值得细细品味，既有猛虎下山式的工程堆叠魄力，又蕴含细嗅蔷薇般的精心雕琢手法，这里再表达三点感受：

第一点是，模型为人服务，人的定义和评估尤为重要，无论是哪种方法，最终都是让模型回答得【好】。

第二点是，在“通用检索”和“通用生成”之外，是对业务的理解。比如作者发现能够通过识别“公司名”来缩小100倍搜索空间，这条策略对于其他场景来说大概率是无用的，但它背后揭示了元数据过滤为搜索带来的增益。

第三点是，细节、细节、细节。CoT如何一步一步思考、One-shot如何设计问答对、模糊问题如何优化指令，都是在上述第1点的指导方针下，精心设计和落地的，需不辞辛苦，深入骨髓，反复测试。

收尾 —— 系统速度与质量

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

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

Respect ！

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费场景POC验证，效果验证后签署服务协议。零风险落地应用大模型，已交付160+中大型企业