SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

上下文窗口和上下文长度:一个管能装什么,一个管能装多少

产品文档和采购清单里,上下文窗口和上下文长度经常互换使用。但在做预算评估和架构设计时,窗口描述的是模型能不能理解长对话这个能力本身,长度是一个具体数字。混用这两个词,报价单上的数字和实际能跑的场景经常对不上。

寓言

阅览室的书桌和书架

档案馆的阅览室有一张大书桌,研究员把当天要用的卷宗摊在桌上,翻完一本换一本。桌子的存在让研究员不必每次都跑回库房——这是房间里最重要的设计。

新馆长上任后,让人在每张书桌侧面贴了一个标签,写着桌面能同时放下几本卷宗。这个数字很好用:研究员预约座位时会先看标签,心里有数今天最多能摊开多少材料。

问题出在下一年采购季。行政部发了一张表让各科室填需求,表格里只有一栏叫“阅览室配置”。有人填的是“需要大书桌”,有人填的是“需要能放十二本卷宗”。采购部按“十二本”这个数字统一买了同款桌子,结果有两个研究组根本不需要摊那么多材料,但需要更宽的桌面来放地图和图纸。桌子长度够,宽度不够,地图只能折着看。

事后复盘才发现,书桌和桌面容量在采购表里被当成了同一件事。书桌是一个功能:让研究员在房间里直接工作。桌面容量是一个数字:当前这张桌子能同时放几本。数字最容易上表格,功能却决定了桌子该做成什么形状。

第二年表格拆成了两行。第一行问“是否需要阅览室桌面功能”,第二行问“需要的桌面容量大约是多少”。两个问题对应两种预算:功能预算决定要不要有这个能力,容量预算决定同一时间能处理多大信息量。

有些科室的填法让人意外。一个法律组在第一行填了“是”,第二行只填了“四本”——他们要的不是大容量,是稳定的桌面照明和在桌上摊开扫描仪的空间。如果继续只问容量数字,这个需求永远浮不上来。

后来档案馆出了一条内部规则:任何涉及阅览室的采购申请,第一行写功能——有没有书桌、有几个座位;第二行写容量——每张桌子能放多少材料、电源够不够。功能和容量分开记,采购才不会被一个数字带着跑。

上下文窗口

模型在单次推理中能够接收和参考的输入信息范围,是一种架构能力——窗口存在与否决定了模型能否处理长文本。

上下文长度

上下文窗口的具体数值,通常以 token 数计量,描述的是“能装多少”。同一模型在不同版本或配置下长度可能不同。

故事对应

  • 阅览室的书桌本身:上下文窗口,是一个功能存在
  • 桌面能放几本卷宗:上下文长度,是功能的具体容量数值
  • 采购问“能放十二本”统一买桌子:只问长度不问窗口形状导致配置错配
  • 地图组需要宽度不是长度:有些场景需要窗口的结构能力而非 token 上限

落到 Agent 项目里

做技术选型时,需求文档里把上下文窗口功能和上下文长度分开写。先确认“模型是否具备长上下文能力”,再确认“当前版本支持的 token 上限是否满足业务文案的长度要求”。报价和压测都应同时提供功能覆盖范围和容量上限两个数字。