贝壳商机平台：基于 NL2SQL 实现指标查询实践

一、背景

门店商机管理助手是专为店东量身打造的智能化门店管理工具。通过整合门店旗下经纪人作业过程中的关键指标数据，结合客户沟通场景的深度数据挖掘，系统可实现多维度对比分析，精准定位业务薄弱环节，并基于数据分析结果输出针对性建议和举措，店东客根据建议和举措对经纪人进行有效管理，助力经纪人优化作业流程、提升专业服务能力，最终实现商机转化率的显著提升，为门店业绩增长构建数据驱动的管理闭环。

门店商机管理助手采用 「Chat 交互 + GUI 可视化」混合形态构建工具矩阵，既支持通过智能对话引擎（Chat）为店东提供实时业务指标咨询、数据解读及策略建议（如经纪人作业优化方案、客户沟通话术指导等），又依托图形用户界面（GUI）打造可视化数据看板，直观呈现经纪人作业过程指标（如商机、转化、客户解读等）。这种「对话式交互 + 可视化分析」的双引擎模式，可助力店东兼顾动态决策的灵活性与数据管理的精准性，实现从「数据洞察」到「业务优化」的全流程效率跃升。

在门店商机管理助手中，作业指标查询是核心能力支撑模块，其底层依托商机指标平台构建的标准化数据底座，实现指标建模、指标加工到数据存储标准流程。作为工具的数据根基，指标平台不仅提供指标数据，也提供指标字典，元数据的定义；在此基础上，作业指标查询功能结合 Chat 智能交互引擎，系统可自动响应自然语言查询指令（如 “查询门店转带看率周环比”），并同步输出优化建议，形成「数据查询 - 智能分析 - 策略生成」的闭环能力，确保店东基于精准数据底座驱动业务决策，夯实商机转化的过程管理根基。

二、作业指标查询-NL2SQL 通用方案对比

NL2DSL（自然语言转领域特定语言）

通过语义解析将自然语言查询转换为中间层领域特定语言（DSL，Domain Specific Language），再由 DSL 映射生成目标 SQL 语句。

例：自然语言 “查询 Q2 XX 门店带看量 Top10 的经纪人” → 转换为自定义 DSL（如{ "action": "query", "dimensions": ["经纪人"], "metrics": ["带看量"], "filters": {"时间": "Q2", "门店": "XX"}, "sort": "desc", "limit":10}）→ 生成对应 SQL（select agent_id from table1 where shop='XX' and date>'XXXX' order by show_count desc limit 10）。

具体实现流程如下图，其中需要定义 DSL 规则，开发 DSL 解析器及 SQL 映射器。

NL2SQL

直接将自然语言查询映射为 数据库操作语言（DML，Data Manipulation Language），即原生 SQL 语句。

例：自然语言 “查询 2025 年 6 月商机量超过 100 的经纪人” → 直接生成 SELECT 经纪人 ID FROM table WHERE 时间='2025-06' AND 商机量>100。

具体实现如上图，需要获取数据库表 schema 来生成 sql。

三、 NL2SQL 实践

3.1 方案选择

在构建自然语言查询能力的过程中，我们选择了基于 NL2SQL（Natural Language to SQL）技术方案，主要基于以下几个方面的考虑：

（1）应用场景灵活，适配用户查询

需求自然语言查询具备良好的通用性与可扩展性。通过 NL2SQL，用户可以用一句话完成诸如“查询昨天北京 ccc 门店的带看量”、“近 7 日转化率趋势”等查询请求，避免了对字段、表结构、查询语法的深入理解。

（2）良好基础设施支撑-商机指标平台商机指标平台

基于 Apache Doris 数据仓库构建，在表结构、指标体系和查询优化方面已形成规范化体系。平台特性天然适配 NL2SQL 技术的快速落地，具体体现在：

• 统一的数据存储引擎： 平台底层基于 Doris 构建，无需适配多种异构数据源，SQL 接口统一，执行逻辑简洁。

• 清晰的指标字段映射： 商机平台中的基础指标如“商机量”、“带看量”、“成交量”等在 Doris 表中均有明确字段表示，且已通过指标管理系统进行口径定义，无需额外引入 DSL（Domain-Specific Language）层来做字段转换和口径解释，降低了技术实现复杂度。

• 标准化的数据维度： 包括时间字段（如 occur_date）、组织维度（如 agent_id, shop_id, area_id）等均已完成统一命名、格式化处理，使得自然语言问题可快速对齐到字段层，无需复杂的语义映射或 JOIN 推理逻辑。

• 减少复杂 JOIN 推理： 平台核心查询指标相同类型和维度会聚合在宽表中，JOIN 逻辑简化，从而减轻了大模型推理和结构生成负担。

综上，商机指标平台具备清晰的指标管理、标准化的数据模型和存储方案，极大提升了 NL2SQL 方案的实施可行性与准确率。当有新的指标接入指标平台，这套方案无需任何开发，即可查询指标数据。

具体实现如下图所示

3.2 难点及解决方案探索

3.2.1 难点

• 自然语言复杂性

• NL2SQL 准确率问题

只使用 table schema 进行 SQL 生成，如何能准确定位多张表的多个字段？

3.2.2 解决方案探索

（1）增强语义理解

用户的自然语言输入形式多变，语义理解可能存在歧义或不完整情况，尤其在涉及口语化表达、上下文省略或多轮对话时，系统需要具备足够的智能去理解、引导并修正用户意图。为此，我们主要围绕以下方面优化：

• 指代消歧： 用户可能使用“谁”、“人员”、“人”等含糊词汇指代“经纪人”，系统结合当前查询上下文、字段使用频率、实体别名等方式进行判别。例如：“查询昨天谁的商机量最多”，需解析为“查询昨天哪个经纪人的商机量最多”。

• 多轮对话承接与补全： 对于多轮查询，如用户首次提问“查询张三商机量”，后续接着问“那他最近 7 天趋势呢？”，需承接历史语义补全主体“张三”以及指标上下文。

• 错误纠正与引导推荐： 当用户提问超出系统支持指标集合或维度组合，如“查询门店业绩波动指数”，系统需反馈：“暂不支持‘业绩波动指数’指标，可查询‘门店业绩总额’、‘门店环比增长率’等。” 。填充默认数据。比如，对于同一类型，指定默认指标。

例：同一类型

1. non_private_opportunity_count（非私域商机量）-默认

2. organic_opportunity_count（自然商机量）

3. commercial_opportunity_count（商业化商机量）

4. opportunity_count（总商机量）

用户输入“查询 CCC 门店 2025 年 6 月商机量”，查询的是“CCC 门店 2025 年 6 月非私域商机量”，生成：

SELECT SUM(non_private_opportunity_count) AS total_non_private_opportunitiesFROM business_opportunityWHERE date >= '2025-06-01' AND date < '2025-07-01' and shop=CCC; 

• 领域词义补充与转换： 某些术语为行业内部通用缩写或复合指标，例如“三好经纪人”代表“响应率>x 且转化率>y 且商机量>z”的组合条件。我们通过在知识库中维护这些业务语义解释，辅助模型做规则展开，生成对应的 WHERE 条件组合。

（2）提升 SQL 生成准确率

由于 NL2SQL 任务的核心挑战在于如何精准映射自然语言到具体 SQL 结构，提升准确率成为系统成功的关键。我们采取以下手段：

• 构建指标知识库： 为每个业务指标维护其名称、口径定义、所依赖字段、所属表、维度限制等信息。系统通过召回 Top-N 相关指标，用于提示语生成或直接使用指标生成 SQL 模板。

• 处理衍生指标： 对于没有直接字段映射的衍生指标（如“转成交率 = 成交量 / 商机量”），维护计算公式，并解析依赖字段及所属表信息，辅助模型根据多字段+表达式组合生成 SQL 语句。

• 时间格式规范化： 将用户自然语言中提到的“今天”、“上周”、“近三月”等模糊时间统一转换为 Doris 兼容时间格式，如 DATE '2025-06-01'，避免 SQL 语法错误和执行失败。

• Few-shot 示例增强： 构建覆盖常见场景（如商机量按城市分布、转化率趋势、多维度 TOP 排行等）的问题-SQL 对，以 few-shot 方式加入 Prompt，提升大模型泛化能力与结构一致性。

NL2SQL 通用提示词模版构建，适配多种业务场景

迭代过程中 Prompt 策略需要不断优化，同时参考网上资料，总结了一套比较通用的 NL2SQL 的 Prompt 方案。在 NL2SQL 的 Prompt 中包含指令（Instruction）、库表结构（Schema）、拼接规则和参考样例（Sample）、约束条件（Attention）、输出格式（Format）、领域知识（Knowledge）、用户问题（Question）这六个要素有较好效果：

• 角色（Instruction）：比如，“你是一位资深数据分析专家，精通 Apache Doris，擅长根据用户自然语言问题，并参考库表结构和聊天记录，生成高效且可执行的 SQL 查询语句。”

• 库表结构（Schema）：将查询出的 Table Schema 动态拼接到 prompt 中，通常包括表名、列名、列的类型、列的含义、主外键信息。如果字段较多，可适当裁剪。

• 拼接规则和参考样例（Sample）：比如时间格式规则，“date 是 2025-09-09”。

• 约束条件（Attention）：有必要的指示。比如拼接的 SQL 要求禁止添加注释，禁止 markdown 格式数据。

• 输出格式（Format）：json 输出，比如{"sql":"select ..."}

• 领域知识（Knowledge）：比如衍生指标计算公式（“转成交率=成交量/商机量”），比如“谁是三好经纪人”，需要告知模型，“三好经纪人”代表“响应率>x 且转化率>y 且商机量>z”

• 用户问题（Questions）：自然语言问题。

#Instruction你是一位资深数据分析专家，精通 Apache Doris，擅长根据用户自然语言问题，并参考库表结构和聊天记录，生成高效且可执行的 SQL 查询语句。#Sample拼接规则和参考样例如下：${Sample}
#Attention注意：${Attention}
#Format输出格式要求：${Format}
#Knowledge问题相关的领域知识如下：${Knowledge}
#Questions用户问题：${Questions}

以上是通用 Prompt 模版，每个部分都可以根据业务场景不同动态拼接出完整的提示词。

（3）SQL 风险控制

由于 SQL 由自然语言自动生成，安全与性能控制尤为重要，系统需避免出现破坏性或高开销的 SQL。我们通过以下措施保障系统稳定运行：

• 类型限制： 限制仅支持 SELECT 语句执行，禁止更新、插入、删除操作，防止 SQL 注入与数据污染。例如“更新张三商机量为 100”的 SQL 会被判定为非法。

• 语法与语义校验： 执行前进行 SQL 语法解析与语义验证，确保所有字段在表结构中存在、语义逻辑合理。

• 默认限制与提示：

时间范围控制：若用户未明确限定时间段，系统默认设置最近 7 天或当月范围，避免无意全表扫描。

结果数量控制：若查询未设置 LIMIT，系统自动添加如 LIMIT 100 以限制数据返回量，避免过大结果影响前端加载。

查询计划分析与反馈：在某些关键查询场景中，系统会调用 Doris EXPLAIN 语句分析执行计划，若出现全表扫描、索引缺失等问题，给予提示并建议优化查询方式。

（4） MCP Server 支持-降低维护成本

基于上述方案实现 workflow 执行流程为人工拆解和编排。 LLM 与 MCP Server 通过工具链协同和任务流程优化，显著增强了 NL2SQL 的性能和可靠性，将人为任务拆解流程交给 LLM，通过 COT 方式拆解和执行。

• 工具链协同

MCP Server 提供以下工具，提升 SQL 生成质量，完成取数逻辑：

get_schema：提供 Doris 表结构信息（表名、字段名、数据类型、约束），帮助 NL2SQL 准确映射用户意图到字段。

sql_query：执行 SQL，返回查询结果。

sql_valid：通过语法和语义校验，确保生成的 SQL 合法且安全，防止无效查询或 SQL 注入。

sql_explain：分析 SQL 的执行计划，识别潜在性能瓶颈（如全表扫描），并建议优化策略（如添加索引）

• 任务流程优化

MCP Server 结合 LLM 的 Function Calling+ReAct 和 Chain-of-Thought 能力，优化 SQL 生成策略：Function Calling：LLM 通过调用 MCP Server 的工具接口（如 Schema 查询、SQL 验证），动态获取元数据和校验结果，提升生成准确性。例如，LLM 调用 Schema 接口确认字段类型，确保时间格式正确。COT：通过分步推理，LLM 自动调整 SQL 生成策略。例如，面对复杂查询（如“查询响应率低的经纪人，并进行周商机量对比”），COT 分解为子任务（解析术语、匹配字段、生成条件），提高查询质量。

性能优化：结合执行计划分析，自动添加性能优化条件（如时间范围、LIMIT），避免低效查询。

LLM 与 MCP Server 的结合，将人为任务拆解流程交给 LLM，通过 COT 方式实现自动化分步推理，有效解决了 NL2SQL 中的语义理解、表关联和查询优化难题，实现了从自然语言到高效 SQL 的智能转换。

3.3 NL2SQL 评测     

为了全面测评 NL2SQL 的可靠性，我们参考了业内通用评价体系：精确匹配率、执行正确率

• 精确匹配率(EM)：衡量生成的 SQL 是否与标准答案完全一致。这是一个严格的度量标准，但并不总是反映实际效果。

• 执行正确率(EX）：只要两个查询在相同输入下产生相同的输出结果，就被视为成功。这种方法更能体现功能上的等效性。

以上评价体系都不能更精准的测评 NL2SQL 的准确率。

为了提高 EM，将 SQL 拆解成多个模块进行对比分析，达到 SQL 逻辑一致的效果，最终得到测评结果。

• 构建评测集

为全面覆盖商机指标查询场景，我们设计了多样化的评测集，包含问题构建和 Golden SQL 构建。

问题构建：评测集分为三类查询，覆盖简单到复杂的场景

(1)简单查询：明确的时间、指标和维度，代表基础查询需求。

(2)中难度查询：涉及指标环比、指标趋势、Top 排行等，需处理复杂逻辑

(3)语义问题查询：包含指代消歧和模糊问题，测试语义理解能力。

Golden SQL 构建：为每个查询提供标准 SQL，需验证过的，确保准确性和性能（如使用索引、避免全表扫描）。Golden SQL 存储在评测集中，作为评测基准。

• NL2SQL 评估

评测的方式是首先通过 SQL 模式对比算法进行对比，判断 SQL 执行的逻辑是否相同，并且还会通过 SQL 执行引擎判断 SQL 的执行结果是否符合预期。只有两个完全一致才符合要求，如果只要有一个不一致就会走到人工来评估。

最终经过系统+人工评估之后，在商机指标查询场景准确率可以达到 93%。

总结与思考

LLM 与 MCP Server 通过工具链协同（Schema 感知、SQL 验证、执行计划分析）和任务流程优化（Function Calling、COT），显著增强了 NL2SQL 在商机指标平台中的性能和可靠性。COT 方式将人为任务拆解流程自动化，解决了语义理解、表关联和查询优化难题。语义对齐（指代消歧、纠错提示、领域知识补充）、准确率提升（指标知识库、衍生指标、时间规范化、Few-Shot）和 SQL 风险控制（注入防控、性能优化）确保了查询的准确性、安全性和高效性。NL2SQL 评测通过多样化的评测集（简单查询、中难度查询、语义问题查询）和模块化拆解（SELECT、FROM、WHERE 等），结合 EM（精确匹配率）、EX（执行正确率）和模块准确率，精准验证了系统的性能，综合准确率达 93%。而相较于 NL2DSL，NL2SQL 开发成本低、生态成熟，完美适配单一 Doris 集群、指标直接映射的场景。

未来方向

为进一步提升 NL2SQL 的适用性，我们计划在以下方向持续探索：

1. 指标 RAG（Retrieval-Augmented Generation）：

a. 目标：构建更智能的指标检索和生成机制，通过 RAG 技术增强 LLM 的上下文理解能力。

b. 实现：将指标知识库与向量数据库结合，基于用户查询检索最相关指标、表结构和计算公式，动态注入 LLM 的提示词。

c. 价值：RAG 可减少对预定义规则的依赖，增强对复杂指标和动态口径的处理能力，适配多变业务场景。

2. NL2SQL 模型微调：

a. 目标：通过领域特定数据微调 LLM，提升商机指标查询场景的适配性。

b. 实现：收集更多用户查询-SQL 对数据集，结合评测集中的复杂查询（如环比、Top 排行、语义问题），优化指代消歧、术语解析和 SQL 生成质量。

c. 价值：微调后的模型将更精准理解业务术语（如“三好经纪人”）和复杂逻辑，提升 EM 和 EX 指标。

3. COT 对复杂查询任务的拆解和执行：

a. 目标：进一步优化 COT 推理，处理更复杂的查询场景（如多表关联、嵌套子查询、动态口径）。

b. 实现：通过设计更细粒度的 COT 模板，将复杂查询拆解为更小的子任务（如指标解析、表关联推理、条件生成、性能优化），并结合 MCP Server 的工具链动态调整执行策略。

c. 价值：COT 的细化拆解将提升复杂查询的准确性和可解释性，增强用户信任和系统鲁棒性。

未来展望

通过指标 RAG、模型微调和 COT 优化，NL2SQL 将进一步提升对复杂业务场景的适配能力，结合 MCP Server 的工具链支持，可实现更智能、高效、安全的数据查询服务。若业务扩展至多数据源或复杂口径对齐，可探索混合方案（NL2SQL 为主，DSL 为辅），为商机指标注入更强大的数据分析能力。