Quand ajouter des structures de graphes aux systèmes de génération augmentée par récupération

Les équipes logicielles combinent de plus en plus la recherche vectorielle avec des structures de graphes pour gérer des requêtes complexes nécessitant la compréhension des relations entre les points de données. Cette approche, souvent appelée Graph RAG, répond aux limites de la recherche purement basée sur la similarité lorsque les réponses dépendent de liens opérationnels spécifiques, tels que la propriété d'un service ou les termes d'un contrat.

Ce qui s'est passé

La récupération vectorielle est devenue la norme pour de nombreuses applications de génération augmentée par récupération (RAG), car elle excelle dans la recherche de textes ayant une signification similaire, même lorsque des mots différents sont utilisés. Par exemple, une requête concernant la fin d'un abonnement peut récupérer avec succès un article d'assistance traitant de l'annulation du compte. Cette méthode fonctionne bien pour la documentation et les connaissances non structurées où la réponse se trouve généralement dans un ou deux passages.

Cependant, la recherche vectorielle rencontre des difficultés lorsque la question exige de prouver une connexion entre des registres commerciaux distincts. Un score de similarité indique la pertinence mais n'impose pas de contraintes strictes telles que les limites de tenant, les dates d'effet ou les identifiants de compte. Deux enregistrements peuvent être sémantiquement proches tout en n'ayant aucune relation opérationnelle, tandis que des enregistrements directement connectés peuvent partager très peu de vocabulaire.

La solution proposée consiste à utiliser le Graph RAG lorsque les relations entre les faits font partie des preuves nécessaires à la réponse. Cela implique de conserver la récupération vectorielle pour trouver les documents pertinents, mais d'ajouter une couche de graphe pour établir des connexions explicites et typées entre les entités. Cela garantit qu'un agent ne déduit pas de relations à partir de passages similaires, mais suit plutôt des chemins vérifiés définis par les données opérationnelles.

Comment cela fonctionne

Dans ce contexte, le Graph RAG fait référence à la construction d'un graphe à partir des relations déjà enregistrées dans les systèmes existants, plutôt que de les inférer à partir de textes non structurés via un grand modèle de langage. Chaque enregistrement devient un nœud, et des arêtes dirigées et typées représentent des relations spécifiques, comme un service utilisant une bibliothèque ou soutenant un environnement client. Ces arêtes portent des métadonnées telles que la source, le propriétaire et les dates d'effet.

Le processus commence généralement par l'identification des entités candidates et des passages pour une question utilisateur. L'application résout ces candidats vers des enregistrements spécifiques, puis traverse uniquement les relations autorisées dans les limites définies. Enfin, elle récupère les documents sources nécessaires pour expliquer le résultat. Cette séparation permet au graphe de répondre à la question « qui est connecté à quoi », tandis que le matériel source fournit la politique détaillée ou le contenu.

La résolution est l'étape la plus critique, car des correspondances ambiguës peuvent conduire à des chemins incorrects. Si une correspondance est incertaine, le système doit présenter les candidats plutôt que de deviner. Les limites de traversée, telles que le nombre de sauts et les frontières de tenant, doivent être appliquées comme contraintes de requête avant que les résultats n'atteignent le modèle. Les arêtes manquantes doivent être signalées comme une incertitude plutôt que d'être inférées, afin de garantir que l'agent ne présente pas de conclusions non étayées comme des faits.

Détails clés

• La recherche vectorielle classe les preuves probables selon la similarité sémantique, mais ne peut pas prouver les connexions opérationnelles telles que la propriété ou la dépendance.
• Le Graph RAG utilise des arêtes dirigées et typées pour enregistrer des relations explicites, comme un service utilisant une version spécifique d'une bibliothèque.
• La résolution d'entités doit être précise, car une correspondance incorrecte au départ peut invalider chaque saut ultérieur dans le graphe.
• Les limites de traversée, y compris les types d'arêtes, le nombre de sauts et les frontières d'accès, doivent être appliquées au niveau de la couche de requête, et non seulement dans les prompts.
• Maintenir le graphe proche des données opérationnelles, par exemple dans des tables relationnelles avec des extensions de graphe, évite les retards de mise à jour et les problèmes de réconciliation.
• Les agents doivent signaler les arêtes manquantes ou les enregistrements conflictuels comme des incertitudes, plutôt que d'inférer des chemins pour fournir une réponse complète.

Pourquoi c'est important

Pour les ingénieurs qui construisent des systèmes d'IA en production, cette distinction clarifie quand investir dans une infrastructure de graphe. Les bases de connaissances simples où un seul document répond à une question n'ont pas besoin de Graph RAG. Cependant, les applications impliquant l'analyse d'impact, l'assistance consciente des droits d'accès ou la réponse aux incidents bénéficient considérablement d'une modélisation explicite des relations. Ces scénarios impliquent souvent des questions multi-sauts où une mauvaise connexion peut entraîner de graves erreurs opérationnelles, comme notifier les mauvais clients concernant une vulnérabilité de sécurité.

La mise en œuvre de cette approche nécessite de traiter le graphe comme une source de vérité qui doit être maintenue avec la même rigueur que les données opérationnelles. Elle exige une propriété claire, des chemins de mise à jour définis et une traçabilité. Les équipes doivent évaluer le chemin emprunté par un agent aussi attentivement que le texte qu'il génère, en veillant à ce que des réponses fluides ne masquent pas des jointures incomplètes ou incorrectes. Ce changement fait passer l'IA de la simple récupération d'informations à la vérification de la logique structurelle derrière ses réponses.

Ce que vous pouvez faire

• Identifiez les questions récurrentes dans votre système qui nécessitent de joindre des faits à travers plusieurs entités ou de suivre des dépendances.
• Pilotez le Graph RAG sur un processus décisionnel spécifique, comme l'analyse d'impact pour les modifications de composants, plutôt que de cartographier toute l'organisation.
• Définissez des indicateurs de succès qui vérifient si l'agent a résolu les bonnes entités et suivi les relations actuelles dans les limites autorisées.
• Appliquez les limites de traversée et les contrôles d'accès comme des contraintes de requête strictes pour empêcher le modèle d'explorer des chemins non autorisés.
• Assurez-vous que vos données de graphe restent synchronisées avec les sources opérationnelles pour éviter de répondre sur la base d'enregistrements obsolètes ou déconnectés.
• Configurez votre agent pour qu'il déclare explicitement lorsqu'il ne peut pas vérifier une connexion, plutôt que d'inférer un chemin à partir de faits disponibles mais non liés.