030、开放词汇检测OVD：CLIP与Grounding DINO的跨模态目标定位

030、开放词汇检测OVD：CLIP与Grounding DINO的跨模态目标定位

昨晚调了一宿的Grounding DINO，发现它在“把那个红色马克杯放到托盘上”这种指令里，愣是把红色马克杯识别成了红色笔记本。我盯着终端里输出的bounding box坐标看了半天，突然意识到问题不在模型本身，而在我对“开放词汇”这四个字的理解还停留在CLIP那个年代。今天这篇笔记，就把我从这个坑里爬出来的全过程记录下来，包括那些让我抓狂的细节。

先说清楚我们到底在解决什么问题。传统目标检测，比如YOLO或者Faster R-CNN，训练的时候固定了类别列表，你给它80个COCO类别，它就只能输出这80个框。但机器人操作场景里，用户说“帮我拿一下那个缺了角的蓝色碗”，这个“缺了角的蓝色碗”根本不在任何训练集里。开放词汇检测OVD要做的，就是让模型能检测出任意文本描述对应的物体，哪怕这个词它训练时从没见过。

CLIP给了我们一个思路：把图像和文本映射到同一个语义空间，用对比学习拉近匹配对的距离。但CLIP本身不做定位，它只能告诉你整张图和某段文本像不像。Grounding DINO则是在DINO这个检测框架上，把文本特征融合进跨模态解码器，让模型同时输出框和对应的文本匹配分数。这两者结合，理论上就能实现“你说什么，我框什么”。

但理论到工程之间，隔着一条叫“特征对齐”的河。我第一次跑通Grounding DINO的demo，输入“a red mug”，它框出来的是一整片红色区域，包括背景里的红色消防栓。我当时心想，这模型是不是把“红色”当成了主要线索，忽略了“mug”这个名词。后来翻源码才发现，Grounding DINO的文本编码器用的是BERT，而BERT对颜色词和物体词的注意力权重分配，和CLIP的文本编码器完全不一样。CLIP训练时见过海量的“a photo of a [color] [object]”这种模板，所以它对颜色和物体的组合理解更均衡。而BERT在预训练时，更多是学习词与词之间的语法关系，颜色词和物体词在句法上并不总是紧密绑定。

这个差异直接导致了一个工程上的坑：如果你直接用Grounding DINO的原始权重做机器人抓取的目标检测，遇到“红色马克杯”这种带颜色修饰的指令，它经常会把注意力过度放在颜色上，导致定位偏差。解决办法有两个方向。一是微调，用你自己的机器人场景数据，把Grounding DINO的文本编码器部分冻结，只微调跨模态模块，让模型学会在特定场景下如何权衡颜色和物体类别。二是做后处理，把CLIP的分数和Grounding DINO的框置信度做一个加权融合，CLIP负责验证“这个框里的东西是不是文本描述的那个”，Grounding DINO负责“哪里可能有东西”。

我后来采用了第二种方案，因为微调需要大量标注数据，而我的场景里只有几百张真实抓取图片。具体做法是：先用Grounding DINO生成一批候选框，每个框对应一个文本描述，然后把这些框裁剪出来，分别和原始文本输入CLIP，得到图像-文本匹配分数。最后把Grounding DINO的检测分数和CLIP的匹配分数做加权平均，权重系数我用网格搜索在验证集上调过，0.6和0.4的组合效果最好。这里有个细节，CLIP的输入图像分辨率是224x224，而Grounding DINO的候选框可能很小，直接resize会丢失细节。我试过把裁剪区域先放大两倍再resize，CLIP的匹配分数明显更可靠。

再聊聊Grounding DINO本身的架构细节。它的核心是DINO的query机制，但每个query不仅要预测框，还要预测和文本token的对应关系。具体来说，每个query会输出一个对齐分数，表示这个框和输入文本中哪个token最相关。这个设计很巧妙，但实现上有个容易忽略的点：文本输入的长度限制。Grounding DINO默认的文本最大长度是256个token，但BERT的tokenizer会把“the red mug on the table”拆成7个token，看起来够用。可如果你的指令是“帮我拿那个放在蓝色托盘上的、旁边有黄色便签纸的红色马克杯”，这句话拆出来可能超过30个token，虽然没超256，但模型对长文本的注意力会分散，导致检测精度下降。我的经验是，在机器人指令解析阶段，先做一次简单的关键词提取，把“红色马克杯”这种核心名词短语单独抽出来作为检测文本，而不是把整句指令直接丢给Grounding DINO。

还有一个让我调试到凌晨两点的坑，是关于类别词表的。Grounding DINO在推理时，文本输入是“class names with .”这种格式，比如“red mug . blue bowl . yellow sponge .”。这个点号是必须的，它告诉模型这是一个类别列表的结束。但如果你在类别列表里混入了“on the table”这种位置描述，模型会尝试把位置信息也当成检测目标，输出一堆奇怪的框。我一开始没注意，把“red mug on the table”直接作为类别输入，结果模型框出了整个桌面。后来改成“red mug . table .”，虽然table也被检测了，但至少mug的框是准的。更稳妥的做法是，在文本输入前用正则把介词短语过滤掉，只保留名词短语。

代码实现上，我用的HuggingFace的transformers库加载Grounding DINO，但发现它的预处理和后处理接口和原版DETR不太一样。这里踩过一个坑：transformers库的GroundingDINOProcessor在把文本转成input_ids时，会自动在开头加一个[CLS] token，但模型内部的文本编码器期望的输入格式是“类别名 + 点号”，如果你直接传“red mug”而不加点号，模型会把它当成一个不完整的句子，输出的对齐分数会偏低。所以我在封装推理函数时，强制在文本末尾追加一个句点，并且把类别名之间的空格替换成“ . ”分隔符。这个细节不处理，你会发现同样的文本，在官方demo里能检测出来，在你的代码里就检测不出来。

关于CLIP的融合，我用的OpenCLIP的ViT-B/32权重，因为它在零样本分类上的表现比原版CLIP略好一点。但注意，CLIP的文本编码器对大小写敏感，“Red Mug”和“red mug”在语义空间的距离比想象中要大。我在预处理时统一转小写，并且把复数形式转成单数，比如“mugs”转成“mug”。这个简单的归一化操作，让CLIP匹配分数平均提升了0.05左右。

融合策略的权重系数，我一开始用固定值，但后来发现不同场景下最优权重不一样。比如在光线均匀的桌面场景，Grounding DINO的框质量很高，CLIP的验证作用没那么大，权重可以调到0.7对0.3。但在光线复杂或者有遮挡的货架场景，Grounding DINO容易产生误检，CLIP的验证作用就变得重要，权重应该反过来。所以我把权重系数做成了动态的，根据Grounding DINO输出的框置信度分布来调整——如果所有框的置信度都很低，说明模型不确定，就加大CLIP的权重；如果置信度普遍很高，说明模型很自信，就减小CLIP的权重。这个启发式规则在测试集上比固定权重提升了约8%的准确率。

调试过程中还有一个让我困惑很久的现象：Grounding DINO对“透明物体”的检测效果极差。比如“透明玻璃杯”，它经常框不出来，或者框出来的区域是背景。后来我看了模型在COCO和ODinW上的训练数据，发现透明物体在训练集里占比极低，模型根本没有见过足够的透明材质样本。这个问题在机器人抓取场景里很致命，因为实验室里到处都是透明烧杯和培养皿。我的临时解决方案是，在文本描述里加上材质词，比如“transparent glass cup”，并且把CLIP的权重调高，因为CLIP在互联网图像上学过透明物体的视觉特征。但这也只能缓解，真正要解决还是得靠领域微调。

最后说说落地经验。如果你要把这套OVD方案部署到真实机器人上，别指望单帧检测就能稳定工作。我建议做多帧投票，连续采集5帧图像，每帧都跑一次检测，然后对检测框做IoU聚类，保留出现次数最多的框。这个简单的时序平滑，能把因为运动模糊或者反光导致的单帧误检过滤掉。另外，检测框的坐标一定要映射到机器人基座坐标系，这里涉及到相机标定，我吃过亏——标定板用的是棋盘格，但实验室灯光反光导致角点检测失败，最后换成了AprilTag才稳定。

关于推理速度，Grounding DINO的base模型在3090上单帧大约120ms，加上CLIP的验证，总共要200ms左右。对于机器人抓取来说，这个速度勉强够用，但如果你用的是机械臂实时伺服，建议把CLIP的验证频率降低，比如每5帧验证一次，其他帧只靠Grounding DINO。或者用更轻量的CLIP变体，比如ViT-B/16，精度略降但速度提升明显。

写到这里，我看了眼窗外，天已经亮了。OVD这个方向，模型本身的能力边界其实很清楚，真正的难点在于如何把模型嵌入到机器人的感知-决策闭环里，处理那些训练数据里永远学不到的边缘情况。我的建议是，别迷信单一模型，CLIP和Grounding DINO的融合只是起点，你还可以尝试把SAM的mask信息加进来，让检测框更贴合物体轮廓，这对抓取姿态估计很有帮助。但每一步融合都会引入新的超参数和调试成本，务必做好消融实验，别一股脑全堆上去。