Nous continuons à parler des projets du hackathon de printemps DevDays, auquel ont participé les étudiants du programme de master
En passant, nous aimerions inviter les lecteurs à nous rejoindre
Analyseur de messages vocaux Telegram Desktop
Auteur de l'idée
Khoroshev Artyom
Structure de commande
Khoroshev Artem – chef de projet/développeur/AQ
Eliseev Anton – analyste commercial/spécialiste du marketing
Maria Kuklina – Conceptrice/développeuse d'interface utilisateur
Bakhvalov Pavel – Concepteur/développeur/assurance qualité d'interface utilisateur
De notre point de vue, Telegram est une messagerie moderne et pratique, et sa version PC est populaire et open source, ce qui permet de la modifier. Le client offre des fonctionnalités assez riches. En plus des messages texte standards, il contient des appels vocaux, des messages vidéo et des messages vocaux. Et ce sont ces derniers qui apportent parfois des désagréments à leur destinataire. Il n’est souvent pas possible d’écouter un message vocal sur un ordinateur ou un ordinateur portable. Il peut y avoir du bruit ambiant, un manque d'écouteurs ou vous ne voulez pas que quiconque entende le contenu du message. De tels problèmes ne surviennent presque jamais si vous utilisez Telegram sur un smartphone, car vous pouvez simplement le porter à votre oreille, contrairement à un ordinateur portable ou un PC. Nous avons essayé de résoudre ce problème.
L'objectif de notre projet chez DevDays était d'ajouter la possibilité de traduire les messages vocaux reçus en texte au client de bureau Telegram (ci-après dénommé Telegram Desktop).
Tous les analogues sont actuellement des robots auxquels vous pouvez envoyer un message audio et recevoir un texte en réponse. Cela ne nous plaît pas beaucoup : transférer un message vers un bot n'est pas très pratique, nous aimerions avoir des fonctionnalités natives. De plus, tout bot est un tiers qui agit comme intermédiaire entre l’API de reconnaissance vocale et l’utilisateur, ce qui est au minimum dangereux.
Comme indiqué précédemment, Telegram-Desktop présente deux avantages significatifs : la facilité et la rapidité de fonctionnement. Et ce n’est pas un hasard puisqu’il est entièrement écrit en C++. Et comme nous avons décidé d’ajouter une nouvelle fonctionnalité directement au client, nous avons dû la développer en C++.
Il y avait 4 personnes dans notre équipe. Initialement, deux personnes recherchaient une bibliothèque adaptée à la reconnaissance vocale, une personne étudiait le code source de Telegram-desktop, une autre déployait le projet de build
Il semblait que la mise en œuvre de la fonctionnalité prévue ne serait pas difficile, mais, comme cela arrive toujours, des difficultés sont survenues.
La solution au problème consistait en deux sous-tâches indépendantes : choisir un outil de reconnaissance vocale approprié et implémenter une interface utilisateur pour de nouvelles fonctionnalités.
Lors du choix d'une bibliothèque de reconnaissance vocale, nous avons immédiatement dû abandonner toutes les API hors ligne, car les modèles de langage prennent beaucoup de place. Mais nous ne parlons que d'une seule langue. Il est devenu évident que nous devions utiliser l'API en ligne. Plus tard, il s'est avéré que les services de reconnaissance vocale de géants tels que Google, Yandex et Microsoft ne sont pas du tout gratuits et que nous devrons nous contenter d'une période d'essai. En conséquence, Google Speech-To-Text a été choisi car il permet d'obtenir un jeton pour l'utilisation du service, qui durera un an entier.
Le deuxième problème que nous avons rencontré est lié à certaines des lacunes du C++ - un zoo de bibliothèques diverses en l'absence d'un référentiel centralisé. Il se trouve que Telegram Desktop dépend de nombreuses autres bibliothèques spécifiques à chaque version. Le référentiel officiel a
Telegram Desktop lui-même prend beaucoup de temps à assembler : sur un ordinateur portable équipé d'un Intel Core i5-7200U, l'assemblage complet (drapeau -j 4) avec toutes les dépendances prend environ trois heures. Parmi celles-ci, la liaison du client lui-même prend environ 30 minutes (il s'est avéré plus tard que dans la configuration de débogage, la liaison prend environ 10 minutes), mais l'étape de liaison doit être répétée à chaque fois après avoir apporté des modifications.
Malgré les problèmes, nous avons réussi à mettre en œuvre l'idée conçue, ainsi qu'à mettre à jour
À notre avis, il s’agit d’une bonne preuve de concept de fonctionnalité qui conviendrait à de nombreux utilisateurs. Nous espérons le voir dans les prochaines versions de Telegram Desktop.
Prise en charge améliorée du langage naturel dans IntelliJ IDEA
Auteur de l'idée
Tankov Vladislav
Structure de commande
Tankov Vladislav (chef d'équipe, travaillant avec LanguageTool et IntelliJ IDEA)
Nikita Sokolov (travail avec LanguageTool et création de l'interface utilisateur)
Khvorov Alexander (travailler avec LanguageTool et optimiser les performances)
Sadovnikov Alexander (prise en charge de l'analyse des langages de balisage et du code)
Nous avons développé un plugin pour IntelliJ IDEA qui vérifie l'exactitude grammaticale, orthographique et stylistique de divers textes (commentaires et documentation, lignes littérales de code, texte formaté en Markdown ou XML) (en anglais, cela s'appelle la relecture).
L'idée du projet était d'étendre le correcteur orthographique standard IntelliJ IDEA à l'échelle de Grammarly, pour créer une sorte de Grammarly dans l'IDE.
Vous pouvez voir ce qui s'est passé
Eh bien, ci-dessous, nous parlerons plus en détail des capacités du plugin, ainsi que des difficultés survenues lors de sa création.
Motivation
Il existe de nombreux produits conçus pour écrire du texte en langage naturel, mais la documentation et les commentaires de code sont le plus souvent rédigés dans des environnements de développement. Dans le même temps, les IDE font un excellent travail pour trouver les erreurs dans le code, mais sont mal adaptés aux textes en langues naturelles. Il est ainsi très facile de commettre des erreurs de grammaire, de ponctuation ou de style sans que l'environnement de développement ne les signale. Il est très important de commettre une erreur dans l'écriture de l'interface utilisateur, car cela affectera non seulement la compréhensibilité du code, mais également les utilisateurs eux-mêmes de l'application développée.
L'un des environnements de développement les plus populaires et les plus développés est IntelliJ IDEA, ainsi que les IDE basés sur la plateforme IntelliJ. IntelliJ Platform dispose déjà d'un correcteur orthographique intégré, mais il ne supprime même pas les erreurs grammaticales les plus simples. Nous avons décidé d'intégrer l'un des systèmes d'analyse du langage naturel les plus populaires dans IntelliJ IDEA.
exécution
Nous ne nous sommes pas fixé pour tâche de créer notre propre système de vérification de texte, nous avons donc utilisé une solution existante. L'option la plus appropriée s'est avérée être
Le code du plugin est dans
Des difficultés
Assez rapidement, nous avons réalisé que si nous transmettons à chaque fois tout le texte à LanguageTool pour inspection, alors l'interface IDEA se bloquera sur tout texte plus ou moins sérieux, puisque l'inspection elle-même bloque le flux de l'interface utilisateur. Le problème a été résolu grâce à la vérification `ProgressManager.checkCancelled` - cette fonction lève une exception si IDEA estime qu'il est temps d'abandonner l'inspection.
Cela a complètement éliminé les blocages, mais son utilisation est impossible : le traitement du texte est très long. De plus, dans notre cas, le plus souvent une très petite partie du texte change et nous souhaitons mettre les résultats en cache d'une manière ou d'une autre. C'est exactement ce que nous avons fait. Afin de ne pas tout vérifier à chaque fois, nous avons divisé le texte en morceaux de manière déterministe et vérifié uniquement ceux qui avaient changé. Étant donné que les textes peuvent être volumineux et que nous ne voulions pas charger le cache, nous n'avons pas stocké les textes eux-mêmes, mais leurs hachages. Cela a permis au plugin de fonctionner correctement même sur des fichiers volumineux.
LanguageTool prend en charge plus de 25 langues, mais il est peu probable qu'un utilisateur en ait besoin toutes. Je voulais donner la possibilité de télécharger des bibliothèques pour une langue spécifique sur demande (si vous la cochez dans l'interface utilisateur). Nous l’avons même mis en œuvre, mais cela s’est avéré trop compliqué et peu fiable. En particulier, nous avons dû charger LanguageTool avec un nouvel ensemble de langues à l'aide d'un chargeur de classe distinct, puis l'initialiser soigneusement. En même temps, toutes les bibliothèques étaient dans un référentiel utilisateur .m2, et à chaque démarrage il fallait vérifier leur intégrité. En fin de compte, nous avons décidé que si les utilisateurs rencontraient des problèmes avec la taille du plugin, nous fournirions un plugin séparé pour plusieurs des langues les plus populaires.
Après le hackathon
Le hackathon s'est terminé, mais le travail sur le plugin s'est poursuivi avec une équipe plus restreinte. Je voulais prendre en charge les chaînes, les commentaires et même les constructions de langage telles que les noms de variables et de classes. Actuellement, cela n'est pris en charge que pour Java, Kotlin et Python, mais nous espérons que cette liste s'allongera. Nous avons corrigé de nombreux petits bugs et sommes devenus plus compatibles avec le correcteur orthographique intégré d'Idea. De plus, la prise en charge de XML et la vérification orthographique sont apparues. Tout cela se retrouve dans la deuxième version, que nous avons publiée récemment.
Quelle est la prochaine?
Un tel plugin peut être utile non seulement aux développeurs, mais également aux rédacteurs techniques (travaillant souvent, par exemple, avec XML dans un IDE). Chaque jour, ils doivent travailler avec le langage naturel, sans avoir d'assistant sous forme de conseils d'édition sur d'éventuelles erreurs. Notre plugin fournit de telles indications et le fait avec un haut degré de précision.
Nous prévoyons de développer le plugin, à la fois en ajoutant de nouvelles langues et en explorant une approche générale pour organiser la vérification de texte. Nos plans immédiats incluent la mise en œuvre de profils stylistiques (ensembles de règles qui définissent un guide de style pour le texte, par exemple « ne pas écrire par exemple, mais écrire la forme complète »), l'extension du dictionnaire et l'amélioration de l'interface utilisateur (en particulier, nous voulons donner à l'utilisateur la possibilité non seulement d'ignorer un mot, mais de l'ajouter au dictionnaire, en indiquant la partie du discours).
Source : www.habr.com