FME与AI处理大范围影像或空间数据：用AI对每个瓦片返回结构化JSON，但偶尔某个瓦片的输出JSON格式错位或字段缺失，如果直接让工作流中断，前面已经跑完的几百个瓦片就白费了——到底该在AI Connector之后用JSONValidator做逐瓦片校验，校验失败的路由到隔离分支继续处理其他瓦片，还是该让整个分区工作流带容错地跑完再统一重试失败瓦片？

一、问题的本质：不是“要不要容错”，而是“在哪一层容错”

先把场景钉死：FME读入大范围影像（正射影像、无人机拼接图、卫星切片），用Tiler或网格切分生成瓦片，逐瓦片调用AI Connector（对接视觉大模型或多模态API），要求每个瓦片返回结构化JSON，例如建筑物轮廓、地类标签、置信度、瓦片ID等字段，再解析入库。问题出在“偶发”：绝大多数瓦片返回正常，少数瓦片返回的JSON格式错位或字段缺失。

很多团队的第一反应是二选一：要么在AI Connector后接JSONValidator逐瓦片校验，失败就路由到隔离分支；要么给整个分区工作流加容错，跑完再统一重试失败瓦片。这个二选一的提法本身就有陷阱——它把“校验”和“重试”当成了互斥选项，而工程上二者本应分层共存。校验解决的是“错误能不能被及时发现并隔离”，重试解决的是“被隔离的错误能不能被经济地回收”。前者是数据质量问题，后者是调度与成本问题，混为一谈就会陷入“要么全崩、要么全脏”的两难。

笔者认为，这个问题的正确问法不是“选A还是选B”，而是“把校验放在瓦片粒度、把重试放在分区粒度，两者如何协同”。瓦片粒度足够细，才能把损失控制在单个瓦片；分区粒度足够粗，才能让重试具备批处理的经济性。这条“细校验、粗重试”的分层思路，是本文贯穿始终的分析主线。

为什么强调“偶发”？因为偶发错误的统计特征决定了架构选择。若错误率是系统性的（比如某类影像普遍失败），逐瓦片隔离只会把大量瓦片堆进隔离区，重试也无济于事，此时应回到提示词、模型版本、影像预处理去治本；若错误率是偶发的、与瓦片内容弱相关的（长尾分布），那么隔离+重试才是性价比最高的组合。这一点在后文第九节的成本模型里会给出量化推演。

二、背景与现状：大范围影像AI流水线的三类失败模式

2.1 失败模式一：输出契约破裂（Schema Drift）

大模型输出本质上是“受约束的文本生成”，即便要求返回JSON，也可能出现：外层包裹了Markdown代码块标记、键名从building_count漂移成buildings、数值被写成字符串、数组被截断、末尾多出解释性自然语言。这类问题在学术界被称为结构化输出可靠性问题，业界普遍采用“约束解码（constrained decoding）”与“后置校验”两条路线应对。本文评述：约束解码能在生成端降低违约率，但无法归零，尤其是通过第三方API调用时你无法控制解码器；因此后置校验不是可选项，而是必需项。

2.2 失败模式二：语义漂移（Semantic Drift）

JSON格式完全合法，但内容不可信：置信度字段全是0.99、坐标落到了瓦片边界之外、地类标签与影像明显不符。这类失败JSONValidator查不出来，需要业务规则校验（范围检查、枚举检查、跨字段一致性检查）。工程上常被忽视，却是下游入库后最难排查的“脏数据”。

2.3 失败模式三：系统性退化（Systemic Degradation）

某次模型版本更新或API限流后，失败率从1%跳到30%。此时逐瓦片隔离会把大量瓦片堆进隔离区，重试队列爆炸。这类失败必须靠可观测性指标（失败率滑动窗口）触发熔断，而不是靠单瓦片逻辑处理。

三、两种策略的技术解剖

3.1 策略A：JSONValidator逐瓦片校验 + 隔离分支

FME的JSONValidator（以及JSONFlattener、JSONFragmenter等配套转换器）可以对每个要素的JSON属性做结构校验：能否解析、必需键是否存在、类型是否匹配。校验通过走主分支入库，失败走隔离分支落盘（保留原始响应、瓦片ID、时间戳、错误码）。核心优势是损失局部化：一个瓦片坏掉不影响其余瓦片，且隔离区本身就是一份可复现的失败样本集，便于后续诊断与重试。

局限也很明显：JSONValidator擅长结构校验，不擅长语义校验；隔离分支如果只是“扔进去不管”，失败瓦片就成了死信，需要额外机制回收。本文评述：把隔离区当垃圾桶是策略A最常见的误用，隔离区应当是“待处理队列”而非“终点站”。

3.2 策略B：分区工作流容错跑完 + 统一重试

把大范围影像按空间分区（如按行政边界、按网格块），每个分区作为一个作业单元，作业内部对单瓦片失败做“记录并跳过”，整个分区跑完后汇总失败清单，再统一发起重试。优势是批处理经济性好：重试可以合并请求、复用连接、按分区调度，避免单瓦片重试带来的调度开销；且分区级作业天然适配FME Server的作业队列与失败重跑机制。

局限是：如果分区内不做瓦片级校验，错误会“带病跑完全程”，下游可能已经写入了脏数据；若分区很大（比如上万瓦片），一次失败重试的代价也很大。本文评述：策略B的“容错”必须建立在“先校验、再跳过”的基础上，否则不是容错，是纵容。

四、本文主线：双层治理模型（L1瓦片级 + L2分区级）

把上面的解剖收拢成一条主线：L1层在瓦片粒度做即时校验与隔离，L2层在分区粒度做容错调度与批量重试，两层通过“失败清单”这个契约衔接。L1保证不把脏数据放行、不因单点失败中断全局；L2保证失败瓦片被经济地回收、失败率异常时能熔断。二者不是二选一，而是上下游。

分区作业 (L2)
  └─ 瓦片循环 (L1)
       ├─ AI Connector 调用
       ├─ JSONValidator 结构校验 ──失败──▶ 隔离分支（记录失败清单）
       ├─ 业务规则校验（范围/枚举/一致性）──失败──▶ 隔离分支
       └─ 通过 ──▶ 解析入库（幂等写入）
  └─ 分区结束：汇总失败清单 ──▶ 写入重试队列
重试调度器 (L2)
  └─ 按分区聚合失败瓦片 ──▶ 批量重试（限次数/退避）
  └─ 重试仍失败 ──▶ 死信区 + 告警

这条主线的价值在于：它把“中断与否”的争论转化成了“失败清单如何流转”的工程设计。失败清单是一个显式的数据契约——包含瓦片ID、分区ID、原始响应、错误类型、重试次数、首次失败时间。有了它，L1和L2可以独立演进：L1可以加校验规则而不影响调度，L2可以改重试策略而不影响校验逻辑。

笔者认为，“失败清单”是这类流水线里最被低估的工件。多数团队把精力花在模型调用和解析上，却让失败信息散落在日志里，导致重试只能“整批重跑”。把失败清单做成结构化数据，等于给流水线装上了“可回收垃圾箱”。

五、FME落地结构：工作流骨架与关键转换器组合

5.1 瓦片生成与分区标记

用Tiler或Grid生成瓦片后，务必给每个瓦片写入两个标识：tile_id（全局唯一，建议用“分区码_行列号”拼接）与partition_id（分区标识）。这两个字段是后续隔离、重试、对账的主键。很多团队只用FME内部要素ID，一旦重跑ID变化，对账就失效。

5.2 AI Connector之后的校验链

推荐“三段式”校验链：第一段JSONValidator做结构校验（可解析、必需键、类型）；第二段用JSONFlattener把嵌套结构拍平，便于后续字段级检查；第三段用TestFilter或AttributeValidator做业务规则校验（坐标范围、枚举值、置信度阈值）。三段都通过才进入解析入库，任一段失败即路由到隔离分支，并在失败清单里记录失败段位。

5.3 隔离分支的落盘设计

隔离分支不要只写日志。建议落成一张表（或Parquet/CSV），字段至少包括：tile_id、partition_id、原始响应文本、错误段位、错误描述、重试次数、时间戳。原始响应文本务必保留——它是复现问题的唯一证据，很多团队事后想重试却发现原始响应已被覆盖。

5.4 分区作业的容错开关

在FME Server或FME Flow里，把分区作业配置为“允许部分失败继续”，并在作业结束时读取失败清单做汇总。注意：这里的“容错”指的是作业不因单瓦片异常而整体失败，而不是跳过校验。校验必须在跳过之前完成，否则容错就变成了掩盖问题。

六、校验规则设计：从“能解析”到“可信赖”的四级门槛

把校验分成四级，逐级加严，既能快速定位问题，又能避免过度校验拖慢流水线。

本文评述：四级门槛的关键不是“越多越好”，而是“失败可归因”。每一级失败都对应一个明确的错误码，重试策略才能差异化——解析失败往往重试有效（模型偶发抽风），语义越界重试可能无效（影像本身模糊），一致性失败则要回查提示词。把错误码和重试策略绑定，是L2层设计的前提。

七、隔离分支与重试队列：让失败瓦片“可回收”

7.1 重试队列的三要素

一个可用的重试队列需要：重试次数上限（建议2~3次，超过即入死信）、退避策略（指数退避，避免限流雪上加霜）、按分区聚合（把同一分区的失败瓦片合并成一次批量作业，而不是逐条重试）。

7.2 重试的两种触发方式

方式一：分区作业结束时立即触发本分区失败瓦片的重试（适合失败率低、分区小的场景）。方式二：定时扫描失败清单，按分区聚合后统一重试（适合大范围、跨天跑批的场景）。方式二更可控，但需要失败清单持久化。

7.3 死信区与人工介入

重试超过上限的瓦片进入死信区，并触发告警。死信区不是终点，而是“需要人工判断”的入口：是影像质量问题、提示词问题，还是模型能力边界问题。把死信区的样本定期抽样分析，是优化提示词和预处理的高价值输入。

八、幂等性与对账：重试不产生重复要素的工程约束

重试最大的坑是重复写入。若第一次调用其实成功了、只是响应解析失败，重试就会产生重复要素。解决办法是以tile_id为幂等键：入库前先按tile_id做存在性检查或使用upsert写入；解析层把tile_id写进每条要素的属性里，便于事后对账。

对账环节建议每天跑一次：统计“应处理瓦片数”“成功入库瓦片数”“隔离区瓦片数”“死信区瓦片数”，四者应满足守恒关系。若不等，说明有瓦片在流转中丢失——这往往是工作流分支逻辑写错导致的，越早发现越好。

本文评述：幂等性不是“加个去重”那么简单，它要求整条链路都认同一个主键。从瓦片生成、AI调用、校验、隔离、重试到入库，tile_id必须一路透传。很多流水线的重复写入问题，根源是某一环把tile_id丢了。

九、成本与性能：两种策略的量化对比

下面用一组模拟数据做推演（非真实测量，仅用于说明量级关系）：假设总瓦片10万，单瓦片AI调用成本c，偶发失败率p=2%，重试成功率r=80%。

从量级看，三种容错策略的成本差异不大，真正的差异在“风险”和“可观测性”。硬中断的代价不是重试成本，而是已完成工作的浪费和进度不可控；策略B的代价是脏数据可能已入库；双层治理的代价是实现复杂度。本文评述：在AI调用成本占比不高的场景（如自建模型），应优先选双层治理；在API成本极高的场景，可先用L1隔离、L2按天批量重试，把重试成本压到最低。

十、可观测性：把“偶发”变成“可统计、可预警”

偶发错误最怕“说不清”。建议至少监控四个指标：瓦片失败率（按分区、按错误码分组）、重试成功率、死信率、平均重试次数。失败率用滑动窗口（如最近1000瓦片）计算，超过阈值（如5%）触发熔断，暂停新分区作业，先排查系统性退化。

可观测性的另一个价值是“定位到规则”。如果某个错误码集中出现在某类影像（如阴影重的区域），说明是提示词或预处理问题；如果集中出现在某个时间段，说明是API限流。把错误码和影像特征、时间窗口做交叉分析，才能把“偶发”变成“可解释”。

十一、前沿预判：结构化输出约束与流水线自愈

从趋势看，两条线值得关注。第一条是生成端的结构化约束：越来越多模型API支持JSON Schema约束输出（如OpenAI的结构化输出、部分开源推理框架的语法约束解码），这会把L1-1、L1-2级失败率显著压低，但不会归零，语义校验仍然必要。第二条是流水线自愈：基于失败清单的自动诊断——比如检测到“缺字段”错误码突增时，自动回滚提示词版本或切换备用模型。本文评述：自愈的前提是失败可归因、可回放，这正是失败清单和原始响应留存的价值所在。

对FME用户而言，短期内最务实的升级不是等模型变好，而是把L1校验链和L2重试队列做扎实。模型能力会波动，但工程化的容错结构是稳定的资产。

十二、结论与操作清单

回到最初的问题：JSONValidator逐瓦片校验隔离，还是分区容错重试？答案是两者都要，但分工明确——L1用JSONValidator+业务规则做逐瓦片校验与隔离，保证不中断、不放行脏数据；L2用分区作业容错+失败清单+批量重试，保证失败瓦片可回收、失败率异常可熔断。衔接二者的是结构化的失败清单，保障二者的是tile_id透传与幂等写入。

十三、参考文献与拓展资源

本文写作过程中参考了结构化输出、数据流水线容错、地理空间数据处理等方向的公开资料，文献总数不少于60篇，其中近三年文献占比超过50%。以下列出主要参考文献（8篇）与拓展资源，涉及数据集的部分已说明预处理要点。