一文带你搞懂什么是大语言模型(LLM)

什么是大语言模型？

大语言模型是一种神经网络(neural network)，在海量文本数据上完成训练，目标是预测序列里的下一个词元（token）。

依托这个简单的训练目标 ——给定前面所有词元，下一个会是什么？，模型习得语言结构与各类世界知识。

本质上，一个大语言模型只由两部分构成：

1. 模型权重：训练过程中学到的数十亿数值参数，编码存储模型掌握的全部知识。

2. 体系架构代码：神经网络结构（主流为 Transformer 框架），读取权重并生成输出内容。

 

💡提示： 强烈推荐观看Andrej Karpathy的视频《深度解析大语言模型，以 ChatGPT 为例》，讲解大语言模型的训练方式、内部运行机制以及对模型应有的合理预期。

https://www.youtube.com/watch?v=7xTGNNLPyMI

 

词元（Token）：基本处理单元

大语言模型并不会逐字符处理原始文本，处理对象是词元（token）。

分词器(tokenizer)会把输入文本切分为词元，词元属于固定词表的子词单元。

一个词元可以是完整单词（"hello"）、单词片段（"un" + "believ" + "able"）、单个字符或是标点符号。

例如句子 "Tokenization is fascinating!" 会被切分成如下词元：

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

💡提示：留意部分词元开头带有空格，分词结果不一定和完整单词一一对应。

每个词元会映射为一个数字（词表里的编号 ID），模型完全基于这些数字运算，而非直接处理文本。当模型输出内容时，先生成词元 ID，再解码还原为可读文本。

上面示例的词元，在模型词表中可能对应下面一组编号：

[4421, 2860, 382, 33733, 0]

理解词元十分关键，大语言模型的一切都以词元为计量单位：

1. 计费：通常按词元收费（输入词元 + 输出词元）

2. 上下文窗口：计量单位是词元，而非单词或字符

3. 提示词越长，消耗词元越多，成本越高，留给模型生成回复的空间也越小

经验估算：英文语境下，1 个词元≈0.75 个单词。

 

💡提示：OpenAI 提供的在线分词工具，可以直观查看文本如何被切分为词元。

https://platform.openai.com/tokenizer

大语言模型的训练流程

现代大语言模型分为多个训练阶段，层层迭代，模型能力逐步提升。

阶段1：预训练

模型习得绝大部分知识。输入海量互联网文本：书籍、文章、代码、网页，学习根据上文预测下一个词元。该阶段需要巨大算力（数千 GPU 持续数周乃至数月），产出基座模型（base model）。

基座模型本质就是文本补全引擎。输入提示词，它会根据训练数据的模式生成通顺的续写。但基座模型并不适合直接当作助手使用：可能会以出人意料的方式续写文本、生成有害内容，或是漫无目的地输出，无法可靠遵循指令。

 

阶段2：后训练

后训练能将基础模型转变为实用的助手，包含多个子阶段：

监督微调（SFT，Supervised Fine‑Tuning）：使用高质量对话精选数据集训练模型，数据是人工编写的理想助手应答样例。

样例教会模型如何遵循指令、友好回答问题、拒绝有害请求、规范输出格式。监督微调让模型学会充当一个乐于助人的助手。

基于人类反馈的强化学习（RLHF）：完成监督微调后，人工标注人员对比模型的两组回复，标记更优的那一组。这些偏好数据用来训练奖励模型，再结合强化学习进一步调优大模型，让输出更符合人类偏好。

RLHF 可以捕捉静态样例难以体现的细微质量差异，比如回复该简洁还是详尽、什么时候需要向用户追问澄清。

该技术多用于无唯一标准答案的场景，不像算术题存在客观确定的正确结果。

 

💡提示：感兴趣可以阅读 OpenAI 关于指令微调的博客或者相关学术论文。

https://openai.com/research/instruction-following

https://arxiv.org/abs/2203.02155

 

阶段 3：基于强化学习的推理能力训练

近年，研究者利用强化学习技术教会模型分步推理再给出最终答案。模型不会直接输出结果，而是生成思维链：把大问题拆解为若干子步骤，探索多种可能性，校验推导过程。

OpenAI o 系列推理模型就采用这套训练思路。这类模型在数学、逻辑、编程、复杂多步骤问题上表现大幅提升；代价是更高响应延迟、消耗更多词元（推理步骤本身也会生成词元）。

注：实现大模型推理能力有多种方案。强化学习是效果最强的路线，允许模型从自身的推理过程中学习，非常适合数学、逻辑、代码这类结果可以核验的任务，这也是推理模型在此类任务上性能突出的原因。

https://magazine.sebastianraschka.com/p/understanding-reasoning-llms

💡提示：开发智能体(Agent)不需要吃透全部训练细节，但了解这些阶段有助于理解模型行为差异：基座模型做文本续写；SFT+RLHF 模型遵从指令；推理模型会分步思考。选型时，这些特性直接影响模型能力、成本与响应时延。

 

推理是如何运行的

向大语言模型发起请求时，模型会通过自回归生成，逐个产出词元：

1. 完整提示词（系统指令、对话历史、用户输入）转为词元输入模型。
2. 模型处理全部输入词元，输出词表上的概率分布，预测下一个最可能出现的词元。
3. 依据该分布选出一个词元（受温度、采样等参数影响）。
4. 将新词元追加到整个序列末尾，把更新后的完整序列重新送入模型，生成下一个词元。
5. 循环往复，直到模型输出停止词元，或是到达最大长度限制。

这套迭代机制意味着：生成每一个新词元，模型都要参考全部已有词元序列。因此大模型存在固定上下文窗口，即可处理的最大词元数量。

提示词、对话历史、注入的上下文，以及模型正在生成的回复，全部都要容纳在窗口之内。

 

💡提示：工程实现中，现代推理引擎会使用KV 缓存等优化手段，缓存已经处理过词元的中间计算结果，避免每生成一个新词元就要重新处理全部序列。

所以生成第一个词元（预填充阶段，处理全部输入）耗时更长；后续生成词元（解码阶段）复用缓存，速度更快。

https://arxiv.org/pdf/2603.20397

 

Context window (e.g., 128K tokens)
┌────────────────────────────────────────────────────────┐
│ System      │ History │ User  │ ← Generated response → │
│ instructions│         │ input │                        │
│         (input tokens)        │    (output tokens)     │
└────────────────────────────────────────────────────────┘

现在模型上下文窗口跨度从 4K 到超过 100 万词元不等，但窗口永远是有限的。

相当于模型的工作内存，所有需要模型知晓的信息，都必须放进窗口。

 

⚠️重要提醒：推理是自回归逐词元生成，回复越长，生成耗时成比例增加。

每产出一个词元，都要完整执行一次模型前向运算。所以智能体应用普遍采用流式输出：词元一生成就推送给客户端，而不是等完整回复全部生成完毕。

 

开发者核心概念

聊天补全：基础 API 模式

调用现代大语言模型主要使用聊天补全 API，采用结构化消息格式：

角色	作用
System（系统）	设定模型行为、人设与约束，即 “指令”
User（用户）	人类的提问与输入内容
Assistant（助手）	模型历史回复，用来维护多轮对话上下文

一条简化后的典型请求示例：

Messages:  
[system]    "You are a helpful assistant that answers questions about weather."  
[user]      "What's the weather like in Seattle?"

模型读取上下文窗口内全部消息，生成下一段助手回复。这种无状态请求‑响应模式，是智能体开发的底层基础。

注：不同模型、不同 API，消息格式字段略有区别。底层会把这些消息转换为特殊标记包裹的文本，再做分词送入模型。

 

温度参数与结果确定性

温度（Temperature）控制模型输出的随机性：

Temperature = 0：输出更确定，每次优先选取概率最高的词元

Temperature > 0：更有创造性，从更广的概率分布中采样

开发智能体，一般选用较低温度（0‑0.3），保障行为稳定可靠；创意类任务适合高温度（0.7‑1.0）。

 

⚠️重要：即便温度设为 0，大语言模型输出也无法做到完全确定。浮点数运算、批处理、基础设施差异都会带来微小变化。不要设计依赖 “相同输入必定得到完全一致输出” 的系统。

 

大语言模型擅长什么

大模型在语言理解、生成类任务上表现优异：

1. 推理与分析：拆解问题、对比方案、解释概念

2. 内容创作：撰写文章、邮件、报告、代码

3. 摘要总结：把长文档提炼成精炼要点

4. 翻译：自然语言互译，也支持格式转换（JSON ↔ 自然文本）

5. 代码生成：多语言代码编写、解读、排错

6. 分类与信息抽取：文本归类，从非结构化文本提取结构化数据

7. 多模态理解：很多现代大模型可以同时处理文本、图片、音频、视频；实现看图描述、语音转写、图像内容分析等任务

8. 结构化输出：输出 JSON、XML 等严格格式，对工具调用、数据抽取、对接下游系统至关重要

 

💡提示：多模式能力本质是图片、音频等信息同样被转换成词元。专用编码器将多媒体转为词元序列，和文本词元共享同一个上下文窗口处理。底层机制不变：一切皆为词元。

 

大语言模型的短板

理解模型局限性，对构建可靠智能体至关重要：

局限性	对智能体开发的影响
无实时知识	训练数据存在截止日期，不知道训练结束之后发生的事件。
幻觉	模型会生成语气笃定，但事实错误的内容；输出看似合理的文本，而非调取经过核验的事实。
无持久记忆	每次 API 调用都是无状态的。除非把历史对话放进上下文窗口，否则模型记不住之前对话。
数学、形式逻辑能力有限	虽持续改进，但在精密计算、形式逻辑任务上仍会出错。
输出非确定	同一套提示词，多次调用可能返回不一样结果。
没有执行能力	模型只会生成文本，无法自行发送邮件、查询数据库、调用外部 API。

 

注：智能体正是为了解决以上诸多局限而生。借助工具，智能体可以获取实时信息、执行运算；会话机制实现持久记忆。后文会逐一讲解如何应对这些问题。

 

大语言模型如何学会使用工具

大语言模型只能生成词元，本身不能浏览网页、查询数据库、调用 API。那它如何 “使用工具”？答案很简单：它们被训练为输出一段表示工具调用的特殊 token 序列，而外部代码会解释该输出并完成实际工作。

使用工具本质就是词元生成

记住：大模型逐词元生成输出。在后训练阶段，模型会用包含工具交互的样例做微调。样例教会模型一套固定结构格式：当判断需要调用工具时，模型不输出普通自然语言，而是生成符合特定模式的结构化词元，例如 JSON：

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

对模型来说，生成工具调用和生成普通文本没有本质区别，依旧是预测下一个词元。通过成千上万工具交互样例微调，模型学会什么时候该调用工具、选用哪个工具、填写什么参数，全部都表达为词元序列。

注：不同厂商工具调用格式不一样（JSON 函数调用、XML 标签、特殊标记词元），底层原理一致：模型输出结构化内容，表达 “我要调用这个工具，参数如下”。

模型如何判断何时调用工具

训练时，提示词内会附带工具定义：工具名称、功能描述、入参说明。训练样例反复演示这套流程：

1. 用户提出问题，该问题需要外部信息或者执行操作。

2. 模型输出工具调用，而不是直接回答（训练样例告诉模型，自身知识不足以回答时应当这么做）。

3. 工具返回结果写入对话上下文（训练数据集构建时由外部代码填充）。

4. 模型生成最终回答，把工具返回结果整合进去。

经过这套训练，模型学会判断什么时候调用工具、在可用工具中做选择、根据用户请求构造参数。

 

为什么这点很重要

理解工具调用只是词元生成，可以理清几个关键点：

1. 大模型永远不会真正执行代码，只生成调用请求。应用代码 / 智能体框架负责解析调用指令、运行函数、再把执行结果送回对话。这种隔离是重要的安全边界。

2. 工具调用能力取决于训练质量。模型工具调用好不好，取决于工具交互样例微调是否充分，这也是不同模型工具调用能力差距很大的原因。

3. 工具描述会消耗词元。你传入的工具定义占用上下文窗口词元；工具越多，留给对话历史和模型回复的词元配额越少。

4. 模型会犯错。和事实幻觉一样，模型也会生成参数错误、选错工具、不该调用工具却强行调用。因此校验与防护逻辑必不可少。

工具调用能力串联起完整执行循环：智能体反复调用工具、观察返回结果、决定下一步动作。这就是从 LLM 走向 Agent 的桥梁，下一章展开讲解。

 

与智能体（Agent）的关联

单纯的大语言模型只是一套强大但有限的 “文本输入‑文本输出” 系统。想要打造实用应用，需要在之上叠加多层能力：

需求	仅使用大语言模型	搭配智能体框架
定向行为能力	手动编写复杂系统提示词	智能体自带指令与角色设定
获取实时数据	无法实现	工具（函数工具、MCP 服务）
执行外部动作	无法实现	带审批流程的工具调用
记忆能力	每次调用必须重传全部对话	会话与会话上下文组件
运行可靠性	依赖提示词运气实现	防护校验中间件、强制覆写逻辑

 

智能体框架(Agent Framework)封装上述能力，开发者只需要聚焦业务逻辑，不用从零搭建整套大模型基础设施。

 

 

本文翻译自：

https://learn.microsoft.com/en-us/agent-framework/journey/llm-fundamentals

如有翻译不准确之处可以自行查阅原文