大模型用起来很简单：一个输入框，一段回答。真要上线跑业务，问题立刻变成一堆——为什么它记不住上一轮定下的约定？为什么同一个问题问两次答案不一样？为什么加个检索突然就准了，加错了又悄悄变差？

这些答案不在 API 文档里，在它的内部实现里。这个系列把它拆开，一个零件一个零件看：它怎么读、怎么记、怎么忘、怎么伸手调工具。你不需要机器学习背景，但得写过业务代码、知道接口和索引是什么。十三篇读完，这三个问题会有答案：这个需求该不该用大模型、该在哪一层解决、出了问题该往哪儿查。

大模型这一路是怎么长过来的，决定了它为什么会记不住、会编、两次答得不一样。

一、五跃：每解决一个旧问题，就暴露一个新问题

大模型这九年（2017–2026），是五次「解决旧问题、暴露新问题」的接力。 每一跃解决的，都是上一跃留下的麻烦。

第一跃｜2017，Transformer。

在这之前，模型读文本是「一个字一个字念」的——RNN（循环神经网络）每读一个词，就把当前的理解压成一个状态，和下一个词一起送进下一步。这带来两个死结：只能串行计算，GPU 闲着；句子一长，前面的信息就衰减没了。Transformer 是 2017 年提出的一种新的模型结构，专治这两个死结：它把「按顺序读」换成「同时看全部，再决定该关注谁」，一次并行计算处理整段文字。它真正的意义在于让并行成为可能；而只有能并行，模型才堆得大。

第二跃｜2018–2020，预训练 + 微调。

以前工程师每做一个功能，都要一份标注数据、从零训一个模型：做情感分析训一个，做问答再训一个。到这一代，做法变了：先用海量没标注过的原始文本预训练一个「懂语言」的底座，再拿少量标注数据微调，把它调到能干这件事。从此模型可以复用了，不必每次都从零训。

这里有个常被忽略的分岔。2018 年前后同时起步了两条路线：Google 的 BERT 走「双向理解」，把一句话挖空让模型填；OpenAI 的 GPT 走「单向生成」，永远接着往下写。当时 BERT 在榜单上更风光，但最后赢的是生成路线。原因很简单：能生成，就能把「判断」改写成「续写」；只会理解，变不出生成能力。

原版 Transformer 是为翻译设计的，两个半边分工明确：编码器先把整句英文读完，压成一串数字；解码器拿着这串数字，一个词一个词写出中文。

生成路线把编码器整个去掉了，那输入怎么办？输入不再被「读懂」，而是直接被当成前文——你的 prompt 因此只是一段「已经写了一半的文本」，模型接着往下写。所以今天几乎所有大模型都只有这一半，叫 decoder-only（只有解码器）。

问答只是其中一种用法。你让它判断一句评论是好评还是差评，它同样是接着往下写：第一个词写「好评」，这句评论就被判成了好评；第一个词写「差评」，就判成差评。判断结果不是一个额外的动作，它就是那个词本身。

第三跃｜2020，做大就变强。

微调范式留下了新问题：一件事一套模型，太碎。 而把模型做得更大、喂的文本更多之后，出现了意外收获：**不用微调，只在输入里给几个例子（few-shot），它就能干没训过的事。**这一跃把「一件事一套模型」变成了「一套模型干好几件事」。

第四跃｜2022，RLHF 对齐。

模型够大了，但它仍然是个「接龙选手」：你问它问题，它可能接着你的话往下编，而不是回答你。RLHF（基于人类反馈的强化学习）的解法是让人来当裁判：同一个问题给几个回答，人来排好坏，再拿这个排序去调模型。「续得像」就这样被掰成「答得让人满意」。

ChatGPT 是分水岭的真正原因：它终于肯好好回答问题了。

第五跃｜2023–2026，多模态、长上下文、推理模型、Agent 化。

对齐解决的只是「不肯好好回答」，没解决「答得对不对」。奖励来自人的偏好，而人偏爱流畅、笃定的回答，于是「听起来有把握」也被一起强化了：它开始自信地编。 后面几项改进补的就是这个洞：能看图（信息不只来自文字）、能装更长的上下文（少忘事）、会先想再答（推理模型把思考过程也写成一串文字，先写出来再回答）、能调工具（不确定的事去查、去算、去做）。它们补的都不是知识，是「说得好听、不管真假」这个毛病。

没有哪一跃是凭空的灵感，每一跃都是被上一跃的问题逼出来的。 五次接力下来，能力换了一整套，可它干的那件事九年没变：拿到前文，猜下一个词。 下一节就拆这一句。

二、一句话本质：它在猜下一个 token

大模型是一个函数：给定前面的所有 token，输出下一个 token 的概率分布。 它做的是续写。推理引擎、查询引擎，都是后来贴上去的叫法。

Token 是分词器切出来的文本碎片，大致相当于一个词，或者半个词。概率分布也好理解：给每个候选词都标一个「有多可能」——比如下一个词是「猫」的可能性 0.6、「狗」0.2、「鱼」0.1，剩下的分给别的词。

从这句话出发，能直接推出三件事：

• 它没有「腹稿」。 输出是边算边吐的，第一个字吐出来时，后面的还没定。所以它会「说着说着改口」，也会在算一道要好几步的题时中途跑偏。
• 它的知识是压进参数的规律。 训练时把海量文本压进参数，压的过程必然会丢细节、也会把不常见的组合「抹平」，这就是幻觉的来源（第 04 篇）。
• 它的输出是抽签，不是标准答案。 每个候选词的可能性都摆在那儿，最后选哪个，由 temperature/top-p 这类抽签规则决定（第 01 篇）。同一问题两次回答不同，不是它心情变了。

「续写」这个定位解释了很多被误传的事：它没有在回答前偷偷搜索数据库，也没有一个「想好了再开口」的内部独白。你想让它知道训练之后发生的事，只能把资料塞进上下文（第 08 篇，RAG），或者让它去调工具（第 07 篇）。

知道它在算什么，下一个问题就具体了：它的哪些部分你能改，哪些改不了。

三、三层：你站在哪一层，决定你能改什么

初学者最容易犯的错，是把三层的边界搅在一起——在 prompt 里写「请使用 2026 年最新数据」，指望它突破知识截止日期。问题出在层次错配：知识截止日期长在模型层，prompt 够不着。

层	里面有什么	你能改什么	你改不了什么
模型层	闭源 API（GPT / Claude / DeepSeek 等）、开源权重（Qwen / Llama 等）	选哪一个；调 temperature / top-p；在支持的前提下做微调	参数量、训练数据、知识截止日期
服务层	部署和跑模型的服务、向量库、网关、缓存、监控、限流	部署形态、并发与成本策略、检索方案	模型本身的行为倾向
应用层	Prompt、RAG、Function Calling、结构化输出、Agent	几乎全部	模型能力的上限

两个方向上的错配，各有一个典型：

• 拿应用层的话术去解模型层的约束：知识过期、算不准数、没有你的私有数据，这些在 prompt 里怎么强调都没用，只能外挂检索或工具。
• 拿模型层的手段去解应用层的问题：检索召回不准、输出格式不稳，去微调是杀鸡用牛刀，先改切块策略和 Schema 约束。

判断口诀：先问「这个约束长在模型身上，还是长在你的代码里」。长在模型身上的（知识截止、上下文长度、不会算数），只能绕过；长在代码里的（检索、格式、权限），可以直接改。

层次分清了，剩下就是四条具体的坑——它们在写方案时最先撞上。

四、四条约束：你会在哪儿撞上它

约束	你会撞上的现象	工程上怎么办	专题
会续写，不会查证	关键数字、法规条款、接口签名，它给得很顺，但可能是编的	允许它说不知道；关键结论必须能溯源	04
有知识，但没有「你的」知识	问内部制度、问昨天刚改的接口，它答得像模像样却是旧版本	私有/易变的事实走检索，不进参数	08 / 09
上下文有限，而且会忘	长文档问答答漏中间段；多轮对话忘了开头定的规则	关键信息放首尾；长文档先切块再检索	02
不会「想好了再说」	多步计算、多条件判断，第一步错就一路错下去	复杂任务拆成小步骤；或换推理模型，让它先把草稿写出来再作答	01 / 03

这四条是设计约束，不是待修的 bug。把它们当物理定律，方案会稳很多——你不会指望一把锤子拧螺丝，也不该指望模型的参数里装着你昨天刚改的接口文档。

小结

• 九年五跃，每一跃都在补上一跃暴露的洞
• 本质就一句：给定前文，猜下一个 token
• 东西分三层（模型 / 服务 / 应用），改错了层，努力全白费
• 四条约束是设计约束：只能绕过，不能对抗

思考题

1. 如果有人说「我们换个更强的模型，这个幻觉问题就解决了」，你会怎么回应？（提示：先分辨是它根本不知道、检索没找对，还是抽签随机让两次说法不一样——三种情况解法完全不同。）
2. 你所在团队如果要做第一个 LLM 功能，会落在三层中的哪一层？哪些东西是你能改的，哪些是必须绕开的？（提示：把需求拆成「要它知道什么」和「要它输出成什么样」两部分。）

高频面试题

Q1：为什么 Transformer 取代了 RNN？

A：核心是并行性。RNN 必须按时间步串行计算，句子一长不仅慢，前面信息还会经多次传递衰减。Transformer 的自注意力让任意两个词直接互相看见（不再层层传递），训练可以完全并行。并行 → 模型能堆大 → 能力才涌现，这是它真正的历史意义。

Q2：预训练、微调、对齐，三者分别解决什么问题？

A：预训练学「语言与知识」（海量无标注文本，目标是接下一个 token）；微调学「任务形式」（少量标注数据，让它按特定格式干活）；对齐学「人类偏好」（用排序反馈让它答得有用、无害、诚实）。顺序不能颠倒：没有预训练的语言能力，后两步无从谈起。

Q3：RLHF 之后模型变强了吗？

A：模型的知识容量没变，变的是它挑下一个词时的偏向。RLHF 把偏向从「接得像」挪到「答得让人满意」。副作用同样明显：它会更倾向给出听起来完整的答案，包括在不确定时也如此。听起来更有把握，不代表真的更准，这是线上事故的常见来源。

Q4：闭源 API 和开源权重，工程上怎么选？

A：先看三样东西：数据能不能出内网、调用量对应的成本、要不要改模型行为。数据敏感或要私有化部署 → 开源权重；只是调用、追求效果上限 → 闭源 API；需要稳定格式和低延迟且量极大 → 小参数开源模型 + 约束解码往往更划算。能用应用层解决的（检索、约束、编排），别急着动模型层。

附录：术语速查

这张表不用从头读：遇到不熟的词查一行，第三列是它的出处，需要展开就翻那一篇。

词	一句话	篇
Token	分词器切出的碎片，模型处理文本的最小单位	01
参数	模型里可调整的数值，「知识」就存在这里	04
上下文窗口	一次能看的 Token 上限，输入输出共享配额	02
训练	用海量文本调整参数，把语言规律压进去	04
推理	拿训练好的模型算一次输出，生成 Token	01
微调	在已有参数上再训一小轮，让它适配特定任务	04
对齐（RLHF）	用人类偏好排序，把「续写」掰成「按你的要求回答」	04
temperature	采样温度，调高发散、调低稳定	01
top-p	只从累计概率达 p 的头部候选里采样	01
Embedding	把语义变成向量坐标，用于「按意思找」	05
RAG	先检索资料塞进上下文，再让模型基于资料回答	08
Function Calling	模型输出结构化意图，执行权在你手里	07

不想从头读到尾，读这四篇：01 生成循环 → 02 上下文窗口 → 04 训练三阶段 → 12 全链路。一条线下来：它怎么一个字一个字往外吐、一次能记多长、这些能力是怎么练出来的、一个请求从进门到出口经过哪些环节。这四件清楚，其余篇目用到时再查。

下一篇 01《一个字一个字蹦出来的回答》：它到底怎么一个字一个字往外蹦，以及 temperature、top-p 这两个旋钮在拧什么。