Page 159 - 《软件学报》2026年第3期
P. 159

1122                                                       软件学报  2026  年第  37  卷第  3  期


                 key  query  entities,  and  a  spatial  data  query  corpus  is  constructed  based  on  large  language  models  to  determine  the  query  type.  In  phase
                 (2),  a  structured  language  model  (SLM)  is  selected  according  to  the  query  type,  and  the  entities  are  then  mapped  into  the  structured
                 language  model  to  generate  the  final  executable  language  for  spatial  databases.  Experimental  results  on  multiple  real-world  datasets
                 demonstrate  that  the  proposed  method  enables  efficient  transformation  from  natural  language  queries  to  executable  languages  of  spatial
                 databases.
                 Key words:  spatial database; natural language interface; natural language interface for databases; semantic parsing; query processing
                    空间数据库为地图服务、物流管理和城市规划提供了重要的地理信息数据管理和分析支持. 地理信息技术的
                 飞速发展和广泛应用, 不仅使空间数据的获取变得可行且具有成本效益, 而且推动了对高效处理空间数据的需
                 求  [1] . 近年来, 诸如  GeoSpark 、Ganos 和  SECONDO 等空间数据库系统相继涌现, 这些系统能够支持多种空间
                                       [2]
                                                           [4]
                                              [3]
                 数据查询, 包括基础空间查询、范围查询、最近邻居查询、空间                      Join  查询和聚合查询. 然而, 空间数据查询的高
                 技术门槛与应用用户日益增长的需求之间存在显著鸿沟. 一方面, 空间查询通常需要构造高度技术化、结构明确
                 的查询语句, 这对用户的专业知识提出了较高要求. 另一方面, 随着空间数据的快速积累与广泛传播, 非专家用户
                 逐渐成为空间数据库的主要用户群体. 他们缺乏深入的领域知识, 难以有效地利用空间数据库的潜力. 为了使非技
                 术用户能够通过自然语言直接查询空间数据库, 需要一个数据库自然语言接口 (natural language interface for
                 database, NLIDB). 虽然研究人员对空间数据库进行了大量的研究, 包括数据分区                [5] 、索引结构  [6] 和空间众包  [7] , 但
                 对空间数据库自然语言接口的研究显著不足.
                    尽管  NLIDB  在关系数据库、XML       数据库和    RDF  问答系统等领域已有广泛研究, 但针对空间数据库的研究
                 仍处于起步阶段. 由于空间数据查询的独特复杂性, 尤其是在涉及最近邻居搜索、空间聚合等高级任务时, 传统
                 的  Text2SQL  框架难以直接应用于空间数据库可执行语言的生成. GPT-4o               等大语言模型 (large language model,
                 LLM) 为空间数据库自然语言接口提供了新思路. GPT-4o                支持空间数据上的自然语言查询 (natural language
                 query, NLQ), 并生成语法上正确的可执行语言, 但这些查询通常在语义上是不准确的.
                    NLQ 1 : What universities are there in Jiangning District of Nanjing?
                    以  NLQ 1 为例, 转换过程如图    1  所示, GPT-4o  错误地提取实体 “Jiangning District”, 使用  within  运算符来判断
                 大学是否完全位于江宁区里, 但实际上应该使用               intersects 运算符进行判断. 同时, GPT-4o  生成的可执行语言没有
                 考虑查询优化.

                                    转换方法       实体         运算符       索引
                                                                                     index operation
                                                                             intersects          “
                                   NALSpatial                                      ”
                                                                                                 within
                                                           within
                                     GPT-4o                          –
                 空间数据自然语言查询                                                         数据库可执行语言
                                             图 1 空间数据库自然语言查询转换示例

                    构建空间数据库的自然语言接口需要解决以下两大关键挑战.
                    挑战  1. 空间关系和位置描述涉及复杂的几何和拓扑概念, 用户的查询可能以多种方式表达, 查询语义难以理
                 解. 如果不能准确理解用户的意图, 将导致查询结果的偏差甚至完全错误. 现有的一些自然语言处理 (natural
                                                         [8]
                                                                 [9]
                 language processing, NLP) 工具, 如  Stanford CoreNLP 、spaCy 、NLTK [10] 和  Stanza [11] , 在解析常规文本时表现出
                 色. 然而, 由于空间数据固有的复杂几何关系和多样化查询类型, 这些工具在准确解析空间数据查询方面的效果并
                 不理想. 近年来, 大语言模型在空间数据自然语言查询的语义解析方面展现了巨大潜力                            [12] , 然而缺乏专门针对空
                 间数据查询的高质量训练语料库. 这种数据稀缺性导致模型在生成可执行语言时需要依赖提示工程, 不仅降低了
                 转换精度, 还可能增加开发成本. 虽然微调模型可以部分解决这一问题, 但设计和创建高质量的微调语料库往往需
                 要大量的人力和资源投入, 在实际应用中难以广泛推广.
                    挑战  2. 可执行查询语句需遵循特定的系统级规则, 如何选择合适的数据表和操作符仍是一个尚未解决的问
   154   155   156   157   158   159   160   161   162   163   164