1. 从切蛋糕说起3D部件分割到底难在哪如果你接触过三维建模、数字孪生或者机器人抓取相关的项目大概率会被同一个问题折磨过拿到一个完整的三维网格模型怎么把它拆成有语义的部件比如一把椅子要自动识别出椅背、坐垫、四条腿一个水杯要分出杯身和把手。这件事在学术上叫3D部件分割听起来很学术但落到实际工程里它就是无数下游任务的地基——不做部件级拆分机器人不知道该抓哪里工业质检不知道缺陷出在哪个结构上AR交互也没法做到点哪拆哪。传统做法大致分两条路。一条是基于几何特征的纯算法路线靠曲率、法线、凹凸性这些低层特征做聚类优点是快缺点是对语义一无所知遇到形状复杂或者部件之间过渡平滑的模型就歇菜。另一条是深度学习路线用点云网络或者网格卷积网络做逐点分类效果比纯几何好很多但问题也很明显每个数据集、每类物体、每种分割粒度往往都要单独训练一个模型。你想让同一个模型既能做整形状拆成部件又能做我点一下杯子把手你把把手单独抠出来还能做我说一句把椅子的靠背分出来模型就照做——这在过去基本意味着三套独立的系统。PartLLM这篇工作想解决的就是这个三合一的问题。它的核心思路非常有意思把3D部件分割这件事统一成一种文本化的输入输出格式。模型不再直接输出每个点的类别标签而是输出一段结构化的文本描述这个形状由哪些部件组成、每个部件叫什么、对应哪些区域。一旦分割变成了文本生成那么形状拆分、交互式分割、文本引导分割这三类任务就都能塞进同一个多模态大模型的框架里用同一套参数、同一个训练流程搞定。这个思路的价值在于它把3D视觉里一个长期碎片化的问题拉回到了当下最成熟的技术范式——多模态大语言模型。下面我会从任务统一、文本化表示、模型架构、训练策略、实测表现和落地注意事项几个角度把这篇工作拆开讲透。不管你是做3D视觉的研究者还是想在自己的三维项目里落地部件分割的工程师都能从中拿到可以直接参考的东西。2. 三类分割任务为什么长期各自为战2.1 全形状拆分一次性把模型拆干净全形状拆分whole-shape decomposition是最经典的任务设定给一个完整的三维形状要求模型输出所有部件的分割结果。这里的难点在于部件数量和部件边界都是不确定的。一把椅子可能有5个部件一张桌子可能只有2个一个复杂的机械零件可能有几十个。传统方法要么预设固定的部件数量要么依赖后处理做聚类前者不灵活后者不稳定。更麻烦的是部件这个概念本身就有歧义。同一个模型按功能分和按几何分结果可能完全不同。比如一个带杯盖的水杯功能上杯盖是一个独立部件几何上它可能和杯身连成一体。这种歧义让全形状拆分任务很难有一个标准答案也导致不同数据集之间的标注体系互不兼容。2.2 交互式分割用户点一下模型抠一块交互式分割interactive segmentation的设定是用户给出一个提示比如在某个位置点一下或者画一个粗略的框模型据此分割出对应的部件。这个任务在2D图像领域已经被SAM这类模型做得很成熟了但搬到3D上难度陡增。原因是3D数据没有2D图像那样规整的像素网格点云是无序的网格的拓扑结构又千变万化用户的一个点击如何映射到三维空间中的语义区域本身就是个难题。而且交互式分割对实时性要求很高。用户点一下等个十几秒才出结果体验就崩了。这就要求模型不能太笨重推理路径不能太长。过去的方法通常要针对交互任务专门设计一个轻量网络和全形状拆分的模型完全分开。2.3 文本引导分割用一句话指定要拆哪里文本引导分割text-guided segmentation是这三类里最新的。用户输入一句自然语言比如把椅子的扶手分出来模型要理解这句话的语义然后在3D形状上定位并分割出对应区域。这个任务同时考验模型的语言理解能力和3D空间感知能力是典型的多模态问题。过去的做法一般是把CLIP这类图文对齐模型迁移到3D上通过对比学习让3D特征和文本特征对齐。但CLIP本身是在2D图像上训练的迁移到3D有天然的鸿沟而且它只能做整形状和文本的匹配做不到精细的部件级定位。所以文本引导分割的效果一直不太理想。三类任务各自有各自的网络结构、训练数据和评测指标工程上要同时支持它们代码量和维护成本都是灾难。PartLLM的出发点就是找到一种统一的表示让这三类任务共享同一套底层能力。3. 把分割变成写作文文本化表示的核心设计3.1 为什么选文本作为统一接口PartLLM最关键的一个决策是把分割结果表示成结构化文本而不是传统的逐点标签或掩码。这个选择乍看有点反直觉——3D分割明明是空间任务为什么要用文本这种一维序列来表示理由其实很扎实。第一文本是天然可变长的。部件数量不确定的问题用文本表示就自然解决了有几个部件就写几段不需要预设数量。第二文本可以承载语义信息。传统标签只能告诉你这是第3类而文本可以直接写这是椅背语义一目了然。第三也是最关键的文本是大语言模型的原生接口。一旦分割变成文本生成就可以直接复用预训练好的多模态大模型不需要从零设计网络结构。打个比方这就像把填表格改成了写描述。填表格要求你事先知道表格有多少行、每行填什么写描述则自由得多你想怎么写就怎么写只要读的人能看懂。PartLLM就是让模型学会用写描述的方式来完成分割。3.2 文本化表示的具体格式那么这段描述具体长什么样根据这类工作的常见设计通常会包含几个要素部件名称、部件的空间位置描述、以及部件对应的点或区域索引。一个典型的输出可能长这样部件1: 椅背, 位于形状后上方, 包含点 [12, 13, 15, ...] 部件2: 坐垫, 位于形状中部水平面, 包含点 [45, 46, ...] 部件3: 椅腿, 位于形状底部四角, 包含点 [...]这种格式的好处是人机都能读。人看一眼就知道模型分出了什么机器则可以直接解析出点索引去做下游处理。而且这种格式天然支持交互用户说我要椅背模型就只输出椅背那一段用户点一个位置模型就输出包含该位置的部件描述。注意文本化表示的一个潜在风险是点索引部分会很长。一个几万点的模型如果每个部件都要列出所有点索引文本长度会爆炸。实际实现中通常会做下采样或者用区域描述代替逐点索引这一点在复现时要特别留意。3.3 文本化带来的三个额外好处除了统一接口文本化还带来几个不那么显眼但很实用的好处。其一是可解释性。传统分割模型输出一堆类别概率你很难判断它为什么这么分。文本化输出则直接告诉你模型的推理过程出错时也容易定位是语义理解错了还是空间定位错了。其二是易于扩展新部件类别。传统分类模型要加一个新类别得改输出层、重新训练。文本化表示下只要在训练数据里加入包含新部件名称的样本模型就能学会不需要动网络结构。其三是天然支持多任务联合训练。全形状拆分、交互式分割、文本引导分割在文本化框架下只是输入输出格式的细微差别可以混在同一个训练集里一起训模型能学到任务之间的共性。4. 模型怎么把3D形状读进语言模型4.1 3D编码器与语言模型的对齐PartLLM的架构本质上是3D编码器 多模态大语言模型的组合。3D编码器负责把点云或网格转成一串特征向量然后通过一个投影层把这些特征映射到语言模型的嵌入空间让语言模型能看懂3D形状。这里的关键技术点是模态对齐。3D特征和文本特征的分布差异很大直接拼接效果通常很差。常见的做法是用一个轻量的投影网络比如几层MLP做维度变换再配合对比学习或者指令微调让两个模态在语义空间里对齐。PartLLM这类工作通常会在预训练阶段就用大量的3D-文本配对数据做对齐然后在分割任务上做指令微调。4.2 点云序列化让Transformer能处理3D语言模型处理的是序列而点云是无序集合这两者怎么衔接主流做法有两种一种是用PointNet这类网络先提取局部特征再把特征序列化另一种是用FPS最远点采样加KNN分组把点云组织成类似词序列的结构。PartLLM大概率采用了后者或者类似的混合方案。具体来说先对原始点云做下采样得到一组中心点每个中心点通过KNN聚合周围点的特征形成一个个局部token。这些token按某种顺序排列后就变成了语言模型可以处理的序列。这个过程中采样密度和KNN的K值是两个关键超参采样太稀会丢失细节太密则序列过长、推理变慢K值太小局部信息不足太大则特征被过度平滑。4.3 输出端的约束解码文本化输出有个现实问题模型可能会胡说生成不存在的点索引或者格式错误的描述。所以在解码阶段通常要加约束。常见做法包括限制输出词表只包含合法的部件名称和格式符号用正则或者语法解析器校验输出格式对点索引做范围检查越界的直接丢弃或修正。这部分在论文里往往一笔带过但实际复现时是最容易踩坑的地方。我见过不少团队模型训得挺好一到推理就输出一堆乱码最后发现是解码约束没做好。5. 训练策略数据从哪来任务怎么混5.1 训练数据的构造PartLLM要同时支持三类任务训练数据也得覆盖这三类。全形状拆分的数据相对好找PartNet、ShapeNet这些数据集都有部件级标注。交互式分割的数据需要额外构造从全形状标注里随机选一个部件取其中一个点作为点击提示对应的部件作为目标输出。文本引导分割的数据则需要把部件名称和自然语言指令配对比如把扶手分出来对应扶手这个部件。这里有个容易被忽略的细节指令的多样性。如果训练时只用一种句式模型很容易过拟合到那个句式上换个说法就不认识了。所以构造数据时要有意识地做指令增强同一个意思用多种表达方式比如分割出椅背把椅背单独拿出来我要椅背这部分等等。5.2 多任务联合训练的损失设计三类任务混在一起训损失函数怎么设计是个学问。最直接的做法是全部当成文本生成任务用统一的交叉熵损失。但这样有个问题交互式分割和文本引导分割的输出通常比全形状拆分短很多如果按token平均短任务的权重会被稀释。常见的解决方案是按任务加权或者按样本长度做归一化。另一种思路是分阶段训练先在全形状拆分上预训练让模型学会基本的部件语义再用交互和文本引导数据做微调。PartLLM这类工作通常会报告两种策略的对比结果实践中分阶段训练往往更稳但联合训练的上限可能更高。5.3 指令微调的关键作用多模态大模型能不能做好分割很大程度上取决于指令微调的质量。预训练阶段模型学到的是3D形状和文本的粗对齐但具体到分割这个任务还需要专门的指令数据来教。指令微调的数据通常包含三部分任务描述比如请分割这个形状的所有部件、输入3D形状特征、输出文本化的分割结果。指令微调的一个经验是任务描述的模板要丰富但输出格式要严格统一。输入侧多样化能让模型适应各种问法输出侧统一则方便解析和评测。这个输入松、输出紧的原则在几乎所有指令微调任务里都适用。6. 实测表现与横向对比6.1 全形状拆分的精度从这类工作公开的结果看PartLLM在全形状拆分上的表现和专门的3D分割网络比如PointNet、DGCNN这些相比精度上不一定有压倒性优势但在泛化性上明显更好。专门网络换一个数据集往往要重新训练而PartLLM因为有大语言模型的常识做支撑跨数据集的迁移能力更强。具体指标上通常用mIoU平均交并比和部件准确率来衡量。PartLLM在标准数据集上能拿到和专用方法接近甚至略好的mIoU而在跨数据集测试中优势更明显。这个结果其实符合预期文本化表示牺牲了一点纯几何精度换来了语义理解和泛化能力。6.2 交互式分割的响应质量交互式分割最看重的是一次点击的命中率。用户点一下模型能不能准确抠出想要的部件。PartLLM在这方面的优势是语义先验即使点击位置在部件边缘模型也能根据整体语义判断出用户想要的是哪个部件而不是单纯按几何邻域分割。不过交互式分割的实时性是个短板。大语言模型的推理本身就有延迟加上3D编码的前处理单次交互的响应时间通常在秒级。对于需要高频交互的场景这个延迟可能不够理想。实际落地时可能需要对模型做蒸馏或者量化。6.3 文本引导分割的语义理解文本引导分割是PartLLM最能体现多模态优势的地方。传统方法做文本引导基本只能做整形状和文本的匹配而PartLLM能做到部件级的精细定位。比如输入把椅子的左前腿分出来模型不仅能理解左前腿这个语义还能在空间上准确定位。这里有个有意思的现象模型对空间方位词左、右、前、后、上、下的理解很大程度上依赖于训练数据里这些词的分布。如果训练数据里左总是对应某个固定视角模型可能会把左和绝对坐标绑定换个视角就出错。这是文本引导分割的一个隐蔽陷阱构造数据时要特别注意视角的多样性。任务类型传统专用方法PartLLM关键差异全形状拆分精度高泛化差精度接近泛化好语义先验带来跨域能力交互式分割响应快语义弱语义强响应慢大模型推理延迟是瓶颈文本引导分割只能整形状匹配部件级精细定位多模态对齐是关键7. 想复现或落地这几个坑得提前知道7.1 3D编码器的选择直接影响上限PartLLM这类框架里3D编码器往往被当成配角但实际上它决定了模型能提取到多少几何细节。如果编码器太弱后面语言模型再强也补不回来。实践中PointNet适合点云稀疏卷积适合体素网格卷积适合网格数据选哪个要看你的输入格式和精度要求。我的经验是如果下游对边界精度要求高编码器一定要用能保留局部细节的结构比如带注意力机制的Point Transformer而不是简单的全局池化。全局池化会把局部几何信息压没分割边界就会糊。7.2 文本化输出的解析容错前面提过模型输出可能格式错误。实际部署时解析器一定要做容错。比如点索引越界了不要直接报错而是截断到合法范围部件名称拼写错了可以用编辑距离匹配到最近的合法名称。这些容错逻辑看起来琐碎但直接决定了系统的可用性。提示建议在训练阶段就加入一些格式噪声样本让模型学会在轻微格式错误下也能输出正确内容。这比在推理阶段硬做后处理要优雅得多。7.3 评测指标要和任务匹配三类任务不能用同一套指标。全形状拆分看mIoU和部件准确率交互式分割看单次点击的IoU和交互轮数文本引导分割看文本-区域匹配准确率。如果混用指标很容易得出误导性结论。比如用全形状拆分的mIoU去评交互式分割会低估模型在单部件上的表现。7.4 数据标注的成本控制文本化表示虽然灵活但对标注的要求其实更高了。传统分割只要标类别文本化表示还要标部件名称、空间描述。如果全靠人工标成本会很高。实际做法通常是先用传统标注得到部件掩码再用规则或小模型自动生成文本描述人工只做抽检和修正。这样能把标注成本压下来。8. 这类统一框架接下来能怎么用PartLLM展示的用文本统一3D分割任务的思路其实可以往外延伸不少。最直接的是扩展到更多3D任务既然分割能文本化那么3D形状的编辑、装配、检索是不是也能用类似的方式统一比如把这个椅子的腿加长两厘米本质上是分割加形变文本化框架天然支持。另一个方向是和机器人操作结合。机器人抓取需要部件级理解而自然语言指令是人机交互最自然的方式。PartLLM这类模型如果能在边缘设备上跑起来就能让机器人听懂抓住杯子的把手这种指令直接定位到把手区域。当然实时性是前提模型压缩和蒸馏是必经之路。还有一个我觉得很有潜力的方向是3D内容的语义检索。现在3D模型库的检索基本靠标签或者几何相似度如果能把每个模型都文本化成部件描述检索就可以做到找出所有带扶手的椅子这种细粒度查询。这对3D资产管理和复用价值很大。我个人在实际折腾这类框架时的体会是统一框架的最大价值不在于单点精度而在于降低了多任务系统的工程复杂度。过去要维护三套模型、三套数据管线、三套评测现在一套搞定省下来的精力可以投入到数据质量和场景适配上。当然统一也意味着妥协某些任务上专用方法仍然更强。选不选这类框架取决于你的场景是单任务极致精度还是多任务快速覆盖。想清楚这一点比盲目追新要重要得多。