编程基础篇 · AI 背后的算法

分治:上下文压缩的算法原理

动手实战篇的 Compaction 其实是分治:把长对话切段、各自摘要、再合并。亲手跑一次递归摘要,看信息怎么被层层压缩

本页解决的问题

先给结论

「分治:上下文压缩的算法原理」要解决的关键问题是什么?

动手实战篇的 Compaction 其实是分治:把长对话切段、各自摘要、再合并。亲手跑一次递归摘要,看信息怎么被层层压缩

判断标准

让这个结论先证明自己值得留下。 把这一页当成决策工具,而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果,以及一个能改变你判断的失败上。

下一步

写下一个问题:试完这个方法后,你能用什么证据回答它?

常见误区

结论听起来很完整,却没有检查最关键的假设。

亲手压一次 · 3600 token 的装修对话

下面是一段你和 AI 讨论装修方案的完整对话,12 条消息约 3600 token,眼看要把上下文窗口塞爆了。点「开始压缩」,留意三幕动作:先(分成三段)、再(每段各自收成一条摘要)、最后(三条摘要并成一条)——顶部的 token 计数器会告诉你压掉了多少。

当前上下文3600token
切分 → 各段摘要 → 合并,三幕连播
试试打开「保留最近 4 条」再压一次。这正是真实 Agent 的做法:最近几条对话往往就是你正在办的事,最金贵,一个字都不动;只把久远的部分压成摘要。你会看到 token 数没有压到 200 那么狠——保真和省空间,永远在做交换
概念卡 · 归并排序同款套路

刚才三幕动作有个正式名字:分治(Divide and Conquer)。教科书里它最出名的代言人是归并排序——把一列数切成小段、每段排好、再两两合并。归并排序排的是数,Compaction 压的是话,骨架一模一样

✂️ 切成小块

大问题直接解不动,就切成几个小块。归并排序:一列数对半切到只剩单个。Compaction:长对话按话题或轮次切成几段。

🔧 每块各自解决

小块规模小,好办。归并排序:小段各自排好序。Compaction:每段各自摘要——段够短,AI 一口就能读完、总结准。这一步还能并行干,又快一截。

🧩 结果合并

把小块的成果拼回完整答案。归并排序:两段有序数列合成一段。Compaction:几条摘要再合成一条总摘要。段还太多?递归再来一轮——上一课的味道回来了。

为什么不一口气让 AI 总结全文?因为「总结一万字」本身就会把上下文塞爆——这不就是我们要解决的问题吗。分治的聪明处在于:把「解不动的大问题」变成一堆「肯定解得动的小问题」,再花点力气拼装。工程进阶篇 Coding Agent 读大代码库也是这么干的:一个文件一个文件地读、各自记要点、最后汇总。
诚实卡 · 压缩的代价

⚠️ 摘要是有损压缩——细节会丢

原文:「预算 8 万以内」「我特别不喜欢红色,全屋别出现红色
压缩后:「讨论了预算和配色偏好」← 具体数字和红色禁令都没了
压缩后 AI 还知道「聊过预算」,但再问它「我预算多少」它只能猜;下次它给你配个红沙发,你都没处说理。所以动手实战篇反复强调:关键事实(数字、硬性要求、决定)要另外记进长期记忆或文档里,不能指望摘要替你留着。摘要负责「大概聊过什么」,档案负责「铁板钉钉的事」。

「亲手压一次 · 3600 token 的装修对话」里的算法代价曲线

「下面是一段你和 AI 讨论装修方案的完整对话,12 条消息约 3600 token,眼看要把上下文窗口塞爆了。点「开始压缩」, 留意三幕动作 :先 切 (分成三段)、再 治 (每段各自收成一条摘要)、最后 合 (三条摘要并成一条)——顶部的 token 计数器会告诉你压掉了多少」真正训练的不是背诵步骤,而是识别重复工作:输入变大时,程序到底多做了多少次比较、移动或递归。

先找重复工作,再谈快慢

「刚才三幕动作有个正式名字: 分治 (Divide and Conquer)。教科书里它最出名的代言人是归并排序——把一列数切成小段、每段排好、再两两合并。」可以拆成输入规模、每轮做什么、以及是否能缩小下一轮范围三个问题。Big-O 是描述增长趋势的语言,不是对每台机器的精确计时;常数、内存和真实数据分布也会影响最终结果。

  • 分治 = 切小、各治、再合 :解不动的大问题,变成一堆肯定解得动的小问题
  • Compaction 是分治在 AI 的真身 :切段 → 各段摘要 → 合并,和归并排序同一副骨架
  • 最近的对话最金贵 :真实 Agent 只压旧的、留新的——保真和省空间永远在交换

别把理论最优当成无条件最优

面对 AI 写出的算法,先用小输入手算一遍,再用逐渐放大的数据做基准测试。这样才能把「把小块的成果拼回完整答案。」从一句结论变成可检查的性能判断。

从「亲手压一次 · 3600 token 的装修对话」走到「概念卡 · 归并排序同款套路」

「亲手压一次 · 3600 token 的装修对话」先把问题落在「下面是一段你和 AI 讨论装修方案的完整对话,12 条消息约 3600 token,眼看要把上下文窗口塞爆了。点「开始压缩」, 留意三幕动作 :先 切 (分成三段)、再 治 (每段各自收成一条摘要)、最后 合 (三条摘要并成一条)——顶部的 token 计数器会告诉你压掉了多少」上;到了「概念卡 · 归并排序同款套路」,讨论继续推进到「刚才三幕动作有个正式名字: 分治 (Divide and Conquer)。教科书里它最出名的代言人是归并排序——把一列数切成小段、每段排好、再两两合并。 归并排序排的是数,Compaction 压的是话,骨架一模一样」。两段连起来,重点就不只是记住一个结论,而是看清它成立所依赖的条件。

把这条判断带到下一个场景

算法题换成真实任务后,先找出重复工作,再问输入规模如何变化,最后用一个小基准验证理论判断。这样不会把复杂度记成脱离场景的标签。

  • 「亲手压一次 · 3600 token 的装修对话」:下面是一段你和 AI 讨论装修方案的完整对话,12 条消息约 3600 token,眼看要把上下文窗口塞爆了。点「开始压缩」, 留意三幕动作 :先 切 (分成三段)、再 治 (每段各自收成一条摘要)、最后 合 (三条摘要并成一条)——顶部的 token 计数器会告诉你压掉了多少
  • 「概念卡 · 归并排序同款套路」:刚才三幕动作有个正式名字: 分治 (Divide and Conquer)。教科书里它最出名的代言人是归并排序——把一列数切成小段、每段排好、再两两合并。 归并排序排的是数,Compaction 压的是话,骨架一模一样
  • 「最后的要点」:段还太多就递归再压一轮 :上一课的递归 + 这一课的合并 = 完整的分治

最后的「最后的要点」把讨论落到「段还太多就递归再压一轮 :上一课的递归 + 这一课的合并 = 完整的分治」。回看这条线索时,最值得保留的是:当输入、规模或风险改变,哪些判断需要重新做一遍。

✅ 这一课想和你分享的

  • 分治 = 切小、各治、再合:解不动的大问题,变成一堆肯定解得动的小问题
  • Compaction 是分治在 AI 的真身:切段 → 各段摘要 → 合并,和归并排序同一副骨架
  • 最近的对话最金贵:真实 Agent 只压旧的、留新的——保真和省空间永远在交换
  • 压缩有损:「8 万以内」「别用红色」这种关键事实要另存,别指望摘要
  • 段还太多就递归再压一轮:上一课的递归 + 这一课的合并 = 完整的分治
标记为已学完 阅读进度会自动记录
← 上一篇下一篇 →

继续阅读

同一条线上的下一篇。

文章讨论

读到这里,留下一个判断。

把刚想明白的地方、还没想通的问题,留给下一位一起学习的人。

正在讨论 分治:上下文压缩的算法原理 AI 背后的算法
3条讨论文章讨论 · 与共学社区同步
在共学社区查看
AM
Asha Morgan内容编辑
观点实践记录

我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是,知道下一步要观察什么。

文章讨论7 有帮助
LH
Lin Harper独立开发者
观点观点

读完以后我先回头找它成立的条件,而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。

文章讨论5 有帮助
KM
Kiki Moore产品运营
问题问题

如果把这个判断放到真实工作里,最先需要补的约束是什么?我想知道从阅读到第一次实践之间,哪一步最值得先做。

文章讨论4 有帮助