Comment construire un graphique de connaissances de produit sans perdre les preuves de source

Commencez par une question que l'entreprise doit répondre

Un graphique des connaissances est utile lorsqu'il améliore une décision répétable. Commencez par des questions comme celle de savoir quelle pièce de rechange est approuvée pour cette machine, quel fournisseur enregistre se réfère au même produit, quel produit prétend être soutenu par un document courant, ou quelle organisation possède une marque particulière. Évitez de commencer avec un objectif de tout connecter.

Écrivez la réponse attendue et la preuve qu'un examinateur devrait lui faire confiance. Une réponse à l'ajustement, par exemple, peut exiger l'identité du produit, la marque et le modèle de la machine, la gamme de production, la position, le document source, la date de la source et le statut de l'examen. Cette liste devient la première tranche du modèle.

M.I.A.I Knowledge Graph est conçu pour relier les entités, les preuves et les relations à des connaissances commerciales réutilisables. Ses capacités approuvées couvrent les entités canoniques, la modélisation des relations, la provenance des preuves et l'accès réutilisable aux connaissances, y compris les liens entre les produits et les applications, la résolution en double et les réponses probantes.

Entités, attributs et relations séparés

Une entité est une chose avec sa propre identité : un produit, une variante de produit, un modèle de machine, un fabricant, une organisation, un document ou un emplacement. Un attribut est une valeur qui décrit une entité, comme un nom de modèle, un poids ou une date de publication. Une relation relie deux entités, telles que manufacturées, compatibles, remplacées ou mises en évidence.

Cette distinction empêche un problème de catalogue commun. Si une application machine n'est stockée que sous forme de texte libre dans une description de produit, elle ne peut être revue, interrogée ou mise à jour de façon fiable. Lorsque le modèle de machine est une entité et que la compatibilité est une relation explicite, l'entreprise peut inspecter toutes les revendications à l'appui, trouver des conflits et réutiliser les mêmes connaissances dans la recherche, les pages de produits et les outils de support.

Le modèle W3C RDF décrit les énoncés graphiques comme des triples objet-prédicat-objet. C'est un modèle mental utile même lorsque la première implémentation utilise des tableaux ou des documents relationnels. Le point important est que la relation a une direction et un sens explicites plutôt que d'être déduite d'un champ de texte partagé.

• Entité: produit P-1042
• Relation: est compatible avec
• Entité: modèle de machine M-208
• Qualification: position du ralenti avant et plage de production applicable
• Preuve : bulletin du fournisseur B-77, page 4
• État d'avancement : examiné et approuvé à une date enregistrée

Créer des identités canoniques sans effacer les enregistrements sources

Une entité canonique représente la vision actuelle de l'entreprise d'une chose réelle. Il devrait avoir un identifiant stable interne qui ne dépend pas d'un titre, d'une URL ou d'une description du fournisseur. Les enregistrements sources demeurent liés avec leurs propres identifiants, valeurs et horodatages.

Ne fusionnez pas les enregistrements simplement parce que leurs noms se ressemblent. Les titres de produit, les noms de société et les descriptions de modèle contiennent des abréviations, des différences de ponctuation et des mots réutilisés. Des preuves solides peuvent comprendre un UGS, un GTIN, le numéro de pièce du fabricant, l'ID de la plateforme, le numéro d'enregistrement de l'entreprise ou une clé composite approuvée. Les preuves acceptables diffèrent selon le type d'entité.

La résolution de l'entité devrait renvoyer une décision et sa base : une même entité confirmée, une correspondance éventuelle nécessitant un examen ou une entité distincte. Préserver les décisions d'appariement rejetées et remplacées de sorte que la prochaine importation ne recrée pas la même ambiguïté. Si deux sources enregistrent un conflit, le graphique peut relier les deux à l'entité canonique tout en maintenant les revendications contradictoires distinctes.

Définir un vocabulaire de petite relation

Les noms de relations font partie du contrat d'affaires. Définir chaque terme, sa direction, les types d'entité autorisés et s'il est symétrique, transitif ou lié dans le temps. Related-to est rarement assez précis pour une décision opérationnelle.

Pour les produits, les distinctions utiles peuvent inclure la variation, le remplacement, le remplacement, la compatibilité, la consommation, la fabrication et la distribution. Le vocabulaire produit de Schema.org illustre plusieurs connexions de produits distinctes, y compris isVariantOf, isRelatedTo, isSimilarTo et isConsumableFor. Ces étiquettes ne doivent pas être considérées comme interchangeables.

Préférez une relation approuvée sur plusieurs quasi-doublements. Si une équipe s'adapte, une autre s'applique et une autre compatible, décidez s'ils ont le même sens commercial. Lorsque le sens diffère réellement, conservez des termes distincts et documentez la différence. Le vocabulaire cohérent rend les requêtes, la validation et les explications des utilisateurs fiables.

Traiter la compatibilité comme une revendication admissible

De nombreuses relations d'affaires nécessitent plus de contexte qu'une simple ligne entre deux nœuds. La compatibilité du produit peut dépendre de la gamme de machines série, année, moteur, configuration, position ou variante régionale. Les relations avec les fournisseurs peuvent avoir des dates de contrat et des territoires. La propriété organisationnelle change avec le temps.

Représenter ce contexte dans un dossier relationnel ou une entité d'affirmation. Entreposez le sujet, le type de relation, l'objet, les qualificatifs, les dates d'entrée en vigueur, les preuves, la confiance ou le statut d'examen, et le propriétaire responsable. Ne cachez pas les qualités dans une note que les demandes ne peuvent pas interpréter.

La spécification W3C RDF note que les relations peuvent changer au fil du temps et que les sources peuvent fournir des états graphiques différents à différents moments. Concrètement, n'écrasez pas la relation approuvée hier sans histoire. Fermez sa période de validité, créez l'affirmation révisée et conservez la raison du changement.

Joindre la provenance aux revendications, pas seulement les fichiers

Enregistrer un PDF source dans un dossier ne suffit pas. Lier l'allégation précise à l'enregistrement source, à la version de document, à la page ou à la ligne, à la méthode d'extraction, au temps de capture et à l'examinateur. Un utilisateur devrait pouvoir passer d'une réponse à l'affirmation, puis à la preuve qui l'appuie.

Le modèle PROV-O W3C fournit des concepts pour décrire les entités, les activités et les agents, y compris la dérivation, la génération et l'attribution. Une implémentation d'entreprise n'a pas besoin d'exposer ce vocabulaire à chaque utilisateur, mais elle devrait conserver les mêmes questions: de quoi cette revendication est-elle née, de quel processus l'a créée, et de qui ou de qui était responsable?

Gardez la preuve de source immuable là où c'est pratique. Si une page Web du fournisseur change, conservez la version capturée ou la somme de contrôle permise par l'accord source. Si un tableur est corrigé, créer une nouvelle version source plutôt que de changer silencieusement les preuves derrière une approbation existante.

• Système source et identifiant d'enregistrement source
• Version de document, URL, page, ligne ou section
• Valeur captée et horodatage de capture
• Méthode de transformation ou d'extraction
• Examinateur, décision et date de la décision
• Période de validité, révision et liens de sursession

Traiter de façon visible les revendications contradictoires

Un graphique devient dangereux quand il transforme le désaccord en fausse certitude. Deux fournisseurs peuvent fournir des dimensions différentes, un document du fabricant peut remplacer un vieux bulletin, ou une description du PGI peut être en désaccord avec une fiche produit-données. Conservez chaque assertion avec ses preuves avant de choisir une valeur préférée.

Les règles de priorité devraient être explicites et limitées à un domaine. L'ERP peut être propriétaire du statut SKU vendable, le fabricant peut être propriétaire de la compatibilité technique, l'IPM peut être propriétaire d'une copie de commercialisation approuvée et une plateforme commerciale peut être propriétaire de son identifiant de destination. Un disque récemment édité n'est pas automatiquement le disque le plus faisant autorité.

Lorsque les règles ne peuvent résoudre un conflit, placez-le dans une file d'attente d'examen avec les entités concernées, les valeurs, les sources et les utilisations en aval. Continuer à servir la dernière affirmation approuvée lorsque l'incertitude est sécuritaire, inscrire au besoin l'incertitude et bloquer la publication à risque élevé lorsqu'il n'y a pas de réponse fiable.

Un exemple concret: une partie, trois systèmes et deux modèles de machine

Considérer comme article 1042 un distributeur dont le moteur est enregistré dans un ERP, dans un fichier fournisseur sous un numéro de pièce du fabricant et dans une boutique en ligne avec un produit distinct et une variante ID. La feuille de calcul du fournisseur dit qu'elle s'adapte à deux modèles compacts de chargeur de piste, tandis qu'un ancien PDF n'en énumère qu'un.

Le graphique crée une entité de partie canonique et relie chaque enregistrement source à lui sans supprimer les ID originaux. Il crée des entités distinctes de fabricant, de produit, de modèle de machine et de document factuel. Deux affirmations de compatibilité relient la pièce aux modèles de la machine. Chaque assertion indique sa position, la portée applicable, la source et l'état de l'examen.

Le premier modèle est pris en charge à la fois par la feuille de calcul actuelle et par l'ancien bulletin, de sorte que le spécialiste du produit l'approuve. La deuxième figure seulement dans le nouveau tableur et reste en attente jusqu'à ce que les preuves du fabricant soient vérifiées. La recherche en magasin et une application répondante peuvent utiliser la relation approuvée, mais ne doivent pas présenter l'attente comme fait.

Lorsqu'un bulletin révisé confirme le deuxième modèle, l'examinateur lie les nouvelles preuves et approuve l'affirmation. La réponse peut maintenant expliquer l'ajustement et citer le bulletin d'appui. Si la partie est remplacée ultérieurement, une nouvelle relation enregistre le remplacement sans changer l'identité ou l'historique de l'élément original.

Valider le graphique avant de réutiliser les applications

La validation devrait porter sur l'identité, la structure et le sens de l'entreprise. Vérifier que les identificateurs canoniques sont uniques, que les types d'entité requis sont présents, que les paramètres de relation utilisent les types autorisés et qu'il existe des qualificatifs obligatoires. Une demande de compatibilité sans état de source ou d'examen ne devrait pas parvenir à une application orientée vers le client.

Ajouter des règles de domaine pour les structures impossibles ou suspectes. Un produit ne doit pas se remplacer. Une variante ne devrait pas appartenir à plusieurs produits parents indépendants, sauf si le modèle l'autorise explicitement. Les chaînes de remplacement circulaires, les plages de validité qui se chevauchent et les affirmations actives en double méritent d'être examinées.

Tester les questions des représentants et les réponses attendues. Inclure des cas positifs, des conflits délibérés, des preuves incomplètes et des revendications révoquées. Le graphique est prêt à être réutilisé uniquement lorsque les demandes peuvent distinguer les connaissances approuvées, en attente, remplacées et rejetées.

Ne donner aux applications que les connaissances qu'elles sont autorisées à utiliser

Un accès réutilisable ne signifie pas un accès illimité. Définir les vues ou les API pour chaque application. Un rechercheur de produit public peut recevoir des relations de produit approuvées et des étiquettes de preuves de sécurité pour le client. Un outil de soutien interne peut voir les demandes en instance et les notes de l'examinateur. Une interface de vérification peut avoir besoin de toute la chaîne de provenance.

Retourner ensemble l'identificateur de l'entité canonique, la réponse, le type de relation, les qualificatifs pertinents, le statut et la référence de preuve. Ne donnez pas à un assistant AI une exportation de texte aplatie et attendez-vous à ce qu'il reconstitue l'autorité. Les réponses fondées sur des données probantes nécessitent une recherche structurée qui porte la base de la réponse dans le processus de réponse.

Loger quelle version graphique et quelles assertions supportaient une réponse importante. Lorsque les connaissances changent, l'entreprise peut identifier les pages touchées, les recommandations ou les réponses à l'appui et décider s'il faut les rafraîchir.

Mesurer la confiance et la réutilisation, et non la taille du graphique

Le nombre de nœuds et de relations montre l'activité, pas la valeur commerciale. Mesurer les entités en double résolues, le pourcentage d'affirmations critiques avec des preuves, le temps d'examiner les conflits, les allégations périmées détectées, les demandes réutilisant les connaissances approuvées et les questions répondues sans recherche manuelle.

Qualité du suivi par type de relation. Les liens entre produits et applications peuvent nécessiter des preuves complètes et l'approbation d'un spécialiste, tandis qu'un lien à faible risque lié au contenu peut utiliser un processus plus léger. Un seul score d'exhaustivité peut masquer de graves lacunes dans les relations qui comptent le plus.

Examiner si le graphique réduit les réponses contradictoires entre les canaux. Si la recherche de produits, le soutien à la clientèle et les pages de produits sont toujours en désaccord, inspecter leurs vues approuvées, cache et propriété de source plutôt que d'ajouter plus de données.

Liste de contrôle de préparation au graphique des connaissances

• Commencez par une question d'affaires définie et la décision attendue.
• Donnez à chaque entité canonique un identifiant interne stable.
• Préserver les enregistrements sources et leurs identifiants originaux.
• Définir les noms de relation, les directions et les types d'entités autorisés.
• Représenter explicitement les qualifications et les dates d'entrée en vigueur.
• Joindre les preuves et la provenance à chaque affirmation importante.
• Gardez les conflits visibles jusqu'à ce qu'une règle approuvée ou un examinateur les résolve.
• Valider l'identité, la structure, les règles commerciales et les réponses attendues.
• Exposer les vues approuvées appropriées à chaque demande de consommation.
• Noter les affirmations qui appuyaient les réponses corrélatives.
• Mesurer la couverture des données probantes, la résolution des conflits et l'uniformité des voies.