我身边不少搞算法的朋友上手大模型就是直接调对话式API。跑文本分类、做实体抽取、相似度匹配全走同一套生成式接口结果有时候能用有时候特别离谱。其实问题不在模型能力而是大多数情况下把架构选错了。大模型的三大主流架构——Encoder-only、Decoder-only和Encoder-Decoder——背后是三种截然不同的建模逻辑。理解它们的区别你就能明白为什么BERT系模型做分类又快又稳为什么GPT系模型擅长续写和对话为什么翻译、摘要这类任务又得靠T5这种双向编码加自回归解码的杂交体。这篇东西我尽量讲人话不给废话带着原理、选型思路和可以直接跑的示例代码帮你把这件事彻底理清楚。适合人群也很明确刚入坑大模型的应用开发、算法工程师以及做技术选型时需要“知道自己在干什么”的团队负责人。纯做学术研究的可以当复习读但重点还是落在工程实践上。1. 先把地基打牢Encoder和Decoder到底是什么1.1 一切架构的核心编码器负责读解码器负责写要搞懂三大架构绕不开Transformer最基础的两个组件编码器Encoder和解码器Decoder。你可以把编码器理解成一个“精读型读者”。它接收一段文本不急着输出内容而是把整句话从头到尾扫一遍一边读一边建立每个词和全句其他词之间的关联。这个过程叫上下文建模产出的是每个词对应的隐藏状态向量。这些向量不是简单的词向量而是融合了整句话语义的“理解结果”。解码器则更像一个“接龙选手”。它在一个时间点只能看到自己已经写过的内容然后根据这些内容预测下一个词是什么。写下一个词之后这个词又加入输入继续预测后面那个词。这种逐个词往外蹦的生成方式术语叫做“自回归”。一个最直观的区分方法编码器是一次性读完整句再干活解码器是那句写一句边看边猜。理解这一点后面看三大架构就非常轻松了。1.2 注意力机制的两种形态双向注意力与因果注意力为什么编码器和解码器行为差异这么大本质是注意力掩码Attention Mask的设计不同。双向注意力允许当前位置的词同时看到它左边和右边的所有词。比如“今天天气真不错”对“天气”这个词而言它既能利用“今天”也能利用“真不错”。这对理解任务特别有利因为在判断“天气”的感情色彩或语义角色时后文往往比前文更关键。因果注意力也叫自回归注意力它规定当前位置的词只能看到自己和它之前的词看不到未来。还是那句话“今天天气真不错”计算“真”的时候模型能看到“今天天气”但看不到“不错”。这是生成任务的硬性要求现实世界写作就是从前写到后你不能先看到后面的内容再决定前面怎么写。表格对比更清楚类型能看到的信息典型使用位置适合任务双向注意力左右全部上下文Encoder分类、抽取、匹配因果注意力仅左侧历史内容Decoder续写、对话、生成理解了这两种注意力三大架构其实就是“怎么组合编码器和解码器”的三种方案。2. 三大架构全景拆解各自解决什么问题2.1 Encoder-only理解类任务的最优解Encoder-only架构通俗说就是“只有一个精读模型不负责写”。它把输入文本全部编码成向量然后直接在这个向量序列上接任务头——分类头、序列标注头、相似度计算头。所有参数都服务于“理解”这件事。比Encoder-only更准确的说法应该叫“双向编码架构”。它的标志性特点是全程使用双向注意力最广为人知的代表就是BERT系模型。这类架构的预训练目标通常是“掩码语言建模”MLM随机遮住输入里一部分词让模型根据上下文把被遮住的词猜出来。比如输入“今天天气[MASK]不错”训练模型预测[MASK]位置是“真”。这个任务迫使模型学会在理解句子时兼顾前后双向信息。Encoder-only在真实工程里的地位远超大多数人的想象。文本分类、情感分析、命名实体识别、抽取式问答、语义匹配、检索排序这些任务在生产环境里的首选方案十有八九是Encoder-only模型而不是生成式对话大模型。为什么因为理解任务需要的不是“想出一个答案”而是“判断输入的标签是什么”“找到输入里哪个片段是实体”。双向注意力天然适合这类判断信息利用率高参数量相对小推理速度快成本低。我在实际项目里最常用的经验是如果业务方提的需求是“帮我判断”“帮我识别”“帮我抽取”先上Encoder-only模型通常一个几十万条数据的微调任务在小规模模型上跑几十分钟就能拿到还不错的基准结果。2.2 Decoder-only生成任务和通用大模型的主流方向Decoder-only架构就是“只有接龙选手没有精读模型”。它的核心机制是因果注意力加自回归生成每个位置生成下一个词时只能依赖之前已经生成的内容。现在市面上绝大多数对话大模型、写作大模型、代码生成模型底层都是这个东西。代表就是GPT系模型及其一系列衍生品。它们做预训练时用的目标也简单就是“下一个词预测”给定前文预测后面那个词无限重复这个动作。看起来简单到有点无聊但海量数据和巨大参数量堆上去之后涌现出对话、推理、遵循指令这些高级能力。Decoder-only为什么能成为大模型时代的主流我拆成三点讲第一它把任务形式统一了。不管是写作文、写代码、翻译、做数学题还是抽取信息在Decoder-only面前通通可以表达成“前缀文本生成补全”的形式。你给模型一段指令和上下文它一直生成到你让它停。这种统一性极大简化了产品架构一套推理逻辑适配无数业务。第二它的训练过程非常稳定。因果注意力有天然的时间顺序限制不会像双向模型那样出现信息泄漏的问题预训练目标固定不变模型只需要学会预测下一个词工程上实现简单分布式训练也好处理。第三它在扩展性上表现极佳这和自回归任务本身的性质有关。训练数据几乎是无限量的——互联网上所有文本都可以让模型“续写”不需要人工打标。模型越大、数据越多生成能力越强这个规律在Decoder-only上表现得很稳定这也让它成了大厂和研究机构最喜欢押注的路线。当然Decoder-only也有明显短板它天生看不到后文在做需要全局理解的任务时会吃亏。后面第3章我会说清楚哪些场景用它反而效果差。2.3 Encoder-Decoder理解与生成通吃但成本更高第三种架构是Encoder-Decoder也叫Seq2Seq架构。它把“精读模型”和“接龙选手”拼在一起前面一个双向编码器读完整输入产出理解向量后面一个因果解码器根据理解向量和已经生成的内容逐词往外蹦。代表是T5系、BART系模型。这类架构的预训练目标通常是“文本填空”或者“噪声恢复”把原文破坏掉一部分让模型重建完整文本。做完预训练之后再用特定任务数据微调让解码器输出指定格式的内容。Encoder-Decoder最适合的场景就是输入和输出是两段不同文本的任务机器翻译、文本摘要、风格改写、表格转文本、数据到文本生成等。原因很好理解双向编码器能充分理解输入的意思自回归解码器又擅长把“理解结果”转成自然语言输出各干各的活互不干扰。但它的缺点也很直观参数规模比单架构模型更大训练和推理成本更高。而且在实际工程里很多任务用Decoder-only硬改一下也能做导致Encoder-Decoder的位置越来越被挤压。目前它像一个“老牌精品工具”不是最热门但在输入输出强差异场景下依然有不可替代的价值。三大架构放一张表看全家福架构注意力机制代表模型类型主打能力典型任务Encoder-only双向BERT系理解分类、NER、匹配、检索Decoder-only因果GPT系生成对话、写作、代码、推理Encoder-Decoder双向编码因果解码T5系、BART系理解生成翻译、摘要、改写3. 架构选型不是追热点任务类型决定一切3.1 从任务类型反推架构的通用决策表很多人选模型的方式很简单粗暴看别人说哪个强就用哪个。但落地到业务生产最可靠的选型逻辑是先列任务类型再倒推架构。我总结了一个基本决策表按这个选基本不会跑偏任务类型需求本质推荐架构理由文本分类/情感分析输入到标签的映射Encoder-only双向信息利用率高参数少部署快实体识别/信息抽取输入到连续标签序列Encoder-only依赖全局上下文判断边界语义匹配/相似度计算两段文本的关系判断Encoder-only双塔或交互式编码都能高效处理文本检索排序query与doc相关性判断Encoder-only可以把文档向量化后做相似度检索自由对话/写作续写前缀到补全文本Decoder-only自回归生成顺畅、风格自然代码生成自然语言到代码Decoder-only生成能力强且支持长距离依赖机器翻译源语言到目标语言Encoder-Decoder双向理解源句自回归输出译句文本摘要长文本到短文本Encoder-Decoder双向把握全文重点生成连贯摘要看到没有任务需求是“判断”的基本Encoder-only能扛任务需求是“生成新内容”的Decoder-only上任务需求是“先全局理解再重新表述”的Encoder-Decoder更稳。3.2 为什么Decoder-only不能通吃所有任务这里要专门说一个很多人踩过的坑既然Decoder-only大模型那么强为什么不用它来做分类、做NER我是真见过直接把分类任务包装成“让模型输出标签名称”然后硬跑的效果偶尔行但极不稳定。原因有几个层面Decoder-only的自回归解码路径决定了它只能按顺序消费信息。做分类时理想情况是模型“看一眼全文综合判断”但Decoder-only被设计成“从头读到尾然后开始编下一段”。这个“判断”过程被拆成了无数个生成步每步只做一个局部的、基于前文的预测全局信息利用率天然低于双向模型。更关键的是分类任务需要的是“决策边界”而不是“语言流畅度”。双向模型把文本编码成一个高维向量向量里浓缩了全文语义分类头在这个向量上做非线性变换输出类别概率。这个过程是显式、可控制、可调试的。而让Decoder-only通过文本生成来“表达”分类结果本质上是在要求一个接龙选手去完成“判断题”效率低且行为不可控。当然大参数量的Decoder-only模型靠海量知识和强大的隐含推理能力能在很多理解型任务上达到不错的成绩。但工程上要考虑成本一次文本生成调用消耗的算力是同等规模Encoder-only模型推理的上百倍延迟还高。同样的任务用Encoder-only模型微调后上线可能十几毫秒就出结果而Decoder-only得几秒钟。所以在真实项目里我的习惯是第一原则“能判断就别生成能抽取就别对话。”3.3 参数量、部署成本与场景匹配的平衡点架构选型不只是效果问题还是资源问题。Encoder-only模型从千万参数到几亿参数已经能覆盖大多数理解任务同效果级别的Decoder-only模型往往要冲到几十亿甚至上千亿参数。举个例子。一个参数量的BERT类模型在普通GPU上做推理单条请求延迟通常低于50毫秒显存占用几个GB。反观同业务用生成式大模型来做要么上几十GB的显存部署要么走外部接口每次调用都付钱一次调用输出的Token数量还不可控。这不是说Decoder-only不能用而是说你的业务是否真的需要那部分“生成能力”如果只是做文本分类你调一个大模型输出一个“积极”或者“消极”的单词和用一个小型Encoder-only模型直接输出一个概率分布哪一个更符合工程上的成本效益答案一目了然。当然纯业务复杂度高的场景比如多轮对话、复杂指令执行Encoder-only确实搞不定这时候果断上Decoder-only不需要犹豫。选型的核心永远是“任务需要什么能力”而不是“什么模型听上去先进”。4. 实操环节三类架构的上手示例4.1 工具准备与模型加载思路动手之前先准备环境。主流的开源模型库简化了大模型的加载与使用流程安装好Python环境后一行命令就能装上依赖。模型权重也分好类按架构找对应的预训练权重即可。你不需要从零训练一个大模型绝大多数场景都是“加载预训练权重 在业务数据上微调”。预训练权重已经掌握了通用语言知识微调只是让它适配你的具体任务格式。我下面给三段代码分别对应三类架构都保持在“能跑通”的最小规模方便你直接照搬改业务。4.2 Encoder-only实战五步跑通一个文本分类模型以中文情感分类为例用Encoder-only架构微调一个模型这是所有任务里最常见、也最容易上手的热身项目。from transformers import AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments from datasets import Dataset # 1. 准备数据每条样本包含text和label两个字段 train_data [ {text: 这家店的菜品真不错下次还来, label: 1}, {text: 上菜太慢了再也不来了, label: 0}, ] # 2. 加载tokenizer和模型num_labels按任务设置 model_name bert-base-chinese # 实际使用时替换成你要用的预训练权重 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSequenceClassification.from_pretrained(model_name, num_labels2) # 3. 数据编码 def encode(batch): return tokenizer(batch[text], truncationTrue, paddingmax_length, max_length128) dataset Dataset.from_list(train_data).map(encode, batchedTrue) # 4. 配置训练参数并启动训练 training_args TrainingArguments(output_dir, num_train_epochs3, per_device_train_batch_size4) trainer Trainer(modelmodel, argstraining_args, train_datasetdataset) trainer.train()第4步开始模型就在你的数据上自动调整参数了。训练完保存模型后面做推理时加载同一个权重输入一句话模型输出各个类别的概率取概率最大的那个就是预测结果。这种流程适配性极强。情感分类换成文本分类改一下label定义就行要改成抽取式问答或实体识别把输出头从“分类头”换成“序列标注头”整体思路完全一致。4.3 Decoder-only实战用生成方式实现文本续写与对话Decoder-only的使用方式和Encoder-only完全不同不需要接分类头而是直接让模型生成。from transformers import AutoTokenizer, AutoModelForCausalLM model_name gpt2 # 换成更大的中文生成模型效果更好 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) prompt 人工智能的未来在于 inputs tokenizer(prompt, return_tensorspt) # 生成时可以通过参数控制风格 output model.generate( inputs.input_ids, max_new_tokens50, do_sampleTrue, temperature0.8, top_p0.9 ) print(tokenizer.decode(output[0]))这里的关键在generate函数的参数。temperature控制随机性值越高越放飞越低越保守top_p做采样的概率截断保留累积概率90%的候选词一起参与抽样。做创作类任务可以调高温度做事实性要求高的任务就调低温度同时可以加repetition_penalty来减少重复。Decoder-only的真实应用往往不止单轮生成要处理多轮对话时把历史消息拼成一段文本喂给模型要加上下文约束时把系统提示词拼在最前面即可。这类架构特别适合“开放域输出”的业务比如智能客服话术生成、报告草稿生成、代码自动补全。4.4 Encoder-Decoder实战摘要生成的最小流程最后看Encoder-Decoder。它和Decoder-only一样是做生成但多了个双向编码阶段更适合“先读完再改写”的任务。文本摘要就是一个典型输入一篇长文章输出一段简短的摘要。from transformers import AutoTokenizer, AutoModelForSeq2SeqLM model_name t5-base # 英文学术场景可换更大权重 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSeq2SeqLM.from_pretrained(model_name) article 大语言模型在过去几年发展迅速不断刷新各种自然语言处理任务的纪录。... inputs tokenizer(summarize: article, return_tensorspt, max_length512, truncationTrue) summary_ids model.generate(inputs.input_ids, max_new_tokens100, num_beams4) print(tokenizer.decode(summary_ids[0], skip_special_tokensTrue))留意输入里加了“summarize: ”前缀。这就是Seq2Seq模型和普通Decoder-only的区别之一输入侧可以附带任务指令模型把指令和内容一起编码再进入解码阶段。num_beams4是束搜索的宽度。束搜索和采样是两种不同的生成策略采样有随机性适合对话和创作束搜索倾向于选概率最高的若干路径适合摘要、翻译这类需要稳定输出的场景。实际项目中做摘要是很常见的不需要自己训练很多中文摘要模型权重可以直接拿来用效果基本能满足需求。5. 架构选错和生产环境里那些麻烦事5.1 分类任务硬上Decoder-only效果差还不稳定很多团队喜欢“一个模型打天下”所有的任务都让生成式模型去做但问题会在实际评测中暴露得很直接。文本分类这种任务训练样本里标签是固定的关键在于精确建模输入到标签的映射。Decoder-only生成的答案天然带着随机性就算同一个输入同一个模型温度设置不同输出的内容都可能变。你把它用在需要严格稳定输出的业务场景里用户反馈“时灵时不灵”是必然的。而且自回归模型在长上下文中做分类时为了生成一个标签需要生成一堆分析过程词这些词位置靠后在残差连接和注意力叠加下早期关键信息很容易被稀释。双向编码模型不存在这个问题它直接把全文信息压缩进最后一层每个位置的隐藏状态里分类决策的所有依据都还在。所以我的经验是如果业务对输出格式和稳定性有硬性要求直接选Encoder-only。省下的推理成本、减少的线上波动比“模型听起来更高级”值钱得多。5.2 双向模型不等于推理更聪明它有天然的天花板Encoder-only模型不是万能的。很多人把BERT类模型当成“大模型”指望它做逻辑推理、常识问答效果往往非常失望。原因在于预训练目标决定了能力边界。掩码语言建模培养的是“根据上下文猜词”的能力这种能力确实能支撑一部分理解任务但猜词和推理是两件事。你在一个Encoder-only模型后面加一个分类头它能判断句子感情色彩但让它一步步做数学推导、理解复杂指令它毫无办法因为参数从头到尾没有为“生成推理步骤”做过优化。所以做架构选型时别犯另一种错明明要写长文、要逻辑推理偏偏选了个双向编码模型。双向模型是效率高的理解者但绝不是生成者。5.3 上下文长度不够用三条实用处理思路生产环境里文本长度是个很常见的问题。微调Encoder-only模型时输入序列长度经常被截断成128到512个Token遇到长文本合同、长文章直接截断就把关键信息截没了。解决办法有三条第一是采样策略。长文本分段每段单独编码做预测最后聚合结果。比如做长文档情感分析把文章切成多个片段分别判断再投票。第二是层次化建模。先用一个小模型把长文本编码成多个句向量再把这些句向量作为输入喂给上层模型相当于做二级聚合效果比简单截断好很多。第三是直接用支持长文本的模型结构。现在很多模型权重已经支持几K甚至更长的上下文但要注意显存消耗和推理效率之间的平衡。5.4 微调Decoder-only模型时最常见的翻车点微调Decoder-only不光是训练资源问题还有一些典型的翻车点。损失不下降。这通常不是模型问题而是数据格式问题。Decoder-only通常用“提示词目标回答”拼接的格式训练如果拼接格式里分隔符不统一模型很难学会“提示词是输入回答是输出”。训练数据里要明确用特殊分隔符区分输入和输出。生成重复。这几乎是自回归模型的通病尤其是在自写数据集质量不高的情况下。对应措施是加重复惩罚参数、调高温度或限制生成长度。如果是拿人工语料继续训练先做好数据清洗。损失下降但生成内容不相关。这往往是因为训练时用教师强制(teacher forcing)每个位置都喂真实目标词模型学会了“看到正确答案后继续生成”但推理时每一步喂的是自己生成的内容一旦第一步产生一个小偏差后续就会越偏越远。对策是训练时引入部分自生成内容作为输入或者直接做两阶段训练先预训练再指令微调。把这些坑都踩过一遍你对Decoder-only的理解才算真正落地。6. 从实际项目反推该不该把所有业务都换成Decoder-only6.1 Decoder-only统一趋势的根源最近一段时间Decoder-only已经成了大模型领域事实上的主流方向。新的预训练模型大多采用Decoder-only架构很多以前用双向模型的任务也开始尝试切换生成式方案。这个趋势的根源不只是生成效果好。更核心的是任务形式统一。Decoder-only天然把各种任务改写成一个统一的“前缀补全”问题产品层可以复用同一套接口、同一套部署方案推理服务不用为每种任务做定制开发这是工程成本上的巨大优势。还有一个原因是大规模预训练的经验积累让Decoder-only模型在“指令跟随”“上下文学习”等能力上表现更稳定。随着模型规模变大、基座能力增强很多以前需要专门的模型结构才能做好的任务现在用Decoder-only配合恰当的提示词也能完成得不错于是换架构的动力就更强了。6.2 但别跟风理解型任务在中小规模场景仍然更香趋势归趋势回到具体业务我始终建议先算账。一个只有几万条训练数据的中小团队做的是售后评论情感分类用Encoder-only模型微调一台普通GPU几小时就能完成部署后单条推理在十几毫秒内返回显存开销小可以轻松支撑每秒几百次的调用。同样的业务换Decoder-only方案要么自建推理服务需要几倍显存和算力要么走外部接口每一次调用都产生费用和网络延迟。即便效果好一点点这个成本差异已经足够让绝大多数中小场景做出选择。所以我的判断是如果业务是强理解型任务训练数据量中等对延迟和成本敏感Encoder-only依然是性价比之王。Decoder-only的普及不意味着其他架构被淘汰它只是给了我们更多选择而选择的关键永远是“划不划算”。6.3 一套通用评估框架当你真正面对选型问题时把方法论沉淀成一套可复用的评估框架每做一个新任务你可以按这五个问题来走评估问题若回答“是”若回答“否”任务输出是固定标签集合吗优先Encoder-only考虑Decoder-only任务需要开放域长文本输出吗优先Decoder-only考虑Encoder-only输入和输出是两种不同结构的文本吗优先Encoder-Decoder单一架构即可业务对延迟和部署成本敏感吗优先Encoder-only选Decoder-only提升能力团队有能力做数据清洗和指令微调吗可考虑Decoder-only先选低门槛架构这套框架不是死规则但大部分项目按它走都不会犯大错。架构本身是手段业务效果才是目的先把这一点想明白后面所有选择都会顺很多。最后说点个人体会。我做过的项目里凡是老老实实按任务类型选架构的后续维护都很轻松凡是贪图“先进”硬上一个高大上方案的几乎都在部署、稳定性和成本上付出过代价。三大架构没有谁取代谁的问题只有谁更适合你的任务。把这篇里的原理和决策表吃透下次再做技术选型你就不会再被各种大模型的营销话术带偏了。