企业RAG挑战赛夺冠秘诀 冠军方案剖析与感悟

前不久读到一篇技术博客，由工程师Ilya Rice撰写，他在文中分享了参与RAG挑战赛的具体可行方法以及踩过的各类坑。最终拿下第一名后，他道出做好RAG的核心秘诀正是「细节」。整篇内容扎实、视角独到，极具启发价值。借此机会，结合他的实践梳理并深入解析关键环节，方便大家理解背后的逻辑。原文与完整代码放在文末。

先说说比赛背景。赛题是构建一个问答系统，面对提问和100份公司年报（PDF格式，最长的超一千页）给出回答。

整体来看，公司年报PDF的格式相对稳定，不像Word那样过于简单，也不像PPT那样形态多变，难度居中。不过图表解析、长文理解依然是绕不开的挑战，解析环节势必耗费不少精力。另外，100份文档对索引构建的压力不大，但真实场景中的文档格式更杂、数量也更大，技术选型必然会更复杂，需要因地制宜。

问题类型与评估规则

问题可能涉及多个PDF才能回答。为了降低评估难度，问题被分为四类：问数字、问是否、问单个名字、问多个名字。评估采用“硬匹配”，总分 = 生成分数 + 检索分数/3。

值得注意的是，即使规则已被简化，作者指出仍存在大量歧义和模糊地带。他为此向组织者提出了几十个问题来明确评估准则。而在现实应用中，问题类型远不止四类，每个人对答案的评判标准也不尽相同。如何让大模型真正理解“好”与“差”？这需要更多机制来支撑。

万事开头难 —— 文档解析

文档解析是第一个硬骨头，有几个关键点值得留意：

1. 解析：作者首先称赞了IBM的docling工具（比赛由IBM赞助），但随即自行补写了一些方法，并用GPU加速。
2. 清洗：写了十几个正则表达式来处理PDF解析错乱，效果仍有不足，最终直接改用OCR。
3. 表格：公司年报中表格数量庞大，行列表头与单元格值之间距离过远，容易切断语义连贯性，从而引发回答错误。作者花了大量篇幅介绍“表格序列化”的思路，但最终并未实际采用。
4. 分块：使用了递归切分器（Recursive Splitter），参数设为300 token + 50 overlap。并未采用高级的语义切分，作者坦言“切分精度对检索系统几乎没有影响”。

这里重点聊聊表格问题——为什么“表格序列化”很好，却没有用起来？

先看为什么需要做表格序列化。通常表格会被按顺序解析为表头、单元格，单元格中的值与垂直、水平标题之间可能相隔成百上千个token，大模型面对此类问题处理效果很不理想，如图所示：

将一张大表格转化为若干组语义紧密关联的独立块，这便是“表格序列化”。例如将图中的行列信息转化为如下形式：

subject_core_entity: Shareholders' equity
information_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).

然而，作者发现用了表格序列化后，“不仅没有提升效果，反而降低了……在页面上添加更多文本只会降低信噪比”。换句话说，该检索到的表格信息可能被检索到，但不该被检索到的信息却大量涌入。不止表格，其他场景也常常陷入“幸存者偏差”：自以为针对性解决某类问题，实际上引入了更多其他问题。最终比赛看的是全局分数，真实世界则还要考虑更多因素。

四两拨千斤 —— 检索

检索部分的关键点如下：

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 reranking算法，思路并不新鲜，甚至存在更强的版本。这里不妨展开聊聊。首先是耗时问题：作者使用30篇候选文档做重排序，若每篇单独打分，一条请求就要调用30次大模型。不过源码中采用了批量评分（如每次3篇），仍需调用10次，非常依赖模型速度。文中记录使用的GPT-4o-mini可达200万token/分钟，这确实是决胜因素。其次，如果非要使用大模型，只做reranker未免大材小用，完全可以将其设计为一种更面向结果的“检索质量评估器”——不仅能评分，还能判断对错，甚至指导后续流程如何更优检索。

猛虎与蔷薇 —— 生成

作者针对不同问题类型撰写了大量提示词。例如数字类问题，模型应回答"1352000"而非"$1352 (in thousands)"——当然，这是为了贴合比赛规则和评估准则。同时，对于模糊的评估准则，作者与组织者深入讨论后，在提示词中作了大量优化，以引导模型“正确”思考和回答。

除了提示词这一直观优化，其他细节罗列如下：

1. 模块化拼接提示词：提升灵活性与清晰度
2. 缩小搜索空间：所有问题均含“公司名”，识别公司名后只查询相关数据表，搜索空间缩小百倍，准确率大幅提升
3. 子问题拆解：部分问题涉及多家公司指标，简单直接检索效果不佳，需拆分为多个子问题逐一检索再回答
4. CoT思维链：简单的"Think step by step"不够，必须清晰指导模型推理步骤、提供目标与示例，明确提示从不同角度分析
5. 结构化输出与自我修复：使用JSON模式定义推理过程、摘要、引用、最终答案。对于不支持强制JSON的模型，设置回退/自我修复机制来修复出错的结构体
6. One-shot：每个提示词配备一个【精心设计】的问答示例对
7. 模糊问题指令优化：站在模型角度思考，对模糊问题需厘清隐含含义

以上每条看似流水账，实则都值得细品。整体来看有三点感受：

第一，模型为人服务，人的定义和评估至关重要。无论用何种方法，最终目标都是让模型回答得【好】。

第二，在“通用检索”与“通用生成”之外，是对业务的理解。例如作者通过识别“公司名”缩小百倍搜索空间，这条策略在其他场景大概率无效，但它揭示了元数据过滤对搜索的强大增益。

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

收尾 —— 系统速度与质量

1. 速度：GPT-4o-mini达200万token/分钟，以25个问题为一批，系统仅用2分钟就完成全部100个问题。速度与质量的权衡是永恒话题。
2. 质量：Llama 3.3 70b仅落后o3-mini几分，即便是小型Llama 8b，整体排名也超过了80%的参与者。开源小模型能逼近商业大模型，与赛题复杂度和精心优化的工程环节密不可分，需辩证看待。

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

Respect ！

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：企业RAG挑战赛夺冠秘诀 冠军方案剖析与感悟要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题