YOLOE : détection et segmentation à vocabulaire ouvert en temps réel#

Ultralytics YOLOE (voir tout en temps réel) est un modèle de détection à vocabulaire ouvert et de segmentation d’instances : au lieu d’une liste de classes définie à l’entraînement, il prend les catégories que tu souhaites au moment de l’inférence, sous forme d’invite textuelle, d’exemple visuel ou de vocabulaire intégré de 4 585 noms. Basé sur les architectures YOLO d’Ultralytics — YOLOv8, YOLO11 et YOLO26 — et inspiré de YOLO-World, YOLOE atteint une précision zéro-shot de pointe à une vitesse proche de celle de YOLO en ensemble fermé.

Démarrage rapide#

Nomme les classes souhaitées et lance l’inférence. YOLOE-26 renvoie des boîtes et des masques de segmentation d’instances pour des catégories sur lesquelles il n’a jamais été entraîné.

from ultralytics import YOLOE

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

# « double-decker bus » n’est pas une classe COCO ; YOLOE l’identifie à partir des seuls mots
model.set_classes(["double-decker bus", "person"])

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

Le premier appel à set_classes() télécharge un encodeur de texte ; consulte Installation et exigences avant de déployer sur une machine sans accès réseau.

Choisir un mode d’invite#

YOLOE prend en charge trois modes d’invite, et ton choix détermine le point de contrôle que tu charges ainsi que la forme des étiquettes de classe. Choisis la ligne correspondant à ce que tu peux fournir au moment de l’inférence.

Installation et exigences#

YOLOE est inclus dans le package principal Ultralytics :

pip install -U ultralytics

L’invite textuelle nécessite en plus un encodeur de texte, qui est téléchargé lors de la première utilisation plutôt qu’au moment de l’installation :

• Le premier appel à set_classes() installe ultralytics/CLIP depuis GitHub avec pip (qui fournit le tokenizer) et télécharge un encodeur de texte TorchScript dans le répertoire de travail actuel. YOLOE-26 récupère mobileclip2_b.ts, d’environ 254 Mo ; YOLOE-11 et YOLOE-v8 récupèrent mobileclip_blt.ts. Lance le téléchargement une fois depuis le répertoire où tu exécuteras le programme, ou copie le fichier à cet endroit ; sinon, il sera téléchargé à nouveau.
• Les deux étapes nécessitent un accès réseau : lance donc une prédiction avec invite avant de déployer sur une machine hors ligne ou isolée du réseau.
• Les invites visuelles et les points de contrôle sans invite n’ont pas du tout besoin d’un encodeur de texte.

Les points de contrôle YOLOE-26 nécessitent ultralytics 8.4.0 ou une version ultérieure ; les familles YOLOE-11 et YOLOE-v8 sont disponibles dans des versions antérieures. Une prédiction avec invite textuelle exécute l’ensemble du processus — téléchargement du point de contrôle, installation de CLIP, encodeur de texte, inférence :

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

Pour éviter complètement le téléchargement de l’encodeur de texte au moment de l’inférence, intègre les invites aux poids une fois et réutilise-les — consulte Réutiliser les embeddings d’invite.

Vue d’ensemble de l’architecture#

YOLOE conserve la structure YOLO standard — un backbone convolutif pour l’extraction des caractéristiques, un neck pour la fusion multi-échelle et une tête découplée sans ancres qui prédit les classes et les boîtes — et ajoute trois modules, un par mode d’invite :

• Alignement région-texte reparamétrable (RepRTA) affine les embeddings textuels issus de CLIP au moyen d’un petit réseau auxiliaire. Ce réseau s’exécute une fois par appel à set_classes() et est fusionné lors de l’exportation, sans coût par image. En revanche, la comparaison des embeddings d’invite stockés avec les caractéristiques des régions est effectuée à chaque passe avant ; consulte Limitations pour connaître le coût associé à un grand ensemble d’invites.
• Encodeur d’invite visuelle activée sémantiquement (SAVPE) encode les caractéristiques sémantiques et d’activation à partir d’une boîte d’exemple, en conditionnant le modèle sur des objets qui lui ressemblent. Il s’agit du processus en un seul exemple pour les cibles difficiles à nommer, comme un logo ou une pièce spécifique.
• Contraste régional d’invite différé (LRPC) compare les embeddings des régions à un vocabulaire intégré de 4 585 noms, afin que les points de contrôle sans invite reconnaissent les objets sans invite externe ni encodeur de texte.

La segmentation d’instances est assurée par une branche de masque sur la tête de détection, comme dans YOLOv8-Seg, et chaque prédiction inclut un masque sur results[0].masks. Une fois le modèle exporté, les modules à monde ouvert sont reparamétrés en une tête YOLO standard ; le fichier exporté suit donc le processus classique de détection/segmentation.

Modèles disponibles#

Chaque point de contrôle ci-dessous est un modèle de segmentation d’instances et prend en charge val, predict, export et track. Charge un fichier *-seg.pt pour les invites textuelles ou visuelles, et un fichier *-seg-pf.pt pour l’inférence sans invite ; ces fichiers ne sont pas interchangeables. Consulte Choisir un mode d’invite. Seuls les fichiers *-seg.pt prennent en charge train ; un point de contrôle sans invite est produit à partir d’un modèle entraîné avec des invites textuelles. Consulte Entraîner les modèles officiels à partir de zéro.

Performances de YOLOE sur LVIS#

Résultats zéro-shot sur le minival de LVIS, à 640 pixels, issus de l’article sur Ultralytics YOLO26.

Invites textuelles et visuelles#

Chaque cellule de précision et de paramètres indique invite textuelle / invite visuelle ; les FLOPs sont indiqués une seule fois. Les paramètres et les FLOPs correspondent à la configuration de détection évaluée dans l’article. La précision correspond au résultat Non-E2E de l’article, le seul protocole rapporté pour tous les modèles de la comparaison ; la tête end-to-end de YOLOE-26 obtient un résultat inférieur d’au plus 1,1 AP avec les invites textuelles et 2,6 AP avec les invites visuelles.

Sans invite#

Les points de contrôle sans invite fournissent des résultats à partir de leur vocabulaire intégré, sans invite fournie. Chaque cellule de précision indique end-to-end / Non-E2E, les deux protocoles utilisés dans l’article pour évaluer YOLOE-26 ; la page YOLO26 cite la colonne Non-E2E.

Avec des invites textuelles et visuelles, les modèles YOLOE-26 devancent leurs équivalents YOLOE-11 et YOLOE-v8 à chaque échelle correspondante en mAP_50-95, tout en ayant moins de paramètres et de FLOPs que la gamme v8. Sur le même sous-ensemble, l’article rapporte 24.4 (S), 32.4 (M) et 35.5 (L) pour YOLO-Worldv2, ainsi que 26.0 pour GLIP-T, 27.4 pour GDINO-T et 34.4 pour DetCLIP-T, des détecteurs basés sur Transformer qui comptent chacun entre 155 et 232 M de paramètres. L’article original sur YOLOE ajoute deux résultats pour les modèles à l’échelle v8 qu’il a présentés. Sur LVIS, YOLOE-v8s surpasse YOLO-Worldv2-S de 3.5 AP avec un tiers du coût d’entraînement et une vitesse d’inférence 1.4× supérieure. Transféré sur COCO, YOLOE-v8l gagne 0.6 box AP et 0.4 mask AP par rapport à YOLOv8-L en détection à classes fixes, avec près de 4× moins de temps d’entraînement.

Exemples d'utilisation#

Chaque exemple YOLOE ci-dessous s’exécute avec l’API Python. La prédiction avec invite textuelle, la validation, l’exportation, le suivi et l’entraînement standard fonctionnent aussi avec la CLI; les recettes de réglage fin et l’invite visuelle transmettent une classe de trainer ou de prédicteur en argument, ce que seule l’API Python accepte.

Utilisation de l’entraînement#

Ajuste n’importe quel point de contrôle *-seg.pt publié sur ton propre jeu de données YOLO. Cette opération suit globalement la procédure standard d’entraînement YOLO; la différence tient au trainer que tu transmets. YOLOEPESegTrainer fusionne les noms de tes classes dans la tête, puis effectue le réglage fin à partir de là; c’est ce qu’il te faut pour tes propres étiquettes. Le trainer par défaut n’entraîne pas le modèle avec tes noms de classes.

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 : le trainer de réglage fin, pas celui par défaut
)

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)

Utilisation pour la prédiction#

L’appel avec invite textuelle est celui présenté dans Démarrage rapide. Les deux autres modes nécessitent chacun un argument supplémentaire :

import numpy as np

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

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

# Une boîte d’exemple par cible, chacune avec son propre identifiant de classe
visual_prompts = {
    "bboxes": np.array([[221.52, 405.8, 344.98, 857.54], [120, 425, 160, 445]]),  # personne, lunettes
    "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",  # Image cible
    refer_image="ultralytics/assets/bus.jpg",  # Emplacement des boîtes d’exemple
    visual_prompts=visual_prompts,
    predictor=YOLOEVPSegPredictor,
)
results[0].show()

# refer_image définit aussi les classes de façon permanente, donc les appels suivants ne nécessitent aucune invite
results = model("ultralytics/assets/bus.jpg")
model.export(format="onnx")  # Et l’exportation les conserve

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) tenseur float dans [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 : personne, lunettes
        np.array([[150, 200, 1150, 700]]),  # zidane.jpg : personne
    ],
    "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()

Utilisation pour la validation#

La validation s’effectue comme avec n’importe quel autre modèle, sur un jeu de données de segmentation :

from ultralytics import YOLOE

model = YOLOE("yoloe-26l-seg.pt")  # ou yoloe-26s/m-seg.pt pour les autres tailles

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

Deux variantes du même appel couvrent les autres modes d’invite :

• Invites visuelles — model.val(data="coco128-seg.yaml", load_vp=True) extrait une représentation visuelle par catégorie directement du jeu de données. Ajoute refer_data="coco.yaml" pour récupérer les représentations depuis un autre jeu de données, qui doit contenir exactement les mêmes catégories.
• Sans invite — charge un point de contrôle *-seg-pf.pt et transmets single_cls=True.

Utilisation de l’exportation#

Les représentations des invites peuvent être enregistrées une fois, puis réutilisées lors de la création d’exportations statiques telles que ONNX, OpenVINO, TensorRT, CoreML, LiteRT et RKNN. Le profil NPZ est chargé par le modèle PyTorch d’origine avant l’exportation; il ne constitue pas une entrée supplémentaire à l’exécution, et le modèle exporté n’a pas besoin du fichier NPZ.

from ultralytics import YOLOE

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

# Le profil est lié au point de contrôle source et peut être réutilisé pour les exportations suivantes.
model = YOLOE("yoloe-26n-seg.pt")
model.load_prompt_embeddings("person-bus.npz")
model.export(format="onnx")

Le même profil d’invites peut aussi configurer un modèle de détection uniquement, créé à partir de l’architecture YOLOE correspondante. Cela supprime la branche de masque tout en conservant les classes définies par les invites :

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)

Suivi d’utilisation#

Les classes définies par les invites sont directement utilisables pour le suivi, ce qui te permet de suivre des objets sur lesquels le tracker n’a jamais été entraîné :

from ultralytics import YOLOE

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

# persist=True conserve la stabilité des identifiants de suivi d’une image à l’autre
for result in model.track("path/to/video.mp4", stream=True, persist=True):
    print(result.boxes.id)

Comparaison de YOLOE#

YOLOE se situe entre un détecteur à classes fixes et un modèle à vocabulaire ouvert plus lourd. Trois comparaisons permettent de déterminer si c’est le bon choix :

• Par rapport à un YOLO à classes fixes. Une fois les invites définies, YOLOE effectue les prédictions avec le processus habituel de détection/segmentation et s’exporte comme tout autre modèle. Il permet de modifier la liste des classes au moment de l’inférence plutôt que de réentraîner le modèle; en revanche, sa précision en zéro-shot est bien inférieure à celle d’un modèle entraîné sur tes propres classes.
• Par rapport aux familles YOLOE précédentes. YOLOE-26 hérite de la tête de bout en bout sans NMS de YOLO26 et couvre cinq échelles (n/s/m/l/x) contre trois auparavant (s/m/l); il est aussi en tête à chaque échelle correspondante dans Performances.
• Par rapport aux détecteurs à vocabulaire ouvert basés sur Transformer. GLIP et OWL-ViT exécutent un Transformer vision-langage au moment de l’inférence. YOLOE encode les invites une seule fois, puis les compare aux caractéristiques des régions dans une tête convolutive.

Les solutions de remplacement les plus proches acceptent toutes une invite textuelle, mais seuls YOLOE et SAM 3 renvoient des masques, et les trois répondent à des besoins différents :

Tu viens de YOLO-World ? L’API suit le même modèle : remplace YOLOWorld par YOLOE, charge un point de contrôle *-seg.pt et conserve ton appel set_classes() tel quel. Tu bénéficies des masques et des invites visuelles; la note sur l’exportation concernant les classes figées s’applique aux deux.

Cas d’utilisation et applications#

La détection à vocabulaire ouvert supprime l’étape de réentraînement pour chaque classe; c’est particulièrement utile lorsque la liste des cibles n’est pas connue à l’avance :

• Détection en environnement ouvert — la robotique et les systèmes de sécurité rencontrent des objets qui n’avaient pas été répertoriés au moment de l’entraînement.
• Détection en un seul exemple — les invites visuelles repèrent une pièce, un logo ou un défaut précis à partir d’une seule boîte de référence, ce qui est utile pour l’inspection industrielle.
• Catalogage des longues traînes — le vocabulaire intégré de 4 585 noms est assez vaste pour les campagnes de surveillance de la biodiversité ou d’inventaire des stocks au détail.
• Amorçage de jeux de données — préannote les images avec des boîtes et des masques avant la vérification humaine, puis entraîne un modèle rapide à classes fixes sur le résultat.
• Segmentation de cibles quelconques — les points de contrôle *-seg.pt publiés renvoient un masque avec chaque prédiction; l’imagerie médicale et l’analyse satellitaire obtiennent ainsi des résultats précis au pixel près sans modèle supplémentaire.

Une approche courante consiste à combiner deux modes : exécuter une fois le mode sans invite pour découvrir les éléments présents, puis passer aux invites textuelles pour les catégories qui comptent.

Limites#

YOLOE sacrifie de la précision pour permettre de modifier les classes au moment de l’inférence. Voici les conséquences à connaître avant de te décider :

• La précision en zéro-shot est bien inférieure à celle d’un modèle entraîné sur tes classes. Les points de contrôle avec invites se situent autour de 22-40 mAP sur LVIS minival; un YOLO à classes fixes entraîné sur tes propres données obtiendra de meilleurs résultats sur ces classes. Choisis YOLOE pour couvrir les classes sur lesquelles tu ne peux pas entraîner le modèle, et non pour remplacer l’entraînement.
• Les catégories rares sont le point faible. La colonne mAP_r de la section Performances indique la précision sur les classes rares de LVIS en particulier; avec des invites textuelles, cette valeur est inférieure à celles des colonnes des classes courantes et fréquentes dans chaque ligne. Consulte-la plutôt que la mAP principale si tes cibles sont inhabituelles.
• Une invite décrit une apparence, pas des relations. La détection compare les caractéristiques des régions à la représentation de l’invite; les invites qui dépendent d’un état, d’un contexte ou d’une comparaison — « endommagé », « le plus à gauche », « celui qu’on transporte » — ne fournissent donc aucun repère fiable à rechercher. Privilégie des formulations proches des noms de catégories courants.
• Les grands ensembles d’invites augmentent la latence. Les représentations des invites sont calculées une fois, mais elles sont comparées aux caractéristiques des régions à chaque propagation avant. Mesurée sur CPU avec yoloe-26s-seg.pt, la durée d’une propagation avant augmente d’environ 19 % en passant de 80 à 1 203 classes, et d’environ 89 % avec le vocabulaire complet de 4 585 noms. Le nombre de FLOPs rapporté ne varie pas, car la similarité entre régions et texte n’est pas prise en compte; le profil ne t’avertira donc pas.
• Les noms de classes sont des espaces réservés tant que tu n’as pas défini d’invites. Un point de contrôle *-seg.pt chargé fraîchement renvoie nc=80 avec des noms numériques ("0", "1", …); appelle donc set_classes() avant de lire les étiquettes. Les points de contrôle sans invite contiennent déjà l’ensemble du vocabulaire.

Notes sur le déploiement#

• Matériel. L’inférence nécessite un GPU NVIDIA avec 4 à 8 Go de VRAM; les modèles n et s fonctionnent sur des GPU embarqués tels que Jetson ou sur CPU à résolution réduite. Le réglage fin nécessite un seul GPU.
• Par défaut, NMS est indépendant des classes. YOLOE effectue ses prédictions avec agnostic_nms=True. Par défaut, cette opération supprime les boîtes superposées ayant un score inférieur entre différentes classes, plutôt que seulement au sein d’une même classe; cela évite les doublons lorsqu’un objet correspond à plusieurs catégories. Avec nms=False, YOLOE-26 n’applique aucune suppression selon l’IoU; le mode indépendant des classes conserve uniquement la meilleure classe pour chaque ancre, au lieu de permettre à une ancre d’émettre plusieurs étiquettes de classe. Transmets agnostic_nms=False pour modifier ce comportement.
• Traitement par lots. L’inférence par lots fonctionne directement, et les invites visuelles peuvent varier d’une image à l’autre au sein d’un même appel.

Entraîner les modèles officiels à partir de zéro#

La plupart des lecteurs n’en ont pas besoin. Cette procédure reproduit les points de contrôle publiés à vocabulaire ouvert à partir d’Objects365, GQA et Flickr30k — environ 1,4 M d’échantillons d’entraînement sur 8× RTX 4090 — et n’a aucun rapport avec le réglage fin sur tes propres données, traité dans la section Utilisation de l’entraînement ci-dessus.

L’entraînement nécessite des annotations de segmentation. Télécharge les fichiers traités ci-dessous ou génère les tiens à l’aide du script fourni par l’équipe officielle, qui s’appuie sur SAM 2.1. La validation utilise LVIS minival.

Le modèle avec invite textuelle est entraîné en premier; les deux autres modes d’invite en sont des versions affinées :

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,  # ou le chemin vers un fichier YAML contenant la même 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",
)

Les points de contrôle à invite visuelle et sans invite partent de ce modèle entraîné avec des invites textuelles et mettent à jour un module chacun. YOLOESegVPTrainer est la recette pour les invites visuelles et YOLOEPEFreeTrainer celle sans invite, mais aucune de ces classes ne gèle quoi que ce soit à elle seule : l’entraînement sélectif provient de la liste freeze que tu lui transmets, qui nomme tous les sous-modules de la tête sauf savpe (ou toutes les tours de classification), et l’exécution sans invite nécessite en plus single_cls=True. Le dépôt YOLOE en amont contient les recettes complètes pour les modèles à l’échelle v8.

Une exécution sans invite terminée est reparamétrée en un point de contrôle qui indique ses noms sans invite lors de l’inférence, à l’aide de get_vocab et set_vocab :

from ultralytics import YOLOE

# Poids écrits par l’exécution sans invite et par l’exécution avec invite textuelle dont elle est issue. Chaque
# nouvelle exécution crée un nouveau répertoire (train-2, train-3, ...), alors utilise les chemins indiqués par les exécutions.
model = YOLOE("runs/segment/train-2/weights/best.pt")  # exécution sans invite, sa tête est déjà fusionnée
text_model = YOLOE("runs/segment/train/weights/best.pt")  # exécution avec invite textuelle, sa tête n’est pas encore fusionnée

names = list(YOLOE("yoloe-26l-seg-pf.pt").model.names.values())  # le vocabulaire de 4 585 noms, ou ta propre liste
vocab = text_model.get_vocab(names)

model.set_vocab(vocab, names)
model.save("yoloe-26l-seg-pf-custom.pt")  # ne jamais écraser le point de contrôle publié

get_vocab renvoie la branche sélectionnée par l’indicateur end2end du modèle, et set_vocab reparamètre cette branche. Les fichiers YOLOE-26 publiés contiennent plutôt un vocabulaire par branche, ce qui permet à nms de choisir entre elles ; reproduis ce comportement en récupérant le deuxième vocabulaire depuis une autre copie du modèle avec invite textuelle. YOLOE-11 et YOLOE-v8 ont une seule branche : ils utilisent donc l’appel ci-dessus sans modification.

one2one_model = YOLOE("runs/segment/train/weights/best.pt")  # get_vocab fusionne la tête qu’il lit, alors charge une deuxième copie
one2one_model.model.end2end = True  # lire la branche sans NMS

model.set_vocab(vocab, names, one2one_vocab=one2one_model.get_vocab(names))

Citations et remerciements#

Si YOLOE a contribué à ta recherche ou à ton projet, cite l’article original de Ao Wang, Lihao Liu, Hui Chen, Zijia Lin, Jungong Han et Guiguang Ding de l’Université 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},
}

Pour en savoir plus, l’article original YOLOE est disponible sur arXiv. Le code source du projet et des ressources supplémentaires sont accessibles via son dépôt GitHub.

FAQ#