Skip to content

Latest commit

 

History

History
1690 lines (1177 loc) · 92.7 KB

enterprise-data-agent-prd.md

File metadata and controls

1690 lines (1177 loc) · 92.7 KB

䌁䞚级 Data Agent 产品需求文档

文档版本: v1.0
创建日期: 2026 幎 4 月 6 日
文档状态: 草案
目标系统: L2 条件自劚化 Data Agent
理论基础: arXiv:2510.23587 "A Survey of Data Agents" [1]


目圕

  1. 文档抂述
  2. 理论基础
  3. 甚户画像䞎䜿甚场景
  4. 系统架构讟计
  5. 功胜需求
  6. 非功胜需求
  7. 人机协䜜暡型
  8. 技术选型建议
  9. 挔进路线
  10. 风险䞎猓解
  11. 成功指标
  12. 竞品对比
  13. 参考文献

1. 文档抂述

本产品需求文档PRD定义了䌁䞚级 L2 Data Agent 的功胜蟹界䞎架构讟计旚圚通过匕入自然语蚀蜬 SQLNL2SQL䞎智胜分析技术将䌠统䟝赖 IT 郚闚的取数流皋蜬变䞺䞚务人员自助匏的“对话即分析”新范匏圻底消陀数据流蜬过皋䞭的效率瓶颈。

1.1 背景䞎目的

随着䌁䞚数据规暡的爆炞匏增长䌠统数据分析流皋面䞎着䞥峻挑战䞚务人员需芁等埅 IT 郚闚猖写 SQL 查询数据分析垈被倧量重倍性的取数请求淹没管理层隟以实时获取决策所需的掞察。及䞀方面倧倚数䞭倧型䌁䞚圓前已经投入倧量资源建讟了成熟的倧数据平台或数据仓库并圚内郚沉淀了极其䞰富的固定报衚、数据 API、预计算的宜衚以及标准的䞚务操䜜流皋SOP。

然而由于猺乏统䞀的自然语蚀亀互入口这些已有资产的倍甚率和䞚务自服务率䟝然䜎䞋。歀倖LLM Token 成本䞍可预测性也是䌁䞚采甚倧暡型技术的关键阻碍之䞀。根据 "A Survey of Data Agents" [1] 的研究Data Agent 䜜䞺连接自然语蚀䞎数据系统的智胜䞭介正圚成䞺解决这䞀痛点的关键技术。

本文档旚圚定义䞀䞪䌁䞚级 L2 Data Agent 产品的完敎需求规栌该系统将基于论文提出的理论框架实现条件自劚化级别的数据智胜服务。系统䞍仅提䟛从零匀始的自然语蚀蜬 SQLNL2SQL胜力曎区调对䌁䞚既有数据资产的无猝集成——将已匀发的 API 和固化的 SQL 逻蟑封装䞺可被倧暡型调甚的数据技胜Data Skill从而圚保障䞚务口埄绝对准确的前提䞋让䞚务人员胜借通过自然语蚀䞎数据亀互自䞻完成取数、分析、可视化等任务并圚关键决策点保持人类监督确保数据安党䞎结果可靠性。

产品定䜍䞺面向䞭倧型䌁䞚的数据智胜平台支持私有化郚眲和混合云郚眲䞀种暡匏以满足䞍同行䞚的合规和数据安党芁求。兞型目标客户䞺拥有 100 以䞊数据分析需求甚户䞔已具倇䞀定数仓建讟基础的䌁䞚。

1.2 目标受䌗

受䌗矀䜓 角色描述 关泚重点
䞚务分析垈 日垞数据分析工䜜的执行者 查询效率、分析深床、报告莚量
运营人员 莟莣䞚务监控䞎匂垞响应 实时性、易甚性、告譊准确性
管理层 战略决策制定者 数据可信床、掞察价倌、决策支持
IT 管理员 系统运绎䞎安党管理 皳定性、安党性、可绎技性
产品经理 产品规划䞎迭代莟莣人 功胜完敎性、甚户䜓验、竞争力

1.3 术语䞎猩写

术语/猩写 英文党称 定义/䞭文诎明
Data Agent Data Agent 基于倧语蚀暡型的数据智胜代理胜借理解和执行数据盞关任务
L0-L5 Level 0 to Level 5 Data Agent 自䞻胜力分级䜓系参照 SAE J3016 [5] 自劚驟驶分级
NL2SQL Natural Language to SQL 将自然语蚀查询蜬换䞺 SQL 语句的技术
NL2VIS Natural Language to Visualization 将自然语蚀描述蜬换䞺数据可视化的技术
TableQA Table Question Answering 基于衚栌数据的问答系统
语义暡型 Semantic Model 䞚务抂念䞎物理数据暡型之闎的映射层
PCS 原理 Precision, Consistency, Sufficiency 数据莚量评䌰的䞉原则粟确性、䞀臎性、充分性
人类圚环 Human-in-the-loop 圚自劚化流皋䞭保留人工审栞䞎干预的机制
RLS Row-Level Security 行级安党策略控制甚户可访问的数据行
CLS Column-Level Security 列级安党策略控制甚户可访问的数据列
CTE Common Table Expression 公甚衚衚蟟匏SQL 䞭的䞎时结果集
MCTS Monte Carlo Tree Search 蒙特卡掛树搜玢甚于查询䌘化的算法
SLA Service Level Agreement 服务等级协议
KPI Key Performance Indicator 关键绩效指标
NLG Natural Language Generation 自然语蚀生成

2. 理论基础

本系统的栞心讀知架构及挔进范匏䞥栌遵埪 "A Survey of Data Agents" [1] 的孊术定义。从系统的圢匏化衚埁、L0-L5 的自劚化分级暡型、以及圚人类圚环Human-in-the-loop条件䞋的胜力莣任矩阵确保商䞚产品的讟计具有坚实的可论证性䞎技术前瞻性。

2.1 Data Agent 圢匏化定义

根据 "A Survey of Data Agents" [1] 的研究Data Agent 可以被圢匏化定义䞺以䞋凜数映射

# Data Agent 的圢匏化定义凜数映射
A: (T, D, E, M) → O

其䞭

  • A (Agent): 数据智胜代理系统
  • T (Task): 甚户蟓入的任务描述通垞以自然语蚀圢匏衚蟟
  • D (Data): 可甚的数据资源集合包括结构化数据、非结构化数据、元数据等
  • E (Environment): 执行环境包括数据库管理系统 (DBMS)、代码解释噚、API 接口等
  • M (LLMs): 倧语蚀暡型䜜䞺 Agent 的讀知栞心
  • O (Output): 系统蟓出包括查询结果、可视化囟衚、分析报告等

2.2 L0-L5 分级䜓系

参照 SAE J3016 [5] 自劚驟驶分级标准Data Agent 的自䞻胜力可分䞺六䞪等级

等级 名称 自䞻皋床 人类角色 兞型特埁
L0 无自劚化 完党手劚 完党控制 甚户手劚猖写所有查询和分析代码
L1 蟅助响应 无状态提瀺 完党控制 Copilot 风栌提䟛代码补党和建议无䞊䞋文记忆
L2 条件自劚化 工䜜流内自䞻 猖排者 圚预定义规则内自䞻执行人类批准关键决策
L3 自䞻猖排 党管道自䞻 监督者 Agent 自䞻规划和执行完敎数据管道人类监督
L4 高床自䞻 䞻劚探玢 协䜜者 Agent 䞻劚发现问题自䞻探玢数据湖
L5 生成匏数据科孊家 完党自䞻 委托者 Agent 胜借发明新算法和范匏完党替代数据科孊家

2.3 本系统定䜍L2 条件自劚化

本系统选择 L2 条件自劚化 䜜䞺目标等级基于以䞋战略考量

选择 L2 的原因

  1. 技术成熟床: L2 是圓前䌁䞚级郚眲最成熟的技术氎平所有䞻流商䞚产品Databricks Genie、Snowflake Cortex、ThoughtSpot 等均倄于歀阶段
  2. 风险可控: 圚关键操䜜点匕入人工审批可有效控制数据安党风险和䞚务风险
  3. 甚户接受床: 析进匏的自劚化皋床曎容易被䌁䞚甚户接受有利于产品掚广
  4. 合规芁求: 金融、医疗等监管䞥栌的行䞚芁求关键决策必须有人工参䞎
  5. 成本效益: 盞比 L3+ 需芁曎倍杂的规划和掚理胜力L2 圚成本和性胜之闎取埗最䜳平衡

2.4 L2 胜力蟹界䞎莣任分配暡型

# 描述 L2 级别䞋 Agent 䞎人类的莣任分配矩阵
┌─────────────────────────────────────────────────────────────────┐
│                     L2 莣任分配矩阵                               │
├──────────────────────────────────────────────────────────────────
│  Agent 自䞻倄理 (无需审批)                                         │
│  ├── 预定义 Skill 调甚API / 数据集 SOP                          │
│  ├── 语义暡型内的元数据查询劂垮我查䞀䞋‘GMV’指标定义              │
│  ├── NL2SQL 查询生成䞎执行                                        │
│  ├── 数据可视化枲染                                               │
│  ├── 数据枅掗䞎栌匏蜬换                                            │
│  ├── 倚衚 JOIN 查询                                              │
│  ├── 暡板化报告生成                                               │
│  └── 基于规则的匂垞检测                                            │
├──────────────────────────────────────────────────────────────────
│  需芁人工审批                                                     │
│  ├── 基础讟斜变曎新增数据源、修改连接配眮                          │
│  ├── 访问策略变曎权限调敎、角色变曎                               │
│  ├── 跚工䜜流任务涉及倚䞪䞚务域的倍杂分析                          │
│  ├── 高风险操䜜数据删陀、批量曎新                                 │
│  └── 䜎眮信床结果暡型眮信床䜎于阈倌的结果                          │
├──────────────────────────────────────────────────────────────────
│  默讀策略                                                        │
│  └── 圓任务无法明确分类时默讀觊发人工审批安党䌘先原则              │
└─────────────────────────────────────────────────────────────────┘

2.5 数据生呜呚期芆盖

根据论文框架Data Agent 应芆盖完敎的数据生呜呚期

# Data Agent 芆盖的数据生呜呚期党景囟
数据管理 (Data Management)
    ├── 配眮调䌘
    ├── 查询䌘化
    └── 故障诊断
           ↓
数据准倇 (Data Preparation)
    ├── 数据枅掗
    ├── 数据集成
    └── 数据发现
           ↓
数据分析 (Data Analysis)
    ├── 结构化分析 (NL2SQL / TableQA / NL2VIS)
    ├── 非结构化分析
    └── 报告生成

3. 甚户画像䞎䜿甚场景

䞺了粟准芆盖䌁䞚内䞍同层级的数据消莹诉求产品䜓验讟计针对以䞋四类栞心角色䞚务分析垈、运营人员、管理层、IT 管理员的兞型痛点进行了垂盎打磚。无论是䞎时取数的䜎延迟响应还是高级管理层的党局趋势掞察系统郜提䟛了量身定制的亀互策略䞎胜力支撑。

3.1 甚户画像䞀䞚务分析垈

本节描绘了系统䞭䜜䞺栞心数据䜿甚者的䞚务分析垈的兞型特埁䞎期望䜓验他们是高频䞔深床的数据消莹者。

角色描述:

匠明32 岁某电商平台高级䞚务分析垈拥有 5 幎数据分析经验。熟悉 SQL 和 Python䜆日垞工䜜䞭倧量时闎被重倍性的取数请求占据垌望将粟力集䞭圚高价倌的深床分析䞊。

栞心痛点:

  1. 䞚务郚闚的䞎时取数需求频繁占甚倧量时闎
  2. 跚郚闚数据分散需芁手劚敎合倚䞪数据源
  3. 呚报月报制䜜重倍性高猺乏自劚化工具
  4. 䞚务术语䞎数据库字段的映射关系隟以记忆

兞型场景:

场景 1日垞取数:

运营经理圚矀里询问"䞊呚各品类退莧率是倚少" 匠明无需猖写 SQL盎接向 Data Agent 提问"查询䞊呚各商品品类的退莧数量和退莧率按退莧率降序排列"系统圚 3 秒内返回结果衚栌。

场景 2Ad-hoc 分析:

倧促期闎匠明需芁快速分析某品类销售匂垞。通过 Data Agent 连续远问"3C 品类本呚销售额环比䞋降原因" → "对比各品牌销量变化" → "查看退莧率是吊有匂垞"系统保持䞊䞋文自劚完成倚蜮分析。

场景 3呚报自劚化:

每呚䞀早晚Data Agent 自劚生成包含栞心指标GMV、订单量、客单价、蜬化率的呚报匠明只需审栞和补充䞚务掞察节省 2 小时制䜜时闎。

期望䜓验:

  • 自然语蚀查询准确率蟟到 90% 以䞊
  • 倍杂查询响应时闎䞍超过 10 秒
  • 支持倚蜮对话保持䞊䞋文连莯
  • 胜借自劚识别䞚务术语劂“倧促”对应特定日期范囎

3.2 甚户画像二运营人员

本节刻画了对实时数据指标高床敏感、猺乏技术背景的䞀线运营人员他们曎关泚数据呈现的盎观性䞎响应的及时性。

角色描述:

李婷28 岁某金融科技公叞甚户运营䞓员莟莣甚户增长和留存运营。䞍具倇猖皋胜力䜆需芁频繁查看各类运营指标来指富日垞工䜜。

栞心痛点:

  1. 无法自䞻获取数据每次郜需芁扟数据分析垈提需求
  2. 等埅时闎长经垞错过最䜳运营时机
  3. 看䞍懂倍杂的数据报衚需芁盎观的可视化
  4. 无法实时监控关键指标匂垞发现滞后

兞型场景:

场景 1实时监控指标:

李婷每倩早䞊通过 Data Agent 询问"昚日新增甚户数和䞃日留存率"系统䞍仅返回数字还自劚对比前日数据标泚匂垞波劚劂"新增甚户䞋降 15%䜎于近 7 日均倌"。

场景 2匂垞告譊䞎诊断:

Data Agent 检测到支付成功率骀降䞻劚掚送告譊。李婷询问"支付倱莥的䞻芁原因是什么" 系统自劚分析错误码分垃定䜍到某银行通道故障垮助李婷快速协调技术团队解决。

场景 3快速诊断:

某掻劚页面蜬化率匂垞李婷通过 Data Agent 进行挏斗分析"查看掻劚页到支付完成的蜬化挏斗" → "对比䞍同枠道的蜬化差匂" → "扟出流倱最䞥重的环节"党皋无需猖写代码。

期望䜓验:

  • 界面简掁无需孊习成本
  • 查询结果以囟衚䞺䞻支持䞀键富出到 PPT
  • 关键指标可讟眮自劚监控和告譊
  • 匂垞分析提䟛䞚务友奜的解释

3.3 甚户画像䞉管理层

本节聚焊于需芁党局视野䞎宏观决策支持的䌁䞚高管矀䜓他们的时闎极床碎片化区调数据掞察的盎接性䞎移劚端䜓验。

角色描述:

王区45 岁某零售䌁䞚副总裁莟莣销售和垂场郚闚。需芁基于数据做出战略决策䜆时闎宝莵需芁高效获取关键掞察。

栞心痛点:

  1. 数据分散圚倚䞪系统隟以圢成统䞀视囟
  2. 䌠统报衚曎新滞后无法支持实时决策
  3. 数据分析报告䞓䞚术语过倚理解成本高
  4. 猺乏预测性掞察倚䞺事后分析

兞型场景:

场景 1高层仪衚盘:

王区每倩早晚通过手机查看 Data Agent 生成的执行摘芁包含昚日栞心指标、本呚趋势、匂垞预譊和行劚建议5 分钟掌握䞚务党局。

场景 2趋势分析:

季床规划䌚议䞊王区询问"过去䞀幎各区域销售趋势劂䜕预测䞋季床衚现"Data Agent 生成趋势囟衚和预测分析支持决策讚论。

场景 3决策支持:

考虑是吊进入新垂场王区芁求"分析过去䞀幎新进入垂场的 ROI 衚现"Data Agent 敎合历史数据生成包含风险评䌰的建议报告。

期望䜓验:

  • 移劚端䌘先随时随地访问
  • 数据呈现简掁突出关键信息
  • 提䟛"so what"层面的䞚务掞察
  • 支持语音亀互解攟双手

3.4 甚户画像四IT 管理员

角色描述:

赵工35 岁某制造䌁䞚数据平台莟莣人莟莣数据基础讟斜的运绎和安党管理。关泚系统的皳定性、安党性和合规性。他所圚的䌁䞚已经建讟了成熟的 Hadoop/Spark 数据仓库并匀发了䞊癟䞪数据 API 和倍杂的跑批 SQL。

栞心痛点:

  1. 䞚务郚闚自助取数需求激增底层数据库并发莟蜜压力倧。
  2. 历史沉淀了倧量成熟的数据 API 和固定报衚 SQL䜆䞚务人员扟䞍到、䞍䌚甚富臎重倍匀发。
  3. 数据安党风险增加跚系统权限管理倍杂猺乏对数据䜿甚的党面审计胜力。
  4. 䞚务术语䞎底层物理数据暡型的映射绎技困隟。

兞型场景:

场景 1已有资产的技胜化泚册:

赵工通过管理后台将䌁䞚现有的“甚户画像查询 API”和“月床营收结算 SQL”盎接泚册䞺 Data Agent 的预眮 Skill。䞚务人员提问时Agent 䌚䌘先调甚这些高可靠的既有资产而䞍再消耗算力去重新生成 SQL。

场景 2语义暡型绎技:

䞚务需求变化需芁新增"VIP 客户"的定义。赵工圚语义暡型层曎新定义所有盞关查询自劚生效无需修改底层 SQL。

场景 3权限管理:

新员工入职赵工配眮其数据访问权限可以查看销售数据䜆看䞍到成本数据可以访问汇总衚䜆䞍胜查看明细。所有访问行䞺被完敎记圕。

场景 4审计䞎合规:

审计郚闚芁求提䟛某敏感数据的访问记圕。赵工通过审计日志快速富出完敎的访问铟谁圚什么时闎通过什么查询访问了哪些数据。

期望䜓验:

  • 细粒床的权限控制胜力
  • 完敎的操䜜审计日志
  • 系统监控和告譊机制
  • 易于绎技的语义暡型配眮

4. 系统架构讟计

平台基于高内聚、䜎耊合的四层架构讟计。由倖及里甚户界面层莟莣倚端亀互意囟捕获L2 代理猖排层充圓“倧脑”进行任务拆解䞎审批拊截栞心胜力层提䟛 NL2SQL 䞎可视化生成匕擎底层基础讟斜层则通过统䞀语义暡型和沙箱环境保障查询的准确䞎安党执行。

4.1 敎䜓架构囟

# 系统四层架构讟计囟UI 层、代理猖排层、栞心胜力暡块层、基础讟斜层
┌─────────────────────────────────────────────────────────────────────────────┐
│                           甚户界面层 (UI Layer)                               │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐ │
│  │  Chat UI    │  │  REST API   │  │   Webhook   │  │  Mobile Dashboard   │ │
│  │  (Web/桌面)  │  │  (第䞉方集成)│  │  (事件掚送)   │  │  (管理层视囟)        │ │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘  └──────────┬──────────┘ │
└─────────┌────────────────┌────────────────┌────────────────────┌────────────┘
          │                │                │                    │
          └────────────────┮────────────────┮────────────────────┘
                                    │
                                    ▌
┌─────────────────────────────────────────────────────────────────────────────┐
│                       L2 代理猖排层 (Agent Orchestration)                     │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                        记忆䞎状态管理 (Memory & State)                │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 短期记忆      │  │ 长期记忆      │  │ 䞊䞋文持久化                │   │    │
│  │  │ (对话䞊䞋文)   │  │ (甚户偏奜)    │  │ (Context Persist)        │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│                                    â–Œ                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                        意囟识别暡块 (Intent Recognition)              │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 查询分类噚     │  │ 实䜓抜取      │  │ 意囟消歧/柄枅              │   │    │
│  │  │ (NLU Engine) │  │ (NER)        │  │ (Clarification)          │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│                                    â–Œ                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      执行计划生成 (Plan Generation)                   │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 任务分解      │  │ 工具/Skill 选择│  │ 䟝赖关系构建               │   │    │
│  │  │ (Decomposer) │  │ (Tool Select)│  │ (DAG Builder)            │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│                                    â–Œ                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      SOP 䞎技胜猖排 (Skill & SOP Orchestrator)        │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ Skill 匹配    │  │ API 参数提取  │  │ 倚步 SOP 状态管理          │   │    │
│  │  │ (Matcher)    │  │ (Extraction) │  │ (State Tracker)          │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│                                    â–Œ                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      人类圚环控制 (Human-in-the-loop)                 │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 审批工䜜流     │  │ 眮信床评䌰    │  │ 反銈收集                   │   │    │
│  │  │ (Approval WF)│  │ (Confidence) │  │ (Feedback Loop)          │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▌
┌─────────────────────────────────────────────────────────────────────────────┐
│                      栞心胜力暡块 (Core Capability Modules)                   │
│                                                                             │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌────────────┐ │
│  │   NL2SQL 匕擎    │ │  NL2VIS 匕擎    │ │  数据准倇匕擎     │ │ 报告生成噚   │ │
│  │  ┌───────────┐  │ │  ┌───────────┐  │ │  ┌───────────┐  │ │ ┌────────┐ │ │
│  │  │ 语义解析   │  │ │  │ 囟衚掚荐    │  │ │  │ 数据发现   │  │ │ │ NLG    │ │ │
│  │  │ SQL 生成   │  │ │  │ 亀互构建    │  │ │  │ 数据集成   │  │ │ │ 暡板    │ │ │
│  │  │ 查询䌘化   │  │ │  │ 枲染匕擎    │  │ │  │ 数据枅掗   │  │ │ │ 调床    │ │ │
│  │  └───────────┘  │ │  └───────────┘  │ │  └───────────┘  │ │ └────────┘ │ │
│  └─────────────────┘ └─────────────────┘ └─────────────────┘ └────────────┘ │
│                                                                             │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐                │
│  │   TableQA 匕擎   │ │  统计分析匕擎     │ │  匂垞检测匕擎     │                │
│  │  ┌───────────┐  │ │  ┌───────────┐  │ │  ┌───────────┐  │                │
│  │  │ 衚栌理解   │  │ │  │ 描述统计    │  │ │  │ 时序匂垞   │  │                │
│  │  │ 倚衚掚理   │  │ │  │ 假讟检验    │  │ │  │ 分垃匂垞   │  │                │
│  │  │ 聚合计算   │  │ │  │ 盞关分析    │  │ │  │ 关联匂垞   │  │                │
│  │  └───────────┘  │ │  └───────────┘  │ │  └───────────┘  │                │
│  └─────────────────┘ └─────────────────┘ └─────────────────┘                │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▌
┌─────────────────────────────────────────────────────────────────────────────┐
│                      基础讟斜层 (Infrastructure Layer)                        │
│                                                                             │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      语义暡型䞎知识库                                  │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 䞚务术语词兞   │  │ 技胜/API 泚册衚│  │ 衚关系囟谱                │   │    │
│  │  │ 字段语义映射   │  │ (Skill Reg)  │  │ 瀺䟋查询库                 │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      执行匕擎                                         │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ SQL 执行噚    │  │ DuckDB 沙箱   │  │ 猓存层 (Redis)            │   │    │
│  │  │ 查询䌘化噚     │  │ (物化API结果) │  │ 结果猓存/查询猓存           │   │    │
│  │  └──────────────┘  └──────▲───────┘  └──────────────────────────┘   │    │
│  │                           ┊                                         │    │
│  │                           ┊ (FR-072 联邊查询Skill 结果物化䞺䞎时衚)   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      权限䞎安党                                       │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 身仜讀证      │  │ 访问控制       │  │ 数据脱敏                  │   │    │
│  │  │ (SSO/OAuth)  │  │ (RBAC/ABAC)  │  │ (Masking)                │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▌
┌─────────────────────────────────────────────────────────────────────────────┐
│                      数据源层 (Data Source Layer)                            │
│                                                                             │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌────────────┐ │
│  │  关系型数据库     │ │  数据仓库/湖      │ │  文件系统        │ │  API/SaaS  │ │
│  │  ┌───────────┐  │ │  ┌───────────┐  │ │  ┌───────────┐  │ │ ┌────────┐ │ │
│  │  │ MySQL     │  │ │  │ Snowflake │  │ │  │ CSV       │  │ │ │ REST   │ │ │
│  │  │ PostgreSQL│  │ │  │ Databricks│  │ │  │ Excel     │  │ │ │ GraphQL│ │ │
│  │  │ Oracle    │  │ │  │ BigQuery  │  │ │  │ Parquet   │  │ │ │ ERP    │ │ │
│  │  │ SQL Server│  │ │  │ ClickHouse│  │ │  │ JSON      │  │ │ │ CRM    │ │ │
│  │  └───────────┘  │ │  └───────────┘  │ │  └───────────┘  │ │ └────────┘ │ │
│  └─────────────────┘ └─────────────────┘ └─────────────────┘ └────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘

4.2 数据流描述

标准查询䞎 Skill 䌘先流皋

# 标准数据查询流蜬党过皋
1. 甚户蟓入 → 意囟识别暡块解析查询意囟和实䜓
2. 意囟拊截 → 检查是吊匹配预定义的 Data Skill已有 API 或 SOP
3. 匹配 Skill → 提取参数盎接调甚底层数据服务 API绕过 NL2SQL
4. 未匹配 Skill → 语义暡型层将䞚务术语映射䞺数据库对象并走标准 NL2SQL 路线
5. 执行计划生成噚构建操䜜 DAG
6. 人类圚环控制评䌰是吊需芁审批
7. 栞心胜力暡块执行具䜓任务API 调甚 / NL2SQL / NL2VIS 等
8. 执行匕擎圚沙箱环境䞭运行查询
9. 权限安党层进行结果过滀和脱敏
10. 结果返回给甚户同时记圕审计日志

猓存䌘化流皋

# 倚级猓存䌘化机制的执行流皋
1. 查询到蟟 → 检查查询猓存盞同查询
2. 猓存呜䞭 → 盎接返回猓存结果
3. 猓存未呜䞭 → 检查语义等价猓存䞍同衚述盞同意囟
4. 执行查询 → 结果存入倚级猓存
5. 元数据变曎 → 自劚倱效盞关猓存

错误倄理流皋

# 匂垞捕获䞎智胜修倍重试流皋
1. 查询执行倱莥 → 错误分类语法错误 / 超时 / 权限䞍足 / 数据源䞍可甚
2. 语法错误 → 自劚重写 SQL 并重试最倚 3 次
3. 超时 → 尝试查询简化或拆分提瀺甚户猩小查询范囎
4. 权限䞍足 → 返回权限诎明匕富甚户申请权限
5. 数据源䞍可甚 → 䜿甚猓存结果劂有或告知甚户圓前服务受限
6. 所有重试倱莥 → 记圕诊细错误信息返回友奜的错误描述和建议操䜜

审批䞭断䞎恢倍流皋

# 审批流皋䞭的䞊䞋文䞭断䞎恢倍机制
1. 任务觊发审批 → 任务状态讟䞺“埅审批”持久化存傚执行䞊䞋文
2. 通知审批人 → 甚户收到“等埅审批䞭”状态提瀺
3. 审批通过 → 恢倍执行䞊䞋文继续执行后续任务
4. 审批拒绝 → 终止任务向甚户返回拒绝原因和替代建议
5. 审批超时默讀 24 小时→ 觊发升级规则或自劚取消通知甚户重新发起

4.3 各层暡块职莣诎明

架构层 栞心暡块 职莣描述
甚户界面层 Chat UI、REST API、Webhook、Mobile Dashboard 提䟛倚端接入胜力统䞀请求栌匏后蜬发至猖排层
L2 代理猖排层 意囟识别、SOP 䞎技胜猖排、执行计划生成、人类圚环控制 解析意囟䌘先匹配 Skill构建执行 DAG圚关键节点觊发审批
栞心胜力暡块层 NL2SQL、NL2VIS、TableQA、报告生成、匂垞检测 执行具䜓的数据查询、API 调甚、分析、可视化和报告生成任务
基础讟斜层 语义暡型、执行匕擎、权限安党 管理䞚务语义映射、沙箱执行查询、区制执行访问控制
数据源层 关系型数据库、数据仓库/湖、文件、API 提䟛底层数据存傚和访问接口

本节明确了系统圚䞍同数据合规䞎成本芁求䞋的物理郚眲拓扑支持从完党隔犻的私有化环境到匹性可扩展的混合云架构平滑切换。

4.4 郚眲架构

系统支持以䞋䞀种郚眲暡匏

  • 私有化郚眲所有组件郚眲圚客户 VPC 内数据䞍出域适合金融、医疗等监管䞥栌的行䞚
  • 混合云郚眲控制平面和 LLM 掚理可郚眲圚公有云数据平面保留圚客户环境适合成本敏感场景

关键郚眲纊束

  • 无状态服务讟计支持 Kubernetes 猖排
  • LLM 掚理层支持 GPU 节点独立扩猩
  • 数据平面䞎控制平面眑络隔犻
  • 支持蓝绿郚眲和灰床发垃

本节划定了系统架构讟计的前眮蟹界条件明确了诞劂“只读访问原则”䞎“元数据䟝赖”等䞍可速越的工皋底线。

4.5 技术纊束䞎假讟

  • 所有数据源均通过只读连接访问系统䞍对源数据库执行写操䜜
  • LLM 掚理延迟䞍纳入系统 SLA 计算受䞉方服务圱响
  • 单次查询返回结果集䞊限䞺 10,000 行超出郚分需通过富出任务倄理
  • 系统假讟底层数据源已完成基本的数据治理衚呜名规范、字段泚释等

5. 功胜需求

系统的栞心胜力版囟由八倧功胜子暡块构成暪跚从数据源接入数据准倇、䞚务抂念映射语义层到自然语蚀对话取数、可视化自劚枲染再到高级掞察报告生成以及已有 API 技胜集成SOP的完敎生呜呚期并圚党铟路䞭嵌入了人机协同机制。

5.1 自然语蚀取数NL2SQL

本暡块是实现“对话即分析”理念的基石通过匕入倧暡型䞎数据库词法的深床融合机制将猺乏结构化特埁的自然语蚀蟓入皳定蜬化䞺语法正确、性胜高效的 SQL 方蚀。该暡块深床解耊了语蚀理解䞎物理执行确保生成铟路的安党性。

5.1.1 语义暡型管理

䜜䞺沟通䞚务层䞎数据基建的桥梁本暡块允讞数据管理员建立䞀套䞎物理衚隔犻的逻蟑语义层Semantic Layer通过同义词词兞、KPI 参数化公匏以及跚衚关联囟谱圻底消陀倧暡型圚解析䞓有䞚务黑话时的“幻觉”。

FR-001: 䞚务抂念映射:

  • 系统应支持将䞚务术语劂"掻跃甚户"、"GMV"映射到数据库衚和字段
  • 支持同义词配眮劂"销售额"="GMV"="Revenue"
  • 支持层级抂念劂"北京"→"华北"→"党囜"

FR-002: KPI 定义管理

  • 系统应支持预定义 KPI 的计算逻蟑劂"留存率 = 次日登圕甚户数 / 圓日新增甚户数"
  • KPI 定义应支持参数化劂时闎窗口、过滀条件
  • KPI 变曎应自劚同步到所有盞关查询

FR-003: 跚衚关联配眮

  • 系统应支持可视化配眮衚之闎的关联关系JOIN 条件
  • 支持䞻倖键自劚识别和建议
  • 支持倍杂关联路埄倚跳 JOIN的自劚发现和䌘化

FR-004: 语义暡型版本控制

  • 语义暡型变曎应支持版本管理
  • 支持灰床发垃和回滚
  • 变曎圱响分析哪些查询䌚受圱响

5.1.2 䞊䞋文增区

本暡块通过构建䞚务瀺䟋库䞎甚户偏奜记忆䜿埗自然语蚀解析胜借充分结合历史语境䞎䞪人习惯星著提升倍杂查询的意囟呜䞭率。

FR-005: 瀺䟋查询库

  • 系统应绎技垞见查询的瀺䟋库
  • 支持基于盞䌌床的瀺䟋检玢参考 Databricks Genie Knowledge Store [3]
  • 支持甚户收藏䞪人垞甚查询

FR-006: 列级元数据

  • 系统应存傚列的诊细元数据数据类型、取倌范囎、䞚务含义、枚䞟倌诎明
  • 支持自劚元数据采集基于数据采样和统计分析
  • 支持敏感数据自劚标记

FR-007: 对话䞊䞋文管理

  • 系统应圚倚蜮对话䞭保持䞊䞋文
  • 支持指代消解劂"刚才的结果"、"那䞪衚"
  • 支持查询条件的继承和修改

FR-008: 甚户偏奜孊习

  • 系统应孊习甚户的查询习惯和偏奜
  • 支持䞪性化查询建议
  • 支持垞甚绎床和指标的自劚掚荐

5.1.3 查询生成䞎执行

本暡块涵盖从基础单衚检玢到倚衚倍杂 JOIN 的党量 SQL 算子生成逻蟑并匕入基于成本的䌘化噚以确保执行效率。

FR-009: 单衚查询生成

  • 系统应支持简单的单衚 SELECT 查询生成
  • 支持 WHERE 条件等于、范囎、暡糊匹配、IN 列衚
  • 支持 ORDER BY 和 LIMIT

FR-010: 倚衚 JOIN 查询

  • 系统应支持倚衚 JOIN 查询的自劚生成
  • 支持 INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL JOIN
  • 自劚选择最䌘 JOIN 顺序和类型

FR-011: 倍杂查询支持

  • 系统应支持子查询Subquery生成
  • 支持 CTE公甚衚衚蟟匏
  • 支持窗口凜数ROW_NUMBER、RANK、LAG、LEAD 等
  • 支持聚合凜数和 GROUP BY

FR-012: 查询䌘化

  • 系统应对生成的 SQL 进行䌘化
  • 支持基于成本的执行计划分析
  • 参考 Alpha-SQL MCTS 方法 [2] 进行查询重写䌘化

FR-013: 查询执行沙箱

  • 所有查询应圚隔犻的沙箱环境䞭执行
  • 支持查询超时控制默讀 30 秒可配眮
  • 支持资源限制CPU、内存、返回行数

5.1.4 验证䞎修正

本暡块圚 SQL 执行前䞎执行后匕入了双重校验机制旚圚前眮拊截高危扫描操䜜并自劚修正语法猺陷确保系统敎䜓可甚性。

FR-014: 执行计划验证

  • 系统应圚执行前验证 SQL 的执行计划
  • 检测朜圚的性胜问题党衚扫描、笛卡尔积等
  • 高风险查询自劚觊发人工审批

FR-015: 结果䞀臎性检查

  • 系统应对查询结果进行合理性验证
  • 检测匂垞倌䞎历史数据对比
  • 检测空结果和匂垞倧结果集

FR-016: 成本䌰算

  • 系统应䌰算查询的执行成本
  • 对高成本查询进行预譊
  • 支持成本配额管理按甚户/郚闚

FR-017: 成本硬拊截䞎预算控制

  • 支持讟眮甚户级/郚闚级的单次查询最倧扫描数据量及预䌰莹甚阈倌
  • 圓查询预䌰超出阈倌时必须区制人工审批或自劚拒绝
  • 实时监控 Token 消耗及查询算力成本觊蟟预算䞊限后熔断服务

FR-018: 查询修正建议

  • 圓查询倱莥时系统应提䟛修正建议
  • 支持语法错误的自劚修倍
  • 支持䞚务逻蟑错误的柄枅和匕富

5.2 智胜数据分析TableQA + 统计分析

脱犻了纯粹的数据检玢本暡块赋予了 Agent “初级数据分析垈”的数倌掚理胜力。通过内眮圚内存沙箱䞭的 Pandas/DuckDB 匕擎系统䞍仅胜针对䞎时挂蜜的子衚进行倚跳关联提问还胜执行同比环比等倍杂的分析论证。

5.2.1 衚栌问答

面对高频的 Ad-hoc 查询本功胜支持甚户对已经抜取的“宜衚”或“䞎时视囟”盎接发问系统将利甚结构化数据掚理技术Table-based Reasoning圚无需重写底层 SQL 的前提䞋完成跚行/列的数倌提取。

FR-019: 单衚问答

  • 系统应支持基于单匠衚的问答
  • 支持事实查询劂"最高的销售额是倚少"
  • 支持比蟃查询劂"A 和 B 哪䞪曎高"

FR-020: 倚衚掚理

  • 系统应支持跚倚匠衚的掚理问答
  • 自劚识别所需的衚和关联关系
  • 支持倚跳掚理劂"莭买过 A 商品的甚户䞭有倚少人莭买了 B 商品"

FR-021: 聚合统计

  • 系统应支持各类聚合计算求和、平均、计数、最倧最小倌
  • 支持分组统计按时闎、类别、地区等绎床
  • 支持占比和同比环比计算

5.2.2 高级分析

本暡块突砎了䌠统取数的局限通过匕入时序预测䞎園因分析算法赋予系统深床的数据挖掘䞎根因诊断胜力。

FR-022: 趋势分析

  • 系统应自劚识别数据趋势䞊升、䞋降、平皳、呚期性
  • 支持趋势拟合和预测
  • 支持趋势变化的拐点检测

FR-023: 匂垞检测

  • 系统应自劚检测数据匂垞犻矀倌、突变、匂垞暡匏
  • 支持时序数据的匂垞检测
  • 支持匂垞原因的初步分析

FR-024: 关联分析

  • 系统应支持变量之闎的盞关性分析
  • 支持盞关系数计算和星著性检验
  • 支持关联规则挖掘适甚于亀易数据

FR-025: 根因分析

  • 系统应支持简单的根因分析
  • 支持绎床䞋钻分析劂销售额䞋降 → 按地区分析 → 按品类分析
  • 支持莡献床分析各因玠对变化的莡献

5.3 可视化展现NL2VIS + 亀互匏囟衚

本暡块打砎了䌠统 BI 拖拜配囟的高闚槛匕入自然语蚀到可视化NL2VIS倚暡态代理架构。通过理解数据特埁的统计孊意义䞎甚户提问的隐性意囟自劚䞺底层数据挂蜜最䌘的视觉映射规则同时保留䞰富的亀互匏䞋钻接口。

5.3.1 自劚囟衚掚荐

本暡块旚圚消陀“选择哪种囟衚最合适”的决策阻力。它根据返回结果的数据类型劂时闎序列、地理坐标、分类变量智胜生成诞劂折线囟、热力囟或南䞁栌尔玫瑰囟等最䜳枲染配眮。

FR-026: 智胜囟衚类型选择

  • 系统应根据数据特埁自劚掚荐最合适的囟衚类型
  • 支持折线囟趋势、柱状囟对比、饌囟占比、散点囟盞关性等
  • 支持倚绎床数据的囟衚类型掚荐

FR-027: 囟衚配眮自劚生成

  • 系统应自劚生成囟衚的标题、坐标蜎标筟、囟䟋
  • 支持颜色和䞻题的自劚配眮
  • 支持数据标筟和提瀺信息的自劚生成

FR-028: 倚囟衚组合

  • 系统应支持䞀䞪查询返回倚䞪盞关囟衚
  • 支持囟衚之闎的关联和联劚
  • 支持仪衚盘风栌的垃局

5.3.2 亀互匏功胜

本暡块区调囟衚生成的灵掻性䞎二次猖蟑胜力支持甚户通过自然语蚀远问或拖拜操䜜对现有视囟进行深床䞋钻䞎联劚分析。

FR-029: 数据钻取

  • 甚户应胜借圚囟衚䞊进行䞋钻操䜜劂从幎 → 月 → 日
  • 支持自定义钻取路埄
  • 支持䞊卷Roll-up操䜜

FR-030: 数据过滀

  • 甚户应胜借圚囟衚䞊进行亀互匏过滀
  • 支持点击囟䟋筛选
  • 支持范囎选择过滀

FR-031: 囟衚联劚

  • 倚䞪囟衚之闎应支持联劚亀互
  • 圚䞀䞪囟衚䞊的选择应同步过滀其他囟衚
  • 支持联劚状态的保存和分享

FR-032: 囟衚富出

  • 甚户应胜借富出囟衚䞺囟片PNG、SVG
  • 支持富出䞺亀互匏 HTML
  • 支持嵌入代码生成

5.3.3 仪衚盘构建

本暡块支持将碎片化的单囟衚聚合䞺党局䞚务看板并提䟛灵掻的垃局定制䞎权限分发机制满足管理层的宏观监控需求。

FR-033: 可视化仪衚盘

  • 系统应支持甚户创建䞪人仪衚盘
  • 支持拖拜匏垃局调敎
  • 支持实时数据刷新

FR-034: 倖郚工具集成

  • 系统应支持富出到 Tableau、Power BI 等倖郚工具
  • 支持生成兌容的数据文件和连接配眮
  • 参考 nvAgent 框架 [6]processing agent → construction agent → validation agent

5.4 分析报告自劚生成

本暡块臎力于解决呚报、月报及倧型䞓题分析报告等重床囟文混排场景的人力消耗。系统䞍仅聚合查询结果曎通过倧暡型匕入倚绎床掞察Insights䞀键蟓出可䟛盎接向管理层汇报的䌁䞚级幻灯片䞎文档。

5.4.1 NLG 数据掞察

䜜䞺“看囟诎话”的数字助理该功胜胜借基于阈倌譊报或星著波劚䜿甚自然语蚀Natural Language Generation智胜撰写数据背后的䞚务事实免去人工園因解读的脑力成本。

FR-035: 自劚掞察生成

  • 系统应䜿甚 NLG 技术将数据发现蜬换䞺文本叙述
  • 支持关键指标的自然语蚀描述
  • 支持匂垞和趋势的自劚解读

FR-036: 数据故事讲述

  • 系统应胜借构建数据故事Data Storytelling
  • 支持时闎线叙事过去 → 现圚 → 预测
  • 支持问题-分析-结论的结构化叙述

FR-037: 倚语蚀支持

  • 系统应支持䞭文和英文的掞察生成
  • 支持䞚务术语的本地化衚蟟
  • 支持语气和风栌的配眮正匏/蜻束

5.4.2 报告暡板

本暡块预眮了芆盖䞻流䞚务场景的标准化报告框架同时支持䌁䞚级视觉规范的深床定制确保蟓出产物的䞓䞚床䞎品牌䞀臎性。

FR-038: 预定义报告暡板

  • 系统应提䟛倚种报告暡板
    • 执行摘芁Executive Summary关键指标、䞻芁发现、行劚建议
    • 诊细分析报告数据背景、分析方法、诊细结果、局限性诎明
    • 定期报告日报、呚报、月报暡板

FR-039: 自定义报告暡板

  • 甚户应胜借创建自定义报告暡板
  • 支持暡板变量的定义
  • 支持条件内容根据数据劚态星瀺/隐藏

FR-040: 报告栌匏富出

  • 系统应支持富出䞺 PDF、Word、PPT 栌匏
  • 支持邮件正文栌匏的报告
  • 支持 Markdown 栌匏富出

5.4.3 定期调床

本暡块通过匕入 CRON 衚蟟匏䞎事件驱劚机制实现了分析报告的无人倌守生成䞎倚枠道自劚化分发。

FR-041: 报告调床配眮

  • 甚户应胜借配眮报告的定期生成和分发
  • 支持按日、呚、月、季床调床
  • 支持条件觊发劂匂垞发生时自劚发送

FR-042: 分发枠道

  • 系统应支持倚种分发枠道
    • 邮件发送
    • 䌁䞚埮信/钉钉/飞乊机噚人
    • Webhook 回调
    • 系统内消息通知

5.5 数据准倇胜力P2 需求第䞉方元数据集成

Data Agent 的栞心价倌圚于“读䞎析”而非“写䞎掗”。䞺了避免陷入自研庞倧 ETL 匕擎的泥札本暡块聚焊于䞎䌁䞚既有数据治理资产的集成通过获取高莚量的元数据䞊䞋文䞺 Agent 提䟛充足的分析背景。

5.5.1 元数据平台集成

本暡块提䟛标准化的适配噚实现䞎䞻流匀源及商䞚数据目圕系统的打通以只读方匏获取䌁䞚党局数据地囟。

FR-043: 第䞉方 DataHub/OpenMetadata 集成

  • 系统应支持䞀键接入 DataHub、OpenMetadata 等䞻流元数据管理平台
  • 支持定时同步衚结构、字段泚释及䞚务术语定义
  • 支持读取䞊枞系统沉淀的数据血猘关系

FR-044: 元数据语义搜玢

  • 甚户胜借通过自然语蚀搜玢已集成的元数据资产
  • 自劚将元数据平台的 Tag 和 Glossary 蜬化䞺 Agent 的䞊䞋文
  • 支持基于䞚务描述的盞䌌床数据集掚荐

FR-045: 数据莚量状态读取

  • 系统应胜借读取第䞉方数据莚量平台劂 Great Expectations的监控状态
  • 圚 Agent 执行分析前若检测到源衚倄于“莚量告譊”状态需向甚户发出风险提瀺

5.6 倚数据源连接

䞺了满足䞭倧型䌁䞚的倍杂眑络架构需求系统通过插件化的连接噚讟计实现了对关系型数据库、倧数据仓库生态及䞉方 API 的党方䜍芆盖圻底打砎数据孀岛。

5.6.1 关系型数据库

䜜䞺倧倚数䌁䞚 ERP/CRM 系统的底层承蜜本暡块提䟛了针对䞻流 RDBMS 的高性胜、加密只读连接适配。系统支持特定数据库方蚀的盎接翻译䞎执行。

FR-046: MySQL 支持

  • 系统应支持 MySQL 5.7+ 版本的连接
  • 支持标准 SQL 方蚀
  • 支持 SSL/TLS 加密连接

FR-047: PostgreSQL 支持

  • 系统应支持 PostgreSQL 10+ 版本的连接
  • 支持 PostgreSQL 特有特性JSONB、数组类型等
  • 支持 SSL 连接和证乊讀证

FR-048: Oracle 支持

  • 系统应支持 Oracle 11g+ 版本的连接
  • 支持 Oracle PL/SQL 存傚过皋调甚
  • 支持 Oracle 特有的数据类型

FR-049: SQL Server 支持

  • 系统应支持 SQL Server 2016+ 版本的连接
  • 支持 T-SQL 方蚀
  • 支持 Windows 讀证和 SQL Server 讀证

5.6.2 数据仓库/湖

本暡块规范了系统䞎䞻流倧数据分析平台劂 Hive、Spark、Snowflake的深床对接标准䞎䞋掚执行策略。

FR-050: Snowflake 支持

  • 系统应支持 Snowflake 连接
  • 支持 Snowflake 特有的语法劂 SEMI JOIN
  • 支持 Snowflake Semantic Views 集成

FR-051: Databricks 支持

  • 系统应支持 Databricks SQL Warehouse 连接
  • 支持 Unity Catalog 集成
  • 支持 Delta Lake 特性

FR-052: BigQuery 支持

  • 系统应支持 Google BigQuery 连接
  • 支持 BigQuery 标准 SQL 方蚀
  • 支持分区衚和嵌套字段

FR-053: ClickHouse 支持

  • 系统应支持 ClickHouse 连接
  • 支持 ClickHouse 特有的数据类型和凜数
  • 支持分垃匏衚查询

FR-054: Hive 支持

  • 系统应支持 Apache Hive 连接
  • 支持 HiveQL 方蚀
  • 支持分区衚和桶衚

5.6.3 文件数据源

本暡块支持对非结构化或半结构化文件CSV、Excel、JSON的快速解析䞎䞎时衚挂蜜分析。

FR-055: CSV 支持

  • 系统应支持 CSV 文件的䞊䌠和查询
  • 自劚检测猖码和分隔笊
  • 支持倧文件分块倄理

FR-056: Excel 支持

  • 系统应支持 Excel (.xlsx, .xls) 文件
  • 支持倚 Sheet 选择和合并
  • 支持公匏计算结果的读取

FR-057: Parquet 支持

  • 系统应支持 Parquet 栌匏文件
  • 支持列匏存傚䌘化查询
  • 支持嵌套数据结构

FR-058: JSON 支持

  • 系统应支持 JSON 和 JSONL 文件
  • 支持嵌套结构的展平和查询
  • 支持 JSON Schema 掚断

5.6.4 API 数据源

本暡块允讞系统通过 REST/GraphQL 接口实时抓取倖郚劚态数据打砎䌁䞚内郚数据孀岛。

FR-059: REST API 支持

  • 系统应支持 REST API 䜜䞺数据源
  • 支持倚种讀证方匏API Key、OAuth、Basic Auth
  • 支持分页和速率限制倄理

FR-060: GraphQL 支持

  • 系统应支持 GraphQL API 连接
  • 支持查询生成和变量䌠递
  • 支持嵌套数据的自劚展平

FR-061: ERP/CRM 连接噚

  • 系统应提䟛垞见 ERP/CRM 系统的预眮连接噚
  • 包括 Salesforce、SAP、Oracle ERP 等
  • 支持标准对象和自定义对象

5.7 人机协䜜功胜

本系统拒绝盲目远求“完党自劚驟驶”而是通过讟计闭环的反銈铟路䞎析进匏的授权䜓系让倧暡型圚䞎人类的协同䞭䞍断进化从而构筑皳固的䞚务信任床。

5.7.1 甚户反銈

䜜䞺数据飞蜮Data Flywheel的栞心驱劚力本暡块允讞甚户通过星匏的点赞、螩及打标操䜜䞺系统沉淀宝莵的对霐样本Alignment Data从而反哺埮调倧暡型。

FR-062: 即时反銈

  • 甚户应胜借对每次查询结果提䟛反銈正确/错误/郚分正确
  • 支持错误类型的标泚理解错误、SQL 错误、数据错误
  • 支持修正蟓入甚于暡型孊习

FR-063: 查询收藏

  • 甚户应胜借收藏垞甚查询
  • 收藏时可添加标筟和倇泚
  • 支持从收藏生成瀺䟋查询库

FR-064: 反銈分析

  • 系统应定期分析甚户反銈
  • 识别高频问题和改进点
  • 生成暡型䌘化建议报告

5.7.2 信任建立

本暡块通过提䟛可解释的执行计划䞎诊尜的数据血猘远螪垮助䞚务人员透视“黑盒”建立对 AI 生成结果的长期信任。

FR-065: 透明床展瀺

  • 系统应展瀺查询的蜬换过皋自然语蚀 → SQL
  • 展瀺数据来源和计算逻蟑
  • 展瀺眮信床评分和䟝据

FR-066: 析进匏授权

  • 新甚户初始权限受限随着䜿甚历史和信任积环逐步攟匀
  • 高风险操䜜需芁额倖的信任验证劂 MFA
  • 支持䞎时权限提升垊时限

FR-067: 信任床评分

  • 系统应绎技甚户的信任床评分
  • 基于历史行䞺准确率、违规记圕等计算
  • 信任床圱响审批流皋和权限蟹界

FR-068: 审批䞭断恢倍机制

  • 支持任务状态的持久化存傚圓觊发人工审批时Agent 自劚保存圓前执行䞊䞋文
  • 审批通过后系统胜借从断点恢倍执行计划避免因等埅过久富臎䌚话超时或让甚户重试
  • 支持讟眮审批超时自劚取消及通知机制

5.8 数据技胜䞎 SOP 猖排

本暡块旚圚集成䌁䞚已有倧数据平台和成熟数据仓库积环的 API、数据资产䞎标准操䜜皋序SOP通过“预定义技胜Skill”机制实现 NL2API 的盎接调甚。

5.8.1 API 䞎技胜泚册

FR-069: 数据 API 接入

  • 支持无猝泚册䌁䞚已有的倧数据平台对倖提䟛的查询 API
  • 支持 OpenAPI/Swagger 规范自劚解析䞎富入 API 端点
  • 统䞀管理各内郚系统的讀证鉎权机制劂 JWT、OAuth

FR-070: 技胜Skill元数据定义

  • 将具䜓的 API 封装䞺 Data Skill并䞺其配眮自然语蚀描述、觊发关键词䞎意囟
  • 支持定义 Skill 的入参/出参 Schema以及参数的枚䞟映射关系
  • 支持圚暡型无法通过 NL2SQL 盎接查询到底层宜衚时䌘先建议甚户调甚盞关 Skill

5.8.2 SOP 猖排执行

FR-071: 倚步 SOP 猖排

  • 支持将倚䞪独立的 Data Skill 䞲联猖排䞺䞀䞪倍杂数据分析 SOP
  • 支持 SOP 䞭的䞊䞋文变量䌠递劂䞊䞀步 API 返回的郚闚 ID 䜜䞺䞋䞀步 API 的入参
  • 支持垊有条件刀断分支If-Else的技胜调甚流

FR-072: 混合查询执行

  • 允讞同䞀䞪甚户䌚话䞭既包含对已有数据 API 的 Skill 调甚也包含实时生成的 NL2SQL 查询
  • 支持将 API 返回的结构化数据盎接䜜䞺䞎时衚䞎数仓䞭已有衚进行联邊查询Federated Query䞎关联分析

FR-073: 技胜结果猓存TTL

  • 支持对 Data Skill 的返回结果讟眮 TTLTime-To-Live猓存策略
  • 针对䜎频变曎数据劂郚闚列衚讟眮长猓存劂 1 小时针对高频数据劂实时库存讟眮短猓存或䞍猓存0 秒
  • 降䜎后端 API 的并发压力提高 Agent 响应速床

6. 非功胜需求

䜜䞺面向䞭倧型䌁䞚的商䞚系统陀了实现基础的䞚务功胜系统圚性胜指标响应延迟、高并发、安党基线行列级权限、脱敏、高可甚架构以及合规审计方面必须蟟到极其䞥苛的生产级 SRE站点可靠性工皋标准。

本节量化了系统圚极端并发场景䞋的吞吐䞎延迟基准确保圚党公叞范囎内掚广时栞心䞚务的䞝滑䜓验。

6.1 性胜需求

䞺了保障良奜的甚户䜓验系统对各类栞心操䜜讟定了䞥栌的响应时闎基准。

NFR-001: 查询响应时闎 SLA

查询类型 P50 目标 P99 目标 诎明
简单查询单衚、少量数据 < 2 秒 < 5 秒 呜䞭猓存的场景
倍杂查询倚衚 JOIN、聚合 < 10 秒 < 30 秒 需芁实际执行的查询
报告生成 < 30 秒 < 2 分钟 包含 NLG 的完敎报告

NFR-002: 系统可甚性

  • 系统可甚性目标99.5%月床
  • 计划内绎技窗口每月䞍超过 4 小时需提前 72 小时通知
  • 故障恢倍时闎目标RTO< 30 分钟
  • 数据恢倍点目标RPO< 5 分钟

NFR-003: 并发倄理胜力

  • 系统应支持 100-1000 并发甚户根据郚眲规暡
  • 查询队列管理圓并发超过限制时请求进入队列等埅
  • 支持查询䌘先级的劚态调敎

NFR-004: 猓存性胜

  • 查询猓存呜䞭率目标> 60%
  • 猓存曎新延迟< 5 秒元数据变曎后
  • 支持倚级猓存内存猓存 + 分垃匏猓存

6.2 安党需求

本节明确了系统的安党基线包括行列级权限控制䞎敏感数据脱敏策略保障䌁䞚数据资产绝对安党。

NFR-005: 行级安党RLS

  • 系统应支持基于甚户属性的行级数据过滀
  • 支持劚态 RLS 策略根据查询䞊䞋文调敎
  • RLS 策略应䜜甚于所有查询路埄包括富出和 API

NFR-006: 列级安党CLS

  • 系统应支持列级数据访问控制
  • 支持敏感列的自劚识别和标记
  • 支持基于角色的列级权限配眮

NFR-007: 数据脱敏

  • 系统应支持敏感数据的劚态脱敏
  • 脱敏规则包括掩码劂手机号 138****8888、哈垌、截断、替换
  • 支持基于甚户权限的差匂化脱敏策略

NFR-008: Agent 级权限执行

  • Data Agent 应圚执行层区制执行权限控制
  • 防止通过提瀺泚入等方匏绕过权限
  • 所有权限检查应记圕审计日志

NFR-009: 数据䌠蟓加密

  • 所有数据䌠蟓应䜿甚 TLS 1.3 加密
  • 支持证乊固定Certificate Pinning
  • 敏感数据圚日志䞭应脱敏存傚

NFR-010: 密钥管理

  • 数据库凭证和 API 密钥应䜿甚䞓甚密钥管理系统
  • 支持密钥的定期蜮换
  • 支持硬件安党暡块HSM集成

6.3 审计䞎合规

本节规定了系统的审计日志及合规芁求确保系统的所有操䜜均可远溯。

NFR-011: 完敎审计日志

  • 系统应记圕所有数据访问和操䜜行䞺
  • 审计日志包括甚户 ID、时闎戳、操䜜类型、查询内容、访问数据范囎、执行结果
  • 审计日志应防篡改保留期限䞍少于 1 幎

NFR-012: 数据血猘远螪

  • 系统应绎技数据血猘关系
  • 支持从报衚远溯到原始数据源
  • 支持血猘圱响分析变曎圱响范囎

NFR-013: GDPR 合规

  • 支持甚户数据富出数据可携垊权
  • 支持甚户数据删陀被遗忘权
  • 支持数据倄理掻劚的记圕和报告

NFR-014: SOC2 合规

  • 满足 SOC2 Type II 控制芁求
  • 支持控制证据的自劚收集
  • 支持审计员的只读访问

6.4 可扩展性

本节明确了系统的扩展机制和倚租户胜力䞺未来䞚务的快速增长提䟛技术保障。

NFR-015: 氎平扩展胜力

  • 系统应支持氎平扩展以应对莟蜜增长
  • 无状态服务讟计支持莟蜜均衡
  • 数据库层支持读写分犻和分片

NFR-016: 倚租户架构

  • 系统应支持倚租户郚眲
  • 租户之闎的数据隔犻粒床䞍䜎于 Schema 级别
  • 支持租户级别的资源配额和计莹

NFR-017: 插件扩展机制

  • 系统应提䟛插件机制支持自定义功胜
  • 支持自定义数据源连接噚
  • 支持自定义分析算法和可视化组件

6.5 可靠性

本节定义了系统圚面对故障时的韧性讟计䞎恢倍策略。

NFR-018: 故障蜬移

  • 系统应支持高可甚郚眲
  • 关键组件应有䞻倇或集矀郚眲
  • 支持自劚故障检测和切换

NFR-019: 健康检查

  • 系统应提䟛健康检查端点
  • 支持组件级别的健康状态报告
  • 支持䟝赖服务数据库、猓存、LLM的健康监控

NFR-020: 䌘雅降级

  • 圓郚分服务䞍可甚时系统应䌘雅降级
  • 栞心查询功胜圚䟝赖服务故障时仍可工䜜䜿甚猓存或简化逻蟑
  • 向甚户明确提瀺圓前的服务限制

NFR-021: 数据倇仜

  • 系统配眮和元数据应定期倇仜
  • 支持增量倇仜和党量倇仜
  • 支持跚区域倇仜容灟

6.6 数据源连接可靠性

本节规定了对底层数据源的连接池管理及匂垞熔断机制避免拖垮䞚务数据库。

NFR-022: 连接池管理

  • 系统应䞺每䞪数据源绎技独立的连接池
  • 连接池倧小、空闲超时、最倧生呜呚期均可配眮
  • 支持连接池监控和告譊耗尜、泄挏

NFR-023: 连接故障恢倍

  • 数据源连接倱莥时应自劚重试采甚指数退避策略最倧重试 3 次
  • 支持连接健康检测定期心跳检查
  • 匕入熔断机制圓某䞪数据源连续倱莥蟟到讟定阈倌劂 5 分钟内倱莥 10 次应自劚熔断该数据源连接池避免雪厩效应拖垮 Agent 服务
  • 连接䞍可甚时应自劚觊发降级策略并通知甚户

NFR-024: 连接超时控制

  • 连接建立超时默讀 10 秒可配眮
  • 查询执行超时默讀 30 秒可配眮
  • 超时后应自劚释攟连接资源并返回友奜提瀺

NFR-025: LLM 幻觉监控

  • 系统应建立指标监控甚户的“点螩率Thumbs Down Rate”
  • 圓针对某䞪知识库或衚结构的 NL2SQL 准确率突然䞋降或点螩率飙升时劂因底层暡型曎新富臎的数据挂移胜借自劚觊发告譊通知管理员介入

NFR-026: 倚暡型 Fallback 自劚降级

  • 系统需支持倧暡型 API 超时、限流或宕机时的自劚降级切换
  • 圓䞻力暡型劂 GPT-4o䞍可甚时请求必须胜无猝 Fallback 至倇选暡型劂 GPT-4o-mini 或本地郚眲暡型以保障栞心对话取数铟路的连续性

7. 人机协䜜暡型

系统拒绝采甚黑盒化的完党自䞻范匏而是创新性地匕入了基于眮信床的“人类圚环Human-in-the-loop”审批干预机制既保证了自劚化执行的高效性又通过析进匏授权䞎反銈回路构建了牢固的䞚务信任基石。

本节诊细定义了觊发人工介入的具䜓风险阈倌䞎䞊䞋文挂起/恢倍流皋是 L2 级别“条件自劚化”圚工皋䞊的具象䜓现。

7.1 审批机制讟计

䞺平衡效率䞎安党系统制定了明确的审批觊发阈倌确保关键操䜜始终有人工介入。

审批觊发条件

觊发条件 审批级别 审批人 诎明
基础讟斜变曎 高 IT 管理员 新增数据源、修改连接配眮
访问策略变曎 高 数据 Owner + 安党团队 权限调敎、角色变曎
跚工䜜流任务 äž­ 数据 Owner 涉及倚䞪䞚务域的分析
高风险操䜜 高 IT 管理员 + 䞚务莟莣人 数据删陀、批量曎新
䜎眮信床结果 äž­ 终端甚户 暡型眮信床 < 阈倌
高成本查询 䜎 系统自劚 超出配额时提瀺确讀

审批流皋

# 任务审批路由流蜬瀺意囟
┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ 任务提亀 │ → │ 风险评䌰 │ → │ 审批路由 │ → │ 人工审批 │ → │ 执行/拒绝│
└─────────┘    └─────────┘    └─────────┘    └─────────┘    └─────────┘
                    │               │               │
                    ▌               ▌               ▌
               ┌─────────┐    ┌─────────┐    ┌─────────┐
               │ 自劚通过 │    │ 升级规则 │    │ 审批委托 │
               │ (䜎风险) │    │ (超时)   │    │ (猺垭)   │
               └─────────┘    └─────────┘    └─────────┘

7.2 眮信床分级

本节定义了系统基于䞍同执行眮信床所采取的分级干预策略确保回答的准确床。

眮信床评䌰绎床

  1. 语义理解眮信床NLU 对查询意囟的理解皋床
  2. 映射眮信床䞚务术语到数据暡型的映射确定性
  3. 结果眮信床查询结果的统计合理性
  4. 安党眮信床权限蟹界和敏感数据倄理的确定性

分级倄理流皋

# 基于暡型眮信床的分级倄理策略矩阵
┌─────────────────────────────────────────────────────────────────┐
│                        眮信床分级倄理                            │
├──────────────────────────────────────────────────────────────────
│                                                                 │
│  高眮信床 (> 90%)                                               │
│  ├── 盎接执行无需确讀                                          │
│  └── 记圕日志甚于持续孊习                                      │
│                                                                 │
│  䞭眮信床 (70% - 90%)                                           │
│  ├── 展瀺执行计划请求甚户确讀                                  │
│  ├── 提䟛倇选方案劂果有                                      │
│  └── 甚户确讀后执行                                              │
│                                                                 │
│  䜎眮信床 (< 70%)                                               │
│  ├── 停止自劚执行                                                │
│  ├── 向甚户请求柄枅                                              │
│  ├── 提䟛可胜的意囟选项                                          │
│  └── 蜬人工倄理可选                                          │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

7.3 反銈回路

本节描述了系统基于甚户反銈进行持续自我挔进的暡型训练铟路。

持续孊习机制

# 闭环持续孊习䞎反銈机制数据流
┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ 甚户反銈 │  →  │ 莚量评䌰 │ → │ 样本筛选  │  → │ 暡型埮调 │
└─────────┘    └─────────┘    └─────────┘    └─────────┘
                                              │
                                              ▌
┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ 效果监控 │  ← │ A/B 测试 │  ← │ 灰床发垃 │  ← │ 暡型验证  │
└─────────┘    └─────────┘    └─────────┘    └─────────┘

本节探讚了劂䜕通过“透明化掚富过皋”避免甚户对倧暡型产生过床䟝赖或盲目䞍信任建立健康的人机协同蟹界。

7.4 信任校准

人机协䜜暡型䞭的信任建立机制通过 FR-065: 透明床展瀺、FR-066: 析进匏授权 和 FR-067: 信任床评分 实现诊见第 5.7.2 节。


8. 技术选型建议

圚栞心组件的实现路埄䞊产品借向于解耊性高、䞍绑定单䞀公有云厂商的匀攟生态组件。通过敎合高性胜的本地沙箱匕擎劂 DuckDB、标准化的语义层工具劂 dbt/Cube搭配可插拔的匂构倧语蚀暡型闭源高粟床/匀源䜎成本构筑兌顟成本䞎性胜的最䜳实践组合。

8.1 倧语蚀暡型

本节评䌰并掚荐了适甚于䞍同场景和安党芁求的基础倧暡型。

以䞋暡型掚荐基于圓前的技术评䌰实际选型时应根据圓时最新的基准测试结果和成本效益重新评䌰。

䜿甚场景 掚荐暡型 倇选方案 选型理由
高粟床 NL2SQL GPT-4o / Claude 3.5 Sonnet Qwen-72B / DeepSeek-V2 倍杂掚理胜力区SQL 准确性高
成本敏感场景 GPT-4o-mini / Claude 3 Haiku Qwen-7B / GLM-4-9B 性价比高适合高频查询
私有化郚眲 Llama 3.1 70B / Qwen-72B Baichuan2-13B 支持本地郚眲数据䞍出域
领域特化 Fine-tuned CodeLlama Fine-tuned StarCoder 针对䌁䞚 Schema 埮调

倚暡型 Fallback 策略高可甚保障 系统圚架构䞊必须支持倚暡型级联降级。圓䞻力暡型劂 GPT-4o遭遇 API 超时、限流Rate Limit或宕机时系统应自劚䞔无感地将请求 Fallback 至倇选暡型劂 GPT-4o-mini 或本地私有化郚眲暡型确保栞心对话取数铟路的连续性而非盎接向甚户抛出匂垞报错。

8.2 Agent 框架

本节对比了圓前䞻流的 Agent 匀发框架及其圚䌁䞚级应甚䞭的适配床。

框架 适甚场景 䌘势 劣势
LangChain 通甚场景 生态䞰富集成床高 孊习曲线蟃陡
LlamaIndex 知识密集型 检玢增区胜力区 倍杂工䜜流支持有限
AutoGen 倚 Agent 协䜜 对话匏猖皋灵掻 生产化皋床埅验证
Semantic Kernel 埮蜯生态 侎 Azure 集成奜 跚平台支持有限

8.3 语义层

本节列䞟了莟莣䞚务逻蟑蜬换䞎指标统䞀的栞心组件候选。

技术 甹途 掚荐场景
dbt 数据蜬换和建暡 已有 dbt 生态的䌁䞚
Apache Iceberg 衚栌匏管理 数据湖场景
Cube.js 语义层和 API 层 需芁统䞀指标服务
LookML (Looker) 语义建暡 已有 Looker 投资

8.4 执行匕擎

本节根据数据倄理的规暡䞎场景掚荐了盞应的高性胜查询匕擎。

匕擎 适甚场景 特点
DuckDB 䞭小规暡分析本地执行 蜻量高性胜易嵌入
Apache Spark 倧规暡数据倄理 分垃匏生态䞰富
Presto/Trino 联邊查询 跚源查询䜎延迟
Apache Arrow 内存计算 列匏存傚向量化执行

8.5 身仜讀证䞎授权

本节给出了系统接入䌁䞚统䞀身仜讀证䜓系的标准方案掚荐。

组件 掚荐方案 诎明
身仜提䟛商 Okta / Azure AD / Keycloak SSO 集成
授权框架 Casbin / Open Policy Agent 细粒床权限控制
数据库 RBAC 原生 RBAC + 代理层检查 双重保险

8.6 数据治理

本节梳理了可䞎 Data Agent 深床敎合的数据莚量䞎元数据管理平台。

组件 掚荐方案 甹途
元数据管理 OpenMetadata / DataHub 数据目圕和血猘
数据莚量 Great Expectations / Soda 莚量规则和执行
䞻数据管理 Collibra / Informatica 䌁䞚级治理

8.7 监控䞎可观测性

本节定义了保障系统可甚性及快速排障的监控运绎工具栈。

组件 掚荐方案 甹途
APM DataDog / New Relic 应甚性胜监控
日志 ELK Stack / Loki 日志收集和分析
指标 Prometheus + Grafana 指标监控和告譊
铟路远螪 Jaeger / Zipkin 分垃匏远螪

9. 挔进路线

产品的生呜呚期管理采取了“敏捷验证 -> 䌁䞚就绪 -> 自䞻升绎”的务实挔进策略。从最初䞉䞪月内打通 NL2SQL 单衚取数 MVP 闭环再到䞀幎内铺匀倚租户䞎党局安党基建最终实现基于因果掚理和䞻劚掞察的 L3 级数据科孊家委托代理暡匏。

9.1 MVP 阶段3-6 䞪月

本阶段的栞心是快速验证系统胜力并圚受限场景䞋建立初步闭环。䞺降䜎初期“暡型幻觉”䞎数据口埄倱控风险本阶段将䌘先萜地“存量数据资产的 AI 智胜化盘掻”策略诊见配套文档《䌁䞚级 Data Agent 敏捷萜地规划存量数据资产的 AI 智胜化盘掻》。

目标通过技胜挂蜜Skill Integration䌘先盘掻已有 API快速闭环并建立䞚务信任同时验证基础 NL2SQL 胜力。

栞心功胜

  • NL2SQL 基础胜力单衚查询、简单 JOIN
  • 基础可视化自劚囟衚掚荐
  • 基础身仜讀证和审计
  • 支持 2-3 种䞻流数据源MySQL、PostgreSQL、Snowflake
  • 明确排陀MVP 阶段䞍包含第 5.5 节“数据准倇胜力”及倍杂的第䞉方元数据集成

技术重点

  • 语义暡型基础框架
  • 查询猓存机制
  • 基础审批工䜜流

成功标准

  • NL2SQL 准确率圚封闭的 10 匠栞心宜衚测试集䞊 > 85%圚党量衚䞊 > 60%
  • 查询响应时闎 P50 < 5s
  • 早期甚户满意床 > 4.0/5.0

9.2 䌁䞚就绪阶段6-12 䞪月

本阶段旚圚完善倚租户、审计䞎安党特性䞺党面掚广铺平道路。

目标满足䌁䞚级郚眲芁求

栞心功胜

  • 倚租户架构
  • 完敎审计和数据血猘
  • 高级安党特性RLS/CLS/脱敏
  • 扩展数据源支持芆盖䞻流数据仓库和文件
  • 报告自劚生成和调床

技术重点

  • 性胜䌘化查询䌘化、猓存策略
  • 高可甚架构
  • 䌁䞚集成SSO、ERP 连接噚

成功标准

  • 系统可甚性 > 99.5%
  • 支持 500+ 并发甚户
  • 通过 SOC2 Type II 审计

9.3 高级胜力䞎 L3 过枡12+ 䞪月

本阶段将系统自䞻性掚向新高床实现从被劚响应到䞻劚掞察的跚越。

目标实现高级分析胜力向 L3 挔进

栞心功胜

  • 工䜜流猖排倚步骀分析自劚化
  • 自劚数据准倇智胜枅掗、集成
  • 预测性分析
  • 䞻劚匏掞察匂垞自劚发现
  • 自然语蚀数据探玢

技术重点

  • Agent 协䜜框架
  • 因果掚理胜力
  • 持续孊习系统

成功标准

  • 倍杂分析任务自劚化率 > 50%
  • 甚户自助率 > 80%
  • 数据准倇时闎减少 70%

10. 风险䞎猓解

䜜䞺前沿的 AI 数据基础讟斜项目䞍仅芁面对 LLM 幻觉Hallucination䞎自然语蚀理解的固有倚义性隟题还需芁应对诞劂䌁䞚数据安党合规、系统级联雪厩倱效等重倧工皋和治理风险。本节䞺栞心嚁胁矩阵讟立了诊尜的干预熔断手段。

10.1 技术风险

本节列䞟了圚架构讟计䞎暡型应甚层面的技术障碍及应对手段。

风险 圱响 抂率 猓解措斜
NL2SQL 准确性䞍足 高 äž­ 查询验证和人工确讀机制 / 癜名单 SQL 暡匏 / 持续埮调䌘化
权限绕过 高 䜎 Agent 层独立权限检查 / 倚重验证机制 / 林透测试
级联错误 äž­ äž­ PCS 原理验证 / 䞭闎结果检查点 / 错误隔犻机制
LLM 幻觉 äž­ äž­ 结果可验证性讟计 / 眮信床评分 / 人工审栞机制
性胜瓶颈 äž­ äž­ 查询䌘化和猓存 / 资源隔犻和限流 / 氎平扩展胜力

10.2 治理风险

本节针对数据安党及合规领域的朜圚风险提出了前眮规避策略。

风险 圱响 抂率 猓解措斜
数据泄露 高 䜎 端到端加密 / VPC 隔犻 / 数据脱敏 / 最小权限原则
合规违规 高 䜎 合规检查枅单 / 定期审计 / 法务团队审栞
暡型偏见 äž­ äž­ 倚样化测试数据 / 偏见检测机制 / 公平性评䌰
数据莚量问题 äž­ 高 数据莚量监控 / 莚量闚犁 / 数据血猘远螪

10.3 运营风险

本节着県于系统䞊线后的持续运营挑战包括甚户接纳䞎倖郚䟝赖。

风险 圱响 抂率 猓解措斜
LLM 暡型挂移 äž­ äž­ 定期基准测试 / 暡型版本管理 / A/B 测试验证
䟛应商锁定 äž­ äž­ 抜象层讟计 / 倚䟛应商策略 / 自研胜力傚倇
人才短猺 äž­ äž­ 培训计划 / 文档和知识库 / 倖郚䞓家支持
甚户接受床䜎 高 äž­ 析进匏掚广 / 甚户培训 / 反銈闭环䌘化

11. 成功指标

通过对工皋系统的 APM 时延纊束劂 P50 延迟芁求、倚级猓存呜䞭率䞎䞚务团队的䜿甚深床劂每日单兵调甚量、工单猩减率进行北极星指标North Star Metric对霐确保该数据䞭台建讟最终胜借蜬化䞺实打实的䌁䞚人效杠杆。

11.1 技术指标

本节量化了系统底层的性胜、皳定性和准确性预期䜜䞺技术团队的北极星指标。

指标 Phase 1 目标 Phase 2 目标 Phase 3 目标 测量方法
NL2SQL 准确率 栞心宜衚 > 85%  党量衚 > 60% > 90% > 95% 人工标泚测试集
查询延迟 P50 < 5s < 3s < 2s APM 监控
查询延迟 P99 < 30s < 20s < 10s APM 监控
系统可甚性 > 99% > 99.5% > 99.9% 监控告譊
猓存呜䞭率 > 40% > 60% > 70% 猓存监控
甚户反銈满意床 > 4.0/5 > 4.2/5 > 4.5/5 甚户调研

11.2 䞚务指标

本节以最终商䞚价倌䞺富向定义了产品成功掚行的䞚务衚现评䌰绎床。

指标 定义 目标
甚户采甚率 月掻跃甚户数 / 目标甚户总数 > 60% (Year 1)
日均查询量 平均每甚户每倩发起的查询数 > 5 次/人/倩
语义暡型芆盖率 䌁䞚 80% 的垞见查询涉及的字段已被映射䞺䞚务术语 > 80%
暡型 Token 消耗呚环比 每呚 Token 消耗量蟃䞊呚的增长/䞋降比䟋成本控制指标 皳定圚预期预算内
数据请求工单减少率 (原工单数 - 现工单数) / 原工单数 > 50%
掞察获取时闎 从提出问题到获埗掞察的平均时闎 从 2 倩 → 5 分钟
自助服务率 无需人工介入完成的查询占比 > 80%
报告自劚化率 自劚生成的报告占比 > 60%

11.3 安党䞎数据莚量指标

本节区调了系统圚红线合规䞎数据眮信床方面的区制性蟟成标准。

指标 定义 目标 测量方法
权限绕过事件数 经审计确讀的权限绕过成功事件数 0 次/幎 安党审计
数据泄露事件数 未授权数据访问或倖泄事件数 0 次/幎 安党监控
审计日志完敎率 审计日志芆盖的操䜜占比 100% 日志分析
数据准确性评分 查询结果䞎人工验证结果的䞀臎率 > 95% 抜样人工验证
敏感数据脱敏芆盖率 已配眮脱敏规则的敏感字段占比 100% 元数据扫描

12. 竞品对比

立足于目前 Snowflake Cortex Analyst 区绑云原生的封闭生态以及 Databricks Genie 等数据仓库衍生插件工具的垂场栌局我们的方案通过提䟛独立解耊的语义层映射䞎䞭立的数据接入探针实现真正的跚云匂构环境联邊分析。

12.1 竞品对比分析

本节暪向比对了䞚界领先的同类产品分析了它们的䌘势䞎局限。

产品 厂商 定䜍 栞心䌘势 局限性 本系统差匂化
Databricks Genie Databricks 数据仓库原生 AI 助手 侎 Unity Catalog 深床集成Knowledge Store 区倧 区绑定 Databricks 生态 倚数据源䞭立性匀攟架构
Snowflake Cortex Analyst Snowflake 云数仓 AI 分析 Semantic Views䌁䞚级安党 仅支持 Snowflake 跚平台支持混合数据源
BigQuery Data Canvas Google 云数仓可视化分析 侎 GCP 生态集成可视化胜力区 仅限 BigQuery 私有化郚眲支持䌁䞚安党
Microsoft Fabric Copilot Microsoft 统䞀数据分析平台 侎 Office 365 集成生态完敎 区绑定 Azure 匀攟 API第䞉方集成友奜
ThoughtSpot Spotter ThoughtSpot 搜玢匏 BI 领富者 搜玢䜓验成熟性胜䌘化奜 成本蟃高孊习曲线 曎区的 NL2SQL 胜力L2 人机协䜜

12.2 关键差匂化策略

本节園纳了基于竞品分析提炌出的系统栞心竞争壁垒䞎技城河。

  1. 匀攟架构䞍绑定特定数据平台支持混合数据源
  2. L2 人机协䜜曎粟细的人类圚环控制适合监管䞥栌行䞚
  3. 语义暡型䌘先区调语义层建讟降䜎绎技成本
  4. 䌁䞚级安党原生支持 RLS/CLS/脱敏等䌁䞚安党需求
  5. 析进匏智胜化从 L2 向 L3 挔进而非䞀步到䜍

13. 参考文献

[1] Yizhang Zhu et al., "A Survey of Data Agents: Emerging Paradigm or Overstated Hype?," arXiv preprint arXiv:2510.23587, 2025. [2] Boyan Li et al., "Alpha-SQL: Zero-Shot Text-to-SQL using Monte Carlo Tree Search," arXiv preprint arXiv:2502.17248, 2025. [3] Databricks. Databricks Genie Technical Documentation[EB/OL]. [2026-04-07]. https://docs.databricks.com/. [4] Snowflake. Snowflake Cortex Analyst Documentation[EB/OL]. [2026-04-07]. https://docs.snowflake.com/. [5] SAE International. (2021). SAE J3016 - Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles. [6] Geliang Ouyang et al., "nvAgent: Automated Data Visualization from Natural Language via Collaborative Agent Workflow," arXiv preprint arXiv:2502.05036, 2025.