企业官网建设流程全解析

AllData 数据中台搭了大半年，元数据盘清楚了，数据地图上线了，数仓分层也规规矩矩了，可业务同事提数还是习惯把需求打在聊天窗口里，数据团队的日常基本被临时SQL和口径解释占满。这套组合调完以后，我的感受特别直接：数据中台本身解决的是"数据能被管起来"的问题，而 DB-GPT 这类开源项目解决的是"数据能像资产一样被人问起来"的问题。把 AllData 和 DB-GPT 集成到一起，目标就是标题里那句——构建一个能理解多类型数据资产、支持自然语言交互的 AI 多模态数据库，让业务用大白话问数，让数据团队从重复取数里腾出手。这篇文章是这次集成从选型到落地再到调优的完整复盘，适合手里已经有一版中台、正琢磨怎么把大模型能力接进去的团队参考。

1. AllData 与 DB-GPT 的集成动机：数据中台不能只是个"数据仓库"

1.1 "资产盘得清"和"业务看得懂"之间隔着一条鸿沟

大部分中台项目做到第二年都会遇到同一个尴尬：资产目录里几千张表、几万个字段，数据质量规则也配了，查看热度也做了，可业务方打开数据地图不知道该搜什么词，搜到表也看不懂字段含义。最后业务还是找数据团队要数，数据团队还是得打开 IDE 写 SQL。

这个鸿沟的本质是语言不一致。业务方的提问习惯是"上个月高价值用户的复购率怎么样"，这是一个包含了指标口径、时间范围、维度限定、甚至隐含过滤条件的完整需求；而数据中台里存的是物理表、字段、分区和 SQL。从自然语言到准确SQL之间，需要有人理解每张表是什么业务、每个字段怎么取数、同名字段在不同表里是不是一个口径。中台把元数据管起来了，但"元数据被人读懂"这一步，过去全靠在人肉完成。

DB-GPT 接入后，这个翻译环节可以被大模型自动化。但我们很快发现一个关键点：模型再聪明，也没有读过你的数仓规范、你的表注释、你的指标口径。所以真正的工作量不在"接入模型"，而在于把中台里的元数据、血缘、生命周期信息，改造成模型能检索和理解的语义知识库。这也是后面第4章我花篇幅重点讲冷热数据和归档表的原因——这是整个 AI 问数过程中最容易被忽略、也最容易翻车的地方。

1.2 为什么是 DB-GPT 而不是从零自研模型应用层

团队一开始也讨论过自研：反正模型 API 都有了，自己写个 RAG、写个 Text2SQL 不就行了？真做起来才发现，从零自研的成本被严重低估。Text2SQL 要处理的问题不只是"把问题转成 SQL"，还包括：识别用户指代的时间范围、处理同义词、区分多表 join 路径、防止模型生成危险 SQL、对结果做解释。这些每个都是独立的工程。

DB-GPT 把这条链路做成了一个可扩展的框架。它自带多模型接入层，既能接 OpenAI 兼容接口，也能接本地部署的开源模型；RAG 知识库部分帮你处理了文档切分、向量化、检索；Text2SQL 部分通过提示词模板和样例管理让你可以不断优化生成质量；Agent 和 AWEL 工作流编排则让我们能把"查元数据 → 生成候选SQL → 执行 → 解释结果"串成一个可观测的流程。对 AllData 来说，我们不缺数据管理能力，缺的正是这一层语义理解和对话编排能力。

换句话说，AllData 管好数据和元数据，DB-GPT 负责让 AI 读懂这些数据，两者合在一起，才可能形成一个真正可用的"AI 多模态数据库"。

2. 选型之前先看边界：各自解决了什么问题

2.1 AllData 在中台侧能提供什么

AllData 本身是一套覆盖面很广的开源数据中台，核心围绕数据集成、数据开发、数据质量、数据服务等模块展开。它不是一个简单的 BI 工具，而是偏"数据基础设施"的定位。对我们集成方来说，最有价值的是它沉淀下来的三类资产：

• 元数据资产：表/字段注释、数据源信息、分区信息、血缘关系。这是后面语义知识库的原料。
• 数据质量结果：质量规则、告警记录、校验结论。AI 在回答时可以把"该表当前质量是否可靠"作为参考信号，避免把脏数据当结论推给业务。
• 数据服务能力：中台上往往已有统一查询入口和权限控制。AI 生成的 SQL 应该走既有数据服务层，而不是另开一条绕过权限的通道。

这里也想提醒一点：AllData 部署本身是有成本的，如果团队目前连元数据采集都没做好、表注释一片空白，那直接上 DB-GPT 效果会很差，因为喂给模型的语料本身就是空的。集成前务必先把元数据补全这件事当成前置条件。

2.2 DB-GPT 在 AI 侧的能力边界

DB-GPT 现在的能力版图基本围绕"AI 原生数据应用"展开，对我们这个项目来说主要用到四块：

• Text2SQL：把自然语言问题转换成可执行 SQL。它支持配置数据源连接，也支持在提示词中注入表结构信息和业务样本。
• RAG 知识库：把非结构化文档（指标说明、数据字典、周报口径）切片后做向量化存储和检索，让模型回答问题前先拿到相关知识片断。
• 多模型与多模态接入：底层可接多种开源/商用模型，上层统一了接口；新版本在多模态上支持图文混合输入，比如用户上传一张报表截图直接提问。
• Agent 与工作流：通过 Agent 插件和 AWEL 编排，我们可以自定义"先查知识库、再生成 SQL、再执行、再总结"的完整链路，而不是停留在单轮问答。

边界也很清楚：DB-GPT 不是一个数据治理平台，它不会主动帮你修元数据、不会生成统一指标口径、更不会替代中台做权限审计。它默认信任你给的 schema 信息，如果你给它一份注释缺失、表名混乱的 schema，它生成 SQL 的准确率会明显下降。所以"中台做治理、DB-GPT 做理解"是分工前提。

2.3 为什么这个组合能省掉一大半自研成本

做完选型评估我们算过一笔账：如果要自研一个同等能力的"元数据语义化 + 企业知识库 + Text2SQL + 多轮对话"系统，纯后端工程保守估计是 3 个人力投入半年以上，还不包括模型调优。而基于 AllData + DB-GPT 二次开发，核心工作量会压缩到三块：元数据加工与同步、提示词和知识库内容设计、以及权限和安全机制的嵌入。这三块恰好是业务相关的部分，必须要自己团队做，而通用技术部分开源项目已经替你踩过很多坑了。

反过来说，这个组合也不是万能的。如果组织内连最基础的数仓分层都没理顺，如果指标口径全靠人脑记忆，那 AI 问数一样会给出"一本正经的错误答案"。工具能放大数据基础的水平，但没法凭空变出数据基础。

3. 集成架构拆解：元数据、知识库、Agent 三层联动

3.1 整体分层与数据流转链路

我们最终落地的架构从逻辑上拆成了四层，核心思路是"每一层只管一件事，层与层之间用标准接口对话"：

• 中台基础层：AllData 负责数据源管理、数仓表、元数据采集、数据质量、权限认证。这一层是事实来源，所有最终要执行的 SQL 都要回到这里。
• 语义知识层：把 AllData 的元数据、表注释、字段枚举、指标口径文档、常用SQL样本同步到 DB-GPT 的向量知识库和样本库。这一层承担"让模型了解业务"的职责。
• 推理编排层：DB-GPT 的 Agent 收到用户问题后，先做意图识别，检索语义知识层，拼接提示词，调用大模型生成候选SQL，再通过校验后交给执行层。
• 执行与反馈层：执行 SQL（带 LIMIT/超时/权限过滤），把结果集返回，由模型生成文字结论和可视化图表，并在回复中附带"用了哪些表、基于什么SQL"的溯源信息。

这里我想强调一下数据流转的关键点：用户的问题不是直接丢给大模型就完了，而是先经过知识检索。比如用户问"最近30天高价值用户流失率"，Agent 会先在知识库里检索"高价值用户"的定义口径、"流失率"在哪个指标的说明文档、对应的事实表是哪一张，然后把检索结果作为上下文一起交给模型生成 SQL。这个"先检索再生成"的顺序直接决定准确率，省不得。

3.2 多模态数据资产的统一建模与存储设计

标题里提到"多模态数据库"，落到工程上并不玄乎。我们把中台里涉及的数据资产分成三类处理：

• 结构化数据：仍然由数仓表承载，例如订单表、用户表、风控记录表。这部分是 SQL 查询的主力。
• 半结构化与非结构化文档：指标口径说明、数据字典、业务规则、历史分析报告、甚至周会纪要中涉及数据的描述。这些文本被切分、向量化后进了向量库，是 RAG 的语料。
• 图片与图表：业务伙伴经常直接甩一张截图过来问"这个数怎么对不上"。我们做了两个方向：一是让系统支持图片识别，从截图里提取指标和数值；二是对查询结果自动生成图表，再结合图表做解释。

存储上，结构化数据继续留在 AllData 对应的数据源里；向量化的知识片断放进 DB-GPT 默认支持的向量数据库；图片类资产我们更多是"即时理解"而不是海量存储，所以重点放在对话链路中引入多模态模型的视觉能力，而不是把图片全都入库。

3.3 模型接入：本地部署还是 API 调用

关于模型选型，我们的结论是：敏感数据场景尽量本地化，通用场景可以用 API 兜底。数据中台里的很多表涉及用户隐私和经营数据，直接把这些数据传到外部 API 服务会带来合规风险。但是本地部署对机器要求不低，一个 7B~14B 量级的模型至少需要 16GB~32GB 显存或内存，推理速度也会受限制。

我们最后采用的方式是双通道：核心库和敏感库走本地模型（Qwen 系和 ChatGLM 系的对话模型都试过），对整体回答质量要求高、但数据不敏感的辅助场景走更强大的外部模型。DB-GPT 的多模型管理机制让两个通道可以同时存在，并且能按数据源或问题类型做路由。这个设计保证了"体验不差，底线安全"。

4. 让模型真正"读懂"数据资产：从元数据到语义知识库

4.1 冷热数据与归档表：AI 理解中翻车率最高的地方

这是我们踩过最深的坑，必须单独拿出来讲。数据中台里天然存在冷热之分：热数据是最近一年甚至半年的业务明细，查询频繁；冷数据是历史数据，通常被迁移到归档表或者按年/月分区存放。问题在于，业务提问往往包含"去年同期""近三年趋势"这类跨冷热区间的描述，而模型并不知道哪张表是归档表、哪个分区是慢查询重灾区。

举个例子。我们的订单表 orders 存了近三个月数据，历史订单被归档到 orders_archive 表。业务问"今年上半年每月订单量"，如果模型只会无脑 join 宽表，很可能生成一个全表扫描 orders_archive 的 SQL，跑五分钟出不来结果。更隐蔽的情况是归档表字段含义和热表不完全一致，比如 hot 表里 status 是 int 枚举，archive 表里变成了 string 描述，模型按热表习惯写 SQL 直接就错了。

解决思路是"给模型显式的冷热提示"。我们做了三件事：

• 在 AllData 元数据里为归档表、冷分区打上生命周期标签，并把"该表数据量大、建议按分区过滤、避免无谓全扫描"这类提示文本写入表描述。
• 在语义知识库里专门为每一张归档表生成一版"使用指南"，例如：orders_archive 适合查历史聚合，不支持实时明细；查询时务必带时间分区条件。
• 在 Text2SQL 提示词模板中固定加入一条规则：涉及时间范围超过当前热表覆盖周期的，必须检查是否存在对应的归档表或历史分区，并在 SQL 中带齐时间过滤。

做完这三步，模型生成 SQL 的形态明显"懂规矩"了很多。所以如果你也准备做类似集成，请务必将冷热数据识别作为一个专项任务来做，而不是等上线后被慢查询打爆了再补救。

4.2 从表注释到企业级语义知识库的构建过程

语义知识库是整个 AI 理解能力的核心，它的构建远不止"把 AllData 的表注释导出来塞进向量库"这么简单。我们走了四步：

• 元数据清洗与增强：先从 AllData 拉出表名、字段名、注释、分区信息、负责人、最近访问时间。对注释缺失的表，用大模型批量生成候选中文描述，再由数据团队审核修正。注意：审核这步不能省，模型续写的注释会理解错业务，一旦错了还会被 RAG 检索出来反复强化错误。
• 生成表级摘要：对每张表生成一段 200~300 字的"表说明书"，包括表的核心业务含义、常用过滤字段、与其他表的关联关系、适用的查询场景。这段文本是向量检索中最需要命中的内容，质量直接影响准确率。
• 沉淀指标口径和通用查询样本：把业务侧经常问的问题和对应的正确 SQL 整理成问答对，放进 DB-GPT 的样本库。这样模型下次遇到类似问题时，可以参考人类写的标准答案格式。
• 定期同步：中台表结构调整是常态，我们写了一个定时任务，每天晚上从 AllData 增量同步元数据变化触发知识库更新。否则模型记住的表结构是上周的，业务问新字段它压根不知道。

整个构建过程看起来繁琐，但它是决定 AI 问数能否从"能聊"变成"能信"的分水岭。前期哪怕是人工多花一点时间整理口径，后期都会直接反映在回答准确率上。

4.3 Text2SQL 提示词模板与样本设计

Text2SQL 不是开箱即用的基础能力，它极度依赖提示词设计。我们经过十几轮调整，最终固定下来的提示词结构大致是这个样子（示意）：

你是企业数据中台的查询助手。请根据已知表结构和业务知识，将用户问题转换为准确、安全的SQL。 约束： 1. 只查询知识库中明确存在的表和字段，禁止猜测不存在的字段名。 2. 所有查询必须带上时间范围条件，禁止无时间过滤的全表聚合。 3. 涉及冷数据、归档表时，优先提示用户并确保SQL使用分区过滤。 4. 聚合查询结果限制在100行以内，避免大结果集。 5. 如果问题含义模糊，请先向用户澄清，禁止自行假设指标口径。 可用表结构： {这里填充检索到的相关表结构信息} 业务知识： {这里填充检索到的指标口径和表使用指南} 用户问题：{用户输入} 请输出SQL和一句中文解释。

这里有几个细节值得展开。第一，"禁止猜测不存在的字段名"这条非常重要，模型幻觉最常见的形式就是编出一个语义上合理的字段；我们在执行前还会做一次字段名校验，把 SQL 中的字段名与中台元数据比对，不存在的直接拦截。第二，时间过滤条件是强制规则，因为中台表普遍很大，缺时间条件轻则慢查询，重则把队列打爆。第三，"模糊问题先澄清"比让模型硬猜更安全，宁可多反问一轮，也不要生成一个"看起来对但口径错误"的 SQL。

样本的设计同样重要。我们按照业务域整理了几十组典型问答对，覆盖了趋势分析、占比计算、TopN 排名、同环比、过滤条件组合这几类高频问题。DB-GPT 会在生成时参考这些样本的写法，模型在"模仿标准答案格式"时稳定得多。

4.4 让模型"看图"：多模态查询的实际会话形态

多模态能力在这个项目里的体验主要落在这几个场景：

• 上传图片提问：业务方不再需要打字描述表格中的异常，直接把一张报表截图发过来，问"这张表里为什么华东区环比下降这么多"。系统会先通过视觉模型读取截图中的指标数值，再联动知识库去数仓里定位可能的原因数据。
• 结果自动图表化：SQL 执行返回后，我们不是只给一张表格，而是根据结果字段类型自动匹配柱状图、折线图或明细表，让模型同时输出一段图表解读。这个交互形态对业务领导汇报特别有用。
• Excel/CSV 混合提问：用户上传一份线下Excel，问"这份清单和中台的客户分层结果匹配度怎么样"，系统需要把 Excel 内容先结构化成临时表，再与数仓表 join 计算。

坦白说，图文混合场景的稳定性是要低于纯文本问数的，因为视觉模型的识别误差会传导到下游。我们的策略是把多模态能力定位为"辅助理解"，而不是"决策依据"，凡是涉及最终口径确认的，系统都会引导用户回到结构化数据验证。

5. 自然语言交互的产品化：权限、溯源与体验

5.1 交互产品怎么设计

对话能力做出来后，最早是直接放在内部网页里给数据团队自测，后来才逐步开放给业务。产品形态上我们坚持三个原则：

• 输入入口要极简：就是一个聊天框，支持文字、图片、文件上传，不做复杂表单。业务同事零成本上手。
• 输出要有依据：每个回答都必须附带"答案来源"。如果是查明细，展示SQL和匹配到的表；如果是知识库解释，展示引用文档。没有溯源的回答一律视为不合格。
• 推荐问题先引导：首页根据当前用户的数据权限和最近热门查询，自动推荐几个问题，比如"本月各区域销售额对比""库存Top10 SKU"。这是提高业务使用意愿的重要手段，因为大多数人面对空白对话框会不知道问什么。

5.2 数据权限怎么隔离

让 AI 执行 SQL 最让人担心的是权限被绕过。我们的实现方式是：AI 生成 SQL 之后并不是直接去数据库执行，而是回到 AllData 的数据服务层，由中台统一鉴权。也就是说，用户能查到什么数据，完全由他在中台里的角色和行级/列级权限决定，模型本身没有任何额外特权。

同时我们做了两层额外保护：

• 敏感字段过滤：在生成 SQL 和展示结果时，对手机号、身份证、银行账号等敏感字段做脱敏或直接隐藏。
• 风险 SQL 拦截：对 DELETE、UPDATE、DROP、DDL 等非查询语句一律拒绝；对全表扫描、超大 join 的语句做超时和资源隔离。

5.3 效果评估与"幻觉"处理

AI 问数类系统不能靠感觉评估。我们建立了一个固定的评测集，包含 100 条常见业务问题，每条标注了正确 SQL 和期望结论，每次改提示词、换模型、调知识库后都会回归跑一遍。用"SQL 完全正确率""表选对但字段有误""结果正确但需人工微调""完全错误"四档来打分。早期文本量少的时候完全正确率只有四成左右，后来随着知识库变厚、提示词约束变强、样本越来越规范，正确率慢慢爬到了七成以上，剩下不少是业务口径本身就不统一导致的。

关于"幻觉"，我的经验是：不要指望模型完全不会幻觉，而是要通过流程设计让幻觉成本变低。具体来说，回答中凡是涉及数值的，必须来自执行 SQL 返回的结果集；模型只能对结果集做"翻译式总结"，不允许生成结果集中没有的数值。这个限制写进提示词之后，绝大多数无中生有的数据问题都消失了。

6. 部署与调优实录：从原型到可交付

6.1 资源规划与版本匹配

先把资源账单摊开说。我们这套方案分两部分资源消耗：AllData 中台沿用原有集群，DB-GPT 这边单独落了服务。DB-GPT 服务端至少需要 8核16GB 起步，如果本地部署 7B 以上对话模型，建议单独一台带 24GB 以上显存的 GPU 机器。我们初期图省事把模型和 DB-GPT 装在同一台机器上，结果模型服务一加载，应用接口响应时间直接飙到十几秒，后来拆开部署才恢复正常。

版本匹配上要注意看 DB-GPT 的 release 说明，不同版本对 Python 版本、向量数据库、模型推理框架的依赖差异很大。建议不要追最新，选一个社区反馈稳定的版本做基线，然后把所有依赖版本 lock 住，避免上线后因依赖升级导致行为漂移。

6.2 Embedding 选型与向量检索调参

语义知识库的检索效果很大程度上取决于 embedding 模型。我们先后对比了通用中英文向量模型和数据领域专门的向量模型，最终选了 bge 系列作为主力，理由是中英文混合的长文本表描述表现稳定，而且支持 512 级别的长文本向量化。embedding 模型未必越大越好，它影响的是检索召回率的下限，真正决定问答质量上限的还是知识库里文本本身写得清不清楚。

向量检索调参我们重点关注两个参数：top_k 和 score 阈值。top_k 太小容易漏掉关键表描述，太大则会把不相关内容混进上下文干扰模型。我们的经验是先调大到 20 观察召回结果，确认质量稳定后再缩回 5~8 的区间。score 阈值用于过滤明显不相关的检索结果，避免模型被无关上下文带偏。

6.3 性能与稳定性：缓存、限流、异步

上线后业务一旦用起来，性能问题就会立刻暴露。我们做了三件很有效的事：

• 查询结果缓存：对相同的自然语言问题在 TTL 时间内直接复用结果，不再重新调用模型和执行SQL。业务上很多问题本质是同一种"高频问题换个说法"，语义向量可以算相似度后直接命中缓存。
• 慢查询隔离：在 AllData 数据服务侧给 AI 生成的查询单独划了资源队列，限制单查询最大返回行数和执行时间，跑太慢就自动提示用户缩小时间范围。
• 异步与流式响应：把"知识检索→SQL生成→执行→总结"变成可观测的异步流程，前端用流式输出让用户先看到"正在检索表结构""正在生成SQL"等阶段进展，体验上比干等十几秒好很多，也方便排查到底卡在哪一步。

6.4 常见坑汇总表

7. 延伸思考：租号平台这类"资产密集 + 冷热分明"的场景值得一试吗

最近看到有讨论在问：游戏租号平台这类业务，要不要搭一个号主 SaaS 管理与资产数据中台？我觉得这个问题和本文的方案放在一起看很有意思。租号平台的"资产"本质上是大量账号，账号同样存在明确的冷热之分：热号是实时可租、价格波动的活跃账号，冷号是长期闲置、无人问津的库存。再加上号主、订单、风控、价格策略这些数据高度分散，如果数据底座没打通，运营很难回答"哪个游戏品类空置率最高""最近一周哪个价格带周转最快"这类问题。

对这种资产密集且冷热分明的场景，我的看法是：不一定要一步到位做全模块的中台，但"轻量数据底座 + AI 问数"的组合值得认真考虑。把账号基础信息、租赁订单、实时上下线状态这些数据汇总成一张或几张核心宽表，再通过 DB-GPT 构建一个运营问答机器人，让运营直接问"按游戏品类统计近7天账号空置率和租金中位数，并列出Top 20的空置账号"，立刻就能获得以前需要数据同学折腾半天的分析结果。这里同样要把冷热账号数据分开打标签、在知识库里写清楚查询建议，防止 AI 把全量历史订单拉出来算实时指标。

从更大的视角看，我认为"中台 + AI 智能体"这套组合会逐步成为数据团队的基础设施标配，但它成功的前提从来不是模型有多强，而是数据资产本身有没有被整理到可以被 AI 理解的程度。冷热数据分层、元数据补全、指标口径沉淀，这些"不性感"的活儿才是整个智能化链路里最值钱的部分。如果你正在规划类似的项目，我的建议是先挑一个业务痛感最强烈的场景、挑一小批表把流程完整跑通，再谈大规模铺开。把第一版的闭环做扎实，后续的扩展会顺利得多。