brazomyna a écrit :



existe-t-il des benchs qui comparent objectivement le taux de réussite d’un google home vs alexa vs mozilla vs cortana par exemple ?



j’aimerais beaucoup migrer ma domotique vers de la reco vocale non cloudesque, mais si c’est pour avoir un taux d’erreur trop élevé, c’est mort d’avance.



ex: pour avoir testé il y a 2 ans environ, la reco vocale de cortana (via le projet S.A.R.A.H et les micros d’un kinect) arrivait à être moins bonne sur des phrases prédéfinies que mon google home avec des phrases non prédéfinies.





C’est difficile de donner une réponse, mais avec un peu de travail y’a pas de raison que ça ne marche pas. Un vocabulaire limité, on arrive assez facilement à avoir de bons résultats. J’avais expérimenté ça y’a un moment déjà, on a aussi des contributeurs qui nous ont fait des retours positifs (notamment un robot contrôlé à la voix).



Quant aux benchmarks, y’en a, mais faut faire attention, les jeux de données de tests peuvent être très biaisés et peu représentatifs d’une utilisation « finale » (avec du bruit, avec des micros pourris, etc). Ếtre plus robuste à du son dégradé on y travaille.

tazvld a écrit :



Je n’ai pas regardé en détail le code de “DeepSpeech.py” (qui est la partie qui m’a intéressé), je n’ai pas très bien vu sur quelle sortie le réseau était entraîné. Main j’ai l’impression qu’une bonne partie du truc peut être fait avec tf.keras (autant utiliser la version de la bibliothèque intégré à TF). Par exemple, les couches dense (et le preprocessing create_overlapping_windows) se remplace très bien avec Conv1D, les LSTM par les LSTM de keras (dans TF, et je crois que c’est seulement depuis TF2, LSTM va utiliser la version cuDNN si c’est possible). Pour le dropout, tu as la couche Dropout, mais je pense que “SpacialDropout” serait peut être mieux. Tu peux utiliser les Callback pour faire des opérations régulièrement, comme les log (via tensorbord), enregistré régulièrement le réseau, earlystop… Le multi GPU est géré (à la base c’est keras.utils.multi_gpu_model , mais dans la doc de TF2, il conseille d’utiliser tf.distribute.MirroredStrategy ).



Dans les remarques, avez-vous essayer de remplacer les LSTM par des GRU ? Vous pourriez gagner en performance sans trop perdre en qualité.



Sinon, comme je l’ai dit, j’aurais tendance à faire du end-to-end, c’est a dire partir de la décomposition en fréquence pour arriver directement à la phrase. Est-ce que c’est prévu ?

L’idée est de pouvoir exploiter le contexte, c’est à dire la phrase en entier, pour deviner le mot prononcé. En effet, c’est ce que l’on fait nous naturellement, on n’entend pas forcément l’intégralité des mots, mais on arrive à le retrouver grâce aux quelques son que l’on a entendu et au contexte.

La façon dont je ferais s’approcherait des réseau de neurone utilisé pour faire de la traduction. On peut même potentiellement faire une version “à la volée”.







Je dirais que la raison la plus évidentes c’est que les outils n’existe pas en Rust. Au contraire, python est Le Langage pour l’apprentissage automatique. Toutes les bibliothèques d’apprentissage automatique ont les version pour Python, tout particulièrement les bibliothèque pour l’apprentissage profond. Dans la réalité, ces bibliothèque sont généralement des wrappers pour du code compiler, les perf d’un code Python pure n’étant pas terribles.



L’autre raison, c’est que Rust n’est pas forcément fait pour ça. Rust est avant tout fait pour les systèmes critiques. Les code demandant une certaine sécurité d’exécution. Ce n’est pas le cas ici.





Ouais, mais tous les trucs de Keras, ça n’existait pas quand on a commencé, comme j’ai dit. Et migrer ça c’est non trivial, faut s’assurer aucune régression dans la qualité, et dans les différentes instances d’inférences. Et l’équipe est pas grosse … On s’en est mangé un paquet de bugs et de comportements non attendus de la part de trucs pas si border-line que ça dans TensorFlow.



Je sais que reuben a essayé les convolutions dont tu parles, et ça marchait pas comme voulu. Bref tu le dis toi même, plein de trucs dans TF 2.0.



Sinon, GRU et end-to-end, c’est des bugs qui sont ouverts / fermés / documentés. GRU, pas ouf des tests qu’on avait fait. End-to-end, c’est pareil, on aimerait bien remplacer KenLM, mais pour le moment on a pas encore le temps.

rmfx a écrit :



Vu la dose de   Je disais ca parce que quand je regarde les sources github, 55.9 pourcent des sources du projet est cpp, qui est dans le meme domaine d’utilisation que Rust. Il ya a donc bien une large portion du code qui pourrait etre oxydee ? Apres, je me penche dessus de maniere assez simpliste. Le tooling est assez basique pour Rust mais si meme chez Mozilla, on ne prend pas le parti de promouvoir Rust, quit a etre moins confort, je me demande qui le fera.





Oui mais regarde la répartition du C++, une grosse partie c’est native_client/ctcdecoder/, dont du code qui implémente l’opérateur TensorFlow augmenté du scoring avec le modèle de langage KenLM, plus openfst. Je sais pas trop ce que ça donnerait d’écrire un module python en C++ avec l’interfaçage nécessaire pour que ce soit appelé depuis CPython, mais très honnêtement, je pense que ça serait se rajouter une part non négligeable de boulot et de bugs.



La partie inférence pourrait être en Rust, sauf que comme ça dépend de bouts de TensorFlow, on se retrouve à dépendre de Bazel. Ça veut dire écrire une API en Rust, et exposée en C pour pouvoir faire des bindings de partout. Et que tout ça se marie correctement avec Bazel. C’était déjà assez galère de cross-compiler avec Bazel pour des cibles non supportées par TensorFlow (RPi3/RPi4) (les gens de Snips pourraient aussi en parler longtemps je crois :)).



Bref, à titre perso j’aime bien Rust mais j’en ai pas (encore) assez fait à mon goût. Dans l’optique de plus dépendre du runtime TensorFlow / TFLite, ça pourrait plus facilement s’envisager, par contre.



Sinon un contributeur propose des bindings Rust :-),https://crates.io/crates/deepspeech (et ça marche bien, je m’en sert sur un autre projet annexe).