Comment optimiser les données avec le Knowledge Graph ?
Nous allons « diviser pour régner » ce sujet en deux catégories : le stockage et la récupération.
Diviser pour régner est une stratégie algorithmique qui divise un problème en sous-problèmes plus petits et gérables. Dans ce contexte, les sous-problèmes sont analogues aux entités d’une base de données de graphes. Un cluster est constitué d’un certain nombre de « sous-problèmes » similaires.
Les entités de votre entreprise, telles que les talents, les projets, les clients, les produits ou les contrats, etc. sont représentées sous forme de nœuds. Les nœuds se connectent à travers des arêtes, représentant des relations (comme dans Neo4j). En connectant les arêtes, vous stockez le contexte pertinent, mais pas tout, juste ce dont vous avez besoin pour la récupération.
Stockage
Il y a deux phases : la première est le stockage de l’information, la seconde concerne les stratégies de stockage.
Stockage de l’information
La plupart du temps, les entreprises disposent d’un environnement de données existant qui doit être transformé en graphe de connaissances. Il s’agit d’organiser les données et de créer des relations entre les différentes données. En outre, vous devez également configurer des données de streaming pour garantir des mises à jour continues à mesure que de nouvelles informations sont disponibles.
Nous suggérons d’utiliser un LLM affiné (business fine-tuned LLM). Cela permet de convertir les données brutes en données indexées et en clusters, ce qui garantit la capture du contexte nécessaire. Un LLM bien réglé, équipé d’un agent et de Neo4j comme outil, créera de manière autonome des nœuds (définissant des propriétés telles que des valeurs et des étiquettes pour la classification) et établira et nommera les relations entre eux.
Stratégies de Stockage
La règle d’or ici est la suivante : définissez vos stratégies de stockage et ontologiques (nœuds, propriétés, étiquettes et relations) en fonction de l’objectif spécifique du LLM.
1. Ownership
Relation : Entre Stakeholders et Projets ou Talents.
Explication : Indique qu’un Stakeholder « possède » ou est responsable d’un certain Projet ou Talent.
2. Hierarchical
Relation : Entre Projets ou Technologies.
Explication : Peut représenter une hiérarchie entre différents projets, par exemple, un projet principal qui supervise plusieurs sous-projets ou des technologies qui dépendent les unes des autres.
3. Causal
Relation : Entre Projets ou entre Technologies et Projets.
Explication : Indique qu’un projet ou une technologie cause ou influence directement un autre projet. Par exemple, la réussite d’un projet pourrait être la cause du démarrage d’un nouveau projet.
4. Sequential
Relation : Entre Projets.
Explication : Représente un ordre temporel entre les projets, où un projet commence après la fin d’un autre ou suit une certaine séquence de développement.
5. Temporal
Relation : Entre Projets ou entre Talents et Projets.
Explication : Marque la durée pendant laquelle un projet est actif ou la période pendant laquelle un talent est engagé dans un projet.
6. Correlation
Relation : Entre Projets, Technologies, ou Talents.
Explication : Indique qu’il y a une association ou une similarité entre différents projets, technologies, ou talents, mais sans impliquer une relation causale directe. Par exemple, deux projets peuvent être corrélés parce qu’ils utilisent des technologies similaires.
Récupération
Une fois que l’information est bien stockée, elle devient une connaissance, qui peut ensuite être récupérée. Vous pouvez le récupérer avec des requêtes Cypher dans Neo4j, ce qui est rapide, et notre LLM dans l’environnement Turing est affiné pour produire des requêtes précises.
Cependant, plus il y a de types de relations (pour rappel : temporelles, causales, corrélation, propriété, séquentielles, hiérarchiques, etc.), plus les requêtes Cypher deviendront complexes.
Dans un environnement multidimensionnel avec un contexte étendu et complexe, la recherche basée sur la similarité avec des vecteurs est souvent plus efficace.
C’est pourquoi, dans le prochain épisode, nous explorerons le « vrai » RAG (Retrieval-Augmented Generation) et VectorDB, en particulier ChromaDB, car il est compatible avec Langchain/LlamaIndex et toutes les bibliothèques/modèles que nous utilisons (et ce n’est pas une base de données vectorielle basée sur le cloud comme Pinecone ou Weaviate).