DB-first or LLM-first or...

现代企业日益受到“DATA+AI”范式的驱动。在这一范式中，自20世纪70年代以来作为企业基石的DBMS和自2020年以来迅速崛起的LLM，已分别成为处理结构化数据和非结构化内容的“两大基础性设施”。

论文开篇即提出了一个核心观点，即二者的关系可以用一个公式来表达：

这一定位至关重要。它没有将LLM仅仅视为DBMS的一个插件或功能，更没有将其视为“替代品”，而是将其提升到与DBMS同等重要的“基础设施”地位。这预示着未来的系统设计必须是围绕这两个系统的共存与深度协同来构建的。

为什么这种集成变得如此迫切？论文指出了几个关键的驱动因素：

1.混合查询处理需求： 现代应用需要在一个任务中无缝地结合结构化数据检索（如SQL查询）和非结构化数据理解（如语义推理、自然语言交互）。

2.系统级协同作用： DBMS数十年来发展的成熟特性（如索引、缓存、事务管理、查询优化）可以被用来反向“增强”和“优化”LLM操作的效率、一致性和可靠性，尤其是在处理大规模或动态数据集时。

3.工业大模型 (ILMs) 的兴起： 这些面向特定行业的模型越来越需要DBMS作为其强大的结构化后端，同时利用LLM提供灵活的推理和自然语言接口。

这种“双基础设施”的范式，也预示着企业IT部门和数据团队的根本性转变。过去，数据库管理员（DBA）、数据工程师和AI团队（数据科学家）可以相对独立地工作。但在新范式下，系统架构师必须同时精通ACID事务、查询优化、向量嵌入和概率推理。这几乎催生了一个新角色——“AI数据库架构师”——的诞生，他们必须在两个领域的交汇处进行系统设计。

为了理清集成的基础，论文首先强调：DBMS和LLM并非竞争技术，它们源于不同的技术背景，解决不同的问题，因此具有高度的互补性。论文通过下表来精炼地阐明这种互补性。

表 1：数据库管理系统（DBMSs）与大型语言模型（LLMs）在工业和商业应用中的比较

·核心优势 (Strengths): 这是最关键的对比。DBMS提供的是“确定性”和“约束”——ACID事务保证、高查询效率、数据完整性、精确的连接与聚合。而LLM提供的是“灵活性”和“泛化能力”——类人交互、非结构化数据处理、从少量样本中学习。

·接口 (Interface): DBMS的接口是“机器友好”的（如SQL），专为精确的数据操作而设计。LLM的接口是“人类友好”的（如自然语言提示），专为理解和生成而设计。

·可解释性 (Interpretability): DBMS的行为是“透明”的，其决策过程可以通过（通常）可读的查询计划来理解。而LLM的行为是“不透明”的，其推理过程是黑盒式的。

·更新 (Update): DBMS支持“细粒度”的元组级更新和事务，这是其核心能力。而LLM没有原生的数据更新机制，其知识更新需要依赖“重量级”的再训练或RAG（检索增强生成）。

这意味着，任何集成架构都必须在“效率/一致性”（DBMS的优势）和“灵活性/推理能力”（LLM的优势）之间做出权衡。这为论文后续提出的五种架构模式分析奠定了理论基础。

这是论文的核心内容。通过对现有工业和商业应用的大量调研，作者识别并归纳了五种代表性的集成架构模式。

图1：不同集成策略的图示

这五种模式分别是：

1.DB-first (数据库优先): LLM作为一个组件或算子被嵌入到DBMS内部。

2.LLM-first (LLM优先): DBMS作为LLM（通常是Agent）调用的一个工具或后端。

3.Middle-layer (中间层): 一个独立的中间协调层（即中间件）来管理和编排DBMS与LLM的交互。

4.Pipe-connected (管道连接): DBMS和LLM作为两个独立的系统，通过数据管道（流式或批量）进行异步数据交换。

5.Platform-based (平台基座): 云平台将DBMS和LLM作为统一管理的托管服务提供，通过平台能力进行集成。

论文进一步提供了一个详细的优缺点对比表（表2），以帮助架构师理解不同策略的权衡。

表2：不同DBMS-LLM集成策略的优缺点比较

表2揭示了一个贯穿全文的核心权衡：开发者是在用“系统性能和深度功能” (DB-first) 来交换“开发灵活性和解耦” (Pipe-connected Middle-layer)。

DB-first 策略是数据库社区最感兴趣的，因为它将传统的DBMS置于核心地位，LLM仅作为辅助模块或外部服务。这种模式保留了DBMS的“完全控制权”。

论文的核心图示（图2）清晰地展示了LLM可以“侵入”DBMS传统处理流水线的三个不同入口点。这三个入口点（Interface, Optimizer, Executor）也代表了集成从浅到深的三个层次。

图2： DBMSs的架构、处理流程以及LLMs的接入点

1. LLM-as-Interface (LLM作为接口)

这是最自然、目前也最广泛被采用的方式，即 Text-to-SQL（或NL2SQL）。LLM被用作一个前端翻译器，将用户的自然语言意图转换为DBMS可以执行的SQL查询。

然而，论文引用了BIRD等新一代Text-to-SQL基准，指出即使是GPT-4这样的SOTA模型，在面对真实世界的复杂数据库（例如充满噪音的数据、需要外部知识、效率约束等）时仍然表现不佳。

更重要的是，论文指出，Text-to-SQL“主要解决的是用户接口层”的问题 ，它“没有改变DBMS的核心查询处理、优化或执行逻辑”。这个关键的洞察，呼应了领域内“Text2SQL is Not Enough” 的声音。仅仅停留在接口层，远未实现真正的智能数据库，我们需要LLM更深入的介入。

2. LLM-as-Optimizer (LLM作为优化器)

查询优化器被誉为DBMS的“大脑”，负责生成最高效的执行计划。此策略探索使用LLM强大的推理和模式识别能力来增强，甚至“取代”传统的、基于规则和成本的优化组件，例如查询重写、连接顺序枚举和执行计划选择。

论文展示了该领域的两种探索路径：

·辅助 (Augment): 例如LLM-R2使用LLM与传统规则结合来生成更有效的查询重写。LLM-PM则不修改DBMS，而是利用LLM生成的执行计划嵌入来“建议性能提示”（如使用何种连接策略）。

·取代 (Replace): 这种模式更为激进。例如LLM-Q和LLMOpt尝试直接使用“微调”的LLM来“生成”SQL执行计划，完全“绕过”了传统的计划枚举和成本建模过程。

这是DB-first策略中最具争议和风险的一步。DBMS优化器是几十年研究的结晶，其核心是基于成本的“确定性”决策。而 LLM-as-Optimizer 引入了一个“黑盒”的、基于“模式识别”的组件。这带来了一个根本性的博弈：我们是否愿意为了LLM的卓越泛化能力而放弃传统优化器的“可预测性和透明度”？这仍是一个开放性问题。

3. LLM-as-Executor (LLM作为执行器)

这是最深度的集成。LLM被直接嵌入到DBMS的执行引擎中，作为查询计划的一部分，在数据流过时对其进行处理。论文总结了两种执行模式：

·LLM-as-UDF (用户定义函数): 这是一种相对简单的模式。LLM的能力被封装成一个SQL可调用的函数，例如 SELECT classify(review_text) FROM reviews。论文提到了BlendSQL (SQLite)和 FlockMTL (DuckDB)等工作，它们将LLM的分类、摘要等功能作为标量或聚合SQL函数。

·LLM-as-Operator (原生算子): 这是一种相对激进的模式。LLM不再是UDF，而是被提升为与 Join, Scan 地位平等的第一梯队。论文提到的GALOIS, ELEET, 和 CAESURA等系统，开始探索定义“多模态算子 (MMOps)”，例如 VisualQA (视觉问答) 或 TextQA (文本问答)，它们可以被优化器统一编排在查询计划中。

LLM-as-Operator 真正地改变了“数据库能做什么”。传统DBMS只能处理结构化数据。一个拥有“多模态算子”的DBMS，理论上可以执行像 SELECT T.product_name FROM products T JOIN product_images I ON T.product_id = I.product_id WHERE VisualQA(I.image, 'is this a red shirt?') = true 这样的混合查询。这标志着DBMS正从一个“数据管理器”向一个“混合推理引擎”进化。

与DB-first策略完全相反，LLM-first策略将LLM定位为“中央编排层”，而数据库则被降级为一个“支撑组件”或“工具”。

在这种模式下，DBMS不再是主角，而是LLM（通常是一个AI Agent）在执行任务时调用的众多工具之一，其角色类似于RAG（检索增强生成）流程中的向量数据库。

论文提到了一些有趣的案例：

· TranSQL: 这是一个比较激进的尝试，它将神经网络（如Transformer）的操作“翻译”成SQL查询，并把模型权重存储为关系表。这使得关系数据库可以反过来管理LLM的执行。

· Chat2Data: 这是一个更典型的RAG应用，它使用向量数据库作为一个“缓存层”，存储常见问题和答案的嵌入，以提高响应速度。

这种模式带来了“控制权”的反转：

· DB-first 是一个“确定性”的控制器（DBMS）调用一个“随机性”的工具（LLM UDF）。

· LLM-first 是一个“随机性”的控制器（LLM Agent）调用一个“确定性”的工具（SQL数据库）。

LLM-first的核心挑战是“可靠性和正确性”。正如表2所指出的，其弱点是“幻觉或不正确的SQL”以及“弱安全/访问控制”。

该策略既不以DB为中心，也不以LLM为中心，而是引入了一个“中介编排层”（Middleware），它位于两者之间，充当“智能控制器”。

论文指出，这种策略的动机是“桥接确定性查询与概率生成两种范式”。

这个中间层（例如以LangChain等框架为代表，或论文中提到的AOP）负责执行DB-first和LLM-first模式都不擅长的“脏活累活”：

1.任务分解: 将复杂的用户请求分解为多个子任务，一些指向DBMS（结构化查询），另一些指向LLM（语义推理）。

2.动态编排: 协调一个混合了SQL操作和语义操作的复杂执行流水线。

3.状态管理: 维护跨越多个调用的上下文和会话历史（例如Sumedh等人提到的使用时序图数据库来捕获对话历史）。

中间层编排策略的主要优势在于其解耦和可维护性。通过引入一个独立的编排层，DBMS和 LLM可以被看作是独立的黑盒服务，它们通过定义良好的接口进行通信。这种松耦合的设计使得两个系统可以独立开发、部署和扩展，从而提高了系统的灵活性和可维护性。

尽管中间层编排带来了诸多好处，但它也引入了性能开销和系统复杂性。首先，中间层本身需要消耗计算资源，这会增加系统的整体延迟和资源消耗。每个请求和响应都需要经过中间层的处理和转发，这可能会导致性能瓶颈，尤其是在高并发场景下。其次，系统协调的复杂性是一个重大挑战。协调DBMS引擎和LLM之间的执行需要一个能够管理状态、处理部分结果、委派操作符和处理错误的先进运行时环境。设计和实现这样一个健壮的编排层本身就是一项 复杂的工程任务。此外，中间层需要动态适应不同的工作负载特征、延迟预算和应用意图 （例如，信息检索与事务处理），这进一步增加了其设计和实现的难度。

论文最后讨论的这两种策略，更侧重于“部署架构”而非“功能嵌入”。

1. Pipe-connected (管道连接)

这是一种务实的、模块化的集成方法。它使用成熟的流处理技术（如Apache Kafka, Apache Flink）或ETL工具（如Dataverse），在两个独立运行的LLM和DBMS服务之间进行实时或批量的数据交换。

这种模式的精髓在于“事件驱动”。例如，一个新订单（DBMS中的INSERT操作）可以通过Kafka触发一个外部LLM服务（进行欺诈检测或情感分析），LLM处理完的结果再通过另一个管道写回数据库。它的优势是“高度解耦和模块化”，但代价是高延迟与数据最终一致性较差。

2. Platform-based (平台基座)

这代表了云巨头（如Amazon AWS, Google Cloud, Microsoft Azure, Oracle Cloud, Snowflake等）的集成模式。它们将DBMS (SaaS) 和 LLM (MaaS) 作为“统一平台”上的可组合服务来提供。

这种策略的重点是“编排”。云平台自身（例如AWS Lambda, Google Workflows, 或Snowflake Cortex）充当了粘合剂，允许用户在云环境中协调和触发DBMS任务与LLM任务。

这可能是大多数企业最终采用的“务实”选择。它通过“全栈可扩展性”和“低设置成本”来吸引用户。但其代价也是显而易见的，平台锁定是一个主要问 题。一旦选择了某个特定的云平台，系统的设计和实现就会与该平台的API和服务紧密耦合，这使得未来迁移到其他平台变得困难和昂贵。这种锁定可能会限制企业的技术选择，并使其在 价格谈判中处于不利地位。其次，平台的复杂性也是一个挑战。虽然平台提供了统一的管理 界面，但其底层实现通常非常复杂，涉及到容器化、服务网格、分布式存储等多种技术。理解和掌握这些技术需要专业的知识和经验，这可能会增加团队的学习成本和运维难度。此外，平台的成本也可能是一个问题。虽然弹性扩展可以节省成本，但平台的各项服务通常按使用量 收费，如果使用不当，可能会导致意想不到的高额账单。

在分析了所有五种策略后，论文提供了一个总结性的“选型指南”，这对于处在技术选型十字路口的架构师和实践者来说极具价值。论文首先提供了一个面向特征的比较表（表3）。

表 3：DBMS-LLM集成策略的面向特征比较

基于此，论文总结了几个关键的决策点：

1.基于任务需求: 如果你的应用需要“实时”分析流式数据，Pipe-connected 或是 DB-first（的UDF模式）是最佳选择。

2.基于功能需求: 如果你的应用需要“复杂的多模态查询”（例如，在一个查询中同时分析表格、文本和图像），DB-first（的Operator模式）几乎是唯一能实现这种深度融合的途径。

3.基于LLM依赖: 如果应用的核心是LLM的“高级推理”和“Agent行为”，LLM-first 或 Middle-layer 提供了必要的灵活性。

4.基于部署模式: 如果企业已经是“云原生”的坚定拥护者，Platform-based 提供了最低的集成阻力和运维成本。

最后，论文指出，在现实世界的复杂系统中，“混合策略” (Hybrid Strategies)可能才是最佳答案。例如，一个系统可能使用 Platform-based 进行整体部署，但其内部的接口层采用了 DB-first (Text-to-SQL)，同时又使用 Pipe-connected 来处理来自其他系统的异步数据更新。

论文在最后指出了该领域亟待解决的四大开放性挑战。这部分内容不仅是总结，更是为该领域未来几年的研究热点划定了议程。

1. DB-first 策略的挑战

·跨模态查询执行: 如何设计能高效处理“混合数据类型”（表、文本、图、图像、视频）的统一执行模型和查询语言。

·成本模型与优化 (Cost Modeling):这是DB-first面临的最大难题。 传统优化器依赖精确的成本模型（如I/O、CPU成本）来选择计划。但如何“估计”一个 LLM-as-Operator 的“成本”。（它可能取决于Token数量、提示词复杂度、模型版本、甚至API的排队时间）。没有可靠的成本模型，DBMS的优化器就无法智能地决定何时使用LLM算子，何时使用传统的Join。

·跨模态算子设计: 如何系统性地定义 Image-Join-Table 或 Text-Filter-Video 这样的新型算子，并保证它们的组合性与高效性。

2. LLM-first 策略的挑战

·控制力受限: 将控制权交给LLM，意味着牺牲了DBMS的优化能力和事务保证，难以确保“查询的正确性和效率”。

·工具调用的可靠性: 这是Agent的核心通病。LLM“调用工具失败”（如生成错误SQL、理解错API）的“脆弱性”问题仍然突出。

3. Middle-layer 策略的挑战

·系统协调: 在DBMS和LLM这两个“异构”引擎之间管理“状态、部分结果、错误处理”极其复杂。

·动态适应: 中间件需要变得更“智能”，能根据“延迟预算”和“应用意图”（用户是想做事务处理还是信息检索）动态调整其编排策略。

4. 系统设计与评估的挑战

·缺乏定量评估框架:这是目前整个领域最致命的短板。 我们没有一个“标准基准”来公平地、定量地比较这五种策略在“延迟、准确性、成本、可扩展性”上的优劣。

·混合架构的复杂性: 在实践中，当多种策略混合使用时，架构师如何在性能、模块化、故障隔离和开发复杂性之间做出“有原则的权衡”。

最终启示：

这篇论文不仅是一篇对现状的综述，更是一份指导未来的“路线图”。它通过系统性的分类（五大模式）和深刻的挑战分析，为“Data+AI”双基础设施 的未来发展指明了方向。它清晰地告诉我们，实现DBMS和LLM的真正协同，绝不是简单地调用一个API，而是一场涉及数据库内核、查询优化、执行模型乃至整个云架构的深刻变革。解决这些挑战是释放DBMS与LLM协同潜能、构建下一代智能系统的必经之路。

论文解读联系人：

刘思源

13691032906（微信同号）

liusiyuan@caict.ac.cn