- 综合排序
- 最热优先
- 最新优先
- 来自专栏云云众生s
解决RAG与长上下文模型的困境
现在，长上下文模型正在兴起，例如具有200万个token上下文窗口的Gemini，其潜在优势使您不禁想知道是否应该完全放弃RAG。 解决这一难题的关键在于了解使用长上下文模型的优缺点，并根据您的用例做出明智的决定。 RAG与长上下文模型的优缺点 传统上，LLM具有较小的上下文窗口，这限制了可以一次处理的文本或token数量。 高质量的上下文是通过针对所提问题进行高度选择性的细粒度搜索实现的，而这是RAG能够实现的。 最后，长上下文模型需要更多GPU资源来处理长上下文，从而导致处理时间更长，成本更高。 尽管存在局限性，但长上下文模型支持一些需要更长上下文的引人注目的用例，例如翻译或摘要，例如，将文档从英语翻译成梵语（印度使用人数最少的语言）用于教育目的。 长上下文模型对于某些需要更长上下文的用例非常适合减少幻觉。但是，对于所有其他用例，我们建议使用RAG检索与回答用户问题相关的上下文，以实现高精度和成本效益。
72610编辑于 2025-01-23 - 来自专栏前端必修课
超长上下文模型知识库实战
承接上一篇《数据库接入大模型实战》，除了上述优化方案，还有一种更直接的方法：使用超长上下文的模型，将资料直接拖入对话框，让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五分钟，上线一年”。
75720编辑于 2025-05-05 - 来自专栏Python进阶之路
探究大语言模型如何使用长上下文
虽然最近的语言模型能够将长上下文作为输入，但对它们使用长上下文的情况知之甚少。这项研究分析了语言模型在两项任务中的表现，这两项任务要求识别输入语境中的相关信息：多文档问题解答和键值检索。 特别是，当相关信息出现在输入上下文的开头或结尾时，性能往往最高，而当模型必须在长上下文中间获取相关信息时，性能会明显下降，即使是明确的长上下文模型也是如此。 这项研究的分析使人们更好地了解语言模型如何使用输入上下文，并为未来的长上下文语言模型提供了新的评估协议。 因此，本研究提供了对语言模型如何使用输入上下文的更深入的理解，并为未来的长上下文语言模型提供了新的评估方法。 这篇论文的研究结果和分析提供了一个更好的理解语言模型如何使用其输入上下文，并为未来的长上下文模型提供了新的评估协议。
54800编辑于 2024-05-25 - 来自专栏机器学习与统计学
长上下文 LLM 会让 RAG 过时吗？
今天，让我们来探讨这场辩论，比较 RAG 和长上下文 LLM，同时分析学术研究。 支持100 万 token 上下文的大模型——MiniMax- M1 什么是长上下文 LLM 和 RAG？ RAG 从外部来源检索相关信息，而长上下文 LLM 则直接在其上下文窗口内处理大量输入。 基于学术研究的比较 论文一) 长上下文语言模型能否取代检索、RAG、SQL 等？[2] 长上下文语言模型能否取代检索、RAG、SQL 等？") 长上下文语言模型能否取代检索、RAG、SQL 等？ 长上下文 LLM 的性能略低于 RAG，同时还需要更多的 token 上下文。 一种集成了 RAG 和长上下文 LLM 的混合方法将重新定义信息检索领域，充分利用两种系统的优势。 检索将有助于降低仅使用长上下文 LLM 会产生的成本。
41010编辑于 2025-07-08 - 来自专栏云云众生s
RAG在长上下文模型时代仍然相关
因此，数据科学家和开发人员必须仔细考虑每项任务的正确上下文量。 在某种程度上，这是一个不错的问题。早期由 LLM 支持的应用程序通常使用整个上下文窗口，并且难以优化适合其中的上下文。 Gemini 1.5 的百万令牌上下文窗口的适用范围 虽然我不建议任何企业构建使用 Gemini 1.5 pro 的完整上下文窗口的生产 LLM 系统，但 Google 的值得注意的成就在企业 AI 开发中占有一席之地 长上下文模型将加速更简单和预生产的用例。这正是当今的许多企业 AI！Gemini 和其他模型将使数据科学团队比现在更快地完成概念验证应用程序。 定制的 RAG > 生产应用程序中的长上下文 Gemini 1.5 代表了一项重大的技术成就。我赞扬 Google 的研究人员和工程师所做的一切。 Gemini 和其他长上下文模型将在企业 AI 中占据重要地位。允许数据科学团队处理具有挑战性的单次问题并更快地完成应用程序的草稿将产生真正的业务价值。 但是，当涉及到生产用例时，RAG 将胜出。
48810编辑于 2024-05-29 VFP AI 插件：超长上下文的识别(一)
VFP AI 插件在访问大模型时，有一个上下文长度的问题。 对于 DeepSeek 而言，其大小为 128K(=128000 token)。 VFP AI 插件 2025.12.15 版，初步实现超长上下文的处理： 所分析 VCX 类库，使用类浏览器转换出的 prg 格式文件，文件体积为 400+KB，共 10329 行，超过模型最大上下文的最大限制
18510编辑于 2026-03-10VFP AI 插件：超长上下文的识别(二)
距离上一篇VFP AI 插件：超长上下文的识别(一)有些时间了。经过不断的试错和优化，终于完成了 VFP AI 插件的超长上下的识别。将时间从数小时压缩至最多几十分钟。
13510编辑于 2026-03-10- 来自专栏朴素人工智能
Transformer-XL 超长上下文注意力模型
本文就提出了一种网络结构Transformer-XL，它不但可以捕捉文本更长时的依赖，同时可以解决文本被分成定长后产生的上下文碎片问题。 如此一来，两个片段之前的上下文信息可以进行有效的传递。 进一步地，作者提出，在理论上不仅仅可以储存并重用之前一个片段的结果，只要GPU允许，完全可以重用前几个片段的结果，使上下文联系更远。
1.2K20发布于 2020-05-07 - 来自专栏GiantPandaCV
如何用Infini-attention实现超长上下文Transformer
这允许模型在处理后续序列时回顾以前的上下文信息，从而支持无限长的输入处理。 Infini-attention对标准的点积注意力机制进行了微小的改动，支持即插即用的持续预训练和长上下文适应。 这种状态共享和重用不仅提高了插拔式长上下文适应的效率，也加速了训练和推理过程。 这种设计显著提高了模型在长上下文建模任务上的表现，同时实现了超过100倍的压缩比，并在困惑度评分上取得了进一步改进。 该研究的目的是评估不同模型在处理具有长上下文依赖的文本序列时的表现，主要通过平均tokens级困惑度来衡量，该指标反映了模型预测文本序列的能力。困惑度越低，模型的预测能力越强。
1.4K10编辑于 2024-04-26 - 来自专栏IT技术订阅
月之暗面Kimi及超长上下文处理技术
超长上下文处理：Kimi支持高达200万字的最长上下文输入，这是在大模型长上下文处理技术上的一个重要突破，使得它能够更好地理解和处理复杂、连贯的文本信息，比如用于论文总结、电影剧本分析、录音内容整理等。 Kimi实现超长上下文处理的技术原理 Kimi实现超长上下文处理的技术原理涉及到几个关键技术点，这些技术共同作用使其能够处理长达200万字的文本而不损失上下文信息，具体包括： 1. 因此，Kimi采用了分块处理策略，将长文本分成多个小段进行单独处理，然后再利用高级的衔接技术将各段的上下文信息有效融合，确保信息的连续性和完整性。 3. 内存增强技术：为了保留长距离的上下文依赖，Kimi使用了外部记忆模块或者改进的递归机制，这允许模型在处理文本块时能够存取之前处理过的信息，从而维持长文本的连贯性和逻辑性。 5. 上下文保留策略：在处理每个文本块时，Kimi设计了特别的策略来选择性地保留或更新上下文状态，确保即便在分块处理后，整体的语境理解仍然准确无误。
5K10编辑于 2024-05-10 - 来自专栏自然语言处理
大模型(LLM) 的长上下文与 RAG：评估与回顾
大模型的长上下文与 RAG 以下是本文的主要发现： 在问答基准测试中，LC 的表现通常优于 RAG 基于摘要的检索与 LC 性能相当，而基于块的检索则落后 RAG 在基于对话和一般性问题查询方面具有优势
31710编辑于 2025-01-09 用Skip Softmax在TensorRT-LLM中加速长上下文推理
对于大规模部署大语言模型的机器学习工程师而言，随着上下文长度增加，注意力计算成本呈爆炸式增长，这是一个熟悉且严酷的现实。 基于在Hopper和Blackwell架构上的性能数据，Skip Softmax在带宽受限的解码阶段和计算受限的预填充阶段都有益处，尤其是在长上下文场景中。 长上下文场景Skip Softmax的效果随着序列长度的增加而提高。跳过阈值（T）与上下文长度（L）在数学上存在关系：T ≈ K / L。这意味着随着上下文增长，安全识别和跳过稀疏块的机会也随之增加。 在RULER（合成的长上下文）和LongBench（现实的长上下文）基准测试上的广泛测试表明，稀疏性存在一个明确的“安全区”。安全区：观察到50%的稀疏比率（跳过一半的块）是安全区。 Qwen3-30B-Instruct模型在128K超大序列长度下的加速效果场景阈值加速 (BF16)基线准确性稀疏准确性准确性差异仅上下文0.21.30x37.21%36.74%-0.47%上下文加生成
32210编辑于 2025-12-31- 来自专栏机器之心
CMU、谷歌提出Transformer-XL：学习超长上下文关系
本文提出的新神经架构 Transformer-XL 可以在不引起时间混乱的前提下，可以超越固定长度去学习依赖性，同时还能解决上下文碎片化问题。 由于上下文的长度是固定的，因此模型无法捕获任何超过预定义上下文长度的长期依赖性。此外，长度固定的片段都是在不考虑句子或其它语义边界的情况下通过选择连续的符号块来创建的。 因此，模型缺乏必要的上下文信息来很好地预测前几个符号，这就导致模型的优化效率和性能低下。我们将这个问题称为上下文碎片化。 我们的方法不仅可以捕获更长的依赖关系，还可以解决上下文碎片化的问题。 为了解决使用固定长度上下文的局限性，我们在 Transformer 架构中引入了循环机制。
1.1K20发布于 2019-04-30 DeepSeek V4长上下文推理与NVIDIA Blackwell架构
两个模型均支持高达100万令牌的上下文窗口，为长上下文编码、文档分析、检索和代理式AI工作流开启了新的可能性。 MIT | MIT面向长上下文推理的架构创新V4系列构建于DeepSeek MoE架构之上，更加注重优化Transformer架构中的注意力组件。 这之所以重要，是因为长上下文正成为代理式应用的核心要求。代理存储的不只是单个提示和响应。它们在工作流中携带系统指令、工具输出、检索到的上下文、代码、日志、记忆以及多步推理轨迹。 DeepSeek V4也可通过NVIDIA NIM在Day 0下载，以便部署以构建长上下文编码、文档分析和代理工作流，使用熟悉的API模式。 驱动代理工作流DeepSeek V4特别适合代理，因为它在长上下文编排、推理和工具调用方面表现出色。
45510编辑于 2026-05-06Skip Softmax技术在TensorRT-LLM中加速长上下文推理
通过Skip Softmax在NVIDIA TensorRT-LLM中加速长上下文推理对于大规模部署LLM的机器学习工程师而言，随着上下文长度的增加，注意力计算的成本呈爆炸式增长，这是一个常见且严峻的挑战 基于在Hopper和Blackwell架构上的性能数据，Skip Softmax在带宽受限的解码阶段和计算受限的预填充阶段（尤其是在长上下文场景下）都很有益处。 长上下文场景Skip Softmax的效果随着序列长度的增加而提高。跳过的阈值在数学上与上下文长度（$N$）相关，关系式为 $\Delta \approx -\ln N$。 在RULER（合成长上下文）和LongBench（现实长上下文）基准测试上的广泛测试表明，稀疏性存在一个清晰的“安全区”。安全区：稀疏率在50%左右（跳过半数的块）被认为是安全区。 与无稀疏基准相比的准确度变化场景阈值加速 (BF16)基准准确度稀疏准确度准确度变化仅上下文0.21.30x37.21%36.74%-0.47%上下文加生成0.61.38x35.81%34.42%-1.39%
25610编辑于 2026-02-01- 来自专栏深度学习与python
争夺“世界上最长的上下文窗口”背后：长上下文是否意味着 RAG 的终结？
另外，最近国内一众大模型企业都开始宣布降价，那么低成本是否跟选择长上下文和 RAG 是否有关系？ InfoQ：我们是不是必须要 200 万甚至无限长的上下文？ 张颖峰：长上下文很有意义，但无限长的上下文则是更偏向于是营销的宣传策略。上下文长度到达一定程度后，丢失的信息也会更多。 但是长上下文也不是无限长更好，我认为对现阶段的开发者而言这是一个 trade-off 的过程，上下文长度的增加对推理成本和时间都有一个平方几倍的增加。 张颖峰：模型成本方面最近降价很猛，我认为这和长上下文确实是有一些关系的。在目前的架构下， 主要瓶颈都在于对 KV cache 的低利用率。 这些问题部分可以用上下文进行缓解，比如在长上下文的语义空间中包含检索需要的答案，这样大模型也能对问题进行回答。不过这种方案还不能完全解决这种问题，我认为还是需要提高 RAG 自身的能力。
1.1K10编辑于 2024-07-24 - 来自专栏大模型系列
万字长文详解DeepSeek：DeepSeek是什么-超长上下文
2.超长上下文支持支持128Ktokens上下文窗口（部分版本达1M）。采用ALiBi（AttentionwithLinearBiases）或YaRN位置编码，有效缓解长度外推问题。
5.8K60编辑于 2026-04-06 - 来自专栏DeepHub IMBA
长上下文记忆的舒适陷阱：为什么更多记忆不等于更可靠
可靠性问题的起点恰恰是人们把长上下文当免费能力用的那一刻。你扩展了上下文就等于换了一个被测系统，测的不再是模型本身，而是模型加上一个持续膨胀的历史 Token 档案。 很多人喜欢把长上下文比作"更大的大脑"，但实际上它更像一张越来越大的办公桌：纸越堆越多最后你连自己要找的那份文件都找不到。 个性化是一种交换，因为可重复性很重要。 可测试性就这样成了长上下文的隐性牺牲品。 长上下文在检索工作流中也能放大幻觉——哪怕检索到的文档本身是对的。 将长上下文视为生产依赖项 要在生产环境中用长上下文，第一天就得建立明确的上下文预算。预算逼你做决定：什么是持久的，什么可以丢弃，什么该被摘要压缩，什么该以结构化记忆而非原始文本的形式留存。
22810编辑于 2026-02-27 - 来自专栏机器之心
MiniMax震撼开源，突破传统Transformer架构，4560亿参数，支持400万长上下文
其次，对于长上下文训练，一大主要挑战是难以将真实的训练样本标准化到统一长度。传统的方式是进行填充，但这种方法非常浪费计算。 在执行推理时，它的上下文长度最高可达 400 万 token，并且其表现出了非常卓越的长上下文能力。 领先的上下文能力 那 MiniMax-Text-01 引以为傲的长上下文能力呢？其优势就更为明显了。 在长上下文理解任务上，MiniMax 测试了 Ruler 和 LongBench v2 这两个常见基准。 下面重点来看看 MiniMax-Text-01 的长上下文能力。
91900编辑于 2025-02-03 - 来自专栏大模型快速上手实践
大模型开发落地实战-长上下文多模态场景大模型运用实战
至于 长上下文多模态场景 的大模型应用，虽然归为“浅水区”方向，但它的复杂度介于两者之间：比智能客服复杂，但又不如深水区需要极高的策略设计能力。 本文将以Qwen-long 为例，详细展示如何在 长上下文多模态场景 中发挥大模型的潜力。 长上下文与多模态技术的基本原理长上下文（Long Context）技术旨在使模型能够处理和理解超长文本序列。传统的自然语言处理模型通常受限于固定的上下文窗口，无法有效捕捉长距离依赖关系。 长上下文技术通过优化模型架构和训练方法，扩展模型的上下文窗口，使其能够在处理如长篇文章、技术文档或代码库时，保持对全局信息的理解和连贯性。 其主要特点包括：超长上下文支持：Qwen-Long 模型支持最大 10,000,000 个 tokens 的上下文长度，约合 1,500 万字，能够处理超长文档和多文档对话场景，适用于代码审查、论文分析等复杂任务
2.7K42编辑于 2025-01-07
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号