Bootstrapping d'embeddings audio à partir de LLM multimodaux

jina-ai/audio-embedding-kickstarter

GitHubjina-ai

Google a récemment publié Gemini Embedding 2, son premier modèle d'embeddings nativement multimodal. Texte, images, vidéo, audio, documents, tous sont mappés dans un seul espace vectoriel de 3072 dimensions. Cela s'inscrit dans une tendance plus large vers les **modèles d'embeddings omni** : des modèles unifiés qui gèrent toutes les modalités dans une seule architecture, de jina-embeddings-v4 à Omni-Embed-Nemotron en passant par Omni-5.

Ce qui a attiré notre attention, c'est l'audio. La plupart des gens entendent « embedding multimodal » et pensent aux images, voire à la vidéo. L'audio est la modalité oubliée : plus difficile à collecter, plus difficile à étiqueter, avec moins de personnes travaillant dessus. Chez Jina AI, nous avons exploré précisément ce problème, en construisant de petits modèles d'embeddings audio (moins de 1,2 milliard de paramètres) dans le cadre de nos travaux sur les modèles omni. La sortie de Gemini Embedding 2 est le moment idéal pour partager ce que nous avons appris en chemin.

向量模型 audio (Embeddings audio)

Un embedding audio est une représentation vectorielle de longueur fixe d'un clip audio. À partir d'une forme d'onde brute, le modèle produit un vecteur dense (généralement de 768 à 3072 dimensions) qui capture le contenu sémantique du son. Deux clips ayant une signification similaire produisent des embeddings similaires, et un clip audio se situe à proximité de sa description textuelle dans l'espace d'embedding partagé. C'est une pièce du puzzle des modèles omni : une fois que vous pouvez intégrer l'audio aux côtés du texte et des images dans le même espace vectoriel, vous débloquez la recherche cross-modale sur toutes les modalités.

L'approche dominante depuis 2022 est le Contrastive Language-Audio Pretraining (CLAP), qui étend CLIP à l'audio. LAION-CLAP a mis cela à l'échelle avec 630 000 paires et une fusion de caractéristiques. La variante la plus performante (Elizalde et al., 2023) a été entraînée sur 4,6 millions de paires en utilisant un encodeur audio sur 22 tâches audio diverses associées à un décodeur autorégressif, atteignant 42,0 cvR@5 sur AudioCaps avec 250 millions de paramètres.

Nous avons pris une route différente : transformer les LLM multimodaux qui comprennent déjà l'audio en modèles d'embeddings.

Architecture

Tout d'abord, ce qui entre et ce qui sort. L'entrée est de l'audio brut : une forme d'onde décodée à partir de n'importe quel format standard (WAV, MP3, FLAC) et rééchantillonnée en mono à 16 kHz. L'encodeur audio convertit cette forme d'onde en un spectrogramme log-mel à 128 bandes, puis le traite en une séquence de tokens de caractéristiques à un rythme d'environ 150 tokens par seconde. Un clip de 10 secondes devient environ 1 500 tokens. La longueur d'entrée maximale est de 30 secondes ; l'audio plus long doit être découpé en segments. La sortie est un vecteur dense unique (l'embedding), généralement de 896 à 3584 dimensions selon la taille de l'architecture du LLM.

Nous partons de Qwen2.5-Omni, un LLM multimodal doté d'une compréhension audio native. Trois composants : un encodeur audio (~0,6-0,8 milliard de paramètres) qui convertit les formes d'onde en vecteurs de caractéristiques via une projection linéaire de ~4,5 millions, une architecture LLM (0,5-7 milliards de paramètres) qui traite à la fois les caractéristiques audio et les tokens textuels, chaque couche de transformer ajoutant environ 0,2 milliard de paramètres, et une couche de pooling qui effectue un pooling moyen du dernier état caché en un seul vecteur d'embedding. Les deux modalités partagent la même architecture LLM, elles sont donc déjà approximativement alignées dès le pré-entraînement.

L'objectif d'entraînement est la perte contrastive InfoNCE. Chaque modalité est encodée indépendamment, la perte est calculée dans les deux sens et moyennée :

def training_step(audio_batch, text_batch):
    audio_embeds = model.encode_audio(audio_batch)  # [B, D]
    text_embeds = model.encode_text(text_batch)      # [B, D]
    
    audio_embeds = F.normalize(audio_embeds, dim=-1)
    text_embeds = F.normalize(text_embeds, dim=-1)
    
    sim = audio_embeds @ text_embeds.T / temperature  # [B, B]
    labels = torch.arange(len(sim), device=sim.device)
    loss = (F.cross_entropy(sim, labels) + 
            F.cross_entropy(sim.T, labels)) / 2
    return loss
Copier

Données d'entraînement

Cinq jeux de données de paires audio-texte, soit 181 000 échantillons au total :

CLAP a utilisé l'intégralité d'AudioSet (plus de 2 millions d'audios) ainsi que d'autres sources totalisant 4,6 millions de paires. Nous n'utilisons qu'AudioSetStrong (~100 000). Partir d'un MLLM pré-entraîné réduit considérablement la quantité de données nécessaires.

def load_sample(audio_path, caption):
    waveform, sr = torchaudio.load(audio_path)
    waveform = torchaudio.transforms.Resample(sr, 16000)(waveform)
    audio_inputs = processor.feature_extractor(
        waveform, sampling_rate=16000, return_tensors="pt"
    )
    text_inputs = processor.tokenizer(caption, padding=True, return_tensors="pt")
    return audio_inputs, text_inputs
Copier

Quatre approches

Objectif : un modèle d'embedding audio de moins de 1,2 milliard de paramètres qui surpasse CLAP.

**Ajustement fin complet du modèle.** Qwen2.5-Omni-7B sur des paires audio-texte : AudioCaps T2A cvR@5 = 63,2, Clotho T2A = 39,2. C'est la limite supérieure, mais 7B n'est pas déployable. Tevatron 2.0 a également été ajusté sur AudioCaps seul (61,2 mais seulement 11,9 sur Clotho, montrant une faible généralisation à partir d'un entraînement sur un seul jeu de données). ColQwen-Omni a été ajusté sur des tâches visuelles-documents sans aucune donnée audio, atteignant 37,4 grâce au transfert cross-modal.

**Élagage de couches (Layer pruning).** Suppression de couches transformer du modèle 7B. Chaque couche fait environ 0,2 milliard de paramètres, donc un modèle à 10 couches compte environ 3,5 milliards de paramètres au total.

La taille des lots (32, 64, 128) n'a pas fait de différence significative. Des lots plus grands aident initialement mais peuvent dégrader les performances plus tard : un lot de 128 a atteint 31,3 NDCG à 2 000 étapes sur Clotho mais est retombé à 29,3 à 10 000 étapes.

**Transfert de modalité text-only.** Ajustement fin uniquement sur des paires de textes (MultiNLI, SNLI, FEVER, SciFact), en s'appuyant sur l'alignement cross-modal pré-entraîné. Cela a fonctionné sur le modèle 7B complet (AudioCaps 46,1, battant les 42,0 de CLAP) mais a complètement échoué sur le modèle élagué à 10 couches (cvR@5 = 5,9). Les connexions cross-modales sont distribuées sur l'ensemble du réseau et ne survivent pas à l'élagage.

**Combinaison de modules.** La percée : prendre un encodeur audio d'un modèle et un SLM d'un autre, même entre différentes familles de modèles. Qwen2.5-Omni s'entraîne en trois étapes : (1) encodeurs audio/vision avec LLM gelé, (2) tous les paramètres dégelés, (3) contexte de 32K. Nous combinons des modules de différentes étapes :

Détail d'implémentation : Qwen3-Omni utilise Qwen3OmniMoePreTrainedModel tandis que le modèle Qwen3 autonome utilise Qwen3ForCausalLM. Nous initialisons une structure de modèle Omni avec des dimensions correspondantes et copions les poids aux emplacements appropriés.

Évaluation

L'évaluation des embeddings audio repose fondamentalement sur la qualité de la recherche : étant donné une requête textuelle, le modèle peut-il trouver le bon clip audio ? Le défi majeur est que ce qui est « bon » dépend du jeu de données. AudioCaps contient des descriptions concrètes (« un homme qui parle suivi d'une porte qui se ferme »), tandis que Clotho a des légendes abstraites (« une atmosphère calme avec un grondement lointain »). Un modèle qui mémorise les caractéristiques audio de surface réussira bien sur AudioCaps mais peinera sur Clotho. Nous nous intéressons principalement à la généralisation entre les différents styles de description.

CV-Recall@5 (cvR@5) : pour chaque requête textuelle, vérifie si un clip audio correct apparaît dans les 5 premiers résultats. Score binaire moyenné sur l'ensemble des requêtes. Métrique standard dans la recherche audio MTEB.

def evaluate_cvr_at_k(model, dataset, k=5):
    audio_embeds = model.encode_audio(dataset.audio_clips)
    text_embeds = model.encode_text(dataset.text_queries)
    sim = F.normalize(audio_embeds) @ F.normalize(text_embeds).T
    
    hits = 0
    for i in range(len(dataset.text_queries)):
        top_k = sim[:, i].argsort(descending=True)[:k]
        if dataset.ground_truth[i] in top_k:
            hits += 1
    return hits / len(dataset.text_queries)
Copier

Trois jeux de données d'évaluation issus de MTEB : AudioCaps (dérivé de vidéos, légendes humaines), AudioSetStrong (étiqueté temporellement, descriptions GPT), Clotho (légendes diverses et abstraites). CLAP a utilisé l'intégralité d'AudioSet (plus de 2M) alors que nous avons utilisé AudioSetStrong (~100K), ce qui explique en partie l'avantage de CLAP sur ce benchmark.

Applications

Les embeddings audio deviennent pertinents au-delà de la recherche traditionnelle. Dans les systèmes d'agents, les embeddings audio permettent le routage d'intention : un agent recevant une entrée vocale peut vectoriser l'audio et l'orienter vers le bon outil ou sous-agent en fonction de la similarité sémantique, sans attendre la transcription complète. La classification d'événements sonores alimente la surveillance en temps réel dans les environnements industriels, l'automatisation de la maison intelligente et les systèmes de sécurité. Dans les flux de travail d'agents multimodaux, les embeddings audio permettent aux agents de rechercher, comparer et raisonner sur le contenu audio de la même manière qu'ils traitent déjà le texte et les images. Les applications de musique et de médias les utilisent pour la recherche par similarité, la détection de droits d'auteur et la recommandation de contenu. À mesure que les interfaces vocales deviennent le mode d'interaction par défaut pour les agents d'IA, des embeddings audio compacts fonctionnant localement sur l'appareil deviennent cruciaux pour des applications à faible latence et respectueuses de la vie privée.

Conclusions

Partir d'un MLLM pré-entraîné est le levier le plus important. Il offre un alignement cross-modal, un encodeur de texte puissant et un encodeur audio performant, le tout dans un seul ensemble. La combinaison de modules est la direction la plus prometteuse : mélanger des encodeurs audio et des LLM issus de différents modèles et étapes d'entraînement ouvre un espace de conception encore peu exploré. Nos modèles dominent AudioCaps mais égalent seulement CLAP sur Clotho, dont les descriptions abstraites révèlent des faiblesses qu'AudioCaps ne permet pas de détecter. Le transfert cross-modal ne survit pas à la compression de modèle.

Ce travail est une étape vers le modèle d'embedding « omni » : un modèle unique qui vectorise le texte, les images, l'audio, la vidéo et les documents dans un espace de recherche unifié. L'approche par combinaison de modules montre qu'il est possible d'amorcer de nouvelles modalités efficacement en réutilisant des composants pré-entraînés. Les prochaines étapes incluent des architectures MoE avec <500M de paramètres d'activation, l'association de la combinaison de modules au transfert de modalité, et l'augmentation des données avec WavCaps, MusicCaps et des jeux de données de parole.