10 月 23 日，我受邀参加了 DolphinDB（浙江智臾科技）与浦东新区联合举办的 AI + 金融创新对话活动。去年错过了相关活动，今年终于有机会亲临现场。原本以为这会是一场常规的产品发布，实际走下来，收获比预期多不少。这不仅是一次产品与技术的集中展示，也让我看到了国产数据库在金融行业长期深耕之后，正在向 AI 时代迈出的新一步。活动现场的另一个细节也让我印象深刻。随着智臾科技子公司落地浦东，相关领导出席了此次活动，体现了地方对科技企业发展和数字经济建设的重视。对于一家从时序数据库起步、长期服务金融与工业领域的公司来说，这样的支持是实打实的。现场的团队同样给我留下了很好的印象：年轻、有活力，对产品和业务有深入理解，对客户提出的问题也能耐心回应。技术产品最终要落到真实的业务场景中，而这种既懂技术、又重视客户需求的团队氛围，是产品能走多远的重要基础。走进产品展区，最直观的感受是，DolphinDB 的技术版图已经远远超出了传统时序数据库的范畴。从原生分布式架构，到时序、分析、向量、文本和特征等多种数据管理能力；从低延迟流计算，到 CPU 与 GPU 协同计算，展板呈现的是一套逐步融合数据存储、实时计算与智能分析的技术体系。这些技术单独来看并不陌生，真正值得关注的是，它们如何在同一平台上协同工作。过去，企业要构建一套 AI 应用，往往需要连接数据库、计算引擎、机器学习框架和各种业务系统。数据在不同系统之间流转，接口和任务调度越来越复杂，数据安全、计算效率与运维成本也随之成为新的负担。如果数据库能够在提供高性能数据服务的同时，直接承担更多分析与模型计算任务，那么数据平台与 AI 应用之间的距离就有机会进一步缩短。这也是我理解 DolphinDB 技术演进方向的一个切入点。金融机构的数据问题，很多时候并不在于数据查不到，而在于同一个业务概念可能存在不同定义，同一个指标可能有多种计算口径。即使 AI 能够生成 SQL，如果它没有真正理解业务对象、指标含义，生成的结果也未必可用。FinOnto 尝试解决的正是这个问题。它将基金、股票、期货等金融业务对象，以及对象之间的属性和关系，组织成统一的业务语义体系。现场展示的方案覆盖六大业务域、70 余个科目和近 600 个指标。六大业务域 · 70+ 科目 · 近 600 指标在这个基础上，用户可以通过自然语言提出问题，系统再根据业务语义识别相关对象和指标，生成执行计划，并将计算任务交给底层引擎完成。这里真正有价值的，并不是让 AI 学会写 SQL，而是让 AI 在明确的业务语义和规则约束下使用数据，而不是凭自己的理解猜测数据。这种设计也有助于减少 AI 应用中常见的几个问题：指标口径不一致、生成的查询不符合业务要求，以及直接暴露底层数据库结构带来的安全风险。配合参数白名单、权限控制和全链路审计，AI 的行为边界是可控的。现场还展示了通过 MCP 等开放协议向外部 Agent 提供标准化工具的能力。这意味着数据库平台不仅可以服务于自己的应用，也有机会成为企业级 Agent 调用数据和执行分析任务的基础设施。量化研究本身就是一个复杂的工程流程，涉及数据准备、因子计算、策略开发、回测、仿真和结果分析。传统方式下，这些环节往往分散在不同的工具和框架中，研究人员需要花费大量时间处理数据、编写代码和打通流程。Quant Cloud 尝试将 AI 引入整个研究流程：研究人员用自然语言描述目标，由 AI 协助拆解任务、生成代码并推进执行；底层则通过因子计算、事件驱动回测和仿真等引擎，支撑策略验证。订单簿、高频回测等金融专用引擎，到面向深度学习的数据加载能力，再到 Coding Agent 和 Web 控制台。AI 能够参与流程，并不意味着可以完全替代研究人员。量化研究涉及复杂的金融假设、模型风险和策略验证，研究过程能否被观察、关键环节能否由人介入，仍然十分重要。展区里的客户名单同样令人印象深刻：国泰海通、中信证券、华泰证券、招商证券、易方达、招商银行、国家电网、中国航天等机构的名字，说明 DolphinDB 已经进入金融、能源和工业等多个领域的核心场景。对于数据库这样的基础软件而言，技术参数固然重要，但能否在复杂业务环境中长期稳定运行，能否真正融入客户的核心系统，往往更能检验产品的成熟度。我正在撰写的《DBA新思维》第五章，专门讨论国内主流数据库的 AI 特性，其中一节研究的就是 DolphinDB 的库内机器学习。这次现场交流，也让我对这一技术路线有了更直观的认识。所谓库内机器学习，简单来说，就是尽可能让数据留在数据库中，直接利用数据库内部的计算能力完成模型训练、预测和分析，而不是先把数据导出，再交给外部计算框架处理。DolphinDB 从 2.0 版本起便提供了多种内置机器学习算法，包括随机森林分类、普通最小二乘回归、K-Means 聚类和 ARIMA 时间序列预测等。▸ 利用 K-Means 聚类分析不同客户群体的流失特征这些案例虽然是基于模拟数据的演示，但能够清楚地说明库内机器学习的基本思路：数据不必为了建模而反复迁移，模型计算可以尽可能靠近数据完成。对于海量数据，跨系统传输本身就可能产生不小的开销。如果数据能够直接在数据库内部参与计算，就可以减少不必要的数据复制和传输。金融数据往往具有较高的敏感性，减少数据在不同系统之间的流转，有助于缩小数据暴露面，也更便于统一管理数据访问权限。当然，库内计算并不意味着所有模型都应该在数据库中完成。对于复杂的深度学习任务，外部专业框架仍然具有重要价值。真正合理的架构，不是简单地用数据库替代所有计算框架，而是根据任务特点做出选择。因此，我更愿意把库内机器学习看作数据库能力的一次自然延伸：数据库不仅负责保存和查询数据，也开始承担更多直接面向业务的计算任务。现场关于「自然语言即代码」的展示，则让我联想到另一个正在快速发展的方向：如何让 AI 更可靠地使用数据库。通过 Skill 为模型提供业务语义、工具规范和执行约束，再由系统生成脚本并在受控环境中执行，能够让自然语言与实际计算之间形成更清晰的衔接。这与我对 NL2SQL 落地的观察是一致的。自然语言转 SQL，看起来只是让大模型生成一段查询语句，真正落地却远没有这么简单。业务口径是否正确、用户是否有权访问相关数据、生成的脚本能否被审计，每一条都是工程问题。相比直接让大模型自由生成并执行 SQL，让 AI 理解业务语义、调用受控工具，并在明确的安全边界内完成任务，才更接近企业级应用所需要的工程化方案。这也是数据库与 AI 融合过程中，我认为特别值得关注的一点：技术的进步不仅要让 AI 更聪明，还要让它的行为更可控、结果更可信。这次活动中，还有一个细节让我颇有感触：金融客户亲自分享了使用体验。对于金融机构而言，数据库往往处于业务系统的底层，涉及核心数据、交易流程和生产稳定性。选择一家数据库厂商，不只是选择一项技术，更意味着长期的系统建设与合作。因此，客户公开分享真实的使用体验，本身就是一种很重的表态。现场的用户代表不仅肯定了 DolphinDB 在实际业务中的价值，也坦诚提出了对后续功能和产品特性的期待。在我看来，这种反馈尤其值得重视。产品进入生产环境，只是一个开始；能够在真实业务中持续发挥作用，并在客户不断变化的需求中持续演进，才是产品长期生命力的体现。客户愿意提出具体要求，说明双方的合作已经不再停留于一次性的产品交付，而是进入了共同打磨产品、推动业务发展的阶段。相比一张张奖状或一份份技术参数，这些来自真实用户的反馈，往往更能说明一款基础软件的价值。一天的交流下来，我最大的感受是：数据库与 AI 的融合，已经不只是概念层面的讨论，而是在逐渐形成可以落地的技术路径。01 数据留在合适的位置，模型尽可能靠近数据运行
02 业务语义得到统一管理，AI 的数据访问和工具调用受到约束
03 专业计算引擎支撑复杂任务，研究人员和业务人员保留必要的判断与控制权这些看似分散的能力，实际上指向同一个目标：降低从数据到智能应用的工程复杂度，让 AI 真正进入企业的核心业务流程。从这个角度看，DolphinDB 的发展值得关注。它正在尝试将高性能数据管理、实时计算、库内机器学习、金融业务语义和 Agent 能力连接起来，探索数据库在 AI 时代可以扮演的新角色。当然，一套技术体系是否真正成熟，最终仍要接受长期生产实践的检验。但至少从这次活动展示的方向来看，数据库厂商正在重新思考自己的边界：不再只关注如何更快地存储和查询数据，也开始思考如何让数据更容易被智能应用使用。作为一名长期与数据库打交道的架构师，我很乐见国产数据库在 AI 时代进行这样的探索。这不仅是一个技术理念，也是在数据治理、计算效率
和 AI 工程化之间寻找平衡的一种思路而这次在浦东的现场交流，让我看到了这条路正在逐步走向现实。
薛晓刚约 8 分钟