企业官网建设流程全解析

标注了一套固定类别，换一个场景就得重新标数据、重训模型；而YOLO-World允许你直接给模型一句话，它就能在图片里去找你描述的物体。"人、公交车、红绿灯"传入模型，它就能把这几类目标框出来。更关键的是，它跑在ultralytics这个几乎所有YOLO玩家都熟悉的框架里，这意味着你可以同时拿到YOLO系列的训练生态和开放词汇的灵活性。这篇内容就是一份从原理、推理、数据集准备、训练执行到问题排查的完整记录，适合已经跑过YOLOv8、现在想尝试YOLO-World的开发者，也适合准备把自己的业务数据喂进去做微调的人。

1. 为什么是YOLO-World：开放词汇检测的设计逻辑

1.1 固定类别模型与开放词汇模型的本质差异

先想清楚一个边界问题：普通YOLOv8和YOLO-World到底差在哪里。

普通YOLO模型的检测头是一个固定维度的分类器。假如训练数据里有5个类别，那检测头的分类分支输出就是5个通道，每个通道对应一个写死的类别。你训练完这个模型，它就只认识这5类，想去检测第6类，只有重新标注数据、重新训练这一条路。这在实际项目里非常难受，尤其是工业场景中目标种类经常变化，或者目标是"没有明确学名、只能用语义描述"的物体时，固定类别模型的维护成本会不断累积。

YOLO-World把这一层逻辑换掉了。它不再为每个预定义类别学习一个独立的分类向量，而是把CLIP文本编码器引入检测头，让"类别"变成可以由文本向量动态指定的东西。在推理阶段，你想检测什么，就把对应的文本描述传给模型，模型通过计算图像特征和文本向量之间的匹配度，输出检测结果。本质上，它从"识别训练时见过的类别"变成了"理解训练时见过的概念并泛化到新类别"。

这个差异带来的好处非常明显：第一，新场景不用重新训练就能跑，对数据标注周期长的项目尤其友好；第二，检测目标是动态的，比如在视频流里先搜"人"，再搜"橙色安全帽"，不需要维护多套模型；第三，它能利用CLIP在大规模图文对上学习到的语义知识，对训练数据没见过的类别也有一定的零样本能力。

当然，代价也是存在的。最直接的是，同等参数规模下，YOLO-World在固定类别上的精度通常不如专门为这些类别训练过的普通YOLO模型。这个后面在训练部分会专门展开，因为很多人在对比mAP时会在这里产生困惑。

1.2 三大组件：CLIP文本编码器、RepVL-PAN、文本对比头

YOLO-World的架构可以拆成三个部分来看，理解了它们各自的分工，后面跑代码和调参时就不会晕。

第一部分是文本编码器。它使用的是CLIP中的TextEncoder，作用是把"person"、"car"这样的自然语言字符串转换成文本嵌入向量。这个编码器通常是冻结的，不参与训练，原因有二：一是CLIP已经在几十亿图文对上预训练过，文本语义知识足够丰富；二是如果放开训练，文本编码器很容易在小数据集上过拟合或者发生语义漂移，导致训练过程不稳定。

第二部分是RepVL-PAN，这是YOLO-World对YOLOv8原有PAN-FPN结构的升级。普通YOLOv8的颈部网络只做视觉特征的多尺度融合，而YOLO-World在融合过程中加入了一个跨模态融合模块，把文本嵌入的语义信息注入到不同尺度的视觉特征中。这个注入不是简单拼接，而是通过注意力或门控机制让视觉特征"知道"当前要找什么，从而更高效的提取和聚集相关信息。简单来说，普通PAN-FPN是一个精密的视觉信息通路，而RepVL-PAN在这条通路上加了一条文本信息旁路，两者在多个尺度上反复对话。

第三部分是文本对比头TextContrastiveHead。这是YOLO-World检测头的核心，它不像普通检测头那样直接输出属于每个类别的概率，而是计算每个锚框的视觉嵌入与文本嵌入矩阵的相似度。这里的文本嵌入矩阵是当前词汇表中所有类别文本的向量集合。用相似度结果加上sigmoid激活，就能得到"这个框是否匹配描述内容"的置信度。因为类别数量不再固定，而是取决于你传入的文本矩阵大小，所以模型天然支持类别集合的动态变换。

1.3 速度为什么还能保持在高帧率

很多第一次接触YOLO-World的人会有一个直觉疑问：一旦引入文本模型，推理开销是不是会爆炸？毕竟像GroundingDINO这类开放词汇检测模型，需要把图像特征和文本特征在Transformer里做稠密交互，帧率很难做高。

YOLO-World的解决思路非常务实：把"理解文本"和"检测物体"解耦。在推理阶段，所有类别文本先通过CLIP文本编码器离线算好嵌入向量，得到一个文本嵌入矩阵。这个矩阵在检测过程中相当于一张提前查好的表，模型只需要把图像区域特征拿过来和这张表做矩阵乘法，本质上和普通分类层的计算复杂度差不多。因此，只要不频繁切换词汇表，YOLO-World的每一帧推理几乎不会产生额外的文本模型开销。

换句话说，它用"词汇表预计算"换来了推理速度。代价是，如果每一帧都要换一批文本描述，那就得每帧都跑一次文本编码器，速度会明显下降。实际业务中通常都是场景固定、词汇表固定，预计算的收益非常可观。这也是YOLO-World能在边缘设备、实时视频流这类场景落地的一个重要原因。

2. ultralytics下把YOLO-World跑起来：文件、参数与第一个Demo

2.1 环境版本建议与模型文件获取

ultralytics从很早就开始支持YOLO-World，但不同版本的支持程度有差异。早期版本里，YOLO-World被封装在单独的YOLOWorld类中，后面版本逐渐统一到了YOLO类里，加载时根据模型结构自动识别任务类型。我的建议是直接使用当前较新的ultralytics版本，同时保证环境里能联网，因为加载模型时可能需要下载权重。

安装不需要特殊处理，常规pip安装即可：

pip install -U ultralytics

模型权重可以从ultralytics官方assets下载，权重文件名的规律是yolov8s-worldv2.pt、yolov8m-worldv2.pt、yolov8l-worldv2.pt，其中worldv2是优化过的版本，推荐优先使用。注意不要拿普通的yolov8s.pt来当YOLO-World用，两者结构完全不同，普通权重加载到world模型上会导致检测头和颈部网络的参数无法对齐，后面训练会出现各种奇怪问题。

加载模型的方式非常简单：

from ultralytics import YOLO model = YOLO("yolov8s-worldv2.pt")

这一步做完，你可以先用model.info()看看模型结构，确认加载的是world变体而不是普通YOLO。如果打印出来的模型结构里有TextContrastiveHead或者RepVL-PAN相关的层，说明权重加载正确。

2.2 text参数、set_classes与推理结果解读

推理时的第一个核心参数就是text。它是模型需要检测的文本描述列表，用逗号分隔：

results = model.predict( source="street.jpg", text="person, bicycle, car, traffic light", conf=0.03, )

初次运行你会注意到，传了text之后，模型会先把这个字符串拆成列表，经过CLIP文本编码器逐条编码，再生成文本嵌入矩阵。在GPU上这个过程耗时不长，但CPU上会比较明显，这正好解释了前面说的"词汇表预计算"机制。

一个容易踩的坑是置信度阈值。默认的conf=0.25在普通YOLO上很合理，但在YOLO-World零样本推理时，模型对未见过类别的响应分布往往比较平滑，很多真实目标都会被滤掉。我自己的经验是，零样本场景下先把conf压到0.03左右，看看模型实际能检出什么，再根据可视化结果调整。如果你已经用数据集微调过，阈值可以逐步恢复上去。

text参数的顺序是有意义的。YOLO-World会按你传入文本的顺序给检测框分配类别ID，也就是说text="person, bicycle"时，结果里的类别0是person，类别1是bicycle。如果你在同一个流程里同时用了多个文本列表，务必保持顺序一致，否则结果对比时会被绕进去。

另一种方式是先固定类别再推理：

model.set_classes(["person", "bicycle", "car", "traffic light"]) results = model.predict(source="street.jpg", conf=0.03)

这两种方式在结果上没有本质区别，但set_classes的好处是，它会主动触发一次文本嵌入计算并缓存起来，后续多次推理不会再重复编码，批量处理图片时效率更高。如果你是对一批图片做离线处理，建议用这种方式。

拿到results之后，常规的取框方式跟普通YOLO完全一样：

boxes = results[0].boxes for box in boxes: print(box.cls, box.conf, box.xyxy)

可视化也直接调用results[0].plot()然后保存图片即可，检测框上会显示文本列表中对应的类别名。

2.3 离线词汇表机制与实际部署限制

set_classes背后有一个很关键的工程概念，就是"离线词汇表"。YOLO-World推理时，检测头拿到的不是一个文本字典，而是一个已经算好的文本嵌入矩阵。这个矩阵的每一行对应一个类别文本。在你想换一批类别时，只要重建这个矩阵，模型就能立刻切换到新的检测语义上，不需要重新加载整个模型。

这给了部署阶段很大的灵活性。比如在服务端，你可以维护一个词汇表池，每个请求根据业务参数选择不同的词汇表，用set_classes动态切换。由于文本编码器本身不大，一次性编码几百个类别也只需数百毫秒，而后续推理帧率不会受到词汇表大小的影响。

但有一个限制需要清醒认识：导出ONNX或TensorRT之后，词汇表会被固化。导出的模型结构里已经写死了文本嵌入矩阵的数值，运行时不再依赖CLIP文本编码器。这意味着，导出的模型只能检测导出前指定的那些类别，无法再动态扩大。如果你的部署形态是多场景共用同一个模型，最好在框架内切换词汇表，或者为每个场景分别导出一个引擎文件。

3. 训练自己的数据集：从标注到custom_vocabulary的每一步

3.1 标注工具与目录结构整理

YOLO-World训练支持的数据格式和普通YOLO完全一致，就是ultralytics统一使用的YOLO标注格式。如果你已经跑过YOLOv8训练，这一步基本没有额外成本。

标注工具方面，常用的有X-AnyLabeling、labelImg、Roboflow。我个人的偏好是X-AnyLabeling，它能加载已有的YOLO-World模型做预标注，人工只需要修正边界框和类别，在冷启动一个数据集的阶段能节省大量时间。不管你用哪个工具，最终输出到磁盘上的标注文件都应该是这样的：

class_id x_center y_center width height

坐标全部归一化到0到1之间，单位是图片宽高的比例。一个典型的目录结构如下：

dataset/ ├── images/ │ ├── train/ │ │ ├── img_001.jpg │ │ └── img_002.jpg │ └── val/ │ ├── img_101.jpg │ └── img_102.jpg ├── labels/ │ ├── train/ │ │ ├── img_001.txt │ │ └── img_002.txt │ └── val/ │ ├── img_101.txt │ └── img_102.txt └── data.yaml

注意一点：每张图片对应的标注txt文件名必须和图片文件名完全一致，包括扩展名前的部分。这个规则和YOLOv5、YOLOv8时代一模一样，不再赘述。

3.2 最容易出错的环节：标注ID与词汇表顺序的对应

这是YOLO-World训练里我认为最值得单独拿出来讲的环节，因为训练时模型本身不会帮你检查，一旦顺序错位，训练过程照常进行，loss也能降，但最终模型的检测语义完全错乱。

普通YOLO训练时，模型的类别语义写在data.yaml的names字段里，类别ID对应names的索引。而YOLO-World训练时，语义信息主要来自custom_vocabulary参数指定的一个纯文本文件，每行一个类别名。关键的对应规则是：标注txt里的类别ID必须与custom_vocabulary.txt中的行号一一对应。

举例说明。假设你的数据集有三类：

• 类别ID 0：car_license_plate（车牌）
• 类别ID 1：car
• 类别ID 2：person

那么custom_vocabulary.txt内容必须是这样：

car_license_plate car person

第一行对应ID 0，第二行对应ID 1，第三行对应ID 2。如果你写成了：

person car_license_plate car

那么训练时，模型会把标注为ID 0的框去和"person"这个文本对齐，而数据里ID 0实际是车牌。结果就是模型努力把车牌学成"人"，整个标签空间被打乱。

怎么提前排掉这个雷？写个小脚本：

import yaml data_cfg = yaml.safe_load(open("dataset/data.yaml", encoding="utf-8")) names = data_cfg["names"] with open("custom_vocabulary.txt", "r", encoding="utf-8") as f: vocab = [line.strip() for line in f if line.strip()] for i, (n, v) in enumerate(zip(names, vocab)): assert n.lower() == v.lower(), f"位置 {i}: names={n}, vocab={v} 不一致" print("names与custom_vocabulary顺序一致")

无论你是否在训练前做这个检查，我都强烈建议把custom_vocabulary.txt和标注文件的ID映射放在一起管理。一旦数据集类别有增删，先同步改这两个文件，再谈训练。

3.3 data yaml与custom_vocabulary的关系

data.yaml里仍然需要提供path、train、val、nc和names字段。其中path、train、val是路径信息，nc由类别数量决定。但有一个容易混淆的点，在YOLO-World训练中决定检测语义的是custom_vocabulary，而不是data.yaml里的names。

那么data.yaml里的names还有没有意义？有意义，但不是用于检测头的语义分配，而是用于数据校验、日志记录和评估阶段的可读性。为了保证整个流程的一致性，我建议data.yaml中的names顺序和custom_vocabulary.txt中的行顺序保持完全一致。这样训练日志里显示的类别名，和模型实际使用的文本嵌入，始终能对上。

最终你的data.yaml大致长这样：

path: /your/absolute/path/dataset train: images/train val: images/val nc: 3 names: 0: car_license_plate 1: car 2: person

而custom_vocabulary.txt与之对应。这两套配置就像一双鞋，缺一只都不行。

4. 训练实战与参数解析：用预训练权重微调的全过程

4.1 训练命令与预训练权重选择

训练YOLO-World，命令行和Python调用都支持。先说命令行：

yolo train \ model=yolov8s-worldv2.pt \ data=dataset/data.yaml \ custom_vocabulary=custom_vocabulary.txt \ epochs=200 \ imgsz=640 \ batch=16 \ device=0

换成Python API，写法也很接近：

from ultralytics import YOLO model = YOLO("yolov8s-worldv2.pt") model.train( data="dataset/data.yaml", custom_vocabulary="custom_vocabulary.txt", epochs=200, imgsz=640, batch=16, device=0, )

这里最关键的是预训练权重的选择。前面已经强调过，不要用普通yolov8s.pt。加载普通YOLO权重到YOLO-World结构时，TextContrastiveHead和RepVL-PAN中的跨模态融合层会随机初始化，等于丢失了模型最重要的语义先验，训练效果往往不如直接加载yolov8s-worldv2.pt。

另外，custom_vocabulary传一次还不够。如果你训练结束后马上做验证，记得验证阶段也要传：

model.val(data="dataset/data.yaml", custom_vocabulary="custom_vocabulary.txt")

因为验证阶段同样需要文本嵌入矩阵来跑检测头，不传词汇表的话，模型要么沿用默认词汇表，要么直接报错。

4.2 关键超参：batch、lr、freeze与实际效果

这里逐个说我从实验里得到的经验值，不代表这些值对每一个数据集都最优，但作为起点很稳。

batch取决于显存。YOLO-World的训练显存占用会比普通YOLOv8略高，因为RepVL-PAN里多了跨模态融合层，梯度回传时这些层也会占用显存。显存不够的时候，我不会一味调小batch，这会降低batch normalization的统计稳定性。更好的方案是保持batch不变、调小imgsz，或者用梯度累积。ultralytics里的batch参数可以直接写数字，也可以用-1自动检测显卡能承载的最大值，我建议先跑一次batch=-1，看自动检测结果，再手动固定下来。

lr0是初始学习率。基于预训练权重微调时，我建议设置成0.0005左右，比从头训练的默认值低一个数量级。这个选择背后的逻辑是：预训练模型已经具备很强的视觉语义能力，学习率太高会把已经学到的好特征冲掉。如果你只用了几百张图的小数据集，再降到0.0001也不过分。

freeze参数在YOLO-World微调里有特殊含义。冻结前N层的最常见用法是冻结backbone，前10层基本都在backbone内部，freeze=10可以显著减少训练时间和显存占用。数据量很小、或者目标域与预训练域相似的场景，冻结backbone通常效果更好。但如果你的数据域和预训练数据差别很大，比如从自然图像转到医学影像，冻结backbone反而会限制模型对新域的适应。这种情况下我更倾向于不冻结，让整个网络充分调整。

还有一个容易被忽略的参数是workers。数据读取线程数设得太低，训练过程会频繁等数据，GPU利用率上不去。设得太高，内存占用直线上升，甚至可能报共享内存不足。一般经验是每张卡workers=4到8，同时设置pin_memory=True。

4.3 训练监控：loss曲线与mAP评估

训练时的loss曲线，观察点和普通YOLO有一处明显区别。

普通YOLO的cls_loss下降通常比较平稳，因为分类任务相对明确。YOLO-World的cls_loss实际上是文本对比损失，在训练早期往往比普通YOLO的cls_loss高出一截，而且波动更大。这不一定是训练出问题，而是开放词汇检测头本身的特性：文本嵌入空间和视觉嵌入空间在初始阶段并没有完全对齐，模型需要先学习把区域特征映射到文本语义空间，这个过程会表现为loss偏高且抖动。所以看到这个曲线时不用慌，让训练多跑几个epoch，如果整体趋势是下降的，就继续等。

用到的主要指标还是mAP50和mAP50-95。验证阶段需要注意，YOLO-World的验证结果和在线推理一样，依赖于词汇表。如果val命令漏掉了custom_vocabulary，模型使用的是默认词汇表，而数据标注的类别可能根本不在默认词汇表里，mAP会低得离谱，这时候先怀疑词汇表传没传，再怀疑模型本身。

训练完成后，runs/detect/trainX/下会生成best.pt和last.pt。best.pt是在验证集上mAP最高的权重，日常使用优先选它。我还会习惯性对比一下微调后的模型和预训练模型在验证集上的mAP差距，这个对比能直观告诉你，微调到底有多少收益。

这里顺便回应一下开头提到的"精度换灵活"问题：微调后的YOLO-World在固定类别上的mAP通常还是比同参数量的普通YOLOv8低一点，但在很多场景下已经足够接近了。如果你的业务类别稳定、数据量大、且对精度极度敏感，普通YOLOv8依然是合理选择。如果你有动态检测需求或冷启动压力，YOLO-World的灵活性就值得这点精度差。

5. 进阶：如何让微调后的模型保持"开放词汇"能力

5.1 固定词汇表微调的局限性

默认的微调流程是，在custom_vocabulary上限定当前数据集的类别，让模型集中学习这些类别的视觉模式。这个流程简单高效，但也埋了一个隐患：随着训练推进，检测头的文本对比分支会被当前词汇表"拉向"训练数据的分布，模型对词汇表之外类别的响应能力会逐步退化。

很多人没有意识到这个退化会在什么时候发生。数据量越大、训练epochs越多，退化越明显。因为在每一轮优化中，模型都在强化"当前类别组合"的特征映射，而其他方向上的语义空间逐渐被挤压。如果你只是做一个固定场景的专用模型，这个退化无所谓。但如果你希望模型"既能做好当前数据集的类别，又能保留一定开放词汇发现能力"，就得换个思路。

5.2 混合数据训练与蒸馏思路

一个立竿见影的办法是混合数据训练。在训练集里，除了你自己的业务数据，再混入一批覆盖面广的开放词汇数据，比如COCO的完整子集。这样模型在每一轮迭代中，既能看到业务类别的紧密样本，也能周期性复习通用类别的语义映射。实际操作时不需要改代码，只需要在目录结构上把两批数据合并，重新生成一份包含全部类别的data.yaml和custom_vocabulary.txt。

但要注意，混合训练有个明显的坑：业务数据的标注质量通常远高于开放数据集，而且数量上往往不对等。如果开放数据量过大，模型会把主要容量花在通用类别上，业务类别的精度反而不够；如果过小，又起不到复习开放词汇的作用。我的经验是，先按业务数据量的20%到30%加入开放数据，观察mAP变化再逐步调整比例。

另一条路是蒸馏。用一个更大的、未微调的YOLO-World模型（例如yolov8x-worldv2）对当前数据集的图片做一次推理，生成预测结果，经过置信度筛选后作为伪标签加入训练。这样做的意义在于，teacher模型看到的图片和训练数据相同，但它保留了更强的开放词汇表征，可以把这些表征迁移到小模型上。实际操作中，伪标签的置信度阈值要设置得比较高，比如0.4以上，而且最好只保留那些置信度高、且类别在目标词汇表中的伪框，避免引入噪声。严格来说这不是标准的知识蒸馏框架，ultralytics也没有专门为YOLO-World蒸馏封装接口，但实践下来，伪标签混合训练确实能缓解开放词汇能力衰减。

5.3 多词汇表切换与工程化建议

在工程部署层面，保留开放词汇能力还有一条更朴素的路线：同时维护多个词汇表，按场景动态切换。

前面提到的set_classes和离线词汇表机制，让这个想法实现起来非常顺滑。你可以在应用启动时把所有场景的词汇表都编码好，缓存成多个文本嵌入矩阵；每次处理请求时，根据业务参数选择对应的矩阵，重新设置给模型。在这个机制下，你甚至不需要为每个场景单独训练一个模型，同一个微调模型的参数在所有场景间共享，切换的代价只是几十毫秒的矩阵替换开销。

我实际跑过的一个项目是安防巡检场景：同一个路口摄像头，白天检测"人、车、非机动车"，晚上检测"行人、电瓶车、施工锥桶"，两个词汇表有重叠也有差异。用YOLO-World后，我只需要训练一个模型，在运行时切换词汇表，就同时满足了两个时段的需求。如果用普通YOLO，要么训练一个包含全部类别的大模型，要么维护两套模型做级联，逻辑和运维都会重不少。

这里还需要提一句中文词汇表的问题。CLIP的文本编码器主要基于英文训练，对中文的支持本质上是通过分词后在英文语义空间里重新组合，效果远不如英文原词。我的建议是，custom_vocabulary.txt里的类别名尽量用英文或英文短语，例如用traffic light而不是红绿灯。如果你的业务系统最终要展示中文，可以在推理后做一个从英文类别ID到中文显示名的映射，展示层做本地化，模型层保持英文，这样训练和部署的稳定性都会高很多。

6. 踩坑实录：从环境异常到精度异常的完整排查链路

6.1 显存溢出与训练中断的定位方法

YOLO-World训练最常见的故障就是CUDA Out of Memory。普通做法是直接把batch调小，但有时候即使是batch=4还是爆显存，这时候问题就不在batch本身了。

我的排查顺序是这样的：先用nvidia-smi确认是否还有其他进程占用了显存，比如之前测试留下的Python进程没有正常退出；然后启动一个只加载模型的前向推理脚本，观察模型本身的基础显存占用；最后再叠加训练过程，看峰值显存出现在哪个阶段。如果峰值出现在第一个step之后，说明是梯度计算和优化器状态占用的显存，优先考虑调小imgsz；如果出现在训练中途，可能是验证脚本在同一会话里运行，验证阶段推理模式会额外加载一层激活值，显存需求会陡增。

调batch之外，有实际效果的手段包括：开启混合精度训练，用amp=True；降低imgsz从640降到512；关闭大尺度数据增强中的mosaic，因为mosaic会拼接多张图，单张训练样本的有效分辨率会成倍增加，对显存的消耗明显。

如果以上都试了还是不够，就检查CPU内存和shared memory。workers设太高时，每个数据加载进程都会复制一份图片缓存，机器内存不足一样会导致训练中断，报错信息往往还比较隐蔽。把workers降到2，或者改batch=1搭配梯度累积，是最后的备选方案。

6.2 loss正常但mAP过低的根因分析

更折磨人的问题是训练过程一切正常，loss曲线下降得也很漂亮，但验证mAP一直在低位徘徊。我的排查顺序如下。

第一步，也是概率最高的一步，检查词汇表顺序和标注ID顺序是否一致。上面讲过，这个错误不会让训练报错，但会让模型学到的语义与真实标注完全错位。我曾经用错乱的词汇表跑了60个epoch，loss降到很低，mAP却只有0.01，定位到问题后重新训练，同样配置下mAP直接跳到0.78。所以在怀疑模型之前，一定先用脚本核对。

第二步，检查训练和验证时用到的custom_vocabulary是否完全一致。有一种隐蔽的情况是，训练时用了custom_vocabulary.txt，验证时忘了传，模型回到了默认词汇表。默认词汇表通常包含80个COCO类别，跟你的3类业务数据完全对不上，mAP自然惨不忍睹。

第三步，画图看预测结果。挑几张验证集图片，载入训练好的模型，把预测框画出来看。这一步能把"词汇表对不上"和"模型真的没学好"区分开。如果画出来的框位置准但类别名全是乱的，词汇表问题；如果框本身乱飘，才需要继续查数据和训练参数。

第四步，检查类别分布。如果训练集里某个类别的样本数只有个位数，模型几乎没有机会学到这个类的特征，mAP低是必然的。这种情况需要补充数据，或者做类别重采样，让每个类别在每个batch中都有代表性的样本。

6.3 类别错乱的中文提示与空格问题

最后一个坑在推理阶段比较常见。

text参数是按逗号分割的，所以类别名称本身不能包含逗号，这个很容易理解。但很多人会忽略空格的问题。比如text="traffic light, fire hydrant"里的空格是标签名的一部分，CLIP编码英文短语时空格有语义作用，所以要正常保留，不要做strip处理。如果你在custom_vocabulary.txt里写了traffic light，但在推理时写了trafficlight，模型不会报错，但检测效果会明显下降，因为文本嵌入已经发生了变化。

中文类别名的问题前面提到过，这里再给一个具体案例。我试过用text="安全帽, 反光衣"直接推理，模型输出非常多误检，很多完全不相干的区域都被高亮。换成英文hard hat, reflective vest之后，误检大幅减少。这不是模型没学好，而是CLIP分词器对中文的切分粒度和语义映射都不够稳定。除非你的业务严格要求中文提示且做了专门的文本编码器微调，否则都建议在输入层用英文词汇，展示层再做本地化翻译。

另外，set_classes之后如果还想切换回之前的词汇表，有一个隐性的显存问题：模型会把新词汇表的嵌入矩阵缓存在内存或显存里，旧的嵌入不一定立刻释放。长时间运行在多个词汇表之间切换的服务，显存占用会缓慢上升。我的做法是每隔一段时间显式重建一次模型对象，或者提前把用不到的嵌入矩阵引用置空，再调一次torch.cuda.empty_cache()。这不是YOLO-World特有的问题，但在这个动态词汇机制下更容易暴露出来。

最后分享一个我自己的常规操作习惯。每次拿到一个陌生场景的数据集，我不会一头扎进训练，而是先用预训练的yolov8s-worldv2.pt配合目标类别的文本去跑一遍原始图片，看看零样本效果到底怎么样。如果零样本已经能框出大部分目标，只是边界不够精细，说明这个任务对模型来说难度不大，微调几十张图就能见效；如果零样本完全找不到目标，那就要怀疑这个目标类别在CLIP的语义空间里缺乏对应概念，需要重新划分类别名，或者加入大量针对性的标注数据。这十个判断步骤，帮我省掉了大量无效训练时间。