引言你对着 ChatBI 输入一句「上月华东区销量 top 5 的产品是什么」系统在不到两秒内就返回了一张带数字的图表。这背后看似简单其实隐藏着一个极其复杂的工程问题如何让机器把一句充满歧义、省略、口语化的人类语言准确翻译成可在数据库上执行的查询语句。传统 BI 的做法是「人写 SQL、机器执行」。ChatBI 的革命在于把这一步彻底翻转——人说话、机器写查询。但这恰恰是难度最高的环节。一句「上个月卖得最好的」可能指销量、也可能指销售额「华东」在有的企业是销售大区在有的企业只是地理标签「top 5」到底是按绝对值还是按同比增长排序用户自己都没说清。衡石 ChatBI 构建了一套以语义层Metrics Layer为核心的查询理解引擎把「自然语言 → 可执行查询」拆解为语义解析、意图消歧、Query 改写、安全校验四个阶段。本文将深入拆解这套引擎的底层技术。一、ChatBI 查询理解为什么难1.1 人类语言的三个天然陷阱歧义性。同一个词在不同语境下指向完全不同。「增长」可能是绝对值增长也可能是增长率「用户」可能是注册用户、付费用户或活跃用户。没有业务背景纯语言模型无法判断。省略与指代。用户不会每次都把条件说全。「和上个月比怎么样」——「上个月」是相对哪个基准「比怎么样」比的是总量还是增速口语交流依赖上下文但机器默认没有记忆。同义与口语化。「GMV」「成交额」「流水」在业务里是同一个东西但字面完全不同「卖得火」「爆款」「畅销」指向「销量高」但没有任何一个词直接出现在数据库字段里。这三个陷阱决定了ChatBI 不能靠「大模型直接生成 SQL」就完事。直接让 LLM 写 SQL 的典型准确率只有 50%-65%而且错误往往很隐蔽——查询能执行、返回了数字但数字的含义和用户想问的根本不是一回事。1.2 衡石的解法语义层优先衡石 ChatBI 的核心设计哲学是不让大模型凭空猜数据库结构而是让它在一个「业务语义层」之上做选择。语义层是一张「业务概念 ↔ 物理字段」的映射表。它提前定义好了哪些业务术语对应哪些指标如「销量」 sales_volume 指标的求和哪些维度可用时间、地区、产品、渠道指标之间的计算关系「毛利率」 (销售额-成本)/销售额维度的层级关系「地区」下面有「华东/华北/华南」等成员大模型面对用户问题时不再需要猜测数据库里有什么而只需要从语义层里「挑选」正确的指标、维度和过滤条件。这一步把开放式的「生成 SQL」问题降级成了一个可控的「从候选集中做选择题」问题——准确率因此从六成跃升到九成以上。二、第一阶段语义解析——把句子拆成结构化意图2.1 实体识别NER圈出关键信息当用户问「上月华东区销量 top 5 的产品」语义解析的第一步是实体识别把句子拆成四类结构化要素指标实体「销量」——映射到语义层的 sales_volume 指标。维度实体「华东区」——映射到地区维度下的「华东」成员「产品」——映射到产品维度。时间实体「上月」——解析为相对时间转换为具体的日期区间如 2026-06-01 至 2026-06-30。修饰实体「top 5」——解析为排序限制按销量降序取前 5。衡石采用「规则 模型」混合的实体识别方案。对于时间表达式上周、本季度、近 30 天用专门的时间解析规则库保证精确对于指标和维度则结合语义层的候选词表做模糊匹配——即使用户写的是「卖了多少货」也能通过同义词表命中「销量」指标。2.2 意图分类判断用户到底要什么实体识别之后需要判断用户的「分析意图」属于哪一类。常见的意图包括明细查询「列出所有华东的订单」聚合统计「华东区总销量是多少」排名分析「top 5 产品」同环比「和上个月比增长多少」趋势分析「最近半年的销量走势」贡献度/占比「华东占整体多少」意图分类决定了后续的查询模板。比如「top 5」命中排名意图引擎会自动附加排序和截断逻辑「走势」命中趋势意图引擎会强制带上时间维度并选择折线图作为默认可视化。三、第二阶段意图消歧——解决「哪个口径」的问题3.1 指标歧义的消解当一句问话命中多个候选指标时引擎需要消歧。衡石的消歧策略分三层第一层上下文优先。如果当前会话之前一直在问「销量」那么后续省略主语的「增长多少」默认继承「销量增长」而不是跳到「销售额」。第二层语义层默认口径。语义层为每个指标配置了默认口径。比如「收入」默认指「主营业务收入」而非「其他业务收入」在用户未明确指定时采用默认值并在回答中显式标注「按主营业务收入口径」。第三层主动追问。当歧义无法通过上述两层消解例如用户同时提到了两个都可能成立的指标且上下文无偏好引擎不会瞎猜而是向用户发起澄清式反问「您指的是「合同额」还是「回款额」」这种「宁可多问一句绝不答错一次」的设计是 ChatBI 可信度的关键保障。3.2 维度成员消歧「华东」在某些企业是标准销售大区在某些企业只是地理分区还可能和「上海」「江苏」等省级成员存在包含关系。衡石的做法是在语义层中为维度成员建立层级树和同义词表。当「华东」出现时引擎先查层级树确认它的成员范围和父子关系再决定查询的过滤粒度——是只查华东大区汇总还是下钻到省级明细由用户问题中的粒度线索决定。3.3 时间歧义消歧「上月」是相对时间但需要锚定「当前月」。更棘手的是「财年」——有的企业财年从 4 月开始有的从 1 月。衡石在语义层配置每个租户的财年起始月和时区时间解析模块据此把「本季度」「上年度」等相对表达转换为绝对日期区间避免跨时区、跨财年导致的口径错误。四、第三阶段Query 改写——从语义计划到可执行查询4.1 语义计划Semantic Plan消歧完成后引擎生成一份「语义计划」——一种介于自然语言和 SQL 之间的中间表示。它长这样用自然语言描述而非代码「对 sales_volume 指标按 product 维度分组过滤 region 华东且 date 在 2026-06按指标降序排序取前 5 条返回 product 名称和 sales_volume 值。」这份计划是 ChatBI 可解释性的核心载体它既能被机器翻译成 SQL也能被人类读懂和确认。4.2 计划到 SQL 的翻译语义计划到 SQL 的翻译是确定性的、可验证的不像让 LLM 直接写 SQL 那样充满随机性。翻译器根据语义层的物理映射把每个抽象概念替换成具体的表名、字段名和聚合函数自动拼接出标准 SQL。由于映射关系由语义层严格定义生成的 SQL 在语法和语义上都有保障。4.3 查询优化与下推生成的 SQL 并非直接甩给数据库。衡石引擎会在执行前做一轮查询优化分区裁剪根据时间过滤条件只扫描相关分区避免全表扫描。预聚合命中如果语义层配置了物化视图或汇总表且用户查询粒度匹配直接走预聚合结果响应从秒级降到毫秒级。权限注入自动在 SQL 中追加行级权限过滤如当前用户只能看自己负责的区域保证「用户问得出来的都是他有权看的」。五、第四阶段安全校验——答得准还要答得合规5.1 三层校验门禁Query 改写完成后、执行之前还要经过三层校验指标权限校验用户是否有该指标的查看权限没有则直接拒答并说明原因。参数白名单校验排序、过滤、时间区间是否在允许范围内例如禁止查询超出授权时间窗的历史数据。资源熔断校验查询涉及的数据量、预估扫描行数是否超过阈值超限则降级为抽样或异步执行防止单条问数拖垮整个集群。5.2 与 RAG 的协同在之前的技术文章中我们介绍过衡石 ChatBI 引入了 RAG 检索增强来抑制幻觉。语义理解阶段正是 RAG 发挥作用的环节之一当用户问到「我们的核心指标定义是什么」这类涉及业务知识的问题时引擎先从指标知识库术语表、指标口径文档中检索相关内容再结合语义层生成准确的回答而不是让大模型凭训练记忆自由发挥。六、一个完整例子从一句话到一张图用户问「今年二季度华东和华北的销售额跟去年比怎么样」语义解析识别指标「销售额」、维度「地区」成员华东、华北、时间「今年二季度」「去年」同比、意图「同环比」。意图消歧「销售额」命中语义层默认口径主营业务收入「今年二季度」根据租户财年配置转换为绝对日期「去年」自动对齐为去年同期的二季度。Query 改写生成语义计划——「对销售额指标按地区分组过滤地区∈{华东,华北}、时间∈今年Q2及去年Q2计算同比增幅」。翻译为两段 SQL今年、去年或带年份分组的单条 SQL并附加同比计算逻辑。安全校验确认当前用户有华东、华北的销售额查看权限时间窗在授权范围内预估扫描行数未超限。执行与呈现返回一张分组柱状图横轴是地区纵轴是销售额并标注每个地区的同比增幅百分比。整个过程通常在 1-2 秒内完成。七、技术选型对比方案准确率可解释性可控性适用场景LLM 直接生成 SQL50%-65%低黑盒低个人探索、非严肃场景Text-to-SQL Few-shot70%-80%中中单表简单查询语义层 计划改写衡石90%高语义计划可读高映射可控企业级严肃分析八、FAQQ1用户的问题太口语化、错别字很多ChatBI 还能懂吗能。语义层配置了同义词表和模糊匹配加上大模型本身的容错能力轻微的口语化和错别字不会影响实体识别。但完全跑题或语义不明的问题引擎会选择追问而非硬猜。Q2语义层需要人工维护吗成本高不高需要一定的前期配置但这是一劳永逸的投入。语义层建好后所有 ChatBI 问数都受益且指标口径统一带来的治理收益远超配置成本。衡石也支持从现有 BI 报表自动抽取指标定义降低冷启动成本。Q3为什么不直接用更聪明的模型就不用语义层了模型再聪明也不了解你企业内部的指标口径和数据结构。语义层是把「企业私有知识」注入 ChatBI 的桥梁这是通用大模型永远替代不了的部分。九、总结ChatBI 的「听懂人话」远不止调用一个大语言模型那么简单。衡石 ChatBI 通过语义解析 → 意图消歧 → Query 改写 → 安全校验四阶段流水线把开放式的自然语言转化为可控、可解释、可审计的查询计划再确定性地翻译为优化后的 SQL。这套架构的核心思想是用语义层把「猜」变成「选」用计划把「黑盒」变成「白盒」。这正是 ChatBI 从玩具走向企业级严肃分析工具的关键一步。下一篇我们将聊另一个容易被忽视、却直接决定体验的环节——当对话超过一轮ChatBI 如何记住你前面说过的话。