retour
Joshua Sum
Fondateur, Morphic
8 min de lecture
Un agent d'IA peut récupérer le bon document tout en comprenant mal l'entreprise.
Il peut reconnaître qu'un client a approuvé un budget sans identifier l'opportunité concernée par cette approbation.
Il peut récupérer une ancienne attribution de partie prenante alors que la propriété a changé.
Pour y remédier, il est nécessaire de disposer d'une représentation explicite de ce que l'entreprise sait, de la manière dont ses concepts s'articulent et des preuves qui soutiennent ses conclusions. Les graphes de connaissances fournissent cette représentation. Les ontologies personnalisées en définissent la signification. Ensemble, ils peuvent donner aux agents une base plus précise pour la recherche, la validation et l'action.
Pour Morphic, un agent de revenus conçu sur la base d'un graphe de connaissances, cela est particulièrement pertinent pour les opportunités dont le contexte se développe au fil de mois de conversations, de décisions et d'évolution des besoins.
Graphes de connaissances et ontologies personnalisées
Un graphe de connaissances représente des entités sous forme de nœuds et des relations sous forme de liens (ou arêtes). Dans un système de revenus, les entités peuvent inclure des personnes, des comptes, des opportunités, des réunions, des exigences et des engagements.
Une ontologie définit les concepts utilisés pour décrire ces entités et ces relations. Elle spécifie ce qu'représente une Opportunity (opportunité), comment elle se rapporte à un Account (compte), et ce que signifie pour une personne le fait d'occuper un rôle d'acheteur.
La distinction se fait entre une définition et une assertion :
Ontologie : Une relation de type "champion" relie une personne à une opportunité.
Assertion du graphe : Maya est la championne pour l'opportunité d'expansion d'Acme.
Preuve : Une conversation particulière ou un enregistrement confirmé soutient cette assertion.
Une ontologie peut également définir des hiérarchies de classes et des relations logiques. La base de données orientée graphe stocke et interroge la représentation. Le choix de l'une d'entre elles ne garantit pas automatiquement la signification, l'exactitude ou la valeur probante de son contenu.
Construire une ontologie signifie rendre les définitions commerciales d'une entreprise suffisamment explicites pour qu'un logiciel puisse les utiliser de manière cohérente.
Le point de départ est l'ensemble des questions et des décisions que le système doit soutenir. Pour un agent commercial, celles-ci peuvent concerner la qualification, la couverture des parties prenantes, les exigences non résolues ou la volonté de faire progresser une opportunité.
L'organisation définit ensuite les concepts nécessaires pour répondre à ces questions.
Décision de modélisation | Ce que l'organisation spécifie |
|---|---|
Types d'entités | Opportunités, évaluations, engagements, rôles d'achat et autres objets commerciaux |
Sémantique des relations | Ce que signifie la propriété, l'influence, l'approbation ou la dépendance |
Portée | Si une assertion s'applique à un compte, une opportunité, un produit ou un accord |
Identité | Comment les enregistrements de différents systèmes correspondent à la même entité |
Temps | Quand une assertion est devenue valide et quand elle a été remplacée |
Preuve | Ce qui soutient une assertion et s'il s'agit d'une déduction ou d'une confirmation |
Validation | Quelles combinaisons de données répondent aux exigences opérationnelles |
Évolution | Comment les définitions changent sans effacer la signification historique |
Considérons un rôle d'achat. Un champ de contact peut qualifier quelqu'un de champion. Un modèle plus précis peut représenter une BuyingRoleAssignment reliant une personne, une opportunité, un rôle, une période de validité et des preuves à l'appui.
Cette structure devient utile lorsqu'une personne participe à plusieurs achats ou change de responsabilités. Elle préserve des distinctions qu'une étiquette de contact générique ferait disparaître.
L'ontologie nécessite également des correspondances à partir des systèmes sources. Un identifiant CRM, un participant à une réunion et une adresse e-mail peuvent faire référence à la même personne. La résolution d'entité établit cette identité ; l'ontologie détermine comment l'entité résultante participe au modèle d'affaires.
La construction d'une ontologie est un travail d'ingénierie continu. Les nouveaux concepts nécessitent des définitions, des correspondances, des validations et des tests de régression. La flexibilité du graphe n'élimine pas la gouvernance du schéma.
Pourquoi les entreprises veulent leurs propres ontologies
Une ontologie personnalisée met des distinctions spécifiques à l'équipe à la disposition des agents et des flux de travail qui utilisent la représentation partagée.
Le texte original est conservé parallèlement à l'enrichissement, de sorte que le système clarifie l'ambiguïté sans écarter les preuves.
Recherche plus précise
Interprétation cohérente à travers les systèmes
Erreurs sémantiques détectables
Connaissances qui persistent à travers les changements de modèle
Pourquoi les agents du fisc ont besoin de graphes de contexte
Morphic se superpose au CRM qu'une équipe utilise déjà plutôt que de le remplacer. Notre agent de revenus lit depuis HubSpot, Salesforce ou Pipedrive, à partir des enregistreurs de réunions, des e-mails, de Slack et de la base de connaissances de l'équipe, et agit en fonction de ce contexte : recherche pré-appel, intelligence de compte, suivis, mises à jour du CRM et respect des étapes de vente et des critères de sortie définis par chaque équipe. Chacune de ces actions dépend de la récupération du bon contexte au moment de la décision. HydraDB est l'endroit où réside ce contexte.
Nous modélisons chaque client Morphic comme un locataire HydraDB et chaque membre de l'équipe comme un sous-locataire. La mémoire personnelle d'un commercial reste limitée à ce commercial, tandis que les connaissances à l'échelle de l'organisation, telles que le CRM partagé et la base de connaissances, se situent au niveau du sous-locataire par défaut et sont visibles par tous les membres du compte. Parce que HydraDB applique les métadonnées d'accès pendant le parcours plutôt qu'après, l'agent ne peut pas présenter de contexte à un utilisateur qui n'est pas autorisé à le voir.
Les enregistrements CRM (entreprises, personnes, opportunités et objets personnalisés), l'historique des activités, les documents de la base de connaissances et les tâches sont tous ingérés en tant qu'entités typées. Lorsqu'une intégration synchronise des données, nous préservons leur source d'origine, de sorte que l'agent sait si un fait provient d'un appel enregistré, d'un champ HubSpot ou d'une page Notion, et chaque réponse reste traçable jusqu'à sa preuve. La résolution d'entités fait le reste : un compte mentionné dans un enregistrement CRM, une transcription d'appel et un fil de discussion Slack devient un nœud unique, sans étiquetage manuel. Avant chaque action de l'agent, celui-ci rappelle un contexte enrichi par le graphe (chemins d'entités et fragments associés, pas seulement des passages correspondants), et les conversations de l'agent sont réenregistrées afin que la mémoire se renforce à l'usage.
Choisir le modèle de graphe approprié - Benchmarks publics
Choisir le modèle de graphe approprié - Benchmarks publics
Les données de revenus ont une forme particulière. Elles sont relationnelles (les contacts appartiennent aux comptes, les comptes aux opportunités, les opportunités aux concurrents et aux objections), temporelles (les étapes progressent, les champions partent, les prix sont renégociés) et soumises à des autorisations (tous les commerciaux ne doivent pas voir tous les comptes). Chaque paradigme de recherche capture une partie différente de cette forme. Voici notre évaluation et nos benchmarks, ainsi que les raisons pour lesquelles nous avons choisi d'utiliser ce que nous utilisons.
Évaluation | Résultat rapporté | Ce que mesure le résultat |
|---|---|---|
Enterprise QA, Sequeda et ses collègues | 16,7 % → 54,2 % | Précision des réponses en utilisant SQL par rapport à une représentation sous forme de graphe de connaissances |
Vérification de requêtes basée sur une ontologie, Allemang et Sequeda | 54,2 % → 72,55 % | Précision après l'ajout de vérifications ontologiques et de réparation de requêtes |
HydraDB LongMemEval-S | 90,79 % de précision globale | La configuration de mémoire et de réponse rapportée |
HydraDB BEAM 1M | Score global de 82 % | Mémoire à long terme au niveau d'un million de jetons |
HydraDB EnterpriseRAG-Bench | Score global de 88,7 ; 92,0 % d'exactitude des réponses | Recherche et réponse sur un corpus d'entreprise synthétique |
HydraDB FinanceBench | 91,4 % de Rappel@10 en mode réflexion | Récupération des preuves à l'appui parmi les dix premiers résultats |
Ensemble, ces résultats nous ont conduits à un graphe de connaissances temporellement versionné avec une ontologie personnalisée pour chaque équipe, fonctionnant sur HydraDB. Nous avons choisi HydraDB car il gère ces trois propriétés directement dans la base de données : il combine la recherche sémantique, par mots-clés et par graphe pour trouver le bon contexte, et son cœur open-source peut fonctionner dans votre propre cloud. Le résultat est un agent ancré dans votre entreprise telle qu'elle fonctionne réellement, sur une infrastructure qui vous appartient.