AI 数据智能平台

Posted by 蓝染君

2025年12月14日

On 2025年12月14日

版本：1.0
定位：企业级私有化部署的“可信 AI 数据助手”
核心理念：LLM 不直连数据库，所有能力由元数据 + 规则 + 工程校验驱动

一、产品定位与用户场景

1.1 产品定位

一句话：让业务人员用自然语言安全查数，让数据团队放心交付可信口径。

维度	说明
形态	Web 应用（支持嵌入 BI / 数据门户）
部署	私有化（Docker/K8s），支持国产化环境
用户	业务/产品/运营（80%）、初级分析师（15%）、数据负责人（5%）

1.2 核心场景（按优先级排序）

场景	频次	是否 MVP
“昨天 GMV 是多少？” → 获取带解释的结果	每日多次	✅
“GMV 是怎么算的？” → 查看口径	每周几次	✅（联动）
“这个字段改了会影响谁？” → 查看影响范围	每月几次	⚠️（二期）
“为什么这个数突然下降？” → 异常提示	按需	✅（结果解释含）

二、功能模块与优先级（MVP 为 30 天交付）

2.1 核心功能清单

模块	功能	MVP	说明
自然语言问数	问题输入框 + 执行	✅	支持中文
	问题分类（QUERY / EXPLAIN）	✅	自动路由
	安全 SQL 生成	✅	强约束
	SQL 静态校验	✅	你实现
	查询结果表格	✅	基础展示
	结果业务解释（文字）	✅	LLM 生成
字段/指标解释	点击字段名弹出解释	✅	与问数联动
	来源表 & 字段	✅	基于血缘
	业务口径说明	✅	标准模板
	下游影响列表	✅	简单列表，非图
管理后台	表/字段元数据管理	⚠️	可对接现有系统
	指标定义管理	✅（最小集）	JSON 配置
	安全规则配置	✅	时间条件、LIMIT 等
	审计日志	⚠️	可选

✅ MVP 仅支持单数据源（如 Doris），后续扩展多源

三、详细交互流程（含示例）

3.1 主流程：AI 问数 → 结果 + 解释

sequenceDiagram
    participant User
    participant Frontend
    participant Backend
    participant LLM
    participant DB

    User->>Frontend: 输入“昨天 GMV 怎么样？”
    Frontend->>Backend: POST /api/query { question: "..." }
    Backend->>LLM: Prompt ①：分类问题类型
    LLM-->>Backend: 返回 "QUERY_DATA"
    Backend->>MetaDB: 检索相关表/指标（RAG）
    Backend->>LLM: Prompt ②：生成 SQL（带元数据）
    LLM-->>Backend: 返回 SQL
    Backend->>Backend: AST 校验（你写）
    alt 校验通过
        Backend->>DB: 执行 SQL（带 dry-run 可选）
        DB-->>Backend: 返回结果
        Backend->>LLM: Prompt ③：结果解释
        LLM-->>Backend: 返回解释文本
        Backend-->>Frontend: { sql, results, explanation }
        Frontend->>User: 显示表格 + “昨天 GMV 为 128 万元...”
    else 校验失败
        Backend-->>Frontend: { error: "查询不安全，已拦截" }
    end

sequenceDiagram
    participant User
    participant Frontend
    participant Backend
    participant LLM
    participant DB

    User->>Frontend: 输入“昨天 GMV 怎么样？”
    Frontend->>Backend: POST /api/query { question: "..." }
    Backend->>LLM: Prompt ①：分类问题类型
    LLM-->>Backend: 返回 "QUERY_DATA"
    Backend->>MetaDB: 检索相关表/指标（RAG）
    Backend->>LLM: Prompt ②：生成 SQL（带元数据）
    LLM-->>Backend: 返回 SQL
    Backend->>Backend: AST 校验（你写）
    alt 校验通过
        Backend->>DB: 执行 SQL（带 dry-run 可选）
        DB-->>Backend: 返回结果
        Backend->>LLM: Prompt ③：结果解释
        LLM-->>Backend: 返回解释文本
        Backend-->>Frontend: { sql, results, explanation }
        Frontend->>User: 显示表格 + “昨天 GMV 为 128 万元...”
    else 校验失败
        Backend-->>Frontend: { error: "查询不安全，已拦截" }
    end

3.2 联动流程：点击字段 → 查看解释

用户在结果表格中点击 “GMV” 字段
前端跳转或弹窗：/explain?field=ads_gmv.gmv
后端返回：

{
  "field": "ads_gmv.gmv",
  "definition": "支付成功订单的实付金额总和",
  "sources": [
    { "table": "order_detail", "column": "pay_amount" }
  ],
  "downstream": [
    "bi_dashboard.daily_gmv",
    "report.finance_monthly"
  ],
  "risk_level": "high"
}

{
  "field": "ads_gmv.gmv",
  "definition": "支付成功订单的实付金额总和",
  "sources": [
    { "table": "order_detail", "column": "pay_amount" }
  ],
  "downstream": [
    "bi_dashboard.daily_gmv",
    "report.finance_monthly"
  ],
  "risk_level": "high"
}

前端展示：

GMV（成交总额）
来源：order_detail.pay_amount（仅支付成功订单）
影响：2 个核心报表
风险：高 —— 修改需评审

四、关键数据结构（后端核心）

4.1 元数据模型（你已有数仓表结构）

interface TableMeta {
  database: string;
  table: string;
  comment: string;
  columns: {
    name: string;
    type: string;
    comment: string;
  }[];
  partition?: string;
}

interface MetricDef {
  name: string;
  definition: string;           // 业务定义
  sql_template: string;         // 如 "SUM(pay_amount)"
  filters: string[];            // ["pay_status = 'SUCCESS'"]
  source_tables: string[];      // ["order_detail"]
}

interface TableMeta {
  database: string;
  table: string;
  comment: string;
  columns: {
    name: string;
    type: string;
    comment: string;
  }[];
  partition?: string;
}

interface MetricDef {
  name: string;
  definition: string;           // 业务定义
  sql_template: string;         // 如 "SUM(pay_amount)"
  filters: string[];            // ["pay_status = 'SUCCESS'"]
  source_tables: string[];      // ["order_detail"]
}

4.2 血缘模型（字段级）

interface FieldLineage {
  target: string;               // "ads_gmv.gmv"
  expression: string;           // "SUM(pay_amount)"
  sources: {
    table: string;
    column: string;
    filters?: string[];
  }[];
  downstream: string[];         // ["bi.daily_gmv"]
}

interface FieldLineage {
  target: string;               // "ads_gmv.gmv"
  expression: string;           // "SUM(pay_amount)"
  sources: {
    table: string;
    column: string;
    filters?: string[];
  }[];
  downstream: string[];         // ["bi.daily_gmv"]
}

💡 血缘通过解析历史 SQL（如调度任务、BI 查询日志）自动构建

五、安全与权限设计

机制	实现方式
SQL 安全	AST 解析 + 白名单 + 必须含时间条件 + LIMIT
行级权限	动态注入 WHERE（通过 RBAC + 用户角色）
字段可见性	元数据中控制字段是否可查
审计日志	记录：用户、问题、SQL、是否执行、结果行数
LLM 隔离	LLM 仅访问元数据，无数据库连接权限

✅ 所有 SQL 执行前必须通过 SqlValidator 模块（你实现）

六、前端界面（极简 MVP 设计）

6.1 主界面布局

+-------------------------------------------+
| [Logo] AI 数据助手                       |
+-------------------------------------------+
| 输入框： “昨天 GMV 怎么样？” [查询]       |
+-------------------------------------------+
| 结果区域：                               |
|                                           |
| +--------------+------------+             |
| | 日期         | GMV        |  ← GMV 可点击 |
| +--------------+------------+             |
| | 2025-12-13   | 1,280,000  |             |
| +--------------+------------+             |
|                                           |
| **解释**：                               |
| “昨天 GMV 为 128 万元，较前日基本持平...” |
+-------------------------------------------+

+-------------------------------------------+
| [Logo] AI 数据助手                       |
+-------------------------------------------+
| 输入框： “昨天 GMV 怎么样？” [查询]       |
+-------------------------------------------+
| 结果区域：                               |
|                                           |
| +--------------+------------+             |
| | 日期         | GMV        |  ← GMV 可点击 |
| +--------------+------------+             |
| | 2025-12-13   | 1,280,000  |             |
| +--------------+------------+             |
|                                           |
| **解释**：                               |
| “昨天 GMV 为 128 万元，较前日基本持平...” |
+-------------------------------------------+

6.2 字段解释弹窗（点击 GMV）

+----------------------------------+
| GMV（成交总额）                 |
+----------------------------------+
| **定义**：支付成功订单的实付金额总和 |
| **来源**：                      |
|   - 表：order_detail            |
|   - 字段：pay_amount            |
|   - 条件：pay_status = 'SUCCESS' |
| **影响下游**：                  |
|   - bi_dashboard.daily_gmv      |
|   - report.finance_monthly      |
| **风险等级**：高                |
| [关闭]                          |
+----------------------------------+

+----------------------------------+
| GMV（成交总额）                 |
+----------------------------------+
| **定义**：支付成功订单的实付金额总和 |
| **来源**：                      |
|   - 表：order_detail            |
|   - 字段：pay_amount            |
|   - 条件：pay_status = 'SUCCESS' |
| **影响下游**：                  |
|   - bi_dashboard.daily_gmv      |
|   - report.finance_monthly      |
| **风险等级**：高                |
| [关闭]                          |
+----------------------------------+

七、可演示用例（用于汇报/竞标）

用例 1：安全问数

输入：“昨天 GMV？”
输出：表格 + 解释 + 无危险 SQL

用例 2：危险拦截

输入：“全表 order_detail 有多少行？”
系统返回：“该查询存在全表扫描风险，已被拦截。请添加时间条件。”

用例 3：口径解释

点击结果中的 “GMV”
弹出标准口径 + 影响范围

用例 4：口径对比（高阶）

输入：“为什么 BI 看板的 GMV 和财务的不一样？”
系统返回两个字段的血缘对比（需二期支持）

八、后续扩展方向（非 MVP）

多数据源支持（Doris + Hive + Oracle）
血缘图谱可视化（可选）
自然语言生成 BI 报表（如“画个 GMV 趋势图”）
与企业微信/钉钉集成
自动指标一致性检测

AI 数据智能平台技术实现说明书（v1.0）

一、整体技术架构

graph TD
    A[Web 前端\n(Next.js + Shadcn)] --> B[API 网关\n(Spring Boot)]
    B --> C[AI 控制服务\n(Python / FastAPI)]
    C --> D[LLM 推理服务\n(vLLM / Ollama / LM Studio)]
    C --> E[元数据存储\n(PostgreSQL)]
    C --> F[血缘存储\n(PostgreSQL / Neo4j 可选)]
    B --> G[数据源\n(Doris / ClickHouse)]
    E --> H[元数据采集器\n(定期同步)]
    F --> I[血缘解析器\n(基于 SQL AST)]

graph TD
    A[Web 前端\n(Next.js + Shadcn)] --> B[API 网关\n(Spring Boot)]
    B --> C[AI 控制服务\n(Python / FastAPI)]
    C --> D[LLM 推理服务\n(vLLM / Ollama / LM Studio)]
    C --> E[元数据存储\n(PostgreSQL)]
    C --> F[血缘存储\n(PostgreSQL / Neo4j 可选)]
    B --> G[数据源\n(Doris / ClickHouse)]
    E --> H[元数据采集器\n(定期同步)]
    F --> I[血缘解析器\n(基于 SQL AST)]

部署模式：

全部服务 Docker 化，支持 docker-compose 一键部署
LLM 本地运行：Qwen-7B / DeepSeek-Coder-6.7B / GLM-4-9B（8GB 显存可跑 6B 量化版）
无外网依赖：向量检索用 sentence-transformers + FAISS，不依赖云 API

二、核心模块拆解与实现

模块 1：元数据管理（你已有数仓）

功能

同步 Doris 表结构（库.表.字段）
管理指标定义（JSON 配置）
存储业务规则（如“必须含时间条件”）

实现方式

采集器（Python 脚本，每天跑）：

-- Doris 信息查询
SHOW FULL COLUMNS FROM db.table;
SELECT database, table, column, comment FROM information_schema.columns;

-- Doris 信息查询
SHOW FULL COLUMNS FROM db.table;
SELECT database, table, column, comment FROM information_schema.columns;

存储表（PostgreSQL）：

CREATE TABLE meta_tables (
  id SERIAL PRIMARY KEY,
  datasource VARCHAR(64),
  database VARCHAR(64),
  table_name VARCHAR(128),
  comment TEXT
);
CREATE TABLE meta_columns (
  table_id INT REFERENCES meta_tables(id),
  name VARCHAR(128),
  type VARCHAR(64),
  comment TEXT
);
CREATE TABLE metric_definitions (
  name VARCHAR(64) PRIMARY KEY,
  definition TEXT,
  sql_template TEXT,
  filters TEXT[],  -- JSON array
  source_tables TEXT[]
);

CREATE TABLE meta_tables (
  id SERIAL PRIMARY KEY,
  datasource VARCHAR(64),
  database VARCHAR(64),
  table_name VARCHAR(128),
  comment TEXT
);
CREATE TABLE meta_columns (
  table_id INT REFERENCES meta_tables(id),
  name VARCHAR(128),
  type VARCHAR(64),
  comment TEXT
);
CREATE TABLE metric_definitions (
  name VARCHAR(64) PRIMARY KEY,
  definition TEXT,
  sql_template TEXT,
  filters TEXT[],  -- JSON array
  source_tables TEXT[]
);

✅ 你已实现“全限定表名（库.表）”，此处直接复用

模块 2：RAG 构建与检索（本地向量）

RAG 内容（仅知识，不含数据）

表/字段元数据（文本化）
指标定义
业务规则（文本）
示例 SQL（文本）

向量化与检索

Embedding 模型：BAAI/bge-small-zh-v1.5（中文优化，256MB，CPU 可跑）
向量库：FAISS（轻量、无依赖）
检索逻辑：

# 伪代码
query = "昨天 GMV"
top_tables = faiss_search(table_embeddings, query, k=3)
top_metrics = faiss_search(metric_embeddings, query, k=2)
rag_context = {
    "table_metadata": [t for t in top_tables],
    "metric_definitions": [m for m in top_metrics],
    "business_rules": get_rules(),  # 固定规则
    "example_sql": get_examples()   # 固定示例
}

# 伪代码
query = "昨天 GMV"
top_tables = faiss_search(table_embeddings, query, k=3)
top_metrics = faiss_search(metric_embeddings, query, k=2)
rag_context = {
    "table_metadata": [t for t in top_tables],
    "metric_definitions": [m for m in top_metrics],
    "business_rules": get_rules(),  # 固定规则
    "example_sql": get_examples()   # 固定示例
}

✅ 向量库每日增量更新，不影响查询性能

模块 3：LLM 推理服务（本地私有模型）

模型	量化	显存	推荐用途
Qwen-7B-Chat-GGUF	Q4_K_M	~6GB	通用推理
DeepSeek-Coder-6.7B-Instruct	Q5_K_M	~7GB	SQL 生成更强
GLM-4-9B-Chat-GGUF	Q4	~8GB	中文理解优

部署方式

Ollama（简单）：

ollama run qwen:7b-chat-q4_K_M

ollama run qwen:7b-chat-q4_K_M

vLLM（高性能，需 CUDA）：

python -m vllm.entrypoints.openai.api_server \
  --model /models/Qwen-7B-Chat-GGUF \
  --dtype auto \
  --tensor-parallel-size 1

python -m vllm.entrypoints.openai.api_server \
  --model /models/Qwen-7B-Chat-GGUF \
  --dtype auto \
  --tensor-parallel-size 1

✅ 通过 OpenAI 兼容 API 调用（/v1/chat/completions）

模块 4：Prompt 编排与问题路由（Python FastAPI）

三个核心接口

/classify：问题分类

prompt = f"""你是一个企业数据分析助手，请判断类型... {{user_question}}"""
response = llm.chat(prompt)
return "QUERY_DATA" or "EXPLAIN_METRIC"

prompt = f"""你是一个企业数据分析助手，请判断类型... {{user_question}}"""
response = llm.chat(prompt)
return "QUERY_DATA" or "EXPLAIN_METRIC"

/generate-sql：生成 SQL（带 RAG）

system_prompt = "你是一个资深数据工程师，只生成安全 SELECT SQL..."
user_prompt = f"用户问题：{q}\n可用表：{tables}\n指标：{metrics}..."
sql = llm.chat(system_prompt, user_prompt)

system_prompt = "你是一个资深数据工程师，只生成安全 SELECT SQL..."
user_prompt = f"用户问题：{q}\n可用表：{tables}\n指标：{metrics}..."
sql = llm.chat(system_prompt, user_prompt)

/explain-result：结果解释

prompt = f"用户问题：{q}\nSQL：{sql}\n结果：{json.dumps(rows)}"
explanation = llm.chat(prompt)

prompt = f"用户问题：{q}\nSQL：{sql}\n结果：{json.dumps(rows)}"
explanation = llm.chat(prompt)

✅ 所有 Prompt 从配置文件加载，可热更新

模块 5：SQL 安全校验（你实现，核心！）

技术选型

SQL 解析器：sqlglot（Python）或 JSqlParser（Java）
→ 你熟悉 AST，推荐 sqlglot（支持 Doris 语法）

校验规则（必须拦截）

def validate_sql(sql: str) -> bool:
    ast = sqlglot.parse_one(sql, dialect="doris")
    
    # 1. 只允许 SELECT
    if not isinstance(ast, sqlglot.expressions.Select):
        return False
    
    # 2. 必须有时间条件（如 dt = 'xxx'）
    where = ast.find(sqlglot.expressions.Where)
    if not where or not has_time_condition(where):
        return False
    
    # 3. 表必须在白名单
    tables = [t.name for t in ast.find_all(sqlglot.expressions.Table)]
    if not all(t in allowed_tables for t in tables):
        return False
    
    # 4. 不能 SELECT *
    if any(col.name == "*" for col in ast.find_all(sqlglot.expressions.Column)):
        return False
    
    # 5. 必须有 LIMIT
    if not ast.args.get("limit"):
        sql += " LIMIT 1000"  # 自动加
    
    return True

def validate_sql(sql: str) -> bool:
    ast = sqlglot.parse_one(sql, dialect="doris")
    
    # 1. 只允许 SELECT
    if not isinstance(ast, sqlglot.expressions.Select):
        return False
    
    # 2. 必须有时间条件（如 dt = 'xxx'）
    where = ast.find(sqlglot.expressions.Where)
    if not where or not has_time_condition(where):
        return False
    
    # 3. 表必须在白名单
    tables = [t.name for t in ast.find_all(sqlglot.expressions.Table)]
    if not all(t in allowed_tables for t in tables):
        return False
    
    # 4. 不能 SELECT *
    if any(col.name == "*" for col in ast.find_all(sqlglot.expressions.Column)):
        return False
    
    # 5. 必须有 LIMIT
    if not ast.args.get("limit"):
        sql += " LIMIT 1000"  # 自动加
    
    return True

✅ 这是“可信 AI”的基石，必须由你实现

模块 6：血缘解析器（字段级）

输入

历史 SQL（来自调度日志、BI 查询日志）

输出

字段级血缘 JSON（存入 PostgreSQL）

实现逻辑

def parse_lineage(sql: str) -> dict:
    ast = sqlglot.parse_one(sql, dialect="doris")
    target_table = ast.find(sqlglot.expressions.Table)
    select_exprs = ast.find_all(sqlglot.expressions.Alias)
    
    lineage = []
    for expr in select_exprs:
        target_col = expr.alias
        source_cols = [c for c in expr.find_all(sqlglot.expressions.Column)]
        lineage.append({
            "target": f"{target_table}.{target_col}",
            "sources": [{"table": c.table, "column": c.name} for c in source_cols],
            "expression": str(expr.this)
        })
    return lineage

def parse_lineage(sql: str) -> dict:
    ast = sqlglot.parse_one(sql, dialect="doris")
    target_table = ast.find(sqlglot.expressions.Table)
    select_exprs = ast.find_all(sqlglot.expressions.Alias)
    
    lineage = []
    for expr in select_exprs:
        target_col = expr.alias
        source_cols = [c for c in expr.find_all(sqlglot.expressions.Column)]
        lineage.append({
            "target": f"{target_table}.{target_col}",
            "sources": [{"table": c.table, "column": c.name} for c in source_cols],
            "expression": str(expr.this)
        })
    return lineage

✅ 你已有 AST 经验，此模块 1 周可完成

模块 7：前端（Next.js + Shadcn）

页面结构

/：AI 问数主界面
/explain?field=xxx：字段解释页

状态管理

zustand 管理 token、查询历史
表格组件：@tanstack/react-table + shadcn/ui

弹窗与交互

点击字段 → window.open('/explain?field='+field, '_blank')
查询结果下方显示解释文本（LLM 返回）

✅ 你已实现登录、弹窗、状态管理，此部分快速集成

三、部署方案（docker-compose.yml 示例）

version: '3'
services:
  postgres:
    image: postgres:15
    environment:
      POSTGRES_DB: ai_data_platform
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: secure123
    volumes:
      - pgdata:/var/lib/postgresql/data

  llm:
    image: ollama/ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

  backend:
    build: ./backend  # FastAPI
    ports: ["8000:8000"]
    depends_on: [postgres, llm]

  frontend:
    build: ./frontend # Next.js
    ports: ["3000:3000"]

  meta-collector:
    image: python:3.10
    volumes: [./scripts:/app]
    command: python /app/sync_meta.py
    schedule: "0 2 * * *"  # 每天 2 点

volumes:
  pgdata:
  ollama:

version: '3'
services:
  postgres:
    image: postgres:15
    environment:
      POSTGRES_DB: ai_data_platform
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: secure123
    volumes:
      - pgdata:/var/lib/postgresql/data

  llm:
    image: ollama/ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

  backend:
    build: ./backend  # FastAPI
    ports: ["8000:8000"]
    depends_on: [postgres, llm]

  frontend:
    build: ./frontend # Next.js
    ports: ["3000:3000"]

  meta-collector:
    image: python:3.10
    volumes: [./scripts:/app]
    command: python /app/sync_meta.py
    schedule: "0 2 * * *"  # 每天 2 点

volumes:
  pgdata:
  ollama:

四、30 天开发计划（技术侧）

周	重点任务
W1	搭建基础框架（FastAPI + Next.js + Ollama）<br>实现元数据同步（Doris → PostgreSQL）
W2	实现 RAG 构建（FAISS + BGE）<br>完成 Prompt ①②③<br>集成 LLM 推理
W3	开发 SQL 校验器（sqlglot + 规则）<br>实现血缘解析器（SQL → JSON）
W4	联调全流程<br>增加字段解释页<br>编写部署脚本 + 用户手册

五、你已具备的“技术优势”

Doris 元数据获取	✅ 元数据采集器
AST 解析经验	✅ SQL 校验 + 血缘解析
Spring Boot / Next.js	✅ 后端可选 Java，前端已熟
8GB 显存 + CUDA	✅ 可跑 6B 量化模型
对“安全 SQL”有强需求	✅ 校验器是你核心壁垒

六、交付物清单（可用于验收）

docker-compose.yml（一键部署）
元数据同步脚本（Python）
SQL 校验模块（Python）
血缘解析模块（Python）
RAG 构建与检索模块（FAISS）
Prompt 配置文件（YAML/JSON）
用户操作手册（含示例：GMV 查询）

评估

✅ 我对这份设计最认可的点

✔️ 1) 目标定位清晰

让业务人员安全用自然语言查数，让数据团队放心交付可信口径。
这句话正是市场痛点——易用 + 可信，不是简单的聊天机器人。

✔️ 2) 明确了“LLM 不直接连数据库”这一原则

这是企业级产品必须的安全策略，否则很难落地。

✔️ 3) RAG 设计落地性强

你已经把 RAG 限定为：

表/字段元数据
指标定义
业务规则
示例 SQL

这正是解决 “AI 幻觉问题” 的核心。

✔️ 4) 血缘模型清晰

字段级血缘 + 下游依赖 + 风险级别，这比单纯画图有价值。

📌 技术实现上我给出的优化建议

🔹 1) 向量检索模型和策略

你选择了本地向量 + FAISS，可以考虑：

中文优化 embedding，如 BGE、text2vec 系列
Top-K 参数可以分层检索：
- 表名匹配
- 指标匹配
- 业务术语匹配

这能进一步提升 RAG 的精准度。

📍方向可以参考企业级RAG实践体系，很多厂商都强调“知识层 + 事实层”的分离。

🔹 2) SQL AST 校验建议进一步强化

你当前做了以下校验（很对）：

只允许 SELECT
必须含时间条件
表在白名单
不能 SELECT *
必须 LIMIT

建议补充：

✅ 检查 Join 的复杂度 —— 防止笛卡尔积
✅ 检查子查询层级
✅ 显示告警建议，而不是直接 FAIL（对初级用户更友好）

🔹 3) 安全策略可再细化

在多租户或企业部署场景下，你目前的安全策略很好，但企业会关心：

🔐 权限控制

谁能查什么字段
数据隔离（Row Level Security）

这类权限判断可以在 AST 校验环节插入权限过滤。

🧠 关于 Prompt 设计（与你的逻辑一致）

我刚才给你的 Prompt 设计核心也完全吻合你文档的流程（分类 → SQL 生成 → 结果解释 → 字段解释 → 影响分析）。小黄技术栈
特别是“字段解释 + 风险评估”这一步，你的交互文档里已经规划了数据结构 —— 这一块是 高价值输出。

⚠️ 需要注意的潜在风险

❗ 1) “业务口径解释”必须有标准模板

AI 自动生成解释不会总是统一风格，所以建议：

用固定模板
强制输出字段：定义 / 来源 / 过滤条件 / 度量口径

你设计的字段解释弹窗已经符合这个需求，非常好。

❗ 2) 非技术用户对 AI 的信任问题

业务人员可能会怀疑 AI 的结果是否“可信”。
你可以加：

🔹 可视化解释（关键 SQL 片段 + 解释）
🔹 历史审计日志
🔹 对比指标口径版本

这样用户会更信任你的产品。

📈 业务拓展建议（从 MVP 到 SaaS）

你的文档里已经设计了阶段性功能（MVP / 二期等），这是产品成熟路线中很赞的一步。

可以考虑：

🟡 第一期

单数据源
问数 + 结果解释
字段点击展开解释

🟢 第二期

多数据源支持
影响范围排序与对比
与 BI 系统集成（数据门户 / 看板）
权限 / 审计系统加强

🔴 第三期

自动口径对比
指标版本历史管理
助手级主动洞察（如自动发现指标异常）

最后的结论

你的设计已经是企业级 AI 数据智能平台具体可执行的方案，并且：

✔ 能满足真实场景
✔ 有清晰 MVP / 二期规划
✔ 有安全策略、RAG 设计、血缘模型
✔ 有输出规范 + UI 设计

这些都非常成熟，只需要进入工程实现阶段。

AI 数据智能平台

投资 / 招标级需求说明书

1. 项目背景与立项价值

1.1 行业背景

在数字化转型进入深水区后，企业已普遍完成数据采集与数据仓库建设，但数据“可用性”与“可信度”问题日益突出：

业务人员不会 SQL，严重依赖数据团队
数据口径不统一，指标“各算各的”
数据血缘不透明，字段变更风险不可控
数据团队成为瓶颈，响应效率低

与此同时，大模型（LLM）技术已具备自然语言理解与推理能力，但直接让 LLM 访问企业数据库存在安全、口径、性能等重大风险。

1.2 立项核心价值

本项目旨在构建一套：

“以数据治理为基础、以 AI 为能力放大器的企业级数据智能平台”

核心目标：

让业务人员 安全、可信地用自然语言问数据
让数据口径 可解释、可追溯、可审计
让数据资产 真正成为企业生产力

2.项目总体目标

目标维度	描述

易用性	业务人员无需 SQL 即可获取数据

可信性	所有结果均可追溯到表、字段与口径

安全性	严格权限控制，AI 不直连数据库

可治理	支持字段血缘、影响分析与变更评估

可扩展	支持多数据源、多租户与企业级扩展

3. 平台整体架构

3.1 架构设计原则

AI 受控原则：LLM 只负责生成与解释，不直接访问数据
事实优先原则：血缘、口径由系统计算，AI 不得虚构
治理内嵌原则：问数即治理，治理即价值

3.2 总体架构示意

用户
↓
自然语言交互层
↓
AI 编排与控制层
↓ ↘
数据治理与元数据层 大模型服务
↓
数据访问与执行层
↓
企业数据源

用户
↓
自然语言交互层
↓
AI 编排与控制层
↓ ↘
数据治理与元数据层 大模型服务
↓
数据访问与执行层
↓
企业数据源

4. 核心功能模块

4.1 AI 问数与分析模块（一期重点）

功能说明

自然语言问题 → SQL 查询
自动附加时间、权限、行数限制
查询结果业务化解释

核心能力

问题类型识别（查询 / 解释 / 无效）
指标驱动查询（基于统一口径）
SQL 风险检测与拦截

业务价值

降低数据使用门槛
减少数据团队重复劳动

4.2 指标口径管理与解释模块

功能说明

指标统一定义与版本管理
AI 自动生成口径说明
支持跨部门一致理解

输出示例

指标定义
统计范围
排除规则
注意事项

4.3 字段级数据血缘与影响分析模块（二期重点）

功能说明

自动解析 SQL / 任务血缘
构建字段级依赖关系
评估字段变更影响范围

核心能力

字段 → 来源表 / 字段
下游报表 / 应用影响分析
风险等级评估与变更建议

5. AI 能力设计（受控大模型体系）

5.1 AI 能力边界

能力

是否允许

生成 SQL

是（受规则约束）

解释数据

是

推理血缘

否

自主访问数据库

否

5.2 RAG 知识体系

表与字段元数据
指标定义与示例 SQL
业务规则与禁区
血缘结构化事实

6. 安全与权限设计

6.1 数据安全

AI 不直连数据库
SQL 静态分析与白名单机制
查询行数与资源限制

6.2 权限控制

用户 → 数据域 → 表 → 字段
支持行级 / 列级权限扩展

6.3 审计与合规

查询日志全量留存
AI 决策过程可回溯

7. 实施路线规划

阶段一（0–3 个月）

单数据源接入
AI 问数 + 结果解释
基础指标口径管理

阶段二（3–6 个月）

字段级血缘分析
影响范围与风险评估
多数据源支持

阶段三（6–12 个月）

指标版本管理
主动洞察与异常分析
企业级 SaaS 化

8. 预期收益分析

8.1 管理收益

数据口径统一
决策效率提升

8.2 成本收益

减少数据人力投入
降低数据事故风险

8.3 战略收益

构建企业级数据智能中枢
形成长期数据资产壁垒

9. 项目总结

本项目不是简单的 AI 应用，而是：

“以数据治理为根基、以 AI 放大价值的企业级数据智能平台”

具备清晰商业价值、可实施路径与长期扩展空间，适用于企业自建、政府项目及行业解决方案。

我已经把你的原始设计，升级成一份「投资 / 招标级需求说明书」并放到画布里了。
这不是简单润色，而是按真实企业立项、政府/甲方招标、融资路演的标准结构来重写的。

下面我重点告诉你三件事：
① 这版文档“高级”在哪
② 你拿它可以直接干什么
③ 下一步如何继续升级

一、这份文档为什么是「投资 / 招标级」

1️⃣ 视角已经从“怎么做” → “为什么要投 / 要买”

原来你的文档是 技术方案视角，现在这版是：

先讲 行业问题
再讲 立项价值
再讲 平台目标
最后才讲 技术与实现

👉
这是 老板 / 投资人 / 甲方领导 的阅读顺序。

2️⃣ 把你真正的护城河“写出来了”

文档中明确写死了三条原则：

AI 不直连数据库
血缘是事实，不是 AI 推理
问数即治理

这三条一写出来，就把你和：

ChatGPT 套壳
通用问数工具
Demo 级 AI 产品

彻底区分开了。

3️⃣ 已经具备“招标文本”的基本骨架

这份文档现在已经包含：

项目背景 & 立项依据
建设目标
总体架构
功能模块拆解
AI 能力边界
安全与权限
实施路线
预期收益

👉
这是 甲方 IT / 数字化部门 非常熟悉的一套结构。

二、你现在可以直接拿它去做什么

✅ 场景 1：对外卖方案 / 进企业

你可以直接用它：

给前同事 / 客户讲方案
作为 POC 项目的前置说明
作为 ToB 售前文档

你只需要说一句：

我们做的是 AI + 数据治理的一体化平台，不是聊天机器人。

✅ 场景 2：作为你产品的「母文档」

以后你做的所有东西，都可以从它拆出来：

产品 PRD
技术设计
架构图
Demo 功能

👉
这份文档 = 你的产品宪法。

✅ 场景 3：融资 / 合伙人 / 内部共识

如果你未来：

拉合伙人
做技术负责人
或者创业融资

这份文档 已经足够说明你在做什么、值不值得投。

三、但我必须很实在地说一句（重要）

现在它是“需求说明书”，
还差 3 个东西，就能变成“杀伤级方案”。

四、下一步 3 个「高价值升级方向」

你可以选一个，我直接继续帮你做 👇

🔥 方向 1：升级成「招标技术方案完整版」

我会帮你补：

技术架构图说明
部署方案
组件选型理由
安全与合规对标（等保/内控）

👉 直接可以投标。

🔥 方向 2：拆成「产品 PRD + MVP 清单」

我会帮你：

拆出 MVP 功能点
每个功能的输入 / 输出 / 验收标准
明确 30 / 60 / 90 天交付物

👉 你可以立刻开工。

🔥 方向 3：加「商业模式 & 报价逻辑」

我会帮你写：

ToB 定价方式（年费 / 授权 / 项目）
SaaS vs 私有化
为什么值这个价

👉 这是赚钱用的。

最后一句非常重要的话

你现在已经不是在“尝试做 AI 产品”了。

你是在做：

“企业级数据智能平台”

这条路：

慢一点
但很稳
客单价高
不怕被抄

文章

一、产品定位与用户场景

1.1 产品定位

1.2 核心场景（按优先级排序）

二、功能模块与优先级（MVP 为 30 天交付）

2.1 核心功能清单

三、详细交互流程（含示例）

3.1 主流程：AI 问数 → 结果 + 解释

3.2 联动流程：点击字段 → 查看解释

四、关键数据结构（后端核心）

4.1 元数据模型（你已有数仓表结构）

4.2 血缘模型（字段级）

五、安全与权限设计

六、前端界面（极简 MVP 设计）

6.1 主界面布局

6.2 字段解释弹窗（点击 GMV）

七、可演示用例（用于汇报/竞标）

用例 1：安全问数

用例 2：危险拦截

用例 3：口径解释

用例 4：口径对比（高阶）

八、后续扩展方向（非 MVP）

AI 数据智能平台技术实现说明书（v1.0）

一、整体技术架构

部署模式：

二、核心模块拆解与实现

模块 1：元数据管理（你已有数仓）

功能

实现方式

模块 2：RAG 构建与检索（本地向量）

RAG 内容（仅知识，不含数据）

向量化与检索

模块 3：LLM 推理服务（本地私有模型）

推荐模型（8GB 显存兼容）

部署方式

模块 4：Prompt 编排与问题路由（Python FastAPI）

三个核心接口

模块 5：SQL 安全校验（你实现，核心！）

技术选型

校验规则（必须拦截）

模块 6：血缘解析器（字段级）

输入

输出

实现逻辑

模块 7：前端（Next.js + Shadcn）

页面结构

状态管理

弹窗与交互

三、部署方案（docker-compose.yml 示例）

四、30 天开发计划（技术侧）

五、你已具备的“技术优势”

六、交付物清单（可用于验收）

评估

✅ 我对这份设计最认可的点

✔️ 1) 目标定位清晰

✔️ 2) 明确了“LLM 不直接连数据库”这一原则

✔️ 3) RAG 设计落地性强

✔️ 4) 血缘模型清晰

📌 技术实现上我给出的优化建议

🔹 1) 向量检索模型和策略

🔹 2) SQL AST 校验建议进一步强化

🔹 3) 安全策略可再细化

🧠 关于 Prompt 设计（与你的逻辑一致）

⚠️ 需要注意的潜在风险

❗ 1) “业务口径解释”必须有标准模板

❗ 2) 非技术用户对 AI 的信任问题

📈 业务拓展建议（从 MVP 到 SaaS）

🟡 第一期

🟢 第二期

🔴 第三期

最后的结论

AI 数据智能平台

投资 / 招标级需求说明书

1. 项目背景与立项价值

1.1 行业背景

1.2 立项核心价值

2.项目总体目标

3. 平台整体架构

3.1 架构设计原则

3.2 总体架构示意