构建高效生产级RAG系统的全方位指南：从数据解析到智能生成
今年以来，我持续进行每日阅读，涵盖学术论文、行业报告以及国内外技术文章。尽管多数内容价值有限，但每周总能筛选出一到两篇极具启发性的文章，例如今日重点探讨的这篇：《How I Won the Enterprise RAG Challenge》。
该文章由 Ilya Abdullin 撰写，是一份关于如何构建最佳RAG系统的详尽指南。其核心观点在于：打造一个高水准的 RAG 系统绝非简单地将用户查询丢给向量数据库并等待大语言模型生成答案。它实际上需要一套精心设计、包含多步骤的架构，深刻涉及数据准备、检索优化以及生成优化等多个层面。
整体阅读体验颇佳，以下是我结合个人实践经验与文章内容所得出的一些思考与见解。
系统架构全景解析
首先，让我们审视该系统的核心架构示意图：
一个优秀的RAG系统本质上是一套精密的工作流程，同时也是一套智能决策系统。它在核心的“检索-生成”链条之外，增设了多个“路由器”与“优化器”模块（对此设计我个人持部分保留态度）：
- 路由决策： 系统首先需要准确判断用户问题应当导向何处寻找答案。
- 检索优化： 在初步获取相关材料后，系统需进一步筛选与排序，以 pinpoint 最相关的信息片段。
- 生成定制： 最后，系统需要根据问题的具体类型与要求，采用最为匹配的策略来生成最终答案。
接下来，我们将遵循Ilya文章中提出的“RAG洋葱模型”，从最外层的基础环节开始，逐步深入到内核的智能决策模块：
讨论至此，不可避免地需要回归到数据准备模块。任何RAG系统的输出质量都高度依赖于其输入数据的质量，因此前文强调核心在于检索与生成链条的观点，我本身便存有疑问。其内在逻辑相当直接：稍微复杂的人工智能系统其逻辑都是相通的，数据工程的质量直接影响提示词工程的效果，而数据处理的质量又决定了数据工程的成败。所以，如果RAG前期数据处理不佳，那么无论后期如何补救，整体效果都难以令人满意。
因此，将非结构化的原始文档（例如WORD、PDF文件）转化为洁净、易于检索的文本块，是一项至关重要且基础的工作…
第一步：文档解析与预处理
文档解析是RAG流程中的首个环节，也是最容易引入错误的阶段。Ilya在尝试了大约二十种不同的解析器后得出结论：没有任何一种解析器能够无损地完美转换所有类型的PDF文档。
他遭遇了各式各样的棘手难题：部分表格被扫描成旋转了90度的图像，解析后文字完全混乱；有些图表由文本层和图片层混合构成，难以完整提取；甚至某些报告文档的字体编码存在问题，视觉显示正常但复制出来后却是无意义的符号。更为极端的情况是，部分文档的文本内容竟采用了凯撒加密，需要特殊解码方能阅读。
他最终选择以Docling作为基础解析器。 为了应对一些复杂场景，他不得不深入其源代码进行定制化修改，以便输出包含丰富元数据的JSON格式，进而生成高质量的Markdown和HTML文档。
这一过程揭示了一个必须正视的现实：在真实的RAG项目中，数据预处理往往占据了超过一半的工作量，并且需要深厚的领域专业知识与工程技巧。
一个比较特别的细节是，由于当时比赛时间紧迫，他还利用了GPU进行解析加速，租用了搭载RTX4090显卡的云服务器。最终，解析100份年度报告共计一万多页的内容耗时约40分钟，这充分展现了工程化思维的重要性。
然而，在实际工作场景中，我们通常不建议采用此类特殊操作。首先，不建议轻易修改解析器的核心源码；其次，除非迫不得已，也不建议进行加速解析，因为项目时间通常相对充裕，无需人为增加技术复杂度，且必须考虑系统后续的移交与维护成本。
在真实的数据处理过程中，必定会遇到各种意想不到的奇葩问题。这里没有捷径可走，唯有秉持“逢山开路，遇水搭桥”的精神，一个个具体问题逐步解决。 每一个小问题本身通常并不复杂，不存在耗时两天都无法解决的情况。此处的关键在于提前暴露并发现问题。
第二步：文本向量化与分块策略
解析完成后的文本需要被切割成更小的“块”才能存入向量数据库。此处的分块策略变得尤为关键：
为了在检索精度与上下文完整性之间取得平衡，Ilya采用了递归分块法，设置了300个token的块大小，并辅以50个token的重叠区域。这种做法确保了语义单元的完整性，同时避免了因块过大而导致关键信息在相似度计算中被稀释。
此外，他对系统进行了远期架构设计，为每个文档（例如每家公司的年报）建立了独立的向量数据库。这背后是效率层面的考量：当用户问题明确指向某家特定公司时，仅在对应的单个数据库中进行搜索，其精度和速度远高于在混合了所有公司数据的庞大向量库中进行全局搜索。
这实际上引入了“路由”概念的雏形：在正式检索之前，先确定搜索的范围。类似的思维策略在国内也有应用，例如树形索引架构也能很好地保持语义独立性：
第三步：检索优化与结果重排
检索是RAG系统中“R”的部分，是整个系统的命脉所在，也是验证前期数据质量好坏的重要标准。如果检索器无法定位到正确答案，那么整个流程可能需要“推倒重来”。
从理论上讲，结合语义搜索与关键词搜索的混合检索模式应当能够提升效果。
但Ilya的实践表明，在未对用户查询进行深度优化的情况下，简单的混合检索有时甚至会降低系统性能。这说明，先进的技术需要正确的使用方式才能发挥效力，否则可能适得其反。
根据过往经验，此处一个比较实用的技巧是问题重写。事实上，一个成熟的系统应该拥有一份自己的预期问题准入清单，或者可以称之为简单的“意图识别”模块。如果没有这份清单，那么系统出错的可能性就较高，即使用户重新措辞提问，也未必能检索出正确答案。
检索之后会得到一个初步的文本块列表，接下来就是应用重排技巧。Ilya的具体做法是：
- 通过向量检索初步召回30个相关的文本块。
- 利用这些文本块的元数据，定位到它们所属的原始页面。
- 将“用户问题 + 页面完整文本”提交给大语言模型，要求模型根据该页面内容对回答问题的帮助程度进行0到1分的打分。
- 将大语言模型的打分与向量搜索的原始分数进行加权融合，最终选出最相关的10个页面。
为了加速这一过程，Ilya让大语言模型一次性同时对三个页面进行评分并返回三个分数。这样，邻近的文本可以互相参照，不仅提高了评分的一致性，也提升了处理效率。最终，通过结合向量相似度分数和LLM评分来计算修正后的相关度，例如可以设定向量权重为0.3，LLM权重为0.7。
这种方法的好处显而易见：它以一种相对低廉的成本（每次查询低于1美分），极大地提升了输入给生成模型的上下文材料的质量。只要数据质量过硬，后续模型的输出质量就有了坚实的基础。
不过，只有在实际应用这种重排策略时，你才会真切感受到管理层对这部分token消耗的密切关注。在某些情况下，效果与成本之间确实难以兼顾，除非在数据工程层面投入更大的精力。换言之：
越是复杂和精细的数据工程，往往会导致后续AI工程也变得复杂，但相应地，也可能催生出成本更低、性能更优的前端用户体验。
第四步：智能路由与答案生成
这部分也是其方法论RAG洋葱模型最核心的组成部分，值得大家重点关注。这也是许多大型AI项目背后的架构设计逻辑，也是我推荐这篇文章的主要原因——它已经勾勒出了一套成熟架构的雏形。这里的核心理念是：
通过智能路由，让问题自动流向其最适合的处理路径。
路由是简化问题、提升系统效率的最有效手段之一。Ilya的系统中设计了两个关键的路由器：
数据库路由： 根据问题中出现的公司名称，直接将其路由到对应的专用向量数据库。
这个看似简单的策略（甚至可以用正则表达式re.search实现），却能将搜索范围从100份文档急剧缩小至1份，带来了性能与精度的双重飞跃。实际上，前文提到的PageIndex也体现了类似的思路：
提示词路由： 比赛要求答案格式严格（例如数字、布尔值、字符串等）。 Ilya没有将所有格式规则塞进一个庞大而臃肿的提示词中，而是为每种答案类型设计了专用的、精简的提示词模板。 系统通过简单的if…else逻辑判断问题所属类型，然后动态选择最合适的提示词，确保大语言模型能够清晰地理解并严格遵守特定类型的输出要求。
特别需要指出的是：这里既可以使用规则引擎进行判断，也可以使用轻量级模型进行判断，具体选择哪种方式并无绝对定论。
当然，上述路由策略主要解决领域内的问题。如果遇到需要跨领域比较的复杂问题，处理起来就会麻烦一些。例如，对于需要比较多个公司数据的问题，系统引入了第三重路由逻辑：
- 首先识别出这是一个复合型问题。
- 使用大语言模型将其拆解为多个独立的子问题（例如“A公司的营收是多少？”和“B公司的营收是多少？”）。
- 每个子问题独立走完标准的RAG全流程（检索、重排等）。
- 最后将所有子问题的答案汇总，交由模型生成最终的综合性答案。
这里值得再次强调的是我之前提到的一个核心观点：能够进行如此设计的前提是：系统所处理的问题类型大多是预设和推演过的，应用场景也是经过充分分析和穷举的。
在经过上述一系列系统而复杂的操作之后，知识从原始PDF文档流入了知识库，又从知识库流入了精心设计的提示词，最终进入了最后一步——模型生成答案。在这一步，Ilya综合运用了多项业界最佳实践： 一、精细化的思维链引导： 不仅仅是简单地要求模型“一步一步思考”，而是通过提示词为模型规划了清晰、结构化的思考路径，特别强调对比问题中提及的指标与上下文中出现的指标是否完全一致。这能有效防止模型“张冠李戴”，是降低“幻觉”产生的关键所在。 例如，当上下文中只提供了“扣折旧后的设备净值”时，模型能够通过理性分析，判断出这并非问题所询问的“研发设备成本”，从而果断地回答“N/A”（不适用）。
二、强制结构化输出：
强制要求大语言模型以指定的JSON格式输出答案，确保了输出的可解析性和系统稳定性。输出中同时包含step_by_step_analysis（逐步分析）和final_answer（最终答案）等字段，既保证了推理过程的透明与可控，又便于程序化提取最终结果。
三、提示词的模块化管理： Ilya采用模块化的方式组织提示词，每个提示词被分解为系统指令、输出格式定义、示例问答对等多个可复用的组件。这种设计便于灵活地“拼装”出适用于不同场景的提示词配置，同时有效控制提示词的长度，减少手动维护的负担。
四、指令打磨与深度融合业务理解： 这是最耗费心力但也最为关键的一环。Ilya深入研究了比赛题目生成器的内在逻辑以及企业年度报告的业务细节，将各种边界情况（例如货币单位转换、职位名称的同义词、数值的单位等）明确地写入提示词指令中。 这告诉我们：一个RAG系统的性能上限，在很大程度上取决于开发者对业务本身的理解深度。 （附注：上述超出预设边界的情况，偶尔也会被模型内化吸收，这也是模型可观测性的一部分。）
至此，基于“RAG洋葱模型”的整个流程，从数据处理到模型生成的主体部分便介绍完毕。通常，当功能实现完成后，讨论的焦点又会回归到成本与性能的平衡上。但性能的瓶颈究竟在哪里？如何优化？这又需要我们回到最初的设计哲学。
第五步：模型选择与系统优化
当时比赛是在2025年3月举行的，大语言模型的迭代速度尚未达到如今的水平，但一个非常值得注意的现象是：在比赛中，Ilya的系统无论是在开源模型还是商用模型上都表现优异！ 例如，Llama 3.3-70B模型的表现几乎追上了OpenAI的GPT-4o-mini，甚至小型的Llama 8B模型也超过了80%的参赛队伍。 这些结果表明，无需盲目追求参数规模更大的模型，只要优化好整个数据处理管道的每一个环节，即使是较小的模型也能取得接近最优水平的性能。
这也就意味着，拥有一套完整的验证数据集和一个可灵活配置的系统至关重要。这使得开发者能够客观量化每一次改进（例如表格序列化策略的优化）所带来的实际效果，避免被主观直觉误导。这种数据驱动的迭代方法，正是工程化思维的核心体现。
说到这里，就需要回归到我们常提及的 AI Max 与 AI Min 的技术选型哲学。只要采用了 AI Min （即轻量级、可控性强）的技术架构，虽然系统整体的复杂度可能会有所上升，但系统的整体可控性以及对第三方模型的依赖性会大大降低。
回顾整个获胜方案，我们可以总结出几条构建生产级RAG系统的核心哲学： 大模型并非银弹，唯有系统化的优化方能取得全局性进步： 胜利并非源自单一的技术突破，而是通过解析、检索、路由、生成等每一个环节的持续迭代与精细打磨。每一个环节微小的改进累积起来，便形成了压倒性的综合优势。 成功路上的拦路虎是一个个具体卡点，每个细节都决定着最终成败： 从PDF解析时遇到的字体编码问题，到提示词中关于数值单位的明确指令，这些看似微不足道的细节，共同决定了系统的最终性能。Ilya的经历证明，在RAG系统中，那些最耗时、最不起眼的“脏活累活”，往往才是成功的关键所在。 系统架构是灵魂所在： 一个优秀的RAG架构应该是可决策、可路由、可灵活配置的。正如“洋葱模型”所揭示的，从基础的数据管道演进到拥有智能路由和优化模块的高级架构，是系统能力实现跃迁的必经之路。冠军系统的架构设计体现了深厚的技术功底与前瞻性的思考。 以评估驱动迭代优化： 拥有一套完整的验证集和一个可灵活配置的系统，能够客观量化每一次改进的实际效果，这是避免被直觉误导、实现持续高效优化的关键。
总结与展望
Ilya 这篇关于RAG的深度文章，我建议每位相关从业者都仔细阅读，因为它非常接近我所接触过的最为复杂的AI工程实践。 他清晰地展示了构建一流的RAG系统是一项复杂的系统工程，它要求我们不仅仅是调用API的工程师，更要成为深入理解业务细节的专家。 我认为文章最有价值的部分在于展示了一种AI架构的可控性哲学：相较于追求一个功能万能但不可控的超大模型，更值得投入精力的是优化各个组件的组合与设计稳定可控的工作流。即使模型本身并不完美，只要在工作流（系统规则）层面做足了功课，依然能够解决许多实际难题。 最后，RAG系统的魔力蕴藏在无数细节之中，希望本文的解析能对各位读者有所启发！