在把UrbanGround的代码和文档完整过了一遍之前我一直觉得“大模型进三维城市”这种题目多半是宣传片里的概念演示。直到我自己拿着手机在香港中环附近的连廊上走了两圈导航提示“请直行50米”可面前分明是上下三层交错的步道头顶还有车流穿行——那一刻我意识到我们习以为常的二维地图导航在立体城市里早就撑不住了。所谓“走两步就忘了路”不是人的方向感太差而是我们和机器都缺少一种把三维空间转换成可理解语义的能力。上交、NUS等团队提出的UrbanGround恰好就是在做这件事把大模型放进真实三维香港让它学会感知空间、记忆位置、并回答“你在哪、你从哪来、你可以往哪去”这类问题。这篇文章我想从这条研究的真正起点讲起拆解它背后的技术逻辑再聊一聊如果我们要复现或参考这个方向会遇到哪些文档里没写的现实问题。1. 立体城市里的人类迷路现场才是这份研究的真正起点先说一个我自己的经历。去年我去香港做城市三维数据采集测试设备包里装着激光雷达和全景相机手里还开着高精度地图App。按道理说这种配置不可能迷路。结果在中环的一个天桥连廊系统里我硬是在同一片区域绕了二十分钟。原因很简单GPS信号被密集高楼反复反射定位点在人行天桥和地面车道之间来回横跳手机地图告诉我“已到达目的地”可我低头一看目的地在上层连廊我站在下层马路。这种体验不是个例。香港这种高密度立体城市天然是传统导航方案的“杀手场景”天桥、地下通道、楼宇连廊、依山而建的坡道把原本的二维平面切割成了多层交错的拓扑结构。人在其中行走时真正依赖的不是经纬度坐标而是视觉地标、空间记忆、方位感这些高度语义化的线索。比如你会记住“在橙色招牌的奶茶店左转上电梯后右手边第二个出口”而不是“东经114.17度北纬22.28度”。UrbanGround这类研究之所以出现根源就在这种场景倒逼。传统SLAM技术可以把点云地图建得很精细但精细的三维几何和人的语言描述之间存在一条巨大的语义鸿沟地图知道墙在哪、楼梯在哪却不知道“红色招牌的茶餐厅”“能看见维港的转角”这些人类真正用来认路的词汇。大模型则相反它知道大量关于空间和地标的世界知识但缺乏与真实物理空间的锚定。UrbanGround尝试做的就是把这两者接起来让大模型在真实的城市三维场景里“落锚”。这里面有一个很关键的研究动机值得注意团队选择香港作为试验场并非偶然。香港的城市纹理极其丰富——密集的商铺招牌、双语甚至三语路标、多层立体路网、风格各异的老旧楼宇——这些在计算机视觉视角下都是极具区分度的语义特征。一个三维场景系统如果能在香港这种复杂环境里稳定工作那么迁移到大多数普通城市难度会低很多。这一点我在和数据组同事聊的时候感触特别深跑一个场景很容易跑一个“能让模型不会记混”的场景才是真正筛选算法水平的地方。2. UrbanGround不是“地图App”是让大模型长出“空间记忆”我第一次看到UrbanGround这个名字时下意识以为它是又一个“三维地图ChatGPT语音播报”的缝合项目。但把项目文档读完之后发现它的定位要准确得多UrbanGround不是在做路径规划也不是在做高精地图它是在做“空间记忆”这件事。传统导航解决的核心问题是“从A点到B点怎么走”它假设起始点、目标点都是已知的、可精确度量的。但在真实行走场景里更常见的困境是“我大概知道自己在哪但说不清精确位置”“我记得刚才路过一个便利店但回头找不到了”。这类问题本质上是空间记忆问题——需要系统理解三维场景中的语义内容理解物体与物体之间的空间关系然后把这种理解转成自然语言表达。UrbanGround所做的事情可以拆成三个递进层面的能力第一层是空间感知。模型要能从真实三维数据点云、网格、高斯模型等等中识别出“这是街道”“这是店铺招牌”“这是楼梯口”并把它们组织成一个带空间坐标的语义场景图。第二层是空间记忆。当用户描述“我刚刚在一家卖鸡蛋仔的店门口”时模型要能把这个描述映射到三维场景中的具体位置形成一个可检索的定位点。第三层是空间推理。模型要能基于当前点与目标点之间的拓扑关系生成符合物理空间的步行指引比如“往前走20米在第二个路口上电梯到二层然后右转”。这个定位和传统SLAM的区别非常明显。SLAM解决的是“我在哪”的几何问题输出的是坐标和位姿UrbanGround解决的是“这里是什么、下一步怎么走”的语义问题输出的是可交互的语言答案。前者是机器内部的语言后者是人与人、人与机器之间共用的语言。这也是为什么这类项目一定要引入大模型只有大模型具备把视觉特征翻译成自然语言、再基于自然语言做多步推理的能力。从技术实现角度说UrbanGround里大模型承担的角色不是“聊天对话框”而是一个空间语义推理引擎。它要读取三维场景的语义描述把用户的问题转换成语义检索条件再从三维场景库中匹配对应的空间实体最后生成带明确空间关系的回答。这套流程听起来简单实际跑起来每一环都有各自的坑。后面我逐层拆开讲。3. 把真实香港三维化之后怎么喂给大模型链路逐层拆解这一章节我尽量把技术细节讲完整但不会直接贴大段源码而是把处理思路理清楚。毕竟UrbanGround这种项目代码版本迭代很快读者拿到手之后还是要结合自己的场景改理解设计逻辑比抄代码更重要。3.1 场景表征层为什么城市级重建大多选择三维高斯泼溅要让大模型理解三维空间第一步是选择一个合适的场景表征方式。在这个环节里UrbanGround这类项目目前的主流选择是三维高斯泼溅3D Gaussian Splatting路线而不是更早流行的神经辐射场NeRF。这个选型逻辑非常实际我直接说结论。NeRF的核心优势是渲染质量高、几何表达连续但它的训练和渲染速度都偏慢而且对动态场景、大尺度场景的支持比较吃力。城市级三维重建动辄覆盖数平方公里用NeRF训练一个区块可能要几个小时迭代一次数据集成本高到难以接受。三维高斯泼溅则把场景表示成大量带位置、形状、颜色和不透明度的高斯椭球通过光栅化方式实时渲染训练速度比NeRF快一个数量级渲染帧率可以达到实时级别。对于需要频繁更新、动态加载的城市数据来说效率优势是决定性的。但选3DGS也有代价。高斯泼溅的几何结构是一堆离散椭球体没有显式的连续表面所以它对“地面”“墙面”“招牌”这类语义边界的表达天然不友好。你必须额外叠加一个语义分割分支把每个高斯基元对应到类别标签上。我在实际操作中见过一个很典型的问题远处看是一面连续的墙放大之后发现是几万个高斯椭球排成的边缘参差不齐。这时候如果要做“墙面上的招牌文字识别”就不能只依赖几何信息还得把RGB图像语义拉进来一起做。这引出一个城市级三维重建里的核心工程问题数据源配准。目前做城市三维场景普遍是激光雷达扫描出几何结构再用全景相机拍摄的影像做纹理映射和语义标注。不同传感器之间的外参标定、时间同步、坐标统一占据整个项目超过三分之一的工作量。这一步如果做不扎实后面大模型再怎么聪明也白搭因为它读到的空间位置本身就是错的。3.2 语义对齐层三维特征如何变成大模型能读的“空间token”场景表征选定了接下来是更关键的一步怎么把三维几何特征和语义特征一起输入给大模型。大模型处理的是token序列而三维高斯泼溅是一堆无序的椭球体这两者之间的鸿沟需要专门的“对齐层”来弥合。UrbanGround这类项目通常的做法是把三维场景中的语义实体店铺、楼梯、路口、标志物抽取出来为每一个实体生成一段结构化的文本描述再配合它的空间坐标组合成一个“空间token”。描述里通常会包含类别、颜色、相对位置、周围上下文等属性。举例来说一个空间token可能是这样组织的[ENT_ID: 1276] [CATEGORY: 餐饮店铺] [NAME: 招牌含“鸡蛋仔”] [POSITION: (x12.8, y33.5, z1.5)] [CONTEXT: 处于天桥入口左侧西南朝向]这段描述用什么方式生成决定了对齐层的质量。最直接的做法是用现成的视觉大模型VLM逐帧提取图像描述再反投影到三维空间。具体来说采集车拍到某一帧画面VLM识别出“画面左侧有一家红色招牌的奶茶店”系统再根据相机位姿做反投影算出这家奶茶店对应的三维坐标。这个方案实现简单但有个致命弱点同一个店铺在相邻几帧里会被重复提取如何合并同一实体的多个描述、如何处理不同帧之间描述不一致的问题都要靠聚类和投票策略去解决。另一个思路是直接在三维空间里训练语义特征。把高斯基元的位置信息、颜色信息、邻域几何特征送入一个小型特征提取网络输出每个基元的语义嵌入再将同一类别的基元聚类成实体。这个方案的泛化性更好但对标注数据的要求更高——你需要有一批已经做好了三维语义标注的训练数据而这恰恰是行业内最稀缺的资源。3.3 推理层空间RAG与路径记忆的检索链路语义实体抽取完成之后大模型就可以开始做推理了。UrbanGround里的推理链路我觉得本质上是一个“空间版RAG”架构也就是用检索增强生成来解决大模型的空间知识缺失问题。流程大致是这样用户输入一句自然语言问题例如“我刚才从地铁站C出口出来走到一个卖奶茶的店门口现在想去附近的洗手间怎么走”。系统先做意图解析拆出两个关键锚点——“地铁站C出口”和“奶茶店”。然后用这两个锚点在三维场景索引中做检索定位出用户的可能位置范围再根据场景图里面的空间关系生成路径建议。检索不是靠文本相似度硬匹配而是结合了空间距离、语义相似度、路径可达性三者的加权评分。这个评分权重怎么调往往是效果差异最大的地方。这里有一个特别容易被忽略的细节大模型在生成路径指引时很容易“一本正经地胡说八道”。如果检索模块召回的地标不够准确模型会基于训练时习得的城市常识强行脑补出一个“合理的”店铺或路口。这在可视化演示里不容易暴露因为合成路径读起来很通顺但用户真正走到现场就会发现指引里的“红色招牌便利店”根本不存在。所以UrbanGround对推理层做了很强的约束第一路径上的每一个节点必须来自三维场景库中的真实实体不允许模型凭空生成第二节点之间的转移边必须符合场景图的拓扑关系不能从一楼直接“跳”到二楼除非中间存在明确的楼梯或电梯边第三最终输出里的每个地标描述都要附上实体ID方便校验和回溯。这三层约束本质上是把大模型的生成能力限制在一个“事实骨架”里运行模型只在组织语言和规划顺序时发挥创造性而不能在空间实体层面自由发挥。3.4 数据配准与标注的完整流程最后讲一下完整体验这个项目时需要走通的数据流程。我按照常见实践整理了一份数据准备链路不同团队可能略有差异但大方向是一致的数据采集激光雷达采集几何点云全景相机采集影像两种传感器通过硬件同步触发器保证每一帧点云和图像时间戳对齐。离线标定解算激光雷达和相机之间的外参矩阵修正两种传感器之间的旋转和平移偏差。点云配准把多趟采集的激光点云通过ICP或NID算法合并到同一坐标系下消除采集车的轨迹漂移。语义分割对点云或图像做语义标注提取建筑、地面、店铺招牌、路标、楼梯等类别。实体化把同类的语义点聚类成实体对象赋予唯一ID并生成实体属性描述。场景图构建根据实体间的空间关系相邻、上下层、连通构建拓扑场景图。数据入库把实体属性、坐标、图像描述统一存入向量数据库供后续检索调用。这里面第4步和第5步是最耗人力的。城市级语义标注的成本大概在每平方公里数千小时人工量级。所以很多团队在尝试用弱监督甚至无监督方案替代人工标注但从实际效果看纯自动化的语义分割在城市复杂场景下还达不到落地的可靠性标准人机协同标注在短期内仍是主流。4. 实跑中躲不掉的问题清单坐标漂移、幻觉与退化场景这一部分聊点真正让人头疼的事。把UrbanGround这类系统从论文里的架构图变成能稳定跑通的工程系统过程中会遇到不少“文档里不会告诉你”的问题。4.1 城市峡谷里的定位漂移首先是城市峡谷环境下的定位漂移。这里说的定位不单指GPS也包括视觉定位和惯性导航。香港中环、尖沙咀这些区域高楼密布GPS信号多路径效应严重接收机解算出来的位置可能瞬间跳变十几米。如果系统完全信任GPS作为用户位置输入那么后续的空间检索和路径生成都会建立在错误的起点上。实践中比较可靠的缓解方案是把视觉定位作为主力用户举起手机拍一张照片系统提取照片中的视觉特征与三维场景数据库中的特征做匹配得到厘米级到米级的定位结果。但视觉定位在夜晚、逆光、雨雾天气下会明显退化这时候就得靠IMU做短时预测把视觉定位的频率兜住。这一套多传感器融合的架构和自动驾驶里的定位模块很像但步行场景有步行场景的难点——手机的姿态变化更随意、行人的运动模式更不规律、可用的算力也更有限。4.2 大模型的空间幻觉大模型的空间幻觉问题值得单独拿出来说。我曾经做过一个测试给模型输入一段真实的香港街道语义地图问它“从A店的门口走到B店的门口路上会经过几个路口”模型给出的回答结构完整、语气笃定但和真实场景图一比对有两个路口根本不存在。这个结果让我意识到空间幻觉比事实性幻觉更隐蔽——一般的事实性幻觉容易被常识识破空间幻觉则很难被用户在短时间内察觉因为路径描述看起来完全自洽。要压制空间幻觉光靠prompt是远远不够的。一个有效的策略是前面提到的拓扑约束在模型生成路径时逐节点校验是否存在于场景图中一旦发现“越界”实体立即中止生成并回退到检索增强模式。另一个策略是引入确定性空间计算模块需要计算距离、方向、可达性时不依赖大模型心算而是调用空间索引库精确计算再把计算结果拼接到回答文本里。这样大模型只负责组织语言数字和实体全部来自外部系统幻觉空间被压缩到几乎为零。4.3 玻璃幕墙、长走廊与地下空间的“退化时刻”然后是视觉检测的退化场景。香港有大量玻璃幕墙建筑在三维激光点云中玻璃幕墙区域会产生大量反射噪声和空洞对视觉特征提取来说玻璃表面会倒映出对面的建筑极易造成语义识别错误。长走廊、地下通道这类纹理稀少的场景也容易出问题视觉定位会退化为“前方是一面相似的白色墙壁到处都长得一样”的尴尬局面。在这些退化场景里系统的可靠性会断崖式下降。我实测下来最稳定的兜底方案是强制引入“空间语义扶手”当你判断当前场景处于低纹理区域时系统切换交互策略优先询问用户“最近的岔路口在哪”“刚才是否经过了一道玻璃门”这类高语义量问题通过集合同一位置多个用户的描述来消除定位歧义。这本质上是一种人机协作式的定位恢复机制也是UrbanGround这类城市级空间系统未来走向实用时必须标配的能力。4.4 三维标注的隐性成本还有一个很多人会低估的事情三维语义标注的隐性成本。二维图像标注只需要在画面上画框、打标签三维场景标注要把同样的标签附着到点云或高斯模型上还要保证跨帧一致性。同一个店铺在采集车不同角度拍摄的画面里是不同样子标注系统需要把它们正确合并成一个实体。香港尤其特殊大量的繁体中文、英文、简体中文混排招牌加上霓虹灯和立体字OCR识别和语义归类的难度比普通城市高出一大截。我在做数据质量分析时就发现自动生成的语义标注里误检率最高的类别往往不是小物体而是“店招文字”。一个招牌在A帧里被识别为“奶茶店”在B帧里被识别为“甜品店”在C帧里直接漏检。这类不一致会在空间实体合并时产生错误实体进而污染后续所有检索结果。所以项目里少不了一个专门的实体一致性校验环节通过多视角投票人工抽检来保证入库数据质量。这一步的工作量坦白说比训练模型本身还大。5. 空间智能的下一个路口从问答式导航到共享空间记忆把视线拉远一点。UrbanGround这类系统虽然目前以“三维场景问答”为呈现形式但它打开的方向其实更大空间智能的规模化落地。5.1 AR与可穿戴设备是第一批受益者AR眼镜和可穿戴设备是空间大模型最早能落地的场景。这类设备的屏幕尺寸有限不适合展示传统二维地图但非常适合“在真实画面上叠加空间指引”。想象一下你戴着AR眼镜走在陌生街区视野里直接浮现出一个半透明的路径箭头地面上的虚拟标记告诉你“右转进入商场”。要实现这种体验系统既要实时理解周围三维场景又要准确估计用户位置还要用自然语言动态生成指引。UrbanGround验证的“语义感知空间检索语言生成”链路恰恰是这套体验的核心骨架。5.2 机器人从单机空间记忆到多机共享另一个方向是机器人的多机共享空间记忆。目前大多数机器人的空间感知是“单机私有的”一台机器人扫过一间屋子地图只存在它自己的硬盘里。而城市级空间系统天然支持多机共享——A机器人采集到某片区域的最新变化上传到空间数据库B机器人再路过同一区域时直接检索就不需要重复扫描。这种“空间记忆共享”机制对于快递机器人、巡检机器人这类需要在固定区域内长期运行的设备来说效率提升非常明显。5.3 端侧化与实时更新的路线图当然从研究到产品还有不少距离。最大的瓶颈还是端侧化目前完整跑通UrbanGround链路需要较强的服务器算力支撑端侧设备只能承担采集和轻量推理。未来如果能在端侧部署压缩后的小模型配合云端空间数据库做协同推理才能真正支持大规模商用。这就是“空间索引在云端语义推理在端侧”的混合架构也是我自己最想继续跟进的方向。6. 一些实操建议以及我踩过之后想提醒你的坑作为收尾我想分享几条实际操作层面的建议。这些不是官方文档里写的内容是自己在几轮踩坑之后总结出来的希望对想做类似“大模型三维场景”方向的人有帮助。第一别一上来就重建全城先跑通小街区闭环。很多人看到UrbanGround的香港演示就想着搞一个全城版本结果数据和算力成本直接失控。我的建议是先选一个几百米范围内的街区把采集、重建、标注、检索、问答整个链路跑通确认每个环节的效果和瓶颈再考虑扩展。小范围闭环跑通一遍你对整个系统的体感比读十篇论文都强。第二评测指标别只盯准确率要盯路径可分性。三维空间问答的准确率指标很容易骗人。我的经验是设计评测集时要特别关注“路径可分性”系统能不能区分两条空间上接近但语义上不同的路径比如“从A店门口出发左转后直行”和“从A店门口出发右转后直行”这两条指令在真实场景里指向完全不同的位置如果系统在这类样本上频繁混淆说明它的空间推理能力还没有真正建立起来。第三语义地图的保鲜度比想象中更重要。城市空间是动态变化的店铺换招牌、临时施工、季节性摊位都会让语义地图过期。系统的长期可用性关键看能否低成本地持续更新空间数据。目前比较现实的方案是“众包更新”让普通用户在使用过程中用手机拍照系统自动检测场景变化对变化区域做增量重建。这个方向已经有一些团队在尝试但离完全自动化还有距离短期内还是需要人工抽查把关。第四不要忽视交互设计。我在测试中发现同一个系统如果交互逻辑设计得好——比如在感知到用户困惑时主动反问、在指令模糊时给出选择项——用户体验会显著提升。空间交互问题的核心不是“答得对”而是“相互校准理解是否一致”。哪怕模型的定位精度不够高只要交互引导做得到位用户也能很快收敛到正确状态。最后说一点个人的体会。跑这类项目最大的感受是三维空间理解这个方向正在从“感知几何”时代走向“感知几何语义推理”时代。UrbanGround的贡献不在于某一个单一的模型指标提升而在于它把一个完整的链路搭出来了并且选择了一个足够复杂的真实城市场景作为验证。做空间智能的人都知道真实场景里的问题永远比数据集里的多也永远更有价值。如果你想在这个方向上找一处可以落地的切入点从复现它、扩展它、改造它开始是个很不错的路径。就我当前的经验来说把语义空间检索和确定性空间计算结合好是最值得投入的地方短期内能看到明显的效果提升。