Source Data Embedding (Schritt 0): Das Fundament legen

Dieser Artikel erklärt, wie wir alle auffindbaren Quellinhalte (Produkte, Teile und Onsite-Seiten) in einen gemeinsamen Vektorraum einbetten, um semantisches Matching über die SEO- und Such-Pipeline hinweg zu ermöglichen.

Das Problem: Abfragen und Inhalte nach Bedeutung abgleichen

Nutzer formulieren ihre Absicht mit vielen unterschiedlichen Formulierungen. Keyword-Matching versagt, wenn die Wortwahl der Abfrage nicht mit der Wortwahl im Katalog übereinstimmt.

Wir verwenden semantische Embeddings, damit sowohl Abfragen als auch Quellinhalte nach Bedeutung verglichen werden können (typischerweise über Kosinus-Ähnlichkeit).

Was eingebettet wird

Wir betten alle Inhalte ein, die ein Nutzer entdecken kann und die die Pipeline verarbeiten kann:

  • Produkte: Die verkäuflichen Katalogartikel (Titel + Merkmalstext + jeglicher kuratierter/KI-generierter Text).

  • Teile: Verkaufbare Komponenten und Zubehör (Namen + Spezifikationen).

  • Onsite-Seiten: Artikel (/a/) und andere navigierbare Seiten, die in Suchergebnissen und internen Links erscheinen können.

Das Einbetten aller auffindbaren Inhalte ermöglicht eine übergreifende Suche über verschiedene Inhaltstypen hinweg (z.B. kann ein Artikel für eine produktorientierte Abfrage ranken und ein Produkt kann für eine informative Abfrage ranken, wenn es angemessen ist).

High-Level-Architektur

flowchart TD
    A[Katalog + Teile + Seiten] --> B[Normalisieren & Beschreibungen erstellen]
    B --> C[Deduplizieren nach kanonischer URL]
    C --> D[Inkrementelles Embedding]
    D --> E[Quell-Embedding-Matrix + Key-Index]
    E --> F[Downstream: Matching, Routing, verwandte Suchen, Suchdienst]

Die Embedding-Pipeline

Schritt A: Quelldaten konsolidieren

  • Zweck: Einen kanonischen Datensatz von Quell-Items erstellen.

  • Eingaben: Produktkatalog, Teile-Datensatz und Seiteninhalte.

  • Ausgaben: Ein konsolidierter Quelldatensatz mit:

    • Keys: Kanonische URLs (als stabile Identifikatoren verwendet)
    • Beschreibungen: Text, der für das Embedding verwendet wird
    • Typen: Produkt / Teil / Artikel / Seite (für das Downstream-Routing)

  • Prozess:

    1. Items aus jeder Quelle extrahieren.
    2. Eine Beschreibung pro Item erstellen.
    3. Nach kanonischer URL deduplizieren, sodass jede URL nur einmal repräsentiert ist.

Schritt B: Inkrementelles Embedding

Wir verwenden Prinzipien des inkrementellen Lernens, um die Neuberechnung von Embeddings für unveränderte Inhalte zu vermeiden.

  • Zweck: Nur neue/geänderte Items einbetten, während zwischengespeicherte Embeddings für unveränderte Items wiederverwendet werden.

  • Eingaben: Konsolidierter Quelldatensatz und ein Embedding-Cache (vorheriger Lauf).

  • Ausgaben: Aktualisierte Embedding-Matrix und Key-Index.

  • Prozess:

    1. Zwischengespeicherte Keys und Embeddings laden.
    2. Ein Änderungssignal für jedes Item berechnen (basierend auf dem Embedding-Text des Items).
    3. Nur neue/geänderte Items mit dem konfigurierten Modell einbetten (siehe Embedding-Strategie).
    4. Zwischengespeicherte und neu berechnete Embeddings in einer stabilen Reihenfolge, die nach URL geordnet ist, zusammenführen.

Schritt C: Artefakte persistieren

Embeddings werden in einem effizienten numerischen Format (typischerweise über NumPy) gespeichert, zusammen mit einem separaten Key-Index, damit Downstream-Schritte Vektorzeilen wieder auf kanonische URLs abbilden können.

Beschreibungskonstruktion (Welchen Text wir einbetten)

Produkte

Produktbeschreibungen werden erstellt aus:

  • Vereinfachter Name: Produktname und Schlüssel-Identifikatoren (z.B. SKU/Serienbezeichnung).

  • Merkmalstext: Menschenlesbare Darstellung der Produktmerkmale (siehe SKU-Struktur).

  • Langform-Text: Kuratierter oder KI-generierter Text, sofern verfügbar (siehe Content AI Generation).

Beispiel (veranschaulichend):

<Produktname>
<Kurzbeschreibung>
<Hauptmerkmale>

Teile

Teilebeschreibungen werden erstellt aus:

  • Kundenorientierter Name

  • Interner Name (Technischer Identifikator)

  • Kategorie

  • Spezifikationen/Attribute als Text dargestellt

Onsite-Seiten

Seitenbeschreibungen werden erstellt aus:

  • Titel

  • Primärer Textausschnitt (Intro/Lead-Abschnitt)

  • Kontextuelle Identifikatoren (Kategorie/Familien-Labels, sofern zutreffend)

Das Ziel ist stabiler, inhaltsrepräsentativer Text, der sich ändert, wenn sich die Bedeutung der Seite ändert.

Deduplizierungsregeln

Jede kanonische URL erscheint einmal im konsolidierten Datensatz.

  • Warum: Mehrere Quellen können dieselbe URL über verschiedene Erzeugungspfade beschreiben; Duplikate brechen Routing, Matching und Downstream-Indizierung.

  • Wie: Ein nach kanonischer URL geordnetes Dictionary erstellen und Einzigartigkeit zum Zeitpunkt der Konsolidierung erzwingen. Falls Duplikate gefunden werden, gibt das Skript die Anzahl aus und entfernt sie.

Wie andere Schritte die Quell-Embeddings verwenden

  • Produkt-Matching: Cluster oder Abfragen werden mit den semantisch ähnlichsten Quell-Items abgeglichen (siehe SEO Product Matching).

  • Verwandte Suchen: Der Generator für verwandte Suchen verwendet Embedding-Ähnlichkeit, um relevante Navigationslinks vorzuschlagen (siehe SEO Related Searches).

  • Suchdienst: Der Online-Suchdienst kann Vektor-Ähnlichkeit über indizierte Embeddings nutzen (siehe Search Service Architecture).

Siehe auch

Referenzen

Zusammenfassung

  • Was: Produkte, Teile und auffindbare Seiten in einen gemeinsamen Vektorraum einbetten.

  • Wie: Nach kanonischer URL konsolidieren und deduplizieren, dann nur geänderte Items inkrementell einbetten.

  • Warum: Dies ermöglicht semantische Suche und Routing über die gesamte Pipeline hinweg (Matching, verwandte Suchen und Online-Vektorsuche).

← Zurück zum Dokumentationsindex