AI技术坟场笔记——1M上下文的乾坤

始于咨询.终于因果

当上下文窗口从几千token暴增到100万token——约70万字、1500页书——所有人都说"记忆问题解决了"。但"记得住"和"看得懂"之间，隔着一道窗口再大也跨不过去的坎。

100万token上下文窗口：能装下整个企业，但装不下一个"为什么"

先回顾一下我们走到了哪。第一期，我拉通了六轮技术周期的全景——从Agent编排到Fable 5，地基始终是向量数学。第二期，我拆了Agent编排——它解决的是"不想写代码但想串联系统"的工程效率问题，不是智能问题。第三期，我拆了RAG——向量相似度这个地基上盖不出因果理解的楼，三个"不等于"一道也跨不过去。

现在进入第三轮。2024年2月，Google发布Gemini 1.5 Pro，首次把上下文窗口推到100万token——约70万字，相当于1500页书。Anthropic紧随其后，2025年Claude Sonnet 4全面开放1M上下文。到了2026年，Claude Opus 4.7标配1M，Gemini 3.1 Pro更是堆到了2M。

逻辑听起来极其合理：RAG之所以不行，是因为检索只能看到片段。那如果不做检索呢？把整个企业的所有文档——制度、SOP、会议纪要、历史决策——一次性全部塞进上下文窗口，让模型在"看到了全部"的前提下回答你。这不就绕过了RAG的检索瓶颈吗？

这个逻辑里藏着一个和RAG一模一样的假设——"看到了全部"等于"理解全部"。而这个假设，同样是错的。

错的理由不是"窗口还不够大"。错的理由藏在三个真实的实验数据里。

一、"看到了"不等于"用得上"——上下文利用率只有54%

最直观的问题出在效率上。2025年，向量数据库公司Chroma对18个前沿模型做了一项大规模压力测试。结论非常残酷。

广告的1M窗口，模型实际能有效利用的只有54%左右。Gemini 2.5 Pro在生产环境中的平均有效利用率约54%。剩下46%的token——你放进去了，模型也"扫"了，但注意力权重太低，相当于没读。你把企业两年的全部会议纪要塞进去，模型真正"认真对待"的，只有其中一半。

更麻烦的是"悬崖效应"。模型的表现不是线性下降的——它在某个临界点突然断崖式暴跌。就像一个人读书：前100页读得仔细，100到300页开始走神，300页之后直接睡着了。而且这个悬崖的位置不固定——同样的文档、同样的长度，这次崩溃在280K token，下次可能崩溃在310K。

更讽刺的是：结构越清晰、组织越良好的文档，注意力反而衰减得越快。一篇逻辑缜密、层次分明的企业制度文档，在100K token后的信息损失率，比一篇随机打乱的文字还高。

为什么？因为LLM的Attention机制天然给开头和结尾更高的权重。结构清晰的文档里，关键信息恰好分布在中间章节——而这些章节的注意力权重最低。你把制度写得好，反而害了它。

这就是"上下文税"（Context Tax）：你为1M token付了全款，模型只给了你54%的阅读量。而且你没办法知道它跳过了哪46%。你问了一个问题，它答了——但你不知道它的答案是基于哪一半建起来的，又漏掉了哪一半。

但效率问题还是表层的。更深的问题是：即使模型认真"读"了全部内容——它"读"到了什么？

二、"读到了文字"不等于"抓到了信息"——当词和词长得不像的时候

2025年ICML顶会上发表了一个叫NoLiMa的基准测试。它的设计极其精巧：在长文档里埋一段信息，然后问一个相关的问题——但问题用的词和文档里的词几乎没有重叠。比如文档里写的是"渠道让利计划"，问题问的是"怎么给经销商那三个点的折扣"。

你知道在第三期里，我说过RAG死在这件事上——"让利"和"折扣"向量距离太远，所以RAG找不到。那你猜1M上下文窗口能不能解决这个问题？

答案是：解决了，但只解决了一半。当上下文窗口在几千token以内时，11个模型里有10个表现良好。但当上下文拉长到32K token——只有标准论文的长度——13个模型里有11个跌到了短文本表现的50%以下。GPT-4o从短文本的99.3%准确率，直接掉到69.7%。

这意味着什么？长上下文窗口确实让你"看到了"那一段——因为不再需要向量检索去"找"它了，它物理上就在窗口里。但看到之后呢？当问题用的词和文档里的词不一样的时候，模型在长窗口里还是很难定位到那一段——因为Self-Attention的计算量随窗口长度呈指数级膨胀，非字面匹配的信息淹没在token的海洋里。

第三期我说RAG的问题是"向量距离不够近所以找不到"。1M上下文把这个问题的形式改了——从"找不到"变成了"找不到"。前一个"找不到"是检索层的问题：文档在知识库里，但检索没命中。后一个"找不到"是注意力层的问题：文档就在模型眼前，但模型在100万token的海洋里游不过去。

你企业的真实文档就是这样的。市场部写"渠道让利计划"，财务部写"销售折扣专项"，运营部写"终端补贴"。三份文件你都塞进了1M窗口——它们都在里面。但你问"经销商让利怎么执行"的时候，模型看到市场部那份的概率很高，看到财务部那份的概率骤降，看到运营部那份的概率接近零。不是因为它们不在窗口里。是因为注意力够不到。

如果说定位信息已经够难了——那定位多个相关信息、并理清它们之间的时间顺序呢？

三、"找得到多个信息"不等于"理得清它们的关系"——多针检索最好成绩只有63.5%

上一个基准测试测的是"找一根针"。但企业经营里几乎没有只找一根针的问题。

第三期里我讲过的审批权问题——"生产线上的耗材采购谁有审批权"——这个答案分散在采购制度、生产管理制度和财务授权办法三个文件里。你需要同时找到三根针，然后把它们拼在一起。

2025年EMNLP上有一个专门测这个的基准——Sequential-NIAH。把多个信息点埋在不同位置，让模型逐一提取并理清顺序。总共14000个样本，上下文从8K到128K。

最好的模型，准确率只有63.5%。而且准确率随上下文长度和针的数量双重衰减——窗口越大、需要提取的信息点越多，模型越乱。不是线性退化，是指数级退化。2根针→91%，4根针→74%，6根针→52%，8根针→31%。

现在把你企业的真实场景代进去。B产品线降价这件事，在两年内讨论了五次——每次的结论都不一样。五份会议纪要全部在1M窗口里。你问"B产品线降价的最终决议是什么"——模型需要在100万token里找到五段相关讨论，辨认它们的先后顺序，理解每一次反转的逻辑，然后告诉你哪一个才是最终决定。

但它连几根针的顺序都理不清。准确率63.5%——这是在标准测试集上。放在你企业那些术语不统一、格式不标准、逻辑不线性的真实会议纪要里，这个数字只会更低。

而且和三期里RAG的困境一模一样——数据越多，答案越乱。1M上下文没有解决"多次反转"的问题，反而让问题更暴露了：以前RAG只召回其中两次讨论，虽然不全但至少不矛盾。现在五次讨论全在窗口里，模型被迫面对五个互相矛盾的"正确答案"，然后把它们"综合"成一段更加流畅的废话。

1M上下文的终极困境是：它能让你"看到全部"，但"看到全部"之后需要的不是更大的窗口——是更强的结构化理解能力。而它在结构上的表现，比在字面匹配上的表现还要差。

但最让人清醒的，还不是这些实验数据。是学术界正在发生的事情。

四、学术界已经过了"更大窗口"的时代——他们都在往另一条路上走

我在调研这一期的过程中发现了一个很有意思的现象。

在2025到2026年的顶级学术会议和期刊上——ICML、EMNLP、NAACL、ACM——我搜到了七篇相关论文。没有一篇在讨论"如何把上下文窗口做得更大"。一篇都没有。

它们全在讨论一件事：如何把知识图谱、因果图和LLM结合起来做可解释推理。

工业故障诊断场景的KG-LLM融合方案已经达到94-96%的准确率。制造业预算差异分析中，一个叫Causal-LLM的混合框架把因果发现算法嵌入LLM推理管道——准确率从纯LLM的0.76跃升到0.87，诊断时间从3.2小时降到10秒。研究者明确指出：关键差异不在LLM本身——在于额外加的那一层因果结构。

这不是小圈子里的自嗨。2026年ODSC——全球最重要的数据科学会议之一——专门设置了一个分论坛。核心演讲者提出了"Dual-Graph Stack"架构：Context Graph负责持久化的上下文记忆，Decision Graph负责因果推理。他在台上说了一句让人印象极深的话：

"更长的上下文本身不够。推理系统才是竞争优势。"

这句话的价值不在于它有多深奥。在于说话的人不是在讲一个遥远的未来——他在讲2026年已经在发生的工程实践。

与此同时，Google Gemini虽然在上下文窗口上持续领先——1M、2M、可能在冲刺更大——但你看Google官方怎么定位Gemini Enterprise？不是"我们的窗口最大"。是"在你的Gmail、Docs、Sheets、Meet里，AI就在手边"。长上下文窗口是基础设施，不是核心竞争力。连Google自己都知道：窗口大只是你把AI嵌入工作流的条件之一，不是AI本身的价值。

但很多企业的认知还停留在"下个版本窗口更大了就好了"的阶段。这就是最危险的地方——你在等一个已经被学术界判了"边际收益递减"的技术方向，而另一条路已经跑通了94%的准确率。

所以1M上下文窗口到底解决了什么，没解决什么？

五、1M上下文的真实位置：一个被高估了的工程改进

我不想说1M上下文没用。它有用。但它的有用，和很多人以为的有用，不是同一件事。

1M上下文真正解决的是"检索瓶颈"——你不再需要先把文档切成碎片、转成向量、祈祷检索能命中。你把它们全部放在桌面上，让模型自己看。这确实绕过了向量检索的三大固有问题中的第一个："找不到"。

但它没有绕过第二个和第三个。

"读不懂"的问题仍然在。看到了全部文档，不等于理解了文档之间的逻辑关系。采购制度、生产制度、财务授权——三份文件全在窗口里，但模型仍然不知道"审批权"是这三份文件里哪些段落的交集。它没有"概念映射"的能力——"让利"和"折扣"在它眼里仍然是两个不同的东西，只是现在它们刚好在同一本书里。 "理不清"的问题更严重了。看到了全部会议纪要，不等于理解了决策演化的时间线。五次讨论全在窗口里，五次结论各不相同，模型没有任何内在机制去判断"哪一次是最终决定"。它唯一能做的就是把这些矛盾的信息"综合"成一段流畅的文字——而流畅和正确，在数学上是两件事。

如果把AI坟场笔记前三期串起来看，1M上下文窗口的位置非常清晰。Agent编排解决的是"不想写代码"的问题——工程效率。RAG解决的是"不想手动翻"的问题——检索效率。1M上下文解决的是"不想检索不准"的问题——窗口效率。三期技术，三个层次，但都在解决同一个维度的东西：让信息更高效地到达LLM的输入端。

它们没有一期解决过另一件事：让到达输入端的信息被正确地理解。Agent编排把流程串起来了——但没让LLM更会判断。RAG把段落检索出来了——但没让LLM更会分清相关和正确。1M上下文把全库都装进来了——但没让LLM多出一个"因果推理"的模块。三期的共同结论是：输入管道一直在升级，但推理引擎始终没有变过。

这就是为什么2026年的学术界已经不讨论"更大窗口"了。不是窗口不够大——2M、10M、100M都不够大。问题是窗口不管多大，它解决的始终是"看到"的问题。而企业经营的真正瓶颈，从来不是"看不到足够多的信息"——是"看到信息之后怎么判断"。

一个能装下整个企业的窗口不等于一个能理解整个企业的大脑。前者是桶，后者是炉。桶越大装得越多——但桶永远不会把东西烧成判断。

顺便说一句——最近很多人把 Obsidian 的 WikiLink 知识图谱和 LLM 结合起来，走的是"图谱感知混合检索"路线：用你手工标注的双向链接作为检索的排序信号，让 LLM 在"有结构的地图"上找信息而不仅仅在"向量噪音"里捞。这条路确实比纯 RAG 强——双向链接是显式的、人标注的关系，不像向量距离那样分不清"让利"和"折扣"。但它的天花板同样清晰：WikiLink 图解决的是"找信号"的问题，不是"理解信号"的问题。它知道[[原料成本]]和[[毛利率]]之间有链接——但它不知道谁导致谁，也算不出换了供应商会怎样。那一步，需要的是因果引擎，不是更大的图。

AI坟场笔记 · 第四期 · 完

系列简介

一个前企业战略投资总监，三年每天实测AI在真实经营场景中的表现。每一期拆解一轮技术浪潮——它解决了什么、没解决什么、为什么天花板在第一天就已经写好了。

下期预告：

MCP协议到CLI——给了它手，没给它判断力。