★ FEATURED ARTICLE 做过一段时间RAG落地的人应该都有同感这个技术方向迭代速度快得离谱几乎每隔几个月就会有新论文、新框架、新范式冒出来稍微不盯一阵子再看感觉就像换了个赛道。我自己的知识库问答项目就是一路从最朴素的向量检索问答改到混合检索加重排再到模块化的Agent对话系统过程中翻过的车、填过的坑确实不少。这篇算是个人视角的RAG技术演进笔记重点放在中文场景和国内工程社区的实际路径上不聊太多花哨的理论尽量把每个阶段的形态、问题、解法和落地经验讲透。1. RAG出现的根本原因大模型并不天然适合做知识问答1.1 纯生成模型在企业知识场景里的三个硬伤要理解RAG为什么走到今天这一步得先说清楚它解决的是什么问题。大模型最擅长的是“用参数记住世界”但企业知识库的场景恰恰对这一点不友好——模型只知道训练数据截止之前的信息新文档、新政策、新内部资料一概不知道模型对自己的知识过度自信遇到没见过的问题也会一本正经地胡编再就是数据隐私很多企业根本不允许把内部文档送到云上的模型接口去微调。RAG的思路其实特别朴素既然模型记不住、记不准那就别让它硬记干脆给它配一个外部知识库每次回答之前先检索相关资料塞进上下文让它“看着资料说话”。这个思路在2020年就有学术论文提出了但真正大规模走进工程界是在大模型普及之后因为只有大模型足够强RAG的生成质量才能撑起实际业务。1.2 为什么中文技术社区对RAG格外热情国内对RAG的追捧不是偶然的。中文文档形态复杂PDF扫描件、Excel报表、报销单、立项书、会议纪要什么格式都有纯靠通用模型去理解这些内容效果很难保证。更关键的是私有化部署和数据不出域是很多行业的硬性要求微调大模型既贵又慢RAG却可以完全跑在本地连模型都可以用开源权重自己部署。我自己接触过的很多项目甲方一不懂提示词二不会训练模型但他们知道自己有一堆历史文档没人看得过来。RAG对这个需求的匹配度几乎是量身定做数据是自己的、模型是通用的、检索逻辑是透明的。可以说在中国RAG不只是一个技术选型更像是一种必然的落地路径。2. 三代RAG架构的演进逻辑从流水线到可编排系统2.1 朴素RAG标准却脆弱的四段式流程最早落地的RAG架构流程清晰得像教科书先把文档解析成纯文本按固定长度切成片段用向量模型把每个片段编码成向量存进向量库用户提问时把问题也编码成向量在库里做相似度检索取回Top-K片段最后把这些片段和问题拼成提示词扔给大模型生成回答。这套流程我在第一个项目里完整跑通过当时的体验是“Demo惊艳生产冒烟”。Demo里问几个运维手册的问题回答像模像样真到了线上文档一多、格式一杂、问题一变问题就全暴露了。索引阶段PDF里表格解析出来是一团乱码标题层级丢失导致切片把上下文切得稀碎检索阶段用户口语化的提问和文档里书面化的表述对不上向量相似度看着不低但关键信息根本没召回到生成阶段更头疼模型会“参考了但没完全参考”明明给它提供了正确的上下文回答里还是会出现文档里根本没有的内容。朴素RAG之所以“脆弱”在于它假设每个环节都是稳定的文档干净、切片合理、向量表达准确、Top-K总能涵盖答案。只要有一个假设不成立整条链路的回答质量就会明显下滑。这个阶段的代码骨架很简单我当时写的大概长这样from langchain_community.vectorstores import FAISS from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import ChatOpenAI from langchain.prompts import PromptTemplate splitter RecursiveCharacterTextSplitter(chunk_size300, chunk_overlap50) chunks splitter.split_text(clean_text) vectorstore FAISS.from_texts(chunks, embedding_model) docs vectorstore.similarity_search(question, k5) context \n\n.join(doc.page_content for doc in docs) prompt PromptTemplate.from_template(根据以下资料回答问题\n{context}\n问题{question}) print(llm.invoke(prompt.format(contextcontext, questionquestion)))这套代码到今天还能跑但放到真实业务里基本只值60分。原因很简单它把检索、切片、权重都固定死了而现实世界的问题类型、文档类型、表述方式千差万别一成不变的流水线必然扛不住。2.2 进阶RAG在检索前后各加一道优化窗口既然朴素RAG的瓶颈出现在整条链路上自然的发展方向就是在“检索前”“检索中”“检索后”三个环节分别做文章。检索前核心是让问题变得“更可检索”。用户问“去年营收情况怎么样”这条中文表述去向量库检索匹配到的片段往往不够精准但把它改写成“2024年度公司营业收入是多少”命中的概率就高得多。这类查询改写可以用一个小模型做意图识别和关键词抽取也可以用大模型自己生成多个搜索候选。另外一个有效手段是HyDE让大模型先假装回答一遍问题再把那个“伪回答”拿去做向量检索因为伪回答和文档的语言风格更接近召回往往比直接用问题检索更好。检索中重心是召回率和精度的平衡。向量检索擅长语义匹配但对精确词、编号、专有名词不敏感BM25关键字检索对精确词很敏锐但无法处理同义表述。最稳妥的做法是两者都做拿到两路结果后做融合排序。我在项目里常用的融合方式是RRF公式不复杂对每个文档在两个列表里分别找它的名次贡献分是1除以一个常数加上名次分数越高排越前。这个手段不用调权重效果比简单拼接稳定很多。检索之后还得过重排序模型向量检索先召回几十个候选重排模型再精排取前几个进上下文。这一步对最终回答质量的提升非常直接我后面会专门展开。检索后要处理的是“上下文污染”。Top-K片段里可能有一半是重复或无关内容直接全塞给大模型会稀释注意力。可以做相似度阈值过滤、去重、压缩甚至先抽取出和问题强相关的句子再拼进prompt。国内团队的实践里“先粗召回、后精抽取”的策略很常见因为LLM的上下文窗口虽然越来越大但塞进去的噪音越多回答质量越不稳定这个规律在实测里非常明显。进阶RAG相比朴素版的提升本质是把“一次检索”升级为“多个环节的策略组合”。缺点是链路变长每个环节都要调参项目排期也随之膨胀。但如果目标是把回答准确率从及格做到良好以上这些环节几乎一个都不能省。2.3 模块化RAG可编排、可替换、可迭代到了模块化RAG阶段思路彻底变了一个维度不再假设整套架构是固定管线而是把检索、重排、压缩、生成等能力全部抽象成独立模块由一个编排器统一调度。这种做法最大的价值是“可替换”。今天我觉得这个向量模型效果不好换一个只需要改配置明天我想在检索前加一道Query改写不需要动生成逻辑后天我想让Agent自主决定先查文档再查数据库也是配置层面的事。这种灵活性对线上系统极其重要因为RAG的优化注定是持续迭代的不可能一步到位。模块化RAG还引出了两种有意思的玩法。一种是检索规划的显式化系统根据问题的难度和类型自动决定用几条检索路径、是否要拆分子问题另一种是面向Agent的迭代式检索Agent先检索一轮、判断信息不足、生成一个检索计划、再检索一轮直到它认为有足够信息回答为止。算上多轮对话记忆和工具调用这种形态已经不太像传统RAG更像一个带着检索工具自主行动的系统。这也是今天很多生产级知识助手的真实形态。3. 中文场景下RAG绕不开的工程命题3.1 中文文档解析和切片隐形的质量天花板很多RAG项目上线后效果不如预期第一刀砍在解析上。英文网页转纯文本通常很干净中文PDF尤其是扫描件第一步要OCROCR的错字会一路传导到向量检索阶段。表格更麻烦一个跨页的表格被切片器按行切开字段和数值直接对不上检索出来了也是废料。切片的粒度问题同样困扰了我很久。中文没有天然的空格分词边界语义单元只能靠模型或启发式规则来划。如果按固定300字硬切一个完整的技术方案经常被拦腰截断如果切得太长向量化的语义表达会被无关内容稀释检索召回反而不准。我目前的经验值一般文档用200到400字加50字重叠的滑窗结构化表格用按行抽取和表头拼接的方式代码或配置类内容先按代码块切再按行补充。每类文档都要单独设定策略指望一个通用切片器包打天下是在给后面的检索环节埋雷。3.2 混合检索中文召回不能只靠向量中文检索的难点在于“意思一样、说法不同”的情况特别多。文档里写“甲方应在10个工作日内完成验收”用户问“多久能搞定验收”语义上高度相关字面上几乎没有重叠向量模型可以解决这层但用户如果问“验收期限是几天”向量模型反而容易把“10个工作日”和“工作”的相关性做偏BM25却可以精准锁定关键词。这就是为什么混合检索几乎是中文RAG的标配。向量负责语义泛化BM25负责精确匹配两路结果用RRF或加权方式融合能够同时覆盖“换着说法问”和“照着原词问”两类场景。需要注意一个容易踩的问题混合检索召回的结果更容易重复同一份内容可能既在向量结果里又在BM25结果里如果不去重直接拼接会白白浪费上下文窗口。3.3 评测体系幻觉、相关性与召回三者要分开看RAG项目的评测比检索系统复杂得多。早期我只关注“回答相关性”发现分数很高但业务方投诉“回答都是套话、细节全是错的”。后来才把评测拆成几个独立维度忠实度看回答里的每个关键信息是否都能在上下文里找到依据相关性看回答是否针对用户问题上下文相关性和召回率看检索环节本身的质量。评测方式也不能靠人肉打分。用强模型给弱模型的回答打分是常见做法让一个指令理解能力更强的大模型充当裁判对忠实度、相关性、完整性分别打分。但裁判模型本身也有温度参数和位置偏见同一个回答换一下片段顺序分数就可能波动因此评测样本要准备足够多并在固定参数下对比。中文场景尤其要注意“表述宽容度”同一个答案用不同句式写出来忠实度应该一致不能因为表达差异就扣分。4. 一套可以复现的RAG落地实操流程4.1 数据准备先清障再建库数据准备往往占掉整个项目60%的工作量这一点再怎么强调都不过分。第一步是格式转换和清洗扫描件先OCR并人工抽检错字率Word和PDF统一抽出层级结构Excel多Sheet按Sheet分别记录来源绝不做全局拼接。第二步是文档区块拆分标题、段落、表格、图片说明分别走不同的处理管线图片走OCR或视觉模型识别表格走结构化抽取。第三步是切片这一步的结果直接决定后续检索的质量。切片参数不是拍脑袋定的我一般按模型上下文和业务文档特点倒推。比如使用的生成模型上下文是8K切200到400字一次塞6到8个片段是安全的如果生成模型是128K长上下文切片可以放大到600字左右减少片段数量、保留更多原始语境。切片之间的重叠率控制在10%到20%避免关键句正好卡在切片边界上丢失但重叠太多会造成重复片段冗余检索时两个相邻片段同时进入Top-K等于浪费一个位置。4.2 索引和检索的配置细节索引阶段的核心决策是向量模型、向量库和检索策略。向量模型要优先考虑中文语义理解能力和维度。市面上有通用模型也有专门面向中文训练的模型中文效果差距明显特别是专有名词、古文、文言文风格文本。维度则影响存储和检索速度高维度通常表达力强但成本更高。以下是我在不同场景下的取舍经验场景推荐策略备注通用文档问答中等维度向量模型 BM25混检性价比最高兼顾语义和关键词法律/合同等精确词重要低维度向量 强BM25权重关键词命中比语义发散更重要客服/FAQ场景向量 重排序为主候选少重排收益大长文档知识库大切片 重排序 摘要压缩避免上下文溢出向量库的选择上我会优先考察过滤功能和标量字段支持。比如按部门、时间、文档类型过滤是线上系统的刚需有的向量库这个能力很弱高基数过滤时性能会明显劣化。检索策略上全库向量检索在百万级片段下会有响应延迟压力可以先按业务维度过滤缩小范围再做近似检索能省下不少算力。4.3 重排和生成把好最后一道关重排序模型的使用是个关键节点。我的做法是先靠混合检索召回Top-50甚至Top-100个候选然后交给重排模型精排最后只取Top-5到Top-8进生成上下文。实测下来这个步骤对忠实度的提升非常显著尤其当向量检索TOP结果里混入语义相似但不相关的内容时重排能有效把“看起来像但实际不相关”的片段压下去。生成阶段除了写提示词更重要的是约束模型行为和输出格式。我会在prompt里明确“只能依据提供的资料回答资料不足时直接说不知道禁止推测”同时要求回答末尾列出参考来源的片段标识方便业务方做事实核查。引用标注还有一个附带好处用户看到答案是“有出处”的对系统的信任度会提升不少。生成参数同样会影响回答质量。温度设置过高会让模型在资料基础上自由发挥幻觉率明显上升。中文知识问答场景我基本把温度控制在0.1到0.3之间top_p控制在0.8左右。这些参数值不是固定的但低随机性是知识型问答的基本倾向。4.4 评测闭环离线打靶与线上回归一起跑不少团队做完检索和生成就认为项目结束了后面线上出了乱子才发现没有评测抓手。我把RAG项目的评测拆成两层一层是离线评测集迭代另一层是线上效果追踪。离线评测集我一般会准备200到500条问题覆盖几类直接命中问题比如“报销流程是什么”需要推理的归纳问题比如“这两个制度有没有冲突”不该回答的拒答问题比如“公司食堂有什么菜”涉及隐私和模糊诱导的问题。评测集必须有标准答案和资料范围每次改动检索或生成逻辑都要跑同一套评测集对比平均分和分类分。只优化了一类问题、却把拒答能力改差的情况我见过太多次回归测试正是用来防这个的。线上追踪则要记录每次问答的检索片段、重排后进入上下文的片段、最终回答、用户点踩踩赞数据做成一个可回溯的日志体系。线上日志最大的价值是能持续把失败案例沉淀成新的评测用例周复一周地形成正循环。没有这个闭环RAG项目改到后面就是在盲调。5. RAG与周边技术的融合趋势5.1 GraphRAG用关系图谱补上“串联知识”的短板向量检索擅长找“相似内容”但很多问题需要跨节点串联推理。比如问“哪些部门的采购流程涉及法务审批”答案分散在多份文档里单靠相似度检索很难一次性召回。GraphRAG的思路是在文档之上再构建一层实体关系图谱在检索时既走向量相似度又走图结构里的多跳关系把“分散但相关”的知识聚合起来。实际使用GraphRAG时我最大的感触是它的构建成本很高。实体抽取要过一遍大模型关系归并、同实体消歧都是繁琐的活适合知识密度高、关系复杂的领域比如法律条文、技术规范、产品需求文档链条。泛文档问答场景直接上GraphRAG性价比不一定划算常见做法是先把高频问题走图检索普通问题仍然走向量检索。5.2 多模态RAG图片、表格和版面一起进上下文中文企业文档里图表和截图的信息密度往往超过正文。多模态RAG最近的发展方向不是简单OCR转文字而是把版面结构、图表语义、图片说明一起编码进检索和生成链路。比如一个饼图传统RAG只能把OCR识别出的数值串进去而多模态RAG可以让视觉模型理解图的含义把“华东区占比最大”这种高层语义抽出来参与检索和回答。这块的工程复杂度明显更高一是多模态向量化对算力要求更大二是生成模型的图文指令跟随能力仍在快速演进。但从趋势看RAG一定会从“纯文本检索”走向“混合模态检索”尤其是财报、医疗报告、设备手册这类图表密集的文档。5.3 RAG与长上下文大模型之间的竞争与互补长上下文大模型火了之后一直有个争论上下文都到百万级了还需不需要RAG我的观点很明确两者不是替代关系。长上下文解决的是“一个超长文档能不能一次读完”的问题但它解决不了“文档太多、哪一段才是答案”的检索问题也解决不了知识更新的问题——总不能每次文档更新都重新预处理一遍塞进上下文。相反长上下文对RAG是有利的。切片可以放得更大上下文可以容纳更多候选片段重排后的最终输入可以保留更多原始语境。我在长上下文模型上测试过RAG的忠实度明显提高因为模型能看到同一个主题的多个完整段落而不是零碎的句子。RAG负责精准定位长上下文负责充分理解两者搭配才是知识问答的理想形态。6. 我在RAG项目里踩过的一些坑第一个坑是切片粒度拿捏失真。一开始为了检索精准我把切片切到100字左右结果模型每次只看到一小段话回答显得特别碎片化稍微需要上下文串联的问题就直接答偏。后来改成400字加重叠回答完整性才上来。教训是检索精准度再高如果生成侧缺少足够语境结果也是废的。第二个坑是混合检索不做去重就会膨胀。加上BM25之后Top-K里经常出现两个高相似片段内容几乎一模一样白白占了上下文位置。我后来在融合排序之后加了一道基于内容哈希和相似度阈值的去重有效保留了上下文的有效信息密度。第三个坑是评测集只有“正向问题”。早期我只评测常规问答的准确性忘了加入非法问题、越权问题和资料不足的问题结果调优过程中模型从原先的“资料不足就拒答”变成“硬着头皮编”因为评测指标里没有惩罚编造。后来在评测集里加入了20%的拒答样本忠实度分数才回归正常。第四个坑是重排模型的引入时机太晚。我一直以为只要向量检索做得好重排不是必需品结果线上日志里大量失败案例都是“检索到了相关片段但排到很后面没进上下文”。加了重排之后Top-5命中率明显提升回答成功率上了一个台阶。重排收益大、成本不算高建议所有RAG项目都尽早加上。第五个坑是只调RAG不调prompt。有段时间我把全部精力放在检索链路优化上结果回答质量提升有限后来发现生成的prompt里“只能依据资料回答”的约束写得太模糊模型在资料不足时还是容易发挥。把prompt改成明确的分步指令加输出格式约束后同样的检索链路回答的稳定性提升了一大截。RAG是一个系统检索和生成两端都要发力偏废任何一边都走不远。
阅读完成 · 觉得有帮助？
-原型与原型链)
