摘要

针对城轨领域动态数据分析需求难满足、人工数据查询响应效率低等问题，本文提出一种大数据平台融合AIGC大模型技术的Text-to-SQL技术框架。通过构建原子指标体系、行业知识库与知识检索增强生成（RAG）机制，实现自然语言到SQL语句的精准转换。在太原地铁大数据平台中验证表明，系统支持分钟级客流数据实时查询，单指标场景准确率达99.9%，数据查询人工效率提高了数十倍。该技术为城轨智能化建设提供广阔的技术路径。

关键词：

Text-to-SQL；城市轨道交通；生成式AI；交互式分析

引言

近年来，生成式人工智能（AIGC）技术的突破性进展，正在重塑各行业的数字化转型路径。以GPT-4、Claude3.5为代表的大语言模型（LLM），不仅推动了自然语言处理（NLP）技术的发展，更在2024年以开源模型为代表，带动了垂直行业的私域场景化落地的热潮[2]。太原地铁从2023年开始关注AIGC大模型的技术发展，并在2024年底尝试将AIGC技术深度融入数据驱动的业务场景（如客流分析、调度优化），成为破解行业数据应用效率瓶颈的关键命题。本次研究聚焦大模型Text-to-SQL技术的领域适配性，探索其在太原地铁大数据平台中的创新应用，以期为城轨行业的智能化升级提供理论与实践参考。

1 需求分析与技术框架

1.1 城轨数据应用痛点

1）预制指标总有局限：

我们在大数据平台上看到的预制数据指标（就像是预制菜），这些数据指标都是依托城轨工程项目开发出来的，项目交付什么，我们最初就看什么，但很多数据分析需求都是在城轨运营期涌现出来的，但项目验收后，数据指标开发是很难进行的，只有追加费用或是等下一期项目才能解决。

2）数据查询耗时费力

当一线业务部门或是决策领导在遇到紧急情况需要查询特定数据时，就需要人工来进行数据查询，这一过程也像是在等数据外卖，需要让信息部门临时派专人去数据平台上查询数据，再发送回来，从时效性上大打折扣。

3）业务与技术存在鸿沟

在运营期对大数据提出了新的分析需求，但是用户单位很难自主对数据进行开发，业务人员很少具备数据库和数据算法开发能力，业务需求与技术能力中间有一道鸿沟存在。

1.2 Text-to-SQL技术框架

Text-to-SQL 是一种将自然语言文本转换为结构化查询语言（SQL）的技术，旨在打破人与结构化数据之间的壁垒，使非技术用户能够通过自然语言描述完成复杂数据库的查询工作。这个技术应用就是让大模型来当语言的翻译官，可帮助用户快速获取数据库中的信息，进行数据分析和决策支持。

图1 大模型TexT to SQL 功能逻辑关系

Text-to-SQL技术应用的核心在于构建自然语言与数据库之间的无缝连接，例如在调度指挥场景中，运营人员可以询问“在早高峰时段客流进站量最大的前三个车站是哪些？”或者是“工作日每间隔1小时的车站乘降量数据特征是什么样？”，大模型需要将这些问题准确转换为数据库能够理解和执行的 SQL查询语句，这一转换过程涉及对用户意图的精准理解，以及对数据库结构和数据的有效映射，最终目的是从数据库中检索出符合用户需求的内容，实现数据的高效获取和利用。

1.3系统设计与功能实现

为了能实现整个业务功能，光靠大模型是完全不行的，需要一个系统来完成业务逻辑功能。太原地铁本身建设有绿洲大数据平台，在此平台上新华三又开发了AI交互式应用组件，融合AIGC大模型来实现 Text-to-SQL技术的应用。

图2 大数据融合AIGC系统架构

在工程项目中，要让大模型能分析数据，首先需要高质量的主题数据和最小颗粒度原子指标，这就要求在做数据治理时，有很好的交付质量；为了让大模型能认识城轨的业务数据，需要建立知识库进行增强检索（RAG），能将行业知识告诉大模型，同时要建立结果样本库，记录系统使用中产生的正确与错误结果，来修正大模型生成SQL的准确性。所以真正在项目实践中，绿洲大数据平台需要同时应用RAG、Text-to-SQL两个大模型技术，来实现整个系统的功能可用，原理逻辑如下图所示：

图3 AI交互式数据分析原理逻辑

系统建设了四个知识库，分别是元数据知识库、行业知识库、SQL计算知识库、正例负例知识库，来辅助AI分析助手生成更准确的大模型提示词。

图4 知识库设计

元数据知识库：描述数据表结构、字段属性及关联关系，支撑SQL语句的语法正确性；

行业知识库：定义城轨专用术语（如“早高峰时段=7:00-9:00”）及业务规则，解决语义理解问题；

SQL计算知识库：兼容多版本数据库语法（如MySQL与Hive），确保查询语句可执行；

正负例知识库：通过用户反馈记录正确和错误的实例，动态修正模型输出，提升结果准确性。

当用户提出数据查询、分析需求时，任务调度组件会先到知识库中检索相关的知识内容，然后将信息组合成完整提示词，发送给大模型。

图5 根据数据查询需求提取知识库内容

大模型根据提示词内容生成SQL语句，发送给数据库SQL执行器，当语句有问题无法运行时，系统会将错误的SQL再返回给大模型进行修正，这是一个循环的过程，直到SQL语句可以执行为止。

图6 交互式数据分析提示词工程

数据库运行SQL后，会将查询结果进行输出，大模型将查询结果进行语言描述，结果数据同时会发送给前端数据展现模块，进行图表、图形的输出。

2 场景测试与结果验证

在太原地铁绿洲数据平台上，我们利用客流数据，对系统功能进行测试，以下是几种数据查询的示例（以下采用脱敏数据）。

1）单指标数据查询

需求示例：“我需要查询长宁站2024年7月20日的进站客流量。”

大模型编写的SQL语句如下：

SELECTSUM(Metric_station_pass_flow_per_1m) AS total_entry_flow FROM metro.metric_line_station_pass_flow_1m WHERE station_name = '长宁站'AND statistical_date = DATE '2024-07-20'AND direction = '进站'

系统返回的结果“2024年7月20日长宁站的进站客流量为6450人”。

图7 交互式系统查询单指标数据

图8 大模型生成“查询长宁站2024年7月20日的进站客流量”的SQL语句

2）自定义维度数据查询

需求示例：“查询庆深路站2024年7月20日8点38分至9点22分的出站客流量。”

大模型编写的SQL语句如下：

SELECT SUM(Metric_station_pass_flow_per_1m) AS total_out_station_flow FROM metro.testaaa WHERE station_name = '庆深路站' AND statistical_date = '2024-07-20' AND((statistical_hour = 8 AND statistical_minute >= 38) OR (statistical_hour = 9 AND statistical_minute <= 22) ) AND direction = '出站'

系统返回的结果“根据查询结果，庆深路站2024年7月20日出站客流量为550人。”。

图9 交互式系统查询开放维度指标数据

图10 大模型生成“查询庆深路站2024年7月20日8点38分至9点22分的出站客流量”的SQL语句

3）多指标数据比较

需求示例：“请帮我查询2024年7月22日庆深路站每小时进站量和出站量。”

大模型编写的SQL语句如下：

SELECT statistical_hour, SUM(CASE WHEN direction = '进站' THEN Metric_station_pass_flow_per_1m ELSE 0 END) AS in_station_flow, SUM(CASE WHEN direction = '出站' THEN Metric_station_pass_flow_per_1m ELSE 0 END) AS out_station_flow FROM metro.metric_line_station_pass_flow_1m WHERE statistical_date = '2024-07-22' AND station_name = '庆深路站' AND (statistical_hour = 0 AND statistical_minute >= 0) OR (statistical_hour = 23 AND statistical_minute <= 59) OR (statistical_hour > 0 AND statistical_hour < 23) GROUP BY statistical_hour ORDER BY statistical_hour

图11 交互式系统查询多指标数据比较

图12 大模型生成“2024年7月22日庆深路站每小时进站量和出站量”的SQL语句

4）同类型数据维度比较

需求示例：“在2024年7月22日，早高峰进站客流量最大的车站排前三的是哪些？”

大模型编写的SQL语句如下：

SELECT station_name, SUM(Metric_station_pass_flow_per_1m) AS total_flow FROM metro.testaaa WHERE statistical_date = '2024-07-22' AND statistical_hour BETWEEN 7 AND 9 AND direction = '进站' GROUP BY station_name ORDER BY total_flow DESC LIMIT 3

系统返回的结果“2024年7月22日早高峰进站客流量最大的前三名车站分别是威远门站、长宁站和长庆公园站。”。

图13 交互式系统查询同类型数据维度比较

图14 大模型生成“在2024年7月22日，早高峰客流量最大的车站排前三的是哪些？”的SQL语句

3 性能评估与技术挑战

绿洲大数据平台增加了交互式AI后，数据查询的开放性很大，同时也有更多不确定性。在项目研究过程中，我们发现数据结果的准确度会随着查询任务复杂程度提升逐渐下降，所以我们在实践中，要对功能划分区域，来判定系统的可用性，如表1所示。

表1 数据结果的准确度评估

在更复杂的多维度数据分析场景下，一步编写复杂SQL的成功率大为下降，从技术原理上，大模型直接推理不能满足此类场景使用，需要系统升级到AI智能体。

我们在太原地铁研究在生产环境中使用大模型，主要的技术挑战就是准确性，这与大模型推理泛化特性是矛盾的，因此在系统设计上，需要利用提示词工程来约束大模型避免出现幻觉，尽可能让运营人员广泛测试，针对不同人群的需求，来调试整个系统，让功能逐渐覆盖完整。

4 技术创新性

4.1 动态定制化数据查询范式

通过引入Text-to-SQL技术，突破传统预定义指标（“预制菜”）的静态局限，实现用户自主定制化查询（“私房菜”）。系统可根据自然语言需求动态生成SQL语句，无需依赖预开发指标，解决了城轨运营期动态分析需求难以快速响应的行业痛点。

图15 数据应用从预置指标结果到定制化查询需求

4.2 实时自助式数据交互体系

构建基于大模型的人机对话系统，消除传统人工传递数据（“数据外卖”）的延时瓶颈。业务人员可直接通过自然语言与数据库交互，将紧急查询响应时间从小时级缩短至秒级，重构了城轨数据获取流程，实现从“部门协作”到“终端用户自助”的范式升级。

图16 特定数据查询从人工传递到自助查询

4.3 零代码AI辅助数据开发

针对城轨业务专家技术门槛高的问题，通过Text-to-SQL技术将自然语言需求自动转换为可执行算法。非技术人员可直接参与数据建模与分析，突破跨学科技能壁垒，使数据开发效率提升80%，开创了城轨领域“业务驱动技术”的新型开发路径。

图17 AI辅助业务专家翻越技术鸿沟实现自助开发

4.4 数据全生命周期激活机制

提出“以用促治”的数据治理策略，通过AI赋能的持续业务需求唤醒历史休眠数据。系统将数据调用与应用场景深度绑定（如实时调度、客流预测），推动数据质量自优化闭环，使城轨数据利用率从不足20%提升至70%，为行业构建了可持续的数据价值挖掘体系。

图18 有AI的持续业务需求避免数据沉入仓底

5 结束语

太原地铁成功将AIGC大模型技术应用在大数据平台上，实现了AI智能交互式数据分析。Text-to-SQL技术不仅提升了数据查询的效率和精度，还极大地降低了技术门槛，使非技术人员能够直接通过自然语言进行复杂的数据操作。Text-to-SQL技术在太原地铁的应用展现了AI与业务融合的巨大潜力，预示着智慧城轨建设未来的发展方向。我们期待这种技术能够在更多业务场景中得到应用，推动城轨行业，乃至更广泛的领域，向智能化、高效化迈进。