两年前我第一次认真研究 RAG检索增强生成的时候最大的感受是网上讲原理的文章很多但真正能指导落地的太少。总有人说“把你的知识库接进去就行了”等真上手才发现文档怎么切、向量怎么选、检索结果怎么用、Agent 怎么协同每个环节都是一堆坑。最近把“Awesome-LLM-RAG”这份开源清单重新过了一遍结合我自己做过的几个大模型应用项目把 RAG 原理、AI Agent 实战和落地中的关键细节一起整理出来希望能给正在折腾这类应用的朋友一些有效参考。这篇文章适合这么几类读者一是刚开始接触 LLM 应用开发想搞明白 RAG 到底怎么运作的新手二是已经在做知识库问答、已经买了向量数据库但检索效果总是不理想的项目开发者三是想把 RAG 能力装进 Agent让助手学会“查资料再回答”的进阶玩家。全文只有实践经验不搞纯理论铺陈你跟着走一遍基本能复现出一个可用的 RAG 系统。1. RAG 这项技术到底解决了什么问题1.1 大模型的两大核心痛点知识边角缺失与幻觉泛滥做 LLM 应用的人都知道大模型有两大硬伤知识截止时间和幻觉。知识截止意味着模型没学过的东西就是不会你说破天它也只能瞎编幻觉更麻烦模型会以极度自信的语气说出完全不存在的信息这在企业场景里几乎是致命问题——没有人敢把客服、合规、医疗建议交给一个可能编造内容的黑盒。RAG 的解决思路其实不复杂既然模型不知道那就先检索给你看。把问题拿去问知识库找出最相关的资料片段然后连同问题一起交给模型让它基于这些资料作答。这样模型既获得了实时/私域信息又因为有了明确的“参考依据”而大幅降低胡编概率。简单说RAG 就是给模型开卷考试。1.2 站在 2024 年回看RAG 的边界与适用场景不过要泼一盆冷水RAG 并不是万能的。它解决的是“知识型问题”也就是答案在文档里能找到、需要引用出处的问题解决不了的是“复杂逻辑推理”“多轮深度规划”这类需要模型自己推导的任务。比如“根据我们的产品手册帮我排查订单异常的原因并生成处理报告”这类任务单纯靠 RAG 也能做但效果一般因为它需要多个文档片段组合推理这时候就该和 Agent 结合也是这篇文章后面要重点展开的部分。我建议你一开始就分清目标场景知识库问答、客诉支持、文档解读、合规核查这些是 RAG 的主场复杂任务自动化、多工具协同、动态决策这些让 Agent 来做RAG 在其中当好“资料员”就够了。搞清边界能省下大量调优时间。1.3 从“Awesome-LLM-RAG”清单能学到什么说回这次解析的主角——一个精心收集的 LLM RAG 资源清单。里面整理了从基础论文到最新框架、从数据集到评估工具的完整链路。认真过一遍你会发现RAG 的进化路线非常清晰从早期百花齐放的范式搭建逐步走向工程优化、评估体系、Agent 融合、多模态扩展等深水区。我建议把它当作学习地图而不是收藏夹按“原理 - 组件 - 实战 - 调优”的顺序去读效率会高很多。2. RAG 核心链路拆解从文档切块到生成回复2.1 文档解析与切分策略章节布局比想象中更重要很多人以为 RAG 就是把 PDF 塞进去让程序自动切块实际上文档解析这一步决定了后续检索效果的上限。拿 PDF 举例有些 PDF 是文本型有些是扫描件有些是带复杂表格的报表。扫描件必须先做 OCR表格要转成结构化数据再入库否则向量检索会把表格内容切得支离破碎检索时召回的内容根本没法看。切分策略更要根据文档形态灵活设计对于技术文档我优先按标题层级切分——先识别 Markdown 标题或 PDF 书签结构以章节为单位切块保留上下文对于产品 FAQ直接按一问一答切分对于长报告我会用固定窗口比如 500-800 token配合 10%-20% 重叠避免跨段的信息被截断。切块大小需要做实验太小充满噪声太大又稀释了语义聚焦一般团队从 200-500 token 起步再按测试结果微调。这里有一个很实用的技巧切块后保留元数据。比如文档来源、章节路径、页号、时间戳这些信息可以拼进检索结果让模型知道“这段内容来自哪份文档的哪个章节”生成时引用来源会准确得多。与其事后靠解析回答来猜出处不如入库时就把“户籍”登记好。2.2 向量化与检索embedding 模型、混合检索与重排序切好的文档块要变成向量这一步最容易踩坑。embedding 模型直接决定检索效果的语义精度常用的中文场景可以优先尝试基于开源中文语料训练的向量模型也可以使用闭源接口的向量能力如果领域专业性强法律、医疗、代码最好用领域语料做微调否则通用向量模型很可能“听不懂”你行业里的黑话。检索环节单靠向量检索是不够的。尤其对于产品型号、合同编号、人名这些专有名词向量语义匹配往往不如关键词精确匹配。我建议采用混合检索向量召回 基于 BM25 的关键词召回然后用融合算法把两个结果合并排序。实践中混合检索通常能把首条命中准确率提高 10-20 个百分点这个提升回馈非常大。融合之后还需要做重排序Rerank。向量检索只是初筛召回前 50 条候选然后用相关性更高的重排模型对候选精细打分只保留前 5-10 条。重排模型虽然有点成本但几乎是你投入产出比最高的一个环节。没有重排的 RAG就像光把简历收上来就直接面试效率太低了。2.3 上下文组装与生成提示词工程是最后一道关卡检索结果拼进 Prompt 也需要讲究。用结构化的格式组织检索内容区分来源、标明出处让模型“只根据资料内容回答不要自行发挥”同时明确如果资料没有相关信息要诚实说“未找到”不要硬答。生成参数也要控制温度调到 0.2 以下减少创造性保证事实性。还要注意控制上下文长度。一个常见问题是明明只该用 3-5 个片段为了稳妥把 10 个片段全塞进 Prompt结果模型注意力被稀释回答重点飘忽。代码实现里我会先按阈值动态挑选片段如果某些片段与问题的相似度低于某个值就直接丢弃宁缺毋滥。这一步可以说是从“能跑”到“好用”的分水岭。3. 从 RAG 到 AI Agent真正把能力解放出来的组合3.1 Agent 的分工与思考模式很多朋友刚开始接触 Agent 时会有疑问Agent 不就是调大模型吗为什么要单独学其实 Agent 的核心在于让模型不再只是“生成一句话”而是成为“过程决策者”——它需要理解目标、拆解步骤、选择工具、观察结果并决定下一步动作直到任务完成。用生活化类比就是RAG 是图书管理员你问他问题他帮你找资料、把资料端到你面前Agent 是项目主管他要制定计划让图书管理员、计算器、代码解释器分别干活最后汇总成结果给你。Agent 常见的思考模式是 ReAct 模式即“推理 - 行动 - 观察”循环。模型先思考当前该做什么然后调用某个工具执行接着根据工具返回结果调整下一步计划反复几轮后收敛出最终答案。这个循环能力让 LLM 从“一次性生成器”升级成了“可自主执行的系统”。3.2 实战把 RAG 封装成 Agent 的“文档知识工具”我参与过的一个内部项目目标是构建一个跨部门的智能文档助手需要回答人力资源制度、IT 运维手册、财务报销流程等多个领域的员工问题。纯 RAG 方案最大的痛点是用户问题会跨领域、会追问、会要求流程类操作而不仅仅是“找出资料”。最后我们采用的方案是Agent 作为大脑RAG 作为工具函数。具体流程是第一步Agent 先理解用户意图区分是“知识查询型”“流程操作型”还是“数据查询型”第二步如果是知识查询就调用 RAG 工具——把问题传进去RAG 返回文档片段和来源第三步Agent 根据片段生成回答如果片段不充分Agent 还能主动改写关键词、再检索一轮第四步如果涉及操作流程Agent 调用对应的流程 API 逐步执行。这套组合让系统的上限远高于纯 RAG。实现上我用了带函数调用能力的 LLM 作为核心在工具描述里写明“本工具面向文档知识检索输入问题输出相关片段列表”模型会在需要时自主决定调用。你不需要用商业平台的 Agent 编排功能直接用代码实现一个 ReAct 循环也完全可行关键是工具接口要设计得足够清晰模型才知道什么时候用、怎么用。3.3 Agent 场景下让 RAG 变得更聪明的三个升级技巧Agent 场景里RAG 和传统单轮问答有一个显著区别Agent 的问题可能经过多轮演化检索策略也需要跟着动态调整。第一个技巧是查询改写Query Rewriting。用户第一轮问“报销流程是什么”第二轮可能说“那发票丢了还能报吗”——这里第二轮的“那”其实指的是“报销”直接拿原句去检索很可能召不回正确文档。我会让 Agent 在每轮对话中先结合历史记录把问题补全为完整的独立语句再触发检索。第二个技巧是重检索Recursive Retrieval。Agent 在推理过程中可能会发现自己需要补充信息比如看到“非药物干预”的片段后还想知道“具体包括哪些项目”此时主动发起第二次、第三次检索。这种“边想边查”的循环比一次性回答效果可信得多。第三个技巧是路由Routing。不需要所有问题都走向量检索。简单常识性问题直接让模型回答就行时效性问题走外部 API 或网页检索只有特定文档相关的问题才走 RAG。我给这个意系统设计了意图路由器同时把“是否检索”也交给模型判断既节省了延迟和成本还避免了无关资料干扰模型。4. 工程落地的核心选型与优化实施建议4.1 向量数据库、框架和模型选择依据场景说真话选型要结合团队情况来看。如果你是做 PoC 或者内部工具可以直接用轻量级方案比如基于本地文件系统的向量搜索库加少量代码不一定要上分布式向量数据库。如果你在面向生产环境、有高并发和水平扩展需求就考虑成熟向量数据库产品同时要关注数据一致性、权限隔离、多租户等能力。传统数据库加向量扩展插件也是一个折中选型好处是可以复用已有运维体系。框架选择上我建议不要过度抽象。开源编排框架能帮你快速搭起骨架但也会带来“黑盒式”的依赖。我的做法是核心 RAG 链路自己写文档切分、检索、重排、Prompt 拼接让代码清晰可控框架只用在和外部能力交互的部分比如接入模型服务、管理工具调用。很多业务问题最终都出现在中间环节的自定义逻辑上依赖框架反而不容易定位。模型选择要分层生成模型优先选推理能力强的向量模型按领域与语言适配性选重排模型单独选。不要试图让一个模型干所有事分层专业化才是工程上的好选择。4.2 建立评估体系没有指标的优化都是无头苍蝇这是很多团队最容易忽略的一步。RAG 与 Agent 是个非确定性系统今天改了切块参数明天可能其他场景受影响如果没有量化评估你根本说不清“改动到底是变好还是变坏”。我从自己的项目中总结出一套轻量评估方案先建评测集收集 80-120 条真实用户问题给每条标注理想答案、预期检索片段、预期来源然后每天跑回归评测盯三个指标——检索召回率Top 5 内是否命中关键片段、生成答案准确率人工加模型双向确认、引用正确率生成内容是否引用了正确的来源。有了这套评测机制后续的所有调优才有依据团队协作效率也高很多。在评测集构建上建议用真实用户日志抽取而不是凭空编问题否则很容易“自我感觉良好”。生成答案的准确率判定我用“LLM 辅助评估 抽检人工复核”的方式让一个强模型当评委根据参考答案打分然后每周人工抽检几十条防止误判。这套方式投入低、效果好。4.3 性能、成本与延迟的平衡策略任何生产级 RAG 系统都要面对延迟和成本的双重挤压。检索环节不能每次都全量计算必须有缓存对高频问题做结果缓存设计时把问题和资料包哈希作为 key命中后直接返回。生成环节要控制 Token 消耗系统提示词固定不变检索片段按相关性截断避免长上下文带来的高成本和注意力分散。另外一个平衡点不要为了让“AI 味”更浓而堆叠多轮链式调用。每一步链式调用都意味着延迟成倍增加。能用一次检索解决就不要强行设计两个工具各步骤能并行的尽量并行。实际测试中我们最成功的优化就是把串行的多轮检索改成并行召回不同来源总耗时直接砍掉将近一半。我还建议对每个 Agent 的执行步骤设置超时上限和最大迭代次数防止模型陷入“工具调用 - 报错 - 再调用”的死循环。这既是稳定性要求也是成本控制的基础。5. 常见问题与排查技巧实录5.1 检索不准、召回不全怎么办症状描述用户问“你们支持哪些支付方式”系统中明明有文档但就是召回不到相关片段。我先排查三种可能一是 embedding 模型与你领域语义差距太大可以先换领域微调或更强的通用模型对比二是切块不合理导致关键信息被切散或切进了无意义的段落试着调整切块策略三是专有名词匹配失败可以补上关键词索引用混合检索解决。实践里专有名词问题占比最高强烈建议你优先补 BM25 类关键词检索。5.2 生成内容仍然出现幻觉如果检索片段已经包含答案模型还是瞎编那通常是 Prompt 约束不够或者生成设置过于“自由”。把温度调低同时在系统提示中明确写出只能依据资料内容回答如果资料不充分直接说明“资料中未找到该信息”另外检查资料片段是否互相矛盾如果检索到不同来源的说法冲突模型可能选择综合发挥这时要在 Prompt 里让它逐条列出冲突观点并标注来源。5.3 Agent 场景下的工具选择混乱与循环卡死Agent 明明能调用 RAG 工具却常常拿到无关结果大概率是因为工具描述写得不够清楚。工具描述里要写清楚“什么时候使用、什么时候不使用”比如“仅当问题涉及企业内部文档时调用常识问题不要调用”。在 ReAct 循环中加入最大步数限制并在工具调用异常时让模型直接向上汇报错误而不是反复重试。这类问题我总结出一个排查口诀先看召回后看答先看输入后看参。也就是优先检查用户问题是否被正确改写、检索条件大于生成 Prompt 的影响多数问题都能快速定位。写在最后我给新手的操作建议RAG 与 AI Agent 的结合本质上解决的还是“可信”二字。知识来源可追溯回答内容可校验复杂任务可分解可执行这些能力放到企业应用里都极其考验工程细节而不是简单调用模型接口就能出的“神奇效果”。如果你现在准备从零起步做这样的项目我给你的建议是先做出最小闭环——单文档问答、混合检索、重排、带引用回答——跑通后发现的问题再一点点丰富到 Agent 场景里。我个人在实操中还有一个体会别迷信所谓的最佳实践文档切分多大、重排模型用谁、Agent 要不要接多轮检索这些都要在自己的数据集上测才行。环境不同结论可能完全相反。建议把你的评测集当作最核心的工程资产任何改动跑一遍回归再做定论这是长期收益最高的工作方式。最后一个小技巧——多花时间设计好“工具说明书”一个清晰可读的工具描述比你想尽办法调模型参数更管用。
