技术
上下文混合压缩原理:多个模型如何预测下一个字节
📅 2026-10-07 · ✍️ 闪压技术团队 · ⏱ 3 分钟阅读
一句话理解上下文混合
压缩的本质是预测。算法每写下一个符号,都在赌"接下来大概是什么",赌对了省下空间,赌错了就得多花几个比特去纠正。
单个预测模型总有盲区。看最近几个字符判断不了,就换成看更长的历史;长历史偶尔太稀疏、统计不稳,又得退回短历史。这种在"长上下文"和"短上下文"之间来回切换的做法,叫上下文建模。
上下文混合换了个思路:不切换,而是让它们同时在场。
为什么单个模型不够用
想象你在读一段代码。
短上下文看到的是"分号刚出现过",它猜下一个大概是换行。长上下文看到的是"上一行是循环的收尾",它猜下一个大概是右花括号。段落模型知道"这里已经连续几段是函数定义",它猜大概是新的一行注释开头。
三个判断都言之有据,但只有一个是对的。谁更可信,取决于你现在站在文件的哪个位置——而压缩时你事先并不知道答案。
多个模型怎么投票
上下文混合的做法是:为每个位置准备若干个模型,分别给出下一个符号的概率分布,再按权重把它们加权求和。
权重不是手工设定的,而是在线学出来的。每压缩一个符号,系统就知道自己猜对还是猜错,猜错的模型权重下调,猜对的权重上调。久而久之,在代码文件里,长上下文模型权重会自己涨上去;换成表格数据,短上下文和字节频率模型会占上风。
权重学习用的是神经网络里的 logistic 混合机制,结构比深层网络轻得多——每个模型就是一组可调参数,不涉及矩阵乘法。
解码端如何复现同一场投票
这是最巧妙的一环。
解码器拿到的是"你在第几步猜错了符号 X,实际符号是 Y"这样的修正信息。它不需要知道压缩器当时怎么投票——只要自己按同样规则重跑一遍同样的模型、算出同样的概率分布,就能确定当时应该给符号 X 多大的权重,进而知道该往回退多少比特。
换句话说,所有模型参数都是从已经解出的文本本身统计出来的,不需要额外传过去。这是压缩算法里非常典型的一招:让两端共享同一份可推导的状态,只传真正无法预测的残差。
和实际压缩软件的关系
上下文混合属于压缩率导向的极端路线,代价是速度——每一步都要更新多个模型和权重,计算量远高于滑窗匹配加熵编码的组合。
日常产品很少把它直接做成默认项,因为多数人更在意"快且够小"。但它的思路已经渗透进各处:ANS 熵编码原理里说的"用状态机代替分数运算",和这里讲的概率建模是一脉相承的。