最近有好几个朋友跟我聊同一个话题AI大模型越来越火但打开技术文章满屏都是“Transformer”“检索增强生成”“智能体”这些词别说外行就连不少写了几年业务代码的开发者也看得一头雾水。我做了几年AI应用落地踩过不少坑也带过团队做内部问答系统、客服助手、知识库机器人这类东西今天就用一篇能一口气读完的篇幅把大模型涉及的核心概念串一遍——基本概念、Prompt、RAG、Agent、多模态看完你至少能听懂别人在说什么甚至能直接动手试一个最小方案。这篇东西不是教科书我尽量用“人话”讲清楚每个概念解决什么问题、背后怎么运转、实操时有哪些坑。适合三类人想给团队做技术科普的开发者刚接触AI产品想搞懂技术边界的产品经理以及准备把大模型接入业务但还没下手的决策者。看完之后你会明白为什么大家都在聊RAG而不是微调为什么Agent总被说成“有手有脚”的AI以及多模态到底比纯文本强在哪。1. 先把大模型这件事说透1.1 大模型到底“大”在哪大模型这个词字面上看是“模型参数规模大”但真正让它和传统算法区别开的是它的训练方式和能力来源。我们现在说的AI大模型绝大多数是基于Transformer架构的神经网络通过海量文本进行自监督学习得到的。它的核心任务非常朴素预测下一个词。你给它一段话它通过计算给出一大堆候选词和概率挑一个最合理的接在后面然后继续预测下一个。就这么一个简单的循环反复执行量变引起质变模型开始涌现出理解、推理、总结、翻译、写代码等能力。那“大”体现在哪一方面是参数量。从早期的几亿参数到后来几百亿、上千亿参数参数越多模型能记住的模式和关联就越丰富。另一方面是训练数据规模。模型见过几乎整个互联网的公开文本包括书籍、论文、代码仓库、维基百科、新闻、论坛帖子所以它“知道”的东西特别多。这里要打个比方传统搜索引擎是“你问它答它去现查”而大模型更像是把一本书反复读了很多遍重要内容已经融入“肌肉记忆”你问的时候它凭记忆写出来。这个差异决定了它的强项跨领域综合、抽象总结、语言表达和弱项精确数字容易错、知识有截止日期、不懂就是一本正经编。还有一个关键概念叫上下文窗口context window指的是模型一次能“同时看到”多少文字。老的模型只能看几千个token大概几千字现在的模型能做到几十万甚至百万级别。窗口越大你一次性塞给它的材料就越多它越能基于你提供的资料来回答而不是只靠记忆。理解这一点后面讲RAG就顺了。1.2 模型能力边界和“幻觉”从哪来所有用过大模型的人迟早会遇到一个现象它一本正经地胡说八道。你说一个不确定的事它给你编得有模有样连数据都像真的。这就是所谓的“幻觉”。幻觉不是bug它是大模型工作方式的副产品。模型学的是“文字接龙”的概率模式它生成的内容追求的是“像人话、逻辑通顺”而不是“符合事实”。当你问到一个它训练数据里没有、或者记忆模糊的内容时它会用最合理的语言组合把答案“编”出来而不是承认自己不知道。这就像一个人被问到不熟的话题为了面子硬撑着说了一通自己都觉得逻辑没问题。实操中幻觉的严重程度跟几个因素有关模型本身的能力、任务类型、Prompt的约束程度。复杂推理和冷门知识最容易触发幻觉而简单归纳、格式转换相对好一些。承认模型会犯错是所有落地工作的第一步。后面讲的RAG本质上就是围绕“怎么减少幻觉、怎么让答案有依据”这一核心诉求展开的。注意上下文窗口不是越大越好。窗口越大模型处理速度越慢成本越高而且它对长文中间部分内容的“注意力”会衰减。给模型喂资料要克制不是把整本手册塞给它就完事。2. Prompt和模型对话的“接口协议”2.1 Prompt为什么值得认真对待大模型本身的能力是你手里的上限但每次实际输出的质量很大程度取决于你输入的那段文字。这就是Prompt的意义。很多人觉得Prompt不就是“把问题写清楚点吗”实际上它更像是跟一个能力很强但很“死板”的同事打交道——你需求描述得稀里糊涂他给你一个跑偏的成果你还怪他不行其实是你没把话说清楚。Prompt工程的核心目标是让模型在尽量少试错的情况下一次就产出符合你预期的结果。它有几种常用手段角色设定“你是资深律师”、任务分解“先判断事实再给结论”、输出格式约束“用表格列出优缺点”、示例引导“参考下面这个回答风格”。这些手段本质上都在做同一件事——给模型的生成过程提供显式的“轨道”减少它自由发挥的空间。举个例子。你直接问“帮我看下这个合同有什么问题”模型会泛泛而谈给你几条安全提示。但如果你说“你是一名合同审核专家请从法律风险、履约条款、赔偿责任三个维度逐条检查发现问题时引用原文编号并给出修改建议”输出质量立刻提升一个档次。差别就在于约束的粒度。2.2 几个立竿见影的Prompt写法从我日常实践来看下面几个技巧几乎适用于所有场景值得直接抄走。第一个是“先给角色和背景再给任务”。模型对上下文的敏感度很高你在开头用一两句话交代身份和目的它会主动调整语气和侧重点。比如“你是给产品经理做汇报的技术顾问听众不懂代码请用通俗语言解释”。第二个是“把复杂任务拆成步骤”。模型在长链路推理时容易逻辑断裂你可以显式要求它按步骤输出比如“第一步列出已知条件第二步分析问题第三步给出结论”。这在处理数学题、逻辑题、复杂分析时尤其有效也被称为思维链Chain of Thought的简化用法。第三个是“给出明确输出格式”。如果你希望结果用JSON返回就在Prompt里写清楚“只输出JSON对象字段包括title、summary、risk_level”如果你希望是表格就明确说“用Markdown表格”。模型很擅长格式模仿你不说它就会自由发挥。第四个是“给示例Few-shot”。模型的学习能力在“看到例子”的时候最强。你给它一个输入和理想输出的配对示例它就能照着那个风格和结构生成后续结果。示例不需要多两三个即可。我自己做实体抽取时给了一条样本准确率明显高于纯文字描述规则。再补充一个容易被忽视的点Prompt不是一锤子买卖而是要像调参一样反复迭代。同一个任务换个说法效果可能天差地别。我一般会准备一个Prompt版本库每次改动都记录下来比对输出质量沉淀出最优版本。这比每次临时瞎写靠谱得多。实操心得Prompt写完之后先用小成本样本快速验证别急着接入正式流程。我见过太多人把Prompt写得特别长、特别满结果模型被太多约束限制反而变得死板、漏掉关键信息。Prompt的优先级是“说清楚做什么”而不是“把所有不做什么都列一遍”。3. RAG给模型装上“外部知识外挂”3.1 RAG解决的是哪三类问题先看几个业务场景。你们公司想做一个内部规章制度问答机器人让员工直接问“年假怎么请”但大模型对你们公司的制度一无所知你想做一个行业研报助手大模型的知识截止在去年最新的报告内容它完全不知道你还想让模型回答问题时列出出处方便追溯责任。这三个问题本质上是同一个——怎么把大模型“不知道”的知识给它补上。RAGRetrieval-Augmented Generation检索增强生成就是为这件事而生的。它的思路特别朴素模型不知道没关系你先把资料准备好提问的时候先去资料库“找答案”找到相关内容连问题一起塞给模型让它基于这些资料来回答。相当于考试的时候允许开卷你先翻书找到相关段落再组织答案。这个思路的好处是训练成本为零资料更新即改即用而且回答有明确引用来源可控性高很多。对比一下另一个方案微调Fine-tuning。微调就是拿你的业务数据继续训练模型让它把这些知识“记住”。它的问题在于代价大、周期长而且每次改资料都要重新训一遍。对大多数业务场景来说知识是动态变化的比如产品文档每周都在改你不可能每周都去微调一次。所以我的建议非常直接只要你的数据能检索、能写成文档优先用RAG别一上来就微调。微调更适合“改变模型的行为风格”而不是“教它新知识”。3.2 一个RAG系统从零到能用的完整流程RAG说起来简单跑起来有门道。我按实际搭建过的最小可用系统给你完整拆一遍。第一步是文档加载。把你的业务资料Word、PDF、Markdown、网页全部收集起来转换成纯文本。这一步看着简单实际上是最容易出问题的环节PDF的表格、多栏排版、扫描件OCR都会让内容变得乱七八糟。第二步是文本切分Chunking。把长文档拆成一个个固定大小的文本片断一般按段落、句子边界来切每条几百到几千字不等。切分有两个关键参数块大小chunk_size和重叠overlap。块太大检索粒度粗容易把不相关内容混进来块太小语义信息不完整检索效果差。重叠是指相邻块之间保留一部分重合文字目的是防止一个完整意思被拦腰截断在边界上。我常用的起点是chunk_size500、overlap50按token算然后根据实际检索效果微调。第三步是向量化Embedding。把每个文本块用嵌入模型转成高维向量。所谓向量就是把文字变成一组数字使语义相近的句子在空间中的距离更近。这一步需要选一个嵌入模型开源的可以用BGE、M3E这类中文效果不错的模型商业API也有现成的。关键点在于嵌入模型的选择直接影响检索质量不建议贪便宜用太弱的模型。第四步是存储和索引。把向量存进向量数据库常见的有开源方案例如Milvus、Qdrant、Chroma和商业服务。向量数据库的主要工作是快速找出“跟查询向量最接近”的若干条记录。这里的核心概念是相似度检索一般用余弦相似度。第五步是检索和生成。用户提问时先把问题转成查询向量去数据库里找到相似度最高的Top K个文本块K一般取3到5然后把原始问题和检索到的文本一起作为Prompt喂给大模型让它根据这些材料生成回答。为了让模型不跑偏Prompt里要明确写“只根据以下资料回答资料中没有的内容回答不知道”。我用一个最小实现示意一下检索部分的代码逻辑Python伪代码from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings # 加载向量库 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh) db Chroma(persist_directory./kb, embedding_functionembeddings) # 用户输入问题 query 员工年假怎么计算 # 检索相关片段 docs db.similarity_search(query, k4) # 拼装Prompt context \n\n.join([doc.page_content for doc in docs]) prompt f请严格根据以下资料回答用户问题。 资料中没有的内容请直接说“资料中未提及”。 资料 {context} 用户问题{query} # 把prompt交给大模型得到最终答案3.3 跑通RAG后必须做的三件优化事系统能跑了只是万里长征第一步。真实使用中你会发现检索质量是个无底洞但大多数问题集中在三个方面。第一召回不准。明明答案在资料库里但检索没找到。最常见的原因是切分不合理答案被拆得七零八落或者query的描述方式和原文差别太大向量化匹配不上。解决办法是调整chunk_size增加检索条数或者做查询改写——比如把口语化问题改写成更接近资料原文的正式说法再检索。第二上下文污染。检索回来的片段里混入了大量无关内容模型的回答被带偏。这里要检查相似度阈值不要为了“有内容”而硬塞低相关片段。我习惯先看到Top K的相似度分数低于某个阈值的直接丢弃宁缺毋滥。第三引用追溯难。给回答加上来源标注最靠谱的做法是在Prompt里要求模型输出时带上片段编号同时做一个简单的对应关系表把编号对应到原始文档和页码。这个功能在内部系统里几乎是刚需不然没人敢信AI的回答。避坑提醒RAG的链路很长每一个环节都可能成为瓶颈。一旦效果不好先别急着换模型或调Prompt按“文档解析质量→切分参数→嵌入模型→检索阈值→生成Prompt”的顺序逐层排查。我见过太多项目改了十版Prompt没效果最后发现是PDF表格解析阶段文本就乱了。4. Agent让模型从“回答问题”变成“完成任务”4.1 Agent和大模型问答的本质区别如果说RAG是给大模型“找资料”那Agent就是给大模型“装上手和脚”。普通问答模式是“模型说你听”模型只负责生成文本。但Agent模式里模型不仅能说还能“决定做什么”比如调用一个天气查询接口、执行一段代码、查询数据库然后根据返回结果继续推理。用一个例子说清楚。普通模式下你问“帮我看看明天北京适合跑步吗”模型只能凭训练记忆给你一个泛泛的答案。Agent模式下模型会判断自己不知道明天的天气主动调用一个天气API获取数据之后结合自己对“适合跑步”的理解生成一个个性化建议。这个能力听着神奇实际上就是给模型暴露出几个函数接口工具模型根据用户请求决定是否调用、调用哪个、参数填什么拿到结果后再继续生成。Agent背后的关键机制叫“推理-行动循环”ReAct。模型在每一轮先推理当前状态决定下一步行动执行行动观察结果再推理再行动直到得出最终答案。你可以理解为一个实习生接到任务后不是一口气瞎干而是边想边做边看结果随时调整策略。这比普通问答多了一个“行动”和“反馈”的闭环。4.2 Agent的常见架构和实现步骤我搭过最小可用的Agent流程上没有想象中那么玄乎。核心四步是这样的。第一步定义工具。把你希望模型能调用的外部能力明确地写成一个函数附上描述信息。比如你有一个“查询班级事务”的内部工具你需要告诉模型这个工具是干嘛的、参数是什么、参数格式是什么。描述写得越清楚模型越知道什么时候该调用它。第二步用“函数调用”协议接入模型。现在主流的大模型API都支持函数调用你把工具的定义列表传给模型模型在需要的时候会返回一个函数调用请求包含函数名和参数。这一步本质上是在Prompt之外建立了结构化的交互协议比“让模型自己写JSON”稳定得多。第三步执行工具并返回结果。你用自己的代码解析模型返回的调用请求真正执行函数拿到真实的返回数据再把数据作为新一轮的消息传给模型。第四步控制循环。给Agent设定最大循环次数防止模型反复调用工具停不下来设置超时时间防止某个工具卡死。我前期的项目里因为没设循环上限出现过模型在两个工具之间来回切换了几十次的情况看起来就像它在“纠结”实际上就是逻辑没有终止条件。下面是一个工具定义的示意函数调用协议中的描述格式{ type: function, function: { name: query_leave_policy, description: 根据员工部门和入职时间查询年假政策, parameters: { type: object, properties: { department: { type: string, description: 员工所在部门名称 }, hire_date: { type: string, description: 入职日期格式为YYYY-MM-DD } }, required: [department, hire_date] } } }4.3 Agent落地中最容易翻车的三个地方第一个翻车点是“工具边界模糊”。模型不知道该用哪个工具或者明明该用工具A它却用了工具B。解决办法是工具描述写得极其精确包括适用场景和不适用场景。比如你的工具只查年假就要写“仅用于年假政策查询不处理薪资相关问题”给模型明确的排除项。第二个翻车点是“过程不可控”。Agent自动决策意味着你无法预测它每步做什么这在真实业务里风险不小。建议在初期阶段做“半自动Agent”也就是模型给建议人做最终确认尤其是涉及发送消息、修改数据、扣费等操作必须加人工确认环节。别觉得“全自动”才高级可靠性永远比炫技重要。第三个翻车点是“评估困难”。Agent每次跑的路径可能不同错误可能是模型推理错了也可能是工具返回数据本身不对还可能是循环逻辑有bug。我建议在开发环境里把所有工具调用记录完整记下来包括模型推理文本、调用参数、工具返回、最终结果方便复盘。没有日志Agent出问题你只能干瞪眼。实操心得做Agent之前先想清楚两个问题——模型的能力上限够不够小模型做不好复杂工具调用以及你的工具是否稳定可靠。工具不稳定模型再聪明也没用。这就像你让一个能力很强的实习生干活但你给他的数据库是坏的他再怎么分析也白搭。5. 多模态让模型“看得见、听得懂”5.1 多模态模型和纯文本模型差在哪大模型最早只处理文本但你实际业务里哪里只有文字合同里有截图客服记录里有图片产品需求里有原型图这些非文本内容传统方式要先靠人转成文字再给模型效率低、信息损失大。多模态模型解决的就是这个问题——它能在同一个模型里同时理解文字、图片、音频、视频。技术上怎么实现的简单说多模态模型把图片分成一个个图像小块通过视觉编码器转成和文字一样的特征向量然后一起放进大模型的Transformer里处理。对模型来说它看到的不再是“一张猫的图片”而是一堆跟文字token类似的特征序列。所以它才能真正做到“看图说话”“图文对照”而不是靠文件名猜。多模态带来的能力提升是质变。你给模型一张流程图截图它能看懂结构并解释每一步含义你给一张报销单照片它能提取出金额、日期、报销人你给一段演讲稿音频它能转写内容并提炼重点。这些在纯文本时代都是要拆成OCR、ASR、文本理解三步去做的现在一步到位而且因为模型理解了上下文准确率往往更高。5.2 多模态的实战场景和几个必须注意的细节我实际用多模态的场景最近的是做“截图问答”——用户把系统报错截图发给客服机器人机器人识别报错信息匹配知识库给出解决方案。以前的处理链路是OCR识别文字然后再走文本问答经常因为截图里排版复杂、中英混杂OCR输出一团糟。换多模态模型后直接把图片丢进去它读取报错、理解界面上下文效果提升非常明显。另一个高频场景是“图表分析”给一张销售数据图表直接问“这个季度哪个区域增长最快”模型能结合图例、坐标轴、数据趋势综合回答。不过多模态有自己的一套坑。第一图片分辨率越高模型要处理的视觉token越多延迟和成本都上涨。直接丢一张超大截图可能一两秒才能返回费用也高。建议先用工具压缩图片、裁剪无关区域把关键部分单独截出来再传给模型。第二多模态模型的幻觉不比文本模型少尤其对图像中的细节数字、小字、模糊区域它照样会一本正经编。涉及精确数据必须让模型“朗读”图片中的原文或者用OCR结果作为参考做交叉验证。第三不是所有“多模态”都一个水平。有的模型在图文理解上很强但图片生成能力弱有的模型支持输入图片但不支持输出图片。选型前明确你的场景到底是“理解图片”还是“生成图片”两者完全不同。我做个简单对比帮助你快速判断自己需要哪种能力。需求适合方案关键考量识别图片文字、理解截图多模态理解模型关注OCR准确率、长图处理能力、分辨率适配自动生成图片、创意配图文生图模型关注风格控制、提示词支持、生成速度从图片中提取结构化信息多模态理解 代码后处理结合JSON模式输出做字段校验视频片段摘要、帧理解具备视频输入的多模态模型注意帧数限制和成本先抽帧再分析5.3 多模态和RAG、Agent组合起来才是完全体多模态不是独立的终点它跟前面讲的RAG和Agent结合才真正释放价值。一个知识库问答系统如果资料里有大量截图和表格你可以让多模态模型先把图片转成文字描述生成“图片说明文本”再走向量化入库。这样用户搜索相关内容时这些图片资料也能被检索到而不是永远沉睡在数据库里。Agent那部分同样可以扩展多模态工具。比如给Agent增加一个“识图工具”当用户上传一张菜单图片问“今天有什么不带辣的菜”Agent调用视觉模型识别菜品再结合用户偏好生成回答。实际上现在不少Agent平台已经内置了视觉、语音工具你只需要做配置和编排。我在内部系统里已经习惯把多模态当作“预处理插件”而不是“最终模型”。遇到带图的请求先让视觉模型抽取信息、清洗、结构化再走RAG检索和生成。这样做的好处是每个环节可控、可logging、可替换不会因为某一张怪图把整个链路带崩。注意多模态输入是有成本的尤其是高分辨率图片。产品在接入前最好先做一次“图片都长什么样”的样本盘点如果大部分是简单文本截图用轻量OCR方案可能更经济如果涉及复杂图表、界面截图再上多模态模型。6. 从“15分钟听懂”到“真正上手”6.1 给你一条最短的上手路径如果看完前面仍觉得抽象我给你一条按角色划分的上手路径照着走就行。如果你是做产品运营的重点应该放在Prompt体验和Agent平台试用上。找一个可视化Agent搭建工具拖拽几个节点接上你们的文档做一个小客服机器人感受一下RAG和Agent在实际交互中是什么体验。你不必会写代码但至少要理解“模型的能力边界在哪里”以后提需求时才不会异想天开。如果你是后端开发最值得投入的是把RAG链路完整手写一遍。不需要用重型框架就照着前面那个Python示例用向量数据库和嵌入模型搭一个能检索、能回答的接口。跑通之后再往上加Agent的工具调用你会发现所有概念都有落脚点了。这个项目做完以后跟人聊大模型应用你不会发虚。如果你是算法方向可以去看开源模型的技术报告了解注意力机制、指令微调、RLHF这些词背后的原理。但是别只看原理最好找一个开源模型用单卡跑起来哪怕是量化版本做几个生成实验把生成参数温度、Top P等一个个调一遍体会“随机性”“创造力”这些词在真实输出里怎么体现。6.2 我趟过的一些坑提前帮你排掉最后说几件我实际趟过的事都是踩了之后才明白的道理。第一件别神话模型能力。大模型确实强但它在结构化输出上经常翻车JSON格式里多个逗号、嵌套括号错位都是常见事故。千万不要信任模型输出的原始JSON一定要做一层解析校验失败就重新生成或降级处理。第二件评估比优化重要得多。不管是Prompt改进还是RAG参数调整都必须有一个标注好的评测集。我从一开始就强调没有量化指标一切“感觉变好了”都是幻觉。哪怕只是收集50条真问题、人工标好答案每次改动跑一遍这50条对比得分也比开发团队凭感觉迭代强一百倍。第三件成本和延迟要提前算。大模型按token计费一次复杂Agent任务可能消耗大量token。你看着每次调用没几块钱量大了完全是一笔不可忽略的开支。我习惯在上线前做一次成本估算按日均调用量、平均token数、单次延迟算清楚再决定用多大模型、开不开缓存、要不要降级到轻量模型。第四件安全第一。任何让模型自动执行的系统都要先想清楚“如果模型做出了非法操作怎么办”。内部工具要有权限校验Agent调用外部接口要加白名单涉及用户数据的场景要做脱敏。AI带来的效率提升不需要用事故来证明。我个人后来的习惯是所有非核心判断尽量交给模型但所有关键闸门都留在自己手里。模型负责“出主意”我来负责“拍板”。这也是我一个项目做了半年才琢磨透的道理——AI的最佳角色从来不是完全替代人的决策而是把人的决策效率抬高一个量级。你现在花15分钟把这些概念搞清楚已经比很多人领先一步了。剩下的就是找一个小场景把它做出来。