SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

上下文窗口和上下文工程

上下文窗口是容器的大小,上下文工程是怎么用这个容器。买更大的容器可以解决一部分问题,但装什么、装多少、什么顺序、什么时候清理,这些靠工程能力,不靠容量。

寓言

货架和理货员

电商仓库的货架是统一规格的:每层宽一百二十厘米,深八十厘米,高六十厘米。新来的仓管小田接手后发现拣货效率很低,每个订单平均要穿越六个货架区。小田的第一反应是买更大的货架——如果能一口气放更多货,拣货员走的路不就少了吗?

老板批了预算,仓库换了一批加宽货架,每层从一米二扩到一米八。运行一个月,拣货效率反而下降了。货架大了,拣货员在一层上找东西的时间变长了——品类太多、排列没规律、热销品和滞销品混在一起。

老板请了一位仓储顾问老乔。老乔在仓库转了两天,做了三件事。第一,把每层货架按出库频率分区:高频区靠近走道入口,低频区靠里。第二,同一订单里经常一起出现的商品摆在一起。第三,每天早晨根据前一天的订单数据调整一层里最靠外的十个位置。

货架尺寸没变,拣货效率提升了百分之四十。小田问老乔:为什么不直接加货架?老乔说:加货架解决的是「放得下多少东西」,我解决的是「需要的东西在哪里、好不好拿」。你以前的问题不是货架不够大,是货架上的东西没有秩序。

小田把老乔的方法记下来,给每个货架层定了三条规则:入口位置留给当天热门品类,中间按关联性排列,深处放低频长尾品。每周末复盘拣货热力图,下周一调整布局。货架从「被动存放」变成了「主动适配」。

半年后仓库扩容,从三百平扩到八百平。小田没急着填满所有货架,而是先规划了新的分区逻辑和拣货动线。老乔的方法从一层货架扩展到了整个仓库——规模变了,思路没变。

小田后来培训新员工时画了一张图:左边是一个大货架,右边是一个小货架旁边站着一个理货员。他说:大货架让你装更多东西,理货员让你拿东西更快。光有更大的货架没有理货员,你只是有了一个更难找东西的巨型杂物堆。

一个同行来参观时问:你们的秘密是不是货架尺寸?小田摇头:货架是基础设施,谁都能买。真正的差别是谁家的理货规则更聪明、更新更快。容量靠采购,秩序靠设计。

上下文窗口

模型一次能处理的输入 token 总容量上限。它决定了「能装多少信息」,是模型的硬件约束或配置参数。

上下文工程

对上下文窗口内信息的组织、排序、压缩、缓存和刷新策略的工程实践。它决定「装什么、怎么装、什么时候换」,追求信息密度和检索效率最大化。

故事对应

  • 货架尺寸:上下文窗口的容量,决定能放多少东西。
  • 老乔的理货规则:上下文工程——分区、关联、热力调整,让有限空间发挥最大效用。
  • 货架变大但效率下降:扩窗口不能替代工程优化,无结构的大窗口反而降低信息利用效率。
  • 三条规则和每周复盘:上下文工程是持续迭代的过程,不是一次配置。
  • 大货架和理货员的对比:窗口是基础能力,工程是持续优化的能力。

落到项目里

遇到「上下文不够用」的问题,不要直接申请更大的窗口。先做上下文审计:当前窗口里哪些信息真正被模型用到了?文档的插入顺序是否合理?有没有重复或冗余信息在占用 token?有没有该缓存的结果没有被缓存?在窗口利用率低于百分之六十之前,扩容是最后的手段,不是第一个动作。