大数据

AI问数及血缘解释

Posted by

一、整体产品战略（先看这张图）

第一阶段（快变现）
AI 问数 & SQL 助手
    ↓
沉淀元数据 / SQL / 使用行为
    ↓
第二阶段（高壁垒）
数据血缘 & 口径解释 & 影响分析

👉 你不是做 2 个产品，而是在做“一个数据智能平台”的两个阶段。

产品 1（AI 问数）是“现金流引擎”，
产品 3（数据血缘 / 口径解释）是“护城河 + 高价产品”。
👉 它们不是二选一，而是“前后关系”。

二、产品 1 深拆：AI 问数 & SQL 助手（你第一个 MVP）

1️⃣ 核心用户 & 场景（非常重要）

用户画像（精准）

  • 业务 / 产品 / 运营（不会 SQL）
  • 初级数据分析（SQL 不稳）
  • 数据负责人（不想被反复打断）

高频场景

  • “昨天 / 本周 / 同比环比”
  • “为什么这个数变了”
  • “帮我查一下 ×××”

👉 这是每天都会发生的场景，极易付费。

2️⃣ 你这个 AI 问数和 ChatGPT 的本质区别

维度ChatGPT你的产品
数据来源不知道真实数据库
口径瞎猜基于表 & 指标
SQL 风险不管你会拦截
企业信任低高

👉 “可信”本身就是卖点。

3️⃣ MVP 必须有的 3 个能力（不要多）

✅ 能力 1：自然语言 → SQL（强约束）

不是“自由发挥”，而是：

  • 只能用 允许的表
  • 自动加：
    • 时间条件
    • limit
    • explain / dry run
  • 高危 SQL 直接拒绝

📌 你在这里的优势非常大。

✅ 能力 2：SQL 结果解释（给人看的）

输出不只是表，而是：

  • 一句话总结
  • 关键指标变化
  • 异常点提示

👉 老板要的是这个，不是 SQL。

✅ 能力 3：慢 / 危险 SQL 提示

例子：

  • 全表 scan
  • 大表 join
  • where 条件缺失

4️⃣ MVP 架构（你 100% hold 得住）

用户问题
  ↓
问题分类（问数 / 解释 / 明细）
  ↓
RAG（表结构 / 指标定义）
  ↓
SQL 生成（LLM + 规则）
  ↓
SQL 静态校验（你写）
  ↓
执行
  ↓
结果解释（LLM）

👉 LLM 只是中间件，核心逻辑在你这。

三、产品 3 深拆：数据血缘 & 口径解释（你的“杀手锏”）

1️⃣ 这是个什么级别的产品？

说句实话：

这是 BI / 数据治理 / 咨询级别的产品。

很多公司：

  • 有表
  • 有 SQL
  • 但没人说得清数据怎么来的

2️⃣ 用户真正想要的不是“血缘图”

他们真正想问的是：

  • ❓ 这个字段从哪来？
  • ❓ 改了会影响谁？
  • ❓ 这个指标怎么算的？
  • ❓ 为什么数不一致？

👉 血缘图只是中间产物，“解释”才是价值。

3️⃣ 你产品 3 的正确形态（很关键）

❌ 错误方向：

做一个复杂的 DAG 图（没人看）

✅ 正确方向：
“AI 数据解释官”

点一个字段 / 指标：

  • 来源表 & 字段
  • 计算 SQL（简化版）
  • 业务口径说明
  • 影响范围（下游报表）

📌 这是管理层和新人都愿意用的东西。

4️⃣ MVP 的最小切法（别一次做完）

第一版只做 3 件事：

  1. SQL → 字段级血缘
  2. 血缘 → 文字解释
  3. 影响表列表

不要画复杂图。

5️⃣ 技术你已经踩过

  • SQL AST 解析（你做过）
  • 表 / 字段依赖
  • LLM：
    • 把“技术血缘”翻译成“人话”

👉 这是你和普通 AI Builder 的分水岭。

四、两个产品如何“合体”，形成强护城河

非常重要的一步（很多人想不到）

产品 1 = 流量入口
产品 3 = 信任 & 高价

举个真实场景：

  • 用户用 AI 问数
  • 点结果中的某个字段
  • 弹出：

“这个字段怎么算的？点我解释”

👇
进入 产品 3 的能力

👉 这是天然的 upsell。

五、给你一个「现实可执行」的 30 天计划

Day 1–7

  • 只做：AI 问数（单库）
  • 只支持：select
  • 只 1 种数据源

Day 8–14

  • 加 SQL 校验
  • 加结果总结
  • 找 1 个真实用户

Day 15–21

  • 加字段 / 指标定义
  • 开始埋血缘数据

Day 22–30

  • 做字段解释 MVP
  • 做第一个“影响分析”

一、产品 1 的整体 AI 架构（先有全局感）

目标一句话
让 AI 在“被强约束的前提下”，把自然语言问题 → 安全、可信、可解释的 SQL + 业务解释

用户问题
  ↓
【Prompt ① 问题分类】
  ↓
【RAG ① 表 / 指标检索】
  ↓
【Prompt ② SQL 生成（强约束）】
  ↓
【你写的 SQL 静态校验】
  ↓
执行 SQL
  ↓
【Prompt ③ 结果解释 / 总结】

👉 LLM 永远不直连数据库
👉 LLM 永远在“你给的上下文”里思考

二、RAG 设计（这是你和普通 AI 产品的分水岭）

1️⃣ RAG 里到底放什么？（非常重要）

不要放数据，只放“知识”

必放 4 类内容：

✅ ① 表元数据（最核心）

{
  "table": "order_detail",
  "comment": "订单明细表",
  "columns": [
    { "name": "order_id", "type": "bigint", "comment": "订单ID" },
    { "name": "user_id", "type": "bigint", "comment": "用户ID" },
    { "name": "pay_amount", "type": "decimal", "comment": "实付金额" },
    { "name": "pay_time", "type": "timestamp", "comment": "支付时间" }
  ],
  "partition": "dt"
}

✅ ② 指标定义（决定“口径是否一致”）

{
  "metric": "GMV",
  "definition": "支付成功订单的实付金额之和",
  "sql_template": "SUM(pay_amount)",
  "filters": ["pay_status = 'SUCCESS'"]
}

📌 有指标定义，AI 才不会乱算

✅ ③ 业务规则 / 禁区（你经验的体现）

- 查询必须包含时间条件
- 默认查询最近 7 天
- 禁止 select *
- 禁止 join 超过 3 张表
- 单次返回行数不得超过 1000

✅ ④ 示例 SQL（极其重要）

-- 查询昨日 GMV
SELECT
  SUM(pay_amount) AS gmv
FROM order_detail
WHERE pay_status = 'SUCCESS'
  AND dt = '2025-12-13';

👉 示例比描述强 10 倍

2️⃣ RAG 检索策略（简单但有效）

推荐做法：

  • 向量检索：
    • 表名 + comment
    • 字段名 + comment
    • 指标名 + definition
  • Top K = 5～10

📌 不要一次给 AI 50 张表
📌 宁少勿多

三、Prompt ①：问题分类 Prompt（第一个关卡）

目的：控制后续流程，不让 AI 自由发挥

Prompt（可直接用）

你是一个企业数据分析助手，请判断用户问题的类型。

类型只能是以下之一：
1. QUERY_DATA（需要生成 SQL 查询数据）
2. EXPLAIN_METRIC（解释某个指标或字段含义）
3. INVALID（与数据无关，或无法回答）

用户问题：
{{user_question}}

请只返回类型枚举值，不要返回任何解释。

四、Prompt ②：SQL 生成 Prompt（核心！）

⚠️ 这是整个产品最重要的 Prompt

System Prompt（强约束）

你是一个资深数据工程师，只负责生成【安全、可执行的 SELECT SQL】。

严格遵守以下规则：
1. 只能使用提供的表和字段
2. 必须包含时间过滤条件
3. 禁止使用 SELECT *
4. 禁止 DELETE / UPDATE / INSERT
5. 禁止子查询嵌套超过 2 层
6. 默认 LIMIT 1000
7. 如果无法生成安全 SQL，直接返回：UNSUPPORTED

输出内容只能是 SQL，不允许任何解释说明。

User Prompt（带 RAG）

用户问题：
{{user_question}}

可用表结构：
{{table_metadata}}

可用指标定义：
{{metric_definitions}}

业务规则：
{{business_rules}}

示例 SQL：
{{example_sql}}

请根据以上信息生成 SQL。

✅ 你要做的一步（很多人忽略）

生成后，你再做一次程序校验：

  • AST 解析
  • 表是否在白名单
  • 是否有时间条件
  • 是否有 limit

👉 AI + 规则 = 企业级可信

五、Prompt ③：查询结果解释 Prompt（老板最爱）

目的

把冷冰冰的数据 → 一句人话总结

Prompt

你是一个数据分析专家，请用业务人员能听懂的语言总结查询结果。

用户原始问题：
{{user_question}}

SQL：
{{sql}}

查询结果（JSON）：
{{query_result}}

请输出：
1. 一句话结论
2. 关键数值说明
3. 是否存在异常或需要关注的点

不要提及 SQL 细节。

📌 这里就是产品“爽点”

六、一个完整请求的真实示例

用户输入

“昨天的 GMV 怎么样？”

AI 实际走的链路

  1. 问题分类 → QUERY_DATA
  2. RAG → order_detail + GMV
  3. SQL 生成：
SELECT
  SUM(pay_amount) AS gmv
FROM order_detail
WHERE pay_status = 'SUCCESS'
  AND dt = '2025-12-13'
LIMIT 1000;

你校验 → OK

结果解释：

“昨天 GMV 为 128 万元，较前一天基本持平，没有明显异常。”

七、你现在已经领先 90% 的 AI Builder

因为你：

  • 没把 AI 当“魔法”
  • 用 数据工程 + 规则 管住它
  • 做的是 企业愿意掏钱的“可信 AI”

一、产品 3 的一句话定位（先定准）

“点一个字段 / 指标，AI 告诉你：
它从哪来、怎么算、影响谁、敢不敢改。”

📌 血缘 ≠ 图
📌 解释 + 影响判断 = 价值

二、整体架构（AI 在哪，规则在哪）

字段 / 指标
   ↓
【你写的血缘解析（AST / DAG）】
   ↓
血缘结构化数据（JSON）
   ↓
【Prompt ① 技术血缘 → 人话解释】
   ↓
【Prompt ② 指标口径说明】
   ↓
【Prompt ③ 影响范围 & 风险评估】

👉 LLM 只负责“翻译 & 总结”，不负责“推理血缘”

三、RAG 设计（非常关键）

1️⃣ RAG 里应该放什么？

✅ ① 字段级血缘（你算出来的，最重要）

{
  "target": "ads_gmv.gmv",
  "expression": "SUM(pay_amount)",
  "sources": [
    {
      "table": "order_detail",
      "column": "pay_amount",
      "filters": ["pay_status = 'SUCCESS'"]
    }
  ]
}

✅ ② 表 & 字段元数据

{
  "table": "order_detail",
  "column": "pay_amount",
  "type": "decimal",
  "comment": "实付金额"
}

✅ ③ SQL 片段（非常重要）

SELECT
  SUM(pay_amount) AS gmv
FROM order_detail
WHERE pay_status = 'SUCCESS'
GROUP BY dt;

✅ ④ 下游依赖（影响分析用）

{
  "field": "ads_gmv.gmv",
  "downstream": [
    "bi_dashboard.daily_gmv",
    "report.finance_monthly"
  ]
}

2️⃣ RAG 使用原则（血泪经验）

  • 血缘 JSON 必须是“事实”
  • Prompt 不允许 AI 自行补血缘
  • AI 只解释，不创造依赖

📌 这是你能卖钱的前提。

四、Prompt ①：技术血缘 → 人话解释（核心）

System Prompt

你是一个资深数据架构师，擅长把复杂的数据血缘关系，
用非技术人员也能理解的语言解释清楚。

你只能基于提供的血缘信息进行解释，
禁止猜测、补充或虚构任何来源。

User Prompt

请根据以下字段血缘信息，解释该字段的来源和计算逻辑。

字段：
{{target_field}}

字段血缘（结构化事实）：
{{lineage_json}}

相关表字段说明：
{{column_metadata}}

相关 SQL 片段：
{{sql_snippet}}

请输出：
1. 这个字段是做什么的（一句话）
2. 它的数据从哪些表、哪些字段来
3. 主要计算规则（用业务语言）

不要输出 SQL，不要使用过多技术术语。

✅ 示例输出

“GMV 表示成功支付订单的成交金额总和。
它来自订单明细表中的实付金额字段，只统计支付成功的订单，然后按时间进行汇总。”

五、Prompt ②：指标 / 口径解释（管理层最爱）

System Prompt

你是一个企业数据口径解释专家，
擅长用统一、规范的方式描述指标含义，
确保不同部门理解一致。

User Prompt

请根据以下信息，生成该指标的【标准口径说明】。

指标名称：
{{metric_name}}

技术定义：
{{lineage_json}}

业务背景：
{{business_context}}

要求输出：
- 指标定义（1 句话）
- 统计范围
- 排除规则
- 常见误解或注意事项

语言要正式，可用于文档。

示例输出

GMV（成交总额）
指在统计周期内，所有支付成功订单的实付金额之和。

统计范围：仅包含状态为“支付成功”的订单
排除规则：未支付、已取消订单不计入
注意事项：退款金额不在该指标中扣除

📌 这是咨询项目级别输出。

六、Prompt ③：影响范围 & 改动风险评估（护城河）

System Prompt

你是一个数据治理专家，
负责评估字段或指标变更对下游系统的影响风险。

请基于事实血缘信息进行判断，
不得夸大或缩小影响。

User Prompt

以下是某个字段的下游依赖信息：

字段：
{{target_field}}

下游依赖：
{{downstream_list}}

请判断：
1. 这个字段是否属于核心指标
2. 变更可能影响哪些报表或系统
3. 风险等级（低 / 中 / 高）
4. 是否建议直接修改，或需要评审

请使用审慎、专业的语气。

示例输出

“该字段被多个核心经营报表使用，属于关键业务指标。
修改该字段可能影响财务月报及管理层看板，风险等级为高。
建议在修改前进行评审，并通知相关业务方。”

📌 这句话 = CTO 愿意付钱。

七、产品 1 & 产品 3 的「无缝联动」（极其重要）

在产品 1 的查询结果中：

  • 点击字段名 → 调用产品 3
  • 展示：
    • 字段解释
    • 指标口径
    • 影响范围

👉 这是天然升级点（Upsell）

下一篇
AI 数据智能平台
上一篇 nextjs使用wangEditor