YOLOE: Detección y segmentación de vocabulario abierto en tiempo real#

Ultralytics YOLOE (Seeing Anything en tiempo real) es un modelo de detección y segmentación de instancias de vocabulario abierto: en lugar de utilizar una lista de clases fija durante el entrenamiento, acepta las categorías que quieras en el momento de la inferencia, como una indicación de texto, un ejemplo visual o mediante un vocabulario integrado de 4585 nombres. Basado en las arquitecturas YOLO de Ultralytics — YOLOv8, YOLO11 y YOLO26— e inspirado en YOLO-World, YOLOE alcanza una precisión zero-shot de vanguardia con una velocidad cercana a la de YOLO de conjunto cerrado.

Inicio rápido#

Nombra las clases que quieras y ejecuta el modelo. YOLOE-26 devuelve cajas y máscaras de segmentación de instancias para categorías con las que nunca se entrenó.

from ultralytics import YOLOE

model = YOLOE("yoloe-26s-seg.pt")

# "double-decker bus" is not a COCO class; YOLOE resolves it from the words alone
model.set_classes(["double-decker bus", "person"])

results = model.predict("https://ultralytics.com/images/bus.jpg")
results[0].show()

La primera llamada a set_classes() descarga un codificador de texto; consulta Instalación y requisitos antes de desplegarlo en una máquina sin acceso a la red.

Elección del modo de prompting#

YOLOE admite tres modos de prompting, y la elección determina qué checkpoint cargas y qué aspecto tienen las etiquetas de clase. Elige la fila que corresponda a lo que puedes proporcionar en el momento de la inferencia.

Instalación y requisitos#

YOLOE se incluye en el paquete principal de Ultralytics:

pip install -U ultralytics

El prompting de texto también necesita un codificador de texto, que se obtiene en el primer uso en lugar de durante la instalación:

• La primera llamada a set_classes() instala ultralytics/CLIP desde GitHub con pip (proporciona el tokenizador) y descarga un codificador de texto TorchScript en el directorio de trabajo actual. YOLOE-26 obtiene mobileclip2_b.ts, de unos 254 MB; YOLOE-11 y YOLOE-v8 obtienen mobileclip_blt.ts. Ejecuta la descarga una vez desde el directorio desde el que vas a ejecutar el modelo, o copia allí el archivo; de lo contrario, se volverá a descargar.
• Ambos pasos necesitan acceso a la red, así que ejecuta una predicción con prompting antes de desplegar el modelo en una máquina sin conexión o aislada de la red.
• Las indicaciones visuales y los checkpoints sin indicaciones no necesitan ningún codificador de texto.

Los checkpoints YOLOE-26 requieren ultralytics 8.4.0 o posterior; las familias YOLOE-11 y YOLOE-v8 están disponibles en versiones anteriores. Una predicción con indicación de texto prueba todo el flujo: descarga del checkpoint, instalación de CLIP, codificador de texto e inferencia:

yolo predict model=yoloe-26s-seg.pt source="https://ultralytics.com/images/bus.jpg" classes="person"

Para omitir por completo la descarga del codificador de texto durante la inferencia, incorpora las indicaciones a los pesos una vez y reutilízalas; consulta Reutilización de embeddings de indicaciones.

Descripción general de la arquitectura#

YOLOE mantiene la estructura YOLO estándar — un backbone convolucional para la extracción de características, un neck para la fusión multiescala y una cabeza desacoplada y sin anclajes que predice clases y cajas— y añade tres módulos, uno por cada modo de prompting:

• Alineación región-texto reparametrizable (RepRTA) refina los embeddings de texto de CLIP mediante una pequeña red auxiliar. Esta red se ejecuta una vez por cada llamada a set_classes() y se elimina al exportar mediante plegado, por lo que no añade ningún coste por fotograma. Lo que sí se ejecuta en cada pasada hacia delante es la comparación de los embeddings de las indicaciones almacenados con las características de las regiones; consulta Limitaciones para conocer el coste cuando se utiliza un conjunto grande de indicaciones.
• Codificador de indicaciones visuales activado semánticamente (SAVPE) codifica características semánticas y de activación a partir de una caja de ejemplo, condicionando el modelo en objetos con una apariencia similar. Esta es la ruta one-shot para objetivos difíciles de nombrar, como un logotipo o una pieza concreta.
• Contraste perezoso de indicaciones de región (LRPC) compara los embeddings de las regiones con un vocabulario integrado de 4585 nombres, de modo que los checkpoints sin indicaciones reconocen objetos sin una indicación externa y sin un codificador de texto.

La segmentación de instancias procede de una rama de máscaras en la cabeza de detección, como en YOLOv8-Seg, y cada predicción incluye una máscara en results[0].masks. Una vez que el modelo se exporta, los módulos de mundo abierto se reparametrizan en una cabeza YOLO estándar, por lo que el archivo exportado ejecuta la ruta normal de detección/segmentación.

Modelos disponibles#

Todos los checkpoints siguientes son modelos de segmentación de instancias y admiten val, predict, export y track. Carga un archivo *-seg.pt para prompting de texto o visual y un archivo *-seg-pf.pt para inferencia sin indicaciones; no son intercambiables. Consulta Elección del modo de prompting. Solo los archivos *-seg.pt admiten train; un checkpoint sin indicaciones se genera a partir de un modelo entrenado con indicaciones de texto. Consulta Entrenamiento de los modelos oficiales desde cero.

Rendimiento de YOLOE en LVIS#

Resultados zero-shot en LVIS minival a 640 píxeles, extraídos del artículo de Ultralytics YOLO26.

Indicaciones de texto y visuales#

Cada celda de precisión y parámetros se lee como indicación de texto / indicación visual; los FLOPs se indican una sola vez. Los parámetros y los FLOPs corresponden a la configuración de detección que evalúa el artículo. La precisión es la cifra Non-E2E del artículo, el único protocolo que presenta para todos los modelos de la comparación; la cabeza end-to-end de YOLOE-26 queda como máximo 1.1 AP por debajo con indicaciones de texto y 2.6 AP por debajo con indicaciones visuales.

Sin indicaciones#

Los checkpoints sin indicaciones responden utilizando su vocabulario integrado, sin proporcionar ninguna indicación. Cada celda de precisión se lee como end-to-end / Non-E2E, los dos protocolos con los que el artículo puntúa YOLOE-26; la página de YOLO26 cita la columna Non-E2E.

Con indicaciones de texto y visuales, los modelos YOLOE-26 superan a sus equivalentes YOLOE-11 y YOLOE-v8 en cada escala comparable en mAP_50-95, manteniéndose por debajo de la línea v8 en parámetros y FLOPs. En la misma partición, el artículo presenta YOLO-Worldv2 con 24.4 (S), 32.4 (M) y 35.5 (L), y los detectores basados en Transformer GLIP-T con 26.0, GDINO-T con 27.4 y DetCLIP-T con 34.4, cada uno con entre 155 y 232 M de parámetros. El artículo original de YOLOE añade dos resultados para los modelos a escala v8 que presenta. En LVIS, YOLOE-v8s supera a YOLO-Worldv2-S en 3.5 AP, con un tercio del coste de entrenamiento y una velocidad de inferencia 1.4 veces mayor. En COCO, YOLOE-v8l obtiene 0.6 box AP y 0.4 mask AP más que YOLOv8-L de conjunto cerrado, con casi 4 veces menos tiempo de entrenamiento.

Ejemplos de uso#

Todos los ejemplos de YOLOE siguientes se ejecutan mediante la API de Python. La predicción con indicaciones de texto, la validación, la exportación, el seguimiento y el entrenamiento normal también funcionan desde la CLI; las recetas de ajuste fino y el prompting visual pasan una clase de entrenador o predictor como argumento, algo que solo acepta la API de Python.

Uso del entrenamiento#

Ajusta cualquier checkpoint *-seg.pt publicado con tu propio conjunto de datos YOLO. Esto sigue en gran medida el procedimiento de entrenamiento YOLO estándar; la diferencia está en el entrenador que pasas. YOLOEPESegTrainer fusiona los nombres de tus clases en la cabeza y realiza el ajuste fino desde ahí, que es lo que necesitas para tus propias etiquetas; el entrenador predeterminado no entrena con los nombres de tus clases.

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEPESegTrainer

model = YOLOE("yoloe-26s-seg.pt")

results = model.train(
    data="coco128-seg.yaml",
    epochs=80,
    patience=10,
    trainer=YOLOEPESegTrainer,  # <- Important: the fine-tuning trainer, not the default
)

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEPETrainer

model = YOLOE("yoloe-26s.yaml").load("yoloe-26s-seg.pt")

results = model.train(data="coco128.yaml", epochs=80, patience=10, trainer=YOLOEPETrainer)

Uso de Predict#

La llamada con una solicitud de texto es la que se muestra en Inicio rápido. Cada uno de los otros dos modos necesita un argumento adicional:

import numpy as np

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEVPSegPredictor

model = YOLOE("yoloe-26l-seg.pt")

# One example box per target, each with its own class ID
visual_prompts = {
    "bboxes": np.array([[221.52, 405.8, 344.98, 857.54], [120, 425, 160, 445]]),  # person, glasses
    "cls": np.array([0, 1]),
}

results = model.predict(
    "ultralytics/assets/bus.jpg",
    visual_prompts=visual_prompts,
    predictor=YOLOEVPSegPredictor,
)
results[0].show()

import numpy as np

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEVPSegPredictor

model = YOLOE("yoloe-26l-seg.pt")

visual_prompts = {"bboxes": np.array([[221.52, 405.8, 344.98, 857.54]]), "cls": np.array([0])}  # person

results = model.predict(
    "ultralytics/assets/zidane.jpg",  # Target image
    refer_image="ultralytics/assets/bus.jpg",  # Where the example boxes live
    visual_prompts=visual_prompts,
    predictor=YOLOEVPSegPredictor,
)
results[0].show()

# refer_image also sets the classes permanently, so later calls need no prompts at all
results = model("ultralytics/assets/bus.jpg")
model.export(format="onnx")  # And the export keeps them

import numpy as np
import torch

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEVPSegPredictor

model = YOLOE("yoloe-11l-seg.pt")

img_tensor = torch.rand(1, 3, 480, 480)  # (1, 3, H, W) float tensor in [0, 1]
visual_prompts = {"bboxes": np.array([[10, 10, 50, 50]]), "cls": np.array([0])}

results = model.predict(
    img_tensor,
    refer_image=img_tensor,
    visual_prompts=visual_prompts,
    predictor=YOLOEVPSegPredictor,
    imgsz=640,
)

import numpy as np

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEVPSegPredictor

model = YOLOE("yoloe-26l-seg.pt")

visual_prompts = {
    "bboxes": [
        np.array([[221.52, 405.8, 344.98, 857.54], [120, 425, 160, 445]]),  # bus.jpg: person, glasses
        np.array([[150, 200, 1150, 700]]),  # zidane.jpg: person
    ],
    "cls": [np.array([0, 1]), np.array([0])],
}

results = model.predict(
    ["ultralytics/assets/bus.jpg", "ultralytics/assets/zidane.jpg"],
    visual_prompts=visual_prompts,
    predictor=YOLOEVPSegPredictor,
)
results[0].show()

Uso de Val#

La validación se ejecuta como en cualquier otro modelo sobre un conjunto de datos de segmentación:

from ultralytics import YOLOE

model = YOLOE("yoloe-26l-seg.pt")  # or yoloe-26s/m-seg.pt for other sizes

metrics = model.val(data="coco128-seg.yaml")

Dos variantes de la misma llamada cubren los otros modos de solicitud:

• Solicitudes visuales — model.val(data="coco128-seg.yaml", load_vp=True) extrae una representación vectorial visual por categoría del propio conjunto de datos. Añade refer_data="coco.yaml" para tomar las representaciones de otro conjunto de datos, que debe contener exactamente las mismas categorías.
• Sin solicitud — carga un checkpoint *-seg-pf.pt y pasa single_cls=True.

Uso de la exportación#

Las representaciones vectoriales de las solicitudes se pueden guardar una vez y reutilizar al generar exportaciones estáticas como ONNX, OpenVINO, TensorRT, CoreML, LiteRT y RKNN. El perfil NPZ lo carga el modelo PyTorch original antes de la exportación; no es una entrada adicional en tiempo de ejecución y el modelo exportado no necesita el archivo NPZ.

from ultralytics import YOLOE

model = YOLOE("yoloe-26n-seg.pt")
model.set_classes(["person", "bus"])
model.save_prompt_embeddings("person-bus.npz")

# The profile is bound to the source checkpoint and can be reused for later exports.
model = YOLOE("yoloe-26n-seg.pt")
model.load_prompt_embeddings("person-bus.npz")
model.export(format="onnx")

El mismo perfil de solicitud también puede configurar un modelo que solo realice detección, creado a partir de la arquitectura YOLOE correspondiente. Esto elimina la rama de máscaras y conserva las clases solicitadas:

from ultralytics import YOLOE

model = YOLOE("yoloe-26n.yaml").load("yoloe-26n-seg.pt")
model.load_prompt_embeddings("person-bus.npz")
model.export(format="rknn", name="rk3588", quantize=16)

Uso de Track#

Las clases solicitadas pasan directamente al seguimiento, por lo que puedes seguir objetos con los que el rastreador nunca se entrenó:

from ultralytics import YOLOE

model = YOLOE("yoloe-26s-seg.pt")
model.set_classes(["forklift", "pallet"])

# persist=True keeps track IDs stable across frames
for result in model.track("path/to/video.mp4", stream=True, persist=True):
    print(result.boxes.id)

Comparativa de YOLOE#

YOLOE se sitúa entre un detector de conjunto cerrado y un modelo de vocabulario abierto más pesado. Tres comparaciones determinan si es la opción adecuada:

• Frente a un YOLO de conjunto cerrado. Una vez establecidas las solicitudes, YOLOE predice mediante la ruta normal de detección/segmentación y se exporta como cualquier otro modelo. Lo que añade es la posibilidad de cambiar la lista de clases durante la inferencia en lugar de reentrenar; el coste es una precisión zero-shot muy inferior a la de un modelo entrenado con tus propias clases.
• Frente a las familias YOLOE anteriores. YOLOE-26 hereda la cabecera integral sin NMS de YOLO26 y cubre cinco escalas (n/s/m/l/x), frente a las tres anteriores (s/m/l), además de liderar en todas las escalas comparables en Rendimiento.
• Frente a los detectores de vocabulario abierto basados en Transformer. GLIP y OWL-ViT ejecutan un Transformer de visión-lenguaje durante la inferencia. YOLOE codifica las solicitudes una vez y después las compara con las características de región dentro de una cabecera convolucional.

Las alternativas más cercanas aceptan una solicitud de texto, pero solo YOLOE y SAM 3 devuelven máscaras, y los tres responden a preguntas distintas:

¿Vienes de YOLO-World? La API tiene la misma estructura: sustituye YOLOWorld por YOLOE, carga un checkpoint *-seg.pt y conserva tu llamada set_classes() tal cual. Obtienes máscaras y solicitudes visuales; la nota sobre la exportación relativa a las clases congeladas se aplica a ambos.

Casos de uso y aplicaciones#

La detección de vocabulario abierto elimina el paso de reentrenar para cada clase, lo que resulta especialmente importante cuando la lista de objetivos no se conoce de antemano:

• Detección en un mundo abierto — robótica y sistemas de seguridad que encuentran objetos que nadie enumeró durante el entrenamiento.
• Detección one-shot a partir de un ejemplo — las solicitudes visuales identifican una pieza, un logotipo o un defecto específico a partir de un único cuadro de referencia, algo útil en la inspección industrial.
• Catalogación de colas largas — el vocabulario integrado de 4.585 nombres es lo bastante amplio para campañas de monitorización de la biodiversidad o inventario minorista.
• Inicialización de conjuntos de datos — preetiqueta imágenes con cuadros y máscaras antes de la revisión humana y, después, entrena un modelo rápido de conjunto cerrado con el resultado.
• Segmentación de objetivos arbitrarios — los checkpoints *-seg.pt publicados devuelven una máscara con cada predicción, de modo que la imagen médica y el análisis por satélite obtienen resultados precisos a nivel de píxel sin un segundo modelo.

Un patrón habitual combina dos modos: ejecuta primero el modo sin solicitud para descubrir qué hay presente y, después, cambia a las solicitudes de texto para las categorías relevantes.

Limitaciones#

YOLOE intercambia precisión por la posibilidad de cambiar las clases durante la inferencia. Estas son las consecuencias que conviene conocer antes de comprometerte:

• La precisión zero-shot es muy inferior a la de un modelo entrenado con tus clases. Los checkpoints con solicitudes obtienen aproximadamente entre 22 y 40 mAP en LVIS minival; un YOLO de conjunto cerrado entrenado con tus propios datos superará ese resultado en esas clases. Recurre a YOLOE para cubrir clases para las que no puedes entrenar, no para sustituir el entrenamiento.
• Las categorías poco frecuentes son el punto débil. La columna mAP_r de Rendimiento informa de la precisión específicamente en las clases poco frecuentes de LVIS y, con solicitudes de texto, queda por debajo de las columnas de clases comunes y frecuentes en todas las filas. Consúltala en lugar del mAP principal cuando tus objetivos sean inusuales.
• Una solicitud describe la apariencia, no las relaciones. La detección funciona comparando las características de región con la representación vectorial de la solicitud, por lo que las solicitudes que dependen del estado, el contexto o la comparación —«dañado», «más a la izquierda», «el que están transportando»— no tienen un elemento fiable con el que establecer la correspondencia. Prefiere expresiones cercanas a los nombres de categorías habituales.
• Los conjuntos grandes de solicitudes aumentan la latencia. Las representaciones vectoriales de las solicitudes se calculan una vez, pero se comparan con las características de región en cada pasada hacia delante. Medida en CPU con yoloe-26s-seg.pt, una pasada hacia delante crece aproximadamente un 19 % al pasar de 80 a 1.203 clases y cerca de un 89 % con el vocabulario completo de 4.585 nombres. Los FLOPs indicados no cambian en absoluto porque la similitud región-texto no se contabiliza, por lo que el perfil no te avisará.
• Los nombres de clase son marcadores de posición hasta que envías una solicitud. Un checkpoint *-seg.pt recién cargado devuelve nc=80 con nombres numéricos ("0", "1", …), así que llama a set_classes() antes de leer las etiquetas. Los checkpoints sin solicitud ya incluyen todo el vocabulario.

Notas de implementación#

• Hardware. La inferencia necesita una GPU NVIDIA con entre 4 y 8 GB de VRAM; las escalas n y s funcionan en GPU de borde como Jetson o en CPU con una resolución reducida. El ajuste fino necesita una única GPU.
• NMS es agnóstica de clase por defecto. YOLOE predice con agnostic_nms=True. Por defecto, esto suprime las cajas superpuestas con menor puntuación entre diferentes clases en lugar de solo dentro de la misma clase, lo que evita duplicados cuando un objeto coincide con varias categorías. Con nms=False, YOLOE-26 no aplica supresión de IoU; el modo agnóstico solo mantiene la única mejor clase por anclaje en lugar de permitir que un anclaje emita varias etiquetas de clase. Pasa agnostic_nms=False para anularlo.
• Procesamiento por lotes. La inferencia por lotes funciona directamente y las solicitudes visuales pueden variar según la imagen en una misma llamada.

Entrenar los modelos oficiales desde cero#

La mayoría de los lectores nunca necesitará hacer esto. Reproduce los checkpoints de vocabulario abierto publicados a partir de Objects365, GQA y Flickr30k —aproximadamente 1,4 M de muestras de entrenamiento en 8× RTX 4090— y no está relacionado con el ajuste fino de tus propios datos, que se explica en Uso del entrenamiento más arriba.

El entrenamiento necesita anotaciones de segmentos. Puedes descargar los archivos procesados siguientes o generar los tuyos con el script proporcionado por el equipo oficial, basado en SAM 2.1. La validación utiliza LVIS minival.

El modelo con solicitudes de texto se entrena primero y los otros dos modos de solicitud son refinamientos de este:

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOESegTrainerFromScratch

data = {
    "train": {
        "yolo_data": ["Objects365.yaml"],
        "grounding_data": [
            {
                "img_path": "flickr/full_images/",
                "json_file": "flickr/annotations/final_flickr_separateGT_train_segm.json",
            },
            {
                "img_path": "mixed_grounding/gqa/images",
                "json_file": "mixed_grounding/annotations/final_mixed_train_no_coco_segm.json",
            },
        ],
    },
    "val": {"yolo_data": ["lvis.yaml"]},
}

model = YOLOE("yoloe-26l-seg.yaml")
model.train(
    data=data,  # or the path to a YAML file holding the same structure
    batch=128,
    epochs=30,
    close_mosaic=2,
    optimizer="AdamW",
    lr0=2e-3,
    warmup_bias_lr=0.0,
    weight_decay=0.025,
    momentum=0.9,
    workers=4,
    trainer=YOLOESegTrainerFromScratch,
    device="0,1,2,3,4,5,6,7",
)

Los checkpoints con solicitudes visuales y sin solicitud parten de ese modelo entrenado con solicitudes de texto y actualizan un módulo cada uno. YOLOESegVPTrainer es la receta de solicitud visual y YOLOEPEFreeTrainer la de modo sin solicitud, pero ninguno congela nada por sí mismo: el entrenamiento selectivo procede de la lista freeze que pasas junto con él, que especifica cada elemento secundario de la cabecera excepto savpe (respectivamente, cada torre de clasificación), y la ejecución sin solicitud necesita además single_cls=True. El repositorio original de YOLOE contiene las recetas completas para los modelos de escala v8.

Una ejecución sin solicitud terminada se reparametriza en un checkpoint que devuelve sus nombres sin ninguna solicitud durante la inferencia, utilizando get_vocab y set_vocab:

from ultralytics import YOLOE

# Weights written by the prompt-free run and by the text-prompt run it started from. Each
# rerun creates a new directory (train-2, train-3, ...), so take the paths the runs printed.
model = YOLOE("runs/segment/train-2/weights/best.pt")  # prompt-free run, its head is already fused
text_model = YOLOE("runs/segment/train/weights/best.pt")  # text-prompt run, its head is still unfused

names = list(YOLOE("yoloe-26l-seg-pf.pt").model.names.values())  # the 4,585-name vocabulary, or your own list
vocab = text_model.get_vocab(names)

model.set_vocab(vocab, names)
model.save("yoloe-26l-seg-pf-custom.pt")  # never overwrite the released checkpoint

Citas y agradecimientos#

Si YOLOE ha contribuido a tu investigación o proyecto, cita el artículo original de Ao Wang, Lihao Liu, Hui Chen, Zijia Lin, Jungong Han y Guiguang Ding, de la Universidad de Tsinghua:

@misc{wang2025yoloerealtimeseeing,
      title={YOLOE: Real-Time Seeing Anything},
      author={Ao Wang and Lihao Liu and Hui Chen and Zijia Lin and Jungong Han and Guiguang Ding},
      year={2025},
      eprint={2503.07465},
      archivePrefix={arXiv},
      primaryClass={cs.CV},
      url={https://arxiv.org/abs/2503.07465},
}

Para obtener más información, el artículo original de YOLOE está disponible en arXiv. Puedes acceder al código fuente del proyecto y a recursos adicionales a través de su repositorio de GitHub.

Preguntas frecuentes#