一文看懂大模型如何理解上下文与生成回答

一、先厘清一个关键事实：模型看到的并不是“聊天”，而是一整段文本

很多用户在使用大语言模型时，会直觉地认为模型像人一样“连续对话”：记得上一句、理解情绪、知道当前进度。但从工程实现看，大语言模型本身并不保存跨轮次的记忆状态。每一次模型调用都是独立的计算过程，真正让它看起来像在对话的，是应用层在每次请求前，把相关上下文重新拼装成一段完整文本，再一次性交给模型。

这段文本在行业实践中通常被称为“上下文”，它至少包含四类信息：

1. 系统提示词：定义模型的角色、语气、边界、输出格式等。例如“你是一个面向初学者的技术助手，回答要通俗、准确，不使用过多数学公式”。
2. 工具说明：当应用需要模型具备调用外部能力时，会在请求中附带可用工具的描述，例如“查询天气”“搜索知识库”“创建工单”等。模型并不直接执行这些动作，而是根据描述决定是否输出结构化调用请求。
3. 历史对话：此前用户与模型之间的多轮问答内容。由于模型没有自动记忆，应用必须将它们重新放入请求。
4. 当前问题：用户最新一次输入，也是模型本次需要重点响应的内容。

一个简化的请求结构可以表示如下：

[
  {"role": "system", "content": "你是严谨的技术助手，回答应准确、易读。"},
  {"role": "user", "content": "什么是上下文窗口"},
  {"role": "assistant", "content": "上下文窗口是模型单次可以处理的最大文本范围。"},
  {"role": "user", "content": "为什么长对话会变慢"}
]

从这个角度看，所谓“多轮对话”，本质上是应用层不断把历史内容追加到新的请求里。模型每次都从零开始计算全部输入，而不会主动读取上一次的内部状态。

---

二、上下文是文本，那模型如何“计算”文本？

大语言模型的核心计算对象并不是自然语言字符串，而是高维空间中的向量矩阵。要让文本进入模型，通常需要经过两个关键步骤：分词与嵌入。

2.1 分词：把自然语言拆成最小处理单元

分词的目标，是将一段不规则的文本转换为模型可以索引的离散单元。这些单元一般称为 token。不同模型使用的分词规则不同，但普遍遵循几个原则：

• 常见的短词、标点、数字可能单独成 token；
• 生僻词或长词可能被拆成多个子词单元；
• 中文可能按字、词或子词粒度切分；
• 英文中前缀、后缀可能被独立拆分，例如某个词可能被表示为“前缀 + 词干”。

举例来说，“今天天气不错”可能被切分为多个 token，而“北京”在不同分词策略下可能是一个 token，也可能是两个 token。分词结果一旦确定，每个 token 都会在一个预构建的词汇表中找到唯一编号，这个编号就是后续计算使用的索引。

需要特别注意的是，分词规则会直接影响模型可处理的中英文长度、费用评估以及速度表现。同一个自然语言句子，在不同模型中的 token 数量可能不同，因此不能仅凭字符数判断请求大小。

2.2 嵌入：把 token 映射为稠密向量

仅有编号还不够，因为编号之间的大小关系并不包含语义信息。模型需要通过一个可学习的嵌入矩阵，将每个 token 编号映射为一个固定维度的向量。这个向量的维度可能是数百、数千甚至更高。

嵌入向量并不是随机生成的。在模型训练过程中，语义相近、语法功能相似的词，其向量会在空间中逐渐靠近；而语义无关的词则会相对远离。这样，模型后续的自注意力层和前馈网络就能在这些向量基础上提取模式。

例如，“苹果”和“香蕉”的向量可能比“苹果”和“汽车”更接近。这种相似性不是通过人工规则写死的，而是模型在海量语料中学到的分布特征。

---

三、位置、注意力与概率重建：一次前向计算中发生了什么

当一段文本被转换为向量序列后，模型会并行地读取这些向量，而不是像人一样逐字阅读。为了让模型知道“哪个 token 在前、哪个 token 在后”，输入向量还会加入位置编码信息。位置编码可以是固定的，也可以是模型学习得到的，目的是保留顺序信息。

接下来的核心结构是自注意力机制。简单理解，自注意力让每个 token 都能参考同一序列中其他 token 的信息，并动态分配关注权重。比如在句子“把书放进包里，因为它很重”中，模型需要判断“它”更可能指代“书”还是“包”。自注意力机制通过让每个词的向量与其上下文中的其他词交互，逐步捕捉这种依赖关系。

这些交互发生在模型的多层网络中。每一层都会对向量进行变换、加权、归一化，再传递到下一层。经过几十层甚至上百层计算后，模型会为整个输入序列生成一组新的向量表示。

最后，模型基于这些向量表示，预测输出序列中下一个 token 的概率分布。它并不是一次性“写出整句话”，而是一个 token 一个 token 地生成。每生成一个 token，都会追加到已有序列后，再次进入模型计算，直到生成结束标记或达到长度上限。

因此，即使是对同一个问题，模型生成的回答也并非从固定的“答案库”中摘取，而是在向量空间和概率分布上实时计算出来的结果。

---

四、为什么上下文会越来越长，这是一个重要的工程问题

回到前面提到的上下文拼装方式：由于每一轮请求都需要包含全部历史信息，所以对话轮次越多，请求体就越大。假设第一轮输入只有 100 token，第二轮加上第一轮问答后可能变成 300 token，第三轮可能变成 600 token，依此类推。

这种增长会带来几个实际影响：

1. 计算量增加：模型需要对更长的输入进行注意力计算，生成速度可能下降。
2. 成本上升：如果平台按 token 数量计费，历史越长，单次调用成本越高。
3. 截断风险：当上下文长度超过模型上限时，应用必须丢弃最早的一部分内容，可能造成信息丢失。
4. 注意力稀释：过长的上下文中，较远的早期信息对当前生成的影响可能减弱，导致模型“忘记”前面交代过的细节。

因此，工程上通常不会无限追加历史。常见做法包括：只保留最近若干轮对话、对历史内容做摘要压缩、根据相关性检索历史信息，或者将关键事实转存到外部存储中再按需注入。

---

五、从原理到实践：善用模型的关键是管理上下文

理解了“输入是文本、调用是独立、上下文会变长”这三个事实之后，很多工程问题会变得更清晰。

在设计提示词时，应尽量将约束条件写清楚。系统提示词不是“越多越好”，但关键的角色定义、输出格式、禁止事项应当明确。模型并不能自动知道你的业务背景，所有它需要知道的规则，都必须明确出现在本次请求中。

在使用工具调用能力时，工具描述应简洁、结构化，只描述功能、输入和输出。工具列表本身也是上下文的一部分，过长的工具说明会挤占有效空间。将不相关工具放在同一次请求中，不仅浪费 token，还可能增加工具选择错误的概率。

在维护多轮对话时，应根据任务复杂度设计上下文策略。简单任务可以只保留最近几轮；复杂任务可采用“摘要 + 关键信息块 + 最近对话”的组合结构。将任务进度、用户偏好、已确认事实单独维护，远比全部塞进原始历史更可靠。

此外，还应预留一定的输出空间。因为生成过程也需要占用上下文窗口，如果输入内容几乎占满上限，模型可能没有足够空间完成回答。一个常见实践是，将较长的知识内容先检索、再压缩，把最相关片段放入上下文，而不是整篇堆入。

---

六、总结

大语言模型的工作方式，可以概括为：将自然语言切分为 token，映射为向量，再通过多层注意力计算提取语义关系，最终基于概率逐 token 生成回答。为了避免误解模型能力，一个最重要的认知是：模型本身不保存状态，所谓对话体验来自应用层对上下文的持续重装。

这意味着，开发者对上下文结构、提示词设计、历史对话管理与工具描述的控制，会直接决定模型输出的质量、速度与成本。越早建立这种“上下文工程”意识，就越能在实际业务中稳定地使用大模型，而不是依赖偶然的生成效果。