ANNEXE H : UN PREMIER MOTEUR DE
Figure 64 : Exemple de suffix trie sur le mot "BANANAS"
Pour notre étude, nous avons choisi une implémentation de l'algorithme de McCreight, algorithme ayant apporté la notion de path compression, c'est-à-dire la possibilité de conserver sur une branche non pas un seul caractère mais une chaîne de caractères. Cette particularité permet de réduire la taille mémoire de O(N2) dans le cas d'un suffix trie à O(N), dans le pire des cas 2N, N étant la taille de la chaîne de caractères. Cet algorithme est détaillé en annexe I. Dans la suite, nous appelerons cette structure un suffix tree. En réalité, pour des questions d'espace mémoire, les labels ne sont pas concrètement représentés par des chaînes de caractères, mais par leurs positions relatives à l'intérieur de la chaîne intégrale S, comme représenté en Figure 65.
Figure 65 : Structure réelle d'un arbre de suffixes
0 (0;6)
1
(1;1)
2 (2;3)
3 (4;6) (6;6)
4
(4;6) (6;6)
5 (6;6)
(2;3)
6 (6;6)
0 1 2 3 4 5 6
B A N
S: A N A $
Les arbres de suffixes généralisés
L'algorithme de McCreight permet de construire un arbre de suffixes à partir d'une seule chaîne de caractères, or nous souhaitons pouvoir inclure dans un même arbre plusieurs documents phonétiques. Pour cela, il existe une extension de l'algorithme permettant de construire un arbre de suffixes assurant la gestion de plusieurs chaînes de caractères séparées par des caractères de séparation appelés sentinelles. L'arbre généré est appelé arbres de suffixes généralisés [LEE 07], il permet de combiner dans un même arbre plusieurs chaînes de caractères différentes tout en étant capable d'identifier à la fois la chaîne et la position du suffixe dans cette chaîne. Concrètement, un identifiant numérique de la chaîne est ajouté dans les nœuds feuilles, comme indiqué en Figure 66, sous la forme (index chaîne, position dans la chaîne). Le caractère sentinelle est dans cet exemple '$'.
Figure 66 : Exemple d'arbre de suffixes généralisé
Voyons à présent comment intégrer cet algorithme à notre problème d'organisation des documents phonétiques.
Arbres de suffixes généralisés et transcriptions phonétiques
Comme vu précédemment, les arbres de suffixes permettent de rechercher un motif M de longueur m dans une chaîne de caractères de taille n avec une complexité en O(m), quelque soit la valeur de n. Cette rapidité d'exécution est telle que nous la souhaitons pour notre système, voilà pourquoi nous avons choisi de structurer nos documents phonétiques dans un arbre de suffixes généralisé. Le découpage automatique des transcriptions en groupes de souffle permet de limiter la profondeur de l'arbre généré, et les silences deviennent dans notre cas le pendant des caractères sentinelles requis par l'algorithme de génération.
Au final, les séquences de phonèmes des groupes de souffle remplacent les chaînes de caractères au niveau des branches, et les feuilles de l'arbre indexent le groupe de souffle ainsi
A
(0;5)
(0;1) NA $
BANANA$
(0;0)
(0;4)
NA
(1;3) LE$
(1;4) E$
S : "BANANA$APPLE$"
NA$
(0;3)
$ (1;0)
PPLE$
(0;2)
NA$ $
(1;1) P
(1;2 ) LE$
PLE$
(0;6) (1;5)
$
que la position du suffixe dans ce groupe de souffle par une paire de paramètres (index GS35, position). Notons cependant qu'effectuer le découpage au niveau des silences lève un problème : on sera incapable de détecter une requête si le décodage a inséré un silence dans la séquence phonétique correspondante. Malgré tout, les silences sont des unités plus longues qu'un phonème basique, et fait partie des phonèmes les plus robustes au décodage, c'est pourquoi on peut faire l'hypothèse que ce type d'insertion sera probablement assez rare.
La Figure 67 donne un exemple d'arbre de suffixes généralisé construit à partir de deux fichiers, comprenant au total 3 groupes de souffles.
Figure 67 : Transcriptions phonétiques et arbre de suffixes généralisé
Comme vu ci-dessus, la recherche exacte d'une requête phonétique de p phonèmes dans un corpus de test transformé en arbre de suffixes généralisé s'effectuera donc en une complexité O(p) totalement indépendante de la taille du corpus. Voyons à présent comment appliquer la recherche approximative dans une telle structure.
Recherche approximative
Abordons à présent le problème de la recherche approximative : est-il simple d'appliquer à un tel arbre l'algorithme de programmation dynamique de calcul de distance phonétique ? Un problème similaire a déjà été posé dans le chapitre sur la détection de mots-clés. En effet, intuitivement, effectuer une recherche approximative dans un arbre revient à calculer la distance entre une requête et chaque branche de l'arbre. Intéressons-nous donc tout d'abord au nombre de calculs de similarités maximum, c'est-à-dire le nombre maximum de feuilles contenues dans l'arbre. Chaque nœud possède au maximum 35 fils, le vocabulaire phonétique contenant 35 phonèmes différents, et la profondeur de l'arbre ne dépassera jamais
35 GS=groupe de souffle
I R
(0;0) (2;0)
(1;0)
A K AN
R
(0;1) (2;1)
(1;1)
A K AN
(0;2) (2;2) A K
(0;3) (2;3) K
(1;2) AN
Fichier 1 : "sil I R A K sil I R AN sil"
Fichier 2 : "sil I R A K sil"
GS_0 GS_1
GS_2
la longueur du plus grand groupe de souffle rencontré. Si on note cette longueur L, alors le nombre maximum de feuilles contenues dans l'arbre est de 35L.
La différence fondamentale avec la détection de mots-clés est qu'ici, la longueur des requêtes phonétiques est connue. Il est donc aisé de connaître la taille approximative des séquences phonétiques susceptibles de contenir une requête effectivement été prononcée. En reprenant le fait que notre moteur de DAP aboutit à un taux d'erreur phonétique d'environ 25%, on fixe, pour une requête de p phonèmes une taille minimale de séquences approximatives à 0.75p et une taille maximale de 1.5p, comme proposé au chapitre précédent.
Cette information permet donc un élagage simple lors d'une recherche approximative, en ne calculant pas de distance au-delà de 1.5p phonèmes pour chaque requête.
De plus, toujours en suivant cette notion, nous avons décidé d'effectuer des types de recherches différents en fonction de la taille des requêtes. Dans cette optique, aucune approximation ne sera tolérée pour les requêtes inférieures à trois phonèmes, seules les substitutions seront gérées pour les requêtes inférieures à cinq phonèmes et les requêtes d'ordre supérieur se verront appliquer une programmation dynamique normale.
Construction de l'arbre à partir du corpus de test ESTER
La Figure 68 illustre le nombre de nœuds requis en fonction du nombre de phonèmes lus lors de la construction de l'arbre de suffixes généralisé effectuée sur le corpus Test_ESTER contenant 7h30 de parole.
0 50000 100000 150000 200000 250000 300000 350000 400000 450000
0 100000 200000 300000 400000
Nb phonèmes
Nb noeuds
Figure 68 : Nombre de noeuds de l'arbre de suffixes généralisé en fonction du nombre de phonèmes lus dans le corpus de test
On en déduit une loi linéaire empirique, relative à ce corpus de test : f(x) ~= (4/3)x (<
2x), qui respecte la loi de complexité vue précédemment posant le fait que l'espace mémoire relatif n'excéderait pas 2N. Concrètement, et suivant notre implémentation personnelle et probablement sous-optimisée, ce corpus de 7h30 sous forme d'arbre prend 74Mo en mémoire.
De façon à constater le comportement de ce système sur une base de données plus importante, nous avons généré 168H de données audio. Pour ce faire, nous avons extrait aléatoirement des phrases et leurs transcriptions phonétiques d'articles du journal Le Monde, en considérant environ 25K phonèmes pour une heure. Au final, l'arbre construit sur cette nouvelle base de données aboutit à environ 1.5Go en mémoire. Cette solution, en l'état actuel d'implémentation, ne semble donc pas adaptée à la manipulation de très grandes bases de données audio.