1. 为什么用餐厅后厨来讲AI技术概念第一次听到“LLM、RAG、ReAct、Memory、Tool Use”这一串词很多人的反应是每个字母都认识连起来完全不知道在说什么。我刚开始接触大模型应用开发的时候也一样看了一堆文档概念背下来了但真到动手搭一个能用的系统还是不知道这些模块之间到底怎么配合。后来我发现一个特别好用的方法把AI系统想象成一家餐厅的后厨。这个类比不是随便找的而是因为两者在结构上高度相似——都有信息输入、都有加工处理、都有记忆存储、都有工具调用、都有质量把控。你只要理解了后厨怎么运转就能理解AI系统怎么运转。这篇文章就是把这个类比从头到尾讲透。不管你是刚入门的产品经理、想转行做AI应用的开发者还是纯粹对大模型好奇的技术爱好者看完之后你至少能做到两件事第一别人再聊这些概念你能听懂它们在说什么第二你自己设计一个AI应用的时候知道每个模块该放在哪里、为什么放那里。我下面会按照后厨的真实运转流程来拆解从客人点单到菜品上桌每一步对应一个AI技术概念。你不需要任何前置知识跟着走就行。2. 后厨全景AI系统的整体架构拆解2.1 一家餐厅后厨的基本分工先想象一家正常运转的餐厅后厨。客人进门坐下服务员递上菜单客人点菜服务员把订单传到后厨。后厨里有几个关键角色主厨负责核心的烹饪工作决定这道菜怎么做、放什么调料、火候多大。配菜员负责提前准备好各种食材切好、腌好、分装好主厨要用的时候直接拿。传菜员负责把做好的菜从后厨送到客人桌上。仓库管理员负责管理食材库存知道什么东西放在哪里、还剩多少、什么时候该补货。厨房设备烤箱、微波炉、搅拌机、温度计主厨需要用什么就去用什么。这五个角色各司其职缺一个后厨就转不动。AI系统也是一样的道理只不过角色名字换了。2.2 AI系统的对应角色把上面的角色翻译成AI术语后厨角色AI对应概念核心职责主厨LLM大语言模型核心推理和生成配菜员RAG检索增强生成提前准备和检索相关信息传菜员Tool Use工具调用连接模型和外部能力仓库管理员Memory记忆系统存储和调取历史信息厨房设备外部工具/API完成模型本身做不到的事后厨工作流程ReAct推理行动决定先做什么后做什么这个对应关系不是硬凑的而是它们在系统中的作用确实一一对应。下面我逐个展开讲。2.3 为什么这个类比能帮你理解很多人学AI技术概念的时候习惯从定义出发LLM是什么、RAG是什么、ReAct是什么。这种学法的问题是你记住了定义但不知道它们之间的关系。从后厨的角度切入你天然就会问主厨做菜的时候配菜员什么时候把食材递过来传菜员什么时候把菜送出去仓库管理员怎么知道食材不够了这些问题对应的就是LLM生成的时候RAG什么时候触发检索Tool Use什么时候被调用Memory什么时候被读写一旦你开始问这些问题你就不是在背概念了而是在理解一个系统。这是完全不同的层次。3. 主厨登场LLM到底在做什么3.1 LLM就是那个厨艺高超但有点“轴”的主厨LLM大语言模型是整个AI系统的核心就像主厨是整个后厨的核心。主厨的厨艺决定了这家餐厅的水平上限LLM的能力决定了这个AI系统的能力上限。但主厨有几个特点你需要知道第一主厨的厨艺是训练出来的不是天生的。一个主厨可能花了十年学做菜去过很多餐厅跟过很多师傅。LLM也是一样它是在海量文本数据上训练出来的。训练数据就是它的“学厨经历”。第二主厨做菜有自己的风格有时候不太听话。你让他少放盐他可能觉得不放盐不好吃还是放了一点。LLM也有这个问题你让它严格按照某个格式输出它有时候就是会加一些自己的“发挥”。这在AI圈叫“幻觉”在后厨叫“主厨的倔强”。第三主厨不知道今天的食材新不新鲜。主厨的厨艺再好如果配菜员给他的食材是坏的做出来的菜也不行。LLM也是一样它的知识有截止日期训练数据之后发生的事情它不知道。这就是为什么需要RAG。3.2 主厨的能力边界在哪里理解LLM的能力边界比理解它能做什么更重要。我总结下来是三条线知识线LLM知道的是训练数据里有的东西。训练数据截止之后的事情它不知道。你问它今天的天气它答不出来。计算线LLM不擅长精确计算。你让它算一个复杂的数学题它可能会给你一个看起来很像但实际错误的答案。这不是它笨而是它的工作方式决定的——它是在“预测下一个词”不是在“计算”。行动线LLM只能输出文字不能直接操作外部系统。你让它帮你发一封邮件它只能告诉你邮件内容应该怎么写不能真的帮你发出去。要发邮件需要Tool Use。这三条线划定了主厨的能力范围。超出这个范围的就需要其他角色来补位。3.3 选主厨的标准怎么挑合适的LLM现在市面上的LLM很多怎么选我的经验是看三个维度第一看菜系。不同LLM擅长的领域不一样。有的擅长写代码有的擅长写文案有的擅长做数学推理。你要根据你的应用场景来选。就像川菜馆不会请一个只会做粤菜的主厨。第二看厨房大小。大模型能力强但资源消耗大小模型能力弱但跑得快、成本低。如果你的应用场景比较简单比如只是做一个客服自动回复没必要上最大的模型。就像一个小面馆不需要请米其林三星主厨。第三看预算。调用API是要花钱的模型越大越贵。你需要算一笔账你的应用每天大概有多少次请求每次请求大概消耗多少token然后乘以单价。这个成本在你选模型的时候就要算清楚。实操心得我一般会先用一个大模型做原型验证确认效果达标之后再尝试用小模型替换看效果下降多少。如果下降在可接受范围内就换小模型省钱。这个思路叫“先跑通再优化”。4. 配菜员的智慧RAG如何让AI“有据可查”4.1 为什么主厨需要配菜员回到后厨的场景。主厨虽然厨艺高超但他不可能记住仓库里所有的食材。他需要配菜员在他做菜之前把这道菜需要的食材准备好放在他手边。RAG检索增强生成就是这个配菜员。它的工作流程是当用户提出一个问题时RAG先去知识库里检索相关内容然后把检索到的内容和用户的问题一起交给LLM让LLM基于这些内容来生成回答。为什么要这样做因为LLM的知识是“死”的训练完之后就固定了。但现实世界的信息是不断更新的。你不可能每次信息更新都重新训练一遍模型那成本太高了。RAG的思路是模型不用重新训练我每次把最新信息检索出来喂给它就行。4.2 RAG的三个核心步骤RAG的工作可以拆成三步第一步切片。把知识库里的文档切成小块。为什么要切因为LLM的上下文窗口是有限的你不可能把一整本书都塞进去。切成小块之后每次只检索最相关的几块。切片的粒度很关键。切得太碎信息不完整切得太粗检索精度下降。我的经验是中文文档一般切成300到500字一块比较合适英文文档可以稍微大一点。块与块之间可以留一些重叠避免关键信息被切断。第二步向量化。把切好的文本块转换成向量一串数字。这个过程叫embedding。转换之后语义相近的文本块在向量空间里的距离就比较近。这样你检索的时候就可以通过计算向量距离来找到最相关的文本块。第三步检索和生成。用户提问时把问题也转成向量然后在向量数据库里找最相似的几个文本块把它们和问题一起交给LLM生成回答。4.3 RAG的常见瓶颈和解决思路RAG听起来简单但实际做起来坑很多。我踩过的几个典型问题问题一检索不准。用户问“怎么退款”检索出来的却是“退款政策”的文档而不是“退款操作步骤”。这是因为向量检索只能匹配语义相似度不能理解用户的真实意图。解决思路在向量检索之前加一层关键词过滤或者用混合检索向量检索关键词检索把两种结果融合排序。另外可以在检索之后加一个重排序rerank步骤用一个专门的模型对检索结果重新打分。问题二知识库更新不及时。你昨天刚更新的文档今天用户提问还是检索不到。这是因为向量数据库的索引没有及时更新。解决思路建立增量更新机制文档变更时自动触发重新切片和向量化。如果更新频率很高可以考虑用实时索引方案。问题三检索到的内容太长。检索出来五个文本块每个500字加起来2500字再加上用户问题和系统提示词可能就超过模型的上下文窗口了。解决思路控制检索返回的文本块数量一般3到5个就够了。如果内容确实多可以先做一轮摘要压缩再交给LLM。注意事项RAG不是万能的。如果你的知识库本身质量很差检索出来的内容也是垃圾LLM基于垃圾生成的结果只会更垃圾。所以做RAG之前先把知识库整理好。5. 传菜员的艺术Tool Use让AI“能动手”5.1 主厨不能亲自端菜主厨做完菜之后他不能自己端着盘子跑到客人桌上。他需要传菜员把菜送过去。Tool Use工具调用就是这个传菜员。LLM本身只能生成文字不能直接操作外部系统。但很多场景下你需要AI不只是“说”还要“做”。比如用户说“帮我查一下明天北京的天气”AI需要调用天气API。用户说“帮我订一张明天去上海的机票”AI需要调用订票系统。用户说“帮我算一下这个月的支出”AI需要调用计算器或者数据库查询。这些都需要Tool Use来实现。5.2 Tool Use的工作机制Tool Use的工作流程大致是这样的你提前定义好一组工具每个工具包括名称、功能描述、参数格式。用户提问时LLM判断是否需要调用工具。如果需要它输出一个工具调用请求包括工具名称和参数。系统执行这个工具调用拿到结果。把结果返回给LLMLLM基于结果生成最终回答。这个流程看起来简单但有几个关键点工具描述要清晰。LLM是根据你的工具描述来判断该不该调用的。如果你的描述含糊不清LLM可能该调的时候不调不该调的时候乱调。比如你定义一个“查询天气”的工具描述写“查询信息”LLM就不知道这个工具到底是查天气还是查别的。参数格式要严格。LLM输出的参数格式必须和你的工具定义一致。如果工具要求传入日期格式是“YYYY-MM-DD”LLM输出了“明天”就会报错。所以参数描述里要写清楚格式要求最好给一个示例。错误处理要完善。工具调用可能会失败比如API超时、参数错误、权限不足。你需要把这些错误信息返回给LLM让LLM决定是重试、换一个工具、还是告诉用户出错了。5.3 工具选型的几个原则不是所有功能都适合做成工具。我总结了几条原则LLM做不到的事情才做成工具。比如精确计算、实时查询、操作外部系统。LLM能直接生成的内容不需要做成工具。工具粒度要适中。太细了LLM要调用很多次才能完成一个任务太粗了LLM不知道怎么用。一般一个工具对应一个明确的操作。工具数量不要太多。工具太多LLM选择的时候容易出错。我一般控制在10个以内超过的话就分组或者用路由机制先选组再选工具。实操心得定义工具的时候我会先写一个“工具使用说明”用自然语言描述这个工具是干什么的、什么时候用、参数怎么传。然后把这个说明直接作为工具描述。这样LLM理解起来最准确。6. 仓库管理员的记忆术Memory让AI“记得住”6.1 主厨的记忆力是有限的主厨在做菜的时候需要记住很多事情这道菜做到哪一步了、刚才放了多少盐、客人有没有说不要放辣。但主厨的记忆力是有限的他不可能记住所有事情。LLM也是一样。它的上下文窗口是有限的你不可能把所有的对话历史都塞进去。而且即使上下文窗口够大把所有历史都塞进去也会导致两个问题一是成本高二是信息太多反而会干扰LLM的判断。Memory记忆系统就是解决这个问题的。它的作用是把重要的信息存下来需要的时候再调出来。6.2 Memory的三种类型Memory可以分成三种类型短期记忆。就是当前对话的上下文。用户刚才说了什么、AI刚才回了什么。这部分信息直接放在上下文窗口里LLM可以直接看到。长期记忆。跨对话保存的信息。比如用户上次说他对花生过敏这次点菜的时候AI应该记得提醒他。长期记忆需要存储到外部数据库需要的时候检索出来。工作记忆。当前任务执行过程中的中间状态。比如AI正在帮用户订机票已经选了航班、选了座位正在选餐食。这些中间状态需要记下来不然下一步就不知道进行到哪里了。6.3 Memory的实现方式短期记忆的实现最简单直接把对话历史拼接到prompt里就行。但要注意控制长度太长了要截断或者摘要。长期记忆的实现方式有几种键值存储把用户信息存成键值对比如{user_id: 123, allergy: 花生}。简单直接但只能存结构化信息。向量存储把信息转成向量存起来需要的时候检索。适合存非结构化的信息比如用户的偏好描述。图存储把信息存成图结构节点是实体边是关系。适合存复杂的关系信息比如“张三的朋友李四喜欢川菜”。工作记忆一般用一个状态对象来维护每一步操作更新这个对象下一步操作读取这个对象。注意事项Memory系统最大的坑是“记了不该记的”。比如用户随口说了一句“今天好热”你把它当成长期偏好存下来了下次用户来的时候你推荐冷饮用户可能觉得莫名其妙。所以存什么、不存什么需要有明确的策略。7. 后厨的指挥系统ReAct如何让AI“边想边做”7.1 主厨做菜不是一步到位的一个主厨做一道复杂的菜不是一步到位的。他会先想一下这道菜大概怎么做然后开始动手做到一半尝一下味道发现淡了再加点盐继续做再尝一下差不多了就出锅。这个过程就是“推理行动”的循环。ReActReasoning Acting就是让AI也这样工作。传统的LLM工作方式是你问一个问题它直接给你一个答案。但很多任务不是一步能完成的需要多步推理和多次行动。ReAct的思路是让LLM先推理下一步该做什么然后执行这个动作观察结果再推理下一步再执行直到任务完成。7.2 ReAct的循环流程ReAct的循环可以概括为三个步骤Thought思考LLM分析当前状态决定下一步该做什么。Action行动执行一个具体的动作比如调用一个工具、检索一次知识库。Observation观察获取行动的结果作为下一步思考的输入。这个循环一直持续直到LLM认为任务完成输出最终答案。举个例子。用户问“帮我查一下北京明天天气如果下雨就帮我订一张电影票。”ReAct的流程可能是Thought我需要先查天气。Action调用天气API查询北京明天天气。Observation明天北京有雨。Thought下雨了需要订电影票。但我不知道用户想看什么电影、什么时间。Action调用电影票API查询当前上映的电影。Observation返回电影列表。Thought我需要问用户想看哪部电影、什么时间。Action输出问题给用户。这个流程比直接让LLM回答要复杂但能处理更复杂的任务。7.3 ReAct的常见问题和优化ReAct最大的问题是“绕圈子”。LLM可能在某个步骤反复循环一直不输出最终答案。我遇到过几种典型情况情况一工具调用一直失败。LLM调用一个工具失败了它再调一次又失败了再调一次……陷入死循环。解决思路设置最大循环次数超过就强制输出。另外在工具调用失败时把错误信息明确返回给LLM让它知道失败原因而不是简单地重试。情况二LLM忘记目标。循环了几步之后LLM忘了最初的任务是什么。解决思路在每一步的prompt里都带上原始任务描述让LLM始终能看到目标。情况三LLM过度思考。简单任务也走很多步浪费时间和成本。解决思路在prompt里加一个判断如果LLM认为可以直接回答就跳过行动步骤直接输出。实操心得ReAct的prompt设计很关键。我会在prompt里明确写出“如果你已经知道答案直接输出不需要调用工具”和“如果连续两次调用同一个工具都失败换一种方式或者告诉用户”。这两句话能避免大部分死循环。8. 后厨的质检环节怎么保证AI不出错8.1 主厨做菜需要尝味道主厨做完菜之后会尝一下味道确认没问题才让传菜员端出去。AI系统也需要这样的质检环节。AI出错的方式有很多种LLM幻觉、检索内容不相关、工具调用参数错误、记忆信息过期。如果不做质检这些错误就会直接暴露给用户。8.2 质检的几种方式方式一规则校验。对LLM的输出做格式检查。比如你要求输出JSON格式就用JSON解析器验证一下。如果解析失败就让LLM重新生成。方式二模型校验。用一个单独的LLM来评估主LLM的输出质量。这叫“LLM as Judge”。比如你可以让一个模型判断“这个回答是否基于检索到的内容有没有编造信息”。方式三人工抽检。定期人工检查AI的输出发现系统性问题。这种方式成本高但能发现规则和模型校验发现不了的问题。方式四用户反馈。让用户对AI的回答打分或者反馈。这是最直接的信号但需要设计好反馈机制不然用户不会主动反馈。8.3 质检的时机质检可以在三个时机进行生成前检查输入是否合法、检索内容是否相关。生成中检查每一步的中间结果是否合理。生成后检查最终输出是否符合要求。我的经验是生成后的质检最重要因为这是用户直接看到的。生成前的质检能提前拦截问题减少无效计算。生成中的质检主要用于复杂任务简单任务不需要。注意事项质检本身也会消耗资源。如果每个请求都做多重质检成本会很高。我的做法是分级质检简单请求只做规则校验复杂请求才做模型校验。9. 从后厨到AI一套可落地的系统设计思路9.1 先画流程图再写代码我见过很多人做AI应用上来就开始写代码写到一半发现架构不对推倒重来。我的建议是先画流程图。流程图不用很复杂把用户输入到最终输出的每一步画出来就行。每一步标注清楚这一步是LLM在做、还是RAG在做、还是Tool Use在做、还是Memory在做。画完之后你就能看到整个系统的全貌知道哪里可能出问题。9.2 从最小可用系统开始不要一上来就搭一个完整的系统。先搭一个最小可用的版本一个LLM加一个简单的prompt能跑通就行。然后逐步加RAG、加Tool Use、加Memory、加ReAct。每加一个模块都测试一下效果有没有提升。如果没有提升或者提升不明显就考虑是不是不需要这个模块。我见过很多系统加了一堆模块效果反而下降了就是因为模块之间互相干扰。9.3 监控和迭代系统上线之后监控是必须的。你需要知道每天有多少请求、平均响应时间是多少、错误率是多少、用户满意度是多少。这些数据能帮你发现系统的问题。比如错误率突然上升可能是某个工具挂了响应时间变长可能是检索的内容太多了用户满意度下降可能是LLM的回答质量下降了。根据监控数据做迭代比凭感觉做迭代要靠谱得多。10. 常见问题速查问题可能原因排查思路解决方法LLM回答不准确训练数据不包含该知识检查问题是否超出模型知识范围引入RAG补充相关知识RAG检索不到相关内容切片粒度不合适检查切片大小和重叠设置调整切片参数尝试不同粒度Tool Use调用失败参数格式不匹配检查工具定义和LLM输出完善工具描述增加参数示例Memory信息过期没有更新机制检查记忆存储的更新策略增加过期时间定期清理ReAct陷入死循环工具调用一直失败检查工具是否可用设置最大循环次数增加错误处理响应时间过长检索内容太多检查检索返回的文本块数量减少检索数量增加摘要压缩成本过高模型太大或调用太频繁统计token消耗和调用次数换小模型优化prompt长度11. 我在实际项目中的几点体会做AI应用这几年最大的体会是技术概念本身不难难的是知道什么时候用什么。LLM、RAG、Tool Use、Memory、ReAct这些概念单独拿出来都能讲清楚但放到一个系统里它们之间的配合才是真正的挑战。我踩过的一个大坑是一开始觉得RAG是万能的什么问题都往RAG上套。结果发现有些问题根本不需要检索LLM直接回答就行加了RAG反而引入了噪音。后来我学乖了先判断问题类型如果是通用知识直接让LLM回答如果是特定领域知识才走RAG。另一个坑是Tool Use定义太多工具LLM选择困难。后来我把工具按场景分组每组不超过5个LLM的选择准确率明显提升。还有一个坑是Memory存了太多没用的信息导致检索的时候噪音很大。后来我加了一个过滤机制只存对后续对话有影响的信息比如用户的偏好、重要的事实不存闲聊内容。这些经验不是从文档里看来的都是实际做项目踩出来的。希望对你有所帮助。如果你也在做AI应用欢迎交流。