当数据不再是孤岛，当查询不再是等待，当分析变成实时，企业的数字化转型才真正开始。

Claude Skills确实代表了AI工具发展的重要方向，它将AI从简单的问答工具推进为个性化的工作伙伴。 但技术的价值不在于其概念的新颖，而在于能否真正解决实际问题，提升工作效率。

不需要成为技术专家，但要理解这些概念，才能在AI浪潮中不掉队。

探讨数据治理与数据安全治理的区别，聚焦于关注点、输出、参考标准、结果和视角。在数字中国战略下，理解二者差异对企业数据安全与治理至关重要。数据治理关注数据组织、使用与质量，而数据安全治理强调全生命周期安全保护，确保数据可用性、完整性与机密性。

当AI真正理解了企业的业务语言、决策逻辑、价值体系，它就不再是一个冰冷的工具，而是成为了企业智能的"数字大脑"。 对于正在探索AI应用的企业而言，Palantir的经验给出了明确启示：技术栈的先进性不如业务理解的深度，算力资源的投入不如专家知识的积累，模型的参数规模不如知识体系的完整。

大型语言模型展现出的智能程度是以往软件所无法比拟的。你可以让它解释复杂的主题、改写电子邮件或帮助你理清思路，而它的回答往往听起来冷静、自信且深思熟虑。这自然而然地引出了人们不断追问的问题：人工智能真的在思考吗？ 诚实的答案很微妙。这些系统的思维方式与人类不同，但它们所做的事情也远不止于简单地重复记忆的文本。要理解人工智能为何如此人性化，就需要了解这些模型真正接受过哪些训练，以及它们没有接受过哪些训练。 现代人工智能模型的基本原理是训练预测下一个词。在训练过程中，模型会接触大量文本，并反复学习如何回答一个简单的问题：根据目前为止的所有信息，下一个最有可能出现的词是什么？随着时间的推移，这个简单的目标会迫使模型内化语言模式、事实、推理方式，甚至人类解释事物的方式。 这就是为什么“这只是自动补全”的解释既正确又具有误导性。正确之处在于，预测确实是其核心机制。误导之处在于，当预测规模扩展到数万亿个单词和数十亿个参数时，系统会开始构建一些内部结构，这些结构看起来很像概念。并非人类意义上的概念，而是稳定的模式，当模型处理诸如数字、城市、情感或因果关系之类的概念时，这些模式会持续激活。 如果你让模型解决一个多步骤问题，它通常会生成一些类似于推理过程的中间步骤。它可能会定义术语、探索其他方案，或者排除之前的可能性。这一切的发生并非因为模型本身的目标就是给出正确的答案。而是因为在它所训练的数据中，正确的答案往往伴随着连贯的解释链。生成这些解释链会增加后续步骤产生合理结果的概率。 换句话说，推理行为的出现是因为它对预测有用，而不是因为模型知道自己在推理。 这种区别至关重要。人类通过推理得出结论。语言模型之所以生成符合推理逻辑的文本，是因为统计上这种文本能带来更好的自动补全效果。因果关系的方向颠倒了。 如果这听起来有些含糊不清，那么最近的可解释性研究已经开始让这些内部模式显现出来。在Anthropic及其合作者的研究中，研究人员开发了一些工具，可以追踪信息在模型内部的流动方式，类似于生物学家使用显微镜观察活体生物体内的细胞。 我们基于近期研究成果，引入了一套用于识别特征并绘制特征间连接图的新工具——类似于神经科学家绘制大脑的“线路图”。我们大量运用了一种名为归因图的工具，它使我们能够部分追踪模型将特定输入提示转化为输出响应所使用的中间步骤链。 如果将模型的内部活动想象成一种隐藏的计算网络，那么这些归因图就如同图表，展示了模型决定写作内容的主要路径。研究人员甚至用类似于简化电路图的图表来可视化这些路径，其中每个节点代表一个学习到的概念，而边则显示了不同概念如何影响输出。 论文中重点介绍的一个例子涉及基本的地理推理。当给出“事实：达拉斯所在的州的首府是……”这样的提示时，模型会补全为“奥斯汀”。研究人员利用他们的工具表明，在幕后，该模型实际上使用了中间概念步骤来得出这个答案。它首先将“达拉斯”表示为位于“德克萨斯州”，然后以此为基础确定“奥斯汀”是首府，所有这些步骤都发生在最终文本出现之前。 Haiku 用一个“多步骤”图表来完成句子，顺序为达拉斯 → 德克萨斯州 → 奥斯汀。 该模型内部执行真正的两步推理，与快捷推理并存……决定说奥斯汀取决于一系列中间计算步骤。 在研究的另一部分，研究人员发现模型在创作诗歌时表现出惊人的特性。在生成诗歌的每一行之前，模型内部的电路通常会激活潜在的押韵词，并利用这些潜在的押韵目标来构建诗行。本质上，尽管模型的目标函数仅用于预测下一个词，但它却能提前规划下一个词之后的内容。 在开始编写每一行之前，该模型会识别出可能出现在句末的押韵词。这些预先选定的押韵选项随后会影响模型构建整行的方式。 另一项令研究人员感到惊讶的发现是，某些内部模式在不同语言中是共通的。当相同的提示被翻译成不同的语言时，模型内部计算中会激活类似的回路路径。这暗示了该模型使用了一种抽象表征，这种表征并非严格局限于单一的人类语言，而是映射到跨语言共享的概念结构。 我们发现该模型使用了特定于语言的电路和抽象的、与语言无关的电路的混合……与较小、功能较弱的模型相比，Claude 3.5 Haiku 中与语言无关的电路更为突出。 这一切都很重要，因为它有助于解释为什么人工智能的回答在多句话中往往显得连贯一致。当你提出问题时，模型并非盲目猜测下一个词。它通常会运用内部对答案类型的理解，然后将其翻译成类似人类语言的表达方式。 但这并不意味着模型理解了它所表达的意思。一个便于理解的方法是想象一个人读过几乎所有书籍，但却没有任何直接的现实世界经验。这个人或许能够解释悲伤是如何产生的，法律体系是如何运作的，或者一家初创公司应该如何运营，而这一切仅仅是通过对所读内容进行模式匹配来实现的。这种解释或许非常精辟，但仍然是二手信息。 这有助于解释一个常见的误解。人们常常认为，如果一个模型能够始终如一地谈论某个概念，那么它一定像人类一样“拥有”这个概念。实际上，模型学习了一套内部表征，这些表征有助于在合适的语境中使用正确的词语。这些表征可能非常稳定，但它们并非基于经验、意图或理解。 这也是为什么模型有时会显得自信满满，但实际上却可能出错的原因。自信只是文本中的一种模式。模型已经学习到，权威的解释往往遵循某些特定的语言形式。如果这些形式在统计学上是合理的，模型就会使用它们，而不管其背后的内容是否正确。 从这个角度来看，现代人工智能系统的行为就更容易理解了。它们之所以强大，是因为它们能将海量的人类知识压缩成一种可以按需重组的形式。它们的局限性在于，它们缺乏人类用来发现错误、寻求澄清或根据现实世界反馈更新信念的机制。 我认为这种框架比任何极端观点都更有用。这些系统并非意识系统，也与意识相去甚远。但它们也绝非肤浅的技巧。一个单一的训练目标就能产生支持翻译、解释、类似计划的行为和抽象思维的内部结构，这的确令人惊叹。 理解其运作原理并非仅仅是学术探讨，它会影响我们如何负责任地部署这些系统。一旦你不再假设模型“知道”何时正确，你就会开始设计能够验证、约束和巩固其输出的系统。你不再依赖流畅性来判断正确性，而是将其视为一种表面信号。 人工智能本身并不思考。但它所产生的行为与从外部视角观察到的思考方式存在重叠。这种重叠既强大到足以发挥作用，也危险到需要我们谨慎对待。我认为，对于任何想要认真研究这些系统的人来说，同时认识到这两点才是正确的出发点。 来源（公众号）：数据驱动智能

AI时代，数据血缘的价值会更加凸显。 数据血缘正在从“数据治理的辅助工具”升级为“AI时代的核心基础设施”

❝ 上周五下午五点半，老张刚准备下班，产品经理突然冲到工位前："张工张工！老板要看全国各区域的销售数据汇总，现在就要！" 老张抬头看了看窗外，心里一万头草泥马呼啸而过...华东的数据在杭州集群，华北的在北京集群，华南的在深圳集群，这要跨三个Doris集群做联合查询！ 按照以前的套路，要么写JDBC Catalog慢慢等，要么就得临时把数据同步到一个集群——前者慢得让人怀疑人生，后者等数据同步完周末都过去了。 老张急忙翻阅了下 Doris 4.0.2版本的 release note，突然不紧不慢地说道："给我半小时..." Doris跨集群查询的老大难，终于有解了 说起跨集群数据分析，做过大数据的人都知道这有多头疼。 你们公司是不是也这样：业务发展快了，一个Doris集群不够用，就搞了好几个。交易数据在A集群，物流数据在B集群，用户画像在C集群。 平时各自安好，但老板一句"我要看全局数据"，技术团队就开始抓狂。 传统的JDBC Catalog确实能用，但用过的人都懂那个痛。 协议开销大得吓人，查询优化策略用不上，简单查询还行，遇到复杂的Join和聚合，性能能把人逼疯。 有个朋友跟我吐槽过，他们用JDBC Catalog跨集群查个订单履约率，单表聚合查询愣是跑了45秒，老板在会议室等得直拍桌子。 更要命的是，数据量一大，JDBC那套基于MySQL协议的玩法就彻底歇菜。 你看着查询进度条一点点爬，心里默念"快点快点"，但它就是快不了。这不是咱技术同学偷懒，而是协议层面的先天不足！ but，Doris团队这次是真狠，连自己都不放过。 他们大概也意识到，光支持Iceberg、Paimon、Hudi、JDBC...这些外部数据湖还不够，Doris自己跨集群访问性能不行，这个湖仓一体的故事就讲不圆。 于是乎，Doris Catalog应运而生，专门用来解决Doris集群之间的高效联邦查询。 测试数据更是让人眼前一亮。 在TPC-DS基准测试中，单表聚合查询场景下，Doris Catalog虚拟集群模式的查询耗时只有0.21秒，而JDBC Catalog需要40+秒——性能提升超过200倍。 这已然不是小打小闹的优化了，可谓是质的飞跃。多表关联查询也有42%的性能提升。虽然没有单表聚合那么夸张，但对于复杂业务分析来说，这个提升已经足够显著。 两种模式各显神通，按需选择 Doris Catalog提供了两种访问模式：Arrow Flight模式和虚拟集群模式。 这个设计思路挺有意思，不是一刀切的方案，而是让你根据实际场景灵活选择。 Arrow Flight模式的设计很聪明。 它让本地集群的FE节点生成查询计划，针对远端表生成单表查询SQL，然后通过Arrow Flight协议直接从远端BE节点拉取数据。 整个过程就像是在本地集群做了个"远程调用"，简单直接。 这种模式特别适合那种查询逻辑简单、但远端集群规模大的场景。 比如你只是想从另一个集群拉取某张表的数据做个UNION操作，用Arrow Flight模式最合适不过。 协议开销小，传输效率高，不需要复杂的查询优化。 虚拟集群模式就更有意思了。 它把远端集群的BE节点当成虚拟BE，直接同步完整的元数据信息，然后生成全局统一的执行计划。 在Doris看来，两个集群的BE节点就是一个大集群，查询计划可以无缝分发执行。 这种设计带来的好处是显而易见的：所有Doris内表的优化策略都能用上，Runtime Filter、分区裁剪、列裁剪这些优化手段全部生效。 对于那种需要复杂Join和聚合的分析场景，虚拟集群模式是不二之选。 回到文章开头老张的故事，他用的就是虚拟集群模式。 配置Doris Catalog只需要一条SQL，指定远端FE的HTTP地址、Thrift地址、用户名密码，设置use_arrow_flight为false，就搞定了。 然后在查询时，用全限定名直接关联本地表和远端表，一条SQL解决战斗： -- 创建Doris Catalog，启用虚拟集群模式（复用内表优化） CREATECATALOGIFNOTEXISTS remote_ctl PROPERTIES (     'type' = 'doris', -- 固定类型     'fe_http_hosts' = 'http://logistics-fe1:8030,http://logistics-fe2:8030', -- 远端FE HTTP地址     'fe_arrow_hosts' = 'logistics-fe1:8040,http://logistics-fe2:8040', -- 远端FE Arrow Flight地址     'fe_thrift_hosts' = 'logistics-fe1:9020,http://logistics-fe2:9020', -- 远端FE Thrift地址     'use_arrow_flight' = 'false', -- false=虚拟集群模式，true=Arrow Flight模式     'user' = 'doris_admin', -- 远端集群登录用户     'password' = 'Doris@123456', -- 远端集群登录密码     'compatible' = 'false', -- 集群版本接近（4.0.3 vs 4.0.2），无需兼容     'query_timeout_sec' = '30'-- 延长查询超时时间（默认15秒） ); -- 查询 SELECT     local.region，     SUM(remote.sales_amount) as total_sales FROM internal.sales_db.orders local JOIN remote_ctl.logistics_db.delivery remote ON local.order_id = remote.order_id WHERE local.create_date >= '2025-01-01' GROUPBY local.region; 这种写法和在单集群查询没什么区别，唯一的差别是多了个Catalog前缀。 但对于查询引擎来说，这背后的优化逻辑完全不同——它会智能地把计算下推到远端集群，减少数据传输量，最大化利用两边的计算资源。 有个做电商的小伙伴用Doris Catalog解决了订单履约率分析的问题。他们的订单数据在交易集群，履约数据在物流集群，以前用JDBC Catalog跑一次查询要好几分钟。换成Doris Catalog虚拟集群模式后，查询时间直接降到秒级，业务人员终于不用盯着进度条发呆了。 面对两种模式，很多人会纠结该用哪个： 其实选择逻辑很简单。 如果你的查询主要是简单的单表过滤、投影操作，或者需要跨集群做UNION，那Arrow Flight模式就够用了。它轻量、高效，不需要同步完整元数据，对FE内存压力小。 但如果你的分析涉及复杂的Join、聚合操作，或者需要依赖Doris的各种查询优化特性，那毫不犹豫选虚拟集群模式。虽然它会同步元数据，对FE内存有一定要求，但换来的性能提升是实打实的。 还有一个考虑因素是集群版本。如果你的多个Doris集群版本不一致，用Arrow Flight模式更稳妥，兼容性更好。 结语 Doris Catalog目前还是实验性特性，官方明确表示会持续优化。 说到底，Doris Catalog的出现，让湖仓一体这个概念更加完整了。 以前Doris可以无缝对接各种外部数据湖，现在连自己的多个集群也能高效互联，真正做到了无界。 数据在哪里不重要，重要的是你能不能高效地查询和分析它。 这种对内对外都不妥协的态度，才是一个成熟数据库应有的样子吧。 来源（公众号）：一臻数据

研究意义 阅读ChatGPT生成的摘要时，你或许会注意到一个奇特现象：模型尤其偏爱“delve”（探究）、“intricate”（复杂）、“nuanced”（微妙）这类光鲜的学术形容词。越来越多文献将这种词汇过度使用视为大语言模型（LLMs）与人类写作者差异的体现。但究竟是什么驱动了这些词汇选择？ Juzek与Ward的研究试图解答这一问题。他们的研究探讨了人类反馈学习（LHF）环节——即人类对模型输出进行排序或比较的过程——是否会系统性推动LLMs偏向使用一小部分受青睐的术语。若确实如此，这种过度使用就并非神秘的程序错误，而是为了让模型更符合人类偏好而设计的流程所产生的副作用。 通俗解读核心发现 研究者对比了LHF训练前与LHF训练后的模型，识别出指令微调后使用频率显著上升的词汇，随后通过人类实验让参与者在两版仅含目标词汇差异的文本中做出选择。结果发现：经LHF训练的模型（Meta的Llama 3.2 Instruct）确实比基础模型更频繁使用某些词汇，而人类偏好那些包含更多此类词汇的版本（≈52% vs. 48%）。简言之：LHF似乎是词汇过度使用的主要推手，而它偏好的词汇恰恰也是反馈环节中人类更青睐的。 方法论逐步解析 3.1 模型选择 基础模型：Llama 3.2‑3B Base——未经人类反馈微调的标准语言模型。 指令微调模型：Llama 3.2‑3B Instruct——相同架构，但经过直接偏好优化（DPO）（一种通过最大化人类偏好分数实现LHF的技术）。 这对模型是唯一公开的、仅因LHF步骤产生差异的配对，适合进行纯净对比。 3.2 构建“词汇指纹” 数据源：从PubMed（2020年）选取10,000篇科学摘要（确保其成文于LLMs普及前，代表人类基准）。 过滤：剔除少于40词的摘要，保留9,853篇。 生成续写：将每篇摘要分为两半，以前半段为提示输入模型： 续写以下学术文章：'{前半段}'   模型生成续写内容（长度不超过输入的两倍）。 清洗：使用GPT‑4o自动去除生成循环、元评论及非摘要内容的杂项文本。 生成语料库： 基础模型续写：约230万词 指令模型续写：约220万词 3.3 标注与计数 词性标注：通过 spaCy (v3.8.3) 标记每个词汇（如名词、动词），区分同形异义词（如“run”作动词或名词）。 词元归并：将词汇还原为词典形式（如“delve”“delves”“delving”→“delve”）。 频率计算：对每个词元-词性组合计算每百万词出现次数（opm）。 3.4 统计检测过度使用词汇 卡方检验比较两语料库的词汇计数。 显著性上升（p < 0.01）的词汇被标记为潜在LHF诱导项。 3.5 从检测到实验验证 目标：证明人类在文本排序时偏好的词汇与LHF过程一致。 生成变体：将50篇随机PubMed摘要转化为关键词列表，输入Llama Instruct生成每篇500个变体（共25,000个）。清洗后保留8,710个有效变体。 评分：为每个目标词汇分配LHF分数（基于其在指令模型中的相对增幅），变体总分为所含词汇分数之和。 筛选对比组：对每篇摘要，选取LHF分数最低与最高的变体，最终保留差异最大的30组作为实验刺激集。 人类受试者：通过Prolific招募400名参与者（主要来自全球南方），每人评估25组（20组关键对比，5组控制组）。剔除低质量数据后保留4,039条有效评分（≈每组135次评分）。 统计分析：主检验为卡方检验（对比高/低LHF分数选择比例与50/50基准），辅以混合效应逻辑回归验证稳健性。 结果解读 实验揭示三大发现： 总体偏好：52.4%的案例中参与者选择高LHF分数变体，虽微弱但显著高于随机水平。 混合效应模型：逻辑回归（含受试者与项目的随机截距）确认固定效应显著，表明偏好模式跨文本与人群均成立。 词汇特异性：当高分数变体含“nuanced”时，偏好率反降至46.6%，暗示某些过度使用词汇若过于显眼可能适得其反。 核心结论：LHF评估者确实偏爱那些被后LHF模型过度生成的词汇，由此形成因果链：人类评估者→LHF微调→模型偏差。 影响与更广语境 对齐与错位：LHF旨在使模型对齐人类偏好，但实际对齐的是LHF劳动力（多为全球南方年轻群体）的偏好，可能与终端用户（学者、记者）反对的“delve效应”冲突。 语言演变：某些术语的过度使用早于LLMs，LHF可能加速代际语言变迁，使模型模仿反馈提供者的语言习惯。 数据透明度：不透明的LHF流程（未公开数据集、隐藏工作者人口统计）阻碍诊断与修正偏差。公开LHF数据可实现针对性去偏。 缓解措施：研究者的检测流程（第2部分）为开发者提供低成本自动化工具，可在模型发布前识别极端词汇过度使用。结合劳动力多样化或偏好数据再平衡，或减少“AI词汇”泛滥。 AI文本检测：过度使用词汇是LLM输出的标志，此方法可改进AI文本检测工具（如基于相对熵或概率曲率的工具）。 核心启示 人类反馈学习是一把双刃剑。它推动LLMs使用评估者（多为全球南方年轻工作者）偏好的语言，却导致模型过度使用少量华丽的学术词汇——许多读者视此现象为与更广泛用户期待的错位。 Juzek与Ward的研究首次实证连接LHF与词汇偏差，既提供诊断工具，也呼吁反馈环节的更高透明度。若要LLMs服务真正多元的受众，我们必须超越当前LHF劳动力，多样化其生成的数据，并警惕模型重复的词汇。 来源（公众号）：AI Signal 前瞻

在人工智能日新月异的发展浪潮中，构建更强大的语言模型往往伴随着高昂代价——计算与内存需求呈指数级增长。 谷歌DeepMind、KAIST AI和Mila的研究人员在其2025年发表的论文《Mixture-of-Recursions: Learning Dynamic Recursive Depths for Adaptive Token-Level Computation》中提出的混合递归框架（MoR），正是这一困局的破局者。 这一开创性架构能够在保持大规模语言模型性能的同时，大幅降低资源消耗，或将重新定义高效AI的未来图景。让我们深入解析MoR的革命性突破，探寻其被誉为"游戏规则改变者"的深层原因。 核心挑战：如何实现高效扩展 像GPT-3和PaLM这样的大型语言模型（LLMs）已展现出惊人能力——从诗歌创作到复杂问题求解无所不能。然而，它们的算力需求同样惊人。训练和部署这些模型需要消耗海量资源，导致其几乎成为资金雄厚的科技巨头专属品。 以往提升效率的努力通常聚焦于两种策略：参数共享（通过复用模型权重缩减规模）或自适应计算（根据输入动态分配算力资源）。但问题在于——这两种方法长期未能有效结合，直到 MoR 的出现。 MoR 通过将参数共享与自适应计算统一纳入递归 Transformer 框架，直击这一难题。最终实现的模型既能达到大模型的性能水准，又只需小模型的资源开销，为AI效率树立了全新的帕累托前沿。 什么是混合递归架构（MoR） MoR（混合递归）架构的核心是通过两种关键方式提升基于Transformer的语言模型效率： 递归式参数共享机制：不同于传统模型为每层计算分配独立参数，MoR采用共享的Transformer层堆叠结构进行多步递归计算。这种设计大幅减少唯一参数数量，使模型在训练和部署时更紧凑高效。 自适应token计算策略：模型通过轻量级路由网络动态分配不同递归深度——对复杂token进行深层计算，而简单token则提前退出。这种细粒度资源分配有效避免了冗余运算。 该架构还创新性地采用了动态KV缓存技术：仅选择性存储当前递归步骤活跃令牌的键值对，显著降低内存占用并提升推理速度。其变体递归KV共享更进一步复用首步递归的键值对，在几乎不影响性能的前提下，大幅减少预填充延迟和内存消耗。 MoR 如何运作 想象一个编辑团队正在润色一份复杂文档。在传统 Transformer 架构中，每个编辑（层）都是独立的，需要消耗大量资源。而 MoR 则如同一位技艺高超的编辑，通过多次迭代审阅来优化文档。以下是MoR的核心组件解析： 递归式Transformer架构 MoR将模型划分为递归块，通过重复应用同一组共享层实现优化。其参数共享策略包含三种模式： 循环模式：层参数按周期循环复用 序列模式：连续重复使用相同层 中间变体：保留首尾层的独立参数，共享中间层参数 这种设计减少了独特参数数量，既提升了训练效率，又通过"连续深度批处理"等技术消除了计算"气泡"。 动态递归路由 全新训练的路由模块会根据token的复杂度分配递归深度：复杂token获得更多计算资源，简单token则提前退出。与事后路由方案不同，MoR的路由机制在预训练阶段就深度集成，确保训练与推理行为的一致性，实现最优性能。 高效KV缓存 MoR采用"递归感知KV缓存"技术，仅存储当前递归步活跃token的键值对，大幅减少内存访问。其"递归KV共享"变体通过复用首轮递归的键值对，可降低50%内存占用，某些场景下推理速度提升达2倍。 MoR为何重要：结果说明一切 MoR框架在1.35亿至17亿参数的模型规模范围内进行了严格测试，结果令人瞩目： 性能优势：在同等训练计算量（FLOPs）条件下，相较于传统Transformer和现有递归基线模型，MoR以更小的模型规模显著降低了验证困惑度，并提升了少样本学习准确率。 吞吐量提升：通过聚焦活跃令牌的计算优化及KV缓存机制，MoR实现了更高的推理吞吐量，使部署速度更快、成本效益更优。 内存高效：该框架将KV缓存内存占用减少约50%，直击大语言模型部署中最关键的瓶颈之一。 扩展性强：MoR的设计兼容现有硬件和架构，成为现实场景应用的实用解决方案。 这些突破性进展确立了MoR作为效率新标杆的地位，以"大模型性能、小模型成本"实现了优质低耗的完美平衡。 迈向更智能、更廉价AI的关键一步 MoR 的意义不仅限于技术效率的提升。通过降低部署大语言模型的计算与资金门槛，这项技术使小型机构和研究者也能用上尖端AI模型，推动了先进人工智能的民主化进程。其自适应计算机制更模拟了某种"计算智能"——像人类分配脑力处理复杂任务那样，动态调配计算资源到最需要的地方。 X平台上的技术爱好者甚至将MoR称为"Transformer杀手"，暗示它可能引发传统Transformer架构的范式转移。虽然这种说法略显夸张，但MoR通过参数共享与自适应计算的创新结合，确实为高效AI设计树立了新标杆。 挑战与未来方向 尽管混合递归（MoR）是一项重大突破，但它仍面临挑战。动态路由机制需要精细训练以避免性能下降，而递归KV共享的权衡方案仍需在不同任务中进一步探索。此外，与所有注重效率的方法一样，需要确保该技术在现实应用中始终保持稳健性能。 未来研究可在MoR基础上整合其他技术，如专家混合（MoE）或DeepMind自研的混合深度（MoD）。该框架的灵活性还为动态样本调度和连续深度批处理等创新开辟了道路，有望进一步提升吞吐量（某些情况下可实现高达2.76倍的加速）。 结论：面向未来的蓝图 混合递归不仅是一项技术创新，更是构建更智能、更经济、更高效AI的蓝图。通过统一参数共享与自适应计算，MoR实现了曾被视作不可能的目标：既能达到大规模模型的性能，又能保持小规模模型的效率。当AI界苦于扩展成本不可持续之际，MoR为平衡性能与实用性提供了可行路径。 随着DeepMind与合作者不断突破AI效率的边界，MoR以其创造性的架构设计证明了创新的力量。无论它是"Transformer杀手"还是变革性的一步，有一点毋庸置疑：混合递归正在为更普惠、更可持续的AI未来铺平道路。 “ 更多细节请参阅arXiv上的原始论文：《Mixture-of-Recursions: Learning Dynamic Recursive Depths for Adaptive Token-Level Computation》 来源（公众号）：AI Signal 前瞻