很多朋友在入门大模型的时候第一反应就是找一堆论文和框架文档硬啃结果越看越乱越学越虚。这其实不是你的问题大模型这门学科早就不是单点技术而是一条完整的链路——从基础模型怎么一步步演变到今天到怎么让模型拿到你私有的最新数据再到怎么让它自己调动工具完成复杂任务。我自己的学习路径就按这个逻辑拆成了三条线发展历程、RAG、Agent。这篇就把这三条线的核心要点和实操中会踩的坑一次说透。无论你是刚接触大模型的初学者还是已经在做应用开发、想补一补底层认知的工程师这篇文章都值得你花一点时间读完并且收藏起来反复翻。我会把每个环节背后的“为什么”讲明白而不是只给你一堆名词解释。毕竟看懂了原理你在做技术选型和问题排查的时候才心里有数。1. 大模型发展历程从统计语言模型到能力涌现1.1 前深度学习时代语言模型的朴素起点语言模型的任务很简单给定一段上文预测下一个词是什么。早期统计方法用的是 n-gram 模型核心逻辑是把句子拆成连续的词片段然后统计每个片段出现的概率。比如“今天天气”后面出现“很好”的概率高出现“笔记本”的概率低模型靠着大规模语料的频次统计就能做简单的文本预测。但这个方法的短板非常明显数据稀疏。如果语料里没出现过某个词组合概率直接归零模型只能靠各种平滑策略硬凑。另外 n 一般取到 3 或 5再长就扛不住了上下文窗口极其有限根本谈不上理解语义。后来神经网络进入这个领域词的表示从离散的 one-hot 变成了稠密的词向量也就是 word2vec 那一套思路。语义相近的词在向量空间里距离近这让模型第一次有了“理解”的雏形。不过当时的模型结构主要还是 RNN 和 LSTM它们按顺序读入文字理论上能保留长距离信息实际训练时梯度衰减严重序列一长基本就记不住前文了。1.2 Transformer 架构为什么它成了分水岭改变一切的是注意力机制的引入。2017 年某研究团队提出 Transformer 架构核心做法是让序列里的每一个词都跟所有词计算相关性权重从而直接建模全局依赖。这和 RNN 的逐字递推有本质区别并行度高训练快长距离依赖不再靠记忆硬扛而是靠注意力矩阵直接抓取。Transformer 里有两个关键子结构你需要彻底理解。第一个是自注意力机制它会让每个词都“看到”整个句子的所有词然后根据相关性强弱分配注意权重。第二个是位置编码因为注意力机制本身不感知顺序所以必须给每个位置加上一个编码信号模型才知道词的先后关系。用生活化的方式理解就是RNN 像一个人逐字读文章读到哪里就只能记到哪里而 Transformer 像一个人扫一眼整页纸能同时把握所有词之间的关联效率和信息利用完全不在一个量级。1.3 预训练大爆发规模带来的质变Transformer 提供了强大的底座接下来的突破来自训练范式的变革。早期的神经语言模型是针对具体任务单独训练的机器翻译就训一个翻译模型情感分析就训一个分类模型每个任务都需要大量标注数据成本极高。预训练加微调的范式打破了这种局面。先用海量无标注文本训练一个通用的语言模型让模型学到语法、知识、推理能力然后在具体任务上用少量标注数据做微调。这个思路的核心价值在于通用知识在大规模预训练阶段已经学会下游任务只需要教模型“怎么用”这些知识。到了大模型阶段规模和训练数据双双起飞随后一个关键现象出现了当模型参数规模跨过某个阈值时在不专门训练的情况下模型自己就学会了上下文学习和思维链推理。这就是大家常说的涌现能力。这个现象没有严格的理论解释学界仍在探索中但它带来了一个重要的工程推论盲目追求更大参数不一定最优理解模型能力和成本之间的关系才是做应用选型时更该关注的事。2. RAG 技术深度拆解原理、实战与调优指南2.1 为什么大模型必须外挂知识库从大模型发展历程中我们能得到一个明确结论模型所有知识都固化在参数里训练截止之后新知识进不来。想让它回答公司内部制度、最新产品文档、某个特定领域的问题它只能靠猜或者干脆编造一个看似合理但实际是幻觉的答案。RAG检索增强生成解决了这个结构性矛盾。它的思路非常朴素在模型生成回答之前先从外部知识库检索出与问题相关的文档片段把检索结果和原始问题一起交给模型让模型基于这些证据作答。相当于考试时允许模型翻书而不是闭卷硬答。在实际应用中RAG 的价值体现在三个方面第一解决知识时效性训练数据截止之后的新信息不需要重训模型第二解决领域定制企业内部知识库、私有文档可以快速接入成为模型的“行业大脑”第三缓解幻觉问题模型必须在给定的上下文中找答案胡编乱造的概率大幅下降。2.2 RAG 完整链路从文档切分到向量召回一个标准的 RAG 系统包含五个核心环节文档预处理、向量化、索引存储、召回排序、增强生成。每一步都有讲究我逐个拆开讲。文档预处理是最容易被低估的一步。你拿到的 PDF、Word、网页内容质量参差不齐可能包含页眉页脚、表格、多栏排版。如果不做清洗直接切分检索质量会受影响。切分策略上常见做法是按固定字符长度切分并设置重叠。比如每个块 500 字符重叠 50 字符这个参数的用意是防止一个语义完整的段落恰好被拦腰截断。我实际测试下来重叠部分对查询命中的提升是实打实的因为很多问题跨越了切分边界。向量化环节要把文本变成计算机能计算的向量。选择嵌入模型时要注意几个指标向量维度越高精度通常越好但存储和计算成本也越高、上下文长度模型能向量化多长的文本、语言支持中文场景要重点测试对中文语义的捕捉能力。同一个文本用不同嵌入模型得到的向量差异巨大我的建议是不要只看榜单分数要拿自己的真实文档和真实问题做评测。索引存储通常使用向量数据库。向量数据库对比传统数据库的核心优势是支持近似最近邻检索能在毫秒级在海量向量中找到相似项。主流方案有专门的原生向量数据库也有基于传统数据库的向量检索扩展插件选型主要看团队运维能力和数据量级。单机几百万向量以内轻量方案足够数据量再大就要考虑分布式能力了。召回排序决定哪些文档进入最终上下文。最常用的是 Top-K 方案也就是取相似度最高的 K 个结果。K 的取值需要权衡太小可能漏掉关键信息太大可能塞入噪音。另一个调优点是把相似度阈值限制加上——低于某个分数段的结果宁可不召回也不要强行喂给模型。进阶方案是做混合检索把向量相似度和传统关键词匹配的分数融合能覆盖向量召回对精确名词匹配不敏感的缺陷。增强生成的首要注意点是上下文管理。模型输入窗口有限把召回文档全塞进去很容易超限。实操中需要对召回文档做重排和截断先按相关性排序只取头部段落如果还是超长再按 token 数动态裁剪。给模型的提示词里务必将检索内容和用户原始问题分开标注清楚并且明确告知模型“仅依据给定资料回答资料中没有的内容不要编造”。2.3 RAG 效果调优一场系统性排查很多人在刚搭好 RAG 链路后兴奋地测试结果发现答案还不如直接问模型。这不代表 RAG 没用只说明链路里某个环节质量不达标。我总结了一套调优排查顺序顺着走效率最高。先看召回质量。把检索出来的文档片段直接打印出来人工判断是否和问题相关。如果不相关问题大概率出在嵌入模型或切分粒度上而不是生成阶段。再看生成质量。如果召回的文档已经够相关但模型回答依然不准确就要优化提示词或检查是否有不相关内容混入上下文。前 50 个爬坑的人多有一个共同毛病把 RAG 当成一个开箱即用的黑盒出了问题就在生成层反复调提示词却忽略了问题很可能在召回层。记住一个基本原则——如果模型根本没见过正确答案提示词调出花来也没有用。3. Agent 架构详解让模型从“会说话”到“会做事”3.1 Agent 的核心构成大模型如何成为“大脑”RAG 解决的是信息获取问题Agent 解决的是行动执行问题。一个典型的 Agent 系统由四层构成大模型作为决策核心规划模块负责拆解任务记忆模块负责记录状态和积累经验工具模块负责调用外部能力。用类比来理解大模型像一个聪明的员工但如果没有手和脚再聪明也只能纸上谈兵。Agent 架构就是给这位员工配上手和脚并且教会它如何安排工作顺序。规划模块让模型把一个复杂任务拆解成多个简单子任务工具模块让它能查数据库、调接口、操作文件记忆模块让它记住“之前已经做到哪一步了”不会重复劳动也不会中途遗忘。3.2 从 ReAct 到多 Agent 协作主流架构模式当前工程落地最常见的架构是 ReAct 模式。它的核心思想是让模型在“思考”和“行动”之间交替模型先根据当前状态推理下一步应该做什么然后调用一个工具观察工具的返回结果再根据新信息继续推理循环往复直到任务完成。这就像人遇到未知问题时不是憋在心里想答案而是查资料、做实验、看反馈、再调整方案。更高阶的模式是 Plan-and-Execute先让模型制定完整任务清单再逐项执行。它比 ReAct 更适合步骤明确的长流程任务不会因为中途某一步出错就全线崩盘。还有多 Agent 协作架构把任务拆给多个不同角色的 Agent 协同处理。一个负责信息检索一个负责方案制定一个负责代码编写通过消息机制交流协作。这种模式在处理复杂工作流时更灵活但系统复杂度也成倍上升。我实际使用的体感是如果任务是单轮问答加简单工具调用ReAct 完全够用如果任务涉及多步骤业务流程Plan-and-Execute 更稳定除非任务确实需要专业分工否则不建议一上来就上多 Agent调试成本会高到让你怀疑人生。3.3 工具调用机制与关键工程细节Agent 能不能有效执行任务很大程度取决于工具调用链路是否可靠。主流的工具使用方式是函数调用能力模型根据用户指令从候选工具列表里选择合适的一个并生成结构化的调用参数系统再真正执行这个函数。工具定义的质量直接影响调用准确率。每个工具的描述要写清楚它能做什么、什么时候该用、参数有哪些约束。描述太含糊模型就会在多个相似工具之间犹豫甚至选错。一个工具函数名和参数命名也不要用太抽象的缩写模型对自然语言描述更敏感。工具返回后的处理同样关键。返回结果可能是结构化 JSON也可能是大段文本系统需要先做解析和压缩把关键信息提炼出来再反馈给模型避免把冗余内容塞进上下文。内存管理也是 Agent 的长久痛点长时间运行的 Agent 会产生大量中间状态的对话记录无限累积会撑爆上下文窗口更严重的是模型会“遗忘”早期关键信息。常见解法是设计记忆压缩机制把旧对话摘要化、归档仅保留核心信息参与后续推理。4. 实操演练动手搭建一个带 RAG 的 Agent 问答系统4.1 模拟项目规划与整体设计前面讲了一堆概念现在把它们落到一个具体的模拟项目 X 上。这是一个面向内部员工的“部门知识库问答助手”需求可以拆成两块第一回答关于公司制度、项目文档的问题这部分用 RAG 解决第二帮员工查询天气、查询内部系统数据这类动作这部分用 Agent 的工具调用解决。这个项目的技术栈选择是嵌入模型负责文本向量化一款轻量级向量数据库负责存储和检索Agent 框架负责编排推理循环。整体流程为用户提问后系统先判断是否涉及知识库检索若涉及则执行检索并整理上下文模型生成回答后系统判断是否需要调用工具补充信息最终把完整答案返回给用户。注意这里说的几家工具都可以用开源方案替代选型依据是社区活跃度和中文支持友好程度。数据量百万级以内的知识库轻量架构完全能扛住。4.2 关键代码实现RAG 检索与 Agent 工具调用文档入库的核心代码如下。先对文档做切分然后批量向量化最后写入向量数据库。这里的切分参数是我实测后的经验值你可以根据自己文档平均长度微调。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , ] ) chunks text_splitter.split_text(department_doc) embeddings [embedding_model.encode(chunk) for chunk in chunks] vector_db.add_documents( ids[fchunk_{i} for i in range(len(chunks))], documentschunks, embeddingsembeddings )这里我想额外说清洗和切分顺序。有些文档清洗之后仍带有多余空行切分时容易产生空块干扰检索效果。再有中英文混合文档的分隔符优先级也要注意我上面的顺序是把中文标点排在空格前面就是为了避免中英文混排时切出过多碎片。检索加生成的核心代码如下。注意我把相似度阈值和 Top-K 同时用上双保险避免无关内容污染答案。from langchain.vectorstores import VectorStoreRetriever retriever VectorStoreRetriever(vectorstorevector_db, search_typesimilarity, search_kwargs{k: 5}) relevant_docs retriever.invoke(user_query) filtered_docs [doc for doc in relevant_docs if doc.score 0.42] context_text \n\n.join([doc.page_content for doc in filtered_docs]) prompt f请基于以下资料回答问题。 如果资料中没有相关信息请直接说明“知识库中未找到相关内容”不要推测。 资料 {context_text} 问题{user_query} response llm.invoke(prompt)这段代码里的相似度阈值 0.42 不是拍脑袋定的我先抽样测试了一批问题和答案统计了正确命中和错误命中的分数分布取了两者之间的分界值。你换了自己的数据后一定要重新做一遍。另外我故意在系统提示词里加了“资料中没有的内容不要推测”这句话。别小看这句它能显著减少模型的自由发挥空间把幻觉率压下来。Agent 工具调用部分核心是给模型注册一个查询工具。你只需要把函数名、功能描述、参数说明列给模型模型就会在合适时机自动调用并把返回结果整合进回答。from langchain.tools import tool tool def query_internal_system(employee_id: str) - dict: 查询员工内部系统信息需要提供员工编号。 参数: employee_id: 员工编号字符串例如 A001 return internal_service.fetch_summary(employee_id) tools [query_internal_system] agent create_react_agent(llmllm, toolstools) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) answer agent_executor.invoke({input: 请查一下员工编号A001的入职日期和当前职级})这个 Agent 的实际调用路径是模型接收到查询请求后从工具列表里匹配到 query_internal_system生成参数 employee_id 并调用拿到返回结果后组织自然语言回复。因为内部查询涉及敏感操作我在工具内做了鉴权封装这里提醒一句接入真实数据时一定要在工具层做权限校验不能把底层接口直接暴露给模型。4.3 效果评估如何量化判断系统好不好搭好系统后评估是一个容易被糊弄过去的环节。我见过很多团队上线 RAG 系统没人说得出到底好还是不好全靠演示时挑几个漂亮案例。正经的评估方式至少要从三个维度做量化召回准确率、答案忠实度、答案相关度。召回准确率衡量的是检索系统有没有把真正相关的资料找回来答案忠实度衡量的是模型回答是否严格基于检索到的资料而没有自己脑补答案相关度衡量的是回答是否真正解决了用户问题。这三个维度各有侧重单一指标都说明不了问题。我自己的做法是准备 30 到 50 条覆盖典型场景的测试集每条包含问题、标准答案、相关文档编号。跑完之后人工打分遇到问题就按 2.2 里的顺序回去排查。测试集规模不大但能帮你快速暴露链路短板这个习惯建议所有人坚持。5. 实践中的高频问题与排查经验速查表5.1 八大典型问题与解决方案我做 RAG 和 Agent 开发以来整理了出现频率最高的几个问题做成速查表分享给大家问题现象根因分析排查与解决检索结果完全无关嵌入模型对领域词汇理解不足换更强的嵌入模型或做领域微调召回相关但答案错误上下文被不相关内容干扰降低 Top-K提高相似度阈值模型总是回答“不知道”检索到的片段太碎片化重新设计切分规则增大 overlap回答重复上下文原话提示词未要求归纳总结明确要求模型用自己的语言组织答案Agent 工具调用参数错误工具描述不清或参数命名抽象重写工具说明用自然语言描述Agent 陷入死循环规划无终止条件设置最大迭代次数增加失败退出分支会话变长后效果急剧下降上下文膨胀导致关键信息被淹没做对话压缩或定期归档历史记录文档格式特殊导致解析乱码扫描版 PDF 或加密 PDF先做 OCR 或转为文本文件再入库针对“Agent 陷入死循环”我想多说两句。社区里最常见的 AI Agent 失败案例就是机器人反复调用同一个工具拿不到进展。根因在于很多 Agent 缺少“放弃条件”。我在工具内部增加了最大重试次数和异常分支返回当某个工具连续失败 3 次Agent 会自动生成“该操作不可行”的结论并结束循环。这个保障机制比任何提示词优化都硬核。5.2 几条亲身踩坑后的经验教训最后分享几条我从失败里换来、普通文档不会写的经验教训。第一向量数据库召回高相似度结果不代表和问题相关。向量相似度衡量的是语义相近度而不是逻辑相关性。举个例子用户问“请假的审批流程是什么”检索到的可能是“请假制度的修订历史”因为两段文本在语义空间里确实离得近。所以千万别唯相似度论重排和过滤是 RAG 系统的刚需。第二嵌入模型和生成模型要分开选不要迷信全家桶。嵌入模型只负责把文本映射到向量空间它不需要很强的生成能力生成模型负责组织语言做推理它也不需要很强的语义匹配能力。两个环节各自有各自的评价指标分开评估选型效果反而更可控。第三Agent 工具层的异常处理比规划能力更影响稳定性。模型规划得再好工具一调通就全崩。我建议把工具返回解析、超时处理、权限校验这些工程细节全部做扎实再考虑优化模型的思考链。一个生产级 Agent 的稳定性80% 靠的是工程兜底不是模型聪明。就我个人在实际项目中的体会大模型应用开发最核心的竞争力不在“调模型”而在于把数据工程、检索工程和系统工程的各个环节都对齐了。RAG 和 Agent 不是库里的魔法而是规范而且可以被系统优化的工程体系你把它们拆细、看透扎实地跑通每个环节就会发现所谓的大模型落地难题大多都能找到明确的解法。这份宝典我花了很长时间整理每一步都是真的跑过的建议你收藏下来以后遇到问题再回来翻一翻应该会有新收获。 
长河君 · 2026/10/21 2:17:23 · 阅读 1.2k 大模型技术全景：从Transformer到RAG与Agent的实践指南
很多朋友在入门大模型的时候第一反应就是找一堆论文和框架文档硬啃结果越看越乱越学越虚。这其实不是你的问题大模型这门学科早就不是单点技术而是一条完整的链路——从基础模型怎么一步步演变到今天到怎么让模型拿到你私有的最新数据再到怎么让它自己调动工具完成复杂任务。我自己的学习路径就按这个逻辑拆成了三条线发展历程、RAG、Agent。这篇就把这三条线的核心要点和实操中会踩的坑一次说透。无论你是刚接触大模型的初学者还是已经在做应用开发、想补一补底层认知的工程师这篇文章都值得你花一点时间读完并且收藏起来反复翻。我会把每个环节背后的“为什么”讲明白而不是只给你一堆名词解释。毕竟看懂了原理你在做技术选型和问题排查的时候才心里有数。1. 大模型发展历程从统计语言模型到能力涌现1.1 前深度学习时代语言模型的朴素起点语言模型的任务很简单给定一段上文预测下一个词是什么。早期统计方法用的是 n-gram 模型核心逻辑是把句子拆成连续的词片段然后统计每个片段出现的概率。比如“今天天气”后面出现“很好”的概率高出现“笔记本”的概率低模型靠着大规模语料的频次统计就能做简单的文本预测。但这个方法的短板非常明显数据稀疏。如果语料里没出现过某个词组合概率直接归零模型只能靠各种平滑策略硬凑。另外 n 一般取到 3 或 5再长就扛不住了上下文窗口极其有限根本谈不上理解语义。后来神经网络进入这个领域词的表示从离散的 one-hot 变成了稠密的词向量也就是 word2vec 那一套思路。语义相近的词在向量空间里距离近这让模型第一次有了“理解”的雏形。不过当时的模型结构主要还是 RNN 和 LSTM它们按顺序读入文字理论上能保留长距离信息实际训练时梯度衰减严重序列一长基本就记不住前文了。1.2 Transformer 架构为什么它成了分水岭改变一切的是注意力机制的引入。2017 年某研究团队提出 Transformer 架构核心做法是让序列里的每一个词都跟所有词计算相关性权重从而直接建模全局依赖。这和 RNN 的逐字递推有本质区别并行度高训练快长距离依赖不再靠记忆硬扛而是靠注意力矩阵直接抓取。Transformer 里有两个关键子结构你需要彻底理解。第一个是自注意力机制它会让每个词都“看到”整个句子的所有词然后根据相关性强弱分配注意权重。第二个是位置编码因为注意力机制本身不感知顺序所以必须给每个位置加上一个编码信号模型才知道词的先后关系。用生活化的方式理解就是RNN 像一个人逐字读文章读到哪里就只能记到哪里而 Transformer 像一个人扫一眼整页纸能同时把握所有词之间的关联效率和信息利用完全不在一个量级。1.3 预训练大爆发规模带来的质变Transformer 提供了强大的底座接下来的突破来自训练范式的变革。早期的神经语言模型是针对具体任务单独训练的机器翻译就训一个翻译模型情感分析就训一个分类模型每个任务都需要大量标注数据成本极高。预训练加微调的范式打破了这种局面。先用海量无标注文本训练一个通用的语言模型让模型学到语法、知识、推理能力然后在具体任务上用少量标注数据做微调。这个思路的核心价值在于通用知识在大规模预训练阶段已经学会下游任务只需要教模型“怎么用”这些知识。到了大模型阶段规模和训练数据双双起飞随后一个关键现象出现了当模型参数规模跨过某个阈值时在不专门训练的情况下模型自己就学会了上下文学习和思维链推理。这就是大家常说的涌现能力。这个现象没有严格的理论解释学界仍在探索中但它带来了一个重要的工程推论盲目追求更大参数不一定最优理解模型能力和成本之间的关系才是做应用选型时更该关注的事。2. RAG 技术深度拆解原理、实战与调优指南2.1 为什么大模型必须外挂知识库从大模型发展历程中我们能得到一个明确结论模型所有知识都固化在参数里训练截止之后新知识进不来。想让它回答公司内部制度、最新产品文档、某个特定领域的问题它只能靠猜或者干脆编造一个看似合理但实际是幻觉的答案。RAG检索增强生成解决了这个结构性矛盾。它的思路非常朴素在模型生成回答之前先从外部知识库检索出与问题相关的文档片段把检索结果和原始问题一起交给模型让模型基于这些证据作答。相当于考试时允许模型翻书而不是闭卷硬答。在实际应用中RAG 的价值体现在三个方面第一解决知识时效性训练数据截止之后的新信息不需要重训模型第二解决领域定制企业内部知识库、私有文档可以快速接入成为模型的“行业大脑”第三缓解幻觉问题模型必须在给定的上下文中找答案胡编乱造的概率大幅下降。2.2 RAG 完整链路从文档切分到向量召回一个标准的 RAG 系统包含五个核心环节文档预处理、向量化、索引存储、召回排序、增强生成。每一步都有讲究我逐个拆开讲。文档预处理是最容易被低估的一步。你拿到的 PDF、Word、网页内容质量参差不齐可能包含页眉页脚、表格、多栏排版。如果不做清洗直接切分检索质量会受影响。切分策略上常见做法是按固定字符长度切分并设置重叠。比如每个块 500 字符重叠 50 字符这个参数的用意是防止一个语义完整的段落恰好被拦腰截断。我实际测试下来重叠部分对查询命中的提升是实打实的因为很多问题跨越了切分边界。向量化环节要把文本变成计算机能计算的向量。选择嵌入模型时要注意几个指标向量维度越高精度通常越好但存储和计算成本也越高、上下文长度模型能向量化多长的文本、语言支持中文场景要重点测试对中文语义的捕捉能力。同一个文本用不同嵌入模型得到的向量差异巨大我的建议是不要只看榜单分数要拿自己的真实文档和真实问题做评测。索引存储通常使用向量数据库。向量数据库对比传统数据库的核心优势是支持近似最近邻检索能在毫秒级在海量向量中找到相似项。主流方案有专门的原生向量数据库也有基于传统数据库的向量检索扩展插件选型主要看团队运维能力和数据量级。单机几百万向量以内轻量方案足够数据量再大就要考虑分布式能力了。召回排序决定哪些文档进入最终上下文。最常用的是 Top-K 方案也就是取相似度最高的 K 个结果。K 的取值需要权衡太小可能漏掉关键信息太大可能塞入噪音。另一个调优点是把相似度阈值限制加上——低于某个分数段的结果宁可不召回也不要强行喂给模型。进阶方案是做混合检索把向量相似度和传统关键词匹配的分数融合能覆盖向量召回对精确名词匹配不敏感的缺陷。增强生成的首要注意点是上下文管理。模型输入窗口有限把召回文档全塞进去很容易超限。实操中需要对召回文档做重排和截断先按相关性排序只取头部段落如果还是超长再按 token 数动态裁剪。给模型的提示词里务必将检索内容和用户原始问题分开标注清楚并且明确告知模型“仅依据给定资料回答资料中没有的内容不要编造”。2.3 RAG 效果调优一场系统性排查很多人在刚搭好 RAG 链路后兴奋地测试结果发现答案还不如直接问模型。这不代表 RAG 没用只说明链路里某个环节质量不达标。我总结了一套调优排查顺序顺着走效率最高。先看召回质量。把检索出来的文档片段直接打印出来人工判断是否和问题相关。如果不相关问题大概率出在嵌入模型或切分粒度上而不是生成阶段。再看生成质量。如果召回的文档已经够相关但模型回答依然不准确就要优化提示词或检查是否有不相关内容混入上下文。前 50 个爬坑的人多有一个共同毛病把 RAG 当成一个开箱即用的黑盒出了问题就在生成层反复调提示词却忽略了问题很可能在召回层。记住一个基本原则——如果模型根本没见过正确答案提示词调出花来也没有用。3. Agent 架构详解让模型从“会说话”到“会做事”3.1 Agent 的核心构成大模型如何成为“大脑”RAG 解决的是信息获取问题Agent 解决的是行动执行问题。一个典型的 Agent 系统由四层构成大模型作为决策核心规划模块负责拆解任务记忆模块负责记录状态和积累经验工具模块负责调用外部能力。用类比来理解大模型像一个聪明的员工但如果没有手和脚再聪明也只能纸上谈兵。Agent 架构就是给这位员工配上手和脚并且教会它如何安排工作顺序。规划模块让模型把一个复杂任务拆解成多个简单子任务工具模块让它能查数据库、调接口、操作文件记忆模块让它记住“之前已经做到哪一步了”不会重复劳动也不会中途遗忘。3.2 从 ReAct 到多 Agent 协作主流架构模式当前工程落地最常见的架构是 ReAct 模式。它的核心思想是让模型在“思考”和“行动”之间交替模型先根据当前状态推理下一步应该做什么然后调用一个工具观察工具的返回结果再根据新信息继续推理循环往复直到任务完成。这就像人遇到未知问题时不是憋在心里想答案而是查资料、做实验、看反馈、再调整方案。更高阶的模式是 Plan-and-Execute先让模型制定完整任务清单再逐项执行。它比 ReAct 更适合步骤明确的长流程任务不会因为中途某一步出错就全线崩盘。还有多 Agent 协作架构把任务拆给多个不同角色的 Agent 协同处理。一个负责信息检索一个负责方案制定一个负责代码编写通过消息机制交流协作。这种模式在处理复杂工作流时更灵活但系统复杂度也成倍上升。我实际使用的体感是如果任务是单轮问答加简单工具调用ReAct 完全够用如果任务涉及多步骤业务流程Plan-and-Execute 更稳定除非任务确实需要专业分工否则不建议一上来就上多 Agent调试成本会高到让你怀疑人生。3.3 工具调用机制与关键工程细节Agent 能不能有效执行任务很大程度取决于工具调用链路是否可靠。主流的工具使用方式是函数调用能力模型根据用户指令从候选工具列表里选择合适的一个并生成结构化的调用参数系统再真正执行这个函数。工具定义的质量直接影响调用准确率。每个工具的描述要写清楚它能做什么、什么时候该用、参数有哪些约束。描述太含糊模型就会在多个相似工具之间犹豫甚至选错。一个工具函数名和参数命名也不要用太抽象的缩写模型对自然语言描述更敏感。工具返回后的处理同样关键。返回结果可能是结构化 JSON也可能是大段文本系统需要先做解析和压缩把关键信息提炼出来再反馈给模型避免把冗余内容塞进上下文。内存管理也是 Agent 的长久痛点长时间运行的 Agent 会产生大量中间状态的对话记录无限累积会撑爆上下文窗口更严重的是模型会“遗忘”早期关键信息。常见解法是设计记忆压缩机制把旧对话摘要化、归档仅保留核心信息参与后续推理。4. 实操演练动手搭建一个带 RAG 的 Agent 问答系统4.1 模拟项目规划与整体设计前面讲了一堆概念现在把它们落到一个具体的模拟项目 X 上。这是一个面向内部员工的“部门知识库问答助手”需求可以拆成两块第一回答关于公司制度、项目文档的问题这部分用 RAG 解决第二帮员工查询天气、查询内部系统数据这类动作这部分用 Agent 的工具调用解决。这个项目的技术栈选择是嵌入模型负责文本向量化一款轻量级向量数据库负责存储和检索Agent 框架负责编排推理循环。整体流程为用户提问后系统先判断是否涉及知识库检索若涉及则执行检索并整理上下文模型生成回答后系统判断是否需要调用工具补充信息最终把完整答案返回给用户。注意这里说的几家工具都可以用开源方案替代选型依据是社区活跃度和中文支持友好程度。数据量百万级以内的知识库轻量架构完全能扛住。4.2 关键代码实现RAG 检索与 Agent 工具调用文档入库的核心代码如下。先对文档做切分然后批量向量化最后写入向量数据库。这里的切分参数是我实测后的经验值你可以根据自己文档平均长度微调。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , ] ) chunks text_splitter.split_text(department_doc) embeddings [embedding_model.encode(chunk) for chunk in chunks] vector_db.add_documents( ids[fchunk_{i} for i in range(len(chunks))], documentschunks, embeddingsembeddings )这里我想额外说清洗和切分顺序。有些文档清洗之后仍带有多余空行切分时容易产生空块干扰检索效果。再有中英文混合文档的分隔符优先级也要注意我上面的顺序是把中文标点排在空格前面就是为了避免中英文混排时切出过多碎片。检索加生成的核心代码如下。注意我把相似度阈值和 Top-K 同时用上双保险避免无关内容污染答案。from langchain.vectorstores import VectorStoreRetriever retriever VectorStoreRetriever(vectorstorevector_db, search_typesimilarity, search_kwargs{k: 5}) relevant_docs retriever.invoke(user_query) filtered_docs [doc for doc in relevant_docs if doc.score 0.42] context_text \n\n.join([doc.page_content for doc in filtered_docs]) prompt f请基于以下资料回答问题。 如果资料中没有相关信息请直接说明“知识库中未找到相关内容”不要推测。 资料 {context_text} 问题{user_query} response llm.invoke(prompt)这段代码里的相似度阈值 0.42 不是拍脑袋定的我先抽样测试了一批问题和答案统计了正确命中和错误命中的分数分布取了两者之间的分界值。你换了自己的数据后一定要重新做一遍。另外我故意在系统提示词里加了“资料中没有的内容不要推测”这句话。别小看这句它能显著减少模型的自由发挥空间把幻觉率压下来。Agent 工具调用部分核心是给模型注册一个查询工具。你只需要把函数名、功能描述、参数说明列给模型模型就会在合适时机自动调用并把返回结果整合进回答。from langchain.tools import tool tool def query_internal_system(employee_id: str) - dict: 查询员工内部系统信息需要提供员工编号。 参数: employee_id: 员工编号字符串例如 A001 return internal_service.fetch_summary(employee_id) tools [query_internal_system] agent create_react_agent(llmllm, toolstools) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) answer agent_executor.invoke({input: 请查一下员工编号A001的入职日期和当前职级})这个 Agent 的实际调用路径是模型接收到查询请求后从工具列表里匹配到 query_internal_system生成参数 employee_id 并调用拿到返回结果后组织自然语言回复。因为内部查询涉及敏感操作我在工具内做了鉴权封装这里提醒一句接入真实数据时一定要在工具层做权限校验不能把底层接口直接暴露给模型。4.3 效果评估如何量化判断系统好不好搭好系统后评估是一个容易被糊弄过去的环节。我见过很多团队上线 RAG 系统没人说得出到底好还是不好全靠演示时挑几个漂亮案例。正经的评估方式至少要从三个维度做量化召回准确率、答案忠实度、答案相关度。召回准确率衡量的是检索系统有没有把真正相关的资料找回来答案忠实度衡量的是模型回答是否严格基于检索到的资料而没有自己脑补答案相关度衡量的是回答是否真正解决了用户问题。这三个维度各有侧重单一指标都说明不了问题。我自己的做法是准备 30 到 50 条覆盖典型场景的测试集每条包含问题、标准答案、相关文档编号。跑完之后人工打分遇到问题就按 2.2 里的顺序回去排查。测试集规模不大但能帮你快速暴露链路短板这个习惯建议所有人坚持。5. 实践中的高频问题与排查经验速查表5.1 八大典型问题与解决方案我做 RAG 和 Agent 开发以来整理了出现频率最高的几个问题做成速查表分享给大家问题现象根因分析排查与解决检索结果完全无关嵌入模型对领域词汇理解不足换更强的嵌入模型或做领域微调召回相关但答案错误上下文被不相关内容干扰降低 Top-K提高相似度阈值模型总是回答“不知道”检索到的片段太碎片化重新设计切分规则增大 overlap回答重复上下文原话提示词未要求归纳总结明确要求模型用自己的语言组织答案Agent 工具调用参数错误工具描述不清或参数命名抽象重写工具说明用自然语言描述Agent 陷入死循环规划无终止条件设置最大迭代次数增加失败退出分支会话变长后效果急剧下降上下文膨胀导致关键信息被淹没做对话压缩或定期归档历史记录文档格式特殊导致解析乱码扫描版 PDF 或加密 PDF先做 OCR 或转为文本文件再入库针对“Agent 陷入死循环”我想多说两句。社区里最常见的 AI Agent 失败案例就是机器人反复调用同一个工具拿不到进展。根因在于很多 Agent 缺少“放弃条件”。我在工具内部增加了最大重试次数和异常分支返回当某个工具连续失败 3 次Agent 会自动生成“该操作不可行”的结论并结束循环。这个保障机制比任何提示词优化都硬核。5.2 几条亲身踩坑后的经验教训最后分享几条我从失败里换来、普通文档不会写的经验教训。第一向量数据库召回高相似度结果不代表和问题相关。向量相似度衡量的是语义相近度而不是逻辑相关性。举个例子用户问“请假的审批流程是什么”检索到的可能是“请假制度的修订历史”因为两段文本在语义空间里确实离得近。所以千万别唯相似度论重排和过滤是 RAG 系统的刚需。第二嵌入模型和生成模型要分开选不要迷信全家桶。嵌入模型只负责把文本映射到向量空间它不需要很强的生成能力生成模型负责组织语言做推理它也不需要很强的语义匹配能力。两个环节各自有各自的评价指标分开评估选型效果反而更可控。第三Agent 工具层的异常处理比规划能力更影响稳定性。模型规划得再好工具一调通就全崩。我建议把工具返回解析、超时处理、权限校验这些工程细节全部做扎实再考虑优化模型的思考链。一个生产级 Agent 的稳定性80% 靠的是工程兜底不是模型聪明。就我个人在实际项目中的体会大模型应用开发最核心的竞争力不在“调模型”而在于把数据工程、检索工程和系统工程的各个环节都对齐了。RAG 和 Agent 不是库里的魔法而是规范而且可以被系统优化的工程体系你把它们拆细、看透扎实地跑通每个环节就会发现所谓的大模型落地难题大多都能找到明确的解法。这份宝典我花了很长时间整理每一步都是真的跑过的建议你收藏下来以后遇到问题再回来翻一翻应该会有新收获。