Conception d'un Système de Tags Multilingue Basé sur des Clés Sémantiques

Le marquage automatique de centaines de milliers de chansons peut sembler être une simple écriture de chaînes de caractères, mais lorsqu’on recherche une cohérence ultime des données et un support multilingue, on se heurte souvent à des refontes extrêmement douloureuses. La naissance de l’architecture de marquage de troisième génération (V3) d’AI Music Organizer visait spécifiquement à mettre fin aux dilemmes causés par la confusion des responsabilités dans les architectures précédentes.

I. Pourquoi les Architectures de Tags Traditionnelles Échouent

Dans les pipelines d’implémentation passés, nous mélangions plusieurs responsabilités complètement différentes :

1. La valeur brute générée par le classificateur (ex. : le modèle crache “Rock”).
2. La Key utilisée pour les comparaisons internes du système.
3. La chaîne finale réécrite dans le fichier (ID3/FLAC).
4. Le texte d’affichage localisé de l’interface utilisateur.

Cela entraînait de graves points de friction commerciaux :

• Keys Instables : Les caractères spéciaux comme /, , et & étaient réécrits à plusieurs reprises au cours du processus d’assainissement, faisant en sorte que le même tag devienne des chaînes différentes à travers différents pipelines.
• Réécritures Redondantes par Erreur : Lorsque le tag du fichier audio sous-jacent est en réalité déjà “摇滚” (Rock en chinois) et que le moteur d’analyse produit “Rock”, une simple comparaison de chaînes générerait un Patch redondant (demandant de passer de “摇滚” à “Rock”).
• Difficulté de Personnalisation : Parce que “la chaîne assainie était la clé”, lorsque les utilisateurs souhaitaient mapper de force les tags originaux anglais vers leur langue maternelle, la logique devenait très fragile.

II. Le Cœur de l’Architecture V3 : Semantic Keys

Dans l’architecture V3, nous avons introduit le concept de la Clé Sémantique (Semantic Key), en séparant explicitement les quatre responsabilités ci-dessus :

1. Les Clés Sémantiques deviennent l’Unique Source de Vérité
Le système interne ne se soucie plus de la chaîne “摇滚” elle-même. Toutes les comparaisons et tous les flux sont entièrement basés sur la ligne de base stable fournie par le classificateur (c’est-à-dire la raw classifier value). Pour les données fortement en cascade (ex. : Funk / Soul---Contemporary R&B), nous avons abandonné l’assainissement global, en les divisant simplement en Clés Sémantiques indépendantes pour le Genre et le Style.

2. Stockage à Deux Niveaux avec Mappage de Localisation (Locale)
Nous avons structuré la base de données avec tag_value_catalog (la table sémantique principale) et tag_value_locale (la table de mappage multilingue) :

• Catalog se soucie uniquement de “Quel est ce concept de tag ?” (ex. : id: 12, semantic_key: 'Rock').
• Locale se soucie de la façon de rendre ce concept sémantique sous diverses localisations telles que l’anglais, le chinois, le japonais, etc. (ex. : display_value: 'Rock', write_value: 'Rock').

[!IMPORTANT]

• Les Clés Sémantiques n’assument pas de responsabilités d’affichage.
• Les mappages Locale n’assument pas de responsabilités d’Identité (reconnaissance unique).

III. L’Art de Comparer : Quand Faut-il Vraiment Réécrire ?

Sous l’architecture V3, la décision de “savoir si nous devons vraiment modifier les métadonnées du fichier cette fois-ci” se divise en deux phases principales :

Phase A : Alignement Sémantique (Merge)

Quel que soit le nombre de raw classifier values actuellement analysés, le système extrait d’abord leurs semantic keys correspondantes pour dédupliquer et les fusionne avec les Brouillons (Drafts) non écrits.

Phase B : Décision de Réécriture (Diff)

C’est l’étape la plus cruciale ! Le fait de générer ou non un patch de modification de fichier ne dépend plus de la semantic key. À la place, il extrait la desired write value (la chaîne attendue pour être écrite selon les préférences actuelles de l’utilisateur) et effectue une comparaison directe avec la file current value (la chaîne réelle actuellement lue depuis le fichier).

Scénarios du Monde Réel :

• Scénario 1 : Le fichier contenait à l’origine l’anglais Rock, et maintenant vous le configurez pour une interface et des tags en français.
  • Clé Sémantique : Rock
  • Valeur Actuelle du Fichier : Rock
  • Valeur d’Écriture Souhaitée : Rock (ou Musique Rock)
  • Conclusion : Générer un Patch ! Le système réécrira parfaitement le fichier original.
• Scénario 2 : Le fichier a déjà été réécrit en Musique Rock, et le système scanne à nouveau la Clé Sémantique pour Rock.
  • Clé Sémantique : Rock
  • Valeur Actuelle du Fichier : Musique Rock
  • Valeur d’Écriture Souhaitée : Musique Rock
  • Conclusion : Aucun Patch Généré ! Cela permet d’économiser considérablement les E/S disque et de garantir la pureté des journaux d’historique.

Conclusion

Un système de tags basé sur la séparation des Clés Sémantiques semble assez traditionnel, mais c’est la fondation qui soutient les futures “règles de mappage définies par l’utilisateur” et “l’unification complexe de vecteurs LLM”. L’ingénierie logicielle ressemble souvent à cela : nettoyez les responsabilités couplées, et la logique métier redeviendra d’une clarté rafraîchissante.