← 返回 2026-05-26

用生成式 AI 拓宽交通安全数据访问渠道:面向空间自然语言查询的 Schema-Grounded 框架 Broadening Access to Transportation Safety Data with Generative AI: A Schema-Grounded Framework for Spatial Natural Language Queries

Mahdi Azhdari, Eric J. Gonzales 📅 2026-05-20 👍 4 2026-07-13 08:36
LLM应用 Text-to-SQL 交通安全 空间数据库 自然语言接口

用 LLM 把自然语言查询编译成确定性空间分析 DAG,降低 GIS 门槛。

前置知识

自然语言接口到数据库 (NLIDB)

NLIDB 旨在把用户的自然语言提问自动翻译成结构化数据库查询(典型为 SQL)。从早期的规则模板系统到如今的 LLM 增强 Text-to-SQL,核心难点都在于用户表述的灵活性与数据库 schema 的严格性之间的差距。

本文本质上是面向空间数据库的 NLIDB 工作,必须先理解传统 Text-to-SQL 的能力边界和失败模式,才能体会为何作者要专门设计语义帧抽象和校验层。

PostGIS 与空间 SQL

PostGIS 是 PostgreSQL 的空间扩展,提供了几何对象(Point/Line/Polygon)、空间索引、邻近分析(如 ST_DWithin)、相交(如 ST_Intersects)等函数。空间查询的计算成本通常显著高于普通关系查询,且涉及距离、坐标系等额外约束。

本文框架的执行引擎正是 PostGIS,所有空间约束最终都翻译成 PostGIS 算子;理解空间操作的代价和组合方式,才能解释为什么 Town Ranking 平均要 61.7 秒、Road Segment Ranking 最长 142.2 秒。

语义帧 (Semantic Frame)

语义帧源自任务型对话系统,结构化表示语句的意图与一组类型化槽位。本文的语义帧包含 targets、references、spatial_constraints、attribute_constraints、relations、ranking 六类顶层组件,每类对应一种分析意图。

语义帧是 LLM 输出和执行引擎之间的中间表示,是理解整套设计的关键枢纽;它是把自然语言的模糊意图转成可验证、可审计的结构化规范的桥梁。

有向无环图 (DAG) 与数据流执行

DAG 是一种节点代表操作、有向边代表数据依赖的图结构,无环意味着不会形成死循环。编译器把 DAG 拓扑排序后逐节点执行,每节点只依赖前置节点结果,因而天然支持可重现、可审计、可静态检查的执行。

本文把每个语义帧编译成空间操作的 DAG,每个节点是一次 PostGIS 调用,每条边是数据依赖。DAG 让重复运行同一语义帧得到同样结果成为可能,是框架 reproducibility 的工程基础。

Schema-Grounded / 模式接地

Schema-grounded 指的是让 LLM 的输出严格落在预定义的实体、字段、值域、关系集合之内,而不是让模型自由生成任意 SQL 或代码。其本质是给模型一张白名单,通过 prompt 约束 + 规则层校验双保险实现。

这是本文与让 LLM 直接生成 SQL 或 Python 代码路线最核心的区别,决定了为什么需要 Validation & Repair Layer、为什么 29% 的查询必须被修复,以及为什么同样的查询永远可重现。

研究动机

交通安全分析在美国已高度依赖数据驱动框架,如联邦公路管理局的 HSIP 和 systemic safety 方法,要求把事故记录、道路属性、地理基础设施数据通过 GIS 工作流整合。但这套技术栈对使用者提出了 GIS 平台、数据库查询和本地数据 schema 三重门槛,导致真正有安全诉求的群体——地方机构、学校安全委员会、社区组织、居民——根本无法亲自检索、过滤、聚合、绘制数据。一个具象场景是:某家长团体想量化某小学 500 米内的行人事故,他们既不会 PostGIS 也不掌握马萨诸塞州 30 类 first harmful event 字段,只能依赖技术中介。已有 LLM+GIS 工作(如 Autonomous GIS、LLMFind、GIS Copilot)多采用直接代码生成或 agentic execution,会带来非确定性、不可复现、错误向下游传播等问题,不满足公共部门对审计性和可问责性的要求。

本文的目标是本文要构建一个 schema-grounded 的自然语言接口,使用户用日常语言就能查询权威交通安全空间数据库,并得到结构化的地图、排名表和可导出数据集。具体目标有三个:(1) 把 LLM 严格限制在意图解释环节,不让它执行分析;(2) 在 LLM 和执行引擎之间插入一个规则化的 Validation & Repair Layer,把自然语言表达强制归一到 schema 支持的规范值;(3) 把规范化后的语义帧编译成类型化的空间操作 DAG,对 PostGIS 数据库做确定性执行,保证输出可复现、可审计、与机构现有工作流兼容。最终意图不是替代专业 GIS,而是让没有 GIS 经验的小机构、社区团体也能参与到以数据为依据的安全规划中来。

与已有工作不同的是,已有工作的缺口是双重错配:其一,通用 LLM+GIS 系统(Autonomous GIS、LLMFind、GIS Copilot 等)面向通用空间查询,没有把交通安全领域的实体类型(Crash/Road/School/BusStop/Crosswalk/Town)、字段结构(severity 四类、first harmful event 30 类)和分析语义(学校邻近筛查、走廊基础设施联动)作为一等公民;其二,这些系统大多依赖代码生成或 agent 执行,在公共部门语境下无法满足 NIST AI RMF 强调的可靠性、审计性、人工监督要求。本文第一个把领域特定的交通安全 schema 与受控 NL 解释 + 确定性执行结合起来,并通过 80 个查询、9 个能力组合的系统性评测把修复率作为可量化指标暴露出来。区别于让 LLM 直接写 SQL 的端到端范式,本文选择 LLM 仅做翻译、规则层把关、DAG 做执行 的三段式架构,把治理责任明确分配到每一层。

核心方法

系统采用三段式管线:自然语言 → 结构化语义帧 → 确定性空间操作 DAG → 数据库结果。直觉上,可以把整个系统想象成一个严格的双层翻译器:第一层用 LLM 做自由翻译——读懂用户口语化的问题,把它翻译成一张结构化的分析工单;第二层用工单触发一连串预先编写好的 PostGIS 查询函数,工单怎么填决定了调用哪些函数、传入什么参数。这样 LLM 永远不直接接触数据库,也永远不生成 SQL。所有 LLM 输出都要经过 Validation & Repair Layer 校验,纠正错误后才是合法工单,最终的工单能且仅能触发预定义的空间操作。整个设计的目标是把语言模型的灵活性与确定性执行的可靠性各取所长,用规则化的中间层把它们黏合起来,并保证同一工单永远产出同一结果。

核心创新是把语言解释与分析执行通过一个语义帧 + 校验层显式解耦,这与已有 LLM+GIS 路线有本质区别。已有 LLM+GIS 系统(Autonomous GIS、LLMFind、GIS Copilot)大多让 LLM 直接生成代码或由 agent 自由组合空间算子,输出虽灵活但不可重现;纯 NLIDB/Text-to-SQL 工作又通常只能生成 SQL 字符串,缺乏对执行路径的审计能力。本文关键不同点有三:(1) 中间表示用结构化 JSON(语义帧)而非 SQL/代码,schema 是封闭的六类顶层组件,模型输出必须严格落在 schema 内;(2) 校验层是规则化的而非端到端可学习的,每个修复动作(值归一、地理锚点解析、结构修正)都可解释、可追溯;(3) 执行阶段用类型化 DAG 而非文本查询,DAG 节点之间的依赖关系显式声明,便于静态检查(无环、节点类型合法、最终节点对应合法输出)。这种封闭 schema + 规则校验 + DAG 执行的三件套让系统既能享受 LLM 的语言理解能力,又满足公共部门对 reproducibility 和 auditability 的硬性要求。

方法步骤详情

系统流程分四步。第一步,LLM 解释:用户查询被送入 Gemini 2.5 Flash 或 GPT-4o(任选其一),模型依据结构化系统提示输出语义帧 JSON。第二步,Validation & Repair Layer 执行四种修复:schema 校验、值归一(如 $1\,\text{km} \to 1000\,m$、$4\text{pm}\text{-}8\text{pm} \to [960, 1200]\,min$)、锚点解析(学校名/地名转坐标,歧义时弹回用户确认)、结构修正(删除虚假 anchor、合并重复约束)。第三步,编译为 DAG:校验后的语义帧被编译成类型化空间操作 DAG,每节点是一次 entity loading、attribute filtering、scope constraint、spatial match、aggregation 或 ranking 操作,边是数据依赖;编译器静态检查 DAG 无环、输入引用合法、最终节点对应合法输出。第四步,PostGIS 执行:DAG 按拓扑序执行,产生地图、排名表、可导出 CSV 等结构化结果。整条管线保证同样的语义帧在同样的数据库状态下永远产出同样结果。

技术新颖性

技术新颖性体现在四个层面。第一,将任务型对话系统的语义帧范式创造性地移植到空间分析领域,把分析意图拆解为 primary/support/scope/anchor/filter 五种角色,比传统 NLIDB 的单目标查询更贴近真实安全分析任务(如 ranking 需要 support 实体做度量、scope 实体做地理边界)。第二,提出了 LLM 仅做意图翻译 + 规则层把关 的治理边界,工程上通过封闭 schema + 规则化归一 + DAG 静态校验三层保险实现,区别于代码生成范式的开放性。第三,给出了 80 个查询、9 个能力组合的系统性评测,把修复率 29% 作为 LLM 输出与 schema 要求之间差距的可量化度量。第四,把对公共部门可信 AI 的 NIST AI RMF 框架落地为具体设计选择:reproducibility 由 deterministic execution 保证,auditability 由可检查的语义帧和 DAG 保证。本文是目前少有把领域特定空间 schema + 受控生成 + 规则校验 + DAG 执行 + 公共部门治理五件事同时做齐的工作。

System workflow from NL query to validated semantic frame, structured execution, and interactive output.
Figure 1: System workflow from NL query to validated semantic frame, structured execution, and interactive output.
Validation and repair example showing normalization of NL values into execution-ready representations.
Figure 2: Validation and repair example showing normalization of NL values into execution-ready representations.
Compiled execution DAG for the query 'show crashes within 500m of all schools in Quincy.'
Figure 3: Compiled execution DAG for the query 'show crashes within 500m of all schools in Quincy.'

实验结果

在马萨诸塞州交通安全数据库(127,414 条 2025 年事故记录、504,905 条道路、2,448 所学校、17,933 个公交站、102,971 个斑马线、333 个城镇)上的评测显示:80 个查询全部成功执行并匹配 ground truth,但 23 个 (29%) 需要 Validation & Repair Layer 修正才进入执行阶段。修复构成上,22/25 是值归一化(最常见的是把 pedestrian、cyclist、bike 等口语表达映射到规范值),其余 3 个是结构性修正。执行时间方面,整体平均 18.6 秒、最长 178.8 秒;LLM 解释阶段固定 2 至 3 秒/查询。G7 城镇 ranking 平均 61.7 秒、最长 178.8 秒;G8 路段 ranking 平均 40.0 秒、最长 142.2 秒。作者把案例分析拆成局部层(单一学校/公交站邻近诊断)和决策层(跨设施/走廊/辖区比较筛选),并把 ranking 指标定义为按用户约束下的事故计数,允许机构替换为加权严重度或自定义评分框架。

Supported entity types and key fields.
Table 1: Supported entity types and key fields.
Evaluation results and execution times by query group.
Table 2: Evaluation results and execution times by query group.
System output for the query 'show sidewalk conditions within 1km of Amherst Regional High School'.
Figure 4: System output for the query 'show sidewalk conditions within 1km of Amherst Regional High School'.
System output for the query 'top 20 road segments with no sidewalks on both sides and the most pedestrian crashes'.
Figure 5: System output for the query 'top 20 road segments with no sidewalks on both sides and the most pedestrian crashes'.
查看结构化数据
任务指标本文基线提升
9 组分析能力的端到端执行成功率(共 80 查询) 执行成功率 + 语义帧与 ground truth 匹配率 80/80 = 100% 成功执行;语义帧 100% 匹配 ground truth(在 Validation & Repair Layer 修正后) 无明确 baseline;作者选择直接报告 ground truth 匹配而非 LLM raw 输出的 F1 等指标 作者指出 29% (23/80) 的查询必须经规则层修正才进入执行,强调开放 NL 到严格 schema 的鸿沟需要可量化的修复率来刻画
LLM 原始输出 → 校验后语义帧的修复率 Repair Rate (%) $23/80 = 28.75\%$ 整体修复率;分布为 $G1=0/6, G2=0/8, G3=3/12, G4=1/7, G5=3/5, G6=2/10, G7=2/8, G8=3/8, G9=9/16$ 无对照组;这是该工作特有的诊断性指标 组合查询(G9)修复率 56% 远高于单一能力查询,说明 schema-grounded 系统在多约束叠加时尤其需要规则层托底
端到端查询延迟 平均 / 最大执行时间(秒) 整体平均 $18.6\,s$,最大 $178.8\,s$;LLM 解释阶段固定 $2 \sim 3\,s$,其余为 PostGIS 计算 无对照组;作者声明该耗时与等价 GIS 工作流一致 G7 城镇 ranking 61.7 s、G8 路段 ranking 40.0 s 成为耗时瓶颈,作者将其归因于空间 join 与聚合本身
值归一化能力(22/25 个修复) 代表性归一映射覆盖度 覆盖 first harmful event、crash severity、distance、time-of-day、ranking order 等关键字段;典型映射如 cyclists → Collision with cyclist、injury → Non-fatal injury、1km → 1000 m、half a mile → 804 m、between 4pm and 8pm → [960, 1200] 分钟、most → highest 无对照组 作者把这一覆盖率本身视作 schema 与领域表达对齐的工程度量

局限与改进

作者在 Section 5.2 (Table 3) 与 Section 5.3 明示的限制主要有六项。第一,语义帧对用户意图的失真:如果查询本身存在歧义(如最危险在不同语境下意义不同),LLM 给出貌似合理但错误的解析时,规则层只能修值与结构,无法识别意图错位。第二,reproducibility 仅在当前 schema 与数据库快照下成立。第三,语义帧与 DAG 的真正审查仍要求一定的技术熟悉度。第四,架构无法阻止用户对输出的过度依赖。第五,降低技术门槛并不解决数据本身的覆盖偏差。第六,公平性问题不能靠一致性执行解决——ranking 城镇或地点依赖于 schema 是否纳入相关公平性变量。从第三方视角还可补两点:(a) 评测仅在马萨诸塞州一个数据库上完成,外推到其他州或领域时数据规模、字段命名差异可能放大修复率;(b) 评测没有跨 LLM 版本的鲁棒性比较。

独立分析的弱点

独立分析可以指出四个可改进的弱点,每点给出改进方向。第一,Validation & Repair Layer 目前以规则为主(hardcoded 映射表、字符串匹配),扩展 schema 时需要人工逐条新增归一规则,跨语言支持也会失效;改进方向是引入检索增强的归一器。第二,ranking 指标默认使用 crash_count,没有暴露严重度加权、暴露量调整(VMT 或行人流量)、人口归一等机构常用的优先级评分;扩展方向是允许机构把自家评分系统封装为可插拔的 metric 节点。第三,框架目前不支持多轮对话、约束迭代、查询变体比较,与实际规划工作流脱节;改进方向是引入会话状态 + 澄清子对话 + 对比查询能力。第四,29% 的修复率仅报告整体数字,没有给出 LLM 原始输出的字段级错误率与归因细分;改进方向是发布 LLM raw output vs repaired frame 的字段级 diff。

未来方向

作者在 Section 5.3 给出四条未来方向:(1) 扩展分析词汇——加入速率/暴露调整指标、严重度加权 ranking、网络可达性度量、灵活的时间聚合;(2) 引入更多数据层——行人流量、土地利用、人口脆弱性指数,让分析更具公平敏感性;(3) 把框架适配到具体规划流程——SRTS 筛查、HSIP 网络分析、公交可达性评估、走廊优先级排序,针对性定制 system prompt 与输出格式;(4) 跨州/跨 schema 部署——研究 schema 自适应的自动化程度与领域专家参与的边界。基于这些方向还可延伸几条:(a) 引入多模态查询,允许用户上传照片/草图作为地理锚点;(b) 把 NL summary 升级为基于反事实的解释(如把缓冲距离改成 1km,则前 5 名学校变化为 X),帮助决策者做敏感性分析;(c) 把系统接入 LLM agent 的工具调用协议(Function Calling / MCP),让 LLM 能调用校验+执行闭环而非一次性 JSON 输出,方便长链路规划任务的工具化集成。

复现评估

复现评估整体处于中等偏上水平。优点:(1) 论文给出了完整的语义帧 schema、六类实体及其字段、值归一映射示例、80 条评测查询及分组,足以让读者重建评测;(2) 数据规模与执行时间公开,便于估算算力——PostGIS 实例需要能处理 127K crashes + 505K roads 的空间 join 与排名聚合;(3) LLM 选型明示(Gemini 2.5 Flash 与 GPT-4o 任选)。不足:(a) 论文没有开源代码或语义帧 schema 的机器可读定义,仅在 Appendix A 给出单个示例帧,第三方实现需要从论文文本逆向工程;(b) Prompt 文本、校验规则集、PostGIS 具体函数与索引方案未公开;(c) 评测只跑了 80 条查询且没有跨 LLM 版本或跨州的对照实验,外部效度有限。综合难度评级为中等:熟悉 PostGIS + LLM API 的领域工程师可以在 2 至 4 周内复现核心管线并跑通评测。