Alors que la saison des fêtes approche à grands pas et qu’une scribe du Hackaday est protégée des tempêtes de l’Atlantique dans son nid douillet, il est temps pour elle de réfléchir aux bases de son métier. Écriture, orthographe et langue anglaise ; des questions telles que la raison pour laquelle les Américains ont une orthographe anglaise différente de celle des Britanniques, mais peut-être le plus important de tous pour les lecteurs de Hackaday ; est-ce « gif » ou « jif » ? Cette phrase ou la phrase plaisante sur l’orthographe peuvent être considérées comme des appâts à clics évidents, mais elles constituent plutôt une poignée pour descendre dans l’étude de la langue. Comment décidons-nous des conventions de notre langage, et devrions-nous même trop nous en soucier ?
Ne croyez pas tout ce que vous lisez à l’école
Nous sommes envoyés à l’école pour apprendre des choses. Pendant ce temps, nous sommes privés de notre liberté alors qu’une succession d’adultes tentent, année après année, de nous bourrer la tête de faits. Nous trouvons certaines parties intéressantes et d’autres moins, mais pour la majorité, nous sommes découragés de penser par nous-mêmes et sommes plutôt censés apprendre par cœur un ensemble de programmes fixes.
Ainsi, alors que les écrivains doivent découvrir par eux-mêmes que l’anglais est une langue en constante évolution grâce à laquelle ils peuvent se libérer des limites artificielles que l’école leur a imposées, beaucoup trop de gens ont peur de mettre la tête hors du parapet linguistique.
Le résultat est que les écarts perçus par rapport aux règles sont exploités par ceux qui ont peur d’évoluer avec la langue, et nous trouvons même nos propres guerres saintes linguistiques à mener. Celui mentionné ci-dessus à propos de « gif » par rapport à « jif » est un excellent exemple. Est-il vraiment important que vous le prononciez avec un « G » dur parce que c’est ainsi que la plupart des gens le disent, ou comme s’il s’agissait d’un « J » ? parce que le créateur du format de fichier l’a dit ainsi ? Pas vraiment, car l’anglais est une langue évolutive entre les mains de ceux qui le parlent, et non entre les mains de ceux qui écrivent des manuels scolaires.
Malheureusement, ce n’est pas vraiment le moment de se réjouir, car même si certaines de ces règles peuvent évoluer avec le temps, ce n’est pas gratuit pour tous. Le langage doit être mutuellement intelligible, nous ne pouvons pas l’inventer au fur et à mesure. Les professionnels adoptent ce qu’ils appellent une approche descriptive, dans laquelle ils vous expliquent comment vous utilisez la langue, au lieu de proscrire la façon dont vous utilisez la langue. devrait je l’utiliserai. Pour ce faire, ils effectuent une analyse statistique de grands corpus, des corps de texte, pour voir quelles formes gagnent le plus de terrain. Et c’est ici que cela devient intéressant, car une analyse linguistique à grande échelle peut vous révéler des choses que vous ne saviez pas sur un sujet que vous pensiez connaître beaucoup.
Comment je n’étais pas l’inventeur de la linguistique computationnelle
J’ai été initié à l’analyse linguistique il y a une quinzaine d’années, alors que je travaillais à l’amélioration de la visibilité d’un très grand site Web dans les moteurs de recherche. Ce n’était pas le monde douteux de la manipulation des moteurs de recherche à l’époque, mais j’étais là pour améliorer énormément le contenu du site et, en bref, le rendre beaucoup plus intéressant à la fois pour les humains et pour les moteurs de recherche. Dans cette entreprise, un peu d’analyse de texte est incroyablement utile, et avant que je m’en rende compte, quelques scripts PHP simples pour traiter le texte étaient devenus une suite à part entière.
Sans savoir qu’il s’agissait déjà d’un domaine, j’ai inventé tout le sujet de la linguistique informatique pour moi-même, et même si je sais maintenant que ce travail est ridiculement inefficace, il a livré la marchandise et m’a aidé à me dire, ainsi qu’au propriétaire du site, où ils se trouvaient. ça avait mal tourné.
Ayant pris goût à l’analyse linguistique, c’est devenu l’un de ces projets qui m’accompagnent depuis de nombreuses années car j’y reviens de temps en temps au fur et à mesure que mon intérêt a augmenté et diminué, et ma suite originale est devenue quelque chose de beaucoup plus utile. Et c’est l’intérêt d’en parler ici, car il n’y a rien de trop difficile là-dedans. Si je peux le faire, vous aussi, cela vaut donc la peine d’essayer de le décrire.
Pour construire un corpus de texte à analyser, il faut d’abord commencer par du texte. J’étais particulièrement intéressé par les données de séries chronologiques autant que par la langue, j’ai donc pris comme source autant de flux RSS que possible. Cela m’a fourni une réserve infinie de nouveaux textes à ajouter à mon analyse, et mon cheval de bataille a été un Raspberry Pi avec un grand disque dur USB qui passe tranquillement une partie de la journée à récupérer des histoires et à les analyser.
Alors, face à un morceau de texte récemment récupéré, quelle est ma première étape ? Avant toute chose, supprimer le code HTML superflu et les sites Web inutiles, ce qui était autrefois un énorme ennui au niveau des règles jusqu’à ce que je découvre que Lynx dispose d’une option de ligne de commande -dump qui fait tout le gros du travail. Ensuite, il est temps de le diviser par délimiteurs de phrases tels que les points et les points d’interrogation, et de diviser les phrases par mots dans un tableau. Je peux ensuite le parcourir mot par mot et traiter ce que je trouve dans mon magasin de données.
Comment récupérer rapidement un mot sur un milliard ?
Lorsque vous disposez de quelques milliers de points de données, il existe de nombreuses options en matière de stockage de données. Une base de données SQL par exemple est une excellente idée. Mais un corpus atteint une taille énorme et abandonne rapidement les approches normales de stockage. Il existe peut-être un logiciel étonnant capable de gérer des milliards d’instances de mots, mais je ne l’ai jamais trouvé, j’ai donc opté pour quelque chose d’intégré à mon système de fichiers. J’utiliserais les chemins du système de fichiers comme requêtes, créant ainsi une arborescence de répertoires de mots que je pourrais interroger simplement en tapant un chemin.
Ainsi, lorsque je parcours les mots d’une phrase, je m’intéresse à leurs fréquences et à leurs colocalisés, c’est-à-dire les mots qui apparaissent à côté. Ainsi, pour chaque mot, je créerais un répertoire contenant un fichier JSON pour enregistrer son occurrence, et dans ce répertoire, je créerais un sous-répertoire pour le mot suivant avec un fichier JSON correspondant. Ainsi, par exemple, je pourrais trouver la popularité du mot « Neil » en ouvrant le JSON dans le répertoire /neil/, et trouver la prévalence de l’expression « Neil Armstrong » dans /neil/armstrong/. Je pourrais également comparer l’occurrence relative de Neils Armstrong et Young, en regardant à la fois /neil/armstrong/ et /neil/young/. La bonne chose à propos de cette approche du système de fichiers est que le script de traitement côté serveur, toujours en PHP, était très simple et que mon client pouvait être du Javascript dans le navigateur qui récupérerait tous ces JSON en temps réel à partir du système de fichiers.
La beauté d’avoir des milliards de mots d’analyse en anglais à seulement un clic de souris est que je peux très facilement vérifier quelle est la version la plus appropriée d’une phrase, quelle est la popularité réelle d’une phrase éphémère, et même la popularité relative de personnalités publiques telles que Les politiciens. C’est comme avoir mon propre vérificateur de vérité linguistique sans avoir à me fier à ce que les autres me disent, ce qui dans mon travail peut être très utile. Cela présente bien sûr des inconvénients, par exemple travailler avec une arborescence de plusieurs millions de sous-répertoires et de petits fichiers JSON devient très fastidieux. Créer une archive, même d’une structure de données de taille moyenne, prend quelques jours, ce qui signifie que la déplacer vers un nouveau disque nécessite une certaine planification.
Ce n’est peut-être pas le tarif habituel pour décrire un projet personnel sur Hackaday, mais c’est un projet qui n’inclut pas moins de temps de développement et d’évolution technologique que n’importe lequel de mes travaux matériels. Si vous souhaitez suivre mes traces, j’ai bien peur d’être timide à l’idée de publier mon désordre mal formé de vieux PHP et Javascript, mais étant donné que sa fonction est assez bien décrite ci-dessus, je pense que la plupart d’entre vous pourraient en écrire un. vous-même si vous y réfléchissiez. Même si ce n’est pas le cas, j’espère que cela vous a donné un aperçu du fonctionnement d’un analyseur de corpus et pourra vous dire des choses que vous ne saviez pas, et vous suivrez mon conseil de ne pas écouter tout ce que votre professeur vous a dit.
