GFS-VL：融合3D VLM稠密知识与少样本校准的广义点云分割

广义少样本三维点云分割是这几年 3D 视觉里越来越受关注的问题。它要解决的核心矛盾是三维点云的人工标注非常贵一个室内场景逐点标完可能要几十分钟所以模型不能依赖大量标注数据而应该只靠少量支持样本就能认出新类别。GFS-VL 是 CVPR 2025 上提出的一个框架标题里已经把关键思路写得很直白用 3D VLM 的稠密知识做底座再用少样本校准把新类别的边界拉准。这篇文章会把问题定义、方法思路、复现准备、参数评估和常见坑拆开讲重点说清楚适合谁看、怎么落地、以及怎么判断结果真的变好了。适合读这篇文章的人大概有三类正在做点云分割、想接入少样本能力的做 VLM 但主要处理 2D 图像、想往 3D 迁移的以及做工业级点云识别项目标注样本不够但又不想全手工标注的。最值得先关注的不是某个模块有多花哨而是“稠密知识”和“少样本校准”这两个东西怎么配合才不会让基类和新类互相打架。1. 先搞清楚广义少样本三维点云分割到底难在哪1.1 少样本、广义少样本和普通分割的差别普通的三维点云语义分割要求训练集里覆盖所有目标类别而且每个类别的样本量要足够大。模型在训练时见过的类别和推理时要预测的类别是一致的。这种设置对我们做项目的人最熟悉但也是最费标注成本的。少样本分割则换了一种任务划分方式。它把类别分成基类和新类两类。基类有大量训练样本新类只提供很少的标注样本通常 1 个、2 个、4 个或者 8 个。模型要在新类只有这么点标注时学会分割出新类。广义少样本分割更接近真实落地。它在测试的时候不仅要求模型能分割新类还要求模型不能丢掉基类。也就是说同一个场景里可能既有基类物体也有新类物体模型必须同时正确处理。这个问题难在两点一是新类样本少容易过拟合二是基类样本多模型天然偏向基类新类很容易被压制。GFS-VL 标题里拿“广义少样本”当关键词说明它主要针对的就是这种不平衡困境。1.2 为什么 3D VLM 的稠密知识能帮上忙传统少样本点云分割通常依赖骨干网络提取几何特征再用支持样本构造类别原型。问题在于几何特征缺少语义先验。新类只有很少样本时原型估计噪声很大碰到同一类物体外观变化明显就很容易认错。3D VLM 解决的是语义先验问题。它把三维点云特征映射到与文本语义对齐的空间里也就是点云里的每个点都可以计算与文本描述的相似度。这里的稠密知识指的是模型能对每个点或者每个局部区域输出与文本对齐的特征而不是整个场景只出一个全局向量。有了稠密知识模型在没有新类样本的情况下也能通过文本提示认出“椅子”“桌子”“显示器”这类语义。这种零样本能力构成了一个不错的底座。但问题也随之而来文本先验不是精确的。同一个词在不同场景里可能对应不同的几何形态直接拿文本相似度当分割结果边界会很粗糙也不够稳定。这正是 GFS-VL 把“稠密知识”和“少样本校准”放在一起的原因。1.3 GFS-VL 的整体思路从标题描述看GFS-VL 的宏观链路可以拆成两段。第一段是用 3D VLM 提取稠密知识。输入点云之后经过三维骨干网络得到逐点特征再通过投影层把特征对齐到文本语义空间。这样每个点都能得到一组与候选类别文本的相似度分数相当于给每个点一个软语义标签。第二段是少样本精准校准。把支持集中的少量标注样本聚合起来变成每个新类的原型特征再用这些原型去修正或重新加权第一段得到的文本相似度。校准的目的不是推翻 VLM 的先验而是去掉先验里的偏差把新类边界拉准。这两段必须配合好。如果只靠 VLM 稠密知识少样本新类可能能认出来但边界不准如果只靠支持样本原型基类可能崩掉。后面讲的参数调优和坑点基本都是围绕这个配合关系展开的。2. 想复现或落地先准备数据和运行条件2.1 数据集划分基类、新类、support、query要按广义少样本设置来做第一件事是把类别重新划分。常见做法是先选定一个三维点云分割数据集比如 ScanNet、S3DIS 这类室内场景数据集然后按类别名把类别分成互不相交的基类集合和新类集合。划分之后再把数据组织成 episode 形式。每个 episode 包含一个支持集和一个查询集。支持集里每个新类取 K 个带标注的样本K 一般是 1、2、4、8。查询集则是用于评测的场景点云里面同时包含基类和新类。基类的训练数据仍然可以正常参与模型训练新类只能用支持集那少量样本。这里最容易犯的错是数据泄漏。新类样本绝对不能出现在预训练或基类训练阶段否则评测出来的指标没有意义。另外不同类别在场景里出现的面积差异很大像“墙”和“门把手”完全是两个量级。采样时建议按场景均匀采样同时记录每个类别的点在总点中的占比后面分析指标时要用。2.2 运行环境与资源要求论文标题没有给出具体的硬件要求我这里按常见三维分割模型的负载来评估。3D VLM 通常包含一个三维点云骨干网络比如稀疏卷积或基于 Transformer 的编码器外加一个文本编码器。文本编码器一般不会太大真正吃显存的是点云骨干和稠密特征输出。如果只是跑推理一张显存 16G 以上的显卡通常够用具体还要看每帧采样点数。如果要做训练或者完整复现建议优先准备 24G 以上显存的环境比如常见的高端消费级显卡或单卡服务器。显存不足时不要急着换机器先把每帧点数降到 4096 或者 2048把 batch size 降到 2 甚至 1再观察显存占用。软件环境方面主要依赖 PyTorch、三维点云处理库以及可能的第三方稀疏卷积库。不同版本之间兼容性问题比较常见我的建议是先看源码 README 里锁定的版本不要直接装最新版。尤其注意 CUDA 版本和稀疏卷积库的匹配很多启动失败都是这里出的问题。2.3 输入输出格式输入一般分为两部分。点云部分需要包含坐标通常还要包含颜色或法向量因为这些额外特征对 VLM 的语义对齐有帮助。输入格式常见的是每帧一个点云文件点数量可能上万甚至几十万使用前需要采样到固定数量比如 8192 个点。文本部分则是类别名字符串经过模板包装后输入文本编码器。输出是每个点的预测标签。评测时要把预测结果和真实标签对齐逐点计算 IoU。注意点云文件的点顺序必须和标签一一对应读取时如果点位和标签来自不同文件或者经过了随机打乱但没同步预测结果就会错位。这个问题在调试时很容易被忽略我排查过很多次最后发现都是数据对齐的问题。3. 从零跑通一条 GFS-VL 式的完整流程3.1 第一步提取点云特征和 VLM 稠密知识按 GFS-VL 的思路第一步是把点云过一遍三维骨干网络得到逐点特征。这里说的逐点特征不是只指原始坐标而是经过多层聚合之后的高维语义特征。接着需要把逐点特征投影到文本对齐空间。常见做法是在骨干网络后面接一个投影头输出维度要和文本特征维度一致。投影之后每个点会得到一个特征向量这个向量可以和候选类别的文本特征做点积得到语义相似度。这个相似度矩阵就是稠密知识的主要载体。这一步建议用小数据验证不要直接上全量场景。我一般会拿一个场景输出每个点的特征维度确认形状对不对再算一次相似度矩阵看看是否出现 NaN 或者全零。很多问题在特征提取阶段就能暴露出来比到最后评测时再排查高效得多。3.2 第二步构建少样本原型少样本校准的核心是原型。原型的含义是每个新类用支持集里的标注点聚合出一个代表该类别的特征向量。聚合方式可以直接对支持集中该类别的所有点的投影特征求平均也可以用加权平均权重可以跟点与类中心的相似度相关。如果 K 比较大还可以考虑用多个原型避免单一原型被代表性差的点拉偏。这里有一个容易被忽略的细节支持样本里的点很多不是所有点都对该类有相同贡献。支持集中可能有误标注点也可能有点实际上属于其他类别只是在边界附近被标进来了。聚合特征前要么先做一次离群点过滤要么用文本先验给每个点一个权重把置信度低的点压下去。否则一个异常点就能把原型拉偏后面校准怎么调都救不回来。3.3 第三步稠密知识与少样本校准融合获得文本先验相似度和少样本原型之后要把两者融合成最终预测分数。融合方式可以简单也可以复杂。最简单有效的方式是做加权相加再加一个可学习的缩放系数。示意代码如下# 示意代码稠密知识 少样本校准的加权融合 # text_logits: [N, C] 每个点与各类别文本的相似度 # proto_logits: [N, C] 每个点与各类别原型的相似度 # tau: 温度系数控制分数平滑程度 # lam: 校准强度控制少样本原型的占比 text_logits point_feat text_feat.T / tau proto_logits point_feat proto.T / tau logits text_logits lam * proto_logits label logits.argmax(dim-1)lam 是关键超参数。lam 过小少样本校准作用体现不出来新类边界还是会跟着文本先验走lam 过大模型容易被支持集里的噪声带偏基类性能也会明显下降。实际调参时可以先固定 lam0.5跑几个场景看每类 IoU 分布再针对薄弱新类调高针对基类掉点调低。更复杂的做法可以是两层结构第一层先用文本先验筛出每个点的候选类别第二层再用原型在候选类别里精修。这样能减少类别间的干扰但实现复杂度也上来了。第一次复现时我建议先跑通加权融合版本确认整个链路没有 bug再考虑加复杂度。3.4 推理、输出和结果检查推理阶段要把训练好的投影头和校准模块都固定住对查询集里的每个场景逐帧预测。输出结果是一个逐点标签数组保存时要注意点顺序和输入一致。拿到输出后先做三件事。第一统计每个类别的预测点数看看有没有类别被完全忽略。如果有某个新类预测点数几乎为零说明它不是没学会而是根本没被激活问题多半在文本提示或原型构建。第二把预测结果可视化到一个或者两个场景里肉眼看边界是否合理。数值指标可以骗人但可视化通常能暴露真实问题。第三分基类和新类分别计算指标不要只看平均值。4. 关键参数与评估标准怎么判断它真的有效4.1 指标怎么选少样本分割最常用的指标是 mIoU即所有类别 IoU 的平均值。但在广义少样本设置里只看整体 mIoU 很容易掩盖问题。比如基类占大多数场景面积基类效果好整体 mIoU 就好看但新类可能实际一塌糊涂。合理的做法是同时报告三个数base mIoU、novel mIoU、整体 mIoU。如果追求更严格的平衡性还可以看 base 和 novel 的调和平均。调和平均对两端差距敏感比算术平均更能反映“同时做好两类”的能力。指标含义主要关注点mIoU所有类别 IoU 平均值总体水平base mIoU基类平均 IoU会不会遗忘旧类novel mIoU新类平均 IoU少样本泛化能力base/novel 调和平均两类指标的平衡度是否偏科每类 IoU逐类结果定位薄弱类别复现时如果源码只打印了整体 mIoU建议自己加一段逐类统计代码。不要小看这一步它能直接告诉你该去调哪个类别的参数。4.2 核心参数怎么调根据前面拆出的流程GFS-VL 这类框架真正需要关注的参数其实不多但每一个都影响明显。参数常见范围作用K-shot1 / 2 / 4 / 8新类支持样本数决定原型质量tau 温度系数0.01 - 0.1控制相似度分数分布越小越尖锐lam 校准强度0.1 - 1.0控制少样本原型占比每帧采样点数4096 - 8192影响显存、速度和细节文本提示模板固定模板或可学习影响文本先验质量投影特征维度256 - 512影响表示能力和显存先调 K-shot。1-shot 能跑通再逐步涨到 4-shot、8-shot。如果 1-shot 和 8-shot 的结果差距极小说明模型根本没利用上支持样本问题不在样本数量而在原型构建或校准方式。反之如果 8-shot 明显好于 1-shot说明校准模块确实在起作用。温度系数 tau 也要重点看。tau 太大所有类别的相似度都接近软标签没有区分度校准也拉不开差距。tau 太小分数接近 one-hot梯度不平滑训练容易不稳定。一般可以从 0.05 开始试观察每类预测点数的稳定度。4.3 结果怎么看跑完一轮实验不要只看最终指标要看趋势。第一新类 IoU 是否随着支持样本数增加而稳定提升。如果提升曲线乱跳说明支持样本质量不稳定可能需要增加数据预处理或离群点过滤。第二基类 IoU 是否保持在可接受范围。广义少样本的核心要求是“不偏科”新类涨了但基类崩了不算成功。第三可视化里边界是否干净。有时候 IoU 数值过得去但预测结果像噪点一样散布这种模型拿到实际项目里很难用。正确理解应该是稠密知识负责“认得出来”少样本校准负责“边界准确”。如果新类整体识别率低先修稠密知识部分如果识别出来了但边界乱先修校准部分。5. 常见问题和排查链路5.1 新类完全不识别遇到新类预测点数为零不要先怀疑模型容量不够按这个顺序排查。先看文本提示。新类名称是否在候选类别列表里文本模板是否合理。比如类别名是复数还是单数是否带了不必要的上下文词这些都会影响文本特征质量。再看支持集数据。支持集中该新类是否真的存在且标注是否正确标注点数量是否太少。最后看原型特征。打印原型和文本特征的余弦相似度如果原型和所有类别文本都相似说明原型被聚合得太泛化需要加强类别特异性。5.2 基类性能掉太多基类掉点通常有两个原因。一是校准强度太大lam 过高导致文本先验被原型完全压过。可以把 lam 调小或者对基类单独加一个保护权重。二是基类样本没有参与校准只参与了训练推理时基类分数来自文本先验新类分数来自文本先验加原型这两者的分数尺度不一致。解决办法是对所有类别的分数做归一化或者引入类别级别的可学习偏置。5.3 显存不够、训练慢显存不足时第一优先级是降低每帧采样点数。点数直接决定特征矩阵大小从 8192 降到 4096显存占用可能直接减半。第二是减小 batch size哪怕 batch size 为 1 也要能跑。第三是检查是否加载了不必要的组件比如用于提取文本特征的大模型如果只是推理可以先离线把文本特征存下来训练时直接读取避免每次重复计算。训练慢还有一个常见原因点云从硬盘读取和预处理太慢。建议先把数据预处理成内存友好的格式比如统一的 numpy 数组或二进制文件并在数据加载时启用多个 worker。5.4 少样本过拟合和输出噪声少样本设置下最容易出现的就是过拟合。新类只有几个支持样本模型很容易记住这几个样本的特征而不是学到类别的一般规律。判断是否过拟合可以把支持样本复制一份做轻微扰动后再放进原型聚合。如果结果剧烈波动说明原型不稳定过拟合风险很高。缓解手段可以包括在点特征上加 dropout、用更平滑的原型聚合方式、增加文本先验的权重也就是调低 lam。输出噪声具体表现是预测标签在相邻点之间频繁跳变。这类问题一般不是校准模块的问题而是缺少后处理。加入常见的 K 近邻投票或者基于点云边缘的平滑操作通常就能改善不少。6. 落地时的几点建议如果你只是学习复现我建议严格按照论文的公开代码先跑通默认配置然后再做消融。不要一上来就改这个改那个否则你根本分不清问题出在系统模块还是参数上。如果你是做实际项目要注意两个事。第一GFS-VL 这类方法解决的是“标注少”的问题不是“零标注”的问题。支持集的质量直接决定结果上限花时间清洗和校准支持样本比调参数更值得。第二文档里说的“支持”“稠密知识”“校准”这些词都要转化为你能测量的指标。比如稠密知识好不好就看文本先验在新类上的零样本 mIoU校准好不好就看加入原型后新类 mIoU 提升了多少同时基类掉了多少。最后很多问题看起来是模型不够强实际是输入数据不干净、点云和标签没有对齐、文本提示写得不对。我个人习惯是先跑小场景、小样本、小点数的最小链路确认每个模块输出形状和数值范围都正常再逐步放大。这条路虽然笨但踩坑最少。