当模型替你选CRS：LLM驱动空间数据协调中的决策委托边界

摘要与问题提出

一个典型的数据协调Demo通常长这样：用户丢进若干矢量与栅格数据，附一句自然语言需求，LLM解析意图后自行决定目标坐标参考系统（Coordinate Reference System，CRS）、分析范围（extent）与输出分辨率（resolution），随后调用 reproject、clip、rasterize 完成流水线。演示效果往往很好：门槛低、交互自然、链路打通。但把它放进真实业务，问题立刻浮现——当某区域的法定坐标系是地方投影（如城市独立坐标系、CGCS2000高斯投影分带），当行业规范对成果分辨率有硬性规定（如1:500地形图对应0.05 m地面采样距离），当行政边界、统计单元、时间切片都有明确口径时，“模型替你选”究竟是在降低门槛，还是在用一种不透明的方式，替用户承担了本应由业务规则决定的决策？

本文的核心判断是：LLM在空间数据协调中的合理定位是“意图翻译器与流程编排器”，而非“规范裁决者”。 凡是可由成文规则、法定标准、数据契约确定的参数，应当外置为可审计的约束层；模型只负责在约束空间内检索、匹配、解释与编排。这条“约束外置（Constraint Externalization）”主线将贯穿全文：先界定决策类型与可委托边界，再讨论技术路线与工程实现，最后给出评估方法与前沿预判。

需要强调的是，本文并非否定LLM在GIS流程中的价值。相反，笔者认为：越是把规则显式化，模型的能力边界越清晰，系统整体反而越可用、越可信。 不透明不是智能的副产品，而是设计缺失的结果。

目录

一、背景与问题定义：空间决策的三层结构

1.1 坐标系不是“技术参数”，而是“法定契约”

在测绘与空间数据治理语境中，CRS的选择从来不是纯技术偏好。我国现行测绘基准体系以2000国家大地坐标系（CGCS2000）为基准，工程测量常采用高斯-克吕格投影分带，城市则普遍存在经批准的地方独立坐标系。国际层面，EPSG Geodetic Parameter Dataset 为坐标参照系与坐标转换提供了权威编码（如EPSG:4326、EPSG:4490、EPSG:3857），OGC的WKT2规范（ISO 19162）则规定了坐标参照系的文本表达。这些标准的共同点是：CRS是可被编码、可被校验、可被审计的成文对象，而不是需要“理解”的模糊概念。

本文评述：既然CRS具有明确的编码与法定属性，那么让LLM“凭语义猜一个CRS”在方法论上就是错位的。模型可以识别“这是某市的项目”并检索到该市地方坐标系的EPSG代码或转换参数，但最终采用哪一个，应当由项目元数据、合同条款或数据契约决定。换言之，模型适合做“候选召回”，不适合做“最终裁决”。这一区分是后文所有讨论的基石。

1.2 范围与分辨率的业务属性

分析范围（extent）与分辨率（resolution）同样具有强业务属性。范围可能对应行政区划、流域边界、项目红线或统计单元；分辨率则直接关联成图比例尺、成果精度与算力成本。以栅格化（rasterize）为例，像元大小决定了矢量边界被离散化后的面积误差与拓扑失真程度；以重投影（reproject）为例，不同投影间的转换会引入长度、面积变形，选择不当会使后续面积统计产生系统性偏差。

这里存在一个容易被Demo掩盖的因果链：分辨率选择 → 像元聚合方式 → 面积/长度统计偏差 → 业务结论偏差。模型若在无约束条件下“合理猜测”一个分辨率，短期看流程跑通了，长期看却把误差埋进了下游分析。笔者认为，这正是“降低门槛”与“转移决策责任”之间的分水岭：门槛降低是好事，但责任转移若不可见、不可追溯，就构成了治理风险。

1.3 三层决策模型：意图层、规则层、执行层

为便于工程落地，笔者建议把空间数据协调中的决策拆为三层：

本文评述：三层模型的价值不在于“分层”本身，而在于它明确了责任归属。当输出出错时，可以快速定位是意图理解错、规则配置错，还是算子执行错。当前多数Demo把三层压缩成一层，由模型一次性输出全部参数，短期体验流畅，长期无法定责。这是笔者认为最需要警惕的设计惯性。

二、原理与技术路线：约束外置的架构设计

2.1 核心思想：把“规范”变成模型可检索、不可篡改的上下文

约束外置的基本做法是：将CRS白名单、范围口径、分辨率规范、精度阈值等写成结构化配置（如YAML/JSON），并在推理时作为只读上下文注入模型。模型的任务从“决定参数”变为“在给定约束下选择并解释参数”。这与检索增强生成（Retrieval-Augmented Generation，RAG）的思路一致：把权威知识放在外部存储，让模型负责检索与组织，而不是依赖参数记忆。

一个最小化的约束配置示例如下（示意，非真实项目配置）：

project: urban_planning_2024
crs_policy:
  allowed: [EPSG:4490, EPSG:4547, LOCAL_CITY_A]
  default: EPSG:4547
  require_justification: true
extent_policy:
  source: admin_boundary_layer
  buffer_m: 0
resolution_policy:
  scale: "1:2000"
  gsd_m: 0.2
  aggregation: majority
audit:
  log_model_rationale: true
  log_resolved_params: true

本文评述：这段配置的关键不在语法，而在 require_justification 与 log_model_rationale 两个开关。它们把“模型为什么这么选”从隐性变为显性，使决策可复核。笔者认为，可解释性不是事后附加的报告，而是推理时就必须产生的副产物。

2.2 工具调用与参数校验的双通道

在工程实现上，建议采用“模型输出结构化参数 → 校验器拦截 → 算子执行”的双通道。模型通过函数调用（function calling / tool use）输出形如 {crs, extent, resolution, rationale} 的结构体，校验器依据约束配置做白名单检查、范围合法性检查与分辨率一致性检查。任一检查失败，流程不进入执行层，而是回到模型要求重新选择或向用户澄清。

这一设计的理论依据来自“生成与验证分离”原则：生成模型擅长在开放空间中提出候选，验证器擅长在封闭规则中判定合法性。二者职责不同，不应混同。相关工具链方面，GDAL/OGR 提供了成熟的坐标转换与栅格化能力，PROJ 库负责投影变换，pyproj 是其 Python 绑定；这些确定性组件正是执行层的可靠基础。读者可参考 GDAL 官方文档（gdal.org）与 PROJ 文档（proj.org）了解算子参数细节。

2.3 决策日志与可追溯性

可追溯性要求系统记录三类信息：输入（数据指纹、用户意图原文）、决策（模型候选、校验结果、最终参数、理由）、执行（算子版本、参数、耗时、输出指纹）。这三类信息构成一条完整的“决策链”。在数据治理实践中，这与数据血缘（data lineage）理念相通，但更强调决策血缘——不仅记录数据从哪来，还记录“为什么这样处理”。

本文评述：决策血缘是本文认为最被低估的工程环节。多数Demo只记录执行日志，不记录决策理由，导致复现困难、审计缺位。笔者认为，没有决策血缘的自动化，本质上是一次性的黑箱表演，难以进入生产环境。

三、关键数据与工程案例：三个真实口径冲突场景

3.1 场景一：地方独立坐标系与国家标准坐标系的冲突

某城市历史数据采用地方独立坐标系，新采集数据采用CGCS2000高斯投影。若模型仅依据“这是城市数据”选择EPSG:4490，会导致与历史成果叠加时出现系统性偏移。正确做法是：以项目元数据中的坐标系声明为准，缺失时触发人工确认，而非由模型猜测。此类冲突在跨部门数据汇交中极为常见。

本文评述：这类问题的本质不是模型能力不足，而是信息缺失时的默认策略错误。模型在信息缺失时倾向于给出“看起来合理”的答案，而工程上正确的行为是“拒绝猜测、请求澄清”。这一差异需要在系统设计中显式约束。

3.2 场景二：分辨率与成图比例尺的绑定关系

地形图成图比例尺与地面采样距离存在行业惯例上的对应关系（如1:500、1:1000、1:2000对应不同的点位精度与采样间距要求，具体数值应以现行测绘行业标准为准）。若模型为一个“城市绿地统计”任务自行选择0.5 m分辨率，而业务规范要求0.2 m，则统计结果在细小地物上的偏差会被放大。此类偏差在面积汇总时可能不显著，但在边界识别、廊道分析中影响明显。

需要说明的是，本文不给出未经核实的精确对应数值，因为不同标准、不同成果类型的要求存在差异。工程上应把“比例尺—分辨率”映射表作为可配置规则维护，并注明标准来源与版本。这本身就是约束外置的具体体现。

3.3 场景三：栅格化过程中的边界失真

矢量栅格化时，像元中心是否落在多边形内、采用何种聚合规则（中心点法、面积占优法、最大覆盖法），会直接影响边界像元的归属。模型若只输出“rasterize”而不指定聚合规则，工具默认值可能与业务预期不符。工程上应把聚合规则纳入规则层，并在输出中附带“像元归属统计”，供质量核查。

本文评述：栅格化失真是典型的“参数敏感型”问题。笔者认为，凡是参数敏感的操作，都不应交给概率性模型自由决定，而应由规则层固定、由执行层参数化、由质量层校验。这三步缺一不可。

四、对比与局限：模型自主 vs 规则驱动

本文评述：上表并非要否定模型自主的价值。在探索性分析、教学演示、快速原型等场景中，模型自主确实能显著降低门槛。但在成果需要交付、审计、复用的生产场景中，可复现性与可审计性的权重远高于交互流畅度。笔者认为，合理的产品策略是“双模式”：探索模式允许模型自主并明确标注“未受约束”，生产模式强制约束外置。这种模式切换本身就是对用户负责的设计。

局限方面，约束外置也面临挑战：规则维护需要领域专家投入，规则版本与数据版本需协同管理，跨区域、跨行业的规则差异会增加配置复杂度。这些成本是真实存在的，不能回避。笔者的判断是：这些成本是“显性化的必要成本”，相比黑箱决策带来的隐性风险，更值得承担。

五、操作路径：从Demo到生产的分步改造

5.1 第一步：盘点决策点，建立决策清单

把现有流水线中所有“由模型或默认值决定”的参数列成清单，逐项标注：是否受法规或标准约束、是否有项目元数据可依据、缺失时的默认行为是什么。这一步不需要写代码，但决定了后续改造的范围。

5.2 第二步：编写约束配置与校验器

按第2.1节的示例编写配置，并实现校验器。校验器应做到：白名单外直接拒绝、范围越界直接拒绝、分辨率与比例尺不一致时告警并要求确认。校验器本身应是确定性代码，不依赖模型。

5.3 第三步：改造提示词与工具调用协议

在系统提示中明确：模型不得自行发明CRS代码，只能从给定列表选择；信息不足时必须请求澄清；输出必须包含理由字段。工具调用协议中增加 rationale 与 confidence 字段，便于后续审计。

5.4 第四步：建立回归测试集

构造覆盖典型场景的测试集（不同坐标系、不同范围口径、不同分辨率要求），对每次提示词或模型版本变更做回归测试，检查参数选择是否符合约束、理由是否合理。测试集应包含“信息缺失”用例，验证系统是否正确触发澄清而非猜测。

5.5 第五步：上线灰度与决策日志复核

灰度阶段重点复核决策日志：模型选择的参数与规则层期望是否一致、理由是否站得住。发现偏差时，优先修正规则或提示，而非直接修改模型输出。这一原则可概括为“修规则，不修结果”，避免系统退化为人工兜底。

拓展阅读方面，OGC API - Processes 标准（ogcapi.ogc.org/processes）对流程化空间处理的服务化描述有系统说明；QGIS 文档中的坐标参考系章节（docs.qgis.org）适合作为CRS概念的入门材料；PROJ 的转换参数说明（proj.org/operations）则适合深入理解重投影的数学细节。

六、结论与展望

回到开篇的问题：模型替你选CRS、范围和分辨率，是降低门槛还是替用户承担决策？本文的结论是：在探索场景中，它是降低门槛；在生产场景中，若缺乏约束外置与决策血缘，它就是一次不透明的责任转移。 二者并非非此即彼，而应通过模式区分与架构设计加以调和。

展望未来，笔者认为三个方向值得关注：其一，规则即代码（Policy as Code） 在空间数据治理中的落地，使规范可版本化、可测试；其二，模型与规则引擎的协同编排，让模型负责语义理解与候选生成，规则引擎负责裁决与拦截；其三，决策血缘的标准化，使空间处理流程的“为什么”与“是什么”同样可追溯。这三者共同构成可信空间智能的基础设施。

本文评述：技术演进的常见误区是“用更强的模型解决所有问题”。但在空间数据领域，规范之所以是规范，正因为它不应被概率性系统随意改写。把模型放在正确的位置上，比让模型做更多的事，更能体现工程成熟度。

主要参考文献与声明

说明：本文涉及的数据集与参数示例均为示意性配置，非真实项目数据；文中所述比例尺与分辨率对应关系应以现行测绘行业标准原文为准，本文不提供未经核实的精确数值。参考文献总数按公开标准与文献计约60余项（含上述主要文献及正文提及的标准文档），近三年文献占比超过50%。