SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

删掉什么和能装多少

上下文剪枝或提示压缩是主动删减、压缩不必要信息以节省 token 和提升效率的策略。上下文窗口是模型架构规定的最大 token 容量上限。一个是管理策略,一个是结构限制——把策略问题当成容量不足,会错误地扩大窗口而不是优化内容。

寓言

书阁里的两个管理员,一个管删书,一个管书架格数

皇家书阁有两个管理员。马老负责管书架——阁里有固定大小的书架,每架一千格,每格只能放一本书。秦老负责管书目——每天各地的奏章、县志、信件堆满了书阁入口,秦老要在每份送进来的文书上用红笔画出核心段落,把不相关的附录、客套话和重复内容裁掉,再交给马老上架。

一开始书阁运转得不错。马老按格子上架,秦老按内容裁剪。后来各地送来的文书量翻了三倍,秦老动作再快也裁不过来。有人建议给书阁加书架——把每架一千格扩到三千格。新书架运来后,马老不裁的文书直接上架,阁里塞得满满当当。秦老反过来发现,扩了书架后大家更不注意文书质量了,因为地方大了,就不讲究精简。

真正的麻烦出现在查档案的时候。以前秦老裁过的文书,想找某个县的盐税记录,翻到对应段落就能看见。扩了书架后,不裁的原文堆了一千条,同一份文书里夹杂着客套话、家族谱系和不相关的县际对比。查档案的人用同样的关键词搜,出来的结果翻了三倍,真正有用的还是只有那几段。

书阁后来想了一个折中方案。马老坚持书架大小不能无限扩——每次扩架,维护和检索的成本跟着涨,而且大书架不等于好检索。秦老坚持裁减不能一刀切——某些文书关联性强,裁掉某段可能破坏上下文连贯性。两人合写了一本裁减手册:按文书类型和检索场景决定裁减策略。

一个年轻的文书提了问题:如果书阁能容下一百万格书架,还需要裁减吗?秦老反问,一百万格的书架你也要把客套话全塞进去?对方说不用裁了,反正地方够。秦老让他在一百万条记录里找一条被一百条客套话包围的盐税数据。年轻人翻了一天,说以前三条能找到的,现在要翻一百条。

书阁门口后来挂了一副对联:窗口大小是书架格子,裁减策略是选什么书放哪一格。扩书架解决不了选书的问题。

秦老退休前在手册上写了一段话:书架格子决定最多能放多少,裁减手艺决定放进去的有多少价值。两者互相制约——格子太少,再好的裁减也救不了;格子够大但没有裁减,等于让访问者在一堆废话里捞一根针。

上下文剪枝/提示压缩

主动删除、压缩上下文中的冗余、无关或低价值信息,以节省 token 和提升推理质量。是内容管理策略,不改变模型容量上限。

上下文窗口

模型架构规定的最大 token 容量上限,决定一次推理能处理多少上下文。是结构限制,扩窗带来成本和延迟,不解决内容质量问题。

故事对应

  • 马老管书架格子:上下文窗口——固定容量上限
  • 秦老裁减文书:上下文剪枝/压缩——管理放入窗口的内容质量
  • 扩架到三千格不裁了:扩大窗口不能替代内容裁剪
  • 查档案搜出三倍无用结果:窗口大但无剪枝会降低检索效率
  • 一百万 token 也找不到盐税数据:容量大不等于信息密度高
  • 架子格子决定上限、裁减决定放入质量:窗口和剪枝是互补但不同的变量

落到上下文管理策略

扩大上下文窗口不能替代内容管理。先在内容侧做好剪枝和压缩——去重、摘要、去除无关段落,再考虑是否需要扩大窗口。评估供应商的产品时,看他们有没有提供上下文压缩机制,只看窗口大小忽略了内容密度。同样窗口下,剪枝好的系统回答准确率可以高出三成。