自然语言查询系统是什么？

自然语言查询系统，是一类让用户用日常语言提问，由系统把问题转换成对数据库或分析模型的查询，再把结果返回给用户的工具。它常出现在商业智能平台、对话式商业智能 ChatBI 和数据分析 Agent 中，也被称为自然语言问数。英文资料里通常写作 NLQ，即 Natural Language Query。

这个说法在不同产品和资料里范围不完全一样。本文按企业数据分析场景使用它，讨论的重点是让业务人员直接向数据提问，并获得可核对的结果。通用搜索引擎和语音助手也会处理自然语言，但它们通常返回网页、文档或指令结果，不直接对企业的指标和明细数据做计算，因此不放在同一范围里。

一个典型问题是，上周华东区新客首购转化率是多少，和前一周相比变化如何。系统要识别新客、首购、华东区、周同比这些条件，找到对应指标和表，生成查询，最后给出数值和图表。问题听起来像日常对话，难点落在每个词背后的口径。

自然语言查询系统是什么

更具体地说，它是一套把自然语言问题转成可执行查询的系统。输入是一句业务问题，输出可以是数值、表格、图表，也可以是一段带查询依据的结论。中间至少要有四件事，理解问题、对齐业务语义、执行查询、组织结果。

TechTarget 在 NLQ 词条里把它描述为一种在分析平台中用日常语言提问的能力，用户不需要写查询语言。这个描述抓住了核心，却没有限定技术路线。早期系统靠规则和语法解析，现在更多系统用大模型理解问题，再由语义层或查询引擎执行。

它不一定是一个独立产品。有的系统把它做成搜索框，有的做成聊天窗口，有的嵌在报表、客服工作台或运营后台里。判断一套系统是否属于自然语言查询系统，关键看它是否真的查询了结构化数据并返回可核对的结果。对话框只是交互形式。

它和普通搜索的差别在返回物。搜索返回的是网页或文档，用户自己从内容里找答案。自然语言查询系统返回的是对数据的计算结果，比如某个指标的值、一组排名或一张趋势图。前者关心内容是否相关，后者关心查询是否执行正确、口径是否一致。

它也不负责解决所有数据问题。数据缺失、埋点错误、指标定义冲突，不会因为加了一个对话框就消失。它擅长回答有多少、哪些、趋势如何、差异在哪这类问题。至于为什么下降，通常还要结合分析模型、业务背景和人工判断。

自然语言查询并不是大模型出现后才有的概念。Androutsopoulos 等人在 1995 年的一篇综述里，已经在讨论数据库自然语言接口的历史、体系结构、可移植性和局限。大模型改变的是语言理解和查询生成的方式，问题定义、语义映射和执行校验仍然存在。

从一句问题到一张图表，中间发生了什么

可以把一次问数拆成五步。每一步都可能成为准确率的分水岭。

第一步，拆出问题里的分析要素

系统先要判断用户想做什么，是查一个数、做对比、看趋势，还是找排名。然后识别指标、维度、时间范围、筛选条件和统计粒度。比如上周华东区新客首购转化率，至少包含新客、首购、转化率、华东区、上周五个要素。缺少任何一个，查询都可能答非所问。

这一步最常见的麻烦是歧义。最近是近 7 天还是近 30 天，新客是首次访问、首次注册还是首次下单，销售额含不含退款。系统要么追问，要么按已确认的口径处理。直接猜一个，往往能得到一个看起来很合理的错误答案。

第二步，把业务词映射到数据对象

业务人员说的是客户、订单、渠道、活动，数据库里存的是表、字段和关联关系。系统需要把前者映射到后者，这一步常被称为模式链接，英文写作 schema linking。它要判断该用哪张表、哪些字段、怎么关联、用什么过滤条件。

映射的质量，很大程度取决于企业有没有把指标和维度定义清楚。自然语言查询系统可以理解语法，却很难凭空知道同一家公司里日活到底按启动、登录还是关键行为计算。业务语义不清楚，模型只能猜，猜出来的 SQL 也可能正常执行。

第三步，生成并执行查询

常见做法有两种。一种是让大模型直接写结构化查询语言 SQL，灵活，能处理没有预先建模的问题，但容易选错表、连错表或漏掉过滤条件。另一种是先让模型选出指标和维度，再由语义层确定性地生成查询。后者的覆盖范围受建模边界限制，覆盖范围内的一致性更好。

dbt Labs 在 2026 年更新的基准里，用 11 道保险业务问题、每题跑 20 轮做了对照。gpt-5.3-codex 直接生成 SQL 的准确率是 84.1%，走语义层是 100%；claude-sonnet-4-6 从 90.0% 提升到 98.2%。这个测试集很小，不能当成普遍准确率，但它说明了一件事，在已建模的范围内，语义层能把查询从自由生成变成受约束的选择。

查询生成之后，还要经过权限、成本和只读校验。用户能不能看这张表，能不能查这个字段，一次查询要扫多少数据，都要在执行前判断。没有这些约束，问数入口会变成数据安全的缺口。

第四步，校验结果并组织答案

结果返回后，系统要检查行数、空值、时间范围、对比基准是否合理，再决定用数字、表格还是图表呈现。更成熟的做法会把查询语句、指标定义、数据来源和时间范围一起展示，方便业务人员核对。

这一步决定了用户敢不敢用。只给一个数字，业务无法判断它是按什么口径算出来的。把依据摊开，即使结果有偏差，也能快速定位是定义、关联还是过滤条件出了问题。

第五步，把修正回流到知识库

用户指出新客口径不对之后，修正不能只停留在这一次对话里。系统需要把确认后的定义、同义词、示例问题和标准查询沉淀下来，下一次同类问题直接复用。没有回流机制，系统会一直停在演示阶段，每次都要重新猜。

自然语言查询的准确率，最终落在三件事上，指标是否确定、数据是否可用、权限是否清楚。

图 1：一次问数的基本链路。结果核对后，修正会回流到语义层，下一次同类问题复用。

它和聊天机器人、传统 BI、知识库问答差在哪

这几个概念经常被混用。把它们放在一起看，差别主要在数据基础和结果形态。

传统 BI 的优势在确定性。报表一旦定义好，所有人看到的数字一致，适合稳定监控。自然语言查询的优势在临时探索，业务人员不用等排期，能自己追问。两者互补，各自覆盖不同的取数场景。

通用聊天机器人回答的是语言问题，它可以解释一个概念，却不能保证算对企业的转化率。文档知识库问答回答的是文档里写了什么，适合制度、流程、产品说明，不负责对数据库做聚合计算。自然语言查询系统的答案必须能落到一条可执行查询上。

和 ChatBI 是什么关系

很多厂商把自然语言查询和 ChatBI 混着叫。更准确地说，ChatBI 强调对话式的 BI 交互，通常包含多轮追问、图表生成、洞察解读等能力。自然语言查询强调的是把问题转成查询的那层能力。一个 ChatBI 产品通常包含自然语言查询，但自然语言查询也可以嵌在报表、客服、运营系统里，不一定以聊天产品的形态出现。

NL2SQL 和 Text-to-SQL 通常指把自然语言转成 SQL 这一步，范围比完整的自然语言查询系统更窄。完整的系统还要处理语义映射、权限、结果呈现和反馈。

为什么有些系统能答，答案却不敢用

演示环境里，几张表、十几个字段、几个标准问题，系统很容易显得聪明。到了企业环境，问题会集中暴露。

同一个词，多套口径

日活、新客、收入、留存，这些词在不同团队嘴里往往不是同一个意思。腾讯云开发者社区在一篇关于自然语言问数的文章里举过例子，上周新客转化率下降了多少，新客可以按首次访问、首次注册或首次下单定义，转化率可以指注册转化或支付转化，上周也可以按自然周或活动周期计算。每一个条件不落到确定对象，答案就会漂移。

这类错误危险的地方在于，查询能跑通，数字也像那么回事。业务人员如果不熟悉底层表，很难发现算错了。

企业库表比演示环境复杂

Spider 2.0 是一个更接近企业场景的 Text-to-SQL 基准，包含 632 个真实工作流问题，数据库经常超过 1000 列，SQL 可能上百行。官方页面给出的对比是，GPT-4o 在 Spider 1.0 上的成功率是 86.6%，在 Spider 2.0 上只有 10.1%。这组数字不能直接套到某一家企业，却足以说明，学术基准的高分不能自动外推到真实库表。

企业数据里还有大量历史表、缩写字段、临时表、重复口径和缺失注释。系统要在这堆信息里找对表，难度远高于做几道标准题。

权限、审计和成本

问数入口连接的是企业真实数据。谁可以看哪张表、哪个字段，能不能导出明细，能不能把结果发给外部，都要有明确边界。查询还要控制扫描量、并发和成本，避免一句模糊问题拖垮数仓。

审计同样重要。出了问题，要能回看是谁在什么时候问了什么、系统生成了哪条查询、返回了什么结果。没有这层记录，数据团队很难定位责任，业务也不敢把问数用在正式决策里。

覆盖范围外的追问

再好的系统也有覆盖边界。用户问一个没有建模的指标，或者问一个需要跨源关联的复杂问题，系统应该明确说明当前范围，避免硬猜一个答案。能承认不知道，比每次都给出一个数字更可靠。

企业落地前要准备什么

自然语言查询系统的效果，一半在产品，一半在准备。准备不足，上线后很容易变成演示工具。

先把指标口径定清楚

从一个业务域开始，不要一上来铺全公司。把最近一个季度高频出现的取数问题收集起来，挑出重复率最高的指标，逐个确认计算逻辑、来源表、时间窗口、过滤条件和负责人。同名不同口径的，要先解决冲突。

这一步看起来慢，却能决定后面每次问数是否可信。指标没有唯一解释，系统再强也只能在多个答案里挑一个。

建一层机器可读的语义

语义层把指标、维度、实体关系、同义词和业务规则集中定义，供报表、问数和 Agent 共用。它和文档知识库的区别在于，语义层能被查询引擎直接执行，文档更多是给人读的背景材料。

可以从一个小范围起步。dbt Labs 的基准题目数量不多，不能说明大范围覆盖的效果，但至少说明先把高频问题建模清楚，能减少大量歧义。具体建设方法可以参考 ThinkingAI 的 Agent 语义层建设指南。

权限和分析边界

在系统上线前，把数据范围、字段脱敏、可调用工具和可执行动作分开设计。查询类操作默认只读，涉及导出、触达或修改数据的动作，要单独授权，必要时加人工确认。

用真实问题做评测集

不要只看厂商演示。从自己的业务问题里抽 50 到 100 道，覆盖单指标查询、对比、趋势、排名、多轮追问和边界问题，提前写好标准答案。上线前跑一遍，记录准确率、无答案率和平均响应时间。上线后每次调整语义或模型，再回归一遍。

评测集里要放一些故意问不清楚的问题，观察系统会不会追问，还是直接编一个答案。这个细节比演示时的流畅度更能说明问题。

设计纠错和运营机制

指定指标负责人，建立口径变更记录和错误回流。业务人员反馈答错时，能定位是定义缺失、关联错误、权限不足还是超出覆盖范围。修正之后，下一次同类问题要能复用。没有运营机制，系统不会自己变准。

怎么判断一套系统是否可靠

可以用下面几项做初步判断。重点看它在自己的数据上表现如何，聊天流畅度只能作为参考。

如果一套系统在这六项上都说得清楚，即使当前准确率还有提升空间，至少方向是对的。反过来，演示很流畅，但查询依据、权限边界和覆盖范围都说不清，落地风险会很高。

ThinkingAI 的实践

在 ThinkingAI 的产品路径里，自然语言查询通常作为数据分析 Agent 的入口，放在企业级 Agent 平台 Agentic Engine 和企业级知识库之上。用户看到的是一个提问框，背后要同时处理语义、数据、权限和行动。

Agentic Engine 把自然语言查数作为一项平台能力，提供 Agent 的创建、管理和多 Agent 协作，支持私有化部署。企业级知识库用 Schema-first 的方式把文档、报表和指标定义加工成 Agent 可调用的结构化知识，通过单一事实来源 SSOT 保证同一概念只有一处定义，通过变更集 ChangeSet 记录变更，方便追溯和回滚。对于问数场景，这套知识基础主要解决两个问题，业务词能不能映射到确定的指标，不同业务线问同一个指标能不能得到同一口径。

平台还预置了 100 多个行业 Skills，把留存、付费、投放、归因等分析方法沉淀成 Agent 可以直接调用的能力。企业在这个基础上补充自己的指标口径和业务规则，不必从零定义每一种分析。ThinkingAI 已服务全球 1500 家企业，接入产品超过 8000 款。旗下 Tiki 智能助手在中国信通院的数据分析智能体评估中拿到 4+ 级。这些能力最终要落到具体业务问题上，概念演示只是起点。

如果企业正在评估问数或数据分析 Agent，可以先从一条高频业务链路开始，用自己的问题集验证口径、权限和结果可追溯性。如果企业关注数据主权，可以进一步了解 ThinkingAI 的私有化部署能力。

常见问题

自然语言查询系统需要会 SQL 吗？

业务用户不需要。系统会把问题转成查询，用户只需要把业务问题说清楚。数据团队仍然要准备数据模型、指标口径和权限，复杂分析也可能需要 SQL。问数降低的是使用门槛，数据工程仍然要做。

它的准确率一般有多高？

没有统一数字。企业库表的复杂度、问题类型、语义覆盖程度、模型能力和权限设计都会影响结果。公开基准可以看趋势，但不能直接当成本企业的准确率。更可靠的做法是用自己的真实问题集测，覆盖单指标、对比、趋势、多轮追问和边界问题。

自然语言查询系统和 ChatBI 是一回事吗？

不完全等同。ChatBI 是对话式 BI 的产品形态，通常包含多轮追问、图表和洞察。自然语言查询是其中把问题转成查询的能力。一个 ChatBI 产品通常包含自然语言查询，但自然语言查询也可以嵌在报表、客服和运营系统里。

它会取代数据分析师吗？

它主要承接高频、标准化的取数需求，让业务人员自己拿到结果。深度建模、复杂分析、因果判断和指标体系建设仍然需要分析师。系统把分析师从重复取数里解放出来，才有时间做更深的分析。

数据安全怎么保证？

常见做法包括私有化部署、行级和列级权限、字段脱敏、只读查询、审计日志和导出审批。选型时要逐项验证，不只看宣传页。尤其要确认权限是否覆盖到字段和明细，以及出了问题能不能追溯。

能直接对接现有数据库或数仓吗？

多数产品提供连接器，但能不能支持你的数据库、权限模型和查询引擎，要实际验证。接入前要准备元数据、指标定义和访问权限。数据留在原环境、不迁移，通常更利于控制和合规。

自然语言查询系统的价值，最终要落在确定的指标、数据和权限上。听懂一句话只是入口。

参考资料

• TechTarget，What is natural language query (NLQ)?，https://www.techtarget.com/whatis/definition/natural-language-query
• I. Androutsopoulos 等，Natural Language Interfaces to Databases - An Introduction，1995，https://arxiv.org/abs/cmp-lg/9503016
• Spider 2.0 官方页面，https://spider2-sql.github.io/
• dbt Labs，Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update，https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026
• ThinkingAI，Agent 为什么需要语义层，https://www.thinkingai.cn/hub/data-foundation/semantic-layer-for-ai-agent/
• 腾讯云开发者社区，自然语言问数为什么会出现指标偏差：语义层与权限设计，2026，https://cloud.tencent.cn/developer/article/2736056

以上资料访问于 2026 年 11 月 7 日。