1. 换血时刻：为什么序列模型在Transformer面前集体失守
1.1 从n-gram到RNN：所有模型都在猜"下一个词"
要聊LLM大模型的技术架构，得先回到所有模型最开始的那个原点：语言模型的核心任务只有一个，就是预测下一个词的概率。
早期统治这个领域的是n-gram模型。它的思路非常朴素——把一个句子拆成连续的n个词，通过统计语料里"这n个词后面跟着什么词"的频率来预测。比如一个三元模型，看到"今天天气"就查语料里出现过多少次"今天天气好""今天天气差"，概率最高的那个词就是答案。这套思路在20世纪90年代是主流，但它有个致命伤：语料再大也是稀疏的，"今天天气"后面跟着的词可能几千种，更别说四元、五元模型。n越大，参数越多，数据却永远不够。所以n-gram模型的n通常只能取到3或4，再大就崩了。
后来RNN（循环神经网络）带着"记忆"登场，试图解决n-gram的短视问题。RNN把句子当成一个时间序列，每读一个词就更新一次隐藏状态，理论上这个隐藏状态能记住前面所有词的信息。LSTM和GRU更是把"记忆度"做到了新高度，一度是机器翻译、语音识别的标配。但RNN有一个绕不过去的坎：它的计算是串行的，每一步的计算都依赖上一步的输出，GPU即使有几千个核心也只能一个词一个词地喂给它。训练一个深层的双向LSTM，速度慢得让人怀疑人生，而且随着序列拉长，早先的信息会被"稀释"掉，长距离依赖依然捕捉不牢。
1.2 自注意力机制：让每个词直接"看见"所有词
2017年Google那篇论文《Attention Is All You Need》提出的Transformer架构，真正的革命性在于它彻底抛弃了循环结构，改用self-attention（自注意力）机制。这个机制的核心你可以用那句流传很广的话来理解：key是"我是谁"，query是"我在找什么"，value是"我能提供什么"。每个词都生成三个向量，然后通过"找我需要的"和"别人提供的"做加权求和，来更新自己的表示。
这个设计有两点直接改变了游戏规则：
- 并行化。因为是矩阵乘法而不是时间步递推，一个句子里所有的词可以同时参与计算，GPU终于能满负荷跑起来。这直接让训练时长从"周"压缩到"天"甚至"小时"。
- 长距离依赖。句子中任意两个词之间的距离，在注意力机制里都被"一步"拉平了。不管两个词中间隔了多少个词，注意力权重都能直接学到它们之间的关联。这是RNN无论堆多少层都做不到的。
我第一次看到注意力权重可视化时，印象最深的不是它学到了语法规则，而是发现"it"这个词在指代不同的名词时，注意力权重的指向完全不同。模型确实是靠注意力机制在做"谁能提供我需要的语义信息"这个匹配过程，而且这种匹配是动态的、数据驱动的。
1.3 Transformer为什么能赢：它不只是模型，而是"基建"
如果说RNN是一个专做语言序列的"手工作坊"，Transformer就是一整套可以到处复用的"标准零件库"。它由Encoder和Decoder两个模块组成，但用户可以根据任务自由裁剪——可以只留Encoder做分类，只留Decoder做生成，或者两个都留做翻译。这种模块化设计催生出了一整条技术路线：BERT用Encoder，GPT用Decoder，T5用Encoder-Decoder。
更重要的是，Transformer的架构容量几乎是无限的。因为它没有序列依赖，可以靠堆层数、加大隐藏维度、增加注意力头数来无限扩大模型容量。这让"规模"本身第一次成为一个可操作的技术变量——模型不是靠更精巧的技巧变强，而是靠更大规模地计算变强。这条路径最终演化成了scaling law，也为后面的一切大模型技术树奠定了基础。
提示：理解Transformer时不要被"多头注意力""位置编码""层归一化"这些术语吓到。你可以把整个结构理解成一个流水线：词变成向量，向量经过很多组"过滤网"层，每层都在提取不同粒度的特征——低层看词性，中层看句法，高层看语义。真正让这个流水线强大的，是每一组"过滤网"都可以根据数据自动调整自己的参数。
2. decoder-only的胜利：GPT如何用"单向"碾压"双向"
2.1 预训练-微调范式：BERT路线曾经的风光
Transformer一出来，整个NLP圈分成了两大阵营。BERT采用的是Encoder路线，它的训练任务是"填空"——随机遮住一句话里的一些词，让模型根据上下文预测被遮住的词。因为Encoder能看到句子左右两侧的所有词，所以这种架构也叫双向模型。BERT在2018年横扫十几个NLP榜单，当时几乎所有人都在做"BERT + 特定任务微调"，给它加个分类头做情感分析，加个序列标注头做实体识别。
但这条路后来被证明有一个天花板：它做的是"理解"而不是"生成"。你没办法让BERT流畅地写一篇文章，它的架构压根不是为了连续输出而设计的。当年做问答系统时，标准的做法是先把语料切成一大把片段，让BERT给每个片段打分，取出得分最高的片段作为答案。这种"检索-再打分的闭卷考试"模式，本质上是把问答当成阅读理解，而不是真正在"生成一个回答"。
2.2 单向生成的优势：自回归的涌现能力
GPT选择的是另一条路线：只用Decoder，而且刻意坚持"单向"——预测下一个词时，只能看到这个词左边的内容，看不到右边。单看这一点，GPT在"智商测试"类任务上确实不如BERT，因为信息不完整。但单向模型换来的是一个极其干净的框架：只要你有文本，就能自监督地训练，因为"下一个词"这个标签是天然存在的，不需要人工标注。
这种"只看左边，预测右边"的自回归方式，最大的优势是它在生成这个场景下有天然的适配性。语言本身的本质就是线性的——我们说一句话也是一次吐出一个词，写代码也是一行一行的。当模型学会了"根据已有内容预测接下来最合理的词"，它就已经学会了写作、翻译、总结、代码生成等所有"以文本输出为目标"的任务。
更关键的是，OpenAI在2020年发布《Language Models are Few-Shot Learners》时展示了一个现象：当模型规模超过某个临界点（GPT-3有1750亿参数）之后，它只需要在提示词里给一两个例子（few-shot），不需要调整任何参数，就能完成一个全新任务。这就是"涌现能力"——大模型做到足够大后，架构本身开始展现出小模型没有的技能。这些技能是"微调"无法手工设计的，而是从海量文本的预测过程中自然长出来的。
2.3 指令微调：从"会说话"到"会听话"
参数规模大了，模型能预测下一个词了，但这时它其实是个"学舌模型"——你给它一段开头，它像接龙一样延续下去，可能写着写着就偏了。2022年诞生的ChatGPT之所以给人"顿悟"的感觉，靠的是一个叫RLHF（基于人类反馈的强化学习）的关键技术。
这个阶段的核心是指令微调（instruct tuning）。做法是先收集大量"用户提问-人工回答"的高质量对话对，让模型学会在"被问"时给出"正确应答"，而不是接龙。然后再训练一个打分模型，专门评估"这两个回答哪个更符合人类偏好"，最后用强化学习去调节生成策略。这一步让模型从"文本接龙器"变成"会听话的助手"。
我个人的体会是，指令微调真正解决的是"模型与真实用户之间的意图对齐"问题。预训练让模型懂语言，指令微调让模型懂任务，RLHF让模型懂好坏。三层能力叠加之后，LLM大模型才开始能够真正被普通人所使用。
3. 上下文工程与检索架构：RAG如何解决"知识过期"的硬伤
3.1 参数化记忆与上下文窗口的矛盾
随着LLM大模型架构越来越成熟，一个核心矛盾开始暴露：模型的所有知识都固化在参数里（这叫做参数化记忆），训练完成那一刻就冻结了。你问它"昨天发生的事"，它答不上来；你问它某个具体产品的内部文档，它没看过；它的知识截止日期永远停留在训练数据那年。
早期大家试图靠"不断重训"来解决。但每一次全量重新训练，成本都是数百万美元级别的算力消耗，而且训练周期长——等训完了，知识又过期了。同时上下文窗口的长度也有限制。早期的模型上下文窗口只有2K、4K token，稍微长一点的资料塞进去直接溢出。就算后来有模型把窗口拉到了128K、200K，你也不可能把整个企业知识库全部塞进去让它做检索。
这两件事合在一起，逼着整个行业想到了一个很朴素的答案：模型不懂的知识，为什么不直接在问它之前主动喂给它？这个思路演变成了RAG（检索增强生成）。
3.2 RAG架构的分层拆解：从朴素版本到GraphRAG
最基础的RAG架构分成三步：
- 离线索引：把知识库文档拆成固定大小的chunk（常取200-500个token），用embedding模型为每个chunk生成向量，存进向量数据库。
- 在线检索：用户提问时，也生成一个query向量，在向量库里做近邻搜索，找出最相似的几个chunk。
- 增强生成：把检索到的chunk拼进提示词的上下文里，交给LLM大模型生成最终回答。
这套架构解决了一个很实际的问题——LLM还是那个LLM，参数不动，但只要上下文里塞入最相关的知识，回答准确率就能大幅提升。它用极低的成本，把"模型知识固化"这个死结解开了。
但朴素RAG有不少坑。最典型的是chunk切分和检索精度的矛盾：chunk太小，语义碎片化；chunk太大，噪音多。还有，向量相似度只衡量"字面或浅层语义接近"，对需要跨多篇文档综合推理的问题，比如"对比A公司和B公司的营收结构"，朴素RAG往往答得七零八落。
于是出现了GraphRAG。它把检索从"向量空间找相似块"升级成"图上做多跳推理"：先用LLM把文档里的事实抽取成实体和关系，构建知识图谱；检索时先定位起始实体，再沿着关系边做多跳扩展，最后把所有关联子图的内容组装进上下文。这个架构比朴素RAG要重得多（离线建图的成本不低），但在处理"需要综合推理、可解释性要求高"的场景下，准确率和逻辑连贯性都明显更强。
近期还有把**本体（ontology）**引入RAG的实践。本体相当于知识图谱的"骨架"——你先定义好实体类型和关系类型，让LLM按这个骨架去抽取事实，能更好避免抽取结果五花八门。这种"本体RAG"的思路，本质上是在"纯向量检索的自由"和"知识图谱的结构"之间取一个中间值，让抽取和检索两个环节都被规范在可控的边界内。
提示：在做RAG架构选型时，我的经验是不用一上来就上GraphRAG。如果你的知识库是FAQ类、单文档查询类场景，朴素向量检索加一个rerank模型完全够用。只有当你明确碰到"需要跨文档综合推断"又对准确率有硬要求时，再升级到图谱类方案。选型不是越复杂越好，而是越匹配越好。
3.3 上下文工程：提示词不再是玄学
RAG的流行还带火了一个更底层的能力训练——上下文工程。以前大家都说提示词工程（prompt engineering），但你看最近的实践会发现，真正决定LLM回答质量的变量已经不只是"你怎么措辞问它"，而是"你往上下文里塞了什么、塞多少、怎么排列"。
上下文工程处理的三个核心问题：
- 上下文的选择：该从知识库里取哪些信息进来，取多少才不会超出窗口。
- 上下文的组织：信息按什么顺序排列。实践表明，把最关键的指令放在系统提示词里，把检索结果放在"参考资料"区并明确标注"仅基于参考资料回答"，模型的表现差异非常大。
- 上下文的压缩：当长对话累积起来后，怎么用摘要或者关键片段替换历史信息，避免token溢出和"注意力被稀释"。
我对上下文工程的一个切身感受是：它把调模型这件事从"改prompt的玄学"变成了"设计信息流的工程"。你不再去猜"用词是不是不够礼貌所以模型生气"，而是去审视"我给模型提供的材料是否充分、是否噪音太大、是否互相矛盾"。这套思维方式，是从LLM实用者走向LLM架构师的必经之路。
4. 从数据中心到个人电脑：推理部署架构的逆向收缩
4.1 训练架构和推理架构是两种生物
很多人以为LLM大模型的部署就是把训练好的模型拿过来跑一下，其实训练架构和推理架构是两套逻辑。训练阶段追求的是"吞吐量"——一次性吃进大批数据，批量做前向和反向传播，用足够大的batch size让GPU算力用满。推理阶段追求的是"延迟"——用户发来一个请求，你要尽快吐出一个词，然后接着吐下一个词，这是串行的。
推理阶段最典型的瓶颈在自回归生成：模型每生成一个token，都要重新把所有历史token的注意力计算一遍。你生成第1000个词时，其实重复计算了前999个词的大量注意力。KV Cache（键值缓存）技术正是针对这一点：把已计算过的key和value向量缓存下来，后续生成新token时只算新的部分，大幅减少重复计算。
此外还有几个部署架构层面的关键优化手段：
- 量化：把模型权重从FP16压到INT8甚至INT4。精度略有损失，但显存占用可以降到原来的四分之一，同时在支持的硬件上计算速度还更快。4-bit量化（如GPTQ、AWQ）是当前本地部署的主流配置。
- 投机采样：用一个小模型先预测接下来的几个token，大模型只需一次前向验算。实测中单token延迟能降低2-3倍。
- 批处理调度：把多个用户的请求合并成一个batch，让GPU在连续的token生成中保持满负荷。
4.2 本地部署的两次跃迁：从Ollama到ONNX Runtime
这一轮架构演进的另外一条线，是LLM正在从云端大规模推理走向个人电脑本地运行。带动这个趋势的有两个关键变化：一是开源LLM大模型（如Llama系列、Qwen系列）的授权和性能达到了可用的水平；二是内存和显存的容量开始能放下中等规模的量化模型。
谈到本地部署架构，目前最典型的是Ollama这类一键式工具。Ollama把模型下载、量化格式转换、推理服务和命令行交互整合在一起，基本做到了"装一个软件，pull一个模型，就能开始对话"。它为什么火？因为它把过去需要折腾CUDA环境、手动安装依赖、写推理脚本的过程全部封装掉了。对普通用户来说，本地部署的门槛降到一个下午能搞定的程度。
但如果要做正式的集成应用，我更推荐关注ONNX Runtime这条路线。ONNX是一个开放的模型交换格式，把PyTorch、 TensorFlow等不同框架训练出的模型统一转化为标准计算图，然后在ONNX Runtime上跨平台高效推理。它的优势在于：
- 统一的模型导出和优化流程（包括图优化、算子融合、量化）；
- 支持CPU、GPU、NPU等多种执行后端；
- 在Windows/Linux/移动端都能跑，是端侧部署的现实选择。
我之前在一个端侧文档摘要项目里尝试过，把7B模型用ONNX格式结合4-bit量化，在一台16GB内存的笔记本上CPU推理，速度大概每秒能出8-12个token。虽然不足以做实时对话，但做离线批量摘要任务完全可行。
注意：本地部署时最容易踩的坑不是模型跑不起来，而是量化等级和任务需求的错配。对话闲聊场景下4-bit几乎感受不到差异，但在代码生成、数学推理这类对精确度敏感的任务上，量化损失会导致明显的错误率上升。我的建议是先从8-bit开始测试，确认实际任务表现可接受后再尝试压缩，而不是一上来就追求最小显存占用。
4.3 应用集成架构：LLM如何接入业务系统
部署模型只是第一步，把LLM大模型真正接入业务系统又是一层架构问题。最近见到了不少基于Spring AI的方案。Spring AI是Java生态里的一套AI集成框架，它把"模型提供商接口""向量数据库""结构化输出解析""RAG模板"这些通用能力都封装成标准组件，开发者只需要配置好模型端点，就能在现有Spring Boot服务里直接注入一个LLM客户端。
这种集成框架的价值在于两点。一是屏蔽模型厂商差异——不管是调用云端的GPT接口还是本地通过Ollama启动的模型服务，API接口形式统一，切换模型只需要改配置文件。二是补齐企业级能力——事务回滚、错误重试、超时控制、请求日志这些在生产环境必须有的能力，单靠自己封装往往会被忽略，而框架已经内置了。
架构上我建议把LLM推理放在独立的服务进程里，和核心业务服务做HTTP或gRPC通信，而不是为每个业务方法都同步调用模型。LLM单个请求的耗时在秒级，甚至可能几十秒，同步调用会拖垮主业务的响应时间。异步消息队列+任务结果是更稳的方案。
5. 多模态与Agent化：LLM开始"长出"手脚
5.1 多模态大模型：把视觉、音频都塞进同一个上下文
LLM技术架构的又一次跃迁，是从"纯文本模型"走向"多模态模型"。传统做法是给图像配一个视觉编码器，再通过一个映射层把图像特征对齐到文本token空间。现在更主流的全模态架构则是直接把图像切成patch，与文本token混在一起进入同一个Transformer主干，用同样的自注意力机制统一处理。这个架构上的统一意味着：模型不是"看看图再翻译成文字"，而是真的在"同时理解文字和图像"。
多模态的工程价值非常直接。以前做"图片里有没有安全隐患"检测要单独训练一个视觉模型，现在直接问LLM"请描述这个画面里的异常"，得到的答案不仅准确，还能兼顾上下文——比如"这个工人没戴安全帽，而且背景里有一处火花"——这种跨模态推理能力是纯视觉模型做不到的。像空间LLM（spatial LLM）则在向三维空间理解延伸，未来在机器人控制、自动驾驶这类场景里会有更深的渗透。
5.2 Agent架构：从"回答问题"到"完成任务"
如果说RAG补齐了LLM的知识短板，那么Agent架构就是在补齐LLM的"手脚"短板。大模型本质上是一个超强的"大脑"，但它不知道如何查数据库、如何调用API、如何操作浏览器。Agent架构把这个大脑接上了一个工具层：
- 用户给出一个任务；
- LLM进行任务规划，拆解成多个子步骤；
- 每一步调用相应的工具（代码执行器、搜索接口、数据库查询、文件读写）；
- 工具返回结果后LLM再决策下一步；
- 全部子步骤完成后再汇总输出。
这个架构最重要的组件是function calling（工具调用）。模型输出一个结构化的调用意图，比如{"函数名": "search_docs", "参数": {"关键词": "安全帽"}}，然后由宿主程序去执行这个调用。很多人碰到"provider rejected the request schema or tool payload"这类报错，根源就在于模型输出的函数调用格式与服务端期望的schema不一致。排错的核心思路是先打印出模型实际输出的function call对象，对比服务端定义的tool schema，而不是凭空猜测。
Agent架构还有一个衍生玩法叫LLM as Judge——让一个大模型去评估另一个模型的输出质量。这个思路在自动评测、数据筛选、RAG效果评估里很常用。你可以用GPT-4级别的模型当裁判，对一批生成结果打分，跑一轮批量评测，得到结论后再人工抽检一小部分验证裁判的可信度。架构上要注意的是，裁判模型的提示词必须包含明确的评分维度（如"准确性""完整性""格式规范性"），并且每次只评估一个输出，否则分数漂移会很严重。
6. 微调、评测与排行榜：能力进化的底层反馈回路
6.1 微调架构的演进：从全量微调到LoRA
LLM大模型的训练流程早已不是"预训练-微调-上线"这么简单的三段式。全量微调的代价太大——7B模型全参数微调就需要几十GB显存，70B模型更是只有大厂玩得起。于是参数高效微调成了主流。LoRA（低秩适配）的做法是冻结原始权重，在旁边加两个低秩矩阵作为可学习参数，训练时只更新这两个小矩阵。这样训练显存占用能降到全量微调的几分之一，训练完成后把两个小矩阵合并回原模型即可。
LoRA之所以好用，不只是因为省显存。更重要的是它保留了一份"干净的原模型"——如果你用LoRA做了一版"医疗问答微调"，发现效果不理想，直接丢弃LoRA矩阵就行，原模型完好无损。这就让"一个底座模型，多领域并行微调，按需加载"的架构成为可能，彻底改变了模型的迭代模式。
6.2 评测架构：Open LLM Leaderboard与"结构化的偏见"
大模型领域做任何技术选型，都绕不开排行榜。Open LLM Leaderboard作为公开的评测榜单，长期是社区选模型的重要参考。它用一套统一的benchmark（涵盖知识问答、推理、代码等维度）对开源模型打分、排序。
但我对排行榜的使用有一个忠告：排行榜分数和你的真实任务表现往往存在明显偏差。原因有三点：
- 蒸馏与污染：很多榜单题目在训练数据里出现过，模型"背过答案"而不是"会做推理"。
- 评测集自选偏差：某些模型针对榜单题目做过定向调优，换了题目就不灵敏了。
- 任务类型错配：排行榜覆盖的是通用场景，而你的业务可能是"契约审查"这种垂直任务，两者分布完全不同。
所以更务实的评测架构是"公开榜单做粗筛 + 自建评测集做精测"两步走。自建评测集一定要从你的真实业务数据中采样，准备50-100道标注了标准回答的题目，跑到模型上打分，再做排序对比。这个成本远低于一次全量微调，但价值远高于参考任何榜单位置。
6.3 微调之外的能力调整方案对比
大模型微调热词搜出来的文章很多，但如果你去问一线工程师，会发现他们现在对"动不动就微调"越来越谨慎。原因在于微调的三个副作用：灾难性遗忘（学会了新任务，忘了老能力）、数据过拟合（训练集之外的泛化能力下降）、成本仍然不低。
完整的模型能力调整梯次应该是：
| 调整手段 | 适用场景 | 成本 | 风险 |
|---|---|---|---|
| 提示词工程 | 快速验证、临时需求 | 极低 | 不稳定 |
| 上下文工程/RAG | 知识问答、私有知识库 | 中（建索引） | 低 |
| 指令微调 | 任务格式固定、输出规范要求高 | 中 | 中 |
| LoRA领域微调 | 垂直领域、专业词汇密集 | 中高 | 中 |
| 全量微调 | 底座能力改变、新语言 | 极高 | 高 |
我的经验是：先RAG，再提示，最后才考虑微调。多数业务问题根本轮不到微调，RAG加精心设计的上下文工程就能解决。只有当任务要求"模型的说话风格、输出格式固化到参数层面"时，微调才真正有价值。
6.4 回看整体架构演进：三条主线贯穿始终
通读整个LLM大模型技术架构发展史，你会发现演进虽然快，但秩序感很强。核心就是三条主线：
第一条线是算力效率。从RNN串行到Transformer并行，从全量微调到LoRA，从FP16到4-bit量化——每一步架构调整都在做同一件事：用更少的算力做更多的事。第二条线是能力边界扩展。从纯文本到多模态，从闭卷记忆到RAG检索，从单一对话到Agent工具调用——模型的能力边界一直在外扩。第三条线是对齐工程。从预训练到指令微调，从RLHF到LLM as Judge评测——我们在不断让模型输出更接近人类真实意图。
我个人在实际操作中最深的体会是：架构演进看起来很高级，但落到每家团队的具体实践里，真正可靠的永远是小步快跑。先用现成榜单和公开模型跑通业务链路，再根据真实反馈决定要不要动RAG、微调还是干脆换更大规模的模型。历史的教训就摆在那里——BERT当年横扫一切榜单，但最终胜出的是那个看起来更慢热的路子。技术架构没有永恒的王座，只有持续贴近真实需求的人才能一直留在牌桌上。
