Metabase + dbt
适合先建立基础指标看板，再叠加 AI 问数能力
- Metabase 上手快，适合业务团队日常分析
- dbt 负责口径建模与指标一致性治理
- 适合作为 AI 分析助手的稳定数据底座
先统一指标口径再开放自然语言查询。
开源项目怎么选
先根据数据治理成熟度选底座，再决定问数层复杂度。
Superset + 语义层
适合数据规模较大、权限复杂的企业分析场景
- Superset 可承载复杂可视化和权限配置
- 配合语义层降低口径漂移风险
- 适合构建“报表 + AI 解读”双轨体系
需要更完整的数据工程支持。
Lightdash + dbt
适合以指标字典和业务语义为核心的团队
- Lightdash 与 dbt 协同，口径治理更清晰
- 适合做“业务提问 -> 指标回答”闭环
- 便于减少跨团队解释成本
上线前需完善指标命名与文档规范。
DuckDB + LlamaIndex/LangChain
适合个人或小团队做本地化分析助手原型
- DuckDB 轻量，适合快速本地分析
- 结合 LlamaIndex/LangChain 快速接入问答层
- 适合先验证自然语言查询体验
生产环境需补齐权限与审计能力。
场景速查：怎么选技术路线
我希望业务同学直接问数据，不再频繁找数据团队
Metabase + dbt + AI 问数层
先保证指标一致，再开放自然语言问答最稳。
我有复杂组织权限和多数据域
Superset + 语义层
更适合企业级权限与可视化治理。
我想重点解决指标口径不一致问题
Lightdash + dbt
指标定义可复用，减少“同名不同义”。
我是个人开发者，想先低成本验证
DuckDB + LlamaIndex/LangChain
本地可跑、迭代快，适合 MVP。
个人可搭建技术路线
先做口径治理，再开放问数能力，能显著降低返工成本。
01
指标盘点
先定义核心业务指标和计算口径，做统一字典。
02
语义建模
把业务术语映射到可查询的数据模型和字段。
03
问数接入
接入自然语言查询层，提供 SQL 解释和结果可追溯。
04
评估迭代
持续优化问数成功率、准确率和业务采纳率。
最小可行架构（MVP）
数据源
DB / DWH / SaaS 数据
建模层
dbt / 语义模型
查询层
NL2SQL / Query Guard
分析层
BI 看板 + AI 解读
治理层
权限 / 审计 / 监控
上线后盯哪些指标
问数成功率
Answered / Asked
衡量用户提问后是否得到可用回答。
口径一致率
Metric Consistency
衡量同一指标在不同场景是否一致。
分析时效
Time to Insight
衡量从提问到获得决策信息的耗时。
业务采纳率
Adoption Ratio
衡量分析结果是否被业务实际采用。
上线前检查清单
建议优先做
- 先开放核心指标，再扩展长尾分析
- 回答结果要可追溯到 SQL/数据来源
- 高风险查询加入权限与规则限制
- 建立“错误问题 -> 修复模型”闭环
常见风险点
- 指标口径未统一就开放全量问数
- 忽视 SQL 权限控制，带来数据泄露风险
- 只看回答流畅度，不看结果正确性
- 没有审计日志，问题无法回溯
自然语言问数一定要带权限与 SQL 审计，否则会把数据风险放大到业务端。