RAG技术正在成为AI应用落地的关键支撑架构。本文系统梳理其核心原理、主流实现方式与行业适配路径，结合医疗等高复杂度场景的真实案例，帮助产品人理解“生成+检索”如何构建可信、可控的智能系统。如果你想做出一个电商智能客服或者企业知识问答助手，或者想入职加入一家做AI应用的公司，RAG是你必须要去学习的一项技术，RAG技术说难不难，说简单也不简单。RAG的教程或者文章已经非常多了，甚至我自己也写过一篇万字长文讲解RAG，偏向于整个项目的复盘。但是我发现小白要真的理解还是比较困难，RAG的知识相对比较枯燥，从20年到现在，RAG架构也是不停的优化和演进，那今天我想带着大家一起扒一扒RAG的面纱，看看它到底是啥。RAG是什么小明作为产品经理刚入职一家新公司，领导让他快速熟悉所有产品资料和规章制度。这个时候开始幻想了：要是有一个大模型能够回答所有关于公司资料的问题就好了，解决套娃文档，同事不回，文档看不懂的问题，甚至还有一些历史遗留问题要是也能直接说出来但是如果他直接问大模型，就会出现这样的回答模型不知道你的产品，当然也无法给出你解决方案。通用大模型的其他问题大家应该也都遇到过，比如说：问问它知不知道现在西瓜的价格听君一席话，如听一席话鲁迅有没有写过一篇叫《人工智能论》的文章？有些大模型天然具有讨好型人格，容易硬着头皮回答你的问题，一顿瞎说，也就出现了幻觉没有RAG遇到的问题模型幻觉：模型容易出现幻觉、有套话没细节知识滞后：知识是老旧、缺失的，缺少你想知道的问答的上下文黑盒属性：不知道为什么结果是这样，如何推导出来的为什么会有这些缺点？本质上源于大模型是静态的、封闭的、概率驱动的黑盒系统，需要经过发布上线这一流程的，每次迭代都需要几个月时间，所以知识时效会存在gap举个例子：9月发布的模型就不知道10月世界又发生了什么那么有没有代替方案？代替方案1-上下文注入Context Stuffing既然大模型是静态的、不可靠的，那我们能不能绕过它，那能不能每次跟大模型交互的时候我都把文档上传给它，让它根据我上传的文档进行回答。基于这个思路，我们来试试第一个解决方案：上下文注入。但是聪明的小伙伴已经发现了问题：每次问问题都要上传1次吗？是不是太浪费token了，而且还有很多别的问题– 存在记忆衰减的情况，当问答轮次过多，之前你上传的内容大模型就已经记不住了，只能凭借回忆回答（跟人类还是挺像的）– 文档过长过多（企业里上百页的文档是常态）超过上下文窗口大小，会导致大模型没办法读取全部信息，存在信息缺失– 成本高，每次都要读一下全部的信息再进行回答代替方案2-微调Fine-tuning上面的方案不行，我们再换一个，做大模型微调，将专有的知识做处理后，重新训练大模型，让大模型根据最新的语料内容来做生成，这样是不是也可以？当然可以但不是所有公司都能做，微调也同样存在几个缺点：– 训练费用高、时间长、需要的数据量大– 无法溯源，知识一旦进入大模型的脑子里，就会变得像黑盒一样，你没法知道它是怎么想的– 可能出现灾难性遗忘的风险，当大模型专注学习部分领域的知识，就会遗忘一些他本来就会的能力微调适合需要非常深厚的专业知识的场景，比如中医/能源/金融等专业领域，推理速度快RAG从天而降？不，是早就在酝酿前两个方案我们发现它们虽然能解决一部分问题，但要么太麻烦、要么太昂贵，还都有着无法溯源、容易遗忘的硬伤。那有没有一种方案，既能让大模型利用我们的私有知识，又能保持低成本和高灵活性，同时还能知道答案是从哪来的呢？当然有，那就是RAGRAG（Retrieval-Augmented Generation，检索增强生成）是一种结合检索模型和生成模型的人工智能技术。官方定义是：RAG是一种将基于检索的模型和生成模型相结合的技术，通过从外部知识库中检索相关信息来增强生成模型的能力，从而生成更准确、更具事实性的回答。简单理解一下，RAG就是给了大模型指定的书籍，先去检索相关资料，再根据这些资料生成答案。就是用外部知识增强了大模型的生成能力，这个过程可以最大程度的发挥大模型的创造性、抑制它的黑盒属性，所以也叫检索增强生成。如此一来，我们就可以只把这几本书管理好，放到我们自有的图书馆里，每次大模型都可以重复使用和查询，只要不停地把新的知识存到图书馆里就好，换任意一款大模型都可以，非常适合企业级落地。而且大模型非常清晰的知道，什么时候才能说：我不知道这个——当它查不到的时候另外市面上RAG的技术论文很多，但我们其实就搞懂一篇开山论文的核心内容和发布时间就行，后续所有的RAG架构都是在此之上的改版和优化，就是2020年的《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》，它的核心观点就是，借助外部知识让大模型减少幻觉，解决大模型知识更新需要重新训练的缺点。其实在大模型出现之前，RAG的雏形就已经出现了RAG是把传统信息检索（IR）+ 向量检索/嵌入 + 生成式模型结合在一起使用的。传统 IR就是我们早期在百度搜索时使用的关键词检索技术，它只能根据关键词进行查找，有了向量检索以后，就可以通过语义进行查找相似知识RAG的大致流程是什么样的？刚刚我们说到一个复杂的文档可能上百页，其中与用户的问题有关的，可能只有其中的几个页面中的某几段话而已。直接给大模型会超出大部分大模型的上下文窗口（Context Window）限制，也就是它一次性阅读和记忆的内容长度。那我们是不是就可以把大文档拆分一下？把一个大文档拆分成一小块一小块的，这样就可以只看需要的内容这就是RAG流程中的知识预处理。把一份完整的文档，拆解成一个个独立的知识片段（知识1, 知识2, 知识3…），这个过程我们称之为分块，也就是chunk。拆分完成后，当用户提出一个问题时，RAG系统会快速从成千上万个知识片段中，检索出与问题最相关的几个，比如知识1、知识4和知识8。我们把这些预备的文本块和用户提出的问题一起塞到提示词里，大模型就相当于有了上下文，就可以基于这些已知信息回复问题。我们在这个指令里明确地告诉了大模型：用户提问：这是用户的原始问题。查询信息：这是我们从知识库里检索到的、与问题最相关的背景资料。限制条件：这是最重要的规则只允许基于给定的信息进行回答。通过这种方式，大模型就相当于有了一个非常清晰的上下文，它被强制要求在给定的开卷材料范围内回答问题，而不是自由发挥。这样一来，它生成答案的准确性和可靠性就得到了极大的保障。总结下来一个全局视角的RAG知识库如下图那么如何实现这个流程？我们可以把上面的流程拆成两个部分知识库构建：这是准备工作的阶段，就像建造和整理一个图书馆。检索与生成：这是用户提问后的实时工作阶段，就像图书管理员去图书馆查资料给你找答案。不过这只是一个最简单的流程，实际上的企业RAG知识库在落地的时候会遇到非常多问题，也就需要不断的增加或者调整过程节点让检索结果更准确。为什么要用RAG我们已经了解了RAG的技术原理，但技术本身没有价值，能解决真实世界问题的技术才有价值。那么，RAG到底是一把什么样的锤子，我们又该去哪里找合适的钉子呢？RAG解决了什么问题01 时效性：让大模型掌握最新资讯大模型的知识是冷冻的。比如，一个在2023年初训练完成的模型，它对之后发生的所有新产品、新政策、新市场动态都一无所知。想让它了解最新情况？一般来说需要再训练或微调，但等于让一个大学生重新回炉重造，不太现实。有了RAG知识库以后，不需要去改造大模型本身，只需要更新图书馆。今天公司发布了一个新政策？把它写成文档，放进知识库里。明天产品上线了一个新功能？把说明文档加进去。整个过程可能只需要几分钟。02 安全性：在不泄露机密的情况下，利用AI的智慧公司项目最重要的就是数据的安全性，没有人敢把包含核心财务数据、客户隐私、技术专利的文档直接上传给公共大模型。RAG就可以解决这个问题，最核心、最敏感的知识资产（所有原始文档），都存储在你自己内部的、完全私有的知识库里。整个检索过程也都在私有环境中完成。03 低成本：所有公司都用得起的AI微调一个百亿参数的模型，成本动辄大几十万甚至上百万。而搭建和维护一个RAG知识库，成本主要在于向量数据库的存储和计算，通常要低几个数量级。04 可溯源：知识来源于哪一章哪一节我必须知道传统的大模型生成内容，就像一个黑盒子，你不知道它为什么会这么回答，也无法验证答案的真实性。这种不可解释性在金融、法律、医疗等场景下绝对不行的。RAG从根本上改变了这一点。因为RAG的答案是基于从你知识库里检索出的特定原文生成的，所以它可以清晰地告诉你，这个答案来自哪份文档的第几页第几段。RAG的应用场景RAG的应用场景非常非常多，其实它已经成了Agent中不可分割的一部分了，用于管理长期记忆非常可靠的手段之一。对内企业智能知识库： 新员工入职助手、HR/财务/法务政策问答机器人、 IT支持与技术文档查询。销售与市场支持：竞品分析报告生成、市场情报自动汇总、销售话术与案例智能推荐。对外智能客服与售后支持： 7×24小时在线的产品问答、基于用户手册的故障排查向导、订单状态与物流信息查询。电商智能导购：基于用户需求的个性化商品推荐、多款产品对比分析助手。专业领域辅助：金融研究报告分析、法律文书检索与起草辅助、医疗信息查询与鉴别。产品经理重点关注作为产品经理，在推动项目落地时不仅仅是技术的旁观者，而是核心的价值定义者和过程推动者。所以我们的工作不光是在技术上，而是聚焦在：– 定义业务问题：我们要明确，引入RAG是为了解决什么具体问题？是为了降低客服70%的重复问题回答工作量，还是为了让新员工入职培训时间缩短一半？这也是面试时会被深挖的问题。– 规划和管理知识源：RAG系统的上限，取决于你图书馆的质量。我们需要规划哪些知识应该被纳入（产品文档、HR政策、历史邮件等），按照什么样的结构进行分类，并建立一套持续更新和审核知识的机制。– 设计用户体验：用户如何提问？答案如何呈现？来源索引如何清晰地展示？如何引导用户提出更精准的问题？我们需要设计一套流畅、可信的交互流程。– 度量与迭代：项目上线不是终点。我们需要定义成功的标准，比如答案的采纳率、用户的满意度、问题解决率等，通过数据反馈，持续优化检索的精度和生成的效果，了解用什么技术解决什么问题。怎么做RAG知识库首先第一步，先拥有一个知识库1. 定义业务问题作为AI产品专家，你的任务是把技术语言翻译成业务语言，让老板、业务部门一听就懂，一听就觉得这事儿必须干。第一步：找到最痛的场景首先，不要立刻就想我要做个RAG，而是去想公司里谁、在哪个环节，因为信息利用效率低下感觉很痛苦。怎么找？用访谈&问卷第二步：量化痛的代价找到了痛点，接下来就要用数据来衡量它到底有多痛。能让项目从nice to have（有了更好）变成must have（必须有）。举例： 通过调研，你发现客服部门有30人，每人每天花2小时回答关于如何退货的重复问题。30人*2小时/天*22工作日/月*时薪50元=公司每月为这个重复问题付出66000元。2. 规划和管理知识库我们要明确图书馆里要放哪些书。在这个阶段，我们的目标就是把所有相关的资料都收集起来。比如公司的每年的年度汇报、年度计划、产品规划等文档知识范围：我们的图书馆应该包含哪些书？是只有HR政策和产品文档，还是要把历史邮件、会议纪要、甚至聊天记录也加进来？知识结构：如何分类和组织？需不需要打上标签（比如公开资料、内部机密）来实现权限管理？知识生命周期：如何建立一套持续更新和审核知识的机制？谁来负责上传新文档？谁来负责废弃旧版本？如何保证知识的单一事实来源？3. 构建知识库让大模型能根据你的需求生成内容，首先第一步，让它先了解你，所以我们需要提供信息给大模型数据清洗原始文档一般来说都没办法直接使用，因为会存在很多脏数据，比如，PDF的页眉页脚、网页上的广告和导航栏、文档里的格式乱码等。这些都会干扰模型的理解。所以，我们要先把这些无关信息清洗掉，只留下最核心、最干净的文本内容。文本切分这是RAG中非常关键的一步，我们在前面提到为了避免一次性给模型太多信息，也为了更精确地定位答案，我们需要把整篇文档切分成一个个更小的、逻辑上独立的知识片段（也叫Chunk）索引在真正入库之前，我们要给每个切分出的小块都打好标签，分层分类列好全部的内容结构。如果缺少索引，就像你要找一本关于苹果营养价值的书，你把图书馆里每一本书都抽出来看一眼，再决定哪本最相关，浪费时间又消耗精力。那我们可不可以像图书馆管理员一样？把所有的书按照区域存放，当搜索开始时，先在一级分类中快速定位到食物这个大方向，然后看细分水果区域，最后在水果区第三排架位上找到苹果书籍。这个过程避免了查看所有书本，所以速度极快。入库现在，我们有了一堆干净的知识片段和它对应的标签，但它们还只是普通的文本，计算机没法高效地理解和检索它们的含义。所以，神奇的一步来了—向量化。你可以把它理解成文本的数字坐标。经过嵌入模型进行转换，可以把每一段文本都转换成一串由数字组成的向量。意思相近的文本，它们转换出来的向量在空间上的距离也就越近。这就彻底改变了传统搜索的模式。过去我们用关键词搜索，你搜苹果，它只会给你包含苹果两个字的结果。但向量化之后，你搜乔布斯创立的公司，它也能精准地找到那段讲苹果公司的文本，因为它理解了它们在意义上是高度相关的。至此，我们的图书馆就建好了。4. 检索生成接下来要开始进入用户提问、检索生成的环节了query向量化当我们问出问题后，RAG系统要去我们刚刚说的图书馆里找到与我问题相关的知识，第一步就是要先把我的问题也转换成向量，只有都在一个维度，才能通过相似度进行匹配，找到最接近的知识。注意点是：必须使用同一个Embedding模型。如果知识库是用模型A向量化的，而查询是用模型B向量化的，就像一个人用GPS坐标，另一个人用北斗坐标，它们之间无法直接比较，也就找不到正确的位置了。召回系统拿着刚刚生成的问题向量，去向量数据库中搜索。从海量的知识向量中，快速捞出与问题向量在意义上最相近的Top-K个知识片段（Chunks）。（例如，K=10的时候，就是找出最相似的10个知识片段）。召回追求的是快和全（高召回率），宁可错杀一千，不可放过一个。它返回的结果在语义上是相似的，但可能不是每一个都精准地回答了问题。比如，你问苹果，它可能会召回苹果怎么吃、苹果树养护等相关文档片段。重排召回步骤返回了10个可能相关的知识片段，但它们的排序是基于向量距离的，不一定是最优的。重排模型（Reranker）会接管这个列表，用一种更精细的方式重新给它们打分和排序。直接将用户原始问题文本和每一个知识片段的原始文本放在一起，进行深度分析，然后输出一个更精准的相关性分数（例如0到1之间）。生成这是RAG中的最后一步。系统会将用户的原始问题和经过重排后排名最靠前的几个知识片段，打包成一个提示词（Prompt），发送给大模型，大模型根据这些内容做理解和生成。设计用户体验作为产品经理，最重要的还有关注用户体验问题一：怎么让用户知道该问什么并且愿意开口？给出开场白和自我介绍输入框里给点灵感直接把热门问题摆出来当按钮智能联想，猜你想问的问题二：答案怎么呈现，才能让人看得懂而且愿意信？直接给结论展示原文出处推荐更多相关问题ps：支付宝的设计真的很不错问题三：万一AI答错了或不知道，怎么办？诚恳地承认，并给出补救措施设计一个反馈按钮，让用户当老师提供人工通道作为最后保障完善多轮交互，让用户给出方向并继续下一步05衡量效果产品经理必须要关心的知识点，怎么能确定知识库上线后是符合预期，且能解决问题的？评估体系主要围绕三大核心组成的关系展开：用户的问题、检索到的上下文、以及最终生成的答案。还会引入客观事实作为标准。检索质量评估上下文相关性 ：为回答这个问题，找回来的资料里，有多少是真正相关的？用户问年假天数，召回了一堆关于事假规定的文档。上下文召回率：回答这个问题所必需的关键信息，都从知识库里找全了吗？有没有遗漏？问报销流程，只召回了贴发票的规定，但遗漏了系统提交的关键步骤。生成质量评估忠实度：你的回答，是否严格忠实于你找到的参考资料？有没有自己瞎编乱造？召回的原文是年假通常为5天，但生成时为了显得客气，变成了我们有充足的年假，一般是5天起，这就是典型的画蛇添足，违背了忠实度。答案相关性：回答是否正面、直接地回应了用户的核心问题？有没有跑题？用户问如何申请报销，AI回答了报销制度的历史沿革，跑题了。对比黄金标准在更严格的评估中，一般还会准备一套包含问题和标准答案的测试集答案准确率：回答与标准答案相比，准确度有多高？答案完整性：回答与标准答案相比，在信息的详细和完整程度上如何？在真实的企业环境中，企业会使用像RAGFlow、FastGPT这样开箱即用的工具，当然很多有研发能力的团队也会选择使用其他的框架如LangChain进行自研，以获得更高的灵活性和定制化能力。但无论使用哪种工具，核心的原理都是我们今天讲解的这一套流程，产品经理的核心也是不变的。到这里，一个最简单的企业知识库已经完成了，给自己鼓个掌吧！你已经掌握了80%的RAG核心知识，足以应对大部分场景！接下来的内容属于进阶部分，我们会探讨在真实、复杂的工业环境中，前面这套标准流程会遇到哪些挑战，以及业界衍生出的高级玩法。如果觉得有难度，可以先收藏，日后再看。企业知识库落地难点及解决方案落地的时候一定或多或少会出现各种问题，而这些问题我们都按照按照前面梳理的整个流程来归类。多源异构数据企业知识往往来源众多，比如各类系统的数据库、wiki知识库多路召回 (Multi-Source Retrieval)：当用户提问时，系统会并行地向所有配置好的检索器发出查询指令。文档解析实际的企业知识源五花八门，财务的PDF里全是复杂的表格，法务的扫描版合同是图片，还有各种文档的页眉、页脚、错别字等噪音信息，甚至还有领导希望能够把视频逐帧存下来做召回的，现实往往很复杂。采用专业解析工具：使用如Marker, Unstructured.io等工具，能更好地识别和提取表格、图片描述，而不是简单粗暴地抽文本，RagFlow这个平台的优势也是在解析方面做得非常好。文本切分块不能太小，否则一个片段包含的信息不完整，可能会断章取义，比如把一句完整的我爱吃苹果切分成了两段，变成我爱吃苹果，那就不知道你到底爱吃什么了。块不能太大，否则包含了太多无关信息，会干扰模型的判断，增加成本。智能切分：可以按段落、标题等语义边界进行切分，保证每个知识块的逻辑完整性。采用层级RAG：专业解法。后台同时保存子知识块（用于精准检索）和它们所属的父知识块（用于提供丰富上下文）。检索时用小的定位，生成时用大的回答，两全其美。向量化AI有时理解不了公司的行业黑话和产品简称。这是因为通用的Embedding模型（翻译官）没有经过专业训练，无法准确理解这些内部语言的真实含义选择行业模型：选用在特定领域（如金融、法律、中文）表现更好的Embedding模型，如BGE, m3e等。微调Embedding模型：对于要求极高的场景，可以在公司自己的文档上对Embedding模型进行微调。query理解用户的问题总是出其不意。有的很模糊（公司福利怎么样？），有的很复杂（对比A、B产品，并总结我们的市场策略）。如果第一步就没理解对用户的真实意图，后面就全错了。query改写：在用户问题进入系统后，先让一个LLM把模糊问题改写得更具体、清晰，再检索。query拆解：对于复杂问题可以拆解成多个独立的子问题，分别检索后，再汇总答案。(高级)HyDE：让AI先猜一个可能的答案，再用这个假想的答案去检索最相似的原文，有时有奇效。检索召回这是最核心的挑战。有时候答案明明在知识库里，但因为说法不一样，系统就是没找到（召回率低）；有时候，系统找回来一堆看似相关但没用的东西（精度低）混合搜索：业界标配。同时使用语义搜索（向量）和关键词搜索（BM25），既能理解言外之意，又不会放过重要的专有名词。融合RAG：如果知识分散在多个系统（公司文档、外部网站、数据库），可以并行检索所有来源。GraphRAG：对于需要理解关系的复杂问题（比如A的供应商B的竞争对手是谁？），引入知识图谱进行多跳检索内容重排初步检索（召回）回来的候选文档可能多达几十个，质量参差不齐。如果直接都交给LLM，会严重影响最终答案的质量和速度。重排模型 (Reranker)：在召回后、生成前，增加一个精选步骤。用一个更专业的重排模型，对召回的候选文档进行二次打分和排序，选出最精华的Top-K。上下文压缩：如果精选后的内容还是太长，可以再用一个模型进行压缩，提炼核心信息，在不损失意义的前提下，降低LLM的处理成本和时间答案生成这是用户看到的最后一步，也最容易出问题。即使参考资料完全正确，LLM也可能自由发挥、总结跑偏、或者回答的语气和格式不符合要求强化提示工程：给LLM下达命令，比如必须只使用提供的资料回答、如果资料不足，直接回答不知道之类的。强制自我修正：要求LLM的每一句回答都必须附上原文出处。生成答案后，再进行自检是否忠于原文。RAG跟Agent之间的关系RAG作为Agent的一个重要组件，可以为Agent提供知识获取和生成能力；Agent作为RAG的执行者和协调者，可以动态调整RAG的策略，实现高效的用户服务。我们刚刚构建的是一个比较基础的RAG流水线，但是实际企业落地的需求一定是越来越复杂越来越奇怪的，所以RAG技术实际上也在一直不停的发展。第一阶段我们先回顾一下标准RAG的工作流程：Query Retrieve Generate。可能遇到的问题：当任务变得复杂和模糊时，一个只会按部就班的图书管理员就不够用了。我们需要的，是一个能独立思考、规划步骤、甚至会自我反思的项目经理。这个项目经理，就是Agent。Agent的核心，是拥有一个能够进行推理和规划的大脑（LLM），以及一个装满各式工具的工具箱。 而我们之前构建的RAG系统，就成了它工具箱里最重要的一件工具，等待被Agent调用。第二阶段：带反思的RAG (Self-Corrective RAG)我们不满足于一次检索就定胜负。我们让Agent在检索后，先不急着生成答案，而是增加一个评估环节。像以前一样，根据用户问题，先检索出一批文档片段。Agent（大脑LLM）会审视这些检索到的片段，并自问：这些内容真的能回答用户的问题吗？如果评估结果是能回答，那就进入最后的生成步骤。如果评估结果是不能回答或信息不充分，Agent就会认为第一次检索失败了。它会启动纠错机制。纠错：Agent会分析失败的原因，并对原始问题进行改写。比如，把模糊的云服务改写成更具体的公司的云服务安全策略是什么？或者公司云服务的成本控制方案有哪些？，然后拿着新问题，重新回到第一步去检索。通过这个检索-评估-重写的循环，RAG从一条直线，变成了一个可以自我修正的闭环。它变得更聪明、更坚韧，大大提高了检索的准确性，解决了一次定生死的脆弱性问题。第三阶段：Agentic RAG现在，我们来挑战个最复杂的问题：对比我们A产品和竞品B的优缺点，并总结我们的市场策略。带反思的RAG也处理不了，因为它只有一个工具——在自己的知识库里查找。它不知道怎么去网上查竞品信息。这时，就需要我们最顶级的形态—Agentic RAG登场了。解决思路：我们赋予Agent一个大脑和一整个工具箱。RAG（内部知识库检索）只是其中一个工具。工具箱里可能还有：web_search_tool：可以上网搜索的工具。database_query_tool：可以查询公司销售数据库的工具。code_interpreter：可以执行代码、计算数据的工具。Agent的思考与工作流程：当Agent收到这个复杂任务时，会开始像一个真正的项目经理一样思考和规划（这个过程被称为ReAct=Reason + Act）：思考：用户的问题很复杂，我需要把它拆解成几个步骤。第一步，我需要了解A产品的优缺点。这应该在我们自己的知识库里。行动：使用knowledge_base_search_tool，输入查询：A产品的优缺点。观察：工具返回了A产品的相关资料。思考：好了，A产品的搞定了。第二步，我需要了解竞品B的优缺点。这需要上网查。行动：使用web_search_tool，输入查询：竞品B的优缺点分析。观察：工具返回了网络上的几篇评测文章。思考：产品对比信息齐了。第三步，我需要找到我们的市场策略。这肯定也在内部知识库里。行动：使用knowledge_base_search_tool，输入查询：市场策略。观察：工具返回了市场部的PPT。思考：现在，我手上已经有了所有需要的信息。我可以整合这些信息，形成最终的答案了。最终生成：Agent将三次查询得到的所有信息，进行最终的总结和润色，形成一份完美的对比分析报告，呈现给用户。其他：自适应检索 (Adaptive Retrieval / FLARE)我们之前所有的RAG架构，都遵循一个先查后答的固定模式。也就是说，在LLM开始生成答案之前，我们就必须把所有可能用到的资料都准备好。但这并不符合人类的思考方式。我们常常是边写边查。当我写到一半，发现需要一个具体的数据时，我才会停下来去查一下，然后再继续写。那是不是可以让LLM自己来决定何时需要检索，以及需要检索什么。架构工作流程（以FLARE模型为例）：主动生成：当用户提出问题后，LLM直接开始尝试生成答案。预测不确定性：LLM在生成过程中，如果遇到它不确定的、需要外部知识来支撑的地方（比如一个具体的日期、人名、或数据），它会主动生成一个特殊的标记，比如[需要检索]。暂停与即时检索：当系统检测到这个标记时，会暂停LLM的生成。然后，它会把标记前的那句话作为高度相关的查询，去知识库里进行一次外科手术式的精准检索。恢复与整合：检索到的新信息会立刻被提供给LLM，然后LLM会恢复它的生成过程，利用刚刚拿到的新知识，继续向下写。这个生成-暂停-检索-恢复的过程会一直持续，直到整个答案生成完毕。结果：自适应检索让RAG过程变得极其动态和高效。它只在真正需要的时候才去查找信息，并且查询的内容也更具针对性，避免了预先检索可能带来的大量无关信息干扰，让整个流程更加智能和流畅。总结到这里，我们一起从0到1构建了一个基础的企业知识库，更重要的是，我们建立了一套解决问题的思维框架。但这仅仅是开始。RAG解决的是AI如何更好地利用人类已有知识的问题，而Agent更是重头戏，当我们的AI助手不仅能博览群书，还能主动执行任务、使用工具、自我修正时，一个真正的AI时代才算到来。希望这篇文章，能成为你通往AGI的坚实一步～本文由 @思敏（AI产品） 原创发布于人人都是产品经理，未经许可，禁止转载题图来自 Unsplash，基于 CC0 协议