承接上一篇《数据库接入大模型实战》,除了上述优化方案,还有一种更直接的方法:使用超长上下文的模型,将资料直接拖入对话框,让AI自动检索。 模型窗口进化与测试 如上图所示,过去两年内,模型的上下文窗口长度大幅提升。例如Gemini 2.0 Pro已支持2000万token的上下文,足以容纳四大名著。下面以Gemini为例进行测试。 本文以Gemini 2.0 Flash模型为例,支持100万token上下文,并有免费额度。 复制Gemini 2.0 Flash 模型ID。 回到 Cherry Studio,填写模型ID并添加。 整个《三国演义》仅消耗了约一半上下文窗口。利用Gemini超大上下文进行知识库检索,是一种高效方案。 总结与展望 AI知识库常被称为“demo五分钟,上线一年”。
本文就提出了一种网络结构Transformer-XL,它不但可以捕捉文本更长时的依赖,同时可以解决文本被分成定长后产生的上下文碎片问题。 如此一来,两个片段之前的上下文信息可以进行有效的传递。 进一步地,作者提出,在理论上不仅仅可以储存并重用之前一个片段的结果,只要GPU允许,完全可以重用前几个片段的结果,使上下文联系更远。
距离上一篇VFP AI 插件:超长上下文的识别(一)有些时间了。经过不断的试错和优化,终于完成了 VFP AI 插件的超长上下的识别。将时间从数小时压缩至最多几十分钟。
VFP AI 插件在访问大模型时,有一个上下文长度的问题。 对于 DeepSeek 而言,其大小为 128K(=128000 token)。 VFP AI 插件 2025.12.15 版,初步实现超长上下文的处理: 所分析 VCX 类库,使用类浏览器转换出的 prg 格式文件,文件体积为 400+KB,共 10329 行,超过模型最大上下文的最大限制
这项实验研究了Infini-Transformer模型在处理长达1M上下文长度的序列时,对于隐藏在不同部分(起始、中间、末尾)的通行密钥的检索准确性。 实验中报告了在各种长度(从32K到1M)的输入中,不同部位通行密钥的tokens级检索准确性。 具体来说,Linear变体在32K序列长度时在开始/中间/末尾的准确性为14/13/98,而到了1M长度时,准确性降至8/6/98。 Linear + Delta变体则显示出稍微均衡的性能,尤其是在较长的序列中,例如在1M长度时达到7/6/97的准确性。 Linear变体在最长的1M序列长度下,开始/中间/末尾的准确性分别为96/94/100,而Linear + Delta变体在相同条件下实现了完美的100/100/100的准确性。
由于上下文的长度是固定的,因此模型无法捕获任何超过预定义上下文长度的长期依赖性。此外,长度固定的片段都是在不考虑句子或其它语义边界的情况下通过选择连续的符号块来创建的。 因此,模型缺乏必要的上下文信息来很好地预测前几个符号,这就导致模型的优化效率和性能低下。我们将这个问题称为上下文碎片化。 为了解决上文提到的上下文固定长度的限制,本文提出了一种叫做 Transformer-XL(超长)的新架构。我们将循环概念引入了深度自注意力网络。 因此,对超长期依赖性建模成为了可能,因为信息可以通过循环连接来传播。同时,从之前的片段传递信息也可以解决上下文碎片化的问题。 我们的方法不仅可以捕获更长的依赖关系,还可以解决上下文碎片化的问题。
超长上下文处理:Kimi支持高达200万字的最长上下文输入,这是在大模型长上下文处理技术上的一个重要突破,使得它能够更好地理解和处理复杂、连贯的文本信息,比如用于论文总结、电影剧本分析、录音内容整理等。 Kimi实现超长上下文处理的技术原理 Kimi实现超长上下文处理的技术原理涉及到几个关键技术点,这些技术共同作用使其能够处理长达200万字的文本而不损失上下文信息,具体包括: 1. Kimi采用了更大规模的Transformer模型,并对模型结构进行了优化,以适应超长文本的处理需求。 2. 分块与重组技术:面对超长文本,直接将整个文本送入模型可能会超出硬件限制。 上下文保留策略:在处理每个文本块时,Kimi设计了特别的策略来选择性地保留或更新上下文状态,确保即便在分块处理后,整体的语境理解仍然准确无误。 通过这些技术和方法的综合应用,Kimi不仅能够处理超长文本,还能在理解、分析和生成内容时保持高度的准确性和连贯性,为用户提供前所未有的长文本处理体验。
DeepSeek新模型上线实测:1M上下文背后,是进化还是取舍?最近在DeepSeek官网上,上线了一个新的版本,这个版本或为V4正式发布前的最终灰度测试阶段。 这次升级主要包含以下几个重要的更新点:模型上下文处理长度将由原有的128K显著扩展至1M,实现近10倍的容量提升;知识库数据已同步更新至2025年5月,同时在多项核心功能维度均取得实质性技术突破。 新机制DeepSeekSparseAttention(稀疏注意力,DSA),旨在在处理长上下文(longcontext)时提升训练与推理效率,同时尽可能保持输出质量不变。 1M上下文与知识更新,属于很典型的基础设施升级,相当于这个新模型在速度和读取能力上有了明显的增长。但是,吐槽声也真实存在。 换句话说,DeepSeek这次面对的是一个典型的两难:一边是长上下文与推理/代码等“硬能力”的成本与收益,一边是拟人化表达与情感交互的“软体验”与黏性。
2.超长上下文支持支持128Ktokens上下文窗口(部分版本达1M)。采用ALiBi(AttentionwithLinearBiases)或YaRN位置编码,有效缓解长度外推问题。
与前代相比,Opus 4.6 在三个维度实现突破: 上下文革命:首次为 Opus 级别模型提供 1M token 超长上下文(Beta) Agent 能力跃迁:复杂任务规划、并行子任务执行、长时间会话维持 编程能力登顶:Terminal-Bench 2.0 评测中成为全球最强编码模型 二、核心技术创新详解 2.1 1M Token 超长上下文:从“记忆碎片”到“全量知识库” Opus 4.6 首次在 Opus 级别引入 1M token 上下文窗口(Beta),标准版仍为 200K,但已足够支撑: 完整代码仓库分析(10 万行+ 代码) 百页级法律/金融文档处理 跨会话长期记忆维持 关键突破:在 8-needle 1M 基准测试中,Opus 4.6 达到 76% 准确率,而 Opus 4.5 仅为 18.5% 。 这意味着模型真正具备了在超长文本中精准定位关键信息的能力。
谷歌 AI 掌门人 Jeff Dean 亲发贺信:「我们在此实验性更新中引入了 1M 长的上下文,以便对长篇文本(如多篇研究论文或大量数据集)进行更深入的分析。 在技术上,Gemini 2.0 Flash Thinking 主要有两点突破:可处理高达 1M token 的长上下文理解;能在多轮对话和推理中自我纠错。 Gemini 2.0 Flash Thinking 主推的亮点是超长的上下文窗口。 不过,众所周知,很多具备长上下文窗口能力的 AI 模型都有个通病:聊着聊着就「变傻」了,说的话前言不搭后语,或者就直接「摆烂」,跳过上下文中的大段信息。 因相比混合在一起的数千亿训练数据,上下文窗口的信息对于模型来说非常清晰,因此,上下文窗口的信息对于 Gemini 2.0 Flash Thinking 来说,就像你让把一张普通轿车的图片改成敞篷车一样,
当用户与一个拥有1M上下文窗口的模型对话时,模型需要为每一个历史token存储Key-Value缓存(KVCache)。 模型参数规模上下文长度KVCache显存占用(估算)GPT-4(推测)1.8T128K约80GBClaude3不明200K约120GBGemini2不明1M约600GB这意味着:即使是顶级GPU,单卡也无法容纳完整的 推动长上下文应用:TurboQuant让1M以上上下文窗口的模型部署成为可能,为文档分析、代码审查、多轮对话等场景铺平道路。 -2.0-Pro1M480GB96GB5.0xMixtral-8x22B128K38GB7.6GB5.0x关键发现:TurboQuant实现稳定的5倍压缩比(FP16→INT4+码本索引)1M上下文场景下 长上下文成标配:1M以上上下文窗口将成为主流模型的标配能力。新应用形态涌现:真正“无限记忆”的AI助手、全库级代码智能体、超长文档分析工具将迎来爆发。
新智元报道 编辑:LRS 【新智元导读】挖掘大模型固有的长文本理解能力,InfLLM在没有引入额外训练的情况下,利用一个外部记忆模块存储超长上下文信息,实现了上下文长度的扩展。 为了让大模型能够记忆并处理更长的上下文,来自清华大学、麻省理工学院和人民大学的研究人员联合提出无需额外训练的大模型长文本理解方法 InfLLM,利用少量计算和显存开销实现了 LLM的超长文本处理。 InfLLM旨在激发LLMs的内在能力,以有限的计算成本捕获超长上下文中的长距离语义依赖关系,从而实现高效的长文本理解。 作者构建了一个外部记忆模块,用于存储超长上下文信息;采用滑动窗口机制,每个计算步骤,只有与当前Token距离相近的Tokens(Local Tokens)和外部记忆模块中的少量相关信息参与到注意力层的计算中 然而,超长序列中的海量上下文对于记忆模块中有效的相关信息定位和记忆查找效率带来了重大挑战。 为了应对这些挑战,上下文记忆模块中每个记忆单元由一个语义块构成,一个语义块由连续的若干Token构成。
高级特性:自适应思维 (Adaptive Thinking)、提示词缓存 (Prompt Caching)、1M 超长上下文。 3. 1M 超长上下文 (Beta) Anthropic 提供了 1M Token 上下文窗口,但目前处于 Beta 阶段,需要显式开启。 ⚠️ 重要限制仅限 API Key:目前 Anthropic 不支持 在 OAuth/Subscription (Setup-Token) 账号上开启 1M 上下文。 五、最佳实践总结生产环境首选 API Key:稳定性高,支持缓存和 1M 上下文,便于成本核算。 个人开发用 Setup-Token:省钱,但需注意 Token 有效期,且无法使用高级缓存和超长上下文功能。
这一发布不仅将上下文窗口从V3系列的128K直接跃升至1M(百万Token),更通过一套名为“双轴稀疏架构”的系统性创新,实现了性能、成本与效率的完美平衡。 第一章:引言——一个时代的分水岭1.1从128K到1M:不仅仅是数字的跨越在DeepSeek-V4之前,128K上下文窗口已是业界顶尖水平。 DeepSeek-V4将上下文窗口一举提升至1M,这并非简单的线性扩展,而是一次质的飞跃。 1.3V4的核心价值主张超长上下文普惠化:1MToken不再是实验室里的奢侈品,而是所有官方服务的标配。极致性价比:以0.2元/百万Token的价格,将顶尖AI能力推向大众市场。 结论从128K到1M,DeepSeek-V4完成的不仅是一次技术参数的跨越,更是一场深刻的架构革命。
“ DeepSeek悄然将上下文窗口扩展至百万级Token,从128K到1M。窗口只是表象,真正藏在更新里的,是mHC流形约束与Engram条件记忆两项底层架构落地。” 01 — 2月11日,昨天,DeepSeek在网页端与App端同步推送版本更新,正式开启百万级Token上下文灰度测试,从原有128K扩展到1M。 在DS官网确认了版本更新: DS应该是国产模型中比较靠后才开始扩展上下文长度的模型了。在早些时候,Kimi 智能助手已宣布支持 200 万字超长无损上下文。 04 — 超长上下文 要在Transformer 模型中实现超长上下文,通常需要从 模型架构优化、训练策略 和 位置编码扩展 三个维度进行综合改造。 1. 超长上下文的关键在于 用“稀疏/线性注意力”取代部分“全连接注意力”(降低计算复杂度),并通过分阶段训练 让模型逐步适应更长的序列。
4月24日,DeepSeek-V4 预览版正式发布并同步开源,其核心亮点——百万Token(1M)超长上下文作为所有官方服务的标配,瞬间引爆了全球AI社区。 核心成就速览超长上下文:上下文窗口从 V3 的 128K Token 一举跃升至 1M Token,相当于一次可以处理《三体》三部曲体量的超长文本。 传统的自注意力机制(Self-Attention)的计算量和内存消耗与序列长度的平方成正比(O(n²)),这在1M长度下是完全不可行的。 最终,这项技术使得 1M Token 上下文 的实时交互成为现实,为处理超长文档、书籍、代码库等场景打开了大门。 它通过“记忆-计算分离”的双轴稀疏设计,巧妙地绕开了大模型发展的传统瓶颈,将超长上下文、顶级性能和极致性价比融为一体。百万字长文对话只是起点。
然而,目前存在一个普遍的限制:由于资源受限,当前大多 LLM 主要是在较短的文本上进行预训练,导致它们在较长上下文方面的表现较差,而长上下文在现实世界的环境中是更加常见的。 长上下文,目前有哪些难点待突破? 注意力复杂度。 上下文处理 (论文第 6 节):除了增强特定低级 Transformer 模块的方法外,一些方法涉及对现成的 LLM 与额外的上下文预 / 后处理。 因此,在长上下文 LLM 领域,这仍然是一个持续追求的目标。 正如在文章第 2.1、2.2 节中前面讨论的,作者已经概述了由于缺乏明确的记忆机制,仅依赖上下文内工作记忆以及在延长上下文交互期间 KV 缓存记忆消耗显著增加而产生的限制。
你想试试更强的长上下文和 agent 能力,Grok 也在快速追。 官方文档显示,当前 deepseek-chat 和 deepseek-reasoner 对应的是 DeepSeek-V3.2,128K 上下文;价格非常激进:缓存命中输入 0.2 元 / 1M tokens Grok / xAI:适合想玩 agent 和超长上下文的人 xAI 这条线现在的关键词,不只是 Grok,而是 工具调用体系。 所以,普通用户的付费逻辑很简单: 想要最稳:买 ChatGPT 想要代码和长文档:买 Claude 想先用国内产品、追求中文和性价比:先看 Kimi / DeepSeek 想尝鲜 agent 和超长上下文 你是开发者 要全能:OpenAI GPT-5.4 / mini 要代码和 agent:Claude Sonnet 4.6 要低成本:DeepSeek 要 Google 生态:Gemini 要工具化和超长上下文
JVM 是可运行 Java 代码的假想计算机 ,包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收,堆 和 一个存储方法域。JVM 是运行在操作系统之上的,它与硬件没有直接的交互。