"我们的ChatBI上线半个月，准确率不到50%，老板问我们是不是在做假demo..."
如果你在做ChatBI，或正在评估要不要上ChatBI，相信你遇到过类似问题。
很多团队以为"ChatBI就是用大模型做自然语言到SQL的转换"。
有时还会被领导质疑："找个开源项目3天就能搞定，你们怎么用了这么久？"
几度陷入自我怀疑...
要知道，单纯依赖开源项目做ChatBI，就像指望买辆车就能参加F1比赛。
前不久我研究了高德准确率接近90%的ChatBI方案，和他们对另外10%的完整兜底方案。
这篇文章不仅带你扫盲ChatBI的基础，还会带你深度拆解高德案例。
告诉你为什么只靠text2sql注定走不通，以及如何构建真正可用的ChatBI系统。
看完你就会明白，那些准确率90%的ChatBI产品，背后到底做对了什么。
做了这么多ChatBI项目，我发现：很多人对ChatBI的理解有偏差。
ChatBI分为Chat和BI。
BI，Business Intelligence。
大家第一反应都是"商业智能"，高大上，但太抽象。
Business，除了"商业"，也指"业务"。
学校有学校的业务，政府有政府的业务，都算Business。
Intelligence除了"智能"，还有"情报"的意思。
比如C.I.A，
所以我更倾向于把BI理解为"业务情报"。
情报的本质是提供"洞察"，那业务情报的本质就是提供"业务洞察"。比如：
电商平台的运营人员，每天面对海量的销售数据、用户行为数据。
如果只盯着这些原始数据看，很难发现什么规律。
BI系统对这些数据做"采集、存储、处理"等一系列处理，最后生成可视化图表。
运营就能发现：哪个品类表现突出、哪个渠道转化率下滑、用户什么时间最活跃。
这些发现，就是业务洞察。
BI是"通过业务情报，辅助人获得业务洞察的系统"，Chat是"聊天"，
因此，ChatBI是"通过聊天的方式来获取业务洞察的系统"。
传统BI只能看图表，ChatBI可以直接聊。
以往，使用传统BI，业务部门想了解数据，得找技术部门：
业务："帮我做个报表，看看上月各品类销售情况。"
技术："好，明天给你。"
业务："我很急..."
技术："大家都很急...你们pk看谁更急..."
业务："..."
现在通过ChatBI，业务直接问系统："上月哪个品类卖得最好？"，系统立即给出答案和相关图表。
但关键在这里：别把ChatBI简单理解为 " 自然语言查数据库 " 或者 " text2sql " 。
Chat是使用BI成果的交互方式，真正决定业务洞察效果的，还是背后的BI能力。
数据治理做得怎么样？指标体系建得是否合理？这些基础工作才是关键。
与其把精力都放在text2sql的技术实现上，不如多花点时间在数据基础建设上。
毕竟，再智能的对话交互，也无法从混乱的基础数据中，给出你满意的答案。
ChatBI从来不只text2sql，真正的挑战在BI。
每年年初，公司各部门都会提数据分析需求。
市场部："我要看每个省份门店销售排行、同比增长、客流变化。"
运营部："做个库存预警仪表盘，超7天未动销要提醒。"
听起来合理，但这些需求通过邮件、OA、例会，零散汇集到IT部门后，问题就来了。BI项目经理要和数据分析师开需求评审会：梳理优先级、指标定义、可行性...光是怎么算"同比增长"，就能讨论半天。
需求讨论后，数据工程师要去各系统找数据。
"订单、销售明细→ POS系统"
"门店、商品信息→ ERP系统"
"会员活跃度→ CRM系统"
"库存变动→ WMS系统"
这里稍微微解释一下这几个系统的作用：
POS系统：处理门店收银和销售交易，记录每笔买卖
ERP系统：统一管理企业核心资源，如商品、门店、财务、采购等基础信息
CRM系统：管理客户资料、消费行为、会员等级和营销活动，提升客户忠诚度
WMS系统：管理商品入库、出库、库存和仓库作业，确保库存准确高效
每个系统数据库结构不同，接口文档也不都齐全。
数据工程师要一个个对接，整理表名、字段含义。
然后开发ETL脚本：凌晨4点定时任务，从源系统抽取数据，第一次全量，后续增量，存入数据仓库。
然后，真正的问题才刚刚开始。
数据搬过来发现：订单表有重复，产品编码历史上变更过，时间格式不统一，某些字段为空...脏数据层出不穷。
数据开发团队要用SQL脚本清洗：去重、补全、类型统一、逻辑校验。每步都要小心，生怕出错。
还要分层管理，ODS、DWD、DWS、ADS...光记住这些缩写就够头疼。
改一个字段，影响十几个下游表是常事。
BI建模师要设计主题数据模型 。
比如"地区-门店-商品-日期"四维度销售事实表，配上商品、门店、员工维表。
还要定义指标口径："销售额=售价×数量-折扣"。别小看这个公式，光"折扣"怎么计算，业务方就能争论好几轮。
有经验的建模师会预留扩展字段，因为他们知道：业务需求永远在变。
BI工程师开发可视化报表
比如，销售排行TOP10、品类趋势、库存预警...
设计初版后收集业务反馈，然后反复改：
"这个颜色不好看"、"能加个筛选条件吗"、"响应能快点吗"...
每次修改都要重新测试，确保不影响其他功能。
上线后还要设置定时任务：每日凌晨跑脚本生成日报，月初汇总推送管理层...
你以为这就结束了？这只是开始。
比如，区域经理："报表数据异常，销售额平时几万今天只有几十。"
数据团队排查发现："业务系统同步延迟，统计时数据不完整。"
然后和业务IT调整同步策略。
比如，业务部门又有新需求，BI团队评估排期，然后整个流程重新再走一遍。
以上，总结出BI本身的主要流程如下：
1、业务部门提出数据分析需求。
2、数据工程团队定期或实时采集业务系统数据，清洗后统一入数仓。
3、数据分析团队与业务部门反复沟通，基于实际业务场景定义标准的数据模型、指标及统计口径。
4、BI开发团队基于这些模型开发和迭代报表、仪表盘，过程中持续收集业务反馈。
5、最终，通过自动化调度实现报表数据的定期或实时更新，保障各层级数据使用人员及时掌握业务动态。
6、BI团队、数据团队继续接受随时提出的反馈，排查问题、评估新需求能否实现、排期...
这就是传统BI：责任分工清晰，流程规范，但严重依赖人工，自动化有限。
很多时候，业务真正想要的是"告诉我销售为什么下降了？"，或者了解一下"某个指标是如何统计的？"
但得到的却是一堆需要自己解读的图表，指标统计口径更是只有问技术人员才能知道，而技术人员不是那么有空的。
而ChatBI的出现，让我们终于可以用聊天的方式和数据交流。
不用记术语、操作步骤，不需要等长开发周期，像和朋友聊天一样说出疑问，就能得到答案。
这是从 " 人适应工具 " 到 " 工具理解人 " 的转变。
ChatBI带来的新可能
以前：写需求邮件→ 开例会解释 → 你说A我听成B → 再拉人解释
现在：直接问"本月库存报警最多的门店有哪些？" → 10秒内得到报表和分析
以前开发新报表要排队半个月，现在简单的数据探索、图表调整、指标变换，只要会打字就行。
想换个角度？随时切换："去年和今年差异最大的省份是哪个？"AI立即帮你做趋势对比。
以前BI报表满屏专业词汇缩写，业务同事经常问"这活跃用户到底怎么算的？"
现在ChatBI能把复杂指标翻译成人话，业务小白也能看懂。
遇到临时想法，不用写需求文档排队，提出来立马有反馈。这对业务效率的提升是肉眼可见的。
ChatBI让我们终于能用 " 人话 " 和数据对话了。
ChatBI还做不了什么？
数据基础设施仍需人工。比如，后台数据接口对接、源头数据质量治理、 表字段历史变更梳理、源系统更新适配。
AI不可能凭空变出你想要的数据，底层的硬活脏活，还得有人干。
企业级建模需要专家。比如，复杂的数据仓库建模、 跨部门数据定义标准、业务规则的最终拍板。
每家企业业务都不同，AI能建议，但最终决策还得人来做。
权限安全必须人工把控。比如， 数据访问权限设计、不同用户可见范围控制、数据安全策略制定。
数据绝不能"放飞自我"，这块AI帮不上忙。
ChatBI让数据分析变得"接地气"了，每个人都能随手问、天天用，探索的主动权回到业务手里。但基础设施和数据治理这些"水电煤"，还得靠专业团队。只有两边配合，企业才能真正享受到聊天式分析的敏捷体验。
ChatBI不是替代数据团队，而是他们数据治理成果的价值放大器。
ChatBI自身面临的挑战
即使BI基础已经做得很好，想实现ChatBI，仍然要解决这些技术难题：
数据规模
企业级BI系统动辄几百上千张表，每张表几十上百个字段。
这些信息全塞给大模型？就算最新的长上下文模型也会消化不良。
时间语义
用户说"近三年"、"去年同期"、"今年Q1"，人类很容易理解，但让系统准确解析就复杂了。
时间基准点、业务日历、财务年度...这些都需要准确建模。
专业术语
每个行业、每家公司都有自己的"黑话"：财务说"应收账款周转率"、销售说"漏斗转化"、运营说"留存曲线"。
这些概念背后往往有复杂的计算逻辑和业务规则。
我见过一个零售企业，光"有效客户"就有三套不同定义，分别用于不同业务场景。
实体对齐
用户说"北京地区"，数据库里存的可能是："110000"（行政编码）、"Beijing"（英文）、"BJ"（简称）。
用户说"小米手机"，系统里可能是"MI_PHONE"或品牌编码"1001"。
多系统集成环境下，同一概念在不同系统中表示方式完全不同。
复杂推理
最难的是复杂查询推理。
用户问"哪个地区的高价值客户增长最快"，系统需要：
-定义"高价值客户"标准
-跨客户表、订单表、地区表关联查询
-计算不同时间段增长率
-排序筛选结果
这种多步推理对模型逻辑能力要求很高，每一步出错都影响最终结果。
ChatBI的核心难点不在Chat，而在于如何让机器真正理解业务。
技术栈可以选择，算法可以优化，但业务理解需要时间积累和不断调试。
这也是为什么很多团队选择先从简单查询开始，逐步扩展到复杂分析。
不要指望一上来就做到100%准确率，先解决60%的常见查询，剩下的再找方案，但必须找方案。
以上，科普部分就这么多。我终于可以开始聊高德是如何做到90%的准确率了。
高德团队认为："没有一步到位的完美方案，不要想着一上来就解决所有问题。"
他们用"灵活性"和"复杂度"两个维度，将业务场景分成四个象限：
固定场景(第二、三象限)用Chat2API
Chat2SQL在复杂的指标统计下，会涉及"多表关联"，"嵌套查询"，"复杂计算公式"，导致生成正确sql的概率很低。
Chat2API将复杂逻辑封装在后端服务中，还可通过缓存提高响应速度，对外接口往简单去设计，提高生成正确接口参数的概率。
不管简单还是复杂，业务稳定的场景都用Chat2API。
灵活简单场景(第四象限)用Chat2SQL
比如，临时增加的指标，虽然没有提前存储，但可简单统计得出，则使用Chat2SQL。
如果用Chat2API，则每次需求变化都要开发新接口：
查看代码
# 今天的需求：按地区查询销售额
@app.route('/sales/by-region')
def sales_by_region(region):
return db.query(f
"
SELECT SUM(amount) FROM sales WHERE region='{region}'
"
)
# 明天的需求：按时间+地区查询
@app.route('/sales/by-region-time') # 又要新增API
def sales_by_region_time(region, start_date, end_date):
return db.query(f
"
SELECT SUM(amount) FROM sales WHERE region='{region}' AND date BETWEEN '{start_date}' AND '{end_date}'
"
)
# 后天的需求：还要加上产品类型...
# API数量爆炸！而采用Chat2SQL可灵活应对：
查看代码
-- 今天：按地区查询
SELECT SUM(amount) FROM sales WHERE region = '华东';
-- 明天：按时间+地区查询
SELECT SUM(amount) FROM sales
WHERE region = '华东' AND date >= '2024-07-01';
-- 后天：再加产品类型
SELECT SUM(amount) FROM sales
WHERE region = '华东'
AND date >= '2024-07-01'
AND product_type = '电子产品';临时查询、简单统计场景用Chat2SQL。
灵活且复杂的场景(第一象限)，用Agent
对于复杂逻辑的，比如问一些为什么、怎么做、怎么选类似的场景，通常需要多步骤推理。
这不是Chat2API、Chat2SQL这种一次调用/查询，一次生成能搞定的事情。
通过Agent可以在Chat2API、Chat2SQL以及其它tools基础上，灵活组合、多轮调用，然后综合所有结果，得到最终答案。
用户问："为什么A产品的销量下降了？"
仅用Chat2API或Chat2SQL，无法实现。
举个例子：
查看代码
# 用Chat2API，需要预设所有可能的API组合
# 但用户的需求可能是这些的任意组合！
# 且只能调用预设的API，无法进行下一步执行
{
"apis": [
"sales-trend-analysis",
"competitor-analysis",
"market-factor-analysis",
"recommendation-engine",
]
}
# 用Chat2SQL，只能查到数据，然后呢？SQL无法进行下一步分析...
SELECT sales FROM products WHERE name='A'再看看如果用Agent：
为了简化Agent过程，这里把问题收窄，加入时间维度"6月比5月"。
用户问："为什么A产品6月比5月销量下降了？"
首先，Agent会思考到需要搞清楚具体下降了多少；
然后，Agent会调用SQL查询工具获取5月和6月的销量数据；
接着，Agent发现5月1000件，6月800件，下降了20%；
然后，Agent判断20%的下降已经超出正常波动范围，需要深入分析。
接着，Agent思考：这个下降是我们独有的问题，还是整个市场都在下降？ 然后，Agent先调用年同比分析工具，发现去年6月是950件，今年确实下降了。
但这还不够，Agent又调用市场趋势分析工具，发现整个行业实际上增长了2%。
为了进一步确认，Agent还查了竞品数据，发现竞品B增长8%，竞品C持平，竞品D增长3%。
这下Agent明白了：市场整体向好，竞品表现不错，问题确实出在自己身上。
然后，Agent开始拆解问题。
Agent知道"销量=访客数×转化率×客单价"，于是调用销售漏斗分析工具。 结果显示访客数从10000降到8500（下降15%），转化率从5%降到4.7%（下降6%），客单价没变。
Agent分析这些数据后推理：访客大幅下降但转化率相对稳定，说明来的人还是愿意买的，产品本身没问题，主要是来的人少了。
这通常是流量获取的问题。
于是，Agent调用流量来源分析工具，发现付费广告流量下降了35%，而自然搜索和社交媒体流量都在增长5%。
问题锁定了：是广告流量出了问题。
Agent继续深挖，调用广告投放分析工具，发现6月的广告预算从50万减少到35万，下降了30%，但广告的点击率和转化率都保持稳定。
最后，Agent验证整个逻辑链：广告预算削减30%导致广告曝光减少，进而使付费流量下降35%，总访客减少15%，最终销量下降20%。
Agent得出结论：根本原因是广告预算被削减，解决方案就是恢复广告预算，预计恢复后7月销量可以回升到950件。
以上只是示例，具体什么效果，取决我们在Agent上的各种选型和改进策略，以及业务规则、基础数据的完善程度。
具体到Agent策略、机制、主流框架的使用等，后面会专门写文章讲。
这就是高德90%准确率的第一个思路："不同场景用不同策略，而不是一套算法解决所有问题。"
高德数据分析场景中面临的ChatBI挑战
1. Chat2S QL目前仅达到"小学生"水平，但用户总会问"高考题"。
用户不管你能力如何，该问的还是会问。
这就是为什么要用四象限策略，让Chat2SQL只处理它能处理好的简单场景。
2. 元数据质量参 差不齐
现实中的数据表结构有很多历史遗留问题。
不同表或业务线的字段定义规范不一致。
有的描述清晰、口径统一，有的描述模糊、计算规则不明确。
同名字段在不同场景下含义可能完全不同。
3. 相似字段的语 义陷阱
"驾车完成率"：完整用完一次导航的占比；
"驾车成功率"：成功到达目的地的占比。
听起来差不多，但统计口径完全不同，业务含义差异很大。
4. 专业术语的理 解困难
像"导航完成度"、"路线覆盖率"、"实走覆盖率"这些专业术语，模型缺乏足够上下文时很容易理解错误。
5. 模型幻觉问题
生成稍微复杂的SQL时，可能出现：自己造字段、造表别名、造查询条件。
6. 结果一致性问 题
同一个问题，模型可能生成不同SQL，导致结果不同，甚至完全矛盾。
7.错误率10%， 依然影响用户使用
理论上90%准确率听起来不错，但实际业务中：
每100个查询就有10个是错的，用户往往不知道哪个是错的。
8.用户发现问题后 ，往往希望能立即解决
为了不被动响应，需要主动监控查询质量，收集用户反馈，持续迭代优化。
面对这些挑战，高德 团队的思路很清晰：
用户输入无法控制，通过路由分发来使用不同象限的策略；
模型能力有天花板，交给大模型厂商迭代，模型只会越来越强；
剩下的关键战场，就是"元数据质量"和"反馈迭代"。
这就是高德90%准 确率的第二个思路："把有限的精力投入到能控制的关键环节。"
那高德怎么做元数据的？
刚做ChatBI的团队，往往认为只要把表结构这种元数据喂给大模型，就能生成各种想要的查询sql。
而传统表结构信息对ChatBI远远不够。
就像让新同事直接上手复杂业务查询，只给一份表结构说明，他也是一头雾水。
以"上周用户导航UV是多少"为例，模型需要理解：
- 导航UV是什么？对应哪个字段？
- 时间范围如何定义？
高德团队设计了四层元数据：
1. 业务域层，快速定位场景
识别这是导航业务、搜索业务还是路况业务。
2. 表结构层，提供数据基础
表业务含义、字段取值范围、关联关系（决定多表查询准确性）。
3. 业务知识层，处理专业术语和"黑话"
像"导航UV"这种导航业务特有概念，没有专门解释，模型可能理解成网站导航。
4. 通用知识层、标准化常用概念
数据分析常用概念、时间格式定义。
用户提问后，大致会经过下面5步，来得到生成sql 需要的上下文：
- 分析指标项，识别所属业务域
- 分析查询对象和筛选条件，在业务域范围内确定需要的表和字段
- 匹配业务知识，根据指标项找到对应的业务解释
- 标准化通用概念，如时间条件的标准取值
- 上下文生成，将以上信息与用户问题一起给模型生成SQL
做个简单总结：
一般方式：只提供表结构 + 用户问题 → 模型生 成SQL
高德方式：业务域 + 表结构 + 业务知识 + 通用知识 + 用户问题 → 模型生成SQL
模型本身能力有限，但通过精心设计的多层元数据，可大幅提升它对业务的理解能力。
这是高德90%准确率的第三个思路："比起让模型 更聪明，不如给更多上下文。"
尝试过 Chat2SQL 的应该都有感触： 在生成多表关联的sql方面，准确率很 低。
因此，为了降低查询复杂度，通常把多张相关表的字段，构建成一张物理宽表，查询时直接查单表，避免复杂关联。
而物理宽表的问题在于：
存储成本高：字段多、数据量大
维护成本高：底表变化或宽表更改都要重新刷全表
针对这个问题，高德团队提出了"虚拟宽表"的思路。
把"多张底表怎么拼、口径怎么取、权限怎么控"预先写成可查询的"视图"。
虚拟宽表带来的优势很明显：
1. 不用自己写复杂join、最新分区、去重逻辑
2. 口径统一，大家都用同一套视图，统计标准一致
3. 行列权限与脱敏内置到视图中，统一控制
4. 底表变更或接入自定义特征，只改视图即可
5. 需要时，仍可对热点查询进行物化提速
比如，用户问："最近7天各导航策略的活跃用户数？"
数据工程师一次性创建虚拟宽表 ：
查看代码
CREATE VIEW vw_nav_virtual_wide AS
SELECT
a.user_id, a.strategy, a.ds,
p.activity, -- 从用户画像取活跃度
b.select_path, -- 从用户行为取选择路径
c.custom_label -- 预留自定义特征挂接点
FROM nav_detail a
LEFT JOIN user_profile p ON a.user_id = p.user_id
LEFT JOIN user_behavior b ON a.user_id = b.user_id
LEFT JOIN custom_features c ON a.user_id =c.user_id;--灵活扩展点 那么，AI只需要生成下面这个简单的单表查询sql
查看代码
SELECT strategy, custom_label, COUNT(DISTINCT user_id) AS dau
FROM vw_nav_virtual_wide
WHERE ds >= current_date - 7 AND custom_label IS NOT NULL
GROUP BY strategy, custom_label;如果要对宽表添加新业务字段，单独更新custom_features 表即可，
视图会自动包含新字段，无需改底表或重新建模。
相比物理宽表，虚拟宽表避免了：大规模冗余存储、变更响应慢、数据治理困难。
这就是高德90%准确率的第四个思路："一个完美平衡'物理宽表简 单但同步困难'和'关联查询灵活但生成困难'的方案。"
元数据、虚拟宽表等基础设施就绪后，高德开始了ChatBI的三 阶段演化之路。
第一阶段：人怎么写SQL，就用COT(思维链)教大模型怎么写
把所有信息(同义词映射、时间规则、表结构信息、业务口径定义)，塞进一个巨大的prompt，期望模型一步到位写出SQL。
就像让一个人同时做翻译、建模、写代码，任何环节出错都会影响最终结果，规则越加越容易产生冲突。
比如，用户问："帝都昨儿订单多少？"
模型需同时完成：
- "帝都" → "Beijing"
- "昨儿" → 日期
- 选表、聚合、过滤
任一步掉链子就失败。
这个阶段的准确率一般能达到60%就很不错了。
而且维护困难 、对提示词敏感，经常改动提示词后原来正常的地方又出错了。
但好处是，可以快速跑通系统。
第二阶段：引入单Agent + 设计原子工具
给模型设计一箱工具，模型只负责任务理解、规划和工具选择，具体执行逻辑由各个工具负责。
不过仍有痛点：
复杂问题导致工具调用链路变长，准确率峰值波动；
原子工具的提示词依然会膨胀；
对规划与参数一致性要求上升，稳定性需要继续优化。
这个阶段每个工具只负责自己的逻辑，且工具错 误在工具间被隔离，端到端准确率峰值突破到90%，但也常有波动。
第三阶段：设计分子化工具+引入多Agent
将多个相关的原子级工具（元数据检索、语法检查、示例检索等）与特定提示词组合，封装成专门的SQL生成Agent。
这种方式的优势在于：
保持了调用多种工具的灵活性；
通过专门提示词降低单个Agent认知复杂度;
不再需要一个Agent掌握几十上百个工具；
让每个Agent专注使用相关的几个工具，分工更明确、出错率更低
同时，这个阶段设计了 三种不同策略的SQL生成Agent，通过一个独立的SQL仲裁Agent选择最佳方案执行。
策略1：Query Plan CoT（查询计划）
按人的习惯将任务分解成三个关键步骤：
"确定要使用的表"、"在表上做计数、过滤或匹配操作"、"通过选择适当的列返回最终结果"。
策略2：Divide and Conquer CoT （分治）
将复杂问题分解成较小的子问题，先分别生成伪SQL查询(强调逻辑正确而非语义正确)，然后组装起来生成最终可执行的SQL。
策略3：Example Generation（示例生 成）
将用户需求、相关表字段、筛选逻辑，以及与用户需求相似的SQL示例给模型（去除特定业务信息）。
举个例子，用户问："找出2023年北京客户的平均订单金额"
策略1：Query Plan CoT（查询计划）
-
分析出需要 orders 表和 customers 表，通过 customer_id 关联；
-
分析出需要过滤：city = '北京'、order_date 在2023年；
-
分析出需要聚合：计算 total_amount 的平均值；
-
分析出需要返回"平均订单金额"；
-
生成SQL：
查看代码
SELECT AVG(o.total_amount) as avg_amount
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE c.city = '北京' AND YEAR(o.order_date) = 2023;策略2：Divide and Conquer CoT（分治）
查看代码
一、分解成子问题，用伪SQL表达
-- 子问题1：获取北京客户,伪SQL1:
SELECT 客户编号 FROM 客户表 WHERE 城市 ='北京'
--子问题2：获取2023年订单,伪SQL2:
SELECT 订单编号, 客户编号, 订单金额 FROM 订单表
WHEREYEAR(订单日期) =2023
--子问题3：合并并计算平均值,伪SQL3:
SELECTAVG(订单金额)
FROM 订单表
WHERE 客户编号 IN (SELECT 客户编号 FROM 客户表 WHERE 城市 ='北京')
ANDYEAR(订单日期) =2023
二、汇总生成最终SQL
SELECTAVG(o.total_amount) as avg_amount
FROM orders o
WHERE o.customer_id IN (
SELECT customer_id FROM customers WHERE city ='北京')
ANDYEAR(o.order_date) = 2023;策略3：Example Generation（根据上下文+sql示例生成）
提供给模型的信息：
(1)用户的需求是要"计算特定城市特定年份的平均订单金额"
(2)相似SQL示例（去除具体业务信息）
查看代码
-- 示例: 地区+时间筛选的聚合查询
SELECTAVG(订单表.金额字段) FROM 订单表
JOIN 客户表 ON 订单表.客户ID = 客户表.客户ID
WHERE 客户表.地区字段 ='某城市' ANDYEAR(订单表.日期字段) = 某年份;模型基于示例生成最终SQL：
查看代码
SELECT AVG(o.total_amount) as avg_amount
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE c.city ='北京'
ANDYEAR(o.order_date) = 2023;最后，由一个仲裁Agent从三个不同策略的Agent分别生成的SQL中，选出一个最合适的来执行，而且这个独立的仲裁Agent只会选择一条最合理的sql，不会对这条sql做任何修改。
这就是高德90%准确率的第五个思路："通过多个不同SQL生成Agent之间相互补充，将准确率峰值稳定在接近90%的状态。"
回顾一下高德ChatBI演化的三个阶段：
第一阶段：通过prompt + 数据基础设施建设，快速达到60分水平的ChatBI；
第二阶段：通过引入Agent和原子工具，拆解复杂prompt，降低错误率，达到90分峰值水平；
第三阶段：通过引入多Agent和分子工具，增加流程稳定性，降低Agent认知复杂度，将准确率稳定在峰值水平。
以上，就是高德90%准确率的思路。
那剩下的10%的错误率可以不管吗？答案是不能。
在生产环境，90%准确率意味着每10个查询就有1个出错，用户体验仍不够理想。
高德的理念是："与其让AI攻克这10%，不如用人机协同 。"
通过有限合理地提高人的参与度，来弥补这10%的问题。
首先，在用户输入前，提供"提问助手引导"，从源头减少奇怪的问题输入；
然后，在回答过程中，给出SQL的逻辑解释，让用户明白SQL是在干什么；
最后，在产出结果后，提供人工介入通道，用户无法判断SQL准确性或对结算结果有疑义时，可以申请人工介入，确保用户总是能走完需求闭环，同时收集用户反馈数据，为系统持续优化提供素材。
这是高德90%准确率的第六个思路："不是让AI做到100%完美，而是让整个系统达到100%可用。"
基于元数据、Agent等构建ChatBI的核心技术思路拆解完毕。
持续优化迭代方面，除了收集用户反馈，高德也提出了ChatBI的主动评测原则。
1）重视评测集的构建
用真实用户的问法 + 基础能力模块(例如时间解析类、地理范围类、业务口径类)测试案例来搭建评测数据集。
注意保持鲜度（定期更新）、做难度划分（简单/中等/困难分类）。
就像考试要有标准答案一样，我们需要收集各种真实问题和标准SQL，这样才能客观衡量系统好不好用。
2）自动化冒烟测试
模拟真实环境，让系统自己跑一遍，看结果对不对；
特别关注大模型生成SQL的准确性和稳定性。
人工测试太慢，自动化能快速发现问题，确保每次改动都不会把系统搞坏。
3）自动化归因分析
SQL生成出错时，自动分析是哪个环节的问题（召回、生成、还是中途某个步骤）
不用人工一个个排查，系统告诉你"问题出在第几步"，Bug修复效率显著提升。
想要持续达到高准确率，就要建立持续优化的机制。
到此，高德目前的所有思路都拆解完了，回顾一下：
- 四象限策略：不同复杂度问题用不同方案解决
- 多层元数据：让AI理解业务而不只是数据
- 虚拟宽表：降低多表关联查询复杂度的同时控制数据更新的复杂度
- 三阶段演化：从60%到90%的渐进式优化路径
- 多Agent协作：三种策略并行+仲裁选择最优方案
- 人机协同：用有限人工介入补齐最后10%
高德90%准确率的本质：不是单一技术突破，而是系统工程的胜利。
最后，是高德数据团队下一步优化方向。
方向一：Graph-RAG + NER，优化召回精准度
首先，在系统建设阶段，需要用NER(命名实体识别)对所有的知识文档进行信息要素抽取。
包括数据库表结构、字段说明、业务文档、SQL示例等等，从中提取出各种实体，比如表名、字段名、指标名、业务概念这些。
然后，基于这些实体之间的关系来构建知识图谱。
比如，某个字段属于哪张表、某个指标需要哪些字段来计算、不同业务术语之间是同义词关系等等，这样就把原本分散的知识片段通过实体和关系连接成一个网络。
当用户提问的时候，系统再次使用NER从问题中识别出关键实体。
比如，用户说"北京近7天新用户复购率"，就能识别出"北京"、"近7天"、"新用户"、"复购率"这些关键实体。
接着，就是在已经构建好的知识图谱中，以这些问题实体为起点进行搜索。
这个搜索过程是分轮进行的。
第一轮：先找到这些实体在图中对应的节点；
第二轮：从这些节点向外扩展一跳，找到直接相关的其他实体。比如"新用户"会连接到"用户注册表"、"复购率"会连接到"订单表"等等。
第三轮：继续扩展，这时候可能会加入关系强度的过滤，只保留那些与用户问题强相关的知识片段。
第四轮：主要做质量控制，确保召回的知识既完整又干净。
最终形成一个知识图，喂给模型作为上下文信息。
方向二：预训练、微调、强化学习
这块做起来成本就非常高了，感兴趣、有实力的朋友可以进一步了解相关论文。
以上，这篇文章已经写了近11000字。
能看到这里，你对ChatBI的理解，已经超过90%的人。
当再有人跟你说找个开源项目三天就能搞出来ChatBI，就把这篇文章怼他脸上。
写在最后
写完后我自己的感觉是，ChatBI这个赛道确实有前景，但坑也确实不少。
技术能解决大部分问题，但剩下那10%往往决定了产品的生死。
AI再强，也永远是辅助人类，承认这一点，才能做出真正好用的东西。
概念可以炒，PPT可以做得很漂亮，但产品得实打实地解决问题。
ChatBI也好，什么AGI也好，最终还是要回到用户价值这个原点。
用户不会为了你的技术有多牛逼而买单，他们只关心自己的问题有没有被解决。
这个行业变化太快，今天的最佳实践可能明天就过时了，今天的独角兽可能下个月就倒了。但有些东西不会变，比如对业务的理解，对用户的敬畏，还有那份工程师的较真劲儿。
ChatBI也好，其他AI应用也好，都不是银弹，但也不是骗局。
它们是我们手中的工具，用得好能创造价值，用不好就是在浪费时间和金钱。
关键是要知道自己在做什么，为什么要做，以及怎么做得更好。
愿每一个在AI路上前行的朋友，都能找到属于自己的那个90%，也都能优雅地处理好剩下的10%。
以上，既然看到这里了,如果觉得不错,随手点个赞、分享、推荐三连吧，我们，下次再见。
作者：秋水，互动交流，请联系邮箱：fennenqiushui@qq.com