AI 自然语言查数据怎么实现？从问句到图表的零代码配置

龙石数据

319人浏览 · 2026-07-13 13:55:19

龙石数据 · 2026-07-13 13:55:19 发布

一、场景介绍

销售总监老李周一早会前打开ERP系统，想快速查一组数据："各区域本月销售额完成率是多少？和上个月环比变化怎么样？再拉出近六个月的月度趋势看看。"他打开BI工具点了半天，发现需要的维度分散在三个不同的报表里，做交叉分析得先导出Excel再手动合并。他给IT部门发了条消息，很快收到回复：需求已收到，排期大约三天后给结果。

这不是老李一个人的问题。在大多数企业的实际工作场景中，业务人员想查询分析数据的路径是固定的：提需求、等排期、IT写SQL（Structured Query Language，结构化查询语言）、返回结果、发现不对、再沟通、再等。一个简单的问题来回几天是常态，复杂一点的交叉分析等一两周也不罕见。

这个问题背后更深层的矛盾在于：企业花大量资源建设数据平台、打通数据孤岛、汇聚数据资产，最终的目的是让数据服务于业务决策。但如果业务人员每一次查数据都必须经过IT翻译，数据中台建设得再好也只是IT团队的后台工具，距离真正赋能业务还差最后也是最关键的一步——让不懂SQL的人也能直接用数据。

二、前置条件：AI读懂数据的四项基础

AI智能用数（即通过自然语言对话的方式查询和分析企业数据）不是在空白系统上装一个聊天界面就能跑通的。一个用户输入"本月华东区销售额排名"，AI需要完成一系列动作：理解用户意图、定位相关数据表、确认字段含义、生成查询语句、返回结果并解读——这个链条的每一步都依赖于数据治理底座的支撑。以下四项基础能力，是AI用数能否跑通的前提。

2.1 数据资产目录——让AI知道"有哪些数据"

数据资产目录（Data Asset Catalog，即对企业全部数据资源的系统性编目和索引）在AI用数场景下的角色发生了根本变化。过去，资产目录更多是一份给管理层汇报的"全景图"。但在AI用数场景中，资产目录变成了AI的导航地图。当用户用自然语言问"本月华东区销售额"，AI需要在资产目录中完成定位：销售额数据存在哪张表里、华东区对应哪些字段、这些表和字段之间是什么关系。目录全不全、目录里的元数据描述准不准，直接决定了AI能不能找到正确的数据。

2.2 元数据管理——让AI理解"数据是什么意思"

元数据（Metadata）即"关于数据的数据"，通俗地说就是数据的"使用说明书"。一个字段名叫customer_name，如果不标注元数据，AI只知道这个字段存的是字符串。但如果标注了元数据——“此字段为ERP客户管理模块中的签约客户全称，与CRM系统中的company_name字段对应同一个业务实体”——AI就能在用户问"客户签约情况"时准确关联到这个字段。当同一个概念在不同系统中的叫法不同（比如ERP叫"客户名称"，CRM叫"签约主体"，财务叫"往来单位"），元数据层负责统一这些语义差异，为AI提供一致的"翻译层"。

2.3 语义模型与数据标准——让AI跨系统理解业务

更关键的是语义层面——不同业务系统对同一个概念的"口径"可能完全不同。以"销售额"为例：ERP系统按含税签约金额计算，财务系统按不含税实收金额计算，CRM系统按销售机会预估金额计算。如果这些口径差异没有在语义模型层面统一对齐，AI就只能忠实地汇总它能找到的数据——而它找到的数据本身口径就不一致。这就是为什么在问"华东区销售额"时，模型返回3200万、财务系统显示2800万的典型案例：不是模型算错了，是数据口径源头就不统一。

2.4 数据质量——让AI输出的结果可信

数据质量（Data Quality）即数据的准确性、完整性、一致性和及时性，在AI用数场景中是最先暴露的问题，也最容易被人误判为"模型不行"。大语言模型对输入数据的"信任"——它不会主动质疑数据来源的可靠性，脏数据会被模型当作事实全盘接受，然后生成流畅但可能完全错误的分析结果。龙石数据中台采用旁路监测模式应对这一挑战：数据正常入库不阻塞业务流转，质检规则在旁路并行扫描，发现问题后自动标记、告警并生成质量工单。

三、配置实战：让AI听懂销售问题

以下配置流程基于龙石AI用数智能体的管理端功能，覆盖从创建场景到发布上线的完整路径。

3.1 步骤1：创建用数场景

目的：为"问数据"智能体定义工作上下文——关联哪个数据源、使用哪套指标体系、遵循什么样的分析规则。一个场景就是一个对话沙盒（Dialogue Sandbox），用户进入不同场景就进入不同的数据工作区。

操作：进入智能体管理→数据知识管理→创建场景。填写三项核心信息：场景名称（如"销售数据分析"），场景描述（如"覆盖订单、回款、退货、客户维度，支持区域/产品/人效多维度分析"），关联业务领域。

3.2 步骤2：接入元数据

目的：让AI知道该场景下可查询哪些数据表、每张表有哪些字段、每个字段的业务含义是什么。

操作：在数据知识管理中配置元数据源，系统自动采集关联数据库中的表结构、字段名称和字段类型。采集完成后，需为每个字段逐项补充业务含义说明——不只是写"字符串类型、长度50"，更要写清楚"这个字段在业务中代表什么、从哪个系统来、计算口径是什么"。同时设置字段启用状态：核心业务字段设为"可查询"，敏感字段（如客户联系方式、身份证号等）设为"不可查询"，实现字段级别的数据权限控制。

3.3 步骤3：提示词模板与召回测试

目的：引导大语言模型按照企业规范生成SQL和回答。提示词（Prompt）即发送给大模型的结构化指令文本，定义了AI的角色、行为边界和输出约束。

操作：平台内置了默认的提示词模板和召回测试机制，一般情况下直接使用即可。在提示词管理中可以查看和微调，但新手上路不必从头编写。配置完成后，在测试界面输入几个真实的业务问题（如"本月各区域销售额排名"），观察AI返回的结果是否符合预期。测试覆盖单表查询、多表关联、聚合统计等几个典型场景即可。

3.4 步骤4：预设高频问题

目的：对企业内最高频的业务查询问题提前配置标准查询语句，确保这部分问题的回答准确率达到100%。

操作：收集业务部门最常问的销售数据问题，按分类录入预设问题库。常见分类包括区域销售分析（“本月各区域销售额排名”、“各区域完成率对比”）、产品分析（“各产品线销量排行”、“产品毛利率分布”）、人效看板（“各团队人均产出”）、趋势分析（“近六个月月度销售趋势”、“同比环比变化”）。每个预设问题配置对应的标准查询语句和预期回答格式。用户在前端使用时可点击预设问题直接查询，无需手动输入。

3.5 步骤5：发布上线

目的：将配置好的智能体和场景从管理端发布到应用端，面向业务用户开放使用。

操作：配置智能体的前端展示信息——名称（如"销售数据助手"）、图标、描述和开场白（如"请输入您想了解的销售数据问题"）。配置场景切换选项，使用户可以在不同业务场景之间灵活切换。确认用户权限分配：按角色设置数据库、表、字段级别的访问范围。设置用户配额（如每人每日200次查询），控制大模型调用成本。所有配置确认无误后，点击发布。

四、配置模板

配置项	填写内容	说明
场景名称	销售数据分析	按业务域命名
场景描述	覆盖订单、回款、退货、客户维度	描述数据范围和可分析维度
关联数据源	sales_db（含订单表、回款表、客户表、区域表）	未关联的数据源对AI不可见
元数据接入	自动采集表结构，逐字段补充业务含义说明	仅靠字段名AI无法理解数据含义
字段权限	客户名称、签约金额→开启；客户联系方式→关闭	从源头阻断数据泄露
提示词模板	使用平台默认	内置角色设定和SQL生成规范
预设问题	"本月各区域销售额排名"等4-6个高频问题	预置标准查询，准确率100%
用户权限	按角色分配数据访问范围	遵循最小化原则
用户配额	每人每日200次查询	控制Token消耗成本

五、验证结果：自然语言查询实战

配置完成并发布上线后，业务人员打开"销售数据助手"智能体，即可以自然语言对话的方式查询和分析销售数据。以下展示三个典型查询示例：

查询示例一：单维度排名统计。 用户输入"本月各区域销售额排名"，AI输出华东、华南、华北、西南等各区域的销售额排名表格，同时自动生成一张柱状图直观呈现各区域对比，并配以文字解读：“本月销售额最高为华东区（1,280万元），其次为华南区（965万元），西南区环比增幅最大（+12.3%）。整体完成率为82%。”

查询示例二：多维度趋势分析。 用户输入"近六个月月度销售额趋势，按产品线分类"，AI返回一张趋势折线图，六条产品线各自呈现近六个月的月度销售额变化曲线，下方附带明细数据表。文字解读自动提炼关键特征：“B产品线和D产品线呈现持续上升趋势，B产品线近六月累计增长34%；C产品线在第四个月出现明显下滑（环比-18%），建议关注原因。”

查询示例三：交叉维度分析。 用户输入"分析一下上季度客户回款率，按区域和大客户/中小客户分类"，AI返回分组柱状图——横轴为区域，每组两根柱子分别代表大客户回款率和中小客户回款率。文字解读：“整体回款率82%，其中大客户回款率（91%）显著高于中小客户（74%）。华北区大客户回款率最低（79%），建议重点关注。”

龙石AI用数智能体在返回数据结果的同时，自动生成自然语言描述对数据的关键特征进行提炼与解释，降低了业务人员理解数据结果的门槛。

六、避坑指南

坑一：元数据不全，AI"读不懂"数据。 现象：用户输入"本月销售额"，AI回复"未找到相关数据"，或者查询了错误的表返回了毫不相干的结果。根因：元数据接入不完整——数据表接入了，但字段的业务含义没有标注。解法：元数据接入环节必须逐字段标注业务含义，不能只停留在字段类型和长度这些技术元数据层面。

坑二：数据口径不统一，AI输出"看着对、实际错"。 现象：销售总监用AI查"本月销售额"得到3200万，财务报告显示2800万，差距400万。根因：同一个"销售额"指标在不同系统中口径不一致（含税vs不含税vs预估）。解法：在数据标准层面统一核心指标的口径定义，确保AI引用的每个指标在语义上单一、明确、无歧义。

坑三：只配工具不建运营机制，“上线即终点”。 现象：智能体上线首月活跃，三个月后日活大幅下滑，偶尔提问发现回答不对，不知道找谁反馈，默默放弃。根因：AI用数不是一次性配置项目，需要持续运营。解法：建立"用户反馈→工单处理→知识库更新→模型优化"的运营闭环。

七、小反转：真正决定效果的不是配置

看到这里，你可能会认为AI用数就是按照上面的步骤逐一配置、反复调优。配置本身确实不复杂——创建场景、接入元数据、编写提示词模板，有经验的运营人员几天之内就能完成部署。但真正决定AI用数效果的，不是提示词写得有多精妙，而是配置背后数据治理的成熟度。

资产目录不完整，AI就找不到数据——这和提示词质量无关。元数据没有标注业务含义，AI就读不懂数据——这和模型能力无关。数据标准不统一，AI输出的结果就是"看着对、实际错"——这和查询逻辑无关。数据质量无人管理，AI给出的分析结论就不可信——这和算法精度无关。龙石AI用数智能体的核心设计前提是：数据治理到位后AI用数效果才好——治理的底子，不能省。

八、案例验证：一个已经跑通的样本

江苏某国企数科运营着一个数据要素流通平台，汇聚了大量公共数据与市场化数据资源。龙石数据为平台部署了AI用数智能体，构建了"感知-匹配-演进"三位一体的智能入口。在技术层面，基于语义检索和模糊检索双模引擎理解用户的自然语言查询意图。运营层面，智能体持续分析用户的搜索失败记录和浏览行为中断点，自动识别潜在数据需求并生成需求洞察报告，驱动数据产品的上架、优化和迭代。

上线后的效果从两个维度得到验证。效率维度：平台基础咨询工单量显著下降，用户从提出问题到获取数据的耗时大幅缩短。价值维度：系统持续挖掘出多个真实用户需求，其中部分高价值需求已进入产品开发流程，数据产品的复用率明显提升。

九、常见问题（FAQ）

Q1：AI用数的准确率到底能达到多少？

AI用数的准确率取决于两个变量：数据治理的质量和问题本身的复杂度。简单场景（按条件查询、单表统计、排名排序）准确率可以做到接近100%；复杂场景（跨多表关联推理、涉及模糊业务概念的查询）会有一定误差。关键区别在于：企业AI用数不是开放域问答，而是在企业自身数据资产范围内做查询和分析——治理到位的元数据和数据标准能大幅缩小AI的理解偏差。

Q2：公司用的是Oracle/SQL Server，不是MySQL，能用吗？

可以。AI用数智能体适配MySQL、达梦、Oracle、SQL Server等多类主流数据源。在提示词模板的SQL约束规范中，将语法类型设置为与实际使用的数据库对应的方言即可。

Q3：数据不出域怎么保证？如果是私有化部署，大模型放在哪？

龙石AI用数智能体支持客户自备本地大模型（如DeepSeek或千问3），所有数据查询和推理分析在本地服务器上完成，企业数据不出域、不上云。大模型部署在客户自有服务器上，数据流转的全链路控制在企业内部网络范围内。

Q4：我们的数据资产目录还没建全，能不能先用起来？

不需要等"完美"再启动。建议先选定一个业务价值最高的用数场景（比如销售数据查询），把这个场景相关的几张核心表的元数据做扎实，配置好提示词和预设问题，先跑通再横向扩展。反过来看，AI用数的需求本身也会驱动数据治理的加速。

Q5：业务人员问的问题太口语化怎么办？

这正是混合检索引擎发挥作用的地方。语义检索和模糊检索双模引擎能够理解"卖得怎么样"背后用户可能想查询的是销售额、增长趋势、完成率等指标。同时，预设问题功能把最高频的业务问题提前配置为标准查询，确保模糊问法也能命中准确结果。

参考来源：