Comment les LLMs comprennent le son sans même avoir d’oreilles

On les imaginait cantonnés au texte. Pourtant, les grands modèles de langage (LLMs) planquent des talents d’audiophiles. Pas besoin de leur greffer des oreilles : ils analysent des spectrogrammes, reconnaissent des instruments, voire transcrivent des paroles… avec des performances qui font pâlir certains modèles spécialisés.

Le problème ? Personne ne leur a vraiment appris. C’est comme découvrir que votre chat sait jouer aux échecs après l’avoir observé pousser des pions avec sa patte. Sauf qu’ici, le chat pèse plusieurs milliards de paramètres et coûte des millions à entraîner.

Fondements techniques : quand le texte rencontre le son

1. La conversion audio → texte : le hack qui change tout

Les LLMs ne mangent pas des fichiers WAV au petit-déjeuner. Leur super-pouvoir repose sur une astuce simple : transformer le son en une représentation textuelle qu’ils peuvent ingurgiter.

Méthode 1 : Les spectrogrammes en ASCII art Des chercheurs ont eu l’idée saugrenue de convertir des spectrogrammes (ces images qui représentent les fréquences sonores) en caractères ASCII. Résultat : un LLM voit une grille de #, @ et espaces, et devine qu’il s’agit d’une note de piano. Oui, comme quand vous reconnaissiez des formes dans les nuages en CE2, mais en moins poétique.

Méthode 2 : Les embeddings audio quantifiés Plus sophistiqué : on encode les features audio (MFCC, mel-spectrogrammes) en tokens discrets via un autoencodeur. Le LLM traite ensuite ces tokens comme du texte. C’est l’équivalent de lui faire avaler une partition en morse.

Exemple concret :

# Extraction basique de MFCC avec librosa (pour les nostalgiques du DSP)
import librosa

y, sr = librosa.load("audio.wav")
mfcc = librosa.feature.mfcc(y=y, sr=sr, n_mfcc=13)
# Puis on quantifie ces features en tokens...

2. L’apprentissage implicite : le LLM comme détective sonore

Contrairement à un modèle audio dédié (type Whisper), les LLMs n’ont pas été explicitement entraînés sur des données sonores. Leur compétence vient de :

• Corpus contaminés : Des datasets comme Common Crawl contiennent des métadonnées audio (balises HTML de players, transcriptions, etc.).
• Alignement multimodal : Quand un LLM voit "[AUDIO: piano_C4.wav]" suivi de "Note: Do central", il fait le lien. Comme un enfant qui apprend le nom des couleurs en voyant des crayons étiquetés.
• Transfer learning accidentel : Les embeddings textuels capturent des patterns qui ressemblent à des structures audio. Un spectrogramme de parole a une "grammaire" proche d’un texte : motifs répétitifs, hiérarchie temporelle.

"C’est comme si on avait appris à un cuisinier à reconnaître les épices juste en lisant des recettes. Un jour, on lui donne une feuille de basilic à sentir, et hop : il sait de quoi il s’agit." — Un chercheur anonyme (et probablement fatigué).

3. Architectures clés : quand le texte rencontre le son

Deux approches dominent pour exploiter ce talent caché :

a. Adaptateurs légers (LoRA/Adapters) On greffe un petit module spécialisé sur un LLM existant. Exemple :

• Un encodeur audio (type CNN 1D) extrait des features.
• Un projet linéaire les convertit en embeddings compatibles avec le LLM.
• Le LLM traite ça comme du texte, avec 0.1% de paramètres en plus.

Avantage : Pas besoin de réentraîner le modèle de base. Inconvénient : Performances limitées par le goulot d’étranglement textuel.

b. Modèles joint text-audio (ex: AudioPaLM, VALLE) Ici, on fusionne carrément les modalités dès l’architecture :

• Un encodeur audio et un encodeur textuel partagent un espace latent commun.
• Le LLM est entraîné à prédire des tokens textuels et audio dans la même séquence.

Exemple d’architecture :

[AUDIO_TOKEN_1][AUDIO_TOKEN_2] → [TEXT_TOKEN_1] → [AUDIO_TOKEN_3]

C’est comme un traducteur simultané qui passerait du français à l’espagnol… mais en traduisant aussi les bruits de bouches.

Implémentation : comment bidouiller ça chez vous

1. La solution "quick & dirty" avec des embeddings

Pour tester sans casser votre budget GPU :

from transformers import AutoModelForMaskedLM, AutoTokenizer
import torch

# 1. On charge un LLM classique
model = AutoModelForMaskedLM.from_pretrained("bert-base-uncased")
tokenizer = AutoTokenizer.from_pretrained("bert-base-uncased")

# 2. On encode un spectrogramme en "texte" (version simplifiée)
def spectrogram_to_text(spectrogram):
    # Ici, on convertit chaque bande de fréquence en un caractère ASCII
    # (en vrai, utilisez un autoencodeur comme dans AudioLM)
    ascii_chars = ["@", "#", "=", "+", ";", ":", ".", " "]
    text = ""
    for row in spectrogram:
        for val in row:
            idx = int(val * (len(ascii_chars)-1))
            text += ascii_chars[idx]
        text += "\n"
    return text

# 3. Le LLM traite ça comme du texte normal
audio_text = spectrogram_to_text(mfcc)  # mfcc = votre spectrogramme
inputs = tokenizer(audio_text, return_tensors="pt")
outputs = model(**inputs)

Résultat attendu : Le modèle va "comprendre" des motifs comme des silences, des rythmes, ou des fréquences dominantes. Bon, il confondra probablement un violon avec une scie musicale, mais c’est un début.

2. La solution pro : fine-tuner un adaptateur

Pour ceux qui ont accès à un cluster (ou un compte AWS bien garni) :

# Exemple avec PEFT (Parameter-Efficient Fine-Tuning)
from peft import LoraConfig, get_peft_model

# 1. On ajoute des LoRA layers pour l'audio
lora_config = LoraConfig(
    r=8,
    lora_alpha=16,
    target_modules=["query", "value"],
    lora_dropout=0.1,
    bias="none",
    task_type="CAUSAL_LM"
)
model = get_peft_model(model, lora_config)

# 2. On entraîne sur des paires (audio_text, description)
# Dataset exemple: {"input": "[SPECTRO: piano_C4]", "output": "Note: Do central"}
# ...

Astuce : Utilisez des datasets comme AudioSet ou FSD50K, mais convertissez les labels en prompts textuels du type :

[AUDIO_START]
{ascii_spectrogram}
[AUDIO_END]
Description: {text_description}

3. Benchmark maison : évaluer les performances

Pour éviter de se faire avoir par du overfitting :

from datasets import load_dataset
import evaluate

# 1. Charger un dataset audio → texte (ex: Common Voice)
dataset = load_dataset("mozilla-foundation/common_voice_11_0", "fr", split="test")

# 2. Métriques clés
wer = evaluate.load("wer")  # Word Error Rate pour la transcription
accuracy = evaluate.load("accuracy")

def evaluate_audio_llm(model, dataset):
    errors = []
    for example in dataset[:100]:  # On teste sur 100 échantillons
        audio_text = spectrogram_to_text(example["audio"])  # À implémenter
        pred = model.generate(**tokenizer(audio_text, return_tensors="pt"))
        pred_text = tokenizer.decode(pred[0])
        errors.append(wer.compute(predictions=[pred_text], references=[example["sentence"]]))
    return sum(errors)/len(errors)

Attention : Les LLMs vont halluciner des transcriptions plausibles même sur du bruit. Toujours croiser avec une métrique comme le CLAP Score (Contrastive Language–Audio Pretraining) pour vérifier l’alignement sémantique.

Benchmarks : qui écoute le mieux ?

Modèle	Tâche	Performance (vs. spécialisé)	Latence	Paramètres
Whisper (base)	Transcription	100% (référence)	1x	74M
LLaMA-2 + LoRA	Transcription	~70% WER	3x	7B + 5M
AudioPaLM	Classification sonore	89% (vs. 92% pour AST)	2x	540M
VALLE	Synthèse vocale	4.1 MOS (vs. 4.3 pour VITS)	5x	300M

Observations :

• Les LLMs ne battent pas les modèles spécialisés (Whisper, AST, VITS) sur leur terrain.
• Mais ils généralisent mieux : un seul modèle pour transcrire, classifier, et générer du son.
• Leur force : les tâches composées (ex: "Décris ce son, puis génère un texte qui lui correspond").

"C’est comme comparer un couteau suisse à un scalpel. Le scalpel coupe mieux, mais le couteau suisse peut aussi ouvrir des bouteilles… et parfois, c’est utile." — Un ingénieur chez Mistral AI.

Limitations : pourquoi ça ne remplace pas Shazam (encore)

1. Le problème de la résolution temporelle

Un LLM traite des séquences de tokens. Or, le son a une granularité fine :

• 1 seconde de audio à 16kHz = 16,000 échantillons.
• 1 seconde de "texte audio" = ~10 tokens (si on compresse bien).

Résultat : Les détails (attaques de notes, bruits parasites) passent à la trappe. C’est comme essayer de décrire un tableau de Van Gogh en 140 caractères.

2. L’illusion de la compréhension

Les LLMs excellent à associer des motifs, pas à les comprendre. Exemple :

• Ils reconnaissent qu’un spectrogramme correspond à "une trompette" parce qu’ils ont vu 1000 fois cette association dans les données.
• Mais demandez-leur de distinguer une trompette en Do d’une en Do# : bonne chance.

Testez vous-même :

# Essayez de faire transcire ce son à un LLM :
# [Bruit de pas] → "Quelqu'un marche"
# [Bruit de pas + écho] → "Quelqu'un marche dans un couloir"
# [Mêmes pas + réverb] → "Quelqu'un marche dans une cathédrale"

Spoiler : Le modèle va inventer des scénarios plausibles, pas analyser l’acoustique.

3. Le coût énergétique absurde

Transcrire 1 heure d’audio avec Whisper :

• Énergie : ~0.01 kWh
• Coût : $0.002 (sur un A100)

Faire la même chose avec un LLaMA-70B + adaptateur :

• Énergie : ~2 kWh (oui, 200x plus)
• Coût : $0.40

Morale : Si vous voulez juste transcrire des réunions, achetez Whisper. Si vous voulez un modèle qui peut transcrire des réunions et écrire des poèmes sur le résultat, là, on parle.

Recherche & évolutions futures : vers des LLMs vraiment multimodaux

1. Les pistes chaudes

a. Tokens audio natifs Des équipes (Meta, Google) travaillent sur des vocabulaires audio : des tokens qui représentent directement des sons, comme les bytes pour le texte. L’idée :

• 1 token = 1 "phonème audio" (ex: un clic de langue, un do joué au violon).
• Le LLM prédit ces tokens comme il prédit des mots.

Avantage : Plus besoin de conversion ASCII bidon. Risque : Explosion de la taille du vocabulaire.

b. Cross-modal attention Au lieu de fusionner les modalités avant le LLM, on injecte des layers d’attention croisée :

• Le texte query les features audio, et vice-versa.
• Exemple : ImageBind mais pour audio + texte.

c. Prétraining sur des paires audio-texte alignées Aujourd’hui, les LLMs voient du texte et parfois des métadonnées audio. Demain : des datasets où chaque phrase est temporellement alignée avec un extrait sonore. Exemple :

[T=0.0s] [AUDIO: bruits_de_pas]
[T=0.5s] "J’entends quelqu’un arriver..."
[T=1.2s] [AUDIO: porte_qui_s’ouvre]

2. Les applications qui pourraient décoller

a. Audio augmentation pour le texte

• Générer des sound effects pour des scènes décrites en texte.
• Exemple : "Un orage éclate" → le LLM propose un sample de tonnerre + pluie.

b. Recherche sémantique dans l’audio

• Chercher "tous les podcasts où on parle de LLMs avec un ton enthousiaste" (en analysant prosodie + contenu).

c. Traduction directe parole→parole Aujourd’hui : parole → texte → texte → parole (4 étapes). Demain : parole → LLM multimodal → parole (2 étapes), avec moins de perte de nuances.

3. Les défis qui restent

• Bande passante : Comment compresser l’audio sans perdre linfo utile ?
• Alignement temporal : Comment synchroniser 10ms de son avec 1 token ?
• Évaluation : Les métriques comme WER ou CLAP sont-elles adaptées ?

FAQ

[Un LLM peut-il remplacer Whisper pour la transcription ?] Non, et ce n’est pas le but. Les LLMs transcrivent avec un WER 20-30% plus élevé que Whisper, mais ils excellent pour des tâches composées (ex: transcrire et résumer et traduire). Si vous voulez juste du texte à partir de voix, restez sur des modèles spécialisés.

[Comment évaluer un LLM sur des tâches audio ?] Utilisez un mix de métriques :

• WER (Word Error Rate) pour la transcription brute.
• CLAP Score pour l’alignement sémantique audio-texte.
• Accuracy sur des tâches de classification (ex: reconnaître un instrument). Et toujours tester sur des sons réels : les LLMs hallucinent moins sur de la parole claire que sur du bruit ambiant.

[Quels frameworks utiliser pour bidouiller ça ?] Pour prototyper rapidement :

• Transformers (HuggingFace) + PEFT pour les adaptateurs.
• Librosa ou TorchAudio pour le préprocessing audio.
• AudioSet ou Common Voice pour les datasets. Pour du sérieux : AudioPaLM (Google) ou VALLE (Microsoft) en base, avec des LoRA pour adapter à votre cas d’usage.