企业官网建设流程全解析

前段时间在一个地图相关项目里，遇到一个很典型的“听起来简单、做起来麻烦”的任务：给定一批无人机影像和公开影像，需要把范围内的所有建筑轮廓提取出来，最终交付成可编辑的矢量图层。

最开始走的是人工勾绘路线。一个熟练的人一天能勾几十栋到一两百栋，速度取决于建筑密度和影像清晰度。按这个速度，一个几千栋建筑的片区要画好几周，而且人的疲劳期会直接影响边界精度。于是项目负责人提出新方案：用深度学习模型自动提取，人工只做校对。

问题随即来了：用哪套模型？

云端接口开箱即用，但建筑轮廓提取通常涉及区域数据，很多团队在数据出域和成本控制上都有顾虑。更现实的问题是，通用模型在别的区域测得很好，换到你这片区域，屋顶材质、建筑密度、阴影角度全变了，输出经常需要大幅度修图，甚至比人工还慢。

所以我们会把目光转向本地模型——把开源权重下载到自己的服务器或工作站上，在本地完成推理，必要时还在本地数据上做微调。这几年可选方案越来越多，但“可选范围大”也意味着“鱼龙混杂”。论坛里有人推 U-Net，有人推 Mask R-CNN，有人说提示式基础模型才是未来。如果不在自己的数据和交付要求上做一轮真实对比，根本分不清谁在说自家方案，谁在说通用经验。

下面就把围绕“本地模型对比”的完整思路拆开讲。直接说核心判断：

本地模型对比，最有价值的产出不是找到“分数最高的模型”，而是找到“在你自己的数据、标注、后处理和交付格式下，能稳定跑成闭环的模型”。

分数是手段，闭环才是目的。

1. 建筑轮廓提取，不是“一张图进、一个面出”

很多人在第一次接触建筑提取时，会误以为它像一个分类器：输入一张图，输出每个建筑的位置和轮廓。真实流程远没有这么简单。

1.1 真正的输出链路

一个常规的本地提取流程，大致是这样：

1. 获取影像：卫星影像、无人机影像或航拍正射影像，通常是大范围高分辨率数据。
2. 预处理：重投影、色彩校正、统一坐标系，有时还要把大影像切块。
3. 模型推理：对每个瓦片做像素级分割或实例分割，得到“哪个像素属于建筑”的概率图。
4. 后处理：对概率图做阈值化、去除小噪点、填补孔洞，得到干净的二值掩膜。
5. 矢量化：把二值掩膜转换成多边形，导出成 GeoJSON、Shapefile 或直接入库。
6. 质量检查：和底图或人工抽查对比，检查漏检、错检和边界偏差。

这个链路里，模型只是其中一个环节。如果最终交付物是矢量多边形，那么第 4 到 6 步的工作量，往往比模型推理还要大。

1.2 为什么“只看模型分数”会误导你

只盯着模型输出的掩膜分数，可能会得出“这个模型不错”的结论。但放到最终交付上，问题就变了：

• 掩膜里细碎的小洞，在后处理时会变成多边形上的锯齿或空洞。
• 相邻建筑在像素上粘连，矢量化后就变成一个包含多栋建筑的大多边形，必须再拆分。
• 模型概率阈值设高一点，漏检增多；设低一点，噪点铺满整个图幅。

所以，对比两个模型时，真正应该比较的是两个模型从同一份输入到同一类交付物的完整链路表现。只比较模型本身，等于只比较了发动机，却没有比较整辆车能不能把货物送到目的地。

2. 本地模型值得认真对待，但理由不在“省钱”

不少文章推荐本地模型，第一句话就是“节省 API 调用费用”。这话没错，但只抓住了表面。对做建筑提取的人来说，本地模型的真正价值在另外三件事。

2.1 云端接口和本地模型的真实差距

先说数据控制。建筑轮廓提取往往会用到不适合随意上传的影像数据，包括特定区域的测绘成果、项目保密数据，或者只是客户明确要求“不出内网”。这种情况下，本地模型不是“可选优化项”，而是“唯一可行项”。

再说迭代速度。云端接口通常只给你固定权重，不支持在自己数据上微调。就算供应商提供微调接口，一次训练也要排队、等待和计费。本地模型不同：可以反复调整训练集、清洗标签、重训、对比不同后处理参数，整个迭代周期能压缩到几十分钟甚至十几分钟以内。对做算法选型的人来说，这种“试错密度”太重要了。

最后是可控性。模型的权重、推理代码、预处理和后处理逻辑都在自己手里。模型出问题时，可以从输入、参数、依赖版本逐层排查；云端接口往往只给一个报错编号，有时候等半天才发现是供应商端出了问题。

2.2 什么样的项目更适合本地跑

当然，本地模型不是银弹，它有非常明确的使用边界：

• 适合本地模型的场景：数据敏感或不能出域；建筑风格有较大区域特殊性，需要微调；团队有 GPU 资源和基本工程能力；项目周期长，需要反复迭代和维护。
• 不适合本地模型的场景：业务量很小、偶发需求，不值得为此维护一套环境；没有本地 GPU，又不愿意折腾云主机；对结果精度要求很高但团队没有算法经验，这时先用云端接口验证可行性也许更实际。

如果只是“试试看”，完全可以先用公开权重在小块影像上跑一遍，体会完整链路。等确认这条路值得走，再投入时间去管理数据、微调和工程化。

3. 先分清你要对比的模型属于哪一类

做对比前，先把候选模型分好类，否则容易拿不同维度的东西硬比。常见的建筑提取模型大致有三类。

3.1 三类常见模型范式

这里要留意一个坑：语义分割和实例分割的“单位”不一样。语义分割输出的是像素类别，相邻建筑在像素上可能连成一片；实例分割输出的是“这是第 1 栋、这是第 2 栋”，天然带实例编号。但实例分割模型通常更重，训练和推理成本更高，对小型独立房屋场景反而可能过度设计。

提示式分割更特殊。它在高质量标注和编辑场景里很实用，比如先用一个分割模型得到粗糙结果，再用提示式模型修正边界。但如果希望完全无人干预地自动跑全图，把它当成主力模型往往不现实——它依赖提示输入，而提示本身又需要人来判断。

3.2 模型名字不是胜负手，数据和配方才是

还有一个更重要的问题：在本地模型对比中，模型名字远没有“训练数据和训练配方”重要。

同一个 U-Net，在公开数据集上预训练，和在你本地精标数据上微调过的版本，效果可能是两个量级。数据标注质量、样本数量、影像分辨率、类不平衡处理、损失函数选择，这些因素加起来的影响，常常远超“换一个更好的骨架”。

所以对比时尽量保证控制变量：要么都使用相同的数据集和训练设置，只比较网络结构差异；要么都加载同一个预训练权重，只比较推理和后处理差异。不要把“换了模型”和“换了数据”混在一起，否则根本不知道赢在哪里、输在哪里。

4. 一个可复现的对比流程：五步固定法

如果不做控制变量，对比就只是感觉。下面给出一个我常用的对比流程，适合在本地环境落地，按这个顺序做一轮，结果会清楚很多。

4.1 固定数据：空间划分比随机划分更可靠

先把数据集切成固定瓦片，比如 512×512 或 256×256。切瓦片时要注意重叠率，重叠不仅影响拼接质量，也会影响训练时的数据分布。

划分训练集和测试集时，有一个地理数据特有的坑：不能随机像素级或随机瓦片级划分。因为同一片区域内的建筑具有很强的空间相关性，相邻瓦片本质上非常相似，如果把相邻瓦片分别分到训练集和测试集，测试分数会被严重高估。

更稳妥的做法是按空间区域划分：把整个研究区分成几个互不相邻的子区域，用其中 A、B、C 区训练，D 区测试。这样至少能在一定程度上模拟“模型去一片新地方”的泛化能力。

4.2 固定指标：不能只看像素重叠率

建筑提取最常用的指标是 IoU（交并比），也就是“预测掩膜和真实掩膜的重叠面积 / 两者并集面积”。但实际使用中不能只看这一个数，因为建筑提取的最终形态是矢量多边形，人对结果的关注点往往由多个维度构成。

我一般会同时看四类指标：

要说明的是：这些指标都有各自的问题，没有一个是“万能 KPI”。IoU 高不代表边界干净；Precision 高也可能意味着漏检更严重。所以对比时把它们全部记录，再看哪个维度对你的项目最重要。

4.3 固定后处理和交付格式

这一步经常被忽略。两个模型，哪怕掩膜输出不完全一样，只要后处理逻辑固定，最终交付物的差距也完全可能被缩小或放大。

所以对比时，我建议把后处理当作标准流程固定下来：统一使用同一个阈值、同一个去噪核大小、同一套多边形简化参数，让所有模型都经过完全相同的后处理链路。这样做之后，才能说“差异来自模型本身”。

注意：后处理参数在真正交付前应该固定成配置文件，而不是散落在脚本里。这样每次对比的结论才可复现。

如果条件允许，更推荐把最终交付格式也纳入对比：统一导出为 GeoJSON，对比每个模型最终产生的多边形数量、面积误差、拓扑错误率。这会直接反映到甲方能不能用，而不只是学术指标。

4.4 固定硬件与推理配置

最后，如果关心推理速度，就要固定硬件和推理配置：同一张 GPU，同一批次大小，同一裁剪尺寸，同一混合精度设置。否则，一个模型比另一个“快”，很可能只是因为前一个用了更激进的推理配置。

推理速度最好记录两个数：单图延迟（单张瓦片耗时）和吞吐量（每秒能处理的瓦片数）。建筑提取经常要跑整片区域，吞吐量往往比单图延迟更重要。

5. 本地运行阶段最容易翻车的工程细节

这一节说说真正跑起来之后的问题。很多人在模型对比阶段一切顺利，一到全量和交付就翻车。翻车点基本集中在下面几个地方。

5.1 大影像的切片推理与拼接

如果输入是一整幅几百兆甚至几个 G 的影像，直接丢给模型是不现实的。常规做法是切瓦片后逐张推理，再用重叠拼接的方式把结果缝回去。

切瓦片时要注意：

• 瓦片大小要和模型输入尺寸匹配，不能太大，否则需要全局池化或裁剪，影响边缘。
• 相邻瓦片之间留一定重叠区域，比如 10% 到 20%。这样边缘预测质量会好很多。
• 拼接时对重叠区域做加权平均，比如距离瓦片中心越近权重越高，能有效减少“沿瓦片边界出现接缝”的问题。

在代码层面，常见写法是一个循环把所有瓦片跑完，再把掩膜写回整张大数组里：

# 伪代码：大影像切片推理 for row_start in range(0, rows - tile_size, stride): for col_start in range(0, cols - tile_size, stride): tile = image[row_start:row_start + tile_size, col_start:col_start + tile_size] prob = model_infer(tile) # 模型推理 accumulate_into(mask, prob, row_start, col_start)

切片重叠率建议从 10% 到 20% 起步。重叠太少，接缝处会出现明显的预测断层；重叠太多，推理时间会成倍上升。

实际项目里建议把重叠和拼接封装成独立模块，避免在实验代码里反复复制逻辑。

5.2 从掩膜到矢量多边形

模型输出是概率图，而交付物往往是多边形。这一步的常见处理流程是：

1. 将概率图按阈值二值化，得到“疑似建筑”的像素区域。
2. 用形态学开运算去除小噪点，用闭运算填补内部小孔。
3. 找出连通域，每个连通域对应一个建筑候选。
4. 用简化算法把像素边界转成顶点更少的矢量轮廓。
5. 必要时做直角化、面积过滤（比如去掉面积小于某个阈值的碎块）。
6. 导出为 GeoJSON 或 Shapefile，并确认坐标系一致。

常见写法类似：

# 伪代码：掩膜转多边形 mask = prob > threshold # 二值化 mask = morphology.open(mask, kernel) # 去噪 polygons = find_contours(mask) # 找轮廓 simplified = [simplify(p, tol) for p in polygons]

需要注意，矢量化后往往会出现两类问题：一是多边形之间重叠或留有缝隙，二是相邻建筑仍粘连在一起。前者需要做拓扑清理，后者需要做实例分离。这也是为什么“像素指标不错”和“交付物能用”之间经常差着一个后处理环节。

5.3 一个按层排查的清单

如果本地跑出来的结果很差，不要急着换模型或者狂调参数。按下面的顺序逐层排查：

1. 先看输入：影像是不是加载正确，波段顺序、分辨率、坐标系有没有问题，瓦片是不是切错了。
2. 再看标注：训练标签质量如何，有没有漏标、错标、边界粗糙。
3. 再看模型输出：概率图是否合理，是整体偏移，还是只有高亮区域有响应。
4. 再看后处理：阈值、去噪核、简化参数是否适配当前数据。
5. 再看交付格式：导出坐标、拓扑关系、属性字段是否完整。
6. 最后才怀疑模型结构：确定前五层都正常后，再考虑是不是模型能力不足或训练不充分。

这个顺序的特点是“先底层后上层”，每一步都可以用可视化确认。如果一上来就换模型，很可能问题其实出在标注或者后处理上。

6. 我的选型建议：从最小闭环开始

如果你还没有确定方案，我的建议不是去网上找“哪个模型最强”，而是先搭一个最小闭环，然后在这个闭环上做增量。

6.1 三档起点对应三类场景

不管你选哪一档，都建议先在一个小面积测试区跑通端到端流程。测试区不用大，几十栋建筑、一张瓦片就够。先确认模型能跑、掩膜能存、后处理能导出、地理坐标对齐，再扩大范围。

单次跑通只说明流程没有断，不代表它能处理全部数据，更不代表批量任务稳定。

6.2 长期使用还缺哪些工程能力

如果要在连续多个项目或长期生产中使用本地模型，除了模型本身，还缺这几块工程能力：

1. 数据版本管理：影像和标注文件往往会不断更新，靠文件名管理会越来越乱。至少要建立一套固定目录结构和命名规范。
2. 实验记录：每次训练或推理，记录数据范围、瓦片大小、模型结构、损失函数、后处理参数和指标结果。否则三个星期后很难复现上一次的“好结果”。
3. 模型与脚本打包：把模型权重、推理代码、依赖版本一起打包，最好能一键复现。不要只在某个环境的 Python 脚本里能跑。
4. 批量任务可靠性：批量化之前，先设计好失败重试、日志输出和输出目录校验。一个瓦片报错不应该导致整个批次重来。
5. 质量抽检机制：选定若干个固定位置的抽查区域，每次跑完都要检查。模型升级、参数调整之后，能快速发现“是不是比之前好了”。

这些能力看上去不如“选一个更先进模型”吸引人，但长期使用体验的差距，基本都体现在这里。

再说回“本地模型对比”这件事。如果要用一句话总结，那就是：

本地模型对比的本质，不是评委打分，而是给自己选一套能持续迭代的流水线。

输赢当然要看，但要把输赢放在自己的数据、自己的指标、自己的交付物这个坐标系里看。离开这个坐标系，任何一个模型在别人的论文里胜利，都和你没有关系。

如果现在要动手，我的建议是：先选一个小测试区，用最简单的那档模型把“影像 → 瓦片 → 推理 → 掩膜 → 矢量 → 导出”完整跑通，然后在这个闭环上做指标记录和模型对比。跑通一次，比看十个模型对比表格都有用。