痛点：传统 BI 为什么不够用

报表平台解决了「看数」问题，但在企业日常运营里仍有三类高频抱怨：

  1. 报表固定：销售总监临时想问「华东区 Q1 客户留存率同比」，往往要等 BI 排期加字段。
  2. 门槛高：业务同学不会写 SQL，指标口径散落在 Excel 与口头约定里。
  3. 响应慢：从提需求到上线一个新看板，周期常以周计。

Data Agent（数据智能体） 的目标，是让业务同学用自然语言提问，系统在秒级返回可解释、可审计、可复现的查询结果——而不是让大模型「编一个看起来合理的数字」。

Data Agent 的定义与边界

在本专题语境下，Data Agent 具备以下特征：

特征 说明
工具化 域分类、检索、SQL 生成、校验、执行、解释各自独立，可单测
元数据优先 指标定义、取数逻辑、表白名单存 MySQL，不靠 prompt 硬背
安全默认 只读 SELECT、表白名单、LIMIT 兜底
可澄清 缺时间周期等问题时主动追问，而非瞎查
可运营 口径缺口、用户反馈可沉淀为配置与规则

它与「聊天机器人 + 数据库连接」的本质区别：SQL 来自结构化取数逻辑，LLM 负责理解与解释，而不是直接生成可执行 SQL。

整体架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
flowchart TB
    subgraph FE["前端 Vue3 + Element Plus"]
        WB[工作台 Workbench]
        DA[问数抽屉 DataAgent]
        KB[知识库管理]
        QA[问答历史与反馈]
    end
    subgraph API["后端 Flask API"]
        ASK["/ask 问数主入口"]
        META["/meta 元数据"]
        KBAPI["/kb 知识库"]
    end
    subgraph PIPE["Direct Analyze 管道"]
        D1[classify_domain 域分类]
        D2[retrieve_all 检索]
        D3[build_sql 生成 SQL]
        D4[validate_sql 校验]
        D5[execute_sql 执行]
        D6[explain_result 解释]
    end
    subgraph DATA["数据层"]
        MY[(MySQL 元数据 + 结果宽表)]
        CH[(Chroma 向量索引)]
        MD[Markdown 知识库]
    end
    subgraph AI["模型层"]
        DS[DeepSeek API]
        BGE[bge-m3 Embedding]
    end
    WB --> DA
    DA --> ASK
    ASK --> D1 --> D2 --> D3 --> D4 --> D5 --> D6
    D2 --> MY
    D2 --> CH
    D3 --> MY
    D5 --> MY
    CH --> BGE
    ASK -.可选.-> DS

技术栈选型

层级 技术 职责
前端 Vue 3 + Vite + Element Plus + ECharts 工作台、问数抽屉、图表
后端 Flask + 工具注册表 REST API、工具链编排
元数据 MySQL bi_metric、bi_metric_extract_logic、bi_table
向量 Chroma + sentence-transformers Markdown 知识 fallback
LLM DeepSeek（OpenAI 兼容） Agent 演示模式、未来 ReAct
Embedding BAAI/bge-m3 中文指标与规则检索

核心模块说明

1. 意图识别（域分类）

用户问「华北区销售收入完成率」时，系统先从 bi_domain 与关联指标关键词判断业务域（如「销售运营域」），缩小检索范围，降低误命中。

2. RAG 检索

一次 retrieve_all 并行拉取 metrics、bi_models、business_rules，MySQL 关键词打分优先，向量库作为 Markdown 知识的 fallback。

3. SQL 生成

生产路径走 _build_sql_from_meta_logic：读取 bi_metric_extract_logic 中的表名、指标名、时间字段、默认过滤条件，模板化拼接 SQL。

4. 安全校验

validate_sql 四层检查：SELECT-only → 禁用 DML 关键字 → 表白名单 → sqlparse 语法。

5. 执行与解释

结果宽表查询后，规则模板生成自然语言摘要，并附带 ECharts 配置（柱状/折线/饼图/仪表盘）。

用户问题到 SQL 全链路

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
sequenceDiagram
    participant U as 业务用户
    participant F as Vue 前端
    participant A as /ask API
    participant T as 工具链
    participant M as MySQL

    U->>F: 华东区 Q1 销售收入是多少？
    F->>A: POST question + session_id
    A->>T: classify_domain
    T->>M: 查 bi_domain 关键词
    A->>T: retrieve_all
    T->>M: 指标关键词检索
    A->>T: build_sql
    T->>M: 查 bi_metric_extract_logic
    T-->>A: SELECT ... LIMIT 1000
    A->>T: validate_sql
    A->>T: execute_sql
    T->>M: 执行只读查询
    A->>T: explain_result
    A-->>F: 答案 + SQL + 图表 + agent_flow
    F-->>U: 气泡 + 可视化

演进路线：从 Agent 框架到 BI 平台

早期可基于通用 Agent 框架（工具注册 + ReAct 循环）快速验证问数可行性；上线后建议切换为 Direct Analyze 管道：

  • 更少 LLM 调用：SQL 不经过模型「创作」，成本与幻觉双降
  • 更易测试：validate_data_pipeline.py 可离线跑通全工具链
  • 更易审计：每一步输入输出可落日志与 agent_flow 可视化

保留 Agent 模式用于复杂多步推理的演进方向（见第 8 篇）。

元数据表一览（虚构示例）

表 作用
bi_domain 业务域与关键词
bi_metric 指标定义（销售收入、客户留存率…）
bi_metric_extract_logic 取数逻辑：表、字段映射、默认过滤
bi_table 结果宽表白名单
bi_metric_gap 口径缺口工单
qa_history / qa_feedback 问答历史与用户反馈

本章小结

  • Data Agent = 自然语言入口 + 元数据驱动 SQL + 安全执行 + 可解释输出
  • 生产推荐 Direct 管道，Agent ReAct 作为演进选项
  • 下一篇深入 Text-to-SQL 五步：域分类 → 指标检索 → 取数逻辑 → 时间解析 → SQL 组装

思考题

  1. 若让 LLM 直接写 SQL，在企业场景下最大的三个风险是什么？
  2. 元数据表与向量知识库分别适合承载什么类型的知识？
  3. 画出你所在团队的「问数」链路，标出最耗时的环节。

系列导航

篇 主题
01 本篇
02 Text-to-SQL
03 RAG 指标库
04 多轮澄清
05 安全校验
06 Vue3 工作台
07 演示验证
08 反馈闭环

← 返回专题首页