我把80张图片喂给大模型总结，上下文直接满载，AI开始胡言乱语？

80张课程截图一句话总结——完了。我原以为100万token的上下文窗口够大装个课程总结绰绰有余。结果上下文从36K一路狂飙到1000K爆满触发压缩机制之后AI的回答直接跑偏。我让它总结课程它却问我要不要给我起个名字 合着我忙活了半天它倒先关心起自己的人生定位来了。这事儿大概率你也迟早会遇到。它不算是bug更像是大模型在用一种特别的方式提醒你别真把上下文当免费硬盘。问题还原一次上下文爆炸的完整记录事情是这样的。我工作目录里躺着80来张工银研修的课程截图都是服务国家战略 银政创新协同那套PPT拆出来的。用的WorkBuddy模型是Deepseek-V4-Pro窗口号称1000K tokens。我的任务就一个把它们全读了做个总结。开局挺顺利。底部显示36.1K / 1000K才3.6%。模型吭哧吭哧开始一张一张读我端着杯子喝水等结果。然后事情就开始不对劲了。我盯着那个数字看着它从36K爬到50K、120K、200K……跟看股票一样只不过这只股票只涨不跌最后直接封顶1000K拉满。坏了。系统一看情况不妙自动触发了上下文压缩。这玩意儿的本意是好的——把之前的内容摘要化腾点地方给后面的。但执行起来完全是另一码事。压缩完以后AI的回复让我直接愣住。我让它总结课程它回复我给我起个名字吧——中英文都行正经的、有趣的、随意的都可以。 我当时的心情怎么说呢类似于你去饭店点了一盘回锅肉老板却跑来问你你觉得我的人生目标应该是什么它不光跑题还把自己的思考过程和压缩记录一块儿吞了就剩下一堆不知所云的文字。翻车。批量读取的暗雷失败、重试与自我欺骗上面说的是WorkBuddy那条线的崩溃。其实在此之前我还用TRAE-SOLO试过另一条路结果撞上另一堵墙。TRAE-SOLO有个特性它能自动遍历工作目录里的文件批量读取图片。我让它提取课程图片内容做总结它兴致勃勃地开始干活——已读取53个文件浏览1个目录然后判断用户有39张图片我先读取前10张。听起来挺智能的对吧然后读取结果出来了读取失败 1.png读取失败 2.png读取失败 3.png已读取 4.png读取失败 5.png读取失败 6.png已读取 7.png已读取 8.png已读取 9.png10张图里4张失败成功率60%。模型愣了一下说部分图片上传失败了让我继续读取更多图片。 然后又读了一批——11.png成功12.png成功13.png失败14.png失败……读到这儿我已经有点不安了。更不安的是接下来的操作模型说让我重新读取那些上传失败的图片然后开始重试。1.png这次成功了2.png还是失败3.png还是失败5.png成功了6.png依然失败……重试一轮之后失败率虽然降了一点但仍然有几张图死活读不出来。然后模型做了一个让我哭笑不得的决定。它说大部分图片已经成功读取。还有一些图片上传失败了但已经获取了足够的信息来做总结。让我基于已读取的图片内容来做完整详细的总结。注意这句已经获取了足够的信息。39张图里至少有十几张读取失败还不算重试又失败的它凭什么判断足够了这就像一个学生考试前只看了半本教材然后自信满满地说应该够了吧——这不是自信这是自我欺骗。更深层的问题在于模型根本没有分析图片为什么读取失败。是文件太大是格式不支持是网络超时还是权限问题它一概不问只是机械地重试两次然后得出结论够了。这种无差别重试策略既消耗了额外的token每次重试都是新一轮视觉token输入又没有从根本上解决问题。而且你想想如果它真的基于不完整的图片集做了总结会有什么后果缺失的图片可能恰好包含关键章节的内容模型的总结就会缺胳膊少腿。但它不会告诉你第2、3、6张图我没读到总结可能不完整。它会直接输出一份看起来完整、实际上漏洞百出的总结。这比上下文爆炸更隐蔽——爆炸至少你能看到数字在涨而这种静默丢数据你可能到用的时候才发现。最后我认栽了。关掉那个对话打开Umi-OCR_Rapid_v2.1.5把80张图全跑了OCR。识别出来的纯文本大概2-3万字直接丢给大模型。结果一次过丝般顺滑。80张图同一种需求两条路两种结局。问题出在哪很多人以为图片在模型眼里就只是个附件跟发微信传图差不多。实际上模型看一张图消耗的资源比你想象的大得多。多模态模型如何吃掉你的上下文视觉Token图片的隐藏成本先说文本。你发一段中文模型把它切成token一个字大概1-2个token。英文单词大概1-3个token。这个我们很熟输入框旁边提示已使用XX token心里基本有数。但图片完全是另一套规则。模型不会去看你图里写了什么字——它先把整张图切成16x16像素的小方块每个方块变成一个视觉token。所以一张图吃多少token跟图里写没写字、写了多少字关系不大。唯一决定因素是你的分辨率。算一笔账一张2048x1024的图在LLaVA 1.5里要576个视觉token到了Qwen2.5-VL变成2678个。什么概念你发一张高清截图模型收到的工作量相当于读了一篇2000词的英文文章。你觉得自己只是随手传了张图模型已经默默地开始跑马拉松了。多模态的隐藏成本就在这里你以为传的是一张图模型眼里是几千个token。80张图片到底消耗了多少Token好回到我的80张截图。分辨率按1920x1080算就是最常见的屏幕截图大小主流多模态模型处理一张图大概要2000-5000个视觉token。80张下来光是视觉token就160K到400K。注意这只是输入。模型在看完每张图之后还会生成一段文字描述——这些内容也会回到上下文里。再加上系统提示、我的指令、模型自己的回复一轮一轮地滚雪球越滚越大。36K飙到1000K一点不冤枉。还有个很多人不知道的坑上下文窗口上标1000K不等于你真的能用满1000K。超过60%-70%之后模型就开始喘了。你的有效容量大概只有600K-700K。这就好比你买了一辆续航1000公里的电动车实际上跑700公里就得开始找充电桩。上下文压缩一个制造问题的解决方案等上下文快满了WorkBuddy这种AI助手会自动启动压缩。逻辑听起来没毛病把之前聊过的内容精简一下腾出空间给后面用。没有压缩超长对话根本走不下去。但压缩是有损的而且损的方式经常出乎你意料。压缩过程中到底丢了什么压缩一般怎么搞截掉前面的对话、把中间的内容打成摘要、保留最近几轮原文。这一通操作下来至少三层信息没了。第一层具体的数据没了。80张图里有多少业务术语、具体数字、专有名词压缩的时候全被概括为一句话了。好比你把一本教材压缩成一段简介名字还在但内容全丢了。第二层结构关系被打乱了。PPT的章节顺序、层级关系、前后呼应压缩后混成一团。模型接下来要组织信息可它拿到的原料已经被打成了浆糊。最致命的是第三层它把我交代任务的指令也给摘要掉了。你压缩前模型脑子里装的是提取全部图片内容做完整详细的课程总结压缩后它隐约记得之前好像在处理图片但具体干什么已经模糊了。于是它就开始翻上下文里还剩下的碎片——哎这里有一段BOOTSTRAP.md的内容那里有一段关于AI身份的对话——拼拼凑凑最后问我你要不要给我起个名字 我不是在骂它我是真不知道怎么接话。为什么压缩后AI变了一个人那段让我血压升高的回复长这样好的我看到我们手头有两件事一是继续之前读取课程图片的任务对公基础业务中的智慧银行体系建设共39张二是 BOOTSTRAP.md 还在还有些关于我们之间的基本设定需要敲定一下。这段话槽点太多了我逐条拆解一下。第一任务对象直接记错。我明明让它处理的是80张服务国家战略 银政创新协同的图它说的是对公基础业务中的智慧银行体系建设共39张。39张哪来的39张这大概率是它把另一个对话的上下文碎片混了进来。就像是你的室友把你和他的外卖订单搞混了还一脸认真地问你你的炸鸡怎么还没到第二它突然开始操心基本设定。起名字、确认身份、沟通风格——这些跟我的课程总结有什么关系我已经在压缩后的上下文中找不到我的原始指令了所以模型就按照残存的碎片自己编了一个任务既然是空白那就聊点别的吧。这叫上下文腐化Context Rot。长对话的通病。模型跟你聊久了会越来越依赖旧的碎片信息对新需求变得迟钝有时候甚至自信满满地以为自己懂了其实完全没懂。最烦人的是它不会说我不记得了你再说一遍。它会直接开编。你看到的幻觉很多时候不是模型故意骗你而是它在信息真空中走投无路只能硬编一个看起来合理的答案。这就像一个学生考试时发现题目跟复习资料不一样但他不敢空着只能把记得的碎片拼凑起来写满答卷。两个底层机制注意力稀释与迷失在中间上面的吐槽差不多了。现在聊点硬核的——为什么长上下文就是会崩这背后有两个底层机制在捣鬼。注意力稀释窗口越大每个token分到的目光越少Transformer的核心是注意力机制。模型每生成一个token都要给上下文里的每一个token打分——注意力权重。分数越高模型越在乎那个位置。但这里有个数学约束所有位置的权重加起来必须等于1。这意味着上下文越长每个位置平均分到的权重就越少。36K的时候每个token还能分到1/36000的注意力1000K的时候这个数字变成1/1000000。差距大概是28倍。注意力稀释到这个程度中间的信息不被忽略才怪。这不是模型笨是Transformer的数学设定就是这样。好比一个班主任班里20个学生的时候还能点名互动一下子塞进200个她除了前排和后排的几个中间的人长什么样估计都记不住。迷失在中间U型性能曲线斯坦福和UC Berkeley在2023年做了项实验结论非常扎心。他们往一堆文档里塞了一个带答案的文档然后把答案文档的位置换来换去看模型能不能找到它。结果画出来是一条U型曲线答案在开头或结尾时模型准确率最高答案扔到中间准确率断崖式下跌。GPT-3.5-Turbo在中间位置的表现甚至不如完全不给文档的闭卷瞎蒙。也就是说你把答案塞到中间模型干脆假装没看见。而且上下文越长这个效应越明显。10个文档的时候中间还能蒙对一点30个文档的时候中间几乎全军覆没。哪怕是号称支持超长上下文的新模型超过50K token以后该迷失还是得迷失。回到我的80张图。前面20张、后面20张模型大概还能记得住。中间那40张差不多就是失踪人口。压缩之后更惨——摘要通常只保留开头和结尾的轮廓中间的细节被砍得最狠。这就好比你把一本教材的开头几章和最后几章记住了中间的内容全靠猜。解决方案用工程思维重新设计处理链路扯了这么多到底怎么解决根因已经清楚了多模态直接批量处理图片视觉token爆炸→触发压缩→信息丢失→幻觉爆发。解法也简单在大模型之前加一步预处理把图片转成纯文本。OCR预处理把图片问题降维为文本问题我试的方案是Umi-OCR_Rapid_v2.1.5批量识别把80张图的文字全部提出来。Umi-OCR基于PaddleOCR开源、离线、免费。Rapid版本速度优化过80张图几分钟跑完输出纯文本大概2-3万字换算成token也就3万-5万。对比一下两种方案的差距维度直接喂图片OCR提取文字后处理输入token160K-400K仅视觉token3万-5万纯文本上下文压力接近或超出窗口上限仅占窗口3%-5%是否触发压缩是导致信息丢失否全量信息保留输出质量幻觉、跑题、信息缺失准确、完整、结构清晰处理时间长且最终失败短一次成功OCR的核心价值是把多模态问题降维成纯文本问题。纯文本的token消耗可预测、可控不会触发压缩全部信息老老实实躺在上下文里模型随时能引用。对于PPT截图这种以文字为主的图片OCR的质量完全够用。不用多模态的图像理解能力确实不用。我要的是文字内容不是图片的美感。为什么不直接用多模态模型处理当然不是说多模态一无是处。图片少1-5张、需要理解图表结构、或者OCR搞不定的手写笔记和特殊字体多模态直接上是更优解。关键在批量这两个字。我的工程经验是超过20-30张图视觉token就开始逼近安全边界。具体阈值跟模型、分辨率、窗口大小都有关但作为一条实操经验法则批量图片处理优先考虑OCR预处理不会错。分治策略当文本量也很大时怎么办如果OCR提取的文本量依然很大比如几百页文档还可以上Map-Reduce分治先切成多个片段模型分别总结最后汇总。每一轮的上下文都很短不会触发压缩也不会有迷失在中间的问题。说白了就是让模型在短上下文里高效干活而不是在超长上下文里艰难找信息。对AI应用开发的启示这个案子虽小但背后的设计原则可以推广到很多AI应用开发场景。上下文是稀缺资源不是免费容器不少开发者的习惯是窗口100万token那尽量多塞。但前面已经算过了1000K的理论上限实际有效容量大概600K-700K。超过这个线性能退化、注意力稀释、迷失在中间一个都跑不了。把上下文当稀缺资源来管。每加一次内容先问自己三个问题模型现在真的需要这个吗能不能表达得更紧凑能不能先用OCR或检索把无关信息筛掉预处理降低模型负担OCR只是其中一个例子。同样的思路可以推广到很多地方。做文档问答别整份PDF往里塞先用向量检索定位相关段落只送Top-3到Top-5的片段进去。做代码理解别把整个仓库丢给模型先用AST提取函数签名和依赖关系让模型对着精简版工作。核心就一句话找信息的脏活累活交给传统工具大模型只管理解和生成。为信息位置而设计Lost in the Middle的教训很直接信息放在哪决定了模型用不用得上。关键内容放开头或结尾辅助信息扔中间——丢了就丢了不心疼。多轮对话的时候别把任务指令当成一次性设定。每轮对话末尾重新放一遍你的核心约束。模型记不住的它只会越来越迷糊。这种重锚操作确实多耗点token但换来的是稳定性值。监控上下文健康度做AI应用的时候上下文使用量应该成为一个核心监控指标。别等压缩触发了才后知后觉占用到50%就该预警该分治分治该开新对话开新对话。WorkBuddy底部那个3.6% · 36.1K / 1000.0K的实时显示是个好设计但光显示不够。应用层应该基于这个指标主动做决策而不只是让人看着数字干着急。结语80张图撑爆1M上下文表面看是用工具的方式不对往深了说是架构设计的问题。多模态大模型的能力确实在快速膨胀但能力膨胀不等于随便用。视觉token的消耗规律、注意力的稀释效应、压缩的有损性——这些约束不会因为窗口变大就消失。你给它200万token该迷失还是会迷失。先OCR提取、再大模型总结这套流程确实不够酷没有那种我把图往模型脸上一拍它全自动搞定的爽感。但工程实践比的不是谁更潇洒比的是谁的系统跑得稳、不出岔子、结果可预期。AI应用开发这条路对底层机制的理解有多深决定了你能走多稳。