E-Commerce-Produktsuche im 100.000-Item-Skala

13 Minuten Lesezeit

Ein E-Commerce-Produktsuchalgorithmus für 100.000 Artikel kann keine einzige Eingabeaufforderung sein.Der Katalog ist eine sich ändernde Datenbank mit Varianten, regionalen Preisen, Kompatibilitätsregeln, Inventar, Werbeaktionen, Garantien und Lieferbeschränkungen.

Entwickler greifen immer noch zuerst nach dem Kontextfenster. Exportieren Sie den Produktfeed, chunken Sie ihn, betten Sie ihn ein, holen Sie einige Passagen ab und bitten Sie das Modell zu wählen. Das kann eine überzeugende Demo produzieren. Es produziert auch das falsche Laptop-Ladegerät, empfiehlt eine nicht verfügbare Größe, zitiert den gestrigen Preis und verliert die Unterscheidung zwischen einer Produktfamilie und einer käuflichen Variante.

Ein größeres Kontextfenster lässt Sie nur den gleichen Kategoriefehler zu größeren Kosten machen.

Das Sprachmodell kann die Anfrage des Kunden interpretieren und das Ergebnis erklären. Es sollte nicht den vollständigen Katalog scannen, fehlende Attribute erfinden oder als maßgebliche Quelle für flüchtige Fakten fungieren.

Wie E-Commerce-Produktsuche zu einer Agent-Schnittstelle wird

Dies ist keine hypothetische Traffic-Quelle mehr. OpenAI hat sein Agentic Commerce Protocol auf die Produkterkennung erweitert, wobei Händler Produkt-Feeds und Werbeaktionen anbieten, damit Kataloge in ChatGPT erscheinen können. Sein aktueller Einkaufsforschungsfluss kann Händlerproduktdaten, öffentliche Produktinformationen und andere Einzelhandelsquellen verwenden und dann einen kleinen Satz Top-Picks mit Kompromissen zurückgeben. OpenAI's Product Discovery Ankündigung und Shopping Research Dokumentation Machen Sie das Architekturproblem sichtbar: Agenten benötigen eine vollständige Produktabdeckung, aber Benutzer benötigen eine kurze, relevante Antwort.

Diese Ziele gehen in entgegengesetzte Richtungen. Abdeckung gehört in die Retrieval-Infrastruktur. Auswahl gehört in eine begrenzte Ranking-Pipeline. Nur die endgültigen Kandidaten gehören in den Modellkontext.

Ein Produkt ist nicht ein Dokument

Nehmen wir eine Industriepumpe, die in vier Spannungsvarianten in sechs Märkten verkauft wird.

• stabile Identität, Marke, Familie und Modell
• technische Merkmale und kompatible Ausrüstungen
• Produkt- und Konformitätsdokumente
• Marktzulassungs- und Kundensegmentbeschränkungen
• SKU auf Variantenebene, Spannung, Abmessungen und Vorlaufzeit
• Preislisten, Vertragspreise und aktive Promotions
• Bestandsaufnahme nach Standort
• Ersatz- und Ersatzmodelle

Das Abflachen in Prosa schadet den Informationsentwicklern am meisten. Ein Satz wie "Verfügbar in 230V und 400V ab 2.400 Euro" kann dem Vollstrecker nicht sagen, welche SKU 2.400 Euro kostet, für welchen Kunden, in welchem Land oder ob sie auf Lager ist.

Erstellen Sie ein kanonisches Produktmodell, das Identitäten und Beziehungen bewahrt:

type CatalogVariant = {
  productId: string
  variantId: string
  sku: string
  title: string
  taxonomy: string[]
  attributes: Record<string, string | number | boolean>
  compatibilityIds: string[]
  marketIds: string[]
  evidenceRefs: Array<{ type: string; digest: string; uri: string }>
  searchableText: string
  embeddingRef?: string
}

Preis und Inventar gehören nicht in diesen stabilen Index, es sei denn, Sie können ihre Abgestandenheit tolerieren. Sogar das gleiche Produkt kann kontextbezogene Preise nach Land oder Käufersegment haben. Shopify zum Beispiel zeigt die Produktpreise in einem bestimmten Land durch seine kontextuelle Preis-API, anstatt einen Katalogpreis als universell zu behandeln. Shopify's ProductContextualPricing Referenz ist eine nützliche Erinnerung, dass "der Preis" oft ein Funktionsaufruf ist.

Verwandeln Sie die Anfrage in eine typisierte Absicht

Angenommen, ein Anlageningenieur fragt:

Finden Sie eine Ersatzpumpe für das Modell XJ-40, 400V, lebensmittelsichere Dichtungen, Lieferung nach Hamburg bis Freitag, unter 3.500 Euro.

Die erste Aufgabe des Modells besteht darin, keine Pumpe zu empfehlen, sondern einen getippten Abfrageplan zu erstellen und Unsicherheiten aufzudecken:

{
  "category": "industrial_pump",
  "must": {
    "voltage": "400V",
    "seal_certification": "food_safe",
    "compatible_with": "model:XJ-40",
    "delivery_region": "DE-HH",
    "latest_delivery_date": "2026-08-14",
    "currency": "EUR",
    "max_total": "3500.00"
  },
  "preferences": {
    "energy_efficiency": "higher_is_better",
    "warranty_months": "higher_is_better"
  },
  "unresolved": []
}

Wenn sich "lebensmittelsicher" auf die benetzten Teile, das Schmiermittel oder die gesamte Baugruppe beziehen könnte, stellen Sie vor dem Abruf eine Frage.

Verwenden Sie eine Staged Retrieval Pipeline

Ein praktischer Großkatalogpfad sieht so aus:

intent parsing
  -> hard structured filters
  -> lexical retrieval
  -> semantic retrieval
  -> compatibility expansion
  -> candidate fusion
  -> live price, inventory and delivery calls
  -> policy and eligibility checks
  -> learned or rules-based reranking
  -> 3 to 10 candidates for the model

Jede Phase hat einen anderen Job.

Strukturierte Filter erzwingen Fakten, die wahr sein müssen: Spannung, Markt, Zertifizierung, Größe, Käuferberechtigung. Setzen Sie diese Filter vor dem teuren Abruf, wenn möglich.

Lexical Suche fängt Identifikatoren und genaue Sprache. XJ-40-R2Teilenummern und Normen wie DIN 11864 Leistung oft besser mit einem invertierten Index als eine Einbettung.

Semantic Retrieval hilft bei Beschreibungen, die keine genauen Begriffe teilen. "Ruhepumpe für eine kleine Milchlinie" kann Produkte entsprechen, die durch Dezibelstufen und Sanitäranwendungen beschrieben werden.

Kompatibilität ist ein graphisches Problem. Ein Austausch kann einen Adapter, einen Firmware-Boden oder eine verbotene Kombination erfordern. Reduzieren Sie dies nicht auf nahe gelegene Vektoren.

Fusion kombiniert unabhängig eingestufte Kandidatenlisten. Reziproke Rangfusion ist eine Option, aber die genaue Methode ist weniger wichtig als die Erhaltung der einzelnen Abrufsignale für das Debugging.

Live-Anreicherung ruft maßgebliche Systeme für den aktuellen Preis, Promotion, Lager und Lieferversprechen auf.

Das Reranking bewertet die Kandidaten in Bezug auf Benutzernutzen und Transaktionsdurchführbarkeit. Es kann den erwarteten Liefererfolg, das Renditerisiko oder historische Kompatibilitätsergebnisse umfassen, aber keine harten Einschränkungen in weiche Präferenzen umwandeln.

Halten Sie harte Filter aus der Scoring-Funktion heraus

Ein Team gibt Kompatibilität ein großes positives Gewicht und Preis ein großes negatives Gewicht. Ein billiger inkompatibler Teil kann immer noch gewinnen, wenn die Gewichte schlecht ausgerichtet sind.

Stellen Sie nicht verhandelbare Anforderungen als Eignungskriterien dar:

function eligible(candidate: EnrichedCandidate, intent: Intent): boolean {
  return candidate.marketEligible
    && candidate.compatibility.status === 'verified'
    && candidate.voltage === intent.must.voltage
    && candidate.delivery.latestDate <= intent.must.latestDeliveryDate
    && decimal(candidate.totalPrice).lte(decimal(intent.must.maxTotal))
}

function score(candidate: EnrichedCandidate): number {
  return 0.35 * candidate.semanticRelevance
    + 0.25 * candidate.deliveryConfidence
    + 0.20 * candidate.energyEfficiency
    + 0.10 * candidate.warrantyScore
    + 0.10 * candidate.outcomeQuality
}

Die Koeffizienten sind illustrativ. Die Trennung ist nicht. Zuerst entscheiden Sie, ob ein Produkt den Antrag erfüllen kann. Dann stufen Sie die förderfähigen Produkte ein.

Geben Sie dem Modell kompakte Beweise, nicht Katalogprosa

Der endgültige Kontext sollte eine Handvoll normalisierter Kandidatenkarten enthalten:

{
  "variant_id": "variant:pump-821:400v",
  "matched_constraints": [
    "400V",
    "food_safe_seals",
    "verified_replacement_for:XJ-40"
  ],
  "price": {
    "amount": "3275.00",
    "currency": "EUR",
    "observed_at": "2026-08-11T09:42:10Z"
  },
  "inventory": {
    "status": "available",
    "location": "DE-HAM-2",
    "observed_at": "2026-08-11T09:42:11Z"
  },
  "delivery": {
    "latest_date": "2026-08-14",
    "confidence": 0.93
  },
  "evidence": [
    { "type": "compatibility_matrix", "digest": "sha256:..." }
  ]
}

Jetzt kann das Modell erklären, warum dieser Kandidat passt, Kompromisse vergleichen und um Bestätigung bitten.

Behandeln Sie Discovery und Transaktionszustand unterschiedlich

Das Universal Commerce Protocol unterscheidet Exploration von Kaufabschluss. Seine Cart-Fähigkeit unterstützt die Sammlung von Artikeln vor dem Kauf, während Checkout Zahlungsabwickler, Status und Auftragsabschluss einführt. UCP sagt auch, dass die Berechtigung zur Checkout-Zeit und die Durchsetzung von Richtlinien verbindliche Transaktionsdaten anstelle eines vorläufigen Kontexts verwenden müssen. UCP Cart und UCP Checkout eine wichtige Grenze unterstützen: Ein Entdeckungsergebnis ist ein Kandidat, kein Versprechen.

Wenn sich der Preis ändert, sollte der Agent die Änderung anzeigen oder die Genehmigung gemäß den Richtlinien anfordern.

Fehlerfälle, die es wert sind, im Evaluationsset aufbewahrt zu werden

Erstellen Sie Fälle, die für ein Sprachmodell plausibel aussehen, aber kommerziell fehlschlagen:

Zurückrufen von Einschränkungen vor der Top-K-Relevanz messen. Rückrufen von exakten Identifikatoren, Rückrufen von kompatiblen Ergebnissen, Rückrufen von veralteten Zuständen, Nicht-unterstützte Anspruchsrate, Null-Ergebnisqualität und der Prozentsatz der endgültigen Kandidaten, die die Checkout-Aktualisierung überleben. Klickrate allein belohnt attraktive Fehler.

Eine Produktbeschreibung kann stundenlang nützlich bleiben, während ein Inventarversprechen nach Sekunden unsicher sein kann. Frische nach Feld und Markt festlegen, anstatt eine Zeit bis zum Leben auf den gesamten Kandidaten anzuwenden. observed_at, Quelle und Version durch jede Retrieval-Phase. Wenn eine Live-Abhängigkeit nicht verfügbar ist, unterscheiden Sie "out of stock" von "stock unknown". Der erste ist eine kommerzielle Tatsache. Der zweite ist eine Systembedingung. Ein Agent, der beide in denselben freundlichen Satz zusammenbricht, wird Vorfälle verbergen und gültige Verkäufe verlieren. Für hochwertige oder knappe Bestände sollte ein Suchergebnis ein Reservierungstool auslösen, bevor der Agent die Verfügbarkeit für den Käufer impliziert.

Was Intelliger jetzt hat und was diese Architektur beschreibt

Der hier beschriebene kanonische Commerce Graph, Katalogindexierungsdienst, Merchant Agent Runtime, Kompatibilitätsgraph, gelernter Reranker und ergebnisbewusstes Routing sind Zielzustandskomponenten in Intelligers Agentic-Commerce-Blueprint vom August 2026.

Die implementierte OATI-Entwicklervorschau deckt eine andere Ebene ab: Schemata, signierte Pass- und Mandatsobjekte, kanonische Anforderungsbindung, deterministische Commerce-Einschränkungen, Quittungen, Middleware und gemeinsam genutzte Konformitätsvektoren. Die lokale Sandbox zeigt eine signierte Paid-API-Transaktion und das gehostete Commerce-Profil beweist die Entdeckung und Überprüfung des Profilvertrags. Es beweist keine Live-Bereitstellung von 100.000 Produkten.

Checkliste der Durchführung

• Normalisieren Sie Produkte, Varianten, Angebote und Händler in separate Identitäten.
• Halten Sie stabile deskriptive Fakten abgesehen von volatilen Transaktionszustand.
• Parse Anfragen in getippte Einschränkungen, Präferenzen und ungelöste Fragen.
• Bewerben Sie harte Filter vor dem Ranking.
• Bewahren Sie den lexikalischen Abruf für SKUs, Standards und genaue Namen auf.
• Verwenden Sie semantische Retrieval für deskriptive Absicht, nicht autoritative Fakten.
• Modellkompatibilität mit typisierten beziehungen und beweisen.
• Holen Sie sich Preis, Lager, Promotion und Lieferung von autoritativen Systemen spät.
• Bind aktualisiertes Angebot Zustand vor dem Checkout.
• Senden Sie nur einen kleinen evidenzreichen Kandidaten, der auf das Modell eingestellt ist.
• Log Retrieval-Phase Gründe, damit Entwickler Ausschlüsse rekonstruieren können.
• Bewerten Sie plausible falsche Antworten, abgestandenen Zustand und prompte Injektion.

Der Katalog gehört in Indizes, Graphen und autoritative APIs. Das Modell braucht die Absicht des Kunden und eine kleine Gruppe verifizierter Kandidaten. Alles zu geben ist keine Vollständigkeit.

Verwendung der AI Shopping Agent Readiness Guide um Produktidentitäts- und Fähigkeitslücken rund um diese Pipeline zu beheben. AI Search Optimization Framework Retrieval-Ausfälle werden also eher messbar als anekdotisch.