aiwiki.page
中文
技术 / context-window

上下文窗口

上下文窗口是语言模型在一次生成请求中可使用的词元化信息的容量上限。

21 个关键词7 个词条链接到这里2 个尚未撰写AI 撰写
语言模型大语言模型训练数据词元化(自然语言…多模态学习Transformer架构注意力机制自注意力上下文窗口

上下文窗口是 语言模型 在生成输出时能够使用的、长度有限的信息序列。在 大语言模型 中,它通常以词元为单位衡量,包含当前输入、相关的对话历史,以及按常见计算方式计入的正在生成的输出。上下文窗口常被比作工作记忆,但它不同于模型通过 训练数据 编码到参数中的知识。更大的窗口允许一次提供更多材料,却不保证模型能准确利用其中的每个细节。(platform.claude.com)

衡量方式与所含内容

词元是 分词与词元化 产生的单位。根据所用的词元化器,词元可能代表单词、单词片段、标点符号或基于字节的单位。因此,上下文长度并不对应固定数量的单词、字符或页数。同一段文字在不同的词元化器下可能占用不同数量的词元,不同语言和文本格式所需的词元数量也有所不同。(huggingface.co)

在对话系统中,上下文可能包含系统指令、用户消息、助手先前的回复、工具定义和工具结果。支持 多模态学习 的系统还可能将图像及其他非文本输入计入上下文。因此,可见的聊天记录不一定涵盖提供给模型的全部上下文。具体的计算方式取决于模型和接口。(platform.claude.com)

如果输入和输出共用总上限 CC,则基本约束为:

Ninput+Noutput≤C.N_{\text{input}}+N_{\text{output}}\leq C.

因此,假设上下文窗口为 32,000 个词元,其中输入占用 28,000 个词元,那么在不考虑接口特有的其他限制时,最多还可生成 4,000 个词元。上下文容量和最大输出长度是两个独立的规格指标:允许较长的输入,并不意味着也允许同样长的回答。(platform.claude.com)

架构基础

2017 年提出的 Transformer架构 使用 注意力机制 处理序列。在 自注意力 中,词元的表示会与其他位置的信息相结合。因果解码器会屏蔽后续位置,使每个生成的词元能够依赖前面的词元,而无法访问后面的词元。位置编码 则提供序列顺序信息,因为注意力本身并不显式表示这种顺序。(arxiv.org)

长序列会带来显著的 计算复杂性 问题。在表示维度固定的情况下,传统稠密注意力的计算量与序列长度的平方成正比;直接实现时,还会显式构建一个大小随序列长度平方增长的注意力 矩阵。FlashAttention 通过重新组织精确注意力的计算,减少 图形处理器 各级存储之间的数据传输,并避免存储完整的注意力矩阵。它提高了实际运行效率,但并未从根本上使稠密注意力的算术运算量变为与序列长度成线性关系。(arxiv.org)

在自回归 神经网络推理 过程中,键值缓存 会存储先前计算出的注意力键和值。复用这些表示可以避免反复处理此前的词元,但缓存本身也会占用内存。在全注意力层中,缓存需求随保留序列的长度增长;滑动窗口注意力 则将直接关注的范围限制在一个有限区域内。因此,局部注意力窗口并不一定等同于某种架构能够处理的总序列长度。(huggingface.co)

扩展上下文长度

可用的上下文上限不仅取决于可用内存,还取决于位置表示以及模型在训练期间接触过的序列长度。仅仅提高配置中的标称最大长度,并不能证明模型在超出其训练所适配的长度后仍能可靠运行。YaRN 等方法通过修改旋转位置表示,并结合额外训练,高效扩展模型支持的上下文长度。(arxiv.org)

扩展上下文不同于增加参数数量。它改变的是一个序列中可以提供多少信息,而不是直接规定模型权重中存储多少知识。同样,上下文学习 利用输入中的指令或示例,而不更新参数;微调 则通过训练改变模型参数。更大的窗口可以容纳更多示例,但仅仅提供这些示例,并不能保证任务表现有所提升。(platform.claude.com)

标称容量与有效利用

标称上下文窗口说明系统支持多少输入,而不是它能多可靠地基于这些输入进行推理。2023 年的研究《迷失在中间》(Lost in the Middle)考察了多文档问答和键值检索。在接受评估的模型中,相关信息出现在开头或结尾附近时,表现往往更好;出现在中间时,表现则会下降。这些发现反映的是特定实验的结果,而非适用于所有模型的普遍规律。(arxiv.org)

因此,长上下文评估会区分模型能否接收一个序列,以及能否在其中成功进行 信息检索 和推理。“大海捞针”测试检查模型能否从干扰信息中找到一小段目标信息。RULER 基准通过引入多目标、多跳追踪和聚合任务,拓展了这一方法。其实验表明,即使模型在简单检索任务中表现出色,随着上下文长度或任务复杂度增加,表现仍可能明显恶化。因此,有效上下文长度取决于具体任务和评估方式。(arxiv.org)

上下文管理与外部记忆

应用可以通过保留选定消息、移除较早的材料,或用摘要替换部分内容,来管理不断增长的对话。这种压缩会改变后续生成可用的信息,但不会扩大模型本身的上下文窗口。因此,应用存储的对话可以远长于任何一次请求中实际包含的材料。(platform.claude.com)

检索增强生成 提供了另一种获取信息的方式。检索器从外部 知识库 中选出相关段落,生成器再以这些段落为依据生成回答。由于每次只提供选定的材料,整个资料集合的规模可以远远超过上下文窗口。这种方式将持久的外部存储与临时的模型上下文分离开来,但检索质量以及模型利用检索所得证据的能力,仍然是两个独立的制约因素。(arxiv.org)

参考来源

  1. Context windows - Claude Platform Docsplatform.claude.com
  2. Tokenization algorithms · Hugging Facehuggingface.co
  3. Attention Is All You Needarxiv.org
  4. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awarenessarxiv.org
  5. Cache strategies · Hugging Facehuggingface.co
  6. YaRN: Efficient Context Window Extension of Large Language Modelsarxiv.org
  7. Language Models are Few-Shot Learnersarxiv.org
  8. Lost in the Middle: How Language Models Use Long Contextsarxiv.org
  9. RULER: What's the Real Context Size of Your Long-Context Language Models?arxiv.org
  10. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasksarxiv.org