ChatBI准确率提升实践：从指标治理到智能体架构拆解

1. 先搞清楚一件事：ChatBI的准确率到底卡在哪

聊ChatBI（智能问数）之前，得先承认一个让很多人不太舒服的事实：准确率这个数字，本身就是一个被严重低估复杂度的问题。去年高德分享过一个案例，把问数准确率从某个“不好意思说出口”的水平提升到了86%左右，消息传开之后，不少团队开始拿着这个数字当对标基准，到处问“你们的准确率到80%没有”。但我在实际接触过几十个问数项目后的体会是：只盯着准确率数字，恰恰是这类项目最容易掉进去的坑。

先说清楚“准确率”在这里到底指什么。ChatBI场景下的准确率，通常不是指模型回答得“像不像”，而是指系统最终返回的数据结果和口径，是否和业务定义完全一致。比如用户问“本季度华东区新客环比增长多少”，模型可能准确识别了意图，抓对了“新客”指标，但环比基期算错了；可能SQL生成完全正确，但权限系统没放开华东区的数据；也可能指标名存在两个口径，系统取了默认值，业务方要的是含退款的净增口径——这些环节里任意一个出错，最终展示的数字就是错的。高德案例里那86%，背后其实是一整套链路共同作用的结果：指标治理、语义理解、SQL生成、执行校验、多轮澄清、权限管控，每一环都在贡献或损耗准确率。

所以这篇拆解，我不想只讲Agent怎么调提示词，而是把高德这类头部案例里真正决定准确率的东西拆开来看：指标层怎么建、智能体怎么分工、生成和验证怎么闭环、评测体系怎么搭。适合正在做ChatBI但准确率卡在60%-70%上不去的团队，也适合准备启动问数项目、想少走弯路的同学。你会看到，准确率不是“调一调大模型”就能涨上去的，它本质上是一个工程问题。

1.1 准确率是个结果指标，不是能力指标

我见过很多团队把准确率当成大模型能力的直接反映：准确率低就是模型不行，换个更强的模型，或者把Prompt写得更长，数字就能涨。这个认知在早期demo阶段可能成立，demo里都是精心挑过的题目，模型确实能答得不错。一上生产就垮，原因不是模型退化了，而是生产环境里的问题复杂度、指标数量、口径冲突、权限边界，远远超过demo集覆盖的范围。

拿一个常见场景举例：用户问“最近30天DAU走势怎么样”。demo集里可能只有一条指标“DAU_全端”，模型轻松命中。生产环境里可能存在“DAU_去重”“DAU_含未登录”“DAU_按端拆分”等多个指标，光是“DAU”到底指哪个，就需要结合用户权限、历史提问习惯、上下文来判定。准确率在这里，衡量的是“系统在复杂约束下做对决策的比例”，而不是“模型理解自然语言的能力”。这也是为什么高德案例里反复强调构建指标体系、做语义层标准化，而不是把宝全部押在模型推理上。

1.2 我见过的ChatBI翻车现场，基本都是这四类

把过去一年我在各种问数项目里见到的错误归类，其实高度收敛，就四类：

• 指标口径错误：查出来的数不对，或者数对了但口径不是用户要的。例如“GMV”有人按支付成功算，有人按下单算，系统选了前者而用户默认后者。
• 筛选条件错误：用户说“最近一周”理解成“自然周”，用户说“头部品牌”系统按销售额TOP10算，但业务定义是TOP20。
• 维度组合错误：用户问“分城市看A产品渗透率”，系统拆成了“分城市+分产品”的交叉表，行数和列数爆炸，用户根本没法看。
• 执行层异常：SQL生成得对，但表数据没刷新、分区不存在、鉴权未通过，最终返回报错或空数据。

这四类错误里，真正属于“模型不会推理”的很少，大头是指标口径和条件约束的链路缺失。理解了这一点，再看高德案例里“准确率提升”的拆解就会清晰很多：它治的不是模型的病，是数据链路的病。

1.3 高德案例真正值得拆的，不是那个数字

高德在公开分享里提到的86%准确率，严格来说是一个综合结果：基于评测集计算出的准确率，其中包含了多轮交互后的修正成功案例。也就是说，用户第一轮问出来可能只有70%的水平，但系统通过追问澄清、返回可点选的候选指标、纠错引导，把最终答对的概率推到了86%。这恰恰是ChatBI和传统NL2SQL最大的不同：它不是一个一次性问答系统，而是一个带有确认和纠错机制的人机协作流程。

这个视角下的准确率，就有了两层含义：一是单轮理解的准确率（模型直接命中的比例），二是系统级准确率（经过多轮澄清后最终答对的比例）。高德的工程重点明显放在后者——为模型设计“不懂就问”的节点，而不是让模型硬答。这和我后面要讲的Agent架构是直接相关的。

2. 指标层是绕不开的“地基”：高德怎么做指标治理

做ChatBI的人经常忽视一件事：大模型不会凭空知道你公司每个指标的口径，它的所有理解都来自喂给它的元数据。如果你的指标字典本身混乱、同名不同义、同义不同名，那模型无论是理解还是生成，都会在这个地基上出错。高德案例里准确率能顶上去，最先下的功夫就是指标治理。

2.1 把业务口径翻译成机器能校验的语义

高德内部在启动ChatBI项目时，指标数量已经是数千级别的规模，分散在不同团队、不同报表里。同一个“订单量”，地图业务和出行业务的统计逻辑不同，自然语言里都叫“订单量”，但底层SQL和事实表是两套。如果直接拿这些原始指标去喂模型，哪怕大模型再聪明，也只能靠猜。他们的做法是建立统一指标层：把业务上要回答的问题收敛成标准化的指标定义，形成一套“指标目录”。

每一指标在目录里至少要包含：指标名称、指标别名、所属主题域、原子指标/派生指标类型、聚合方式（SUM/AVG/COUNT/DISTINCT）、统计粒度（日/周/月/累计）、时间范围默认值、过滤条件、以及对应的物理表字段。这个目录的价值在于：模型在生成SQL之前，已经拿到了一个确定性的模板。它不需要去“发明”指标怎么计算，只需要在候选指标里做选择。

拿一个具体例子说：业务方问“高德地图本周新增注册用户数”。如果指标目录里已经定义了“新增注册用户数 = COUNT(DISTINCT user_id) WHERE reg_time BETWEEN 本周开始 AND 当前时间”，那模型要做的事情就从“写出一条正确SQL”降维为“找到指标ID=report_user_reg_cnt的这条定义，然后补充时间范围”。这个降维的幅度非常大，也是准确率能上去的根本原因。

2.2 梳理出主题域和原子指标、派生指标的关系

光有指标目录还不够，还要定义指标之间的关系，否则模型面对“A/B测试里实验组转化率比对照组高多少”这类复合问题时，不知道该用哪几个原子指标参与计算。高德的做法是把指标拆成原子指标（如“用户数”“订单金额”）和派生指标（如“客单价”=订单金额/订单数、“转化率”=转化人数/曝光人数），并在指标目录里显式维护派生指标的血缘。

这样做的好处非常实际：模型在做参数抽取时，如果识别到用户问的是“客单价”，它可以直接查指标目录看到这是一个派生指标，需要先计算“订单金额”和“订单数”。它不需要在推理时临时构建这个计算逻辑，因为推理过程中的任何“临时构建”，都是准确率的隐患。对于用户不太可能问到的冷门复合指标，这种方式也保证了系统能组合出正确的算式，而不是依赖模型在大规模表结构下碰运气。

这一层做扎实之后，ChatBI对模型推理的依赖度会明显下降。准确率的天花板，从“模型理解能力上限”变成了“指标目录的覆盖度和清晰度”。后者的可控性，远高于前者。

2.3 质量守门：查不到、口径错、更新慢，三类问题如何收敛

指标目录建起来只是开始，更持久的工作是质量控制。我们做过统计，ChatBI上线后最容易引发用户投诉的，不是模型听不懂话，而是：指标根本查不到、指标口径描述错误、指标数据更新延迟。这些问题几乎都不是大模型能解决的，需要指标平台的持续运营。

高德在指标平台上做了比较重的数据质量监控：每个指标配置数据刷新时间、数据源变更通知、口径文档版本管理。一旦底层表结构变化，指标定义关联的字段会同步更新，并触发历史会话缓存失效。这个机制保证了模型拿到的元数据始终是“当前有效的”，而不是三个月前的版本快照。

我在自己的项目里也复用过这个思路：给指标目录加一个“置信度”字段，只有经过业务方确认过的指标才开放给ChatBI使用，未确认的一律不出现在候选列表里。做过这个动作之后，准确率直接涨了三到五个百分点——因为模型连选错的机会都没有了。这一步听起来无关模型，但往往是准确率提升最稳的一笔投资。

3. 问数智能体架构：意图识别、多轮追问与工具调用

指标地基打完之后，才轮到智能体架构本身。高德案例里的Agent并不是一个简单的“大模型+提示词”单体，而是按照职能拆成多个可独立评估、独立优化的模块。这种架构设计对准确率的作用，不在于某一个模块有多强，而在于每个模块都可以单独测试、单独回滚、单独调优——这让整个系统的准确率变得可管理。

3.1 先分诊再干活：意图识别决定走哪条链路

用户进入ChatBI后的第一句话五花八门，可能是“看看今天的流量情况”、可能是“把上个月各省份的时长数据给我拉一下”、也可能是“为什么最近留存跌了”。这三种问题对应的处理链路完全不同：第一种是指标查询，第二种是指标+维度查询，第三种是归因分析，需要多步拆解甚至调用专门的分析模板。

高德的Agent在接收到用户问题后，第一件事是做意图分类，而不是直接抽参数生成SQL。意图分类的结果会决定后续走哪条子链路。比如：

• 查询类意图：走指标选取+维度解析+SQL生成链路
• 对比类意图：走指标+对比基期解析链路
• 归因类意图：走指标下钻+维度拆解链路，可能需要多轮补充
• 闲聊/非问数意图：直接走拒答流程，避免误生成SQL

这个“分诊节流”设计的核心价值，不只是功能划分更清晰，更在于避免模型在错误方向上浪费推理并且产出看似合理但实际错误的SQL。很多准确率问题，本质上是意图识别错了还在硬答。加入分诊层后，答错了的cost被限制在分类层，而分类层只有几个类别，评估和修正都容易得多。

3.2 参数抽取不是简单找实体，而是把问题对齐到指标代数表达式

用户问“北京地区本月日均活跃用户数同比”，模型需要抽取出：地域=北京、指标=日均活跃用户数、时间=本月、对比=同比。常见做法是用LLM做NER式抽取，把“北京”“本月”“同比”标签化。但这样抽出来的参数是零散的，缺少结构化的组合关系。

高德案例里给人的启发是：参数抽取的输出，不是标签集合，而是指标选择与参数组合的代数表达式。也就是系统直接输出类似“indicator=MAU_daily, filters=[city=='北京'], time_range=[本月1日~今日], compare=[同比]”的JSON结构。这样做的原因很实际：后续的SQL生成不需要再做一次跨字段拼接，字段映射关系已经在抽取阶段确定。

这个细节决定了准确率的一个关键环节：同一句话，不同业务背景有不同理解。“本月”在一个按自然月结账的业务里指1号到月末，在一个按滚动30天考核的业务里指今天往前推30天。如果抽取阶段不做标准化，把“本月”原样丢给SQL生成器，那SQL生成器就得自己判断口径，而它每次判断都可能不一致。高德的做法是在抽取阶段就结合指标目录里定义的默认时间口径，把自然语言里的时间词翻译成确定的时间边界。

3.3 多轮对话的“确定性”：澄清、确认、跳转，靠节点而不是靠模型自由发挥

高德准确率能到86%，多轮交互贡献很大，但多轮不是让模型自由聊天。架构上他们设计了一套确定性交互节点：当参数抽取结果的置信度低于阈值，或者候选指标存在多个可能时，系统主动向用户提问，给出候选让用户选，而不是让模型猜一个答案出来。

举个例子：用户问“看看高德的用户数”，指标目录里可能有“高德地图DAU”“高德打车用户数”“高德导航活跃用户数”三个候选。如果模型直接选一个，有三分之二的概率选错；但如果系统返回“您想问的是以下哪个？”，用户一点选，准确率就是100%。这个“澄清节点”的引入，把原来不可控的模型猜测，变成了可控的人机协作。

从工程角度看，这里面有一个设计原则：能通过交互消除的歧义，就不要让模型承担。多轮对话的每一轮，都应该是在收窄不确定性，而不是在引入新的自由发挥空间。有些团队做大模型对话，恨不得模型讲得越多越好，但ChatBI场景恰恰相反——每个确定性节点（比如“请选择指标口径”）如果被模型用一段话来代替，准确率反而会下降，因为模型在复述中可能夹带幻觉。

3.4 数据能力API化：让模型用“功能”而不是用“回忆”回答问题

高德的Agent还有一层很关键的架构设计：把数据能力封装成API工具，Agent只负责理解用户意图、选择工具和传递参数。这意味着agent并不需要“知道”某个报表长什么样，它只需要知道“工具A=查询指标数据，工具B=返回指标列表，工具C=执行归因分析”，然后通过一个结构化的函数调用协议来使用它们。

这和直接让模型写SQL有本质区别：模型在SQL生成时，需要回忆表结构、字段含义、join关系、where条件语法，任何一个记忆错误都可能生成错误SQL。但工具调用模式下，模型只需要从工具列表里选对工具，参数已经被前面的抽取模块标准化了。底层SQL的生成逻辑，可以放在一个确定性的代码模块里，甚至用模板+配置来渲染，完全摆脱模型幻觉影响。

这个思路的副产品是：准确率评测粒度更细了。你可以单独评测“工具选择准确率”“参数传递准确率”“工具执行成功率”，而不是混在一个“SQL生成准确率”里说不清道不明。哪一环弱，就补哪一环。我做过一个比喻：让大模型直接写SQL，等于让一个实习生在没有培训手册的情况下操作生产数据库；让大模型调用API，等于给实习生一本带例子、带约束的手册，让他照着手册发请求。后者的稳定性，明显高于前者。

4. 从生成到验证：大模型出SQL之后的闭环校验体系

到了真正生成SQL、执行取数的环节，一个非常容易被低估的事实是：大模型生成的SQL，即使语法正确、逻辑看起来也对，也仍然可能在执行环境里出错。权限没开、表分区不存在、数据量为空、join键重复导致数据膨胀，这些都是静态文本正确但执行失败的典型场景。高德的案例在这一点上给了我很大启发——他们把生成之后的动作做成了闭环回归和运行时校验两个阶段。

4.1 确定性回归：把SQL生成变成可回归的工程问题

高德内部建了一套“确定性回归”体系，核心思路是：SQL生成器不只是一个文本模型，而是一套可以批量回放的确定性流程。他们对历史上有代表性的问题做基线集，每次改动指标定义、更新提示词、升级模型版本，都要在基线集上完整跑一遍，对比生成SQL与标准SQL的差异。任何改动如果导致已有正确case翻车，就会被拦截。

这件事说起来简单，做起来要求很高：评测集要覆盖高频问题、歧义问题、边界问题，标准答案要经过业务方和工程方双重确认。但一旦跑起来，收益非常大。我自己的项目里，就是因为上线前补了这套回归机制，才避免了一次提示词调整导致全量SQL前缀错误的事故。

有人可能会问：如果每次模型升级都要重新验证，那模型升级还有什么自由度？答案是：升降级变成了一种评测任务，而不是拍脑袋决定。某大模型新版本号称推理能力强，但跑你的基线集发现上下文遵循能力下降，那就继续用旧版本。这套机制把“模型选型”从一个玄学问题变成了一个可量化问题。

4.2 执行结果的运行时校验：非零判断、鉴权、限流、兜底

除了离线回归，线上执行环节也要做校验。高德的执行校验体系里，我印象最深的是“非零判断”和“空结果兜底”的设计。系统执行完SQL后，不只是把结果返回给用户，还要做一系列检查：

• 返回行数是否为0：如果查询本身应该非空，需要触发修正逻辑
• 数值是否超出合理区间：某指标历史最大值100万，本次返回10亿，大概率而不是真相
• 鉴权是否透明：某些数据用户无权限时，不是报错，而是明确告知“该数据不在您权限范围内”
• 执行时间是否超时：超过阈值则走异步任务队列，而不是让用户一直转圈

这些校验单独拎出来都很朴素，但组合在一起，就把“SQL执行异常”从用户可感知的错误，变成了系统内部自动修正或友好提示的流程。准确率在这个过程中没有被降低，反而因为“错误结果被拦截”而显得更高了——因为错误结果如果直接展示给用户，用户会把这次回答判为“错误的”，而不是“偶发的技术问题”。

4.3 数据和权限的一致性：为什么结果对但用户不能看

还有一个决定ChatBI可用性的细节是权限。很多团队的生物权限模型还是“用户看不到某数据”，但ChatBI生成SQL是在服务端统一执行的，模型本身不知道用户权限边界。结果就是：问的指标能查到，返回数据也正确，但点开明细发现不是自己该看的——这在合规上很危险。

高德的方案是把权限过滤下沉到底层执行层，用户在生成SQL前，系统先获取该用户的权限标签集，然后在指标选择和维度过滤条件里动态拼接权限约束。比如一个用户没有北京区域的数据权限，那“全国用户数”这个查询对他是不可见的，系统会在意图识别阶段就把候选集缩小到他有权限的范围内。

我自己复用过这个逻辑，效果很好：与其让模型生成的SQL里临时拼权限条件，导致语法拼接风险，不如在工具层直接注入权限过滤条件，把可见性逻辑集中管理。这事不做，准确率再高也上不了生产，因为业务方和数据安全团队都不敢给你过审。99%准确率的一次越权查询，比10%准确率的普通查询严重得多。

5. 准确率评测与回归方法：怎么复现86%，而不是被86%误导

前面聊了高德案例的架构和工程链路，最后一个核心话题，也是很多团队最想知道的：他们那个86%的准确率是怎么测出来的？我怎么复现一套类似的评测体系？

先说结论：评测体系的设计，会直接决定你优化的方向。如果用错评测方法，后续所有优化都会白费力气。

5.1 评测集不要按“模型觉得难的题”来建，按“业务高频问题”来建

见过不少团队建评测集的方式是：找几个典型SQL场景让大模型生成，发现答错了，就换更难的题继续测。这个思路的误导在于：大模型觉得难的题，不一定是业务方常问的题。一个只占1%查询量的冷门埋点指标，模型答错的概率再高，对整体准确率的影响也微乎其微。

高德的做法是直接采集真实用户问题分布：从日志里拉出过去一个季度用户问得最多的Top 200问题，覆盖不同业务线、不同指标、不同难度分布，然后人工标注期望答案。评测时不是简单算“答对了多少题”，而是按用户真实提问频率加权。这样算出来的准确率，才和线上用户的实际感知一致。

我建评测集的习惯是“三层结构”：

这个结构下评测出的准确率才有指导意义：第一层决定你现在能拿多少分，第三层决定你能不能在复杂场景里稳住下限。

5.2 分环节统计准确率，比一个总数字更有用

单一总准确率数字很容易掩盖瓶颈。举个例子：系统总准确率75%，看起来不错，但拆开一看，指标识别准确率90%、条件抽取准确率82%、SQL执行成功率70%——瓶颈很明显在执行层。你花大力气优化指标识别，顶多把总准确率提两三个点；但把执行校验做扎实，可能直接跃升十个点。

所以我强烈建议团队把准确率拆成四个指标来统计：

• 意图识别准确率：系统对问题类型的判断是否正确
• 指标和参数抽取准确率：从问题里抽出的指标、维度、时间是否正确
• 工具执行成功率：生成的SQL是否能在权限、数据、分区都正确的前提下成功返回值
• 最终结果准确率：用户看到的最终数字和标准答案是否一致

高德的案例里，他们敢把准确率作为对外宣传的数字，说明这四个环节都有相对成熟的度量方式。对于想对标高德的团队，我的建议是先按这四个维度建立自己的度量表，再决定先优化哪块。否则今天调一下Prompt、明天换一个模型，都是在没有方向盘的情况下开车。

5.3 线上反馈闭环：评测集要持续吸收用户的真实提问

评测集不是一次性工作，ChatBI上线后，每天都会有新的话术问法、新的指标别名、新的组合条件。高德案例里有一个反复强调的细节：用户问了但系统答错的问题，应该自动沉淀为未来的评测用例。

落到实现上，就是记录每次失败会话的完整上下文（用户问题、Agent中间结果、最终反馈、用户是否点了“不认可”按钮），定期从中抽取代表性样本，人工标注后加入评测集。这一套闭环跑起来之后，评测集的规模会越来越大、越来越贴合真实场景，准确率衡量标准也随着业务演进而更新。

有人可能觉得“评测集越来越大是不是会让分数越来越难看”，这个担心是多余的——你要的不是一个固定不变的漂亮分数，而是一个持续反映真实能力的度量工具。评测集变大，分数暂时下降，那是在提示你系统还没跟上业务变化，这是好事。

6. 落地过程中我踩过的坑，以及一些可以复用的经验

最后一个部分，聊聊我在自己的项目里复盘出来的几条经验。这些东西不一定在高德的案例里明确写过，但我在踩过坑之后回头看，发现他们的架构早就避开过类似的雷区。

6.1 指标平台还没建好，能不能先上ChatBI

这是每一个想快速出demo的团队都会遇到的问题：指标目录一团乱，但老板想月底就看到ChatBI效果，怎么办？我的建议是：demo可以做，但Demo准确率不具备参考性。

demo阶段你只会喂给ChatBI少量精选过的指标，比如5个指标，模型再笨也能找对。一上生产变成500个指标，模型就要做选择，而没有指标目录做约束的选择，准确率必然下降。高德案例里他们先花大力气建指标层，本质上就是在回答这个“先基建还是先见效”的问题。

如果实在没法等待完整指标层建好，可以做折中方案：先圈定一个最小的业务范围（比如只做“用户增长”主题域的50个核心指标），把ChatBI的候选范围锁死在这50个指标里。这样生产化之后的准确率仍然可控，也不会一次性暴露在500个未治理指标的高复杂度下。

6.2 同一指标多个别名，靠Prompt根本无法覆盖

业务方和用户从来不会按标准名称问数。“活跃用户”可能被叫“日活”“DAU”“活跃”“留存用户”……如果你把这些别名硬编码到Prompt里，提示词会变得无法维护，而且总有漏掉的说法。

高德的思路是把别名放进指标目录，让同义词匹配变成一个数据问题而不是提示词问题。指标目录里“DAU”这一行可以配置别名列表：日活、DAU、日活跃用户数、活跃用户数。系统在参数抽取时，通过一个字典匹配做指标候选召回，而不是让大模型去猜。这个改动让我在项目中绕过了一大类“用户换个说法就答错”的问题，综合准确率大概提升了两到三成。

6.3 不要盲目对标86%，先让你的基线稳定复现

最后想说的是，对标高德的86%没有意义，因为每个公司的指标复杂度、数据质量、用户群差异都很大。ChatBI准确率的提升路径，本质上是把大模型的不确定性出口逐步替换为确定性系统的过程。今天做好指标目录，明天加好意图分诊，后天补齐执行校验，每一步都能把准确率推高一点。

我在自己项目里体会最深的一件事：准确率增长不是线性的，早期调Prompt增长最快，但会快速进入平台期；之后每一次结构化改动——加指标、加回归、加断言——都是跨越平台期的关键。等到哪一天，你发现准确率问题主要来自新增指标还没纳入目录、或者某条SQL模板还没覆盖到，那就说明你的ChatBI已经进入了工程化提升的正轨。