在人工智能日新月异的发展浪潮中，构建更强大的语言模型往往伴随着高昂代价——计算与内存需求呈指数级增长。 谷歌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 前瞻

研究意义 阅读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 前瞻

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

引言 数据驱动决策一直在各行各业中至关重要，业务分析师常常面临繁重的数据查询任务。通过自然语言生成结构化查询语言（SQL）的技术，即NL2SQL，业务分析师不再需要掌握复杂的编程技能，便能够轻松访问和处理数据。这篇文章将探讨如何利用NL2SQL技术来自动化处理常见的数据查询任务。 想象一个典型的场景：一位业务分析师需要提供上个月销售额最高的前10个商品。如果用传统方法，首先分析师需要知道销售额相关的基础数据表是哪些，接着得确认销售额的具体口径定义，最后需要按照一定方式编写复杂的SQL查询得到结果。这不仅需要对SQL语言有深刻的理解，还要对指标的定义、业务数据来源非常熟悉。 如果将NL2SQL技术和日常数据分析结合。可以帮助业务分析师显著减少完成数据分析所需的时间，同时还可以借助NL2SQL纠正发现语法问题减少人为错误，甚至即使没有技术背景的用户也能通过自然语言简单地进行复杂的数据查询，提高运营自助分析查询的效率。 技术背景与发展历程 ▐ 2.1 问题定义 什么是NL2SQL NL2SQL是"Natural Language to SQL"的缩写，指的是将自然语言查询转化为SQL查询语句的技术。它主要用于将用户以自然语言提出的问题自动转换成能够被数据库系统理解并执行的SQL查询，从而实现从数据库中检索相关信息的目的。 问题拆解 语义理解 自然语言通常具有很高的复杂性和多义性。语义理解要求系统能够准确地捕捉用户查询的意图，并处理自然语言中的模糊和歧义。这包括理解自然语言中的上下文、处理指代、识别关键实体和关系，以及解析复杂的句子结构。 Schema映射 Schema映射涉及将自然语言查询映射到数据库模式中的具体表和列。数据库的模式通常非常结构化，而自然语言查询可能没那么直接地指明这些结构。例如，一个查询可能使用同义词或间接提及而不是明示的列名或表名。系统需要具备将自然语言中提到的概念正确映射到数据库结构上的能力。 SQL生成 SQL生成是将处理过的自然语言意图和映射到数据库元素的信息转换为合法的SQL查询的过程。生成的SQL不仅需要语法正确，而且在语义上准确地代表原始的用户需求。挑战在于生成的SQL需要处理不同的查询形式和复杂度，包括聚合、嵌套查询、连接等功能。此外，生成的SQL必须满足高性能、合规性和安全性问题。 核心挑战 语法正确 数据库架构本身的复杂性和庞大体量的数据对NL2SQL构成了明显的挑战，比如数据库语法的多元性、表之间的关系复杂性、列名的相似性、以及大数据量的不完整性。 语义正确 自然语言可能因歧义和不明确性而含有不确定性，例如词义歧义、句法歧义、信息不足和用户错误。与此同时，当实际应用到业务场景时，不同团队对同一术语的定义也可能不同。比如“成交”可能意味着产生订单，也可能意味着必须支付。 效果稳定 NL2SQL与编程语言不同，因为输入的NL和输出的SQL查询之间通常存在一对多的映射。即使是完全一样的问题，也可能输出各种不同的SQL结果。 ▐ 2.2 发展历史 基于规则的方法 早期研究主要集中在使用预定义规则或语义解析器来理解自然语言查询并将其转换为SQL查询。 基于神经网络的方法 为了解决基于规则的方法的局限性，研究者开始利用神经网络来解决NL2SQL，例如使用序列到序列模型或图神经网络。 基于预训练语言模型的方法 随着BERT和T5等预训练语言模型的出现，基于PLM的NL2SQL方法在多个基准数据集上取得了显著的性能提升。 大型语言模型时代 随着LLMs的出现，NL2SQL技术取得了显著进展，LLMs具有卓越的语言理解和新出现的能力，例如使用提示来执行NL2SQL任务。 关键技术挑战与解决方案 ▐ 3.1 Schema Linking（模式链接） Schema Linking旨在理解自然语言查询与数据库模式（schema）之间的语义关系，以帮助生成准确的SQL查询。 自然语言问题 → 表选择器 → 相关表集合 → 列选择器 → 最终SQL 检索模块 用户提问—>含有小样本的命名实体识别prompt+LLM—>得到关键词和实体—>根据关键词的语义相似性匹配top k列 | 基于局部敏感哈希 (LSH) 和语义相似性的两阶段检索策略检索值—>得到最终列和值 表选择器 表选择器的作用是识别哪些表与查询最相关，并需要在SQL查询中用到。 表选择器通常通过以下几步实现： 自然语言理解：分析用户的查询，提取关键实体和操作动词。 Schema 分析：了解数据库模式中有哪些表、字段以及它们之间的关系。 语义匹配：将用户查询的关键部分与数据库的表和字段进行匹配，以识别相关的表。 表优先级排序：根据相关性对表进行排序，优先选择最相关的表参与SQL构建。 列选择器 含有小样本的prompt+LLM—>仅选择与用户提问最相关的最少列。 ▐ 3.2 复杂查询理解 Chain-of-thought（CoT） 思维链（CoT）与大型语言模型（LLM）相结合，能在复杂的推理任务上取得了不错的结果。 Divide and Conquer CoT（分而治之CoT）：让模型把查询任务拆解成更细粒度的任务，然后用SQL伪代码写出对这些子任务的查询，最终将结果合成一个完整的SQL。直接写SQL效果不好是因为模型可能没有见过这样的数据分布，但是它肯定见过简单任务的数据分布，在SQL子语句都写出来了的前提下，SQL的组合就显得没那么复杂了。 Query Plan CoT（查询/执行计划CoT）：让模型先把SQL的执行计划描述出来，再通过执行计划来生成SQL。这么做可以让模型换个角度思考问题，将数据分布切换到了另外一个领域，能让模型更多地关注具体要用的表、列，能补足“分而治之”方法对细节把控不足的缺点。 ▐ 3.3 提示词工程 在利用LLM完成NL2SQL任务时，提示工程的关键在于将自然语言问题与必要的数据库信息转化为适用于LLM的自然语言序列输入，即问题表示。同时，当允许输入一些样例以利用LLM的in-context learning能力时，还需要考虑如何选择样例以及如何将这些样例有机地组织到输入序列中。 基本提示 基本提示（Basic Prompt）是一种简单的Prompt模板，它由表模式、以 Q: 为前缀的自然语言问题、以及提示LLM生成SQL的响应前缀 A:SELECT 组成。之所以命名为基本提示，是因为它并未包含任何指令内容。 文本表示提示 文本表示法提示（Text Representation Prompt）相比于基本提示，在提示的开头添加了指导LLM的指令。 OpenAI范式提示 OpenAI示范提示（OpenAI Demostration Prompt）首次在OpenAI的官方NL2SQL演示中使用，它由指令、表模式和问题组成，其中所有信息都用“#”进行注释。与文本表示提示相比，OpenAI示范提示中的指令更具体，而且还有一条规则约束，“仅完成sqlite SQL查询，无需解释”。 代码表示提示 代码表示提示（Code Representation Prompt）是一种基于SQL语法实现NL2SQL任务的方式。具体来说，它直接将表创建语句“CREATE TABLE …”放到Prompt中。相较于其他的问题表示方法，代码表示提示的独特之处在于，它能够提供创建数据库所需的全面信息，例如列名、列类型、主键/外键等。 通用方案总结 综合考虑上述Prompt策略，可以总结出一套通用且有效的NL2SQL Prompt策略。这一策略由六个关键要素构成，每个要素在提升模型生成SQL的准确性和效率中发挥着重要作用。以下是各个要素的详细说明： 指令（Instruction）：为模型提供清晰而具体的指导方针。例如，"你是一个SQL生成专家。请参考如下的表格结构，直接输出SQL语句，不要提供多余的解释。" 数据结构（Table Schema）：类似于语言翻译中的“词汇表”，这是你需要嵌入到Prompt中的数据库表结构。由于大模型无法直接访问数据库，你需手动提供包括表名、列名、列的类型、列的意义，以及主键和外键信息。 参考样例（Sample）：这是一种启发模型生成SQL的可选技巧。你可以提供一个类似任务的SQL样例作为参考，以帮助模型更好地理解应该如何构建查询。 其他提示（Tips）/约束条件（Constraint）：这些是你认为必要的额外指示。例如，要求生成的SQL中不允许出现某些表达式，或者要求列名必须采用“table.column”的形式。 领域知识（Knowledge）：在某些特定问题中，这是一个可选要素。例如，如果用户的问题涉及“谁是这个月最厉害的销售”，你需要告诉模型，“最厉害”是指“销售单量最多”还是“销售金额最多”。 用户问题（Question）：这是以自然语言形式表达的查询需求，如“统计上个月的平均订单额”。这一部分用于明确用户的意图和需求，以便模型生成正确的SQL语句。 ▐ 3.4 多轮对话 SQL 候选生成和优选 候选生成（Candidate Selection）是为了从候选SQLs中选出最好、最正确的一个，常见方法包括： self-consistency。以N个候选SQL中最常见的（非空）答案为准 selection agent。用模型来挑选最好的SQL，可以用提示词或fine-tuning等技术 基于Unit test。参照AI coding，生成Unit Tests，用来评估每个candidate SQL的得分 SQL 语法微调 采用SFT方法，通过微调小参数量模型来生成可控的SQL查询。然而，参数限制使得复杂的推理和领域的迁移变得困难。此时可以聚焦于生成高精度、多样化的SQL候选语句。 基础语法训练：这一阶段专注于使用简单且通用的SQL模式和语法对预训练模型进行微调，不涉及具体SQL方言。其目标是开发一个能够激活SQL生成能力的基础模型。 生成增强训练：在基础训练后，通过多任务和句法偏好数据增强模型能力。除了标准的查询生成，还可以额外设计SQL转换任务以深化SQL与问题间的关系。这包括从SQL推断问题、从SQL选择证据及其优化任务。这些任务加强了SQL与上下文信息的关联性，提高了SQL生成的广泛性和多样性。通过不同风格的句法特征，扩展训练样本，使模型从多样化数据中学习，从而生成更丰富的SQL查询。 SQL 查询优化 生成的候选SQL查询不可避免地包含逻辑或语法错误。通过利用这些SQL查询缺陷中的线索，进行一定程度的修正。为此，可以引入一个SQL优化器来优化生成的SQL。在实际应用中，基于与架构相关的上下文、生成的SQL查询以及执行结果（包括潜在的错误信息），可以使模型能够进行第二轮的修正。原始SQL和重新生成的SQL还可以进一步通过选择模型进行最优选择，这一过程可以迭代执行。 ▐ 3.5 检索增强生成（RAG） 简单来讲，RAG技术就是通过检索获取相关的知识并将其融入Prompt，让大模型能够参考相应的知识从而给出合理回答。因此，可以将RAG的核心理解为“检索+生成”。而在上文的「提示词工程」章节我们可以看到，为了提高NL2SQL生成的SQL质量，需要在提示词中加入业务领域知识、表知识（Scheme）和列知识（Indicator），甚至是一些样例（Examples）问题便于query改写。而这往往又会造成提示词过多造成的上下文token不够的问题。因此，如果能将这些知识都转换成即时查询的方式，可以有效解决上下文token过大的问题。 在NL2SQL场景中，以下关键步骤可以借助RAG提高效率： 领域知识查询： RAG可以利用预训练模型和检索技术相结合，帮助理解用户的查询所涉及的领域或上下文。通过从相关文档或数据库检索信息，RAG可以为生成更精确的SQL语句提供背景知识。 具体应用包括根据领域特定的术语或概念检索相关信息，从而帮助系统更好地理解和处理复杂或专业的查询。 表查询： 在生成SQL查询时，正确选择和理解数据库中的表是至关重要的。 RAG可以通过检索数据库的元数据或相关文档，帮助识别合适的表及其结构。 指标查询： 对于用户查询中涉及的各种指标，例如计算平均值、总和、最大值等，RAG可以帮助检索相关的计算逻辑或历史数据。 RAG能够从过去的查询实例或相关文档中提取信息，帮助提高生成查询的准确性和效率，尤其是在复杂计算的场景中。 ▐ 3.6 NL2Semantic2SQL 除了从数据库和SQL层面思考如何提高NL2SQL的准确性，还可以从增加语义理解层来思考解决方案。因为如何将用户模糊、多变的业务意图如何精准、高效地映射到企业复杂的数据资产中？这一问题本身就是数据工程问题，而非单纯的 AI 问题。 可以通过如果额外引入一层语义层来更好的解决NL2SQL问题。语义层需要有以下特征： 统一的业务语义抽象层，作为Agent和开发人员共同理解的“数据语言”； 强大的元数据管理能力，确保指标定义的唯一性、透明性和可追溯性； NL2Semantic2SQL 技术路线通过引入语义层作为中间抽象，大幅提升了系统的灵活性和可解释性。指标平台采用"度量"和"维度"两大基础要素，并运用"基础度量"、"业务限定"、"时间限定"和"衍生方式"四大要素，灵活定义和组合具有明确业务含义的指标，打造了一个统一的语义模型。自然语言查询首先被转换为语义表示，然后由系统基于语义模型生成最优SQL查询。 这种语义与表结构的解耦设计，使系统能够理解指标的业务意义，而不仅仅是表结构，确保在不同场景下，同一指标的口径保持一致性。随着业务规则的变化，只需调整语义定义，无需修改所有相关表或查询，显著提高了系统的适应性。 语义层的引入是 NL2Semantic2SQL 相对于传统NL2SQL的核心优势。它不仅提升了查询的准确性，还增强了系统的可解释性，赋予业务人员更强的自助能力。通过构建统一的业务语义模型，指标平台有效地跨越了技术与业务之间的鸿沟，使业务人员可以直接理解和使用数据，而无需深刻掌握SQL语法。 ▐ 3.7 半结构化的数据库表达 scheme LLM专属注释 正如上文所说，在使用基于LLM的NL2SQL技术时，为了使模型能够准确理解数据表的含义和列名的表示，建议为常用的数据表及其列添加注释。 表注释有助于模型更好地理解表的基本信息，从而在生成SQL语句时准确定位相关表。注释应简单明了，概括表的核心内容，如订单、库存等，并建议控制在10字以内，以避免过多解释。 列注释通常由常用名词或短语构成，例如订单编号、日期、店铺名称等，以准确表达列名的意义。此外，可以在列注释中包含列的示例数据或映射关系。例如，对于列名“isValid”，注释可以写成“是否有效。0：否。1：是。”以清楚地表示该列的含义和数值对应关系。 但是传统的数据库表注释和列注释可能已有一定的含义和上下游对接规范，所以目前有些数据库可支持scheme维度LLM专属的注释，用于提供NL2SQL时获取表和列的提供便利。比如阿里的PolarDB，开源的M-Schema项目。 来源（公众号）：大淘宝技术

2025上半年，DeepSeek大模型以“免费开放+开源生态”迅速占领技术圈，其强大的自然语言理解、代码生成、数据推理能力，正在重塑企业数据仓库的运作逻辑。

来源（公众号）：大数据AI智能圈 周一早上，销售总监急匆匆跑到你办公室："我们需要分析一下华东区域的客户画像，制定下季度的营销策略。" 你打开CRM系统，发现客户信息不全。打开ERP系统，发现交易数据格式乱七八糟。再打开财务系统，发现同一个客户竟然有三个不同的编号。 这就是数据孤岛的真实写照。每个系统都在自己的小王国里称王称霸，互不往来。你想要的那个"完整的客户画像"，就像拼图游戏一样，碎片散落在各个角落。 数据孤岛的隐性成本，远比你想象的高 让我给你算一笔账。 某制造企业的采购经理小王，每次采购都要花2小时核对供应商信息。同样的供应商，在不同系统里有不同的编码、不同的名称、不同的联系方式。 小王说："我感觉自己不是在采购，而是在做侦探工作。" 这还不是最糟糕的。更要命的是，错误的数据会导致错误的决策。 去年，一家零售企业的市场部门，基于不准确的客户数据，投入了500万做精准营销。结果呢？转化率只有预期的30%。后来才发现，他们的客户数据有40%是重复的，30%是过期的。 你看，数据质量差不仅仅是技术问题，它直接影响的是你的钱包。 更可怕的是，在数字化转型的今天，数据已经成为企业的核心资产。 如果你的数据还在"各自为政"，那你的竞争力就会被严重削弱。 AI重新定义主数据管理的游戏规则 传统的主数据管理，就像是让一群人工编辑去整理图书馆。 他们需要逐本逐页地检查、分类、整理。工作量大，效率低，错误率高。 AI的出现，完全改变了这个游戏。 如果此时，你有一个超级智能的助手，它可以： 自动识别和清洗数据。它能瞬间发现"苹果公司"和"Apple Inc."其实是同一家公司，能自动修正"138****1234"这种不完整的电话号码，能识别出哪些是重复数据、哪些是异常数据。 智能关联不同系统的数据。它能像侦探一样，通过各种线索（姓名、电话、地址、交易记录等）找到散落在不同系统中的同一个客户信息，然后把它们完美地拼接在一起。 实时监控数据质量。它会24小时不间断地监控你的数据，一旦发现异常，立即发出警报。就像是给你的数据安装了一个"健康监测器"。 这已然不是科幻小说，这是正在发生的现实。 从案例看AI+主数据的真实威力 让我跟你分享几个真实案例。 案例一：全球消费品巨头的数据整合 这家公司在全球有200多个分支机构， 数据散落在几十个不同的系统中。传统方法需要几百个人工作一年才能完成数据整合。 AI介入后，3个月就完成了全球数据的统一管理。数据质量提升了30%，决策效率提高了15%，运营成本降低了10%。 更重要的是，统一的数据视图让他们能够更好地理解全球客户需求，制定更精准的产品策略。 案例二：零售企业的精准营销 某大型零售企业面临的问题是：客户数据质量差，营销效果不理想。 AI帮助他们整合了来自线上线下的所有客户数据，构建了完整的客户画像。系统能自动识别客户的生命周期阶段，并推荐相应的营销策略。 结果：营销转化率提高了20%，客户满意度提高了15%，销售额提升了10%。 案例三：金融企业的风险管控 金融行业对数据安全和合规性要求极高。传统的人工监控方式既费时又容易出错。 AI系统能实时监控所有数据访问行为，自动识别异常操作，确保数据合规性。这家企业的数据安全风险降低了20%，合规性提高了15%。 你看到了吗？ AI+主数据不仅仅是技术升级，它是商业模式的根本性变革。 结语 AI技术还在快速发展。 未来的AI+主数据管理会变得更加智能、更加自动化。 现在的问题是：你的企业准备好迎接这个变革了吗？

龙石数据中台 V3.7.1 升级详情速览

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

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

"小王，这个数据跑了三个小时还没出来，明天的AI模型训练怎么办？" 办公室里，数据科学家小李盯着电脑屏幕，眉头紧锁。屏幕上的进度条像蜗牛一样爬行，让人怀疑人生。 这个场景你熟悉否？在AI时代，如果数据真是新石油，那么数据科学家就真是炼油工了。大家都在谈论AI多么神奇，DeepSeek多么智能，模型多么强大。 可现实呢？90%的时间都在等数据，等数据传输，等数据清洗，等数据准备。 数据科学家们经常自嘲："我们是AI时代的搬砖工。" 传统数据传输的痛点：慢到怀疑人生 让我们算一笔账。 一个中等规模的机器学习项目，需要处理10TB的数据。用传统的MySQL客户端或JDBC连接方式，传输速度大概是每秒几百MB。10TB数据需要传输多久？ 整整一个通宵。 更要命的是，这还只是传输时间。数据到了本地，还要进行格式转换、清洗、预处理。原本的列存格式数据，要先转成行存传输，到了客户端再转回列存格式供算法使用。这个过程好比把一箱苹果先打散，装到一个个小袋子里运输，到了目的地再重新装箱。 "这不是脱裤子放屁吗？"一位资深算法工程师吐槽道。 传统方案的问题不止于此： 数据传输过程中要经历多次序列化和反序列化，CPU资源消耗巨大。内存占用也成倍增长，动不动就爆内存。网络带宽被低效利用，明明有千兆网络，却只能跑出百兆的效果。 更让人抓狂的是，很多数据科学项目需要反复试验，同样的数据要传输N次。每次调参、每次验证、每次重新训练，都要重新来一遍这个痛苦的过程。 Arrow Flight SQL：数据传输界的su7 Doris 2.1版本带来了一个救命性的功能：基于Arrow Flight SQL协议的高速数据传输链路。 什么概念？原来需要一晚上传输的10TB数据，现在可能只需要几十分钟。性能提升不是10%、20%，而是百倍级别的飞跃。 这真就从绿皮火车换到了高铁，从马车换到了小米su7。 Arrow Flight SQL的巧妙之处在于彻底颠覆了传统的数据传输思路。 Doris内部查询结果本身就是以列存格式的Block组织的。传统方案需要把这些Block转换成行存的Bytes传输，客户端接收后再反序列化为列存格式。 Arrow Flight SQL直接跳过了这个"脱裤子放屁"的过程。数据在Doris里是什么格式，传输过程中就是什么格式，到了客户端还是什么格式。零转换，零损耗。 这就像快递公司不再要求你把东西重新包装，而是直接用你的原包装发货。省时省力省心。 而真正让Doris在数据科学领域脱颖而出的，不仅仅是速度，更是它对生产环境复杂性的深度理解。 很多数据科学项目在实验室里跑得很好，一到生产环境就各种问题。网络不通、权限不够、配置复杂、扩展困难。 Doris的Arrow Flight SQL充分考虑了这些现实问题： 1. 多BE节点并行返回结果 当查询结果很大时，可以从多个节点同时获取数据，进一步提升传输效率。 2. 支持反向代理配置 生产环境中BE节点通常不直接对外暴露，Doris可以通过Nginx等反向代理实现数据转发，既保证了安全性，又维持了高性能。 3. 提供灵活的连接管理 支持长连接复用，减少连接建立开销；同时提供合理的超时和清理机制，避免资源泄露。 与大数据生态的深度融合 当然，数据科学项目很少是孤立的。 它们通常是更大数据处理流水线的一部分，需要与Spark、Flink等大数据框架协同工作。 Doris的Arrow Flight SQL为这种协同提供了完美的桥梁。Spark可以通过Arrow Flight SQL高效读取Doris数据，进行大规模特征工程；Flink可以实时消费Doris的流式数据，为在线机器学习提供支持。 更重要的是，Arrow作为一种标准化的内存数据格式，已经被越来越多的数据处理框架采用。这意味着基于Arrow Flight SQL的数据流水线具有很好的互操作性和可扩展性。 你的数据可以在Doris、Flink、Spark、Pandas、TensorFlow之间无缝流转，就像水在不同容器间流动一样自然。 用Python轻松驾驭海量数据 对数据科学家来说，最爽的事情是什么？当然是代码跑得飞快，数据来得及时。 import adbc_driver_manager import adbc_driver_flightsql.dbapi as flight_sql # 连接Doris conn = flight_sql.connect(uri="grpc://doris-fe:8070", db_kwargs={     adbc_driver_manager.DatabaseOptions.USERNAME.value: "user",     adbc_driver_manager.DatabaseOptions.PASSWORD.value: "pass", }) cursor = conn.cursor() # 执行查询 cursor.execute("SELECT * FROM massive_table") df = cursor.fetch_df()  # 直接返回pandas DataFrame ... 就这么简单。几行代码，亿级数据瞬间到手。不需要复杂的配置，不需要担心内存爆炸，不需要等待漫长的传输时间。 关键是cursor.fetch_df()这个方法。它直接返回pandas DataFrame，数据全程保持列存格式。科学家们可以立即开始数据分析，无缝对接NumPy、Pandas、Scikit-learn等主流数据科学库。 有位数据科学家兴奋地说："这感觉就像从拨号上网时代一步跨入了光纤时代。" Java生态的全面支持 Java开发者也没有被遗忘。Doris提供了多种Java连接方式，适应不同的使用场景。 如果你的下游分析需要基于行存数据格式，可以使用标准的JDBC方式： String DB_URL = "jdbc:arrow-flight-sql://doris-fe:8070"; Connection conn = DriverManager.getConnection(DB_URL, "user", "pass"); Statement stmt = conn.createStatement(); ResultSet resultSet = stmt.executeQuery("SELECT * FROM data_table"); ... 如果你想充分利用Arrow的列存优势，可以使用ADBC Driver： final BufferAllocator allocator = new RootAllocator(); FlightSqlDriver driver = new FlightSqlDriver(allocator); AdbcDatabase adbcDatabase = driver.open(parameters); AdbcConnection connection = adbcDatabase.connect(); AdbcStatement stmt = connection.createStatement(); stmt.setSqlQuery("SELECT * FROM massive_dataset"); QueryResult queryResult = stmt.executeQuery(); ArrowReader reader = queryResult.getReader(); ... 这种方式返回的是原生Arrow格式数据，可以直接用于大数据分析框架，性能达到极致! 结语 回到文章开头的场景。现在的小李不再需要通宵等数据了。 "小王，昨天的10TB数据已经处理完了，新的模型训练可以开始了。"小李轻松地说道。 "这么快？"小王有些惊讶。 "Doris的Arrow Flight SQL，数据传输快得飞起。我现在有更多时间专注于算法优化，而不是等数据。" Doris的Arrow Flight SQL让数据科学真正起飞了，让AI应用的开发变得更加高效和可靠 来源（公众号）：一臻数据