LLM引用：技术原理与实战详解

核心洞察

这篇文章最让我服气的地方，是把 LLM 从“玄学”拉到现实里来。特别是“工具调用也是令牌生成”这个角度，读完以后，很多代理框架里的设计决策一下就顺了。有一点我持保留态度：文里的训练细节基本来自 OpenAI 系模型，换到别的模型，表现和坑可能不太一样。

要构建 AI 代理，得先摸清底下撑它的那个东西：大型语言模型，也就是 LLM。这篇是给开发者看的全景图：它是什么、怎么训练、在哪强、哪弱。心里有这张图，后面搭代理的时候才不容易跑偏。

核心结论

1. LLM 的训练分为三阶段：预训练得到“续写引擎”式的基础模型；监督式微调（SFT）和基于人类反馈的强化学习（RLHF）将其调教为能执行指令的助手；再用强化学习训练出“先思考再回答”的推理模型——三者能力、成本和时延逐级递增。

2. LLM 推理是自回归令牌生成：一次只生成一个令牌，理论上前一个令牌生成后整个序列需重新过一遍模型；现代推理引擎通过 KV 缓存在自回归推理中存储历史键值对，避免重复计算，是加速推理的关键技术。MLA 对其进行了优化。加速，因此首令牌最慢，后续令牌明显更快。

3. 工具调用本质上仍是令牌生成：模型只是输出一段结构化请求（如 JSON），真正执行工具的是外部应用代码——这条边界本身就是安全边界；工具调用能力取决于训练数据，模型可能选错工具或编造参数。

4. 温度设为 0 也不保证确定性：浮点运算、批处理方式和底层硬件差异仍会导致同一输入产生不同输出，不能设计依赖“相同输入永远相同输出”的系统。

5. 上下文窗口按令牌计数，1 个令牌约等于 3/4 个英文单词；当前模型窗口短则 4K、长则超 100 万令牌，但所有输入输出都必须塞进这个上限内。

什么是 LLM？

LLM 是在海量文本上练出来的神经网络。训练目标一句话就能说完：给定前面所有内容，猜下一个令牌。奇怪的是，目标本身朴素，但一直练到足够大的规模以后，模型自己长出了语言结构和世界知识。

LLM 的核心只有两样东西：

• 模型权重：训练中学到的几十亿个数值参数，模型的知识都存在这里。
• 架构代码：神经网络结构，一般是 Transformer。运行时靠这段代码让权重真正吐出内容。

令牌：基本构件

LLM 按令牌读文本，不按字符。分词器把输入切成固定词表里的小单元。一个令牌可以是完整单词，比如 hello；可以是半个词，比如 un + believ + able；也可以是一个字母或标点。

比如“Tokenization is fascinating!”这句话可能被拆成这样：

["Token", "ization", " is", " fascinating", "!"]

注意看，有些令牌前面带着空格。分词并不总是跟单词对齐。

每个令牌对应模型词表里的一个 ID。模型算的完全是数字，不是文本。输出的时候也是先出一串 ID，再解码回文本。

上面那句可能被映射成这样的 ID：

[4421, 2860, 382, 33733, 0]

令牌为什么要单独拎出来说？因为 LLM 世界的一切都按它计量：

• 计费：一般按输入令牌加输出令牌收钱。
• 上下文窗口：按令牌衡量，不是单词数。
• 提示长度：提示越长，占用令牌越多，留给模型回答的空间就越小，价格也越贵。

一个粗略的换算：1 个令牌约等于 3/4 个英文单词。

想直观看看文本怎么被分词，OpenAI 有个在线分词器，贴文本进去就能看。

如何训练 LLM

现代 LLM 的训练分几步，每一步都踩在上一步的肩膀上。

阶段 1：预训练

预训练是模型攒知识的主战场。互联网上海量的文本，书、文章、代码、网页，全被扔进来。模型只学一件事：已知前面所有令牌，预测下一个令牌。这个阶段极其烧算力，几千块 GPU 连续跑几周甚至几个月都很正常。跑完得到的叫基础模型。

基础模型说白了就是个续写引擎。给它一段开头，它按训练数据里的模式接下去。但把它当私人助手用会很别扭：它可能把内容续到奇怪的方向，可能吐有害内容，也可能前言不搭后语。让它稳定执行指令？做不到。

阶段 2：训练后

训练后就是把基础模型调教成能用的助手。这一步又拆成两段：

监督式微调（SFT）：先给模型看一批人工精挑细选的对话样例。这些样例演示“理想助手”应该怎么表现：怎么照着指令做、怎么答得有用、怎么拒绝不合适的要求、怎么把回复格式排利索。SFT 教的是角色感。

接着是基于人类反馈的强化学习（RLHF）。人类标注员会对比两个回复，指出哪个更好。这些偏好数据被用来训练一个奖励模型，奖励模型再带着强化学习把 LLM 往人类偏好的方向推。为什么需要这一步？因为“简洁但不过分简单”这种微妙的度，静态样例很难覆盖全面。这类判断通常出现在没有唯一正确答案的领域，跟算术那种有客观对错的问题不一样。

阶段 3：通过强化学习学会推理

最近两年，强化学习又被拿来教模型先想后答。模型接到问题不直接回复，而是先吐一串思考过程，把问题拆成子步骤、试试别的方向、回头验证一下。OpenAI 的 o 系列就是这条训练路子。

效果是数学、逻辑、编码和复杂多步问题的表现明显上了一个台阶。代价是延迟更高，因为思考过程也要当令牌生成。

注释：LLM 里实现推理的办法不止一种，想系统了解可以去看 Sebastian Raschka 写的这篇。强化学习之所以最猛，是因为模型能拿自己的推理过程当训练材料继续学，而且它特别适合数学、逻辑、编码这类能自动验证对错的领域。

提示：建代理不需要背下全部训练细节，但懂这几步能帮你解释很多现象。基础模型会续写。SFT 加 RLHF 的模型会执行指令。推理模型会先思考再回答。给代理挑模型的时候，这几档差异直接对应到能力、成本和时延。

推理是怎么跑的

往 LLM 发一个请求，它其实是一个令牌一个令牌往外蹦。这个过程叫自回归生成。

具体说：

1. 完整提示，包括系统消息、对话历史、用户输入，全部转成令牌，喂进模型。
2. 模型读完这些令牌，为词表里的每个候选算出概率。
3. 按概率分布挑一个令牌，挑的时候受温度这些采样参数影响。
4. 新令牌接到整个序列后面，整个序列重新喂回模型，接着算下一个。
5. 一直循环到模型吐出一个终止令牌，或者撞上长度上限。

自回归意味着每生成一个新令牌，模型在理论上都要把整个序列重新过一遍。这就是为什么 LLM 的上下文窗口是固定的：它一次能处理的令牌数有上限。你的提示要占，历史记录要占，临时塞进来的资料要占，模型吐出来的回答也在窗口里。

不过实际引擎不会真这么傻。现代推理引擎一般会用 KV 缓存这类技术，之前算过的令牌不用每次从零再来。所以第一个令牌出来最慢，那是在做“预填充”。后面每个令牌快得多，走的是“解码”阶段，一次只处理一个新令牌。

上下文窗口（例如 128K 令牌）
┌────────────────────────────────────────────────────────┐
│  系统指令  │  历史  │  用户  │ ← 模型生成的回复 →   │
│             (输入令牌)            │    (输出令牌)     │
└────────────────────────────────────────────────────────┘

现在的上下文窗口短则 4K，长则超过 100 万令牌。但上限就是上限。模型能知道的全部信息，都必须塞进这个窗里。

还有一层现实约束：回复越长，总耗时越长。每个新令牌都得过一次完整的前向计算。代理应用里一般都会开流式传输，出一个令牌就推一个，不让用户干瞪眼等着全部生成完。

开发者要懂的几个关键概念

聊天补全：最基本的接口形态

现代 LLM 通过聊天补全接口来调用，消息按角色分好：

一个典型请求长这样，简化过的：

消息：
[system]    "你是一个会回答天气问题的助手。"
[user]      "西雅图现在天气怎么样？"

模型会把上下文窗口里所有消息一起处理，再输出下一条助手消息。这个无状态的“请求进来，回复出去”模式，就是代理搭建时的地基。

不同模型和接口在消息格式上有细节差异。模型内部会把消息序列拼成类似“系统……用户……助手……”的长文本，然后再走分词和计算。

温度与确定性

温度控制的是模型输出里的随机成分。

• 温度等于 0：偏向确定性，每次都选概率最高的令牌。
• 温度大于 0：从更宽的分布里抽，输出花活更多。

代理应用建议用低温，0 到 0.3 之间，图的是行为稳定。做创意内容再考虑 0.7 往上。

注意：温度 0 也不保证完全确定。浮点运算细节、批处理方式、底层硬件差异都能引起细微波动。别设计一个依赖“相同输入永远输出相同结果”的系统。

LLM 强在哪

按任务类型看，LLM 最趁手的是这些：

• 推理与分析：拆解问题、对比选项、把概念讲明白。
• 内容生成：文章、邮件、报告、代码，都能写。
• 摘要：长文档压成几个要点。
• 翻译：语言之间互转，也能在 JSON 和散文这种格式之间转。
• 代码生成：写代码、解释代码、调试代码。
• 分类与提取：文本打标签，或者从一大段非结构化内容里抠出结构化字段。
• 多模态理解：不少新模型能连图片、音频、视频一起处理，比如描述画面、转写语音、分析视频内容。
• 结构化输出：按要求吐 JSON 或 XML。做工具调用、数据抽取、对接下游系统时，这个能力很关键。

多模态的原理也简单：图像、音频这些输入会被专门的编码器转成令牌，跟文本令牌混在同一个上下文窗口里算。底层机制没变，一切皆令牌。

LLM 做不好什么

做靠谱的代理，得先知道 LLM 会在哪些地方掉链子。对照着看：

上面这串限制，恰好就是代理框架要去补的洞。工具让代理能拿实时数据、能执行动作，持久记忆交给会话层处理。这个系列后面的文章会一个一个来填。

LLM 是怎么学会用工具的

LLM 只会吐令牌。它不能自己打开浏览器，不能直连数据库，也不能调第三方接口。那“工具调用”是怎么来的？原理比想象中朴素：它被训练成在恰当的时候输出一段结构特殊的令牌。这段令牌跟回答无关，它在描述一次工具调用。真正的执行，由模型外部的代码完成。

工具调用，说到底还是令牌生成

别忘了自回归：LLM 永远是一次一个令牌地生成。训练后阶段，模型见过大量包含工具交互的数据，学会了特定格式。当它判断应该调工具而不是直接回答时，它会吐一段结构化的 JSON，比如：

{
  "tool": "get_weather",
  "arguments": { "location": "Seattle" }
}

对模型来说，这和生成任何普通文本没有区别，还是在猜下一个令牌。但海量样例教过它，让它掌握了三件事：什么时候该调工具、在多个工具里选哪个、参数怎么按用户的话组织。

不同模型厂商给工具调用定义了不同格式。有 JSON 函数调用的，有类似 XML 标签的，也有专门搞特殊令牌的。但底子是同一套：模型输出一个结构化请求，说“我要调这个工具，参数如下”。

模型怎么决定何时调工具

训练的时候，模型的输入里带着工具定义，包括工具名称、功能说明、参数结构。训练样例反复演示同一个流程：

1. 用户发问，问题需要额外信息或外部操作。
2. 模型不直接作答，先吐出一段工具调用。
3. 工具执行结果回到对话流里，这一步由外部代码完成。
4. 模型依据工具结果生成最终回复。

这么练出来的模型，学到的是三件事：遇到哪些情况该求助工具而不是硬答、从可用清单里挑哪一个、怎么把用户的自然语言请求翻译成参数。

知道这个，对你有啥用

“工具调用只是令牌生成”这层窗户纸捅破以后，几条重要结论就藏不住了：

• LLM 从来不执行任何动作。它只生成请求。真正执行工具函数的是你写的应用代码。这条边界本身就是安全边界。
• 工具调用靠不靠谱，看训练。模型在工具使用数据上微调得越多，实际调用就越准。这也是为什么模型之间的工具调用能力差距很大。
• 工具定义吃上下文。每个工具的名字、说明、参数都要占窗口。工具越多，留给对话历史和最终回答的空间越少。
• 模型会犯错。它可能编出带着错误参数的工具调用，可能选错工具，也可能在不需要工具时强行调用。校验和护栏必须留一手。

从工具调用到完整的代理执行循环，也就是让代理反复调工具、看结果、决定下一步，中间那一步桥接，就在下一篇文章里。

这跟代理怎么接上

单个 LLM 再强，也只是个文本进、文本出的系统。要变成能干活的应用，得补几层东西：

代理框架把这些层都封装好了。你要做的是专注应用逻辑，不用每次从零搭一套 LLM 基础设施。

了解更多

想继续深入，推荐两个入口：

• 什么是大型语言模型（LLM）？ 微软 Azure 的介绍，讲了类型和常见使用场景。
• 深入了解 ChatGPT 等 LLM Andrej Karpathy 的三小时视频，从训练讲到工作原理，再讲到该怎么预期它。信息密度很高。

后续步骤

下一篇去读从 LLM 到代理。工具调用怎么串成完整的代理执行循环，入口在那。

常见问题（FAQ）

什么是LLM令牌？它如何影响开发者？

令牌是语言模型处理文本的基本单位，可以是单词、子词或字符。所有计费按令牌算，上下文窗口也以令牌衡量，提示和生成都会消耗令牌。理解分词规则有助于控制成本、优化提示词长度，并避免超出模型的最大令牌限制。

LLM的预训练和训练后有什么区别？

预训练在大规模文本上用预测下一个令牌的方式训练，得到的基础模型只会续写。训练后通过监督微调和基于人类反馈的强化学习，教会模型遵循指令、生成有用回答和拒绝不合理请求。推理模型还利用强化学习学会先思考后回答，提升复杂任务表现。

LLM有哪些能力边界和开发注意事项？

语言模型擅长推理、生成、摘要、翻译等任务，但上下文窗口有限，提示过长会占用生成空间；温度为零也不能保证输出完全一致，可能受硬件影响。开发代理时建议使用低温获得稳定行为，用流式传输降低感知时延，并密切关注令牌消耗和回复长度。