CityJSON 等语义三维城市模型保存了建筑几何、层级和属性，却往往只能由熟悉专用格式的人查询。自然语言接口能降低门槛，但如果系统只返回一句答案，规划人员无法确认它查了哪些对象、是否跨库拼接正确、图上高亮是否与文本相符。CityLLM 的研究把空间库、图数据库和可视化检查组合起来，为三维城市 GIS 的对话式访问提供了可验证的思路。
可核查事实
CityLLM: A framework for natural-language querying of semantic 3D city models 于 2026 年 7 月 16 日提交 arXiv，并注明已被第 21 届 International 3D GeoInfo Conference 接收、将发表于 ISPRS Annals。论文目标是让非专业用户可用自然语言查询语义三维城市模型及补充城市数据。
框架将空间数据库与图数据库纳入 LLM 工作流，支持迭代查询改写与跨数据库链式查询。这里的关键不是让模型“知道”城市，而是让它生成和修正可执行的查询，再由受控数据库返回对象、关系和几何。
作者在鹿特丹 CityJSON 数据集上评估，数据含 853 座 LoD2 建筑。LoD2 的适用范围是该测试数据的建筑层次，不代表所有三维模型或其他城市都具备相同完整度、语义字段和几何质量。
实验使用 GPT-OSS、Gemini 3.1、GPT-5.4 及部分变体，考察答案正确性、可视化正确性、查询成功率和重试次数。评估集有 54 条自然语言查询，覆盖空间、图关系、跨数据库和多轮对话 4 类场景。
论文报告答案正确性为 85.2%—100%，可视化正确性为 92.9%—100%，全部 54 条查询的执行成功率为 100%，每条查询重试少于 3 次。这些范围属于论文的模型、数据、指标和查询集，不能直接作为生产系统的服务等级承诺。
核心机制
可靠的对话式三维查询应产出三份可核对证据：自然语言回答、数据库查询与返回记录、地图或三维视图中的对应几何。空间库解决范围、距离和几何谓词；图数据库解决构件或实体关系；LLM 负责意图解析、链式组织与失败后的改写。只要其中一项不能回读，系统就可能把语言流畅误当作空间正确。
GIS 场景
可用于城市更新前的建筑条件检索、公共设施邻近分析、三维资产巡检和跨部门数据发现。用户问“哪些建筑满足条件”时，结果应显示查询版本、数据快照、坐标参考、空间谓词、对象 ID、属性字段和高亮几何。问答结果应先作为检索和审查入口，不应直接驱动许可、征收、执法或应急调度。
技术路径
- 为 CityJSON、空间库和图数据库建立对象 ID、语义字段、坐标参考与版本映射。
- 将自然语言请求限制为可审计的查询模板；拒绝超出数据覆盖或权限范围的请求。
- 保存每轮提示、生成查询、执行状态、返回行数、重试原因和数据版本。
- 同时验收文本答案、查询结果和三维高亮，按空间、图关系、跨库和多轮场景分别统计。
- 对高影响结论要求人工复核原始属性、几何和最新权威数据，并保存更正记录。
检查清单
- 是否可从回答回读查询、数据版本、对象 ID 和几何。
- 是否同时测试答案与可视化的一致性。
- 是否按空间、关系、跨库和多轮对话分场景评估。
- 是否记录失败、重试和权限拒绝，而非仅统计成功案例。
- 是否明确 LoD、字段完整性、数据日期和权威来源边界。
风险边界
研究只在一个含 853 座 LoD2 建筑的鹿特丹 CityJSON 数据集和 54 条查询上验证。跨城市时，建筑编码、坐标参考、LoD、地下设施和数据许可都会改变结果；LLM 也可能生成看似合理但不正确的查询。所有文本答案和三维高亮都必须以可执行查询和原始城市数据为准，并保留人工复核。
结论
自然语言是三维城市数据的入口，不是证据本身。只有把答案、查询、对象关系和可视化几何一起验收并可回读，城市模型问答才能成为可信的 GIS 工作流。