大型数据库模型(LDM)的定义与数据现状
视频开篇通过对比常见的AI缩写,引出了大型数据库模型(Large Database Model, LDM)这一概念。与大型语言模型(LLM)和大型推理模型(LRM)不同,LDM并非基于书籍、文章或维基百科等文本数据训练,而是专门针对关系型数据库中的选定表或视图进行训练。这种模型的核心优势在于能够处理企业中最核心的数据资产。据统计,仅有1%的企业数据最终会进入LLM的视野,而其余99%的数据被锁定在关系型数据库中,往往受到加密和访问控制的层层保护。因此,若要让AI真正服务于企业的日常业务,必须有一种技术能够深入这99%的数据腹地,而LDM正是为此而生。
"Instead of training on books and articles and Wikipedia and what have you, an LDM can be trained on a selected number of tables or views that reside in a relational database using the columns you choose to include."
传统SQL查询的局限性与成本分析
为了说明LDM的价值,视频构建了一个电商推荐场景:当一位顾客将美容产品加入购物车时,零售商需要找到行为相似的其他顾客进行精准推荐。在传统模式下,数据科学家需要手动创建客户画像,这通常涉及编写复杂的SQL查询。例如,查询可能设定为:"SELECT customer ID FROM customers WHERE age BETWEEN 20 AND 40 AND city = 'New York' AND beauty spend > 1000"。这种方法的致命缺陷在于查询条件的刚性——数据科学家必须主观猜测哪些字段(如年龄、城市、消费金额)与顾客相似性相关,而忽略了性别、购物时间、退货历史等其他潜在重要因素。此外,这一过程效率低下且成本高昂,因为数据需要被提取并加载到分析平台中,导致数据离开受保护的环境,增加了安全和合规风险。
IBM的报告指出,客户将其IT预算的32%至40%仅用于数据的移动和传输。这种高昂的成本不仅体现在资金上,更体现在数据离开安全环境后难以追踪和保护的隐患上。传统方法依赖于人工筛选字段,这不仅耗时,而且由于人为判断的局限性,往往无法捕捉到数据间复杂的非线性关联。
LDM查询机制:语义与向量的结合
相比之下,LDM生成的查询方式截然不同。它不再依赖硬编码的WHERE子句来筛选特定字段,而是允许用户直接询问:"给我找出与顾客ID CUST4729最相似的顾客",并指定基于训练好的模型进行查询。这种查询方式的核心优势在于消除了人工猜测字段的必要性。LDM模型已经通过训练,学习了选定表中各行和各列之间的共现关系,理解了哪些值倾向于一起出现。当查询发起时,数据库基于从选定列和行中学习到的向量表示(Vector Representations)来回答,从而自动捕捉数据间的深层关联。
值得注意的是,LDM并非完全摒弃SQL,而是实现了AI语义查询与标准SQL能力的结合。用户仍然可以在LDM查询中加入传统的WHERE子句以限制范围(例如仅限某个国家的客户),从而兼顾了语义智能与精确控制。这种混合模式被认为是"两全其美"的最佳实践,既利用了AI的泛化能力,又保留了数据库的严谨性。
LDM的五步构建流程与嵌入技术
LDM的实现过程包含五个关键步骤。第一步是选择数据表并分类列属性:将列分为分类列(如状态、地区等离散值)、数值列(如年龄、价格等连续值)以及主键列(如客户ID)。第二步涉及将每个值转换为令牌(Token),这是LDM技术中最精妙的部分,依赖于嵌入(Embeddings)技术。嵌入技术将单词或数值转换为数字列表(向量),使得语义相似的词(如"cat"和"kitten")在向量空间中指向相似的方向。
然而,数值处理比文本更复杂。模型并不天然理解数值的大小关系,例如数字37和38在模型眼中可能只是两个不同的令牌,其向量距离未必比37和"kitten"更近。虽然模型可能通过间接数据关联学习到37岁和38岁顾客行为相似,但这是一种缓慢且不可靠的学习方式。此外,连续数值列往往包含大量稀有值(如37.5和37.6),这些值出现频率太低,导致模型难以为其学习良好的向量表示。因此,对于任何数值列,通常需要先进行分箱(Binning)处理,即使用聚类算法将连续值离散化,以便模型更有效地学习其向量表示。
"For any numeric column, the values get binned first, which is to say a clustering algorithm compresses the continuous values into discrete bins."
"The model doesn't really have the concept of numbers as numbers, to it 37 and 38 are just two different tokens."
"With LDMs, the model has learned from the columns selected for an AI object across the rows in that table of view and it's learned which values tend to show up alongside which other values."
LDM的数据预处理:数值分桶与上下文隔离
大型数据库模型(LDM)的核心在于将结构化数据转化为AI可理解的Token序列,这一过程始于对数值和分类数据的精细化处理。对于数值型数据,模型采用数值分桶(Binning)策略,将数值相近的值归入同一区间。例如,年龄37岁和38岁会被映射到同一个桶中,获得相同的ID。从模型视角来看,这两个值被视为完全相同的Token,这种处理方式避免了让模型从零开始学习数值间的细微等价关系,从而大幅降低了学习成本。
同时,为了防止语义混淆,每个值都会与其所在的列名绑定。例如,“New York”出现在“city”列中时,生成的Token与出现在其他列(如“state”或“address”)时完全不同。这种设计确保了模型能够区分相同字符串在不同列中的不同语义,避免将含义迥异的数据混为一谈。这一步骤确立了数据在向量空间中的基础身份标识。
行转句与自监督训练:构建语义向量空间
数据预处理完成后,LDM进入序列化和训练阶段。每一行数据被转换为一个无序句子(Bag of Words),这意味着行内每个Token与其他Token的关系是平等的,不依赖列的位置顺序。以顾客4729为例,其数据行可能转化为包含“city: New York”、“age: b7”、“gender: f”等Token的序列。其中,分类字段保留原始标签(如“beauty”),而数值字段则使用分桶后的ID(如“b7”代表35-39岁区间)。
随后,自监督神经网络遍历所有“行句子”,学习每个唯一Token的向量表示。训练结果是,模型词汇表中包含了所有选定的分类值和数值聚类。关键在于,出现在相似行中的值会在向量空间中彼此靠近。例如,行为模式相似的顾客所在的城市会在向量空间中形成聚类。这种机制使得模型能够捕捉数据中隐含的语义关联,而非仅仅存储原始记录。
SQL原生交互:五大语义查询能力
LDM的独特优势在于训练好的模型被直接加载回数据库内部,用户无需将数据发送至外部AI服务,而是通过标准SQL直接进行语义查询。这种架构支持五种核心操作:
- 相似性搜索(Similarity):例如查找“哪些顾客与我们的目标顾客相似?”或“哪些交易模式与正常模式差异最大?”,用于异常检测。
- 聚类(Clustering):确定某个产品属于哪一组参考产品集群。
- 类比(Analogy):判断一种关系是否与另一种关系相似(如“A之于B”是否等同于“C之于D”)。
- 共性分析(Commonality):识别记录中特别常见或罕见的模式。
“All this is running... As standard SQL against the database itself with the data being used in place rather than being sent off to an AI model someplace else.”
这种原位数据处理方式不仅降低了延迟和数据隐私风险,还让具备SQL基础的用户即可执行复杂的语义分析,无需数据科学家介入构建管道。
行业应用与IBM商业落地案例
LDM已跨越零售领域,在保险、金融和食品零售等行业实现生产级应用。在保险业,系统从数百万记录中检索最相似的历史保单,以预测新报价的成功率;欺诈检测团队利用其识别偏离典型模式的异常交易;合同管理部门则通过对比投资组合中的协议,快速发现 standout agreements(突出/异常协议)。在食品零售中,LDM被用于营养相似性搜索,例如查询“什么食品在营养上与裹糖杏仁相似?”,模型给出的答案是燕麦片,展现了其跨品类语义理解能力。
商业落地方面,IBM于2022年推出了首款基于LDM的数据库产品SQL Data Insights,作为DB2 for ZOS的一部分。2026年3月发布的SQL Data Insights Pro进一步扩展了能力,支持非结构化文本与结构化列的联合处理,并引入了增量模型刷新功能,使模型能够针对新数据更新而无需重新训练整个类别。这标志着LDM技术从概念验证走向成熟的企业级部署。
“Anybody who can string together a SQL statement... can ask these semantic questions without needing a data scientist to translate them into a pipeline first.”
两个核心趋势在此显现:模型运行在数据所在处,且任何会写SQL的人都能直接进行语义查询。