上下文

在大语言模型（LLM）中，上下文（Context） 指的是模型在生成回答、理解意图或进行推理时，所依赖的全部输入信息的集合。它就像模型的“即时记忆”，包含了所有与当前任务相关的文本信息，是模型判断语义、关联逻辑、维持连贯性的核心依据。

一、上下文的核心构成：模型“看到”的所有信息

上下文并非单一信息，而是由多类文本组合而成，具体包括以下3类核心内容：

1. 当前用户输入
   这是最直接的信息，即用户当下提出的问题、指令或需求（例如“解释量子力学的基本原理”“帮我写一封请假条”）。这是模型生成回答的直接触发点。

2. 历史交互记录
   在多轮对话场景中，上下文还包含了此前所有的对话内容——既包括用户之前的提问、补充说明，也包括模型之前给出的回答。
   例如：

   • 用户第一轮：“推荐一本科幻小说。”
   • 模型第一轮：“《三体》是经典的科幻作品，讲述了……”
   • 用户第二轮：“它的作者是谁？”
     此时模型的上下文不仅包含“它的作者是谁？”，还包含前两轮的对话。正是通过历史上下文，模型才能理解“它”指代的是《三体》，而非其他作品。

3. 附加参考信息
   当用户为了让模型更精准地响应，提供了额外的文本（如文档片段、代码块、数据表格等）时，这些信息也会被纳入上下文。
   例如：“根据这段文字，总结核心观点：[此处粘贴某篇论文的摘要]”，其中的论文摘要就是上下文的关键组成部分。

二、上下文的本质：模型的“语义锚点”

人类理解语言依赖“语境”——同样的词语在不同场景下含义不同（如“苹果”可以指水果，也可以指科技公司）。大模型的工作逻辑类似，上下文就是模型的“语境”，其核心作用是解决“语义模糊”和“逻辑断裂”问题：

• 解决语义模糊：通过上下文锁定指代、歧义词汇的具体含义（如上述“它”的指代）；
• 维持逻辑连贯：在多轮对话、长文本处理中，确保模型不“遗忘”前文信息（如写小说时，上下文能让模型记住主角名字、剧情伏笔）；
• 支撑复杂推理：对于数学计算、代码调试等任务，上下文能提供推理所需的前提条件（如“已知a=5，b=3，求a+b的值”，“a=5，b=3”就是推理的上下文依据）。

三、与“上下文长度”的关系：容量与内容的区别

需要明确的是，“上下文”和之前提到的“上下文长度”是两个相关但不同的概念：

• 上下文：是“内容本身”——即模型所依赖的输入信息集合（相当于“记忆里的具体事情”）；
• 上下文长度：是“容量限制”——即模型能容纳的上下文的最大长度（相当于“记忆的最大空间”）。

当上下文的总长度（通常以tokens为单位）超过模型的“上下文长度限制”时，早期或不重要的信息会被自动“截断”（即模型无法再调用这些信息），可能导致回答逻辑断裂或理解错误。

四、举个例子：直观理解上下文的作用

假设用户与模型有如下交互，我们可以清晰看到上下文的价值：

如果没有上下文，模型在第2轮会无法理解“其中”指什么，第3轮更无法定位“它”的含义——这正是上下文的核心价值：为模型提供“语义锚点”，实现连贯、准确的交互。

总结

简单来说，大模型的“上下文”就是它在处理当前任务时“能看到的所有相关信息”，包括你现在说的话、之前聊过的内容，以及你提供的任何参考资料。它是模型脱离“答非所问”、实现“理解意图”的基础，而“上下文长度”则决定了这份“记忆”能装下多少信息。

上下文长度

在大语言模型（LLM）中，上下文长度（Context Length） 指的是模型在生成回答或进行理解时，能够同时“看到”和处理的输入文本的最大长度限制。它就像模型的“短期记忆窗口”——窗口内的内容能被模型关联、分析和利用，而窗口外的内容则会被“遗忘”，无法直接参与当前的计算。

核心本质：模型的“短期记忆容量”

大模型的工作逻辑并非像人类一样能“永久记忆”所有输入，而是依赖于输入文本的上下文关联性进行推理。上下文长度本质上是模型在单次交互中，能纳入“记忆”的文本总量上限，通常以tokens（词元） 为单位（1个token约等于0.75个英文单词，或1-2个中文汉字）。

例如：

• 如果一个模型的上下文长度是4096 tokens，大约能容纳3000个英文单词，或2000-4000个中文汉字（含标点、空格）；
• 目前主流模型的上下文长度已从早期的几千token（如GPT-3的4096）提升到数万甚至百万级（如GPT-4 Turbo的128k，Claude 3 Opus的200k）。

上下文长度的关键作用

上下文长度直接决定了模型能处理的任务复杂度和交互深度，具体体现在3个方面：

1. 理解长文本：处理长篇文档（如论文、报告、小说）时，若文本长度超过上下文限制，模型无法一次性“读完”全文，可能遗漏关键信息（比如分析一篇5万字的报告，短上下文模型需分段处理，容易断裂逻辑）。
2. 维持多轮对话连贯性：在连续对话中，所有历史对话（用户提问+模型回答）都会计入上下文。若上下文满了，早期的对话内容会被“挤出窗口”，导致模型“忘记”之前的信息（比如聊了100轮后，模型可能不记得开头提到的“主角名字”）。
3. 支持复杂任务：复杂任务（如代码调试、法律合同分析、多文档对比）需要模型同时关联大量细节（如代码的前后逻辑、合同的条款关联），更长的上下文能让模型“看到”更完整的信息，减少推理错误。

为什么会有“长度限制”？

上下文长度并非越长越好，其限制主要来自技术成本和计算原理：
大模型的核心组件是“Transformer架构”，其中负责捕捉上下文关联的模块（自注意力机制，Self-Attention）的计算量与上下文长度的平方成正比（即长度翻倍，计算量翻4倍）。

• 更长的上下文需要更多的GPU显存来存储中间计算数据；
• 同时会大幅增加推理时间（生成回答变慢）和硬件成本。

因此，模型厂商需要在“上下文长度”“推理速度”“硬件成本”之间做权衡，不同模型会针对不同场景设计不同的上下文上限（如轻量模型侧重短上下文的快速响应，专业模型侧重长上下文的深度处理）。

上下文窗口（Context Window）

即“上下文长度”的另一种表述，强调其“有限范围”的属性——模型只能在这个“窗口”内进行信息交互。

输入上下文

用户提供的所有文本（含历史对话、prompt、参考文档等），是模型“读取”的内容；

输出上下文

模型生成的回答内容，部分模型会将输出也计入总长度限制（即“输入+输出”不能超过上限）。

超长上下文的 Trick

对于超过模型原生上下文限制的文本，通常会用“分段处理”或“检索增强生成（RAG）”技术：

• 分段处理：将长文本拆成多个小块，逐块输入模型，再拼接结果（但可能丢失跨块的逻辑关联）；

• RAG：先从海量长文本中“检索”出与当前问题相关的片段，再将片段（而非全文）输入模型，既规避长度限制，又提升准确性。

对用户的实际影响

1. 对话时注意“历史信息密度”：若与模型聊复杂话题（如写方案、改代码），尽量精简无关的历史对话，避免关键信息被“挤出”上下文窗口。
2. 上传长文档需拆分或用工具：若需分析长篇报告/论文，优先用支持超长上下文的模型（如Claude 3），或先自行拆分文档，标注段落逻辑（如“第1段：研究背景，第2段：实验方法”）。
3. 理解模型的“遗忘”现象：若模型突然“不记得”之前提到的信息，大概率是历史对话已超过其上下文长度，此时需重新补充关键信息。

总之，上下文长度是衡量大模型处理复杂任务能力的核心指标之一——更长的上下文意味着更强的“记忆”和“关联”能力，但也受限于当前的硬件和技术成本。