Ce journal a d’abord été posté en lien, mais à la demande générale des commentaire …
Wikifunctions (ancien nom de code : Wikilambda) est le nouveau projet de le fondation Wikimedia, un wiki de fonctions, au sens informatico-mathématique du terme, éditables par tout un chacun, avec des implémentations dans plusieurs langages de programmation, que tout le monde peut écrire et appelable/exécutable avec une API publique.
Conçu pour servir d’infrastructure au projet Abstract Wikipedia (Présentation ici), un projet de wiki multilingue écrit dans une langue/structure de donnée construite par la communauté et traduite ensuite en plusieurs langues. Les fonctions existent pour la phase de traduction, et aussi probablement pour le système de type qui contiendra la langue construite.
Lancement très préliminaire, pour l’instant quasi aucune fonctionnalité n’est prête, il s’agit plus d’une étape technique mais néanmoins importante et symbolique pour le projet.
# L’annonce de sortie
Posté par Thomas Douillard . Évalué à 5.
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-07-26 (oublié dans le journal)
[^] # Re: L’annonce de sortie
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4.
Quand on n'a pas de tête, il faut avoir des doigts :-).
Merci pour le journal (et le lien).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Lien direct vers le nouveau projet
Posté par Victor STINNER (site web personnel) . Évalué à 3.
https://www.wikifunctions.org/
# Natural Language Generation
Posté par Dring . Évalué à 5.
J'aime pas trop le terme, car dès qu'il est prononcé les gens s'imaginent qu'on parle d'intelligence articielle avancée voire de LLM.
Mais grosso modo, partir de données structurées et générer un texte lisible par un humain et respectant la grammaire du langage cible, c'est "déjà" du NLG. Et ça implique déjà un bon niveau de complexité (règles d'accord, ajustement grammaticaux divers et variés, voire - mais pas dans le cas de wikipedia j'imagine - choix de synonymes pour rendre le texte moins monotone).
Donc pour moi, Abstract Wikipedia c'est clairement du NLG. Et une question : où est-ce qu'on peut trouver le code ? Je suis très curieux de voir l'implémentation. J'ai déjà trouvé quelques frameworks open-source, mais pas très convaincants, et qui ne faisaient presque rien.
Et si quelqu'un se demande "pourquoi utiliser ce type d'outil plutôt qu'un LLM ?", la réponse est généralement : parce qu'on veut être sûr de ce qu'on va obtenir en sortie.
[^] # Re: Natural Language Generation
Posté par Thomas Douillard . Évalué à 5.
La référence en la matière, j’ai l’impression, c’est Grammatical Framework
, qui a pas mal de bouteille.
Des gens de Google ont fait des internats chez Abstract Wikipédia ces dernières années, et certains ont suggéré d’utiliser ce framework qui supporte déjà pas mal de langages. Mais ça ne colle pas du tout avec la vision de Denny, porteur et responsable d’Abstract Wikipedia.
Mais oui, c’est clairement un défi pour la communauté, faudra voir comment elle se forme et s’organise, quelle genre d’architecture logicielle va émerger (pour un projet communautaire ça sera plus probablement en mode bazar que cathédrale, ça sera intéressant à observer en tout cas). Pour les phases préliminaires il a été proposé qu’un système de "motifs" soit mis en place, avec des "template" à trous. Il se pourrait que la communauté ait du mal à aller bien plus loin dans un premier temps, ça pourrait rester des éléments importants. L’évolutivité sera sûrement un point important, et c’est là qu’on peut se demander comment ça va fonctionner et, si ça fonctionne en mode bazar, ça sera facile à faire évoluer à mesure que la génération devient plus mature ou si ça demandera des travaux de maintenances lourds.
Sinon la variation du vocabulaire et des tournures de phrases, ça semble important pour Wikipédia dés que tu veux dépasser la phase d’articles très formatés avec des templates génériques pour un grand nombre d’articles, donc quand tu veux avoir des choses plus personnalisées sur chaque sujet. Et même avant d’ailleurs. Ça ne semble pas trop un problème si il existe différentes "fonctions" de rendu pour les mêmes structures abstraites (descripteurs), donc plusieurs règles pour un même "non terminal" dans une grammaire, de manière analogue. Pour le vocabulaire ce sera lié avec la partie lexique de Wikidata qui propose une base de donnée lexicale. Ça permet notamment de faire des liens entre les concepts et les mots dans un peu toutes les langues, https://dicare.toolforge.org/lexemes/challenge.php?id=28 ou de faire des liens directs entre les sens des mots équivalent dans les différentes langues. Le tout probablement accessible à terme depuis Wikifunction, mais qui demande encore beaucoup de travail pour compléter.
[^] # Re: Natural Language Generation
Posté par Thomas Douillard . Évalué à 4.
Je rajoute un lien vers l’analyse de ceux parmi les internes de Google ont écrit une évaluation critique : https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Google.org_Fellows_evaluation
La réponse de Denny est dans la page.
[^] # Re: Natural Language Generation
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
L'étude, le traitement et la génération de langues naturelles font partie du domaine de recherche de l'intelligence artificielle. Pourquoi de nos jours, tout le monde semble croire que IA == réseaux de neurones? Y a tout un monde en dehors de ces technologies particulières.
Franchement ça doit être frustrant pour les gens qui travaillent depuis des décennies sur des domaines d'IA et le grand public vient soudainement leur dire que ce qu'ils font, c'en est pas, parce que c'est pas des réseaux de neurones (et tout ça parce que quelques marketeux ont récemment réussi à faire parler d'eux récemment, plus que d'habitude). 🤦
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Natural Language Generation
Posté par barmic 🦦 . Évalué à 2.
Parce que c'est eux qui font parler d'eux parce qu'ils ont obtenu des résultats impressionnant accessibles au grand publique. Rien de bizarre là dedans.
C'est pas des débats qui sont arrivés avec l'an dernier.
C'est vraiment pas neuf et je dirais que si ça ennui à se point les pratiquants ils auraient arrêté avant qu'OpenAI fasse parler d'eux et bien sûr c'est complètement con. Il y a différentes façons de traiter un sujet et elles n'ont même pas forcément à être en concurrence.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Natural Language Generation
Posté par Xavier Verne (site web personnel) . Évalué à 3.
La blague dans le milieu est la suivante : une fois qu'un problème est résolu avec de l'IA, ben… C'est de l'algorithmique.
[^] # Re: Natural Language Generation
Posté par Misc (site web personnel) . Évalué à 6.
Perso, de ce que j'imagine, c'est sans doute plus maintenir des templates pour faire des articles wikipedia automatiquement à partir de Wikidata (un peu comme reasonator).
Par exemple, le logiciel pourrait prendre un film dans wikidata, et automatiquement écrire une intro qui dit que "$FILM est un film d'origine $ORIGINE sorti en $DATE. Il a fait $POGNON au box office et a obtenu $RECOMPENSES. $SCENARISTE a obtenu $RECOMPENSE_2".
Il y a pas mal d'articles qui sont formatés suivant des principes précis, et avoir des fonctions pour ça permettrait de gagner du temps.
Ensuite, un souci fondamentale, c'est qu'on ne peut pas tout mettre dans Wikidata. Par exemple, le synopsis d'un film, ça va pas rentrer.
Et un autre souci, l'importance des infos.
Toujours dans l'exemple des films, un film comme Joyland qui a eu à la fois 2 prix à Cannes (Queer Palm, et prix du Jury "Un certain regard"), et un prix dans un festival plus local (Cheries-cheris, festival à Paris) pose la question de la hierarchisation des infos, comme on peut le voir en comparant l'article en francais et l'article en anglais, et les choix faits pour les mentions de récompenses.
Donc je pense qu'il y a plein de truc intéressants de possible, mais comme d'hab, quelqu'un va râler (tm).
[^] # Re: Natural Language Generation
Posté par Thomas Douillard . Évalué à 5.
Le plan c’est de dépasser largement ça, au moins à terme. Faire des "articles template" est le plus facile, mais ce n’est pas ce qui est envisagé, il s’agit de faire du contenu personnalisé pour chaque élément potentiellement, avec du contenu spécifique, dans un ordre choisi. Et de mettre du contenu qui n’est pas forcément exprimable dans Wikidata parce que la structure de la "langue abstraite" sera plus riche et plus souple.
De ce que j’en comprend, le plan sera d’avoir des "descripteurs" qui exprimeront des constructions sémantique. Par exemple si on veut dire que Paris est à la fois une capitale administrative et culturelle, il est envisageable qu’il y ait un "descripteur" pour exprimer cette idée de "à la fois", descritpeur qui aura pour paramètres les choses qu’on veut exprimer sur Paris, donc l’idée de "capitale administrative" et "capitale culturelle". Le tout serait relié à "Paris" par un descripteur "nature".
Ça pourrait donner avec une notation avec des parenthèses "Nature(Paris (Q90), ALaFois(capitale administrative, capitale culturelle)))". Un article abstrait devrait ressembler à une suite de ces structures.
Les fonctions seront chargées de transformer cette structure de donnée, en quelque sorte, en langue naturelle. Avec par exemple une fonction qui sera chargée de rendre le descripteur "Nature", qui pourra analyser les paramètres pour faire des choix de rendu, comme appeler une fonction de rendu pour "ALaFois", et ainsi de suite, en fonction de la langue.
Ça permet évidemment des descripteurs très haut niveau genre avoir un descripteur "film" qui permettrait une approche générique telle que tu la propose, mais aussi de personnaliser le contenu en le remplaçant par du personnalisé à l’envie, ce qui résoudrait le problème de la personnalisation à condition d’avoir une langue suffisamment riche et des traducteurs qui fonctionnent bien pour nos descripteurs.
Du coup on voit qu’il y a potentiellement un compromis à trouver entre le côté personnalisé des descripteurs, genre on a une fonction template pour les "films" dans toutes les langues, ça peut faire des centaines de fonctions de rendu par template, et des descripteurs plus "bas niveau" mais bien plus générique comme "ALaFois" ou "Nature" pour lesquels on écrirait une fonction de rendu par langue mais qui seront utilisables pour plusieurs phrases par articles et bien au delà des films, avec à la clé un effort de maintenance potentiellement moins important parce que ces structures sont plus génériques et plus souple, du côté du rendu linguistique.
Il n’est pas interdit de combiner les approche et d’avoir des fonctions de rendus qui retournent eux même des "phrases abstraites" de plus bas niveau, comme un compilateur qui fonctionnerait en plusieurs phases. Donc on aurait des template eux même écrits dans la langue abstraite et donc plus facilement maintenables et dont la modification se traduit dans toutes les langues.
[^] # Re: Natural Language Generation
Posté par Misc (site web personnel) . Évalué à 5.
Je ne doute pas que les ambitions sont bien plus ambitieuses que ce que j'imagine.
Ensuite, j'ai aussi peur que la majorité de la communauté soit perdue devant la tache abstraite en question. J'ai bien vu pour wikidata, qui me parait simple à comprendre, mais qui requiert quand même d'avoir une certaine vision de la gestion des données qui échappe à beaucoup de monde.
Et j'ai aussi peur que la nature du projet (à savoir essayer de contenter tout le monde via une syntaxe abstraite) soit une source de clash de plus entre différentes communautés linguistiques. La toxicité de chaque projet pris individuellement est déjà haute, j'ose pas imaginer ce que ça va donner si en plus, on s'attends à ce que les mêmes personnes se mettent d'accord avec d'autres.
D'ailleurs, tu donnes des exemples de fonctions en français, mais ç'est aussi un biais qui va sans doute surgir (à savoir que soit les fonctions sont multilingues et c'est le bordel, soit on se limite à des concepts que l'anglais peut exprimer).
Et ça, c'est sans compter sur les problèmes connus comme les pluriels, ou je pense que la question de la génération va être intéressante.
C'est un sujet de recherche ambitieux et intéressant, je ne dit pas le contraire, mais perso, je pense que plutôt que d'avoir plus de centralisation, il en faudrait moins.
Les fonctions sont un pas dans le bon sens pour ça, je ne sais pas si AbstractWikipedia ne sera pas 2 pas en arrière.
[^] # Re: Natural Language Generation
Posté par Thomas Douillard . Évalué à 5.
Tu négliges un peu le principal intérêt de tout ça : fournir des ressources linguistiques dans des langues qui en manquent. De ce côté là, tu peux mutualiser la production de contenu, avec une concentration de l’effort sur les traducteurs pour les parties ou ça se différencie.
Sur le côté multilingue des fonctions ou descripteurs, ce sera le même esprit que Wikidata et c’est un peu la raison d’être de Wikifonctions, tout sera traduisible dans toute les langues. Le multilinguisme est la raison d’être de tout ça et c’est une piste et un parti pris exploré à fond : le but c’est d’avoir des gens de toutes cultures qui participent et de voir ce que ça donne, sans leur imposer une langue ou même un langage de programmation.
Seuls des natifs pourront probablement créer des traducteurs pour certaines langues, le but est de tenter de leur faciliter la tâche. Évidemment c’est un pari risqué, peu de compétences probablement dans les langues avec peu de locuteurs, mais le pari c’est justement d’essayer d’utiliser au mieux ces compétences pour fournir du contenu dans la langue.
Avoir du contenu personnalisé sur tous les sujets dans toutes les langues, ce que tu suggérerait pour avoir de la décentralisation totale, c’est juste la situation actuelle, avec un paquet de Wikipédias avec peu de contenu. Et les wikipédias majoritaires qui ont peu de contenu sur les sujets des cultures moins hégémoniques.
[^] # Re: Natural Language Generation
Posté par Misc (site web personnel) . Évalué à 5.
Certes, mais je suppose aussi que les langues les plus couvertes vont être celles avec la plus grande communauté, et le reste, pas vraiment. Bien sur, pouvoir écrire une encyclopédie avec moins de ressources est un plus. Mais on va pas nier que Wikipedia, ç'est le point de vue du plus grand groupe qui prime.
Fr.wp a un biais vers la France, en.wp sans doute vers les USA.
Wikidata contourne le souci via des identifiants abstraits, et le seul endroit ou tu vois du texte, c'est dans les labels. Il est d'ailleurs intéressant de voir que même si ça n'est pas destiné à écrire du texte et à être lu à la base, il y a quand même eu des gens qui ont voulu traiter ça comme du texte à part entière, avec tout les soucis que ça entraîne d'un point de vue linguistique.
Ici, les fonctions (dans ton exemple) vont avoir des noms dans une langue (sans doute l'anglais, on va pas se mentir). C'est ça le souci pour moi.
Oulah non, au contraire, je trouve la structure des wikipedias actuelles beaucoup trop centralisés, je suis beaucoup plus radical à ce niveau.
Mon argument, c'est celui de la fin de ce commentaire sur l'espace pour le désaccord, à savoir qu'il n'y pas vraiment moyen de facilement faire une encyclopédie dérivée de Wikipedia, sauf sur des axes mineurs (comme l'inclusion ou non de certaines pages), ou via un processus peu pratiques (importer des dumps réguliers, qui requiert des compétences poussés et entraine des soucis à la synchro).
Pour reprendre un sujet qui déchire la communauté en ce moment, le fait d'avoir des images ou pas sur les articles pourrait être un exemple de choix possible si WP n'était pas si centralisé.
Avoir des fonctions pour faire son propre "abstract wikipedia", serait un bon pas, car en théorie, quelqu'un pourrait surcharger les fonctions pour changer des choses (tout comme on le fait pour spécialiser une classe en prog objet, ou du monkeypatching, etc).
Pour reprendre mon exemple, avec un système de surcharge pas trop mal foutu, rien n’empêcherais d'avoir le choix du type d'infobox, avec ou sans les images dessinées, etc. Les gens qui ne veulent pas les voir les retirent, les gens qui pensent que c'est un plus les affichent. Et tout le monde serait libre de proposer son encyclopédie, tout comme tout le monde, en théorie, peut faire des choses avec wikidata sans avoir à se mettre d'accord sur tout un tas de détails.
Maintenant, si une éventuelle surcharge est aussi pratique que "surcharger" une page de WP, alors ça ne va pas être vraiment décentralisé au sens ou je l'entends, plutôt le contraire.
Les infoboxes tirés de wikidata sont acceptées car elles sont surchargeables sur wikipedia au cas par cas. Un monde ou ça ne serait pas le cas tournerait à la guerre civile, car ça entraînerais une centralisation sur wikidata pour décider ce qui s'affiche sur X instances de WP, et c'est la centralisation en question qui est (selon moi) une des principale source de conflit.
Sans ce mécanisme de surcharge (qui est peut être prévu, j'ai pas suivi du tout le projet), ça va être au mieux autant source de friction que WP classique, au pire, ça va être pire parce qu'il n'y a pas la soupape de "les anglophones font ce qu'ils veulent, les francophones font autre chose".
[^] # Re: Natural Language Generation
Posté par Thomas Douillard . Évalué à 3.
Deux trucs : Non pour l’instant il est pas prévu que les versions linguistiques de Wikipédia utilisent des articles d’Abstract Wikipédia. On sait pas encore ou le contenu sera stocké et affiché, c’est pas défini. Donc probablement pas sur les Wikipédias et le contenu et ses règles seront gérés par la commun Abstract, pas les commus locales. (Enfin perso j’imagine pas que ce soit le cas, trop compliqué à gérer avec certaines personnes qui vont faire barrage et mauvaise volonté hostile)
Non, les fonctions n’ont pas un nom spécifique. Par exemple celle ci, List to string en anglais, a un id Z886. Ça va fonctionner exactement comme les identifiants Wikidata et leurs libellés dans toute les langues. Pour l’instant il y a que l’anglais mais c’est juste la phase préliminaire. J’imagine que quand on écrira des fonction par composition dans le langage natif de Wikifunctions, un genre le Lisp a priori, on pourra choisir sa langue et les id seront résolus en fonctions. Le code est stocké dans une structure de donnée Json qui contiendra les IDs je pense, pas de manière classique.
[^] # Re: Natural Language Generation
Posté par Misc (site web personnel) . Évalué à 4.
Il y en avait dans ton exemple, c'est pour ça que j'ai dit ça.
Donc ok, une forme d'indirection, c'est une approche intéressante. Je sais pas si c'est maintenable, mais bon, qui vivras verras.
Ensuite, ici, ça parle de faire du python "classique", donc on en revient à la question d'avoir un nom ou pas.
Après tout le pâté fait par l'équipe sur "oui, on fait pas de supposition sur le fait que les gens parlent anglais", c'est riche.
Si le projet est sérieux sur l'idée d'être utilisable par des gens ne parlant pas anglais, faudrait le faire dans une langue que personne ne parle dans l'équipe dés le début.
Et en lisant les documents que tu as donné (l'analyse par des chercheurs de Google et la réponse), j'ai un mauvais pressentiment sur le projet.
La discussion sur "functional vs imperative" ressemble beaucoup aux questions qu'on a dans le domaine de la gestion de config (declaratif comme puppet vs imperatif comme ansible), et j'ai vu hier une présentation intéressante, notamment sur son point sur la question de qui doit gérer la complexité, et quel complexité doit être exposé.
Et c'est ce qui me dérange un peu dans le document, c'est la naïveté concernant la complexité qui va émerger (mais j'ai un train à prendre, donc je donnerais mon avis plus tard).
[^] # Re: Natural Language Generation
Posté par Xavier Verne (site web personnel) . Évalué à 2.
Si on centralise trop, ça pourrait devenir le systemd de l'initialisation des pages wikipedia ?
[^] # Re: Natural Language Generation
Posté par Thomas Douillard . Évalué à 4.
Des internes de Google ont travaillé sur une architecture et un langage pour des templates pour Abstract Wikipédia, déjà : https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Template_Language_for_Wikifunctions
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.