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”降维为“找到指标IDreport_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式抽取把“北京”“本月”“同比”标签化。但这样抽出来的参数是零散的缺少结构化的组合关系。高德案例里给人的启发是参数抽取的输出不是标签集合而是指标选择与参数组合的代数表达式。也就是系统直接输出类似“indicatorMAU_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问题覆盖不同业务线、不同指标、不同难度分布然后人工标注期望答案。评测时不是简单算“答对了多少题”而是按用户真实提问频率加权。这样算出来的准确率才和线上用户的实际感知一致。我建评测集的习惯是“三层结构”层级来源比例作用第一层历史真实问答日志60%反映线上高频问题决定基本盘第二层业务方提出的常见进阶问题25%覆盖有可能快速增长的场景第三层边界条件、歧义问题、坑人题15%防止系统在极端情况下翻车这个结构下评测出的准确率才有指导意义第一层决定你现在能拿多少分第三层决定你能不能在复杂场景里稳住下限。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已经进入了工程化提升的正轨。 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”降维为“找到指标IDreport_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式抽取把“北京”“本月”“同比”标签化。但这样抽出来的参数是零散的缺少结构化的组合关系。高德案例里给人的启发是参数抽取的输出不是标签集合而是指标选择与参数组合的代数表达式。也就是系统直接输出类似“indicatorMAU_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问题覆盖不同业务线、不同指标、不同难度分布然后人工标注期望答案。评测时不是简单算“答对了多少题”而是按用户真实提问频率加权。这样算出来的准确率才和线上用户的实际感知一致。我建评测集的习惯是“三层结构”层级来源比例作用第一层历史真实问答日志60%反映线上高频问题决定基本盘第二层业务方提出的常见进阶问题25%覆盖有可能快速增长的场景第三层边界条件、歧义问题、坑人题15%防止系统在极端情况下翻车这个结构下评测出的准确率才有指导意义第一层决定你现在能拿多少分第三层决定你能不能在复杂场景里稳住下限。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已经进入了工程化提升的正轨。