Wikipédia abstraite/Mises à jour/2023-04-19
| ◀ |  Actualités de la Wikipédia abstraite 
|
▶ |
|
Choisir la bonne implémentation
Les fonctions dans Wikifonctions peuvent avoir plus d'une implémentation. Par exemple, si nous avons une fonction qui met en capitale la première lettre d'un mot, nous pouvons avoir plusieurs implémentations, par ex. une ou deux en Python, une en JavaScript et une en utilisant la composition. Vous pourriez trouver certaines implémentations surprenantes. Nous avons déjà expliqué pourquoi nous avons fait le choix de conception d'autoriser plusieurs implémentations pour une seule fonction.
Jusqu'à récemment, Wikifonctions sélectionnait une implémentation au hasard. Cela signifie que chaque fois que quelqu'un appelait une fonction et qu'il y avait plusieurs implémentations disponibles, Wikifonctions sélectionnait l'implémentation à utiliser au hasard.
Les implémentations de la même fonction peuvent avoir un comportement d'exécution très différent. Certains peuvent être très lents, et d'autres peuvent être très rapides : trier une liste de 100 000 nombres aléatoires à l'aide de tri à bulles (bubble sort) peut prendre une minute sur un processeur actuel, mais avec tri rapide (quick sort) la même liste de nombres peut être triée en moins de deux centièmes de seconde - plus vite qu'un clin d'œil. Beaucoup plus vite.
Dans Wikifonctions, les fonctions doivent être accompagnées de tests. La fonction de capitalisation dont nous avons parlé plus tôt n’a qu’un test actuellement, qui vérifie que la mise en majuscule du mot « test » renvoie « Test ». Si tout se passe bien, Wikifonctions exécutera chaque test sur chaque implémentation. Les résultats de ces tests sont stockés : la réussite de l'implémentation, le nombre de ressources nécessaires et d'autres métadonnées. Ces informations d'exécution sont également présentées à l'utilisateur dans une fenêtre contextuelle sur demande, pour les personnes intéressées par les détails du back-end.
Wikifonctions classe désormais les implémentations en fonction de ces métadonnées et met à jour l'ordre interne des implémentations. Les échecs de test entraînent un moins bon classement et des résultats rapides conduisent à un meilleur classement. Ainsi, au cours des dernières semaines, au lieu de sélectionner une implémentation au hasard, nous sélectionnons maintenant la première implémentation en fonction de ce classement. Voici un exemple de cette réorganisation qui fonctionne en pratique (hélas, les différences ne sont pas encore implémentées).
Cela devrait mener à une considérable réduction des ressources utilisées et à un comportement plus cohérent des fonctions Wiki. Les appels de fonction devraient moins souvent produire des délais d'attente. Cela devrait également éviter à la communauté Wikifonctions de devoir se préoccuper des implémentations inefficaces et de savoir si nous devons les accepter ou non. Souvent, les algorithmes plus simples sont plus faciles à lire et à vérifier, mais sont plus lents : le tri à bulles en est un bon exemple, comparé au tri rapide. Le tri à bulles est généralement considéré comme beaucoup plus facile à expliquer et à comprendre que le tri rapide. Le fait d'avoir les deux permet de comparer les résultats de l'implémentation la plus simple aux résultats de l'implémentation la plus complexe, les deux passant la même suite de testeurs, et d'augmenter ainsi notre confiance dans le système global. Dans le même temps, nous pouvons en pratique utiliser l'implémentation la plus efficace et ainsi réduire l'utilisation globale des ressources.
Avec cela, la première version d'un élément majeur qui fonctionne dans les coulisses de Wikifonctions a été mise en place, et nous avons terminé un autre objectif de la phase actuelle.
Réflexion de Maria Keet sur la Wikipédia abstraite jusque là
Maria Keet a été un élément actif et central du Natural Language Generation Workstream. Elle est professeure à l'Université de Cape Town, en Afrique du Sud, et sa collaboration avec Ariel Gutman sur le template language et ses arguments ont été mentionnés dans l’évaluation des « collègues » et la réponse. Maria a maintenant écrit ses propres réflexions et les a publiées sur son blog :
keet.wordpress.com/2023/03/14/some-reflections-on-designing-abstract-wikipedia-so-far/
Le texte est très accessible, donne le contexte, explique certains des problèmes auxquels sont confrontés les langages à faibles ressources et fait des suggestions sur la manière de procéder. Maria décrit également certains des défis frustrants qu'elle a rencontrés pour faire entendre et reconnaître sa voix. Cette partie rend la lecture douloureuse et indique les changements nécessaires.
Pour reprendre ses derniers mots :
C'est une montagne que nous continuerons à gravir, que ce soit avec ou sans le projet Wikipédia abstraite. Si la Wikipédia abstraite doit voir le jour et s'épanouir pour de nombreuses langues bientôt, elle doit aussi laisser une place pour les taupinières, les fourmilières, les digues, les dunes et les collines, et avec toutes les fleurs disponibles pour la mettre en place et la faire grandir.
Nous remercions à Maria pour ses constantes contributions. Nous espérons que nous pourrons créer un espace plus inclusif, dans le but de faire de la contribution une expérience plus saine.
Présentation de la Wikipédia abstraite en Suède
Le professeur Aarne Ranta donnera une présentation sur la génération de langage naturel et la Wikipédia abstraite le jeudi 20 avril 2023 à 17 h 30 heure locale, au musée maritime de Göteborg en Suède. L'événement est en présentiel et gratuit pour le public. La présentation sera en suédois.
Vous trouverez plus d’informations en suédois sur cette présentation ici :
https://www.vetenskapsfestivalen.se/for-alla/kunskap-utan-granser-abstract-wikipedia/5944/