1. 从“聊天机器人”到“智能大脑”AI术语的迷雾与现实如果你最近刷社交媒体、看科技新闻或者只是和同事朋友聊天大概率会频繁听到“LLM”、“Agent”、“RAG”这几个词。它们被包装成各种神奇的概念仿佛有了它们AI就能瞬间无所不能。但当你真正想搞明白它们到底是什么、能做什么、以及对你我这样的普通人或开发者意味着什么时却常常被一堆晦涩的术语和夸张的宣传搞得云里雾里。今天我们不谈那些高深莫测的理论和遥不可及的愿景就从一个最朴素的视角出发把这些概念还原成我们身边看得见、摸得着的工具和逻辑。你可以把这篇内容看作是一位在AI应用一线折腾了挺久的老兵坐下来跟你聊聊这些“热词”背后最实在的东西——它们本质上是什么怎么工作以及最重要的是我们到底该怎么用又该避开哪些坑。简单来说你可以这样理解它们的关系LLM大语言模型是那个“博览群书但可能有点健忘和瞎编”的超级大脑它是所有智能的基石。Agent智能体是给这个大脑配了一个“秘书”和“手脚”让它能按计划做事、使用工具、与人交互。RAG检索增强生成则是给这个大脑配了一个“超级外接硬盘和事实核查员”让它回答问题时能随时查阅最新、最准确的资料减少胡言乱语。接下来我们就一层层剥开这些概念的外壳看看它们的内核。2. LLM大语言模型——AI的“基础脑力”与它的天生局限2.1 核心原理它真的在“理解”吗让我们先抛开所有光环用最直白的方式解释LLM。你可以把它想象成一个在互联网规模文本上完成了“终极填字游戏”训练的超级学生。它读过的书、文章、网页、代码可能比一个人几辈子看的都多。它的核心能力是根据上文预测下一个最可能出现的词是什么。比如你输入“今天天气真”它根据海量数据统计发现“好”、“不错”、“热”等词出现的概率极高于是它就可能输出“好”。这个过程层层递进就生成了一整段话。所以LLM的“智能”本质上是基于统计规律的模式匹配和序列生成而不是人类意义上的逻辑推理或真正理解。这导致了它的几个核心特点知识丰富但可能过时它的知识截止于训练数据的时间点例如GPT-4可能是2023年初。它不知道这之后发生的任何事情。擅长生成与模仿不擅长精确计算与事实核查它能写出文笔优美的文章但让它算“3527乘以148”它可能会瞎编一个看起来合理的数字。它也会自信地编造看似真实但完全不存在的信息即“幻觉”。没有记忆和持续状态每次对话对于标准的LLM来说都是一次全新的开始尽管技术上可以通过传入历史对话文本来模拟上下文但有长度限制。注意很多人误以为LLM连接了互联网或拥有实时数据库。实际上在纯聊天模式下它只是在“回忆”训练时学到的东西。它的“知识”是静态的、凝固的。2.2 实际应用中的“能”与“不能”基于以上原理我们就能更理性地看待LLM能做什么不能做什么。它擅长的事情可以放心使用的场景创意与内容生成写邮件、大纲、故事、诗歌、营销文案。这里追求的是流畅度和创意而非100%的精确事实。文本转换与概括将一段技术语言转换成小白能懂的话总结长篇文章的核心要点翻译不同风格的文字。代码辅助根据注释生成代码片段、解释一段代码的功能、在不同编程语言间转换语法。它见过无数代码模式这是它的强项。开放式问答与头脑风暴探讨一个概念、提供各种点子、从不同角度分析问题。这类问题没有唯一正确答案适合LLM发挥。它不擅长或高风险的事情需要警惕或必须辅助的场景提供实时、动态信息比如“今天某支股票股价是多少”、“刚刚发布的某政策原文是什么”。它给的信息很可能是过时或编造的。进行精确的数学、逻辑运算虽然简单计算可能蒙对但复杂的、多步骤的运算不可靠。给出涉及专业、法律、医疗的精确建议它可能混合正确信息和编造信息给出听起来合理但危险的建议。需要深度理解特定、私有领域知识比如你公司内部的规章制度、产品手册、未公开的会议纪要LLM根本没见过这些资料。理解了LLM的这些天生局限我们就会明白为什么需要Agent和RAG来补足它的短板让它从一个“聪明的聊天者”进化成一个“可靠的实干家”。3. Agent智能体——为LLM装上“手脚”与“计划本”当LLM自己搞不定一件事时Agent就登场了。你可以把Agent理解为一个以LLM为“大脑”或“决策中心”的自动化程序。这个程序不仅能理解你的指令还能自己规划步骤、调用各种工具API、函数、搜索引擎等、并持续执行直到完成任务。3.1 Agent的核心工作流思考、行动、观察一个典型的Agent工作流就像一个自律的项目经理规划LLM大脑分析用户目标如“帮我查一下本周北京飞上海最便宜的航班并总结天气情况”。它将大目标拆解成可执行的子任务[任务1: 搜索航班信息 任务2: 搜索北京天气 任务3: 搜索上海天气 任务4: 整合信息生成报告]。执行Agent根据规划依次调用对应的工具。调用搜索工具查询航班API。调用天气工具查询两地天气API。观察获取工具返回的结果可能是JSON数据、网页文本等。迭代LLM大脑“观察”这些结果判断任务是否完成。如果完成了就生成最终答案如果没完成比如第一次搜索没找到合适航班就重新规划或调整参数继续执行。这个“规划-执行-观察-迭代”的循环是Agent区别于简单问答的核心。3.2 关键组件让Agent真正“动”起来一个功能完整的Agent通常包含以下几个部分组件角色类比实例规划器拆解任务制定步骤项目总监将“做一顿晚餐”拆解为“查菜谱、买食材、洗切、烹饪”。工具集Agent可调用的外部能力工具箱搜索引擎API、计算器、数据库查询函数、文件读写接口、邮件发送服务。记忆模块存储对话历史、工具执行结果工作笔记记住用户说过不喜欢香菜上次查询的航班号任务执行的中间状态。执行引擎协调各组件按步骤运行流水线调度按顺序调用工具处理异常管理整个循环流程。3.3 实操心得构建一个简单Agent的避坑指南假设我们要用Python借助LangChain、AutoGen等框架构建一个能查询天气并给出穿衣建议的简单Agent以下是一些血泪教训1. 工具定义要精确且安全给LLM的工具描述必须清晰无歧义。例如定义一个get_weather(city: str) - str工具描述应为“获取指定城市当前天气情况参数city是城市名返回天气描述字符串”。切忌模糊描述否则LLM可能会错误调用或传入危险参数。2. 控制“思考”成本与循环次数LLM的每次“思考”规划、总结都需要消耗Token费用和算力。必须为Agent设置最大循环次数如10次防止它在遇到难题时陷入死循环不停“空转”烧钱。同时要设计清晰的终止条件。3. 记忆的设计是关键难点是让LLM记住全部历史还是只记住摘要记忆太长会浪费Token太短又会丢失关键上下文。一个实用技巧是采用“分层记忆”核心参数如用户偏好长期记忆最近几轮对话详细记忆更早的对话则只保留摘要。4. 错误处理必须健壮工具调用可能失败网络错误、API限流。Agent必须有基本的错误处理逻辑例如重试、降级方案换一个工具、或向用户坦诚地报错而不是让LLM开始编造一个假的工具返回结果。Agent让LLM从“思想家”变成了“行动派”但它行动所依赖的“知识”如果本身是过时或错误的那就会“一本正经地做错事”。这就是我们需要RAG的原因。4. RAG检索增强生成——给LLM配一个“实时资料库”RAG是为了直接攻克LLM的“知识静态性”和“幻觉”问题而生的。它的核心思想非常简单在让LLM回答问题之前先从一个你指定的、可靠的资料库如公司文档、产品手册、最新新闻中检索出与问题最相关的片段然后把“问题相关片段”一起交给LLM让它基于这些提供的可靠资料来生成答案。4.1 RAG的工作流程三步走一个标准的RAG系统分为两个阶段索引和查询生成。阶段一索引构建你的专属知识库这一步是离线的为你自己的资料建立快速查找的“地图”。加载文档从各种来源PDF、Word、网页、数据库加载你的原始文档。分割文本将长文档切成大小合适的“块”Chunks。这是关键步骤块太大检索不精准太小则失去上下文。通常按段落或固定字符数如500字分割并保留部分重叠以确保连贯性。嵌入向量使用嵌入模型如OpenAI的text-embedding-ada-002或开源的BGE、M3E将每个文本块转换成一个高维度的向量。这个向量就像是这段文本的“数学指纹”语义相近的文本其向量在空间中的距离也相近。存储向量将这些向量及其对应的原始文本存入专门的向量数据库中如Pinecone、Chroma、Milvus、Qdrant等。传统数据库按关键词查找向量数据库则能按“语义相似度”快速查找。阶段二查询与生成实时回答问题这一步是在线响应用户的。用户提问用户输入一个问题。检索系统使用同样的嵌入模型将用户问题也转化为向量。然后在向量数据库中寻找与这个问题向量“距离最近”即最相似的K个文本块例如前3个最相关的。增强提示将用户问题和检索到的相关文本块组合成一个新的、增强版的提示Prompt交给LLM。提示模板通常类似请基于以下提供的上下文信息来回答问题。如果上下文信息不足以回答问题请直接说“根据已知信息无法回答”。 上下文 {检索到的文本块1} {检索到的文本块2} ... 问题{用户原始问题} 答案生成LLM基于这个被“喂了参考资料”的提示生成最终答案。由于答案来源被限定在提供的上下文中其准确性和可靠性大幅提升。4.2 实操中的核心挑战与调优技巧RAG听起来简单但想做好细节决定成败。1. 文本分割的艺术不要盲目按固定字数分割这可能会把一个完整的步骤说明或一个关键论点从中间切断。优先尝试按“自然段落”、“Markdown标题”、“句子”进行分割。使用重叠窗口让相邻的两个文本块有部分内容如100字重叠这能有效防止检索时丢失跨块的关键信息。针对不同文档类型采用不同策略代码文件可以按函数/类分割论文可以按摘要、章节分割对话记录可以按对话轮次分割。2. 检索不是越多越好Top-K的选择检索多少个相关块K值需要平衡。K太小可能信息不全K太大可能引入无关噪声还会增加Token消耗。通常从3-5开始测试。重排序简单的向量相似度检索有时不准。可以增加一个“重排序”步骤用一个更精细但更慢的模型或交叉编码器对检索出的Top-K个结果再次打分排序只保留最相关的1-2个给LLM效果和成本会更好。3. 提示工程是关键明确指令必须在提示词中强制要求LLM“仅根据上下文回答”并设置拒绝回答的兜底策略。提供引用来源要求LLM在答案中注明依据来自哪个文本块如【来源1】这极大增强了答案的可信度和可追溯性方便人工复核。4. 无法回避的“幻觉”残留即使提供了上下文LLM在整合信息时仍可能产生细微扭曲或添加未提及的细节。解决方法包括使用更强大的LLM通常更大的模型如GPT-4在遵循指令和减少幻觉方面优于小模型。后处理验证对于关键事实可以用另一个流程对生成答案中的关键实体、数据与原文进行二次核对。RAG成功地将LLM的通用能力与你的专属、动态知识结合了起来是当前构建企业级知识问答、智能客服、研究报告分析等应用最主流、最实用的架构。5. 三者融合构建实用AI应用的真实场景现在我们把LLM、Agent、RAG放到一个具体场景里看看它们是如何协同工作的。场景一个智能旅游规划助手用户输入“我想下周末从深圳去西安玩三天预算5000元帮我做个规划要包含航班、住宿、景点和美食推荐最后生成一份PDF行程单。”Agent规划与调度启动规划器LLM将这个复杂请求拆解为[查询深圳-西安航班 查询西安酒店 查询西安景点 查询西安美食 整合信息生成文本行程 将文本转为PDF]。它识别出需要调用多种工具。RAG提供精准知识介入当任务进行到“查询西安景点”时Agent调用的可能不是一个简单的搜索API而是一个RAG系统。这个RAG系统的知识库索引了最新的旅游攻略、官方景点介绍、用户评价。它根据“西安 三日游 经典景点”检索出最相关的信息块如“兵马俑、大雁塔、城墙、回民街”的详细介绍和游览建议提供给LLM。LLM核心生成与决策全程工作在每一步LLM都负责理解子任务、解析工具返回的原始数据JSON格式的航班列表、酒店价格、RAG检索到的文本、进行信息摘要和整合。例如它看到航班列表后能判断“早班机价格便宜但太累晚班机耽误第一天游玩”从而做出“选择中午起飞的航班”的建议。最后它将所有整合好的信息组织成一份结构清晰、语言优美的行程描述。Agent执行与交付收尾Agent调用“PDF生成工具”将LLM生成的文本行程转换为PDF文件。最终将完整的行程规划和PDF文件交付给用户。在这个流程中三者各司其职LLM是理解、生成、决策的“大脑”Agent是规划、调用工具、管理流程的“秘书兼手脚”RAG则是为大脑提供实时、准确、专属资料的“智库”。缺少任何一个这个应用要么不智能要么不可靠要么不能执行。6. 常见问题与实战排坑指南在实际开发和使用的过程中你会遇到各种各样的问题。下面是一些典型问题及其解决思路这些都是实践中真金白银换来的经验。6.1 关于LLM的幻觉与胡说八道问题即使我用了RAG提供了上下文LLM生成的答案里还是混入了一些它自己编造的内容。排查与解决检查检索质量首先确认RAG检索到的文本块是否真的包含了答案。可能检索本身就不准。可以调低向量搜索的相似度阈值或增加重排序步骤。强化提示词约束在提示词中使用更严厉的指令例如“你必须严格且仅使用以下上下文中的信息。上下文未提及的任何内容不得出现在答案中。如果无法从上下文中找到答案请输出‘信息不足’。”采用“引用”格式要求LLM以【引用自段落X】的形式在答案中标注每一句话的来源。这不仅能遏制幻觉也便于人工审计。你会发现LLM在需要注明出处时会谨慎得多。模型选型如果预算允许尝试换用更高级的模型如从GPT-3.5-Turbo切换到GPT-4。更大的模型在遵循复杂指令和抑制幻觉方面通常表现更好。6.2 Agent陷入死循环或执行混乱问题Agent在一个简单任务上反复执行相同步骤就是不结束或者调用工具的顺序乱七八糟。排查与解决设置明确的停止条件在Agent的规划逻辑中必须硬性规定最大迭代次数如8-10次。达到次数后强制退出并报告失败。优化工具描述工具的功能描述必须极其清晰、无歧义。描述应包含输入参数的精确含义、格式以及输出结果的示例。模糊的描述会导致LLM错误理解工具用途。给Agent提供“反思”能力在每一轮“观察”后让LLM不仅判断是否完成还要简短总结“上一步发生了什么”、“当前状态如何”、“下一步最该做什么”。这个简单的“自我反思”能显著提升规划质量。简化任务有时任务对当前Agent来说过于复杂。尝试将任务拆解得更细或者先构建能完成子任务的专用Agent再用一个“主管Agent”来协调它们。6.3 RAG检索效果不佳问题用户问的问题明明知识库里有但就是检索不到相关的文本块。排查与解决文本分割策略这是最常见的原因。回顾你的分割策略。对于问答型知识库尝试按“问答对”分割对于文档型确保分割点不在句子中间并使用重叠。嵌入模型是否匹配中文知识库使用针对英文优化的嵌入模型效果会很差。务必选择针对你的语言和领域微调过的嵌入模型如中文可选BGE、M3E。查询改写用户的问题可能表述很口语化而知识库文本很正式。可以在检索前先用LLM将用户问题“改写”成几个更接近文档表述方式的关键词或问句再用这些改写后的查询去检索效果常会提升。混合检索不要只依赖向量检索。可以结合传统的关键词检索如BM25。先分别用两种方法检索再对结果进行融合和重排序。这能兼顾语义相似性和关键词匹配尤其对包含特定术语、缩写、产品型号的查询非常有效。6.4 成本与延迟的权衡问题应用效果不错但响应速度慢API调用费用高。优化策略缓存对常见的、结果不变的查询如“公司介绍”将最终的问答结果进行缓存下次直接返回避免重复进行RAG检索和LLM生成。LLM模型分级并非所有任务都需要最强大的模型。可以用小模型如GPT-3.5-Turbo处理简单的分类、摘要任务用大模型GPT-4处理复杂的推理、创作任务。Agent的“规划器”有时也可以用更便宜、更快的模型。精简上下文严格控制送入LLM的上下文长度。RAG检索时不要盲目追求返回多的文本块通过“重排序”精选最相关的1-2个。在Agent中记忆模块要定期摘要避免历史对话无限增长。AI应用的构建不再是神秘的黑科技它正逐渐工程化、模块化。理解LLM、Agent、RAG这些核心组件的本质、能力和边界是有效利用它们的前提。记住没有银弹任何一个炫酷的AI应用背后都是对这些基础组件的巧妙组合、精心调优以及对大量细节问题的务实处理。 LLM、Agent与RAG：从核心原理到工程实践，构建可靠AI应用
1. 从“聊天机器人”到“智能大脑”AI术语的迷雾与现实如果你最近刷社交媒体、看科技新闻或者只是和同事朋友聊天大概率会频繁听到“LLM”、“Agent”、“RAG”这几个词。它们被包装成各种神奇的概念仿佛有了它们AI就能瞬间无所不能。但当你真正想搞明白它们到底是什么、能做什么、以及对你我这样的普通人或开发者意味着什么时却常常被一堆晦涩的术语和夸张的宣传搞得云里雾里。今天我们不谈那些高深莫测的理论和遥不可及的愿景就从一个最朴素的视角出发把这些概念还原成我们身边看得见、摸得着的工具和逻辑。你可以把这篇内容看作是一位在AI应用一线折腾了挺久的老兵坐下来跟你聊聊这些“热词”背后最实在的东西——它们本质上是什么怎么工作以及最重要的是我们到底该怎么用又该避开哪些坑。简单来说你可以这样理解它们的关系LLM大语言模型是那个“博览群书但可能有点健忘和瞎编”的超级大脑它是所有智能的基石。Agent智能体是给这个大脑配了一个“秘书”和“手脚”让它能按计划做事、使用工具、与人交互。RAG检索增强生成则是给这个大脑配了一个“超级外接硬盘和事实核查员”让它回答问题时能随时查阅最新、最准确的资料减少胡言乱语。接下来我们就一层层剥开这些概念的外壳看看它们的内核。2. LLM大语言模型——AI的“基础脑力”与它的天生局限2.1 核心原理它真的在“理解”吗让我们先抛开所有光环用最直白的方式解释LLM。你可以把它想象成一个在互联网规模文本上完成了“终极填字游戏”训练的超级学生。它读过的书、文章、网页、代码可能比一个人几辈子看的都多。它的核心能力是根据上文预测下一个最可能出现的词是什么。比如你输入“今天天气真”它根据海量数据统计发现“好”、“不错”、“热”等词出现的概率极高于是它就可能输出“好”。这个过程层层递进就生成了一整段话。所以LLM的“智能”本质上是基于统计规律的模式匹配和序列生成而不是人类意义上的逻辑推理或真正理解。这导致了它的几个核心特点知识丰富但可能过时它的知识截止于训练数据的时间点例如GPT-4可能是2023年初。它不知道这之后发生的任何事情。擅长生成与模仿不擅长精确计算与事实核查它能写出文笔优美的文章但让它算“3527乘以148”它可能会瞎编一个看起来合理的数字。它也会自信地编造看似真实但完全不存在的信息即“幻觉”。没有记忆和持续状态每次对话对于标准的LLM来说都是一次全新的开始尽管技术上可以通过传入历史对话文本来模拟上下文但有长度限制。注意很多人误以为LLM连接了互联网或拥有实时数据库。实际上在纯聊天模式下它只是在“回忆”训练时学到的东西。它的“知识”是静态的、凝固的。2.2 实际应用中的“能”与“不能”基于以上原理我们就能更理性地看待LLM能做什么不能做什么。它擅长的事情可以放心使用的场景创意与内容生成写邮件、大纲、故事、诗歌、营销文案。这里追求的是流畅度和创意而非100%的精确事实。文本转换与概括将一段技术语言转换成小白能懂的话总结长篇文章的核心要点翻译不同风格的文字。代码辅助根据注释生成代码片段、解释一段代码的功能、在不同编程语言间转换语法。它见过无数代码模式这是它的强项。开放式问答与头脑风暴探讨一个概念、提供各种点子、从不同角度分析问题。这类问题没有唯一正确答案适合LLM发挥。它不擅长或高风险的事情需要警惕或必须辅助的场景提供实时、动态信息比如“今天某支股票股价是多少”、“刚刚发布的某政策原文是什么”。它给的信息很可能是过时或编造的。进行精确的数学、逻辑运算虽然简单计算可能蒙对但复杂的、多步骤的运算不可靠。给出涉及专业、法律、医疗的精确建议它可能混合正确信息和编造信息给出听起来合理但危险的建议。需要深度理解特定、私有领域知识比如你公司内部的规章制度、产品手册、未公开的会议纪要LLM根本没见过这些资料。理解了LLM的这些天生局限我们就会明白为什么需要Agent和RAG来补足它的短板让它从一个“聪明的聊天者”进化成一个“可靠的实干家”。3. Agent智能体——为LLM装上“手脚”与“计划本”当LLM自己搞不定一件事时Agent就登场了。你可以把Agent理解为一个以LLM为“大脑”或“决策中心”的自动化程序。这个程序不仅能理解你的指令还能自己规划步骤、调用各种工具API、函数、搜索引擎等、并持续执行直到完成任务。3.1 Agent的核心工作流思考、行动、观察一个典型的Agent工作流就像一个自律的项目经理规划LLM大脑分析用户目标如“帮我查一下本周北京飞上海最便宜的航班并总结天气情况”。它将大目标拆解成可执行的子任务[任务1: 搜索航班信息 任务2: 搜索北京天气 任务3: 搜索上海天气 任务4: 整合信息生成报告]。执行Agent根据规划依次调用对应的工具。调用搜索工具查询航班API。调用天气工具查询两地天气API。观察获取工具返回的结果可能是JSON数据、网页文本等。迭代LLM大脑“观察”这些结果判断任务是否完成。如果完成了就生成最终答案如果没完成比如第一次搜索没找到合适航班就重新规划或调整参数继续执行。这个“规划-执行-观察-迭代”的循环是Agent区别于简单问答的核心。3.2 关键组件让Agent真正“动”起来一个功能完整的Agent通常包含以下几个部分组件角色类比实例规划器拆解任务制定步骤项目总监将“做一顿晚餐”拆解为“查菜谱、买食材、洗切、烹饪”。工具集Agent可调用的外部能力工具箱搜索引擎API、计算器、数据库查询函数、文件读写接口、邮件发送服务。记忆模块存储对话历史、工具执行结果工作笔记记住用户说过不喜欢香菜上次查询的航班号任务执行的中间状态。执行引擎协调各组件按步骤运行流水线调度按顺序调用工具处理异常管理整个循环流程。3.3 实操心得构建一个简单Agent的避坑指南假设我们要用Python借助LangChain、AutoGen等框架构建一个能查询天气并给出穿衣建议的简单Agent以下是一些血泪教训1. 工具定义要精确且安全给LLM的工具描述必须清晰无歧义。例如定义一个get_weather(city: str) - str工具描述应为“获取指定城市当前天气情况参数city是城市名返回天气描述字符串”。切忌模糊描述否则LLM可能会错误调用或传入危险参数。2. 控制“思考”成本与循环次数LLM的每次“思考”规划、总结都需要消耗Token费用和算力。必须为Agent设置最大循环次数如10次防止它在遇到难题时陷入死循环不停“空转”烧钱。同时要设计清晰的终止条件。3. 记忆的设计是关键难点是让LLM记住全部历史还是只记住摘要记忆太长会浪费Token太短又会丢失关键上下文。一个实用技巧是采用“分层记忆”核心参数如用户偏好长期记忆最近几轮对话详细记忆更早的对话则只保留摘要。4. 错误处理必须健壮工具调用可能失败网络错误、API限流。Agent必须有基本的错误处理逻辑例如重试、降级方案换一个工具、或向用户坦诚地报错而不是让LLM开始编造一个假的工具返回结果。Agent让LLM从“思想家”变成了“行动派”但它行动所依赖的“知识”如果本身是过时或错误的那就会“一本正经地做错事”。这就是我们需要RAG的原因。4. RAG检索增强生成——给LLM配一个“实时资料库”RAG是为了直接攻克LLM的“知识静态性”和“幻觉”问题而生的。它的核心思想非常简单在让LLM回答问题之前先从一个你指定的、可靠的资料库如公司文档、产品手册、最新新闻中检索出与问题最相关的片段然后把“问题相关片段”一起交给LLM让它基于这些提供的可靠资料来生成答案。4.1 RAG的工作流程三步走一个标准的RAG系统分为两个阶段索引和查询生成。阶段一索引构建你的专属知识库这一步是离线的为你自己的资料建立快速查找的“地图”。加载文档从各种来源PDF、Word、网页、数据库加载你的原始文档。分割文本将长文档切成大小合适的“块”Chunks。这是关键步骤块太大检索不精准太小则失去上下文。通常按段落或固定字符数如500字分割并保留部分重叠以确保连贯性。嵌入向量使用嵌入模型如OpenAI的text-embedding-ada-002或开源的BGE、M3E将每个文本块转换成一个高维度的向量。这个向量就像是这段文本的“数学指纹”语义相近的文本其向量在空间中的距离也相近。存储向量将这些向量及其对应的原始文本存入专门的向量数据库中如Pinecone、Chroma、Milvus、Qdrant等。传统数据库按关键词查找向量数据库则能按“语义相似度”快速查找。阶段二查询与生成实时回答问题这一步是在线响应用户的。用户提问用户输入一个问题。检索系统使用同样的嵌入模型将用户问题也转化为向量。然后在向量数据库中寻找与这个问题向量“距离最近”即最相似的K个文本块例如前3个最相关的。增强提示将用户问题和检索到的相关文本块组合成一个新的、增强版的提示Prompt交给LLM。提示模板通常类似请基于以下提供的上下文信息来回答问题。如果上下文信息不足以回答问题请直接说“根据已知信息无法回答”。 上下文 {检索到的文本块1} {检索到的文本块2} ... 问题{用户原始问题} 答案生成LLM基于这个被“喂了参考资料”的提示生成最终答案。由于答案来源被限定在提供的上下文中其准确性和可靠性大幅提升。4.2 实操中的核心挑战与调优技巧RAG听起来简单但想做好细节决定成败。1. 文本分割的艺术不要盲目按固定字数分割这可能会把一个完整的步骤说明或一个关键论点从中间切断。优先尝试按“自然段落”、“Markdown标题”、“句子”进行分割。使用重叠窗口让相邻的两个文本块有部分内容如100字重叠这能有效防止检索时丢失跨块的关键信息。针对不同文档类型采用不同策略代码文件可以按函数/类分割论文可以按摘要、章节分割对话记录可以按对话轮次分割。2. 检索不是越多越好Top-K的选择检索多少个相关块K值需要平衡。K太小可能信息不全K太大可能引入无关噪声还会增加Token消耗。通常从3-5开始测试。重排序简单的向量相似度检索有时不准。可以增加一个“重排序”步骤用一个更精细但更慢的模型或交叉编码器对检索出的Top-K个结果再次打分排序只保留最相关的1-2个给LLM效果和成本会更好。3. 提示工程是关键明确指令必须在提示词中强制要求LLM“仅根据上下文回答”并设置拒绝回答的兜底策略。提供引用来源要求LLM在答案中注明依据来自哪个文本块如【来源1】这极大增强了答案的可信度和可追溯性方便人工复核。4. 无法回避的“幻觉”残留即使提供了上下文LLM在整合信息时仍可能产生细微扭曲或添加未提及的细节。解决方法包括使用更强大的LLM通常更大的模型如GPT-4在遵循指令和减少幻觉方面优于小模型。后处理验证对于关键事实可以用另一个流程对生成答案中的关键实体、数据与原文进行二次核对。RAG成功地将LLM的通用能力与你的专属、动态知识结合了起来是当前构建企业级知识问答、智能客服、研究报告分析等应用最主流、最实用的架构。5. 三者融合构建实用AI应用的真实场景现在我们把LLM、Agent、RAG放到一个具体场景里看看它们是如何协同工作的。场景一个智能旅游规划助手用户输入“我想下周末从深圳去西安玩三天预算5000元帮我做个规划要包含航班、住宿、景点和美食推荐最后生成一份PDF行程单。”Agent规划与调度启动规划器LLM将这个复杂请求拆解为[查询深圳-西安航班 查询西安酒店 查询西安景点 查询西安美食 整合信息生成文本行程 将文本转为PDF]。它识别出需要调用多种工具。RAG提供精准知识介入当任务进行到“查询西安景点”时Agent调用的可能不是一个简单的搜索API而是一个RAG系统。这个RAG系统的知识库索引了最新的旅游攻略、官方景点介绍、用户评价。它根据“西安 三日游 经典景点”检索出最相关的信息块如“兵马俑、大雁塔、城墙、回民街”的详细介绍和游览建议提供给LLM。LLM核心生成与决策全程工作在每一步LLM都负责理解子任务、解析工具返回的原始数据JSON格式的航班列表、酒店价格、RAG检索到的文本、进行信息摘要和整合。例如它看到航班列表后能判断“早班机价格便宜但太累晚班机耽误第一天游玩”从而做出“选择中午起飞的航班”的建议。最后它将所有整合好的信息组织成一份结构清晰、语言优美的行程描述。Agent执行与交付收尾Agent调用“PDF生成工具”将LLM生成的文本行程转换为PDF文件。最终将完整的行程规划和PDF文件交付给用户。在这个流程中三者各司其职LLM是理解、生成、决策的“大脑”Agent是规划、调用工具、管理流程的“秘书兼手脚”RAG则是为大脑提供实时、准确、专属资料的“智库”。缺少任何一个这个应用要么不智能要么不可靠要么不能执行。6. 常见问题与实战排坑指南在实际开发和使用的过程中你会遇到各种各样的问题。下面是一些典型问题及其解决思路这些都是实践中真金白银换来的经验。6.1 关于LLM的幻觉与胡说八道问题即使我用了RAG提供了上下文LLM生成的答案里还是混入了一些它自己编造的内容。排查与解决检查检索质量首先确认RAG检索到的文本块是否真的包含了答案。可能检索本身就不准。可以调低向量搜索的相似度阈值或增加重排序步骤。强化提示词约束在提示词中使用更严厉的指令例如“你必须严格且仅使用以下上下文中的信息。上下文未提及的任何内容不得出现在答案中。如果无法从上下文中找到答案请输出‘信息不足’。”采用“引用”格式要求LLM以【引用自段落X】的形式在答案中标注每一句话的来源。这不仅能遏制幻觉也便于人工审计。你会发现LLM在需要注明出处时会谨慎得多。模型选型如果预算允许尝试换用更高级的模型如从GPT-3.5-Turbo切换到GPT-4。更大的模型在遵循复杂指令和抑制幻觉方面通常表现更好。6.2 Agent陷入死循环或执行混乱问题Agent在一个简单任务上反复执行相同步骤就是不结束或者调用工具的顺序乱七八糟。排查与解决设置明确的停止条件在Agent的规划逻辑中必须硬性规定最大迭代次数如8-10次。达到次数后强制退出并报告失败。优化工具描述工具的功能描述必须极其清晰、无歧义。描述应包含输入参数的精确含义、格式以及输出结果的示例。模糊的描述会导致LLM错误理解工具用途。给Agent提供“反思”能力在每一轮“观察”后让LLM不仅判断是否完成还要简短总结“上一步发生了什么”、“当前状态如何”、“下一步最该做什么”。这个简单的“自我反思”能显著提升规划质量。简化任务有时任务对当前Agent来说过于复杂。尝试将任务拆解得更细或者先构建能完成子任务的专用Agent再用一个“主管Agent”来协调它们。6.3 RAG检索效果不佳问题用户问的问题明明知识库里有但就是检索不到相关的文本块。排查与解决文本分割策略这是最常见的原因。回顾你的分割策略。对于问答型知识库尝试按“问答对”分割对于文档型确保分割点不在句子中间并使用重叠。嵌入模型是否匹配中文知识库使用针对英文优化的嵌入模型效果会很差。务必选择针对你的语言和领域微调过的嵌入模型如中文可选BGE、M3E。查询改写用户的问题可能表述很口语化而知识库文本很正式。可以在检索前先用LLM将用户问题“改写”成几个更接近文档表述方式的关键词或问句再用这些改写后的查询去检索效果常会提升。混合检索不要只依赖向量检索。可以结合传统的关键词检索如BM25。先分别用两种方法检索再对结果进行融合和重排序。这能兼顾语义相似性和关键词匹配尤其对包含特定术语、缩写、产品型号的查询非常有效。6.4 成本与延迟的权衡问题应用效果不错但响应速度慢API调用费用高。优化策略缓存对常见的、结果不变的查询如“公司介绍”将最终的问答结果进行缓存下次直接返回避免重复进行RAG检索和LLM生成。LLM模型分级并非所有任务都需要最强大的模型。可以用小模型如GPT-3.5-Turbo处理简单的分类、摘要任务用大模型GPT-4处理复杂的推理、创作任务。Agent的“规划器”有时也可以用更便宜、更快的模型。精简上下文严格控制送入LLM的上下文长度。RAG检索时不要盲目追求返回多的文本块通过“重排序”精选最相关的1-2个。在Agent中记忆模块要定期摘要避免历史对话无限增长。AI应用的构建不再是神秘的黑科技它正逐渐工程化、模块化。理解LLM、Agent、RAG这些核心组件的本质、能力和边界是有效利用它们的前提。记住没有银弹任何一个炫酷的AI应用背后都是对这些基础组件的巧妙组合、精心调优以及对大量细节问题的务实处理。