Text2SQL 系列博客 08：4 步选型法（下）- 评估打分与最终决策

系列目录（共 15 篇） ：

1-7（略）

8. 4 步选型法（下）：评估打分与最终决策（本文）

9-15（略）

关键词：技术选型决策、加权评分、雷达图对比、PoC 验证、风险评估、最终决策

---

目录

• 一、写在前面：从标准到决策
• [二、第 3 步：评估打分](#二、第 3 步：评估打分)
• 三、加权评分模板
• 四、雷达图对比
• 五、风险评估
• [六、第 4 步：最终决策](#六、第 4 步：最终决策)
• 七、决策矩阵
• [八、PoC 验证](#八、PoC 验证)
• 九、推演示例：某金融公司的决策过程
• 十、总结

---

一、写在前面：从标准到决策

上一篇我们讲了明确场景 和定义标准 ，这一篇讲评估打分 和最终决策。

核心问题：

候选项目有 5 个，怎么客观对比？
评估结果出来后，怎么做最终决策？

这一篇我会给你一套实战可用的评估和决策方法。

---

二、第 3 步：评估打分

2.1 评估的三层结构

评估不是简单的"打分"，而是一个三层结构：

第 1 层：加权评分（量化对比）
   ↓
第 2 层：雷达图（直观对比）
   ↓
第 3 层：风险评估（识别坑点）

2.2 加权评分法的核心公式

总分 = Σ（标准得分 × 标准权重）

2.3 评分的客观性保证

原则 1：多维度打分

不要只用一个总印象分，要按维度打分。

原则 2：多人打分

至少 3 个人独立打分，避免主观偏差。

原则 3：基于事实

每个分数都要有依据，不能拍脑袋。

原则 4：权重透明

权重设定要提前公开，避免事后调整。

---

三、加权评分模板

3.1 评分表模板

我设计了一个标准评分表，可以直接用：

标准	权重	SuperSonic	DB-GPT	WrenAI	SQLBOT
场景匹配度	35%	9	9	8	8
语义管理	30%	10	7	6	9
易用性	25%	6	5	9	8
生态	10%	8	10	8	7
加权总分	100%	8.45	7.45	7.60	8.15

3.2 详细评分依据示例

以 SuperSonic 为例：

场景匹配度：9 分（满分 10）

依据：

• ✅ 业务自助分析 ✓ （9 分）
• ✅ 复杂多表查询 ✓ （9 分）
• ✅ 归因分析 △ （8 分）
• 加权：9 × 0.6 + 9 × 0.3 + 8 × 0.1 = 8.9 ≈ 9

语义管理：10 分（满分 10）

依据：

• ✅ Metric Registry ✓ （10 分）
• ✅ 实体建模 ✓ （10 分）
• ✅ 强制消歧 ✓ （10 分）
• ✅ Owner 责任体系 ✓ （10 分）

易用性：6 分（满分 10）

依据：

• ⚠️ 业务同学需培训 △ （6 分）
• ⚠️ 部署较复杂 △ （5 分）
• ✅ 文档质量 ✓ （7 分）

生态：8 分（满分 10）

依据：

• ✅ GitHub 5,100（2026-09 抓取） stars （8 分）
• ✅ Issue 响应快 （8 分）
• ✅ 文档完整 （8 分）

3.3 加权计算过程

总分 = 9 × 0.35 + 10 × 0.30 + 6 × 0.25 + 8 × 0.10
     = 3.15 + 3.00 + 1.50 + 0.80
     = 8.45

3.4 多项目对比

项目	总分	排名
SuperSonic	8.45	🥇
SQLBOT	8.15	🥈
WrenAI	7.60	🥉
DB-GPT	7.45	4
Vanna	5.20	5

---

四、雷达图对比

4.1 为什么用雷达图？

雷达图能直观展示多维度对比：

• 一眼看出每个项目的"形状"
• 识别优势和短板
• 横向对比多个项目

4.2 4 个核心候选的雷达图

SuperSonic
         场景匹配 9
              ▲
             /|\
            / | \
           /  |  \
          /   |   \
         /    |    \
   SQL  ◀─────●─────▶ 语义管理 10
  生成 9 \    |    / 
          \   |   /
           \  |  /
            \ | /
             \|/
              ▼
          易用性 6

解读：

• 场景匹配、SQL 生成、语义管理都很强
• 易用性是短板（Java 栈部署重）

4.3 多个项目叠加对比

把 4 个项目的雷达图叠加：

SuperSonic:    9-10-6-8 (强语义)
DB-GPT:        9-7-5-10 (强生态)
WrenAI:        8-6-9-8 (强易用)
SQLBOT:        8-9-8-7 (强语义+强易用)

直观看出：

• SQLBOT 是均衡派
• SuperSonic 偏语义牺牲易用
• DB-GPT 偏生态牺牲易用
• WrenAI 偏易用牺牲语义

4.4 用雷达图识别"短板"

SuperSonic: 易用性 6（短板）
DB-GPT: 易用性 5（短板）
WrenAI: 语义管理 6（短板）
SQLBOT: 全部均衡（无明显短板）

截图位置 1：4 个项目的雷达图叠加对比

---

五、风险评估

5.1 为什么需要风险评估？

加权评分只反映当前能力 ，不反映未来风险。

项目	当前评分	主要风险
SuperSonic	8.45	Java 栈部署复杂，未来可能不够灵活
DB-GPT	7.45	学习曲线陡，团队可能用不起来
WrenAI	7.60	语义层薄弱，复杂查询准确率风险
SQLBOT	8.15	商业化倾向，长期可能受限

5.2 风险评估维度

维度 1：技术风险

风险点	影响	缓解措施
部署复杂	落地慢	预留 PoC 时间
学习曲线陡	团队不接受	提前培训
大模型依赖	成本高	多模型备份
性能瓶颈	体验差	性能测试

维度 2：业务风险

风险点	影响	缓解措施
准确率不达标	业务不信任	PoC 验证
数据口径混乱	决策错误	语义治理
用户不接受	推广失败	用户调研
流程改变	阻力大	渐进式推进

维度 3：组织风险

风险点	影响	缓解措施
团队能力不足	项目失败	培训 + 外包
资源投入不够	项目搁置	高层支持
部门协调困难	推进慢	跨部门项目组
维护成本高	长期负担	简化架构

维度 4：未来风险

风险点	影响	缓解措施
项目停滞	后续无更新	选择活跃项目
技术过时	3-5 年后淘汰	关注架构趋势
厂商绑定	切换困难	优先开源
政策风险	合规问题	提前评估

5.3 风险评分

给每个风险打分（1-10 分，分数越低风险越大）：

项目	技术风险	业务风险	组织风险	未来风险	加权平均
SuperSonic	6	7	8	8	7.25
DB-GPT	6	6	5	9	6.50
WrenAI	8	7	8	7	7.50
SQLBOT	7	7	8	7	7.25

---

六、第 4 步：最终决策

6.1 决策的 3 个层级

第 1 层：基于评分选 Top 1
   ↓
第 2 层：基于风险评估修正
   ↓
第 3 层：基于实际情况拍板

6.2 不能只看总分

反面案例（示意，非真实项目记录）：

某公司选了评分最高的 SuperSonic
但团队不熟悉 Java，部署阶段反复卡住
最后换了 Vanna，反而更快落地

教训：评分是参考，不是唯一标准。

6.3 最终决策的 5 大考量

考量 1：评分排名

按加权总分排名，Top 1 优先考虑

考量 2：风险评估

如果有重大风险，Top 1 可能不是最优选择

考量 3：团队实际能力

团队能不能 hold 住这个项目

考量 4：实施成本

包括部署成本、培训成本、运营成本

考量 5：未来扩展性

能不能支撑未来 3-5 年的发展

6.4 决策矩阵

把多个考量综合到一个矩阵里：

考量维度	权重	SuperSonic	DB-GPT	WrenAI	SQLBOT
加权评分	50%	8.45	7.45	7.60	8.15
风险评估	20%	7.25	6.50	7.50	7.25
团队匹配	15%	8	6	9	7
实施成本	10%	6	6	9	7
未来扩展	5%	8	9	7	7
综合得分	100%	7.95	7.05	7.85	7.80

结论：

• SuperSonic 综合得分最高，但实施成本分低
• WrenAI 综合得分次高，但语义管理弱
• 最终选择要根据公司具体情况

---

七、决策矩阵

7.1 单选 vs 组合

决策类型 1：单选（适合小公司）

直接选 1 个项目，全力投入

决策类型 2：组合（适合大公司）

SuperSonic 做语义层底座
DB-GPT 做上层应用
WrenAI 做业务前端

7.2 组合方案的优势

┌────────────────────────────────┐
│   WrenAI（业务前端）            │
│   - 体验好                      │
└────────────┬───────────────────┘
             ↓ 调用
┌────────────────────────────────┐
│  SuperSonic（语义层）           │
│  - 指标统一                     │
│  - 权限管控                     │
└────────────┬───────────────────┘
             ↓ 调用
┌────────────────────────────────┐
│  DB-GPT（复杂 Agent）           │
│  - 数据应用                     │
└────────────────────────────────┘

7.3 决策树

场景：企业级 BI 落地
   ↓
Q1：团队有没有 Java 能力？
   ├─ 是 → 候选 SuperSonic、SQLBOT
   └─ 否 → 候选 DB-GPT、WrenAI
       ↓
Q2：是否需要复杂语义治理？
   ├─ 是 → 候选 SuperSonic、SQLBOT
   └─ 否 → 候选 WrenAI、DB-GPT
       ↓
Q3：是否需要 Agent 应用？
   ├─ 是 → 加 DB-GPT
   └─ 否 → 单选 SuperSonic/SQLBOT
       ↓
Q4：预算和时间？
   ├─ 充足 → SuperSonic + DB-GPT 组合
   └─ 紧张 → WrenAI 单选

---

八、PoC 验证

8.1 为什么必须做 PoC？

核心理由：

Demo 不能替代 PoC。Demo 是厂商环境，PoC 是你的真实环境。

PoC（Proof of Concept）验证 = 真实环境、真实数据、真实场景。

8.2 PoC 验证清单

必测场景：

• Top 5 业务查询场景
• 复杂多表查询（5+ 表 JOIN）
• 模糊查询（"上个月大概..."）
• 数据权限（不同角色看到不同数据）
• 性能压测（并发 10 个用户）

必测能力：

• 准确率（至少 80%）
• 响应时间（< 3 秒）
• 异常处理
• 权限管控

8.3 PoC 周期

推荐 PoC 周期：2-4 周

第 1 周：环境搭建
第 2 周：真实数据接入
第 3 周：业务场景验证
第 4 周：评估报告

8.4 PoC 评估报告

PoC 结束后，输出一份评估报告：

1. 测试场景覆盖度
2. 准确率测试结果
3. 性能测试结果
4. 用户体验评估
5. 问题清单
6. 最终推荐

---

九、推演示例：某金融公司的决策过程

本节的公司背景、人数、天数、准确率与效果数字全部是虚构的教学推演，不是任何真实项目的记录，也不构成对任何厂商产品效果的陈述。

9.1 公司背景

• 行业：金融
• 规模：5000 人
• 数据团队：30 人
• 业务团队：500+ 人

9.2 决策过程

第 1 阶段：明确场景（1 周）

核心场景：
1. 业务自助分析（80%）
2. 监管报表自动生成（15%）
3. 风险分析（5%）

关键约束：
- 必须符合金融监管要求
- 必须支持细粒度权限
- 必须支持行级数据脱敏

第 2 阶段：定义标准（1 周）

场景匹配度：35%
语义管理：30%
合规能力：20%
易用性：10%
生态：5%

第 3 阶段：评估打分（2 周）

PoC 候选：SuperSonic、SQLBOT、DB-GPT

评估结果：
- SuperSonic：8.2 分（语义管理强、合规能力强）
- SQLBOT：7.8 分（权限强、商业支持好）
- DB-GPT：7.0 分（生态强但合规弱）

第 4 阶段：最终决策（1 周）

决策：
- 主体：SuperSonic（语义治理底座）
- 补充：DB-GPT（复杂 Agent 应用）
- 不用：WrenAI、SQLBOT

理由：
- SuperSonic 语义层最完整
- 金融合规能力到位
- DB-GPT 补充复杂场景

第 5 阶段：试点落地（3 个月）

试点：
- 选择 1 个业务线（信用卡）
- 治理 20 个核心指标
- 100 个业务同学使用
- 准确率：88%

第 6 阶段：全公司推广（6 个月）

全公司部署：
- 治理 200 个指标
- 1000+ 业务同学使用
- 准确率提升到 92%
- 业务满意度：85%

9.3 关键经验

1. 场景定义要细：不能停留在"业务自助分析"这种大概念
2. 标准要量化：每个标准都要有具体评分细则
3. PoC 必须做：不能直接信厂商演示
4. 试点先行：不要一上来就铺全公司
5. 组合方案：单个项目不够就组合用

---

十、总结

第 3 步：评估打分

• 用加权评分表量化对比
• 用雷达图直观识别优劣势
• 多人打分避免主观偏差

第 4 步：最终决策

• 不能只看总分，要综合考量
• 必须做 PoC 验证
• 大公司优先考虑组合方案

5 大决策考量：

1. 加权评分排名
2. 风险评估结果
3. 团队实际能力
4. 实施成本
5. 未来扩展性

核心认知：

评分是参考，决策要综合考虑。PoC 是必须做的，不是可选的。

---

下一步预告 ：不同场景下的选型推荐矩阵------我会针对 10+ 个具体场景（小团队、大企业、金融、电商、客服等），给出明确的选型推荐。

---

本系列基于 2026 年 6-7 月的公开资料（官方文档、GitHub 仓库、公开分享）整理撰写。凡标注「推演示例」的案例均为教学虚构，不是任何真实项目的记录；未标来源的周期、规模与资源配置区间是作者的经验估算，不是行业统计。文末「本篇依据」列出全部外部事实的来源与抓取日期。

如果你在评估智能问数 / ChatBI 的落地方案，站内私信我说「评估」，我把《企业智能问数落地评估清单》发你；也接企业内训与落地评估（10 年金融/保险/通信数据工程，Oracle OCP、RHCE，做过真实上线与踩坑）。

---

本篇依据（外部事实，统一抓取日期 2026-09-19，Star 数与版本会随时间变化）

• DB-GPT：https://github.com/eosphoros-ai/DB-GPT （20,014★；最新正式 release v0.8.2，2026-08-26）
• SuperSonic：https://github.com/tencentmusic/supersonic （5,100★；由腾讯音乐开源；Java 包根为 com.tencent.supersonic，顶层模块为 auth / chat / common / headless / launchers / webapp / benchmark / docker / evaluation）
• Vanna：https://github.com/vanna-ai/vanna （23,816★；仓库已归档停更，本系列把它作为学习参考，生产选型需先评估自维护成本）
• SQLBot：https://github.com/dataease/SQLBot （dataease 组织，仓库主语言 JavaScript + Python，不是 Java 原生）
• 榜单类分数与厂商宣传数字一律按「厂商宣称 / 第三方整理」标注口径引用，找不到一手出处的不写成事实。