什么是上下文?对于一个非IT出身的学生,初次见到上下文这个词着实让我困惑,特别让我想起了学生时代的阅读理解。理解字里行间的逻辑,提炼中心思想。 ? 其实道理是一样的,现在我们面对的表格就好比阅读理解的语段,只有理解好它们的逻辑,才能写出正确的表达式。表的构成很简单,列和行。所以它的上下文分为两种,筛选上下文(即列的上下文)和行上下文。 ? 筛选上下文最容易理解,是纵向的列筛选条件。比如下面的表中销售量2974的筛选上下文是"2016年-第2季度-拿铁",即对日期列和咖啡种类列的筛选。 ? 行上下文,顾名思义,是要横向的看。 你可能会问,不对啊,记得我们的数据模型关系原材料表与数据表间是以[咖啡种类]建立的一对多关系,为什么没有求得卡布奇诺的数量呢? ? 我们还以第一行举例,Calculate这个超级力量函数就好比模型的启动键,当赋予Calculate时,关系模型的阀门启动,数据信号顺流而下,这个数据信号是将行上下文转换成了筛选上下文,按照当前行中咖啡种类卡布奇诺这个筛选条件对数据表进行筛选
特别是,当相关信息出现在输入上下文的开头或结尾时,性能往往最高,而当模型必须在长上下文中间获取相关信息时,性能会明显下降,即使是明确的长上下文模型也是如此。 这项研究的分析使人们更好地了解语言模型如何使用输入上下文,并为未来的长上下文语言模型提供了新的评估协议。 实验结果显示,模型在处理相关信息位于输入上下文的开头或结尾时表现最好,而当相关信息位于输入上下文的中间时,模型的表现显著下降。 因此,本研究提供了对语言模型如何使用输入上下文的更深入的理解,并为未来的长上下文语言模型提供了新的评估方法。 这篇论文的研究结果和分析提供了一个更好的理解语言模型如何使用其输入上下文,并为未来的长上下文模型提供了新的评估协议。
在生成第 t 步时,模型必须确保下一个词与之前所有内容保持一致:你的提示、已生成的部分、系统指令,乃至任何隐藏上下文。 硬件瓶颈 在解决它之前,我们必须先理解瓶颈所在: 搬运数据代价高昂。GPU 做数学运算极快,但真正的成本往往在于把正确的数据在正确的时间送到正确的位置。 可视化差异 为了真正理解 KV 缓存的神奇之处,让我们跟随动画,看看我们的 LLM 如何生成短语“I Love cats”。我们将重点观察模型如何处理这些 token,以预测序列中的下一个词。 KV 缓存的大小由以下几个因素决定: 对于一个上下文窗口长达 32,000 token 的大模型,这块缓存就能吃掉几十 GB 的宝贵 GPU 显存。 这就是为什么即使上下文变长,生成速度依然很快。
在大语言模型的使用中,“支持32k上下文”的意思是该模型可以处理并记住最多32,000个标记(tokens)的输入。这些标记通常是文本的最小组成部分,可以是一个字符、一个单词,或一个词组的部分。 传统的模型在处理这些代码时,往往因为上下文窗口的限制,难以理解代码之间的依赖关系。 支持32k上下文的模型展示了未来大语言模型的发展方向,也给业界带来了更多思考空间。如何在保证高效推理的同时处理海量上下文信息,仍然是未来模型优化的重要方向。一种可能的技术优化方法是分层记忆机制。 随着GPT模型和其他大语言模型的不断演进,支持更大上下文窗口的能力将继续扩展。 它不仅提高了模型处理长文本和复杂任务的能力,还展示了大语言模型在各个领域中的广泛应用潜力。从法律文本分析、代码生成到复杂对话和长篇写作,32k上下文为这些任务提供了强大的支持。
最近,老婆又又又刷到一条新闻(PS:也不知道为什么总是看新闻):“大模型靠上下文理解能力碾压传统 AI!”她一脸懵地问我:上下文不是写作文要首尾呼应吗?难道 AI 还要学语文课? 而具备上下文能力的大模型,就像贴心的助理,立刻明白“她”指代上文的罗琳。上下文的本质想象一下,上下文能力让 AI 拥有了“时间线管理术”。它不仅能记住你说过的话,还能像侦探一样串联线索。 为什么要上下文?你可能会问:让 AI 一句一句处理不行吗?但传统模型有三大死穴:失忆症晚期:传统模型处理完上句话立刻“格式化记忆”。 上下文的秘诀大模型实现上下文能力的核心,是靠两大法宝:1. 注意力织布机(Attention):自动给关键信息打高光。 上下文的局限但上下文能力并非无懈可击,仍有三大难关:记忆长度有限:就像人类只能记住最近 7 件事,以DeepSeek为例,推理模型和对话模型的最大上下文窗口均为64K tokens(约6万多个汉字),
405B 参数的模型,32 位精度下光权重就要 6.5TB 内存。再算上梯度、状态、激活值,后者还随上下文长度二次方增长。单台 NVIDIA HGX B300 配了 2.3TB HBM3e都不够。 模型并行针对大模型:单卡装不下,就把模型拆开,不同的层放不同的卡上,按顺序跑。405B 这种规模只能这样,并且下游的卡得等上游算完中间是有空转的。 张量并行更极端:连单个矩阵乘法都塞不进一张卡。 模型大、上下文又长到几百万 Token,张量并行也顶不住。因为注意力的二次方内存增长太凶,激活值直接占满显存。128k 上下文的激活值内存是 8k 的 16 倍,这个目前没办法,因为就是这么夸张。 Ring Attention 就是来解决这个问题的,让多节点多卡的大模型训练和推理能在大规模数据中心里跑起来。 上下文并行与 Ring Attention 常见问题 上下文并行把输入序列切到多张 GPU 上,突破训练时的内存限制。跟张量并行、数据并行不同,它在所有模型模块里都切序列维度。
至于 长上下文多模态场景 的大模型应用,虽然归为“浅水区”方向,但它的复杂度介于两者之间:比智能客服复杂,但又不如深水区需要极高的策略设计能力。 本文将以Qwen-long 为例,详细展示如何在 长上下文多模态场景 中发挥大模型的潜力。 需求场景为了深入展示 长上下文多模态大模型 在实际场景中的应用潜力,我们以 招标文档解读 作为示例,探索如何利用大模型高效解析长篇复杂文档并提取核心信息。 长上下文与多模态技术的基本原理长上下文(Long Context)技术旨在使模型能够处理和理解超长文本序列。传统的自然语言处理模型通常受限于固定的上下文窗口,无法有效捕捉长距离依赖关系。 长上下文技术通过优化模型架构和训练方法,扩展模型的上下文窗口,使其能够在处理如长篇文章、技术文档或代码库时,保持对全局信息的理解和连贯性。
如果单独分析每个单词的词性,算法模型是无法判断此单词是名词还是动词。因此,必须要将两个词放入同一个上下文中分析,才可以得到预期的结果。我们通过设置窗口的方式,来获取连续上下文的效果。 因此文本的长度越长,算法模型处理的资源消耗就越多。在大模型中,自注意力机制的引用,就是为了打破窗口长度与文本内容长度的相关性而设计的。 其中,与是两个通过模型训练而学习得的矩阵,可以理解为确定的常量,其代表着注意力关注的重点(也可以理解为知识)。 在attention function的选择上,并没有一个确定的公式。 上述的位置编码函数,只是Transformer模型中使用的。编码函数的选择,也是一个暂无确定解的问题。模型的设计者,可以通过自身对位置的理解,而设计不同的位置编码函数。 05 、总结 自注意力概念首次在《Attention is all you need》(https://arxiv.org/abs/1706.03762)这篇划时代的论文中被提出,标志着对注意力机制理解的一大突破
一、引言 在大模型的世界里,理解其处理长文本的能力,不能只看一个数字。我们常听到“支持128K上下文”这样的宣传,但真正决定模型能否有效利用这些信息的,远不止窗口长度本身。 Context Window(上下文窗口) 模型的一次性阅读能力,在大模型中,上下文窗口指的是模型在一次推理过程中能够接收并处理的输入 token 序列的最大长度。 同理,当用户输入一篇超长文档给大模型,而文档长度超过了它的上下文窗口,多余的部分就会被直接截断或丢弃,模型根本看不见,更谈不上理解。 因此,上下文窗口不是记忆力,而是单次感知能力的上限。 所以,上下文窗口是硬件和架构给的舞台大小,而注意力跨度是模型自己演出的专注范围,简单理解就是模型在能看懂的文字里,真正能关注到的有效范围,不是窗口内所有文字都被平等关注。3. 三、模型如何读懂文字要理解上下文窗口,必须先掌握 Transformer 自注意力机制,这是大模型处理文本的核心引擎。我们用学生造句的例子,一步步拆解。1.
• 三大核心挑战:实验证明,在长上下文中,模型的性能会受到语义模糊性、干扰信息和上下文结构的严重影响,即使是简单的任务也会失败。 他们将这种随着输入 Token 增加,大模型性能逐渐下降甚至崩溃的现象,命名为上下文腐烂(Context Rot)。 那么,上下文究竟是如何「腐烂」的?让我们一起学习一下 Chroma 的研究方法。 「大海捞针」测试的误导性 首先,我们需要理解为什么我们之前会普遍认为长上下文问题已经「解决」了。 Chroma 的研究正是从这里切入,设计了一系列实验,系统性地探究了上下文腐烂的成因。 大模型性能如何随着上下文变长而「腐烂」? 报告明确指出,即使是当今最强大的大模型,在处理简单的长上下文任务时也会遇到困难。信息是否在上下文中存在,并不重要;更重要的是,这些信息是如何呈现的。
背景 在过去几年里,逐渐膨胀的大模型上下文,使得LLM的性能受到巨大的挑战。另外,LLM的上下文窗口有限,也使得其丢失记忆的情况很常见。 丢失细节比较容易理解,而大模型的性能,会因为压缩的上下文所提供的背景信息,以及本身也在逐渐膨胀的消息列表,仍然会比较低。 因此,寻找一种更优的大模型上下文工程方案,是我本篇文章的目标。 保留聊天的细节,让大模型记忆不丢失,甚至得到增强。2. 大模型性能不受损。关注我的公众号 wwwtangshuangnet,一起探讨Agent架构优化。 在当前的所有方案中,它们需要输出非常长的聊天历史,来遵照大模型的API接口设计。但是,目前公开研究发现,丢掉所有聊天历史,在没有历史记忆的情况下,大模型所驱动的Agent会有更准确的效果表现。 但是,这并不绝对,因为通过精准的意图识别,可以减少上下文的长度,剔除无用的信息,这又可以提升大模型首个token响应时间。
然而,对于许多人来说,理解这些大模型的内部机制,尤其是它们的权重(weights),仍然是一个挑战。在这篇文章中,我们将深入探讨大模型的权重及其重要性。 什么是大模型权重? 大模型权重是指模型中每个神经元连接的参数。这些权重在训练过程中不断调整,以使模型能够更准确地预测输出。简单来说,权重决定了输入数据如何通过模型被处理和转换。 例如,在图像识别任务中,模型通过调整权重来识别图像中的边缘、形状和颜色;在自然语言处理任务中,模型通过权重来理解单词之间的关系和上下文。 权重的初始化 在训练模型之前,权重需要被初始化。 结论 大模型权重是机器学习模型中至关重要的组成部分。通过理解和调整这些权重,我们能够构建出功能强大、性能优异的模型。尽管权重的概念可能看似复杂,但它们实际上是模型学习和推理能力的核心。 随着技术的不断进步,对大模型权重的理解和应用将继续推动人工智能领域的发展。
本文将介绍构建推理模型(Reasoning LLMs)的四种主要方法,即如何为大语言模型(LLMs)增强推理能力。希望这些内容能为你在快速发展的AI之路上提供一些有价值的参考。 希望本文能在 2025 年 AI 持续高速发展之际,为你理解和实践推理模型提供帮助! 我们如何定义“推理模型”? 什么时候需要使用推理模型? 在前文我们已经定义了“推理模型”。接下来,在进入如何构建和改进推理型 LLM 的技术细节之前,先思考一个关键问题:我们究竟何时需要使用推理模型? (图示:DeepSeek-R1-Distill 模型开发流程) 为什么要开发蒸馏模型? 2.纯强化学习(Pure RL) 对研究很有价值,可帮助理解推理能力作为一种涌现行为。但在实务开发中,RL + SFT通常更优,能训练出更强的推理模型。
这被称为“上下文长度”——提供给网络以进行未来预测的上下文。现代网络可以拥有非常大的上下文长度(几千个词),这很有帮助。 确实存在一些输入无限长序列的方法,但这些方法的性能虽然令人印象深刻,后来还是被拥有大(但固定)上下文长度的其他模型超越了。 细心的读者还会注意到,我们对同一字母的输入和输出采用了不同的解释方式! 事实上,我们在这个模型里把数字当作输入的方式并不是最优的,稍后我们会探讨更好的做法。 是什么让大语言模型如此高效? 好消息是,我们简单的前馈模型会与上下文中的所有词连接,因此它可以学习重要词的适当权重。但问题在于,通过前馈层连接模型中特定位置的权重是固定的(对每个位置都一样)。 大多数 GPT 模型都使用这一架构(在不同模型间存在变化)。如果你一直跟着文章看到这里,这应该很容易理解。用框图表示,高层架构看起来如下: GPT 架构。
通过官网提供的一张图可以清晰理解MCP。 MCP 主机(MCP Hosts):希望通过 MCP 访问资源的程序(例如 Claude Desktop、IDE 或 AI 工具),用于发起连接。 MCP 服务器(MCP Servers):轻量级程序,每个程序都通过标准化模型上下文协议公开特定功能。为客户端提供上下文、工具和 prompt 信息。 模型上下文协议的JavaSDK支持AI模型和工具之间的标准化集成,那么如何集成呢? JavaSDK整体架构 在JavaSDK中,遵循分层架构,明确分离关注点。 MCP客户端 MCP客户端是模型上下文协议(MCP)架构中的关键组件,负责建立和管理与MCP服务器的连接。它实现了协议的客户端。 MCP服务端 MCP服务器是模型上下文协议(MCP)架构中的基础组件,它为客户端提供工具、资源和功能。它实现了协议的服务器端。 引入依赖包 如果你使用了一个Maven项目,那么可以引入下面的包 <!
for Large-scale Learning)是一个高效且用户友好的强化学习库,专为不同类型用户设计,它不仅能够在各种硬件资源条件下高效完成多样化的训练目标,还特别针对需要大规模 GPU 资源的大语言模型 ROLL在诸如人类偏好对齐、复杂推理和多轮自主交互场景等关键领域显著提升了大语言模型的性能。 (4)质陪解决方案由中关村科金得助智能开发,创造性地融合成熟的AI大模型质检与陪练系统,推出了全面高效的“质陪解决方案”。智能质检采用大小模型结合的方式,对销售人员的销售行为进行全方位监测和分析。 (5)上下文工程上下文工程指通过为任务提供完整的背景信息,让大模型能够合理解决问题。在AI智能体的兴起发展过程中,上下文工程才是决定大多数AI智能体成败的关键而并非模型。 上下文工程致力于设计和构建动态系统而并非字符串,这些系统在恰当的时机提供信息和工具,从而让LLM拥有完成任务所需的一切。
如何让自己使用的大模型能够像 Manus 一样,胜任各种复杂任务,应该采取哪些措施? 这就需要一种方法把各种工具和助手整合到一起。 MCP就是这样一种方案,它让AI能够更好地理解上下文,记住之前的对话,并且在需要的时候调用不同的工具。 设想一下,倘若你的手机、电脑与耳机仅需一根USB-C线便能实现无缝对接,生活将变得何等便捷? 01—什么是模型上下文协议 MCP(模型上下文协议)是一种大模型时代出现的开放协议,旨在标准化应用程序向大型语言模型 (LLMs) 提供上下文(数据)的方式。 通过分离模型、上下文和协议,开发人员可以: 在不破坏整个系统的情况下更换不同的 AI 模型。 动态地引入新的上下文(例如,使 NLP 模型适应新的语言或行业)。 为 AI 模型编排定义强大的协议。 和以前需要手动设置的API不同,MCP更像是一个智能框架,让AI能更好地理解上下文,并且有更强的互动能力。
大模型的长上下文与 RAG 以下是本文的主要发现: 在问答基准测试中,LC 的表现通常优于 RAG 基于摘要的检索与 LC 性能相当,而基于块的检索则落后 RAG 在基于对话和一般性问题查询方面具有优势
什么是上下文工程? “上下文工程”是指为大语言模型设计和构建一整套动态的信息生态,让模型在推理时能够获取充分且相关的上下文,以更可靠地完成任务。 再次,多模态上下文(Multimodal Context) 处理也是一大挑战。当任务涉及图像、音频、视频等非文本信息时,需要将这些不同模态的数据编码成模型可理解的形式,并与文本上下文融合。 上下文工程关注如何统一处理多模态信息并让模型结合它们进行推理 。当前,多模态大模型(如 GPT-4V 等)的出现正是朝着让模型直接处理多模态上下文迈进了一步 。 其次,模型理解与生成能力的非对称性凸显了关键难题:目前LLM在理解复杂上下文方面表现卓越,但在生成同样复杂、长篇且连贯的输出上力不从心 。 总之,只有正视并解决好以上部署与社会影响层面的挑战,才能确保大模型上下文工程技术以安全、可靠、负责任的方式服务于社会。 总结 总的来说:上下文工程就是帮大模型“吃好、消化好”信息的艺术与科学。
大型语言模型(LLMs)在上下文知识理解方面取得了令人瞩目的成功。 本研究通过一系列精心设计的实验,揭示了自注意力模块中极大值的存在与上下文知识理解之间的关键联系。 四大核心发现 1. 设计新的量化方法时应重点考虑保护 Q 和 K 中的大值,对于优先保持上下文理解能力的应用场景,AWQ 和 SmoothQuant 等方法更为合适。 4. 非大值破坏的对照实验 为验证研究发现的可靠性,研究团队还设计了对照实验:当仅破坏非极大值部分时,所有任务的表现保持稳定,变化通常小于 ±1%。这进一步确认了极大值在上下文知识理解中的特殊重要性。 这项研究不仅加深了我们对大型语言模型内部工作机制的理解,也为未来更高效、更强大的模型开发铺平了道路。通过揭示极大值的关键作用,研究者们为我们提供了解锁大语言模型上下文理解能力的一把新钥匙。