Optimisation de taille

B.3.1. Optimisation de la taille du modèle

La taille du modèle Keras est de 35,8 Mo, ce qui est trop élevé pour s’ajouter à une application de messagerie. Il convient alors d’optimiser le modèle non plus uniquement vis-à-vis des performances comme ce fut le cas dans le chapitre 5, mais également vis-à-vis de sa taille finale, de son efficience.

L’optimisation de la taille du modèle peut se faire de plusieurs manières. Elle peut se faire en amont tout d’abord, lors de la limitation du vocabulaire pris en compte avec, par exemple, un nombre minimum d’occurrences par mot plus élevé ou une limite de taille de vocabulaire définie arbitrairement en prenant uniquement en compte les éléments les plus fréquents du corpus d’entraînement. Cette approche est risquée puisqu’elle modifie directement la capacité du modèle à inférer. Pour cette raison et parce que la taille du corpus d’apprentissage ne nous permet pas de le limiter, nous n’avons pas appliqué cette méthode.

La seconde méthode pour optimiser la taille du modèle est celle recommandée par Google qui consiste à quantifier le modèle (quantize) précédemment figé. Il s’agit dans un premier temps de figer le modèle Keras en un graphe Tensorflow uniquement, permettant de passer de 35,8 Mo à 11,7 Mo. Ensuite, il convient de quantifier ce modèle, c’est-à-dire limiter le nombre de décimales prises en compte après la virgule pour toutes les valeurs des vecteurs du modèle, permet-tant de réduire la taille de plus de deux tiers. La quantification a été utilisée sur les matrices de poids du modèle permettant de passer de 11,7 Mo à 3,0 Mo.

B.3.2. Optimisation de la taille de la librairie

Le modèle faisant désormais 3,0 Mo, il convient d’optimiser la librairie Ten-sorflow afin de limiter la taille embarquée dans l’application android. Pour cela, il convient de compiler notre propre version C++ de Tensorflow en y sélec-tionnant uniquement les opérations utiles pour notre modèle. Chaque opération est un fichier à importer et bon nombre de ces opérations ne sont pas néces-saires lors de la prédiction mais uniquement lors de l’entraînement. Nous avons donc sélectionné les opérations nécessaires afin de recompiler la librairie d’infé-rence pour les architectures ARM. C’est ensuite cette librairie native d’inféd’infé-rence qui sera utilisée par le NDK d’android et manipulée à l’aide de la classe Java

org.tensorflow.contrib.android.TensorFlowInferenceInterface. Au final, la librairie

native recompilée a une taille de 14,6 Mo. Cette taille pourrait encore être op-timisée en filtrant davantage les opérations inutilisées même pendant la pré-diction, et ainsi obtenir une version de Tensorflow totalement dépendante du modèle déployé. La figure B.2 permet de voir les détails d’utilisation disque de

Bibliographie

l’application finale compressée au format APK.

Figure B.2. – Utilisation de l’espace disque dans l’application finale

La taille de la librairie d’inférence est un sujet actuel ayant motivé une version de Tensorflow dédiée aux systèmes embarqués, nommée Tensorflow-lite. Cette version n’était pas stable lors de la mise en place du déploiement android de notre modèle, mais pourrait désormais remplacer l’utilisation directe de Tensor-flow.

B.4. Performances

B.4.1. Performances du modèle

L’objectif lors du déploiement n’est pas d’optimiser les performances du mo-dèles comme ce fut le cas au chapitre 5. Toutefois, la réduction de la taille du modèle via sa quantification altère légèrement les performances finales puis-qu’elle supprime des informations mineures dans les matrices de poids du mo-dèle. De plus, la performance finale est possiblement altérée par la différence de pré-traitement. En effet, même si le pré-traitement appliqué est le même, des dif-férences mineures peuvent venir du fait qu’il s’agissait d’utilisation de librairies Python, ré-implémentées en Java afin de se passer de toute dépendance supplé-mentaire. La tokenisation est actuellement moins approfondie lors du passage au Java.

Les différences de performance ne sont pas chiffrées puisque les modèles fi-naux sont appris sur l’ensemble du corpus disponible. En revanche, leurs diffé-rences sont observables en insérant le même texte dans l’application EmoReco Android, et dans l’application EmoReco Web9.

9. http://lsis-mood-emoji.lsis.org:8080/

Bibliographie

B.4.2. Utilisation des ressources

L’utilisation des ressources par le système prédictif est un point sensible pour l’inclusion du système en production, tout particulièrement dans le cas d’une ap-plication de messagerie. Deux points sont à vérifier : l’utilisation de la mémoire et la consommation énergétique.

Figure B.3. – Analyse des consommations globales

Nous partons du principe que la consommation énergétique est directement liée à l’utilisation du ou des processeurs. Cette utilisation apparaît dans la figure B.3 sous forme de pics localisés principalement lors du chargement de l’activity principale et varie lors de la frappe. La consommation excessive lors du lan-cement de l’activity principale est due à l’initialisation de la classe d’inférence avec l’intégration du modèle. Initialiser cette classe lors de l’accès à l’application, quelle qu’en soit l’activity déclenchée peut être une bonne idée afin de réduire cette consommation au lancement initial de l’application, et non à chaque accès comme c’est actuellement le cas. Pour une application de messagerie à laquelle on accède plusieurs fois par jour, ce détail est important.

En analysant plus en détails l’utilisation des processeurs, comme visible en fi-gureB.4, nous constatons un pic d’usage de 60 % maximum au chargement de la classe d’inférence, puis d’un usage régulier oscillant entre 17 et 20 % maximum lors de la prédiction. L’usage de la batterie reste ainsi modeste si l’application n’est pas sans cesse relancée et peut être davantage optimisé en ajoutant un dé-lai d’attente de fin de frappe de 0.4 seconde entre chaque insertion de lettre, comme c’est le cas dans l’application web.

Bibliographie

Figure B.4. – Analyse de la consommation du processeur

Concernant la mémoire utilisée, le constat est plus mitigé. La figure B.5 per-met d’observer un usage correct de la mémoire issue du code de l’application avec seulement 19 Mo de mémoire constante utilisée, que ce soit pendant ou en dehors de la prédiction. Cependant, la librairie native consomme initialement un peu plus de 32 Mo de mémoire avant de doubler à 63,7 Mo suite aux pré-dictions. dans le code actuel, la représentation vectorielle du texte en flottants n’est pas vidée à la fin de chaque prédiction. Le minimum incompressible est donc supérieur à 32 Mo de mémoire utilisée avec des pics à 63,7 Mo. Cela peut paraître peu en soi, mais une fois le système intégré dans une application finale possédant d’autres fonctionnalités et images générées, cet ajout d’utilisation de mémoire supplémentaire n’est pas anodin.

B.5. Conclusion

Le déploiement du système de recommandation d’emojis dans une application android est l’objectif industriel final vis-à-vis de l’entreprise. Ce processus doit être pris en compte dès la constitution du modèle afin d’optimiser l’utilisation de toutes les ressources de l’environnement mobile, qu’il s’agisse de l’espace disque, de la mémoire ou du processeur et de la consommation de la batterie.

Notre système déployé en une application android est le résultat d’un léger compromis entre intégration logicielle et performance de prédiction pure.

Bibliographie