企业官网建设流程全解析

1. To B项目的Data+AI，为什么总卡在数据这一层

1.1 模型好选，数据难喂

我这两年跑了小二十个To B的Data+AI项目，一个特别明显的感受是：模型选型从来不是瓶颈，GPT类大模型、开源小模型、行业微调，方案一大把，算力也能租，真正让项目卡住不动的地方，全在数据这一层。

C端互联网的AI应用，数据通常是海量、同构、格式干净的，模型只要喂得够多就能出效果。To B完全不是这个逻辑。一个年产值几十亿的制造企业，数据分布在ERP、MES、SCADA、设备点检系统、OA、邮件、PDF工单里，光"把同一台设备的数据对齐"就能干上两个月。设备振动传感器记录的毫秒级采样，DCS（分布式控制系统）里存的温度压力曲线，ERP里的工单状态，MES里的批次追溯记录，甚至是老师傅手写在点检本上的异常描述——这些数据的数据模型、时间粒度、质量水平、更新频率完全不同。

我记得有一次跟某装备制造企业的IT负责人聊预测性维护项目，他上来就说了一句话让我印象很深："模型你们随便选，但你们得先告诉我，这些数据到底能不能凑齐、能不能对齐、能不能信。"这句话基本概括了To B Data+AI的困境：模型是显性的难题，数据是隐性的深坑。

1.2 数据库厂商为什么在这个环节变得重要

过去做数据分析项目，数据库厂商的角色很简单——提供存储和计算引擎，上面跑BI报表，出一张看板就完工。但AI落地把数据的使用方式彻底改变了。

传统BI的链路是：业务系统 → 数据仓库 → ETL加工 → 固定报表 → 人看。AI的链路变成了：业务数据 → 数据底座 → 特征工程/向量化 → 模型训练或推理 → 应用系统自动响应。这个变化看起来只是多了"特征工程"和"向量化"两步，实际上对整个数据基础设施提出了完全不同的要求。

数据不再只是给人看的，还要给机器"读"。机器读数据的方式和人完全不同：人要的是聚合汇总，机器要的是原始明细加语义关联；人要的是月度趋势图，机器要的是实时特征向量；人看报表可以容忍T+1延迟，AI实时风控、智能质检、在线推荐全部要求秒级响应。

这就引出了南大通用这类老牌数据库厂商在Data+AI时代的位置问题。GBase系列产品矩阵（面向分析场景的8a MPP、面向交易场景的8s、面向分布式云化场景的8c）在国内政企、金融、能源等行业有大量存量部署。这些客户要发展AI能力，不可能把原来的数据底座推倒重来，更现实的做法是在已有数据库基础上长出AI能力。

南大通用路线图里反复强调的"Data+AI 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 湖仓不是又建一个仓库

Data+AI对数据量的需求远超传统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项目里是刚需。

这就是Data+AI场景下的"数据治理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辅助数据库自治运维

Data+AI对数据库厂商的意义不只是"让数据库多存一种数据"，更深远的变化是AI开始反向重塑数据库本身。这个趋势里最先落地的一定是AI辅助的自治运维。

我见过不少企业的DBA团队，日常工作中很大一部分精力消耗在慢SQL优化、索引调优、参数配置这些事务上。这些工作本质上高度模式化——分析执行计划、找全表扫描、看索引失效原因、调整并行度。过去的做法是DBA凭经验判断，现在完全可以由AI模型基于历史诊断数据自动给出建议，甚至是自动执行。

数据库厂商做这件事有天然优势：慢SQL日志、执行计划、系统指标、历史优化案例，这些数据全部在数据库内部产生，数据获取不需要额外集成，优化效果也能在系统内闭环验证。这类能力就是"AI重塑数据库"的第一阶段——先用AI把数据库本身的运维成本降下来。对南大通用这类国产数据库来说，这一步还能直接提升存量客户的粘性和口碑。

5.2 未来形态：数据库变成"数据智能底座"

再往后看，数据库在Data+AI To B场景里的终局形态，我倾向于认为是"数据智能底座"——不只提供存储和计算，还提供特征存储、模型注册、在线推理服务，让AI应用的能力以数据库为圆心向外生长。

这个判断的依据是To B客户的真实采购心理。这些年我在客户现场感受到一个非常明显的倾向：企业IT团队极不愿意为一个AI项目配置一套全新的、独立的技术栈。因为独立技术栈意味着新的运维团队、新的安全评估、新的故障责任边界，在企业复杂的IT治理环境里，这些隐性成本往往是AI项目无法落地的主要原因。

客户更愿意接受的方式是：在已有的数据平台上"长出"AI能力，能在GBase里完成的事就不要另起炉灶。所以数据库厂商的Data+AI路线图，与其说是技术演进，不如说是顺应客户"最小化变更"的诉求——把AI能力封装成数据库能力的自然延伸。

现在GBase系列产品矩阵已经覆盖了交易、分析、分布式等主流数据库场景，在这些场景之上逐步叠加向量检索、特征存储、AI推理函数，用户就可以用一套数据底座同时支撑传统业务和AI应用。这个演进路径一旦走通，国内To B市场的Data+AI落地速度会明显加快。

我在多个项目里最深的体会是： To B的AI项目不要一开始就铺很大，选一条高价值短链路先跑通。拿数据库这条路来说，先做一个知识库问答或一个经营分析助手，两个月内让业务部门看到效果，再逐步扩大数据范围和应用场景。数据底座的建设跟着AI场景走，不要超前建设，也不要落后需求太多——这个节奏把握好了，Data+AI项目才真正能在企业里扎根，而不是停留在演示稿里。