AI问数架构详解

“上个月华东区的净销售额是多少？比去年同期下降了多少？”

把这个问题交给大模型，生成一段SQL并不难。真正难的是：净销售额是否扣除退货，按订单日期还是开票日期归属月份，华东区按客户所在地还是销售组织划分，去年同期是否采用了相同口径。

这些条件只要有一个不同，两段都能正常执行的SQL，就可能给出两个不同答案。

这也是企业AI问数容易被低估的地方。聊天入口解决了表达问题，数据库解决了计算问题，中间还需要一套机制，把业务含义可靠地转换成查询，并把查询限制在正确的数据与权限范围内。

评价问数架构，最重要的三个问题是：查询逻辑由谁生成，业务口径由谁约束，执行权限由谁控制。

沿着这三个问题，可以把常见方案归纳为四种模式：

1）Text-to-SQL

2）语义层驱动问数

3）受控工具调用，

4）结构化与非结构化混合分析

前三种主要区别在查询如何产生；第四种把多条查询和检索路径组织起来。它们可以组合使用，并不存在一条从“低级”到“高级”的固定升级路线。

01｜Text-to-SQL：灵活，但正确性需要逐层验证

Text-to-SQL，也常写成NL2SQL，最直接的做法是把问题、表结构和字段说明交给大模型，由模型生成SQL，再由数据库执行。

当数据域只有几张表，这条链路可以很短。进入企业环境后，模型面对的往往是数百张甚至更多业务表，以及大量缩写、编码和历史字段。此时，先找到相关上下文，再生成查询，比把所有表结构塞进提示词更可控。

因此，实际系统通常加入Schema RAG：检索相关的表结构、字段含义、关联关系、业务术语和经过验证的SQL示例。LlamaIndex的官方Text-to-SQL示例就分别展示了表结构检索，以及行值、列值检索对查询生成的帮助。

图1｜检索负责准备上下文，模型负责生成候选查询；校验与执行必须留在受控服务中。

这条链路里有三个不同的技术任务。

首先是找对数据。用户说“客户”，可能对应售达方、付款方，也可能对应集团客户。检索要帮助模型选对业务对象，而不只是找到字段名称相似的表。

其次是生成计算逻辑。模型需要确定关联条件、聚合粒度、时间窗口和过滤范围。例如查询净销售额时，退货如何处理、税额是否剔除，都属于查询逻辑的一部分。

最后是执行前校验。SQL能通过语法解析，只说明语法成立；数据库能返回结果，也不代表业务含义正确。生产系统还需要检查允许访问的表和列、语句类型、关联方式、资源消耗，以及是否需要人工审核。LangGraph的SQL Agent教程展示了查询检查和人工介入的组织方式，同时明确提醒使用最小数据库权限。

一个典型错误是关联后的重复计数。假设一张1000元订单对应两条回款记录，直接把订单表与回款表关联，再对订单金额求和，结果就可能变成2000元。SQL没有报错，金额却翻倍了。数据库并不知道用户想统计的是订单额还是回款额。

错误反馈可以帮助模型修正列名、语法或类型，但通常发现不了这种业务错误。循环重试应设置上限；不能把“直到SQL执行成功”为止，当成“直到答案正确”为止。

这里还要划清RAG的作用：检索少量交易记录，可以帮助理解编码和值域，不能替代全量数据的精确聚合。全年收入、去重客户数、期末库存，仍应交给数据库或指标引擎计算。

Text-to-SQL的优势是开放，能够覆盖事先没有设计过的分析问题。代价是每次生成都可能引入新的逻辑，验证难度随表数量、关联复杂度和业务歧义增加。

因此，它很适合分析师探索、主题范围清楚的临时分析，也适合作为正式指标之外的补充路径。让它直接面对未经整理的ERP物理表，再向全员承诺稳定的经营口径，风险很高。

SQLBot、LangGraph SQL Agent和LlamaIndex都值得研究，但应用、开发框架与企业指标体系是不同层次的东西。

02｜语义层驱动：让指标定义先于问题存在

如果企业每天都在问销售额、毛利率、库存周转和逾期应收，逐次生成这些指标的计算逻辑，往往不是合理的工程选择。

语义层的做法，是提前定义指标、维度、实体关系、聚合规则和时间口径。用户提出问题后，系统先识别他要哪个指标、按什么维度观察、采用什么时间范围，再生成对应的查询。

这里的语义模型不能只有字段中文名。它还需要处理事实表粒度、关联基数、币种转换、财年，以及指标能否跨维度相加。例如收入可以按月份累计，月末库存通常不能沿时间轴直接求和；毛利率也不能把各产品毛利率简单相加或无权平均。

图2｜“有语义层”还不够，要继续检查查询执行时是否必须遵循已定义的规则。

技术上，至少要区分两种实现。

第一种，语义作为生成上下文。

模型读取指标定义、关系和示例，然后生成SQL。相比只看物理表，这能提供更完整的业务含义，但模型仍然可能写出偏离定义的逻辑。Snowflake文档就说明，Cortex Agents可以读取Semantic View定义，并直接针对物理表生成SQL。

第二种，语义作为执行约束。

模型输出的是受限制的查询意图，例如指标、维度、时间和筛选；后端校验这些对象是否合法，再由确定性的语义引擎编译查询或执行预定义计算。

例如，下面是一份示意性的查询意图，不是某个产品的标准接口：

指标：net_sales_v3维度：region期间：2026-08比较：上一年同期

在这条受控路径里，模型可以选择“净销售额”，却不能自行把定义中的退货扣减删掉。前提是后端确实校验参数，并且没有给同一调用方开放绕过语义服务的任意查询通道。

Power BI语义模型、Looker的LookML，以及Cube Core、MetricFlow、WrenAI等，都可以作为研究语义驱动问数的入口，但它们的查询接口和约束方式并不相同。尤其要留意临时计算：Power BI Copilot支持临时DAX计算，因此不能把“查询了语义模型”一概等同于“只使用了已批准的度量值”。

语义层最大的收益是复用。一个指标一旦经过业务确认，报表、问数、API和其他应用可以围绕同一份定义工作。问题从“每段SQL是否正确”，转向“指标定义是否正确，以及请求是否遵守定义”。

它的代价也很明确：必须有人维护指标含义和版本。系统再先进，也无法替销售与财务决定收入确认口径。模型可以辅助生成定义，最后仍需要业务负责人确认。

对于正式经营分析，这通常是更稳妥的起点。对于大量新颖、尚未建模的问题，则需要补充探索路径，不能靠不断扩大语义模型来包办所有临时分析。

03｜Agent调用受控工具：把自由查询收敛为业务能力

有些问题不需要大模型写SQL。

例如查询指定期间的净销售额、某仓库的可用库存、某客户的逾期应收。企业如果已经有可靠的指标服务或业务API，模型可以只负责选择工具和提取参数。

工具：get_net_sales参数：period="2026-08", region="EAST"

查询规则由后端实现，模型不能随意修改。工具背后可以是参数化SQL、语义查询服务，也可以是现有业务系统接口。

图3｜模型提交的是调用请求。用户身份、数据范围和执行许可由服务端验证，不能采信模型自报的权限。

这类架构的关键，在于把工具设计成业务能力，而不只是给数据库访问换一个包装。

get_net_sales限制了指标含义和可接受参数；一个接受任意字符串的execute_sql，仍然允许模型自由生成查询。即使两者都通过MCP连接，风险也完全不同。

MCP统一工具连接方式，不替企业完成指标治理，也不自动建立权限边界。Google的MCP Toolbox for Databases同时提供通用数据库工具与自定义工具机制，正说明连接协议之上还需要应用设计。

Microsoft Data API builder则可以作为REST、GraphQL和MCP数据访问层的参考组件。

后端至少应完成三件事：验证真实用户身份；校验参数和值域；将用户映射到允许访问的数据范围。租户、组织和用户权限不能取自模型自行填写的身份字段。即使使用服务账号，也必须在可信后端落实等效的用户级授权。

参数化查询能处理值注入问题，却不能自动解决所有动态查询风险。允许选择的列、排序字段或数据对象，仍需要白名单和结构校验。工具接口越接近稳定的业务能力，能够证明的边界通常越清楚。

这条路线的优势是稳定、容易审计，也便于嵌入已有业务应用。它适合高频正式指标和权限要求严格的场景，常常不需要迁移原有数据库。

局限在于覆盖面：没有相应工具的问题，系统就做不了。合理的行为是澄清、说明边界或转入审核路径，不能偷偷改走权限更宽的通用SQL工具。

还要注意，语义层与受控工具不是竞争关系。一个受控工具完全可以调用语义引擎：前者限制应用能做什么，后者统一指标如何计算。

04｜混合分析：把“数是多少”和“原因是什么”分开处理

“华东毛利率为什么下降，是否与客户合同中的折扣条款有关？”

这种问题已经超出一次SQL查询。系统需要计算毛利率变化，分析产品或客户结构，再检索相关合同、折扣政策和业务说明。

合适的架构是将任务拆开：结构化数据交给查询引擎；文档交给带权限的检索服务；需要进一步计算时，调用受控的统计或代码工具。最后再对齐实体、时间和证据，生成回答。

图4｜不同分支返回的是证据，最终解释必须区分已计算事实、文件依据与尚待验证的推断。

Snowflake Cortex Agents将结构化查询、Cortex Search和其他工具组织起来，可以作为这类商业产品的参考。自建方案也可以用工作流或Agent框架实现类似职责划分。

实现时，最容易低估的是证据关联。销售数据里的客户编号，要能对应到合同中的主体；毛利率统计期间，要与合同条款的有效期一致。检索到一份提及折扣的合同，不足以证明它造成了当期毛利下降。

因此，输出应明确区分：“已计算的差异”“文件中有依据的解释”和“需要进一步验证的假设”。如果还涉及预测，应调用明确的统计或机器学习方法，并披露假设；不能让模型凭语言能力补一个预测数字。

混合架构扩大了问题覆盖范围，也增加了时延、调用成本和故障点。每个分支都要独立执行权限检查，失败的分支不能被其他结果掩盖。任务较稳定时，显式工作流通常更容易测试；只有分解与工具选择确实需要动态判断时，才值得增加Agent的自主规划。

知识图谱或本体可以帮助处理复杂业务关系，例如客户集团、供应商网络、BOM或合同关联。但它们解决的是关系与上下文问题，不会自动替代指标定义、数据质量和访问控制。

05｜Fabric和其他产品，分别落在哪一层？

理解了查询机制，再看产品就清楚得多。Fabric是数据平台及相关服务的选择，Text-to-SQL、语义层和工具调用则是问数机制，两者不在同一个比较层次。

以Fabric Data Agent为例，它可以根据数据源类型使用不同查询工具：面向Lakehouse、Warehouse等SQL数据源使用T-SQL；查询Power BI语义模型使用DAX；面向Eventhouse中的KQL数据库使用KQL。相关访问还要受请求者权限及平台治理规则限制。

图5｜Fabric承载了多种问数路径。图示仅保留主要SQL、DAX、KQL路径，并非全部连接器清单或内部实现图。

因此，“通过Fabric问数”仍然需要继续问：查询的是原始表，还是已经整理过的语义模型？标准问题是否有验证过的查询？新生成的逻辑如何评测？平台可以提供连接与治理能力，不能替企业决定“净销售额”应当如何定义。

Power BI Copilot与Fabric Data Agent也不能混为一个入口。前者围绕Power BI模型和分析体验展开；后者可以配置多类数据源及问数路径。

其他主流产品可以按同样方法拆解。

Databricks Genie围绕Unity Catalog、业务指令、SQL示例和可信资产组织问数；

Snowflake提供Semantic Views、Cortex Analyst和Cortex Agents等相互配合的能力；

Looker Conversational Analytics利用已有Looker模型与分析资产。Quick BI智能小Q则提供围绕数据集配置的中文问数体验。

这些产品的共同优势，是能复用已有数据资产、权限和运维体系。代价在于平台依赖、容量与使用成本，以及不同功能的版本、区域和发布状态限制。应以具体路径验证能力，不宜仅凭一次演示比较“谁更聪明”。

开源选型也要分层：SQLBot更接近完整问数应用；Cube Core、MetricFlow和WrenAI可用于研究语义与上下文能力；LangGraph、LlamaIndex侧重应用编排和查询开发；MCP Toolbox、Data API builder提供工具和数据访问组件。拿一个开发框架与一套完整商业平台直接比较功能数量，结论通常没有意义。

06｜企业更实用的选择，是分开正式指标与探索分析

四种模式各自解决不同问题。选型时，先看问题性质，再看现有资产，而不是先指定一个大模型或云平台。

**开放探索，优先考虑Text-to-SQL。**它允许分析人员提出新问题，前提是业务域可理解、权限收紧，并且有能力复核生成逻辑。

**正式经营口径，优先考虑语义层。**它把指标定义变成可复用资产，代价是前期建模与持续维护。

固定高频或严格权限问题，优先考虑受控工具。它缩小执行空间，换取稳定性和审计性，代价是需要明确设计能力范围。

跨数据和文档的复杂问题，再增加混合编排。先确保每条基础路径可信，再让系统承担证据组合和解释任务。

实际部署时，这些模式往往应当共存。

图6｜正式指标与临时计算分流，统一落实授权、执行控制和证据回传。各数据源仍要独立执行权限限制。

在这个参考架构中，正式经营问题走语义服务或受控业务API；临时分析走范围受限的SQL生成路径，必要时人工审核；合同和制度问题走文档检索。统一入口可以把复杂问题拆给多个分支，但不能用一个分支的授权替代另一个分支的授权。

用户看到的答案也应有所区别：正式指标标明定义与版本，临时计算标明公式与假设，文档解释附上依据。不能把三类结果都包装成同等确定的一句结论。

如果企业已经有可靠的Power BI模型、Looker模型或指标API，应优先验证能否复用，而不是为了聊天入口重新建设一套口径。**如果数据平台尚未确定，也不必默认迁移到Fabric；独立Agent、语义服务与受控接口，同样可以接入现有数据库或分析副本。

另一个常见误区是多数据源。“能同时连接ERP和CRM”，与“能可靠计算两者之间的关联”是两项能力。跨源分析还要解决实体映射、时间快照、粒度和重复计数。Trino等联邦查询引擎能承担跨异构来源的SQL执行，但不会自动补齐这些业务定义。

07｜上线之前，比聊天效果更值得验收的四件事

第一是业务正确性。准备经过业务确认的标准问题和答案，分别检查语法、执行结果、指标口径及应当澄清的歧义。调优集与盲测集要分开；SQL文本不同未必错误，SQL执行成功也未必正确。

第二是权限不可绕过。数据库、语义服务或可信后端必须强制授权。表结构、样本值、文档检索、查询结果和缓存都可能泄露信息，不能只保护最终答案。数据和文档中出现的指令，也不能获得工具调用权限。

第三是成本与故障可控。设置只读角色、允许对象、超时、资源额度、结果大小和重试上限。只加一个LIMIT，不能保证扫描成本下降。对必须执行的代码使用隔离环境，不把统计分析工具变成任意系统操作入口。

第四是结果可以复盘。至少记录用户问题、模型与提示配置、语义版本、查询或工具、筛选条件、数据时间和执行结果。模型、指标或数据结构升级后，要重新跑回归评测。Fabric和Snowflake均提供问数评估机制，可以借鉴测试组织方式，验收内容仍要以本企业的真实问题为准。^[15]

没有适用于所有企业的单一最优问数架构。开放查询换来灵活性，语义建模换来口径复用，受控工具换来明确边界，混合编排换来更广的问题覆盖面。每一种收益，都对应一项需要持续承担的工程责任。

好的AI问数系统，应当让模型善于理解问题，让计算引擎负责算数，让企业自己的规则约束口径和权限。

只有这三者各司其职，问数才能从演示功能变成可依赖的分析服务。