Wie man ein Produkt Knowledge Graph zu bauen, ohne Quelle Beweise zu verlieren

Beginnen Sie mit einer Frage, die das Unternehmen beantworten muss

Ein Wissensgraph ist nützlich, wenn er eine wiederholbare Entscheidung verbessert. Beginnen Sie mit Fragen wie dem, welches Ersatzteil für diese Maschine zugelassen ist, welche Lieferantenaufzeichnungen sich auf dasselbe Produkt beziehen, welche Produktaussagen durch ein aktuelles Dokument unterstützt werden oder welche Organisation eine bestimmte Marke besitzt. Vermeiden Sie es, mit einem Ziel zu beginnen, alles zu verbinden.

Schreiben Sie die erwartete Antwort und die Beweise, denen ein Rezensent vertrauen müsste. Eine Anpassungsantwort kann beispielsweise die Produktidentität, den Maschinenhersteller und das Modell, den Produktionsbereich, die Position, das Quelldokument, das Quelldatum und den Überprüfungsstatus erfordern. Diese Liste wird zum ersten Teil des Modells.

M.I.A.I Knowledge Graph wurde entwickelt, um Entitäten, Beweise und Beziehungen zu wiederverwendbarem Geschäftswissen zu verbinden. Die genehmigten Fähigkeiten umfassen kanonische Einheiten, Beziehungsmodellierung, Evidenzherkunft und wiederverwendbaren Wissenszugang, einschließlich Produkt-zu-Anwendung-Links, doppelte Auflösung und evidenzbewusste Antworten.

Separate Entitäten, Attribute und Beziehungen

Eine Entität ist eine Sache mit eigener Identität: ein Produkt, eine Produktvariante, ein Maschinenmodell, ein Hersteller, eine Organisation, ein Dokument oder ein Standort. Ein Attribut ist ein Wert, der eine Entität beschreibt, z. B. ein Modellname, ein Gewicht oder ein Veröffentlichungsdatum. Eine Beziehung verbindet zwei Entitäten, wie z. B. made-by, compatible-with, oversedes oder evidenced-by.

Die Unterscheidung verhindert ein gemeinsames Katalogproblem. Wenn eine Maschinenanwendung nur als Freitext in einer Produktbeschreibung gespeichert wird, kann sie nicht zuverlässig überprüft, abgefragt oder aktualisiert werden. Wenn das Maschinenmodell eine Einheit und Kompatibilität eine explizite Beziehung ist, kann das Unternehmen alle unterstützenden Ansprüche prüfen, Konflikte finden und das gleiche Wissen in der Suche, Produktseiten und Support-Tools wiederverwenden.

Das W3C RDF-Modell beschreibt Graphenaussagen als Subjekt-Prädikat-Objekt-Tripel. Das ist ein nützliches mentales Modell, auch wenn die erste Implementierung relationale Tabellen oder Dokumente verwendet. Der wichtige Punkt ist, dass die Beziehung eine explizite Richtung und Bedeutung hat, anstatt aus einem gemeinsamen Textfeld abgeleitet zu werden.

• Einheit: Produkt P-1042
• Beziehung: ist kompatibel mit
• Einheit: Maschinenmodell M-208
• Qualifikation: vordere Leerlaufstellung und anwendbarer Produktionsbereich
• Nachweis: Lieferantenbulletin B-77, Seite 4
• Status: überprüft und genehmigt an einem aufgezeichneten Datum

Erstellen Sie kanonische Identitäten, ohne Quelldatensätze zu löschen

Eine kanonische Entität repräsentiert die aktuelle Sicht des Unternehmens auf eine reale Sache. Es sollte eine interne stabile Kennung haben, die nicht von einem Titel, einer URL oder einer Lieferantenbeschreibung abhängt. Quelldatensätze bleiben mit ihren eigenen Identifikatoren, Werten und Zeitstempeln verknüpft.

Verschmelzen Sie keine Datensätze, nur weil ihre Namen einander ähneln. Produkttitel, Firmennamen und Modellbeschreibungen enthalten Abkürzungen, Interpunktionsunterschiede und wiederverwendete Wörter. Starke Beweise können eine geregelte SKU, GTIN, Herstellerteilnummer, Plattform-ID, Firmenregistrierungsnummer oder einen genehmigten Kompositschlüssel sein. Der akzeptable Nachweis unterscheidet sich je nach Entitätstyp.

Die Entitätsabwicklung sollte eine Entscheidung und ihre Grundlage zurückgeben: bestätigte gleiche Entität, mögliche Übereinstimmung, die eine Überprüfung erfordert, oder separate Entität. Bewahren Sie abgelehnte und ersetzte Match-Entscheidungen bei, damit der nächste Import nicht die gleiche Mehrdeutigkeit erzeugt. Wenn sich zwei Quelldatensätze widersprechen, kann der Graph beide mit der kanonischen Entität verbinden, während die widersprüchlichen Ansprüche getrennt bleiben.

Definieren Sie ein kleines Beziehungsvokabular

Beziehungsnamen sind Teil des Geschäftsvertrags. Definieren Sie jeden Begriff, seine Richtung, die zulässigen Entitätstypen und ob er symmetrisch, transitiv oder zeitgebunden ist. Related-to ist selten präzise genug für eine operative Entscheidung.

Für Produkte können nützliche Unterscheidungen umfassen is-Variante, ersetzt, ersetzt, ist-kompatibel, ist-verbrauchbar-für, hergestellt-von und verteilt-von. Das Produktvokabular von Schema.org veranschaulicht mehrere verschiedene Produktverbindungen, darunter isVariantOf, isRelatedTo, isSimilarTo und isConsumableFor. Diese Etiketten sollten nicht als austauschbar behandelt werden.

Bevorzugen sie eine genehmigte beziehung gegenüber mehreren fast duplizierten. Wenn ein Team Fits verwendet, gilt ein anderes für und ein anderes ist kompatibel, entscheiden Sie, ob sie die gleiche geschäftliche Bedeutung haben. Wo sich die Bedeutung wirklich unterscheidet, behalten Sie separate Begriffe und dokumentieren Sie den Unterschied. Durch konsistentes Vokabular sind Abfragen, Validierungen und Benutzererklärungen zuverlässig.

Behandlung der Vereinbarkeit als qualifizierter Anspruch

Viele Geschäftsbeziehungen benötigen mehr Kontext als eine einfache Linie zwischen zwei Knoten. Die Produktkompatibilität kann von der Serienpalette, dem Jahr, dem Motor, der Konfiguration, der Position oder der regionalen Variante der Maschine abhängen. Lieferantenbeziehungen können Vertragsdaten und -gebiete haben. Organisationseigentum ändert sich im Laufe der Zeit.

Repräsentieren Sie diesen Kontext in einem Relationship Record oder einer Assertion Entity. Speichern Sie das Thema, den Beziehungstyp, das Objekt, die Qualifikationen, die effektiven Daten, den Nachweis, den Vertrauens- oder Überprüfungsstatus und den verantwortlichen Eigentümer. Verstecken Sie keine Qualifikationen in einer Notiz, die Anwendungen nicht interpretieren können.

Die W3C RDF-Spezifikation stellt fest, dass sich Beziehungen im Laufe der Zeit ändern können und dass Quellen unterschiedliche Graphenzustände zu unterschiedlichen Zeiten bereitstellen können. In der Praxis, überschreiben Sie nicht die gestern genehmigte Beziehung ohne Geschichte. Schließen Sie den gültigen Zeitraum, erstellen Sie die überarbeitete Bestätigung und behalten Sie den Grund für die Änderung.

Fügen Sie Provenienz zu Ansprüchen, nicht nur Dateien

Das Speichern einer Quell-PDF in einem Ordner reicht nicht aus. Verknüpfen Sie den genauen Anspruch mit dem Quelldatensatz, der Dokumentversion, der Seite oder Zeile, der Extraktionsmethode, der Erfassungszeit und dem Reviewer. Ein Benutzer sollte in der Lage sein, von einer Antwort auf die Behauptung und dann zu den Beweisen zu gelangen, die sie unterstützen.

Das W3C PROV-O-Modell bietet Konzepte zur Beschreibung von Entitäten, Aktivitäten und Agenten, einschließlich Ableitung, Erzeugung und Zuordnung. Eine Geschäftsimplementierung muss dieses Vokabular nicht jedem Benutzer aussetzen, aber sie sollte die gleichen Fragen bewahren: Woraus wurde dieser Anspruch abgeleitet, welcher Prozess hat ihn geschaffen und wer oder was war verantwortlich?

Halten Sie die Quelle Beweise unveränderlich, wo praktisch. Wenn sich eine Lieferanten-Webseite ändert, behalten Sie die erfasste Version oder die durch die Quellvereinbarung zulässige Prüfsumme bei. Wenn eine Tabelle korrigiert wird, erstellen Sie eine neue Quellversion, anstatt die Beweise für eine bestehende Genehmigung stillschweigend zu ändern.

• Quellsystem und Quelldatensatzkennung
• Dokumentversion, URL, Seite, Zeile oder Abschnitt
• Erfasster Wert und erfasster Zeitstempel
• Umwandlungs- oder Extraktionsverfahren
• Reviewer, Entscheidung und Datum der Entscheidung
• Gültigkeitsdauer, Revisions- und Supersession-Links

Umgang mit widersprüchlichen Forderungen sichtbar

Ein Graph wird gefährlich, wenn er Meinungsverschiedenheiten in falsche Gewissheit verwandelt. Zwei Lieferanten können unterschiedliche Dimensionen bereitstellen, ein Herstellerdokument kann ein altes Bulletin ersetzen oder eine ERP-Beschreibung kann mit einem Produktdatenblatt nicht übereinstimmen. Speichern Sie jede Behauptung mit ihren Beweisen, bevor Sie einen bevorzugten Wert auswählen.

Präzedenzregeln sollten explizit und auf eine Domäne beschränkt sein. Das ERP kann den verkaufbaren SKU-Status besitzen, der Hersteller kann die technische Kompatibilität besitzen, das PIM kann eine genehmigte Marketingkopie besitzen und eine Commerce-Plattform kann seine Ziel-ID besitzen. Ein kürzlich bearbeiteter Datensatz ist nicht automatisch der maßgeblichste Datensatz.

Wenn Regeln einen Konflikt nicht lösen können, legen Sie ihn in eine Warteschlange mit den betroffenen Entitäten, Werten, Quellen und nachgelagerten Verwendungen. Halten Sie die letzte genehmigte Aussage weiterhin bereit, wenn sie sicher ist, kennzeichnen Sie gegebenenfalls Unsicherheit und blockieren Sie die Veröffentlichung mit hohem Risiko, wenn es keine vertrauenswürdige Antwort gibt.

Ein konkretes Beispiel: ein Teil, drei Systeme und zwei Maschinenmodelle

Betrachten Sie einen Händler mit einem Leerlauf, der in einem ERP als Artikel 1042, in einer Lieferantendatei unter einer Herstellerteilnummer und in einem Online-Shop mit einer separaten Produkt- und Varianten-ID aufgezeichnet ist. Die Lieferanten-Tabelle sagt, es passt zwei kompakte Track-Loader-Modelle, während eine ältere PDF-Listen nur eine.

Der Graph erstellt eine kanonische Teilentität und verknüpft jeden Quelldatensatz mit ihr, ohne die ursprünglichen IDs zu löschen. Es erstellt separate Hersteller-, Produkt-, Maschinenmodell- und Beweisdokument-Entitäten. Zwei Kompatibilitätsbehauptungen verbinden das Teil mit den Maschinenmodellen. Jede Behauptung zeichnet ihre Position, den anwendbaren Bereich, die Quelle und den Überprüfungsstatus auf.

Das erste Modell wird sowohl von der aktuellen Tabellenkalkulation als auch vom älteren Bulletin unterstützt, so dass der Produktspezialist es genehmigt. Die zweite erscheint nur in der neuen Tabellenkalkulation und bleibt anhängig, bis der Herstellernachweis überprüft wird. Storefront-Suche und eine antwortende Anwendung können die genehmigte Beziehung verwenden, dürfen jedoch die anhängige nicht als Tatsache darstellen.

Wenn ein überarbeitetes Bulletin das zweite Modell bestätigt, verknüpft der Rezensent die neuen Beweise und genehmigt die Behauptung. Die Antwort kann nun die Anpassung erklären und das unterstützende Bulletin zitieren. Wenn der Teil später ersetzt wird, zeichnet eine neue Beziehung den Ersatz auf, ohne die Identität oder den Verlauf des ursprünglichen Elements zu ändern.

Validieren Sie den Graphen, bevor Anwendungen ihn wiederverwenden

Die Validierung sollte Identität, Struktur und Geschäftsbedeutung umfassen. Überprüfen Sie, ob kanonische Identifikatoren eindeutig sind, erforderliche Entitätstypen vorhanden sind, Beziehungsendpunkte zulässige Typen verwenden und obligatorische Qualifikatoren vorhanden sind. Ein Kompatibilitätsanspruch ohne Quell- oder Überprüfungsstatus sollte eine kundenorientierte Anwendung nicht erreichen.

Hinzufügen von Domänenregeln für unmögliche oder verdächtige Strukturen. Ein Produkt sollte sich nicht selbst ersetzen. Eine Variante sollte nicht zu mehreren nicht verwandten Mutterprodukten gehören, es sei denn, das Modell erlaubt dies ausdrücklich. Zirkulare Ersatzketten, überlappende Gültigkeitsbereiche und doppelte aktive Aussagen verdienen eine Überprüfung.

Testen Sie repräsentative Anfragen und erwartete Antworten. Fügen Sie positive Fälle, absichtliche Konflikte, unvollständige Beweise und widerrufene Ansprüche hinzu. Der Graph ist nur dann zur Wiederverwendung bereit, wenn Anwendungen genehmigtes, ausstehendes, ersetztes und abgelehntes Wissen unterscheiden können.

Geben Sie Anwendungen nur das Wissen, das sie verwenden dürfen

Wiederverwendbarer Zugriff bedeutet nicht uneingeschränkten Zugriff. Definieren Sie Ansichten oder APIs für jede Anwendung. Ein öffentlicher Produktfinder kann genehmigte Produktbeziehungen und kundensichere Beweisetiketten erhalten. Ein internes Support-Tool kann anhängige Ansprüche und Reviewer-Notizen sehen. Eine Audit-Schnittstelle benötigt möglicherweise die vollständige Herkunftskette.

Geben Sie die kanonische Entitätskennung, die Antwort, den Beziehungstyp, die relevanten Qualifikatoren, den Status und die Beweisreferenz zusammen zurück. Geben Sie einem KI-Assistenten keinen abgeflachten Textexport und erwarten Sie, dass er die Autorität rekonstruiert. Evidenzbewusste Antworten erfordern einen strukturierten Abruf, der die Grundlage der Antwort in den Antwortprozess trägt.

Loggen Sie, welche Graphenversion und Behauptungen eine wichtige Antwort unterstützten. Wenn sich das Wissen ändert, kann das Unternehmen betroffene Seiten, Empfehlungen oder Support-Antworten identifizieren und entscheiden, ob sie aktualisiert werden müssen.

Messen Sie Vertrauen und Wiederverwendung, nicht Grafikgröße

Node und Beziehungszählungen zeigen Aktivität, nicht Geschäftswert. Messen Sie doppelte Entitäten, Prozentsatz der kritischen Behauptungen mit Beweisen, Zeit zur Überprüfung von Konflikten, festgestellte veraltete Ansprüche, Anwendungen, die genehmigtes Wissen wiederverwenden und Fragen, die ohne manuelle Recherche beantwortet wurden.

Track Qualität nach Beziehungstyp. Produkt-zu-Anwendung-Links erfordern möglicherweise vollständige Nachweise und eine fachkundige Genehmigung, während ein Link mit geringem Risiko in Bezug auf Inhalte einen leichteren Prozess verwenden kann. Ein einziger Vollständigkeitswert kann ernsthafte Lücken in den Beziehungen verbergen, die am wichtigsten sind.

Überprüfen Sie, ob der Graph widersprüchliche Antworten über Kanäle hinweg reduziert. Wenn die Produktsuche, der Kundensupport und die Produktseiten immer noch nicht übereinstimmen, überprüfen Sie die genehmigten Ansichten, den Cache und das Quelleigentum, anstatt weitere Daten hinzuzufügen.

Vollständigkeits-Checkliste

• Beginnen Sie mit einer definierten Geschäftsfrage und erwarteten Entscheidung.
• Geben Sie jeder kanonischen Entität eine stabile interne Kennung.
• Bewahren Sie Quelldatensätze und ihre ursprünglichen Identifikatoren auf.
• Definieren Sie Beziehungsnamen, Anweisungen und erlaubte Entity-Typen.
• Stellen Sie Qualifikationen und effektive Daten explizit dar.
• Belege und Herkunft für jede wichtige Behauptung beifügen.
• Halten Sie Konflikte sichtbar, bis eine genehmigte Regel oder ein Reviewer sie löst.
• Validierung von Identität, Struktur, Geschäftsregeln und erwarteten Antworten.
• Freigabe genehmigter Ansichten, die für jede verbrauchende Anwendung geeignet sind.
• Notieren Sie, welche Behauptungen konsequente Antworten unterstützten.
• Messen Sie die Evidenzabdeckung, Konfliktlösung und kanalübergreifende Konsistenz.