第2章 接龙机器的真相——LLM

小A接了个任务：给公司的 AI 客服写第一版问答接口。需求很简单：把用户的问题发给模型，把回答展示出来。他半天就把代码写完了，高高兴兴地跑了几组测试。然后他发现：同一个问题，用户问两次，第一次模型回答得规规矩矩，第二次却冒出一个根本不存在的 API，还一本正经地给出了用法。

参数、模型、代码全一样，结果却差这么多。他把两次输出并排贴在屏幕上，越看越不对劲，把老Z拉了过来。

“是我哪里写错了吗？”他指着屏幕问。

老Z没接话，盯着看了一会儿，反问道：“你觉得，它到底在做什么？”

“在……回答问题？”小A不太确定，“它学的东西多，知道答案。”

老Z不置可否，把电脑转过来，在终端里敲了一行字：“从前有座山，山里有座__”。回车。模型接出两个字：“庙”。

“再来一次。”老Z又敲了一遍同样的话。模型还是接了“庙”。

小A没看懂：“这能说明什么？”

“说明它不知道答案。”老Z说，“换成你，看到‘从前有座山，山里有座’，你也会接‘庙’。你没有查过任何资料，‘庙’就是最顺的接法。它做的也是这件事：读你已经写下的所有文字，猜下一个最可能出现的字。”

比喻：接龙机器

它是一台只做一件事的打字机：读你已经写下的所有文字，然后打出下一个最可能的字。它不知道自己写的是代码还是诗，只知道顺着读下去，这里最该出现什么。

“可它能写代码、能解数学题，”小A不服气，“猜字怎么能猜出这些？”

“你把‘猜下一个字’重复几千遍，看看会发生什么。”老Z在终端里画了个循环图：

输入 token ──> 下一个 token 的概率分布 ──> 采样一个 token
     ^                                      │
     └──────────── 把结果追加回输入 ─────────┘

“给定已有 token，语言模型输出的是下一个 token 的概率分布；选出一个 token，加回输入，再继续。这个过程叫自回归生成：自己接自己生成的结果，滚雪球一样往下滚。”

小A盯着这张图，半天没说话。他想起自己那句“它学的东西多，知道答案”，忽然觉得有点站不住脚。

“所以它输出的‘代码’，是一个字一个字续出来的？”

“对。这就是为什么它有时候给你一个不存在的 API：它不是查过了才写，是顺着读下去，这里‘最该出现’一个 API 调用。所以‘流畅、像真的回答’不能当事实证据。”老Z顿了顿，“‘预测下一个 token’是已确认的模型目标和推理接口层面的事实；但它不能单独证明模型没有内部表征或不能完成推理。工程上更有用的结论是：输出是概率生成的文本，不是数据库查询结果。”

要点

• 大模型的本质是预测下一个 token，不是“查答案”
• 生成方式是确定的（自回归），能力是训练出来的，别混成一句“模型会思考”

先把名字对齐

中文术语	英文全称或缩写	本书工作定义	不等于什么
大语言模型	Large Language Model, LLM	根据输入 token 生成后续 token 概率分布的模型或服务	事实数据库或工具执行器
token／分词器	token／tokenizer	文本被编码成模型处理的离散单位	汉字数、单词数或字符数
自回归生成	autoregressive generation	选中一个 token 后把它追加为条件继续生成	一次取回完整答案
参数	parameters／weights	训练中被优化的数值	每次请求都会写入的记忆
训练	training	用训练目标和数据更新模型参数的过程	一次普通模型请求
模型推理／推断	inference	使用固定参数处理新输入并生成输出	第3章 给思考留一张草稿纸——CoT讨论的 reasoning 过程
上下文窗口	context window	一次请求共同可见的 token 预算	跨请求自动持久化的会话
采样／温度	sampling／temperature	从候选分布选择 token 的过程／调节该分布的常见参数	正确性开关或统一厂商刻度
幻觉	hallucination	看似合理但不真实的事实、引用或代码细节	仅指措辞不够精确
提示词缓存	prompt caching	服务对可复用输入前缀复用计算的机制	正确性或应用侧自动记忆

2.1 它做的是条件续写

那天下午，小A把“接龙”这个说法翻来覆去地嚼，还是觉得不对：模型会写代码、会翻译、会解题，怎么可能只是“接龙”？

他忍不住又去找老Z：“你说它只做接龙，可它明明能干这么多事。”

“那你想想，说‘接龙’的时候，你脑子里最像的比喻是什么？”

“呃……打字机？”小A试着说。

“对，打字机。开头说的‘重复几千遍’，就是这台打字机在干的事。”老Z说，“我拿‘接龙’打比方，是让你先把生成方式抓住；能力是训练出来的，另一码事。这两件事，最容易被混成一句‘模型会思考’。”

要点

“接龙”说的是生成方式（怎么产生下一个 token），不是能力上限。能力是另一回事，后面几章会展开。

2.2 token 是计量单位，不是字数

小A回到工位，开始给接口加用量统计。他本来想按“字数”算账：用户发了几百个字，模型回了几个字，一目了然。可他打开账单明细，愣住了：上面标的不是“字数”，而是一个叫 token 的单位，数字跟他数的字数对不上。

他拿着账单去找老Z：“这 token 是什么？为什么比字数多？”

“它处理的不是‘汉字’，也不是‘单词’，而是分词器切出来的 token。”老Z说，“切分方式随模型而变：一个词、一段代码片段、一个标点，都可能构成一个 token；同一个字符串，在不同模型的 tokenizer 下数量也不一样。拿‘一个汉字等于一个 token’去估算，早晚算错账。”

“那它到底影响什么？”

“三件事：上下文能放下多少输入；输出能生成多长；多数 API 的计量和计费方式。”老Z扳着手指，“写程序时要先数一遍吗？只在接近模型限制、排查成本或设计截断策略时才需要。平时把长日志、整份仓库和重复规则当作有成本的上下文，而不是免费的字符串，就够了。”

“不同语言的文本，token 数差很多吗？”

“差很多。分词器是按训练语料的统计规律设计的：英文里一个常见单词可能就是一个 token；中文的常用汉字多在一个 token 上下，生僻字可能被切成两三个 token；代码里的缩进、括号、标识符各有各的切法。同样长度的文本，换一种语言或换一种内容类型，token 数和费用可能差几倍。”

内容类型	大致 token/字符比	备注
英文常见词	约 0.25（4 字符 ≈ 1 token）	最经济
中文	约 0.5-1.5（1 汉字 ≈ 0.5-1.5 token）	随分词器和字符频率变化
代码	变化很大	缩进、括号、长标识符各自切分
JSON/结构化	偏高	大量标点和引号被单独切分

“这些比例是固定的吗？”

“不是，只是大致量级，精确值取决于具体模型的 tokenizer。”老Z说，“要做精确估算，用目标 API 提供的 token 计数接口，或本地跑对应 tokenizer。没有通用的‘字数 ÷ N = token’公式，N 随模型和内容变。”

“那对上下文管理有什么影响？”

“直接影响截断策略。”老Z说，“按字符数截断历史消息，可能在 token 预算还有余量时就过早截断了（浪费空间），也可能在 token 已经超限时还没截断（请求被拒）。按 token 截断更准确，但前提是能计数 token；没有计数能力时，留出安全余量比卡着上限更稳妥。”

2.3 参数、训练与推理

第二天，小A在调试时随口问了一句：“它这么会续写，是天生就会吗？”

“不是。参数（也常称权重）是模型在训练中学习得到的数值。”老Z说，“训练以大量样本和优化过程更新参数；推理则使用固定参数，对新输入执行前向计算并生成输出。”

“那我也能训练一个吗？”小A的眼睛亮了一下。

“能，但要分清职责。应用开发通常调用推理服务，而不是在每次请求中改变模型参数。”老Z给他列了一张表，“训练和推理的资源形态、成本，以及你能控制的东西，都完全不同。”

阶段	主要动作	应用工程师通常控制什么
训练	用训练目标更新参数	数据、训练方案或模型选择（若参与训练）
推理	用固定参数生成输出	输入、模型、采样、工具和停止条件

“两边成本差多大？”

“好几个数量级。”老Z说，“训练一次大模型需要大量 GPU 跑数周或数月；公开报道常把它描述为百万美元量级。推理一次请求通常按 token 计费，可能落在几分钱到几毛钱量级。这两个量级只用于说明训练与应用推理的差距，【需核实：本节未绑定具体模型、日期和价格来源，不能当价格结论引用。】应用开发者的工作是在推理预算内把任务做好，不是重新训练模型。”

“那微调（fine-tuning）呢？我看很多人在说。”

“微调介于两者之间：用较小的数据集在已有模型上继续训练，调整部分参数。成本远低于从零训练，但仍远高于推理调用。”老Z说，“它适合你有大量领域数据、且通用模型在你的任务上表现不足的场景。但它不是免费的性能提升：微调过的模型在通用能力上可能退步，还需要额外的评测和维护。”

方式	成本量级	适合场景	风险
从零训练	极高（示例量级：百万美元；需核实）	基础模型研发	非应用开发者的事
微调	中等（需数据和 GPU）	有大量领域数据、通用模型不足	通用能力可能退步
推理调用	低（按 token 计费）	绝大多数应用场景	无（只是调用服务）

“那参数越多的模型，是不是一定越聪明？”

老Z摇头：“‘参数更多必然更聪明’不是可靠规则。模型架构、数据、训练方法、推理预算和任务类型都会影响结果，选型应以目标任务的评测为准。”

“评测具体要注意什么？”

“在你的任务上测，而不是在排行榜上测。”老Z说，“排行榜的分数是别人的任务分布算出来的，你的场景可能是长文本、是工具调用、是中文输出；排行榜上的一分之差，换成你的任务可能完全反过来。评测要构造自己的样本集：几组真实任务、几条失败路径、一段固定探针，跑同一份看输出是否满足契约。这样换模型时，你比的就是‘谁更符合我的场景’。”

要点

你作为应用开发者，只做推理：调用已训练好的服务。训练是模型厂商的事，两者成本差着好几个数量级。

2.4 上下文是一次请求的工作台

第三天上午，小A兴奋地跑来找老Z：“我昨天跟模型聊了二十多轮，它全记得！你说它记不住，是不是说错了？”

老Z没有直接反驳，只是问：“你今天发的那条消息里，有没有把昨天说的话也带进去？”

小A一愣，翻了自己的代码：他的实现把整段历史都塞进了每次请求。

“记不住。”老Z说，“每次模型调用都有一个有限上下文：系统指令、用户消息、历史消息、工具结果和当前问题都会占用它。模型本身不会在两次 HTTP 请求间自动记住上一次对话；你看到的‘记得’，是程序把有关内容再次带进了新请求，是应用主动做的事。”

“那不还是记得嘛。”小A有点不甘心。

“你可以把上下文想成一张工作台。”老Z在纸上画了个方框，“桌上能摆的东西有限，摆不下就得取舍；换一个请求，就是换一张新桌子。”

系统规则 + 对话历史 + 工具结果 + 当前输入 + 预留输出
                         └──── 共同受上下文限制 ────┘

“那 maxTokens 是不是就是桌子的尺寸？”小A觉得自己找到了答案。

“只对了一半。maxTokens（或相近命名）通常限制本次期望的输出上限；上下文窗口限制输入与输出的总预算，但不同服务对保留空间和字段名称的定义不同。”老Z提醒，“实现时应读取目标 API 的当前文档，并在请求前预留输出空间，不能只看输入长度。”

“输入和输出都涨，先砍哪个？”

“先砍‘可重建的’。”老Z说，“系统规则和历史消息里，哪些能重建、哪些必须保留？通常的裁剪顺序是：能重新检索的项目资料先裁，历史对话按时间从旧到新裁，系统规则最后裁。每次请求都可以问一句：这段上下文如果没了，模型还能不能完成当前任务？不能，就留着；能，就先裁它。”

“上下文满了怎么办？直接截掉会不会坏事？”

“截掉会损失信息，但有比截掉更糟的：不截，请求直接被拒绝。”老Z说，“截断是显式丢弃旧内容并告知模型的边界；不截断则是让请求超限失败，任务根本没法开始。两者之间还有压缩（把旧对话压成摘要），但压缩会损失细节。截断、压缩、扩充窗口，是按代价从低到高排序的三条路，没有免费的。”

“工具结果算哪一类？它也在桌上吧。”

“算，而且是最容易被忽视的一块。”老Z说，“一次工具调用返回的日志、文件内容、搜索结果，全部占用上下文，用完这一轮就得腾出来。它和对话历史一样可重建，重跑一次工具就能再拿到，所以裁剪优先级很高。但能重建不等于重建没代价：重跑要重新付一次成本，能缓存的结果先缓存，实在要裁的，裁之前把引用位置留给审计。”

要点

• 上下文窗口：一次请求可见的有限预算（桌子的尺寸）
• maxTokens：单次输出上限（一口气能写多长）
• 两者各管一摊，别混为一谈；模型本身不跨请求记忆

2.5 采样让结果不是唯一答案

又过了两天，小A碰上一个新问题：同样的请求，跑两次，答案不一样。他怀疑是网络问题，正准备去排查，被老Z拦住了。

“先别查网络。你把两次的输出并排看看，除了个别字，是不是大致对得上？”

小A照做了，发现确实如此。

“这就对了：模型给出的是概率分布，不是唯一答案。”老Z说，“模型给出分布后，服务会按采样规则选 token。温度、top-p、top-k 等参数，改变的就是这个候选分布或候选集合。”

“把温度调低，是不是就‘准确’了？”

“不一定。低随机性通常更利于格式稳定和重复性，高随机性可能增加表达多样性。”老Z说，“但它们不是‘准确模式’和‘创意模式’的保证，错误事实在低随机性下仍可能稳定地重复。若接口支持 seed，它也只能帮助复现某些条件下的结果，不应被当成跨模型、跨版本的确定性承诺。”

“温度、top-p、top-k 各自控制什么？”

“它们控制的是‘从候选里怎么挑’，三个层次不同。”老Z说，“温度调节分布的平坦度：温度越高，低概率 token 越容易被选中，输出越发散；top-p（核采样）保留累积概率达到阈值的最小候选集，从里面挑；top-k 只保留概率最高的 K 个候选。三者改的都是采样路径，不改模型本身的能力，参数调得再极端，模型也不会凭空会做它本来不会的事。”

参数	控制什么	调高的效果	常见误用
温度	分布平坦度	更发散、更多样	以为能“纠正”事实错误
top-p	候选集的累积概率阈值	候选更集中在高概率区	与 top-k 同时叠加不加思考
top-k	候选集大小	只保留概率最高 K 个	固定 K 忽略分布形状

“这些参数要一起调吗？”

“不要随意叠加，同时调的时候作用会互相干扰，你很难说清最终效果是哪层贡献的。”老Z说，“实践上通常只动一两个：格式任务把温度调低，探索型任务把温度调高，多数情况保持默认。另外并非每个提供方都支持全部参数，先读文档再决定。”

小A在本子上记下“只动一两个”。

“那怎么验证输出是稳定的？”

“靠测试，不靠参数。”老Z说，“固定任务跑多次，看格式是否一致、关键事实是否每次都对；需要可复现时用 seed 加固定参数组合，并把它们作为请求的一部分记录下来。稳定性是测出来的结论，不是参数调出来的保证。”

小A还不死心：“温度调到 0 呢？格式总该保证合法了吧？”

“不保证。温度调到 0，只是每次都选概率最高的那个 token，模型照样可能生成不闭合的 JSON，只是概率低一些，不是零。”老Z说，“格式合法性是校验问题，不是采样问题：需要严格格式时，用 schema 约束加运行时校验，或让模型通过工具按受控模板产出。”

要点

采样参数调的是“怎么选”，不是“对不对”。要格式稳定，收紧随机性并做测试；要事实正确，靠证据和校验。

2.6 幻觉是验证问题，不是措辞问题

折腾了两天，小A终于把话题拉回了一开始那个 bug：“它给出的那个不存在的 API，算是‘措辞不够好’吗？”

“不是措辞问题。”老Z说，“当模型生成看似合理但不真实的事实、引用或代码细节时，常被称为幻觉。它的表现包括编造 API、误读文件、错误归因和虚构来源。模型生成的是可能的续写，单靠提示‘不要幻觉’消除不了风险。”

“那我能做什么？”小A记起自己踩过的坑，语气认真起来。

老Z列了几条：

缓解幻觉的工程手段

1. 对可查事实提供原始资料，并要求引用位置
2. 让模型通过受限工具读取、搜索或运行验证
3. 对高风险结果设置规则校验、测试或人工审批
4. 把“不确定”和“验证失败”保留为可见状态，而不是强迫模型给结论

小A把四条抄进笔记本：“‘保留不确定状态’，具体怎么落地？”

“就是把‘不知道’和‘没验证’都当成合法的输出类别。”老Z说，“很多任务逼模型给结论，不答就是答错。但工程上，模型明确输出‘我无法从证据确认’，比硬编一个答案安全得多。应用把这种状态单独展示，而不是当失败吞掉，用户才知道该去核实而不是照着做。允许模型说‘不知道’，是校验链路的一部分。”

小A指了指清单第二条：“那让模型去‘查一下’，就一定对吗？”

“不一定。”老Z说，“工具返回的内容也可能错误或被污染。工具不是‘真相按钮’，它只是让证据链可检查的一环。”

小A还是不放心：“幻觉是不是只有‘整段编造’一种？”

“不是，更难防的是部分失真。”老Z说，“整段编造一眼能看出来，但更常漏网的是：引用了真实存在的文章，却把结论张冠李戴；数字本身没错，适用范围却讲错了；API 名是真的，参数却编了出来。这类幻觉每个片段单独看都‘查得到’，合起来才不对劲。验证不能只问‘这东西存在吗’，还要问‘它在这里用得对吗’，前者挡编造，后者挡失真。”

“那验证本身会不会出错？”

“会，验证也是代码。”老Z说，“正则可能匹配错，抓取的页面本身是错的，人工审批也可能漏。所以验证的结论要保留原始证据的引用：模型引用了什么、你查了什么、结论是什么，三者存成一条记录，验证就不是一锤子买卖。”

2.7 成本与提示词缓存

月底对账，小A看着模型账单傻了眼，去找老Z：“怎么这么贵？我就聊了几十个来回。”

“你每次都把整个历史重新发一遍，还带了几份长文档，对吧？”老Z说，“一次调用的成本通常和输入、输出以及服务提供方的缓存规则有关。长上下文会增加延迟和费用，也会稀释真正重要的指令。许多服务提供提示词缓存或前缀复用：当稳定前缀满足其匹配和有效期条件时，服务可以复用部分计算。”

“那我是不是把资料都塞进提示词，缓存命中就省了？”小A眼睛一亮。

“别为了缓存把无关资料长期塞进提示词。”老Z打断他，“通用设计建议是把稳定规则放在前缀，把频繁变化的信息放在后面；但缓存优化不能替代上下文管理。具体价格、命中条件和保留时间是产品政策，应以调用时的官方文档与账单为准。”

“缓存有没有容易踩的坑？”

“最大的坑是：前缀差一个字符，整段缓存就不命中。”老Z说，“提示词缓存按稳定前缀精确匹配，前缀只要动一处，后面所有内容都要重新计算。要是把会话号、时间戳这类每次都在变的字段放在前面，缓存就永远命中不了，账上却看不出问题。判断前缀稳不稳，就看它是不是每次请求逐字节相同；会变的内容放后面，别进前缀，命中率才保得住。”

要点

提示词缓存按“稳定前缀”命中，前缀一致才能省钱。别把缓存优化当成上下文管理的替代品。

2.8 一次生成如何变成可观测的请求

新的一周，小A把老Z请到工位前，重新演示了一遍那个“不存在的 API”的 bug。

“我该从哪一步开始排查？”他问。

老Z把电脑转过来，指着日志：“把‘接龙’落到程序里，至少有三个彼此不同的阶段：输入被 tokenizer 切分；服务在已有上下文上计算并逐步选择输出；应用收到文本、用量或结束信号。前两个阶段由模型服务完成，最后一个阶段由应用控制。把它们混成‘模型回答了一次’，会让排障失去位置。”

用户任务 → 应用装配上下文 → 服务生成 token 序列 → 流式事件 → 应用验证/展示
             ↑                 ↑                    ↑
          可控输入          概率输出            可审计结果

“失败路径也不止‘答错’一种吧？”

“对。输入可能超过预算而被拒绝，输出可能因长度限制中断，流式连接也可能在得到部分文本后断开。”老Z说，“UI 应把部分结果标成未完成，不要把它和自然结束的回答存成同一种状态。”

“阶段之间怎么交接，才不会丢信息？”

“阶段之间传的是结构化记录，不是一句话。”老Z说，“应用装配阶段记输入摘要和版本号；服务生成阶段记用量和停止原因；应用处理阶段记校验结果和落库位置。每个阶段的输出是下一个阶段的输入，上一阶段要是只留了一句‘模型回答完毕’，下一阶段就没有任何证据可用。把‘回答完毕’拆成‘用了多少 token、怎么停的、校验过没有’，排障时才能回答不同的问题。”

“用户中途不想等了，能取消吗？”

“能，而且取消要和‘完成’分清楚。”老Z说，“取消是应用主动中断：发出中断信号，服务停止生成，应用把已收到的部分标成‘未完成’。这和你前面看到的截断、断流都不是一回事，截断是输出到上限被切，断流是连接失败，取消是主动作废。三种都叫‘没答完’，但原因不同，记录时必须分开存，否则统计‘有多少次回答被中断’时只能靠猜。”

示意： 用户要求“列出仓库中的测试命令”。若应用没有提供仓库文件或检索工具，模型只能根据训练中常见项目继续生成；即使命令格式流畅，也不能说明它存在。若应用先读取项目配置，再要求模型引用读取结果，结论仍需由实际执行或人工检查确认。

2.9 把机制和结论分开

几天下来，小A终于把整条链路理清楚了。他列了一张表，贴在自己工位旁边：

已确认机制	可以安排的工程动作	不能据此推出
token 逐步生成	为长度、取消和部分输出设计状态	输出一定经过完整推理
固定参数参与推理	不把一次聊天当成模型训练	参数多一定更准确
有限 context window	预算、截断或压缩上下文	每条输入都会被正确使用
采样影响选择	对格式任务收紧随机性并做测试	低温必然事实正确
prefix caching 是服务策略	稳定前缀与动态内容分层	一定命中缓存或省钱

“所以开头那个 bug（它给出了不存在的 API），不是网络问题，也不是我代码写错？”小A把整章的内容在脑子里过了一遍。

“对。同事在仓库走查中说‘读取配置后再回答’，只能说明应用把证据放进当前 context；仍应通过执行或人工核对确认结论。”老Z最后总结，“正常完成但引用不存在的 API，是事实验证失败，不是网络失败；输入超预算、输出达到长度上限、流中断则分别需要缩减、标记未完成或停止恢复，不能统一保存为成功。”

“排查的时候，怎么快速判断是哪个阶段的问题？”

“按‘证据在谁手里’分。”老Z说，“应用装配阶段的错误，日志里能看到输入字段不对，查应用代码；服务生成阶段的问题，看用量字段和流式事件，查请求参数和服务端状态；应用处理阶段的问题，看 UI 和存储，查你的展示与落库逻辑。每类错误的证据位置不同，混在一起排障就是在猜。”

“最后还有什么要留意的？”

“两个易混点。”老Z说，“一是‘模型没报错’不等于‘结果正确’，正常完成只是生成了文本，文本内容仍需验证；二是‘截断了’和‘拒绝了’是不同状态，截断是输出超长被切断，拒绝是输入超预算请求没发出。把每种状态分开存，排障时才分得清。”

小结

理解 LLM 的第一步，是放下“它会思考”这个直觉。它本质上是一台接龙机器：以 token 为单位，根据已经看到的内容，预测下一个 token 该是什么。token 不等于字、词或半个词，它由分词器决定，同一个词在不同分词器下可能拆成不同的碎片。模型选中一个 token 后，把它追加到条件里继续生成下一个，这就是“自回归”的全部含义。训练阶段把海量语料压缩成参数，推理阶段用这些固定参数处理新输入，两者是完全不同的过程，不要混为一谈。

这台接龙机器有两个根本限制。第一是上下文窗口：超出窗口的内容，模型不是“忘了”，而是“从未收到”，窗口就是请求时一次性可见的预算。第二是采样的概率性：温度、top-k、top-p 这些参数改变输出的分布，但不改变事实的对错，没有任何一个采样参数能保证生成的内容是真的。概率采样会让输出产生变化，温度调得再低，模型也可能稳定重复错误事实；约束幻觉要靠证据、执行和校验。

动手核验

用同一模型和同一问题运行两次：一次只要求结论，一次要求列出可核对的本地证据或官方来源。比较两份回答中可验证断言的比例。再把一段无关长文本加入输入，记录延迟、用量字段或输出质量的变化；若服务未暴露这些字段，不要据此猜测其内部计费。