← 返回概念解读

Concept Fable精修版

解码器

Decoder · Transformers

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

边看草稿边写下一句的回信房

驿站有一间回信房,专门替各地商会写回信。老书记每写一句,就把前面写过的内容压在手边,再决定下一句该怎么接。

起初信很短,书记凭经验就能写完。后来回信要包含报价、风险提示、附件说明和客户语气,任何一句写错都会影响后面的承诺。

站长先给书记发了一本套话手册。信看起来更完整,却常常前后矛盾:前面答应三天交付,后面又写需要两周审核。

有人又要求书记写完后统一检查。检查能抓出一部分错,但生成过程本身仍然像一条单行路,早期选择会一路影响后文。

后来回信房换了规矩:每写一个字,都只能查看已经写出的草稿和允许使用的资料,再预测最合适的下一个字。

这种方式很适合连续生成,也让成本清晰可见。信越长,步骤越多;上下文越大,每一步查看的信息越多。后来站长又发现,书记越往后写,越容易被前面的话带偏。早先选了客气语气,后面就会继续客气;前面漏了限制,后面可能越承诺越远。

站长发现,回信房最怕无边界的自由写作。必须给它明确任务、可用资料、格式约束和停止条件,否则它会把顺畅当成正确。后来管事把这次经验写进日常规矩:先看场景,再看边界,最后看失败时谁能接手。只有这些都清楚,漂亮演示才会变成可交付的工作。

最后,驿站明白:会写不是一次吐出答案,而是在受限上下文里一步步续写。每一步都像小决定,累积起来才是整封信。于是回信房增加了停笔规则:写到价格、日期、责任这些节点,要重新查看资料;达到结尾标记就收束,不再顺着文气添枝加叶。续写能力被放进边界里,才适合正式回信。

揭示

这个故事讲的是:解码器

Decoder 是 Transformer 中用于生成输出序列的部分。典型 Decoder 在生成时使用因果掩码,只能关注已生成 token,并逐步预测下一个 token。企业 Agent 中,Decoder 支撑回复生成、代码生成、工具调用参数生成和计划续写;它的推理成本与输出长度、上下文长度和注意力实现强相关。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 回信房:Transformer Decoder
  • 草稿:已经生成的 token
  • 套话手册:静态模板或提示词修补
  • 只能查看已写内容:因果掩码下的自回归生成
  • 下一句决定:next-token 预测过程
  • 信越长步骤越多:生成成本随输出长度增长
  • 最后洞察:生成质量来自每一步受约束的连续决策

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

encoderGPTautoregressive modelcausal mask