1. To B项目的DataAI为什么总卡在数据这一层1.1 模型好选数据难喂我这两年跑了小二十个To B的DataAI项目一个特别明显的感受是模型选型从来不是瓶颈GPT类大模型、开源小模型、行业微调方案一大把算力也能租真正让项目卡住不动的地方全在数据这一层。C端互联网的AI应用数据通常是海量、同构、格式干净的模型只要喂得够多就能出效果。To B完全不是这个逻辑。一个年产值几十亿的制造企业数据分布在ERP、MES、SCADA、设备点检系统、OA、邮件、PDF工单里光把同一台设备的数据对齐就能干上两个月。设备振动传感器记录的毫秒级采样DCS分布式控制系统里存的温度压力曲线ERP里的工单状态MES里的批次追溯记录甚至是老师傅手写在点检本上的异常描述——这些数据的数据模型、时间粒度、质量水平、更新频率完全不同。我记得有一次跟某装备制造企业的IT负责人聊预测性维护项目他上来就说了一句话让我印象很深模型你们随便选但你们得先告诉我这些数据到底能不能凑齐、能不能对齐、能不能信。这句话基本概括了To B DataAI的困境模型是显性的难题数据是隐性的深坑。1.2 数据库厂商为什么在这个环节变得重要过去做数据分析项目数据库厂商的角色很简单——提供存储和计算引擎上面跑BI报表出一张看板就完工。但AI落地把数据的使用方式彻底改变了。传统BI的链路是业务系统 → 数据仓库 → ETL加工 → 固定报表 → 人看。AI的链路变成了业务数据 → 数据底座 → 特征工程/向量化 → 模型训练或推理 → 应用系统自动响应。这个变化看起来只是多了特征工程和向量化两步实际上对整个数据基础设施提出了完全不同的要求。数据不再只是给人看的还要给机器读。机器读数据的方式和人完全不同人要的是聚合汇总机器要的是原始明细加语义关联人要的是月度趋势图机器要的是实时特征向量人看报表可以容忍T1延迟AI实时风控、智能质检、在线推荐全部要求秒级响应。这就引出了南大通用这类老牌数据库厂商在DataAI时代的位置问题。GBase系列产品矩阵面向分析场景的8a MPP、面向交易场景的8s、面向分布式云化场景的8c在国内政企、金融、能源等行业有大量存量部署。这些客户要发展AI能力不可能把原来的数据底座推倒重来更现实的做法是在已有数据库基础上长出AI能力。南大通用路线图里反复强调的DataAI To B场景落地本质上就是在回答一个问题数据库厂商如何把自己从存储引擎升级为智能数据底座。这不是BI的升级版而是一次基础设施层面的重构。2. 向量检索能力下沉把语义搜索做进数据库2.1 关系型数据库怎么处理语义To B场景里有一类需求增长特别快——知识库问答。设备维修手册、历史故障工单、客服话术、招投标文件、合同条款这些非结构化文档过去躺在文件服务器里检索基本靠关键词搜轴承温度过高永远匹配不出轴瓦烧毁原因分析这类语义相关的文档。解决语义检索的标准做法是做embedding向量化把文本切成片段通过模型转成几百维的浮点向量存进向量数据库查询时用余弦距离或内积找最相似的片段。这个技术栈本身已经比较成熟但To B落地时有个很尴尬的问题——向量数据孤岛。业务数据在关系型数据库里权限体系、事务一致性、备份容灾都在那边向量数据单独放在一个向量库里两边各管各的业务数据发生了变更向量库里对应的片段不会自动同步。两个系统的权限模型还不一样安全审计要同时查两套日志。我在一个电力行业的售前项目里遇到过真实案例客户要做企业制度问答系统制度文件存在OA系统里向量库单独部署制度文件更新后向量库没人同步员工问出来的答案永远是过期版本。对比来看传统BI是数据仓库管数据、报表工具出图数据库其实不直接面向业务用户而知识库问答是AI应用直接面向一线员工数据一旦不同步错误会被放大后直接呈现在用户面前口碑影响非常直接。2.2 落地路线SQL里跑向量检索要解决这个问题最合理的技术路线不是把向量库并进来而是让数据库本身具备向量检索能力。具体来说就是在关系型数据库里增加向量数据类型和向量索引让SQL可以直接执行相似度检索。用SQL风格来表达就是-- 示例检索与轴承温度过高语义最接近的5条维修记录 SELECT doc_id, doc_title, chunk_text, vec_col - query_vector AS distance FROM maintenance_knowledge ORDER BY distance ASC LIMIT 5;这里-表示向量距离算子query_vector是用户查询经过embedding模型转换后的向量。和独立向量库相比这种实现方式有几个非常实在的好处第一权限体系不用重建。现在GBase数据库里已有的行列级权限、审计日志、数据脱敏规则对向量列天然生效。AI应用不会成为绕过安全管控的后门。第二事务一致性有保障。文档更新、向量更新、索引刷新可以在同一个事务里完成数据永远是一致的不会出现上面说的制度文件更新了但向量还是旧的。第三运维体系平移。备份、容灾、扩容、监控全部走现成数据库工具链企业IT团队不需要重新学一套新系统的运维。从公开的路线图信号和行业实践来看GBase这类的MPP分析型产品在向量化上更有优势——列存引擎天然适合向量数据的高吞吐扫描分布式架构可以并行做向量分片检索。比较现实的落地路径是分析型场景先支持向量列和向量索引事务型场景通过旁路同步先把能力用起来后续版本逐步融合。我在跟客户交流时经常说一句话不要把向量数据库当成一个独立系统数据双写是噩梦。文档进业务系统一次再进向量库一次两边结构不一样、更新时机不一样出问题是迟早的事。成熟的路线一定是业务数据在哪向量向量就长在哪。2.3 一个关键参数向量检索的召回质量向量检索不是能搜就行落地时最需要盯的是召回质量。我见过不少项目上线后效果很差问题基本出在三个地方切片粒度不合理。文档按固定长度切语义边界被切断检索出来的片段答非所问。阈值设得不对。距离阈值太严什么都召回不了太松召回的是一堆噪音。没有做混合检索。纯向量检索对数字、型号、编号这类精确信息不敏感查询型号为XG-2000的备件这种问题向量检索往往不如关键词精确匹配。实际项目里的解法一般是混合召回向量检索和BM25关键词检索并行然后做rerank融合。数据库层面的向量能力解决的是语义召回这半边另一半还得在应用层配合。这个坑我建议所有做知识库问答团队都要提前踩。3. 湖仓一体与数据治理AI能吃到的数据从哪来3.1 湖仓不是又建一个仓库DataAI对数据量的需求远超传统BI很多To B客户上来就想建数据湖把全量数据先存起来再说。这个思路在做BI时代是对的因为BI分析范围会不断变化数据先存不亏。但在AI时代数据成本压力会大得多——原始数据全量入湖、全量治理、全量打标做一半发现核心AI场景只需要其中20%的数据剩下80%成了纯成本。湖仓一体的思路和传统数仓最大的区别是它不是为了先建一个仓库再想用途而是围绕AI场景反推数据需求。湖保存原始数据成本低、格式灵活仓提供治理后的数据服务结构清晰、质量可控中间通过一套元数据和数据管理能力打通。南大通用这类厂商在湖仓一体里的角色我理解不是为了卖一个湖仓一体平台的新包装而是把原有MPP分析引擎的存储计算能力向外延伸兼容更多数据格式同时强化与数据湖中对象存储的协同。3.2 元数据与血缘AI的可信基础To B和C端还有一个本质区别To B的AI输出结果要负责任。银行贷款审批辅助、设备故障预测、医疗影像筛查这些场景里模型给出的每一个预测都必须能追回去——基于哪些样本训练的、命中哪些特征、用了哪个版本的模型。我在和金融客户交流时对方反复强调一个词可解释性。这个可解释性不只是模型的shap值更包括数据层面的血缘关系。这条预测结论依据的是哪个时间段的数据数据是哪个系统来的中间经过了怎样的加工这些信息在C端AI场景里没人关心但在To B项目里是刚需。这就是DataAI场景下的数据治理2.0——不只是管数据质量还要管特征、样本、标注、模型版本。具体到基础设施层面需要的关系型能力包括特征注册与特征版本管理模型上线用的特征和训练时的特征必须完全一致样本和标注版本管理标注变更后模型效果对比要有据可查实验追踪每一次模型训练的数据集、参数、结果都要留存。这些能力不一定要求数据库全部实现但数据库作为存储底座需要提供足够灵活的数据模型来承载这些元数据同时通过事务能力保证版本切换的一致性。给AI应用提供可信数据比提供海量数据重要得多。4. Agent化应用落地OLTP与OLAP混合负载是真实考验4.1 Agent不是聊天机器人进入2024年下半年之后To B市场对AI的应用预期从智能问答转向了Agent也就是让AI不只是回答问题还要能调系统、办事情。典型的例子是经营分析助手业务人员问华东区上个季度哪些客户的订单交付延迟超过5天Agent需要先理解这句话然后把它转换成SQL到数据仓库里查数据再对结果做归因分析最后用自然语言生成结论。这里面数据库侧要扛的担子比传统BI重得多。Text2SQL这条技术路线业界已经踩了不少坑我总结下来数据库侧需要支撑的关键点至少有三个第一Schema感知。Agent要生成正确的SQL需要理解数据库的表结构、字段含义、枚举值分布。这意味着数据库的元数据管理必须对外开放让Agent能拿到足够详细的表结构描述。第二样例召回。很多Text2SQL模型在生成SQL时需要参考类似的问题-SQL对作为少样本示例。数据库里沉淀的历史查询语句本身就是最好的训练素材。那些跑得慢的、被DBA优化的SQL经过整理后可以变成Agent的参照样例。第三执行计划校验。Agent生成的SQL可能有语法正确但执行代价极高的情况——比如漏了时间分区条件全表扫描几亿行。数据库需要在执行前做代价评估发现异常就拦截回退而不是傻傻地跑几分钟。4.2 资源隔离与弹性MPP的机遇和挑战Agent应用会给数据库带来混合负载压力这是过去To B系统很少遇到的问题。过去OLTP系统跑交易OLAP系统跑报表数据库各司其职。但Agent应用是先查后算再答一条用户请求会拆成多轮数据库交互既有短小精确的查询改一下where条件也有重量级的聚合分析算一个季度的维度汇总。在这种负载下传统MPP分析型数据库会暴露一个短板大查询跑得好但小查询的响应时延不够稳定。我见过不止一次Agent在前面等数据返回数据库因为正在跑一个耗时十分钟的生成任务把Agent的小查询堵在后面排队。解决思路不外乎几条读写分离分析任务走只读副本资源组隔离划分不同的并发和内存配额结果集缓存把高频查询结果缓存起来直接返回。或者更进一步——把Agent生成的高频SQL做模式识别自动创建物化视图把每次实时聚合变成增量更新后直接查结果。这条路对MPP架构来说其实是新的增长机会因为这类自动化调优能力一旦产品化会让Agent应用在To B环境里的可用性大幅提升。我在评估数据库产品对Agent的支撑能力时通常建议客户做三类测试一是短查询并发测试模拟Agent中高频的快查询二是长短查询混合测试看资源隔离是否真的有效三是会话级超时控制确认慢查询不会拖垮整体响应。这三个测试过了Agent应用上生产的把握会大很多。5. 路线图的下半场从数据库支持AI到AI重塑数据库5.1 AI辅助数据库自治运维DataAI对数据库厂商的意义不只是让数据库多存一种数据更深远的变化是AI开始反向重塑数据库本身。这个趋势里最先落地的一定是AI辅助的自治运维。我见过不少企业的DBA团队日常工作中很大一部分精力消耗在慢SQL优化、索引调优、参数配置这些事务上。这些工作本质上高度模式化——分析执行计划、找全表扫描、看索引失效原因、调整并行度。过去的做法是DBA凭经验判断现在完全可以由AI模型基于历史诊断数据自动给出建议甚至是自动执行。数据库厂商做这件事有天然优势慢SQL日志、执行计划、系统指标、历史优化案例这些数据全部在数据库内部产生数据获取不需要额外集成优化效果也能在系统内闭环验证。这类能力就是AI重塑数据库的第一阶段——先用AI把数据库本身的运维成本降下来。对南大通用这类国产数据库来说这一步还能直接提升存量客户的粘性和口碑。5.2 未来形态数据库变成数据智能底座再往后看数据库在DataAI To B场景里的终局形态我倾向于认为是数据智能底座——不只提供存储和计算还提供特征存储、模型注册、在线推理服务让AI应用的能力以数据库为圆心向外生长。这个判断的依据是To B客户的真实采购心理。这些年我在客户现场感受到一个非常明显的倾向企业IT团队极不愿意为一个AI项目配置一套全新的、独立的技术栈。因为独立技术栈意味着新的运维团队、新的安全评估、新的故障责任边界在企业复杂的IT治理环境里这些隐性成本往往是AI项目无法落地的主要原因。客户更愿意接受的方式是在已有的数据平台上长出AI能力能在GBase里完成的事就不要另起炉灶。所以数据库厂商的DataAI路线图与其说是技术演进不如说是顺应客户最小化变更的诉求——把AI能力封装成数据库能力的自然延伸。现在GBase系列产品矩阵已经覆盖了交易、分析、分布式等主流数据库场景在这些场景之上逐步叠加向量检索、特征存储、AI推理函数用户就可以用一套数据底座同时支撑传统业务和AI应用。这个演进路径一旦走通国内To B市场的DataAI落地速度会明显加快。我在多个项目里最深的体会是 To B的AI项目不要一开始就铺很大选一条高价值短链路先跑通。拿数据库这条路来说先做一个知识库问答或一个经营分析助手两个月内让业务部门看到效果再逐步扩大数据范围和应用场景。数据底座的建设跟着AI场景走不要超前建设也不要落后需求太多——这个节奏把握好了DataAI项目才真正能在企业里扎根而不是停留在演示稿里。