Wikiversité

Recherche:Pensées Profondes et Dialogues Pertinents/Approche

< Recherche:Pensées Profondes et Dialogues Pertinents
Début de la boite de navigation du chapitre
Approche
Icône de la faculté
Chapitre no 3
Recherche : Pensées Profondes et Dialogues Pertinents
Chap. préc. :État de l'art
Chap. suiv. :Implémentation
fin de la boite de navigation du chapitre
En raison de limitations techniques, la typographie souhaitable du titre, « Pensées Profondes et Dialogues Pertinents : Approche
Pensées Profondes et Dialogues Pertinents/Approche », n'a pu être restituée correctement ci-dessus.

Synergie

modifier

TODO: Pourquoi cette approche a été adopté?

L'idée qui guide le travail dans culturia est la synergie entre les approches symbolique et les approches probabiliste et statistique[1]. Il s'agit donc d'un système hybride. L'approche synergique a été adopté dans AskPlatypus[2] mais aussi dans le projet OpenCog[3].

L'approche par synergie adopté est la suivante:

L'utilisateur exprime un problème sous la forme d'une chaîne de caractère. Un arbitre prend en charge ce problème et le soumet en parallèle à un ensemble d'agents qui vont à tour de rôle fournir des éléments de réponses. Le processus se répète jusqu'à ce que plus aucun agents ne puissent ajouter d’élément de réponse. Un agent peux s'activer après plusieurs itérations en se basant sur les éléments de réponses apportés par d'autres agents.

A tout moment l'utilisateur peux demander à culturia des éléments de réponses, et ceci même si tous les agents n'ont pas finit leur travail. Ceci permet à l'utilisateur de contrôler la recherche en éliminant certaines pistes de réflexion en apportant des éléments de réponses aux théories élaborées par les agents.

Un agent a deux caractéristiques souhaitables:

  1. Il devrait implémenter un algorithme glouton, de façon a fournir une réponse la plus pertinente possible à chaque itération le plus rapidement possible
  2. Il devrait adopter une stratégie paresseuse, c'est-à-dire que le calcul des éléments de réponses doivent se faire progressivement.

Au lieu de générer l'ensemble des éléments de réponse en une unique itération. L'idée est que le calcul de l'ensemble des éléments de réponse peux bloquer longtemps l'agent dans un problème qui risque d'être faciliter par un autre agent ou par l'utilisateur. En calculant progressivement sa réponse, il peux rapidement revoir le problème avec les éléments de réponse apporté par un autre agent et ainsi ré-évalué sa stratégie en conséquence.

Cette approche permet d'avoir toujours, ou tout du moins le plus souvent possible, des éléments de réponses à soumettre à l'utilisateur. Autrement dit, il faut éviter les barres de progression et compter sur la patience de l'utilisateur. Effectivement, cette mécanique implémente une coopération implémentant un algorithme de recherche en faisceau et anytime.

Arbitre

modifier

Dialogues pertinents

modifier
  • NLG based on frames
  • dialog based knowledge base

Base de connaissances

modifier

Historique

modifier

Au début, forcé par la mode, le focus étais sur les bases de données en forme de graphe tel que TinkerPop ou Neo4J. Les performances, le manque de simplicité a poussée les développements vers la création d'une solution embarquées. Initialement écrit en python, les performances laissaient a désirer, c'est ce qui a pousser la transition vers Chez Scheme. Entre temps, MongoDB et ArangoDB ce sont aussi positionnées comme base de donnée ACID, transactionnelle, embarquées et multi-modèle. Ce sont devenu de possibles solutions.

La lecture de[4] a été un tournant considérable, dans le sens ou un logiciel de tutorat comme base de donnée personnel devrait au moins permettre la coopération et l’échange. C'est ce qui a motivé la création d'une base de donnée de tuples a n items comme une généralisation des triple-stores et quad-stores. Ces travaux sont en cours de standardisation dans la spécification SRFI-168[5]. A l'aide de cette abstraction une base de donnée de quads versionnées dans un graphe orienté acyclique a été créée. Cette base, appelée datae, est utilisée dans culturia pour stocker et représenter les connaissances.

Qualités requises

modifier

Une base de donnée avec:

  1. une utilisation simple
  2. un schéma flexible
  3. un schéma évolutif
  4. un stockage fiable
  5. plus grand que la mémoire vive

Par utilisation simple, on entend l'absence d'installation ou de configuration supplémentaire. Ceci élimine la majorité des bases de données notamment PostgreSQL. A fortiori, il n'est pas acceptable d'avoir a installer plusieurs base de données comme par exemple la configuration courante dans l'industrie qui consiste a coupler ElasticSearch comme un index spécialisé avec une base de donnée "maître" par exemple PostgreSQL ou MongoDB. D'autant plus que la fiabilité de tel système laisse a désirer. En effet, la synchronisation des données, qui bien qu'elle pourrait se faire uniquement vers ElasticSearch, se fait en dehors des transactions et pose le risque d'avoir des incohérences entre les sources de données. De part ce besoin, on ne peux que considérer les base de données qui peuvent être embarquées dans le processus du logiciel.

MongoDB, ArangoDB et peut-être encore Neo4J ont un mode de fonctionnement embarquées, ont un schéma flexible, évolutif et un stockage fiable supporté par des transactions avec les propriétés ACID.

Neo4J a encore peu ou pas de solution transactionnel pour créer des indices spécialisés tel que les indices full-text ou géospatial ou tout simplement pour permettre les réponses paginées.

MongoDB et ArangoDB aurait pu être utilisée comme moteur de stockage dans culturia (ou pas).

Le choix a été fait d'utiliser WiredTiger comme moteur de stockage. Cette bibliothèque fourni des primitives bas-niveau tout en garantissant les propriétés ACID. Elle offre les performances et la flexibilités nécessaire a la mise en place d'une base de connaissances versatile.

Implémentation

modifier

Voir en annexe la référence sur l'interface de programmation.

Représentations

modifier

Pensées profondes

modifier

anything2text

modifier
modifier

https://en.wikipedia.org/wiki/Link_grammar

Méta-connaissances

modifier

https://link.springer.com/book/10.1007%2F3-540-29966-1

Moteur de recherche

modifier

Méta

modifier

Embarqué

modifier
  • crawler
    • robots.txt
    • sitemap.xml
    • common crawl
    • ad-hoc support

Indexation

modifier

Références

modifier
  1. ↑ « On Chomsky and the Two Cultures of Statistical Learning », sur norvig.com (consulté le 5 juin 2019)
  2. ↑ askplatypus (https://askplatyp.us/) est un logiciel de question-response basé sur wikipedia, la version précedente est nommé Projet Pensée Profondes (https://projetpp.github.io/)
  3. ↑ OpenCogPrime: A cognitive synergy based architecture for artificial general intelligence (http://ieeexplore.ieee.org/abstract/document/5250807/)
  4. ↑ Federico Morando, Raimondo Iemma, Simone Basso et Lorenzo Canova, « Collaborative Open Data versioning: a pragmatic approach using Linked Data », {{{périodique}}}, Edition Donau-Universität Krems, 2015, p. 171–183  (ISBN 9783902505699) [texte intégral (page consultée le 2019-06-05)]
  5. ↑ « Generic Tuple Store Database », sur srfi.schemers.org (consulté le 5 juin 2019)



  État de l'art
Récupérée de « https://fr.wikiversity.org/w/index.php?title=Recherche:Pensées_Profondes_et_Dialogues_Pertinents/Approche&oldid=909551 »