RAG技术正在成为AI应用落地的关键支撑架构。本文系统梳理其核心原理、主流实现方式与行业适配路径配资交流平台，结合医疗等高复杂度场景的真实案例，帮助产品人理解“生成+检索”如何构建可信、可控的智能系统。
如果你想做出一个电商智能客服或者企业知识问答助手，或者想入职加入一家做AI应用的公司，RAG是你必须要去学习的一项技术，RAG技术说难不难，说简单也不简单。
RAG的教程或者文章已经非常多了，甚至我自己也写过一篇万字长文讲解RAG，偏向于整个项目的复盘。
但是我发现小白要真的理解还是比较困难，RAG的知识相对比较枯燥，从20年到现在，RAG架构也是不停的优化和演进，那今天我想带着大家一起扒一扒RAG的面纱，看看它到底是啥。
RAG是什么
小明作为产品经理刚入职一家新公司，领导让他快速熟悉所有产品资料和规章制度。这个时候开始幻想了：要是有一个大模型能够回答所有关于公司资料的问题就好了，解决套娃文档，同事不回，文档看不懂的问题，甚至还有一些历史遗留问题要是也能直接说出来
但是如果他直接问大模型，就会出现这样的回答
模型不知道你的产品，当然也无法给出你解决方案。
通用大模型的其他问题大家应该也都遇到过，比如说：
问问它知不知道现在西瓜的价格
听君一席话，如听一席话
鲁迅有没有写过一篇叫《人工智能论》的文章？
有些大模型天然具有讨好型人格，容易硬着头皮回答你的问题，一顿瞎说，也就出现了幻觉
没有RAG遇到的问题
模型幻觉：模型容易出现幻觉、有套话没细节
知识滞后：知识是老旧、缺失的，缺少你想知道的问答的上下文
黑盒属性：不知道为什么结果是这样，如何推导出来的
为什么会有这些缺点？
本质上源于大模型是静态的、封闭的、概率驱动的黑盒系统，需要经过发布上线这一流程的，每次迭代都需要几个月时间，所以知识时效会存在gap
举个例子：9月发布的模型就不知道10月世界又发生了什么
那么有没有代替方案？
代替方案1-上下文注入ContextStuffing
既然大模型是静态的、不可靠的，那我们能不能绕过它，那能不能每次跟大模型交互的时候我都把文档上传给它，让它根据我上传的文档进行回答。基于这个思路，我们来试试第一个解决方案：上下文注入。
但是聪明的小伙伴已经发现了问题：每次问问题都要上传1次吗？是不是太浪费token了，而且还有很多别的问题
–存在记忆衰减的情况，当问答轮次过多，之前你上传的内容大模型就已经记不住了，只能凭借回忆回答（跟人类还是挺像的）
–文档过长过多（企业里上百页的文档是常态）超过上下文窗口大小，会导致大模型没办法读取全部信息，存在信息缺失
–成本高，每次都要读一下全部的信息再进行回答
代替方案2-微调Fine-tuning
上面的方案不行，我们再换一个，做大模型微调，将专有的知识做处理后，重新训练大模型，让大模型根据最新的语料内容来做生成，这样是不是也可以？当然可以
但不是所有公司都能做，微调也同样存在几个缺点：
–训练费用高、时间长、需要的数据量大
–无法溯源，知识一旦进入大模型的脑子里，就会变得像黑盒一样，你没法知道它是怎么想的
–可能出现灾难性遗忘的风险，当大模型专注学习部分领域的知识，就会遗忘一些他本来就会的能力
微调适合需要非常深厚的专业知识的场景，比如中医/能源/金融等专业领域，推理速度快
RAG从天而降？不，是早就在酝酿
前两个方案我们发现它们虽然能解决一部分问题，但要么太麻烦、要么太昂贵，还都有着无法溯源、容易遗忘的硬伤。
那有没有一种方案，既能让大模型利用我们的私有知识，又能保持低成本和高灵活性，同时还能知道答案是从哪来的呢？
当然有，那就是RAG
RAG（Retrieval-AugmentedGeneration，检索增强生成）是一种结合检索模型和生成模型的人工智能技术。官方定义是：RAG是一种将基于检索的模型和生成模型相结合的技术，通过从外部知识库中检索相关信息来增强生成模型的能力，从而生成更准确、更具事实性的回答。
简单理解一下，RAG就是给了大模型指定的书籍，先去检索相关资料，再根据这些资料生成答案。就是用外部知识增强了大模型的生成能力，这个过程可以最大程度的发挥大模型的创造性、抑制它的黑盒属性，所以也叫检索增强生成。
如此一来，我们就可以只把这几本书管理好，放到我们自有的图书馆里，每次大模型都可以重复使用和查询，只要不停地把新的知识存到图书馆里就好，换任意一款大模型都可以，非常适合企业级落地。
而且大模型非常清晰的知道，什么时候才能说：我不知道这个——当它查不到的时候
另外市面上RAG的技术论文很多，但我们其实就搞懂一篇开山论文的核心内容和发布时间就行，后续所有的RAG架构都是在此之上的改版和优化，就是2020年的《Retrieval-AugmentedGenerationforKnowledge-IntensiveNLPTasks》，它的核心观点就是，借助外部知识让大模型减少幻觉，解决大模型知识更新需要重新训练的缺点。
其实在大模型出现之前，RAG的雏形就已经出现了
RAG是把传统信息检索（IR）+向量检索/嵌入+生成式模型结合在一起使用的。
传统IR就是我们早期在百度搜索时使用的关键词检索技术，它只能根据关键词进行查找，有了向量检索以后，就可以通过语义进行查找相似知识
RAG的大致流程是什么样的？
刚刚我们说到一个复杂的文档可能上百页，其中与用户的问题有关的，可能只有其中的几个页面中的某几段话而已。直接给大模型会超出大部分大模型的上下文窗口（ContextWindow）限制，也就是它一次性阅读和记忆的内容长度。
那我们是不是就可以把大文档拆分一下？把一个大文档拆分成一小块一小块的，这样就可以只看需要的内容
这就是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，而是去想公司里谁、在哪个环节，因为信息利用效率低下感觉很痛苦。怎么找？用访谈&问卷
第二步：量化痛的代价
找到了痛点，接下来就要用数据来衡量它到底有多痛。能让项目从nicetohave（有了更好）变成musthave（必须有）。
举例：通过调研，你发现客服部门有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-SourceRetrieval)：当用户提问时，系统会并行地向所有配置好的检索器发出查询指令。
文档解析
实际的企业知识源五花八门，财务的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的工作流程：QueryRetrieveGenerate。
可能遇到的问题：当任务变得复杂和模糊时，一个只会按部就班的图书管理员就不够用了。我们需要的，是一个能独立思考、规划步骤、甚至会自我反思的项目经理。
这个项目经理，就是Agent。
Agent的核心，是拥有一个能够进行推理和规划的大脑（LLM），以及一个装满各式工具的工具箱。而我们之前构建的RAG系统，就成了它工具箱里最重要的一件工具，等待被Agent调用。
第二阶段：带反思的RAG(Self-CorrectiveRAG)
我们不满足于一次检索就定胜负。我们让Agent在检索后，先不急着生成答案，而是增加一个评估环节。
像以前一样，根据用户问题，先检索出一批文档片段。Agent（大脑LLM）会审视这些检索到的片段，并自问：这些内容真的能回答用户的问题吗？
如果评估结果是能回答，那就进入最后的生成步骤。如果评估结果是不能回答或信息不充分，Agent就会认为第一次检索失败了。它会启动纠错机制。
纠错：Agent会分析失败的原因，并对原始问题进行改写。比如，把模糊的云服务改写成更具体的公司的云服务安全策略是什么？或者公司云服务的成本控制方案有哪些？，然后拿着新问题，重新回到第一步去检索。
通过这个检索-评估-重写的循环，RAG从一条直线，变成了一个可以自我修正的闭环。它变得更聪明、更坚韧，大大提高了检索的准确性，解决了一次定生死的脆弱性问题。
第三阶段：AgenticRAG
现在，我们来挑战个最复杂的问题：对比我们A产品和竞品B的优缺点，并总结我们的市场策略。
带反思的RAG也处理不了，因为它只有一个工具——在自己的知识库里查找。它不知道怎么去网上查竞品信息。这时，就需要我们最顶级的形态—AgenticRAG登场了。
解决思路：我们赋予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将三次查询得到的所有信息，进行最终的总结和润色，形成一份完美的对比分析报告，呈现给用户。
其他：自适应检索(AdaptiveRetrieval/FLARE)
我们之前所有的RAG架构，都遵循一个先查后答的固定模式。也就是说，在LLM开始生成答案之前，我们就必须把所有可能用到的资料都准备好。
但这并不符合人类的思考方式。我们常常是边写边查。当我写到一半，发现需要一个具体的数据时，我才会停下来去查一下，然后再继续写。
那是不是可以让LLM自己来决定何时需要检索，以及需要检索什么。
架构工作流程（以FLARE模型为例）：
主动生成：当用户提出问题后，LLM直接开始尝试生成答案。
预测不确定性：LLM在生成过程中，如果遇到它不确定的、需要外部知识来支撑的地方（比如一个具体的日期、人名、或数据），它会主动生成一个特殊的标记，比如[需要检索]。
暂停与即时检索：当系统检测到这个标记时，会暂停LLM的生成。然后，它会把标记前的那句话作为高度相关的查询，去知识库里进行一次外科手术式的精准检索。
恢复与整合：检索到的新信息会立刻被提供给LLM，然后LLM会恢复它的生成过程，利用刚刚拿到的新知识，继续向下写。这个生成-暂停-检索-恢复的过程会一直持续，直到整个答案生成完毕。
结果：自适应检索让RAG过程变得极其动态和高效。它只在真正需要的时候才去查找信息，并且查询的内容也更具针对性，避免了预先检索可能带来的大量无关信息干扰，让整个流程更加智能和流畅。
总结
到这里，我们一起从0到1构建了一个基础的企业知识库，更重要的是，我们建立了一套解决问题的思维框架。
但这仅仅是开始。
RAG解决的是AI如何更好地利用人类已有知识的问题，而Agent更是重头戏，当我们的AI助手不仅能博览群书，还能主动执行任务、使用工具、自我修正时，一个真正的AI时代才算到来。
希望这篇文章配资交流平台，能成为你通往AGI的坚实一步～
贵丰配资提示：文章来自网络，不代表本站观点。
热点资讯
推荐资讯
