大模型开发者技术图谱：Transformer、RAG与Agent实战解析

1. 从一张全景图说起：大模型开发者到底在学什么

如果你最近两三年一直在关注技术圈，一定会有一个感觉：大模型这个领域的信息量已经爆炸到让人头皮发麻。今天看到一个新框架，明天冒出一个新术语，后天又有人在争论“Agent是不是伪需求”。我身边不少开发者朋友，包括我自己，很长一段时间里都处于一种“看了很多，记住很少，落地更少”的状态。

后来我把市面上主流的大模型技术资料、开源项目、论文和实战教程梳理了一遍，发现一个规律：无论外界包装出多少新名词，核心的技术栈始终没有脱离三条主线——基础架构（Transformer 及其衍生）、知识增强（RAG 及其变体）、智能体（Agent 及其生态）。把这三条线打通，你再看任何新出的技术方案，基本都能快速归位，知道它解决的是什么问题、处在图谱的哪个位置。

这篇文章就是把我整理的技术图谱完整拆开，从 Transformer 的原理细节讲到 RAG 的工程落地，再讲到 Agent 的规划与工具调用，每一层都附带我在实际项目中踩过的坑和验证过的方案。适合刚入门大模型开发、准备转岗 AI 应用方向，或者已经在做 LLM 应用但总觉得知识体系有点散的同学。看完你能带走一张清晰的“技术地图”，以及可以直接抄作业的参数配置和架构思路。

2. 技术图谱的总体框架：推理层、记忆层与行动层

2.1 我梳理大模型技术栈的三种分层方式

很多人一上来就扎进 Transformer 源码，或者上来就调 LangChain 接口，看起来学得很努力，实际效率很低。原因在于缺少分层意识。我习惯把大模型应用涉及的技术点拆成三个层次：

第一层，推理层，解决“模型怎么理解并生成内容”的问题。这一层的主角是 Transformer 及其衍生架构（LLM、多模态模型），核心技术点包括注意力机制、位置编码、KV Cache、缩放法则、量化推理、分布式并行等。这一层的关键产出物是一个个“开箱即用”的基础模型，例如对话模型、向量化模型、多模态理解模型。

第二层，记忆层，解决“模型答非所问、知识过时、胡说八道”的问题。这一层的主角是 RAG（检索增强生成）以及围绕它的数据管道、向量数据库、混合检索、重排序、缓存等工程组件。这一层不改变模型本身的参数，而是通过外部知识注入来提升回答的准确性和时效性。

第三层，行动层，解决“模型只能聊天、不能干活”的问题。这一层的主角是 Agent 及其相关机制，包括任务规划（Planning）、工具调用（Tool Use）、记忆管理（Memory）、多智能体协作（Multi-Agent）等。这一层让模型不再止步于文本输出，而是能操作外部系统、执行复杂流程。

这三层并不是替代关系，而是叠加关系。你在做一个实际项目时，往往同时用到 Transformer 底座的能力，接入 RAG 做知识问答，再套上 Agent 做自动化任务处理。因此我的建议是：不要只盯着某一个层次学，而是以“能串起三层的最小闭环”为学习目标。

2.2 图谱上的关键节点速览表

下面这张表是我整理技术图谱时的核心索引，也是后续每个章节的展开依据。我把每个节点的核心作用、常用选型、典型应用场景列了出来，先混个眼熟，后面再逐个详解。

3. 推理层核心：Transformer 的前世今生与关键机制

3.1 自注意力到底在计算什么

很多教程在讲 Transformer 时喜欢堆公式，但实际上自注意力（Self-Attention）的思想特别朴素：对于一句话里的每个词，都让它去跟这句话里的所有词建立联系，并学习这种联系的强度。联系越强，后面的计算就越关注相关信息。

我举个生活的例子。有人跟你说“今天苹果发布了新品”，如果你不了解上下文，你甚至分不清这里的“苹果”是水果还是公司。但如果前面的句子是“库克上台演讲”，那么“苹果”这个词在自注意力计算中，就会和“库克”建立很高的注意力权重，模型就能大概率判断出这里指的是科技公司。这就是自注意力做的事情：它不仅看某个词本身，还看这个词在整句中的“关系网络”。

在实际实现中，模型会把每个 token 映射成 Query（查询向量）、Key（键向量）、Value（值向量）三组向量。每个 token 用自己的 Query 去和所有 token 的 Key 做点积计算相似度，得到注意力权重，再按权重加权求和所有 token 的 Value，得到该 token 的新表示。整个过程可以并行计算，这是与循环神经网络（RNN）最大的区别——RNN 只能一个一个地顺序处理词，而 Transformer 可以在一次计算中处理整个序列。

3.2 为什么需要位置编码

自注意力机制本身对词序是不敏感的。你把“我喜欢你”和“你喜欢我”按词拆分后，在没有位置信息的情况下，模型看到的两句话的词集合完全一样，但语义完全不同。为了让模型感知顺序，Transformer 引入了位置编码。

最初的方案是使用不同频率的正弦和余弦函数生成位置向量。后来业界逐渐转向更高效的可学习位置编码、相对位置编码，而目前开源社区最主流的是RoPE（旋转位置编码）。RoPE 通过旋转矩阵将相对位置信息编码进向量，不仅效果稳定，更重要的是对长文本的外推能力更好——模型训练时只见过 2048 长度的文本，但推理时能扩展到更长上下文，RoPE 在这方面的优势非常明显。

3.3 推理优化的关键：KV Cache与解码策略

很多人第一次用大模型时都会想：为什么模型输出的第一个字那么慢，后面的字越来越快？这和 KV Cache 有很大关系。

在生成第一个 token 时，模型需要计算整段输入序列的 Key 和 Value。生成第二个 token 时，如果重新把整段序列全部计算一遍，代价会随序列长度线性增长，完全不现实。KV Cache 的做法是：保留之前所有 token 的 Key 和 Value，新的 token 只需要计算自己的 Query、Key、Value，然后与缓存中的 K、V 做注意力计算即可。代价小、速度快，所以后续 token 的生成比首个 token 快得多。

理解了这一点，你就能看懂为什么很多推理框架都在强调“首 token 延迟（TTFT）”和“生成速度（Tokens/s）”两个指标，也就理解了为什么上下文越长、显存占用越大，因为 KV Cache 也在同步膨胀。这也是PagedAttention、量化 KV Cache、滑动窗口等优化方案出现的原因。

3.4 开发者需要掌握的配套知识点

基础架构原理之外，真实做项目时你还会碰到几个高频概念：

缩放法则（Scaling Law）：简单说，模型参数量、训练数据量、计算量按比例同步增长时，模型能力会稳定提升。这解释了为什么大家都往“大”里做，但也提醒我们不要盲目堆参数量，数据质量不行时数量再大也白搭。

指令微调（Instruction Tuning）与对齐（Alignment）：预训练阶段模型只会“续写文本”，要让它遵循指令、变成能对话的形态，需要一个“提问-回答”质量数据的监督微调阶段，再做强化学习对齐（常见如 RLHF 或直接偏好优化 DPO）。商用模型的能力很大程度来自这两个后训练阶段。

量化（Quantization）：把模型权重从 FP16 压缩到 INT4/INT8，用少量精度损失换取显存占用和推理速度的显著优化。博主在自己机器上跑 7B 模型时，通常会选用量化版，省心且成本低。

我在实际项目里的体会是：不知道 Transformer 细节也能调用 API 做应用开发，但如果想做性能优化、模型选型、问题排查，你终归要回来补这一层。比如模型输出莫名变慢、显存爆掉、长上下文效果变差，根因往往都在推理层。

4. 知识增强的工程实践：RAG 的完整技术链路

4.1 为什么有了大模型还不够，还要上 RAG

大模型虽然强大，但有三个与生俱来的短板：一是知识截止时间带来的时效性问题，训练数据只到某个时间点，之后发生的事情一概不知；二是幻觉问题，模型不知道答案时会强行编造，尤其在垂直领域或者私有知识上，这个现象非常致命；三是缺乏可追溯性，普通对话里用户很难知道回答到底基于什么来源。

RAG（Retrieval-Augmented Generation）的核心思路简单粗暴：在模型回答之前，先去一个外部知识库中检索出与问题相关的文本片段，把这些片段塞进提示词（Prompt）里，让模型基于这些内容来回答。相当于给模型配了一个“随查随用”的搜索引擎。

做企业知识库、文档问答、客服机器人类项目时，RAG 几乎是目前最稳健的方案。博主见过不少团队试图绕过 RAG 直接微调模型来做垂直领域应用，结果大多不尽如人意——模型确实是学会了某些说法，但遇到具体问题、具体数字、具体业务流程时依然容易“编”，而且每轮微调的数据准备和训练成本都相当高。RAG 的数据可以实时更新，逻辑透明，各模块可单独优化，这些优势在工程落地时非常关键。

4.2 一个标准的 RAG 流程包含哪些环节

我在团队里带着做过的知识库问答项目，整体流程可以拆成两大阶段。

离线索引阶段：先把文档数据清洗干净，去掉页眉页脚、图片水印和无意义的重复段落。然后按一定规则把长文档切成小块（Chunk），比如按标题层级、段落、或固定字符数切分。每个块经过嵌入模型转成向量，存入向量数据库，同时保留原始文本、来源、标题等元数据。

在线问答阶段：用户提问后，首先对问题做查询改写或扩展，提升检索召回的准确性。然后把问题转成向量，在向量库中做相似度搜索，取回 Top-K 个片段。更严谨的做法是再做一次重排序，让最相关的结果排到前面。最后将检索结果和原始问题一起组装成 Prompt，交给大模型生成答案，同时在回答中附上引用来源。

4.3 分块（Chunking）策略：RAG 效果的分水岭

很多人把 RAG 做得烂，第一个坑就出在分块上。分块大小将严重影响后续的召回质量。

如果块太大，确实能把完整上下文包住，但转成向量后语义不够聚焦，检索时经常捞回来一个什么都讲了点、但跟问题对不上重点的大杂烩块；如果块太小，语义太碎，又容易漏掉关键背景信息，模型拿到的材料不完整，答案自然不准确。

我实践下来的经验是：优先按语义结构切块，而不是死板地按字符数切。比如一份产品手册，先按章节拆，再按小节拆，最后若某个小节仍超过你设定的最大长度（比如 800 字），再按句子或固定窗口做二次切分。同时，相邻块之间可以设置少量重叠（Overlap），例如 50 到 100 字，以防止某个关键句刚好落在两块边界而被切散。

在一个合同问答项目中我还发现，纯粹按字数切会让一个完整的条款被拆断，检索效果特别差。后来改成基于语义段落的大模型智能切分，条款边界保留完整，实测召回率提升非常明显。如果你在做一个严肃的项目，建议花时间设计数据解析和切分流程，这比换模型对你的效果提升更直接。

4.4 嵌入模型与混合检索的选型细节

嵌入模型决定文本向量化的语义质量。目前中文场景下可选方案主要有 OpenAI 的 Embedding 系列、开源的 BGE 系列、M3E 等。由于数据隐私和成本考虑，国内项目普遍倾向使用开源模型部署本地，BGE 系列在中文语义匹配上表现比较稳定。

但向量检索并不是银弹。向量检索擅长处理“语义相似”的问题，但面对精确术语、唯一编号、产品型号这些碎片化信息时，召回效果经常不如简单的关键词匹配。模型只知道“苹果手机”的字面，很难把“A2638”与“iPhone 某个型号”关联起来。

所以我在实际项目中强烈推荐混合检索（Hybrid Search）：BM25 这类稀疏检索负责精确匹配专业术语和 ID 型内容，向量检索负责语义模糊匹配和同义改写召回，两者结果合并后，再用重排序模型（Reranker）做一次精排。Reranker 与嵌入模型最大的不同是，它不是把文本变成向量，而是直接计算“问题-文档片段”之间的相关性得分，精度高，但因为要逐条计算所以相对慢，适合对候选结果做最后一步精排。

数据实测中，加了重排序后 Top-1 准确率往往能从 60% 上下提升到 80% 以上，这个提升在知识问答场景感受非常明显。

4.5 向量数据库和图谱补充：到底该怎么选

向量数据库是 RAG 的另一基础设施。市面上选择很多，比如开源的 Milvus、Qdrant、Chroma、Weaviate，还有结合 PG 生态的 pgvector。选型的几个关键维度包括数据规模、查询延迟、部署难度、索引类型支持、是否有高可用方案。

如果项目刚起步、数据量在百万级以下，直接用 pgvector 或者轻量级向量库就行了，省去一套独立服务；如果数据规模大、对延迟和并发要求高，则要选择专门的向量数据库。不要一开始就引入多复杂的组件，这是很多团队的过度设计通病。

另外一个值得提的方向是GraphRAG（图增强的 RAG），它在普通向量库基础上引入知识图谱，把实体和关系显式建模，适合需要回答“关系类问题”的业务场景，比如“某部门下有哪些项目的负责人是谁”。但要做好它，你需要额外搭建实体抽取、关系抽取的流程，成本和复杂度都更高。我的建议是：先做好向量 RAG，确实存在多跳关系推理需求时再考虑 GraphRAG。

4.6 RAG 项目中的高频故障排查速查表

下面把我在真实 RAG 项目中碰到最多的问题整理成速查表，每个问题都附上排查思路和解决方向，供读者直接对照。

5. 从能聊到能干活：Agent 的技术拆解与工程落地方案

5.1 Agent 和普通对话到底差在哪

如果你让一个普通大模型“帮我查一下这个月的销售数据，并做一个可视化报表”，它十有八九会给你一段代码，或者告诉你“作为语言模型我没法直接访问数据”。因为它只具备“生成文本”的能力，没有“动手执行”的接口。

Agent（智能体）的本质，是让模型在更完整的“感知-决策-行动”闭环里工作。模型不仅生成回复，还能规划任务步骤、决定调用哪些工具、解析工具返回结果、判断任务是否完成、以及在失败时做策略调整。简单说，Agent = 大模型（推理大脑）+ 规划（做事方法）+ 工具（手脚） + 记忆（经验与上下文）。

5.2 规划能力：CoT、ReAct 和任务分解

规划能力是 Agent 和普通 Prompt 的最大区别。业界用得最多的范式是ReAct（Reasoning + Acting），核心逻辑是让模型交替执行“思考（Thought）”和“行动（Action）”两个环节，每步先分析当前状况，再调用工具，看到工具结果后进入下一步思考，直到完成任务。

举个例子，Agent 被问到“对比我们团队两个项目上个月的开支”时，它的执行轨迹可能是这样的：

1. 思考：需要先找到两个项目的支出明细 → 行动：调用“查询项目支出”工具，参数项目A、月份；
2. 观察：项目A的支出为 25000 元 → 思考：还需要项目B的数据 → 行动：调用工具查询项目B；
3. 观察：项目B的支出为 31000 元 → 思考：两个数据都有了，可以对比分析 → 行动：生成结论并输出。

这种“思考-行动-观察”的循环结构，就是 ReAct 的核心。更长的任务还需要任务分解（Task Decomposition），把一个大目标拆成若干子任务，甚至让不同的子 Agent 并行处理，再由主 Agent 汇总结果。

5.3 工具调用：让模型真正操作外部系统

要让 Agent 执行真实操作，你需要给模型定义一套可供调用的“工具集”。主流模型和方法已经支持函数调用（Function Calling），你可以按照约定的 JSON Schema 描述每个工具的用途、参数和返回格式。

比如定义一个查询天气的工具，它的 Schema 会包含工具名称、所需参数（城市、日期）、参数类型和是否必填等信息。模型在对话中看到用户说“北京明天冷不冷”，会自动生成一个对该工具的调用请求，应用层收到请求后执行真实 API，并把结果返回给模型继续生成回答。

这里有一点需要特别提醒：工具定义的质量决定了 Agent 调用的准确率。工具描述要写清楚“这个工具是干什么的、什么时候不要用它、参数取值约束是什么”。我见过团队定义工具名暧昧不清，比如一个叫“search_thing”的工具，模型完全猜不准该不该调它，调用率自然很低。另外，参数尽量设计成简单扁平的结构，少用嵌套对象，减少模型生成错误参数的几率。

5.4 记忆体系：短期上下文与长期知识

Agent 要实现复杂的多轮任务，必须有记忆能力。短期记忆通常就是上下文窗口，可以把历史对话记录、中间推理结果、工具返回信息全部拼进对话历史里。但上下文窗口总有上限，所以需要做摘要压缩：当内容太多时，先用模型对旧对话做摘要，保留关键决策和用户目标，再继续新的任务。

长期记忆则偏向量数据库或结构化存储，用来保存用户偏好、历史结论、业务规则等跨会话信息。比如一个客服 Agent 经过几轮交互后，应该记住用户所在城市、常用产品线、之前提交过的工单编号，下次对话无需用户重复描述。

我建议在做 Agent 项目时，先把“记忆需要记录什么”抽象成明确的数据结构，例如用户画像表、对话摘要表、任务状态表，再决定是存向量库还是普通数据库。不要一开始就上复杂的内存图或个人知识库。

5.5 单 Agent 与多 Agent 的取舍

很多人一上来就想搞多 Agent 系统，觉得“多个智能体分工协作”是项目标配。但实际上，绝大多数业务场景用单 Agent + 丰富的工具集就足以覆盖，而且系统更稳定、调试更容易、Token 开销更低。

什么时候才需要多 Agent？当任务本身涉及多个明确专业角色，或者一个 Agent 的全流程串行处理时间过长、上下文严重溢出的情况下，我再建议拆分为多个 Agent。常见的两种模式：

主从模式：主 Agent 负责任务理解、拆解和汇总，从 Agent 分别负责具体子任务，例如一个写代码、一个查资料、一个做检查。

辩论模式：多个 Agent 对同一个问题给出不同观点，互相质询与补充，最后汇总成更严谨的结果。这种方式适合方案评审、内容品控，效果往往比单个模型输出的质量高出一截。

多 Agent 的难点在于多角色之间的通信协议、上下文隔离和任务同步。我在实际项目中的经验是：先把单 Agent 流程彻底跑通，再观察瓶颈发生在哪个环节。如果瓶颈在“单一上下文塞不下”，优先做记忆压缩；如果瓶颈在“需要同时拉取多类数据”，优先做并行工具调用；只有持续处理复杂流程仍不见效果时，才升级到多 Agent 做角色拆分。

5.6 Agent 与大模型、RAG 的组合使用要点

严格来说，Agent、RAG 和大模型三者不是三选一，而是互补关系。RAG 可以当作 Agent 的一个“检索工具”来用。Agent 收到需要专业知识的问题时，可以自主判断并调用“知识库搜索工具”去检索资料，再把资料交给模型推理。

这种组合在真实业务里非常实用。比如一个智能运维 Agent，用户问“这个报错怎么处理”，Agent 先把报错信息拆解，决定调用“故障知识库检索”工具取回相关案例，再调用“服务器状态查询”工具确认当前环境，最后综合所有信息给出处理方案。整个过程体现了推理层（模型底座）、记忆层（知识库检索）、行动层（工具调用与规划）的协同。

组合使用时的调优重点在于：工具之间的调用权限设计要清晰，不要让 Agent 有权调用未授权的敏感接口；工具结果返回后要给模型足够的再思考空间，不要急着让模型出结论。

6. 开发者的学习路径：如何把这张图谱消化成内功

6.1 我建议的“三步走”学习顺序

很多初学者来问的第一个问题是：我应该先学 Transformer 还是先学 LangChain？我的回答通常是：如果你目标是做应用，先别急着补底层理论，先跑通一个端到端的最小闭环，再回头补原理。否则你会在理论里陷进去，迟迟落不了地。

第一步：跑通最小闭环。可以直接调用现成的大模型 API，给自己做一个简单的文档问答机器人或一个带工具调用的 Agent 演示。目标不是做得完美，而是把检索、Prompt、模型调用、输出解析这条链路走通。

第二步：逐层深入调试。当你发现回答质量不行时，去排查到底是分块问题、检索问题还是 Prompt 问题；当你发现响应太慢时，去研究 KV Cache、量化推理和并发方案；当你想把任务自动做完整时，去研究规划、工具调用和记忆设计。带着问题学原理，效率比单纯刷论文高得多。

第三步：横向扩展图谱。等你把主链路都做顺了，再去看微调、多模态、GraphRAG、多 Agent、模型部署优化等进阶方向。每学一个新方向，都尝试把它归入推理层、记忆层或行动层，看看它替换或增强的是哪一环。

6.2 我在项目中反复验证的几条避坑经验

下面这几条经验，是博主在多个项目里反复踩坑之后沉淀下来的，每一句背后都有真实的教训，分享给读者参考。

第一，先确定任务边界，再选模型。我见过太多人上来就用最强模型，导致成本失控。如果你做的是知识库问答，关键优化点在检索质量而不是模型参数大小；如果你要做复杂推理和工具调用，那确实需要更强的基础模型；如果只是简单的意图分类、实体抽取，很多轻量模型就够了。

第二，不要迷信 RAG 是银弹，它的效果取决于数据质量。文档里有大量扫描版 PDF、手写表格、格式混乱的文本时，解析和清洗成本可能占整个项目工作量的 50% 甚至 70%。这一环节省时间的投入，后面都会变成检索效果差、用户投诉的代价。

第三，Prompt 工程依然是低成本高收益的技能。虽然很多人说“大模型都这么强了，还要什么 Prompt 工程”，但实际做项目时，Prompt 的格式、角色设定、约束范围、示例质量，对输出稳定性的影响依然非常大。尤其在 Agent 场景，好的系统提示词能显著提高工具调用成功率和任务完成率。

第四，时刻关注 Token 成本和延迟。博主见过一个内部工具调用一次大模型就要消耗上万 Token，一个月下来账单高得惊人。建议提前做好缓存设计（语义缓存、重复问题缓存）、Prompt 瘦身、以及结果 caching 机制，RAG 场景下把检索文段控制在必要长度内。

6.3 从“会用工具”到“理解原理”的进阶建议

等到你手上的项目稳定运行之后，我建议再回炉补一些底层知识，包括如何用矩阵运算描述注意力机制、位置编码的数学形式、KV Cache 的原理与显存估算公式、RAG 召回评估指标（命中率、MRR、NDCG）等。理解这些不是为了面试好看，而是当线上问题出现时你能快速定位是哪一层出了问题。

博主自己有一个习惯：每做一个新项目，都会把项目涉及的技术节点画到那张分层图谱上，记录它解决的是什么问题、引入的代价是什么、在什么条件下可以不引入。积累几个项目后，你会有一种“看山还是山”的豁然感——所有复杂系统，拆到底都是模型、数据和交互策略的组合。

7. 常见问题查找表与实操心得补遗

7.1 关于大模型选型与部署的常见问题

读者问得最多的一类问题是模型怎么选、怎么部署。这里整理成表格，方便对照。

7.2 RAG 与 Agent 联调的现场心得

博主近半年做的最多的其实是 RAG 和 Agent 联调项目。这个过程中有几个经验，常规文档中很少提到，但实际价值不小。

一是查询改写对召回的影响可能超过换检索模型。用户原始问题往往是口语化的、信息不全的，直接拿去做向量检索经常捞不准。我在问答系统里加了一个查询改写模块，把用户问题转换成更完整、更明确的查询语句后，召回效果提升非常明显。比如用户问“上次那批货怎么回事”，改写成“某项目某批次货的物流异常与处理进展”，检索质量完全不是一个级别。

二是RAG 和 Agent 共用知识库时，建议做一个独立的知识检索工具。而不是把知识库内容直接全塞进系统提示词。Agent 自主决定查什么、什么时候查，既节省上下文，又让回答更有时效性。

三是对长文档做层级切分时要保留结构上下文。我见过很多团队把文档切成几百个碎片，丢了标题和层级，结果 Agent 检索到片段后根本不知道这段属于哪一个章节。解决方法是把“标题路径”作为元数据和片段一起入库，比如 产品手册 > 第三章 安装说明 > 3.2 连接电源，检索到片段时把这一串信息注入 Prompt，模型的理解准确度会大幅提升。

7.3 算力不足时的一些务实替代方案

很多个人开发者或者小团队最头疼的是没有足够的 GPU 资源。博主分享几个务实方案：模型优先选择量化版或者 MoE 架构中参数量小的版本；推理服务用支持连续批处理和 PagedAttention 的推理框架，吞吐能提升不少；如果实在没有本地算力，用云 API 做主力推理模型，本地只跑文档处理和向量检索。

一个实际项目里，我的做法是：日常低并发用云 API 保证体验，批量离线任务用本地量化模型控制成本，两个链路共用同一套 RAG 数据管道。这样既控制了成本，也保留了私有化能力。

7.4 升级到多模态与行业大模型前的预备课

如果你打算扩展做图像、音频、视频相关的应用，知识图谱依然适用。多模态模型的核心是把不同模态的数据映射到共享语义空间，底层还是注意力机制在起作用。你可以把图像当作一种特殊 token 序列，把音频当作需要对齐时间步的信号流，再结合 RAG 检索音频片段或图像描述，以及 Agent 工具调用外部视觉 API。

进入行业大模型前的预备课，核心是把通用能力组合成行业专用流程。金融领域关注报表理解、风控规则匹配、合规问答；医疗领域关注病历结构化和诊疗辅助。要做的技术分解大同小异：解析层解决数据格式，检索层解决知识召回，生成层解决表达逻辑，行动层解决流程操作。

8. 最后分享一点我自己沉淀的技术复盘方法论

我做了多年技术复盘，有一个固定动作值得分享：每个项目结束后，把项目里用到的关键技术节点和它们的“原因”重新整理一遍，做成个人版的技术图谱。

比如做知识库问答项目时，我会记录：为什么用这块方案而不是那块方案？是在什么条件下做的取舍？假如数据规模扩大 10 倍，会不会换向量库？假如回答准确率再涨 5 个点，瓶颈会在检索还是生成？这些记录积累下来，就成了自己做技术决策时的判断依据。

刚开始接触大模型时，我也面临过信息过载和理论恐惧，每天刷几十篇文章感觉还是没有体系。后面我慢慢发现：真正的成长不是记住所有方案细节，而是理解每个技术在“推理层-记忆层-行动层”图谱中的位置，以及它和上层应用之间的依赖关系。搭建这套体系之后，你再看到新的模型、新的框架、新的应用范式，都能快速定位它的核心价值。

我也特别建议初学者保持“做出来”的习惯，哪怕是最简单的 Demo，也会比纯看文章带来更深的记忆。某一个环节一旦亲手搭建过，它的 Failure Mode、调优方向和决策逻辑都会刻在脑子里，这才是真正属于你的技术内功。希望这份图谱梳理对你也有类似的价值，接下来就是动手的事情了。