E-Commerce Product Discovery für KI-Agenten
Entwerfen Sie Produktdaten, Abrufe, Live-State-Checks und -Bewertungen, die KI-Agenten dabei helfen, geeignete Produkte zu finden, ohne Preis oder Verfügbarkeit zu erfinden.

E-Commerce-Produkterkennung für KI-Agenten ist der Prozess, bei dem die Anfrage eines Käufers in einen kurzen, vertretbaren Satz von käuflichen Varianten umgewandelt wird. Es braucht zwei Datenpfade: einen Index für stabile Produktfakten und eine Laufzeitsuche für volatile Fakten wie Preis, Inventar, Förderfähigkeit und Lieferversprechen. Wenn diese Pfade in einen veralteten Index zusammenfallen, wird der Agent schließlich eine Option empfehlen, die er nicht kaufen kann.
Dieser Leitfaden richtet sich an Commerce-Architekten und Suchingenieure, die eine Implementierung benötigen, die sie testen können, nicht eine weitere Katalog-Feed-Checkliste. Das Ergebnis ist ein Discovery-Service, der erklären kann, warum eine Variante übereinstimmt, nachweisen kann, dass harte Einschränkungen erfüllt wurden, und das Angebot vor einer Folgemaßnahme revalidieren kann.
Es ist Teil von Intelligers Agentic Commerce Architektur Guide, die Discovery mit Transaktions- und Vertrauensgrenzen verbindet.
Was Produktentdeckung in einem Agentensystem bedeutet
Herkömmliche Website-Suche optimiert oft eine Liste für einen Menschen, der Filter, Abzeichen und Produktseiten einsehen kann. Ein Agent benötigt einen kleineren und expliziteren Vertrag. Er muss eine unterspezifizierte Anfrage lösen, Varianten vergleichen, harte Einschränkungen bewahren und wissen, welche Fakten eine neue Suche erfordern.
Verwenden Sie diese Definitionen konsequent:
- Produkt ist das langlebige kommerzielle Konzept, wie ein Schuhmodell.
- Variante ist eine käufliche Konfiguration mit eigener Kennung, wie Größe 44 in Schwarz.
- Indexierte Fakten ändert sich langsam genug, um in einem suchindex zu leben, wie material, dimensionen oder kompatibilität.
- Lebender Staat kann zwischen Abruf und Aktion, wie Lager, Preis oder Lieferschätzung, wechseln.
- Förderfähigkeit Es ist eine harte Entscheidung, die aus Einschränkungen, Richtlinie und Live-Zustand abgeleitet wird.
- Präferenz beeinflusst das Ranking, macht aber keinen nicht anerkennungsfähigen Posten förderfähig.
OpenAI beschreibt Produkt-Feeds als eine Möglichkeit für Händler, Kataloge und Werbeaktionen in ChatGPT darzustellen, während lokale Verfügbarkeit und ETAs als sich entwickelnde Commerce-Fähigkeiten beschrieben werden.OpenAI ProduktentwicklungShopifys agentenorientierte Shopbeschreibung zeigt Discovery-Endpunkte, schreibgeschützte Produktdaten und Commerce-Fähigkeiten, anstatt anzunehmen, dass eine Seite jede Antwort enthält ()Shopify agents.md DokumentationBeide weisen auf einen Vertrag hin, der aus strukturierten Daten und abrufbaren Fähigkeiten besteht.
Bauen Sie zwei Datenebenen, nicht ein übergroßes Dokument
Der Entdeckungspfad sollte als einfaches Zustandsmodell lesbar sein:
- aufgenommenQuelldatensätze werden kanonischen Produkt- und Variantenidentitäten zugeordnet.
- Indexiert: stabile Fakten sind durchsuchbar und tragen Quellzeitstempel.
- AbrufenKandidaten entsprechen lexikalischen, semantischen und strukturierten Einschränkungen.
- validiertAutoritative Dienstleistungen bestätigen aktuellen Preis, Aktien und andere volatile Fakten.
- Rangfolge: Berechtigte Kandidaten werden mit Präferenzen und Beweisqualität bestellt.
- GestelltDer Agent erhält einen kleinen Satz mit Gründen und Frische-Metadaten.
- Revalidiert: Das ausgewählte Angebot wird vor dem Warenkorb oder Checkout erneut überprüft.
In zugänglichen Begriffen antwortet der Index "Was könnte passen?" und Live-Systeme antworten "Was kann jetzt gekauft werden?" Der Agent sollte niemals aufgefordert werden, widersprüchliche Bestandsaufnahmen selbst in Einklang zu bringen.
type Currency = 'USD' | 'EUR' | 'GBP';
interface IndexedVariant {
productId: string;
variantId: string;
title: string;
attributes: Record<string, string | number | boolean>;
categoryPath: string[];
compatibleWith: string[];
sourceUpdatedAt: string;
}
interface LiveOffer {
variantId: string;
market: string;
priceMinor: number;
currency: Currency;
availableQuantity: number | null;
purchasable: boolean;
promotionIds: string[];
delivery?: { postalCode: string; earliestDate: string };
observedAt: string;
expiresAt: string;
}
interface DiscoveryCandidate {
variant: IndexedVariant;
offer: LiveOffer;
eligible: boolean;
failedConstraints: string[];
preferenceScore: number;
evidence: Array<{ field: string; source: string; observedAt: string }>;
}
Nicht kopieren priceMinor oder availableQuantity Das Google Merchant Center definiert ausdrücklich Verfügbarkeitswerte und erwartet, dass die Verfügbarkeit von Landingpages und Checkouts übereinstimmt.Google VerfügbarkeitsspezifikationEin interner Agentendienst benötigt mindestens die gleiche Disziplin.
Identität normalisieren, bevor das Ranking verbessert wird
Eine Lieferanten-SKU, ERP-Materialnummer, Marktplatzliste und Storefront-Variante können sich auf dieselbe verkaufbare Einheit beziehen.
canonical_variant: shoe-482-black-44
identifiers:
merchant_sku: SH482-BLK-44
gtin: '00012345678905'
erp_material: '4820044'
attributes:
color: black
size_system: EU
size: 44
provenance:
attributes: pim://products/482/version/91
compatibility: rules://footwear/2026-07-15
Datensätze nicht still zusammenführen, nur weil ihre Titel ähnlich sind. Erforderlich einen deterministischen Schlüssel oder eine überprüfte Abgleichregel. Bewahren Sie den Originalwert neben dem normalisierten Wert, insbesondere für Einheiten, Farbfamilien und regionale Größen. Das Original unterstützt Audit und Korrektur; der normalisierte Wert unterstützt das Abrufen.
Bei Bundles und konfigurierbaren Produkten, Modellkomponenten und Auswahlregeln muss ein Agent, der nach "Laptop mit 32 GB RAM" fragt, wissen, ob 32 GB eine Vorratsvariante, eine Build-to-Order-Option oder eine inkompatible Kombination ist.
Verwandeln Sie Konversation in Einschränkungen vor dem Abrufen
Ein LLM kann Sprache analysieren, aber der Abrufdienst sollte eine getippte Abfrage verwenden.
interface DiscoveryIntent {
category: string;
hard: Array<{
field: string;
op: 'eq' | 'in' | 'gte' | 'lte' | 'compatible';
value: string | number | boolean | string[];
}>;
preferences: Array<{
field: string;
direction: 'prefer' | 'avoid';
weight: number;
value: unknown;
}>;
market: { country: string; postalCode?: string; currency: Currency };
unresolved: string[];
}
Wenn ein Käufer einen 16-Zoll-Laptop mit einem Gewicht von weniger als einem Kilogramm möchte und der Katalog keinen enthält, geben Sie ein strukturiertes No-Match-Ergebnis zurück. Entspannen Sie nicht ruhig die Gewichtsgrenze. Wenn der Benutzer "leicht" sagt, behandeln Sie es als Präferenz, bis das Gespräch einen Schwellenwert festlegt.
Retrieval sollte vier Signale kombinieren:
- Strukturierte Filterung nach Kategorie, Abmessungen, Zertifizierung und Kompatibilität.
- Lexical Retrieval für genaue Modellnamen, technische Begriffe und SKUs.
- Semantische Abrufung für deskriptive Bedürfnisse und Synonyme.
- Geschäftsberechtigung für Markt-, Kanal- und Richtlinienbeschränkungen.
Bestimmen Sie Live-Angebote für einen begrenzten Kandidatenpool und entfernen Sie dann gescheiterte harte Einschränkungen. AI-Suche nach E-Commerce-Guide deckt diese Pipeline und ihre Bewertung eingehender ab.
Rückgabebeweise, die ein Agent verwenden kann
Ein Produktergebnis sollte kein Prosa-Absatz sein, der aus versteckten Feldern generiert wurde.
{
"variantId": "shoe-482-black-44",
"eligible": true,
"matchReasons": [
{ "constraint": "size = EU 44", "field": "size", "value": 44 },
{
"constraint": "color in [black, navy]",
"field": "color",
"value": "black"
}
],
"offer": {
"priceMinor": 12900,
"currency": "EUR",
"purchasable": true,
"expiresAt": "2026-08-11T14:05:00Z"
},
"provenance": {
"product": "pim://products/482/version/91",
"offer": "commerce-api://offers/shoe-482-black-44/request/8f31"
}
}
Diese Form ermöglicht es der Konversationsschicht, ein Ergebnis zu erklären, ohne die Autorität für seinen Preis oder seine Eignung zu werden.
Wenn man den Kandidaten klein genug hält, um darüber nachzudenken, normalerweise ein konfigurierbares Top-K anstelle des gesamten Katalogs.
Ausfallfälle und Wiederherstellungspfade
Stale Preis im Index. Der Kandidat sieht mit 89 US-Dollar berechtigt aus, aber der Angebotsservice gibt 109 US-Dollar zurück. Ersetzen Sie den indexierten Anzeigewert durch das Live-Angebot, notieren Sie die Diskrepanz und ordnen Sie einen neuen Rang ein, wenn der Preis gegen ein Budget verstößt.
Variant-Level-Bestand versteckt durch Produkt-Level-Bestand. Das Produkt ist "auf Lager", aber die gewünschte Größe ist nicht verfügbar. Die Live-Validierung muss die Variantenkennung verwenden.
Verträglichkeit aus der Beschreibung. Eine semantische Übereinstimmung legt nahe, dass ein Teil in eine Maschine passt, während die Kompatibilitätstabelle dies nicht sagt. Die deterministische Kompatibilitätsquelle gewinnt.
Service-Timeout anbieten. Konvertieren Sie niemals "unbekannt" in "verfügbar". Geben Sie Kandidaten als nicht verifiziert zurück, versuchen Sie es innerhalb eines begrenzten Budgets erneut oder degradieren Sie zu reinen Ergebnissen. Deaktivieren Sie Warenkorbaktionen, bis ein neues Angebot verfügbar ist.
Catalog Update Rennen mit Löschung. Ein Index enthält immer noch eine nicht mehr verfügbare Variante. not_found Die Antwort sollte den Kandidaten unterdrücken und eine Indexreparatur anstellen.
Lieferversprechen fehlt das Ziel. Geben Sie keine generische ETA als verbindliche Zusage an, fragen Sie nach der Postleitzahl oder kennzeichnen Sie die Schätzung mit ihren Annahmen.
Diese Wiederherstellungen funktionieren, weil unbekannt, falsch und abgestanden sind getrennte Zustände. available Feld ist nicht genug.
Eine reproduzierbare Entdeckungsbewertung
Bauen Sie eine Vorrichtung aus Katalog-Snapshots und maßgeblichen Angebotsantworten. Jeder Fall sollte die Absicht, das erwartete förderfähige Set, verbotene Varianten und die Uhr enthalten, die für Frischeprüfungen verwendet wird.
case: waterproof-hiking-shoe-eu44-under-150
clock: 2026-08-11T14:00:00Z
intent:
hard:
- [category, eq, hiking-shoe]
- [waterproof, eq, true]
- [size, eq, 44]
- [priceMinor, lte, 15000]
expected:
must_include: [shoe-482-black-44]
must_exclude: [shoe-117-black-43, shoe-901-blue-44]
max_offer_age_seconds: 300
Führen Sie nach jeder Schema-, Synonym-, Modell- oder Rangfolgeänderung die gleiche Vorrichtung aus.
| Maßnahme | Frage, die es beantwortet |
|---|---|
| Förderfähiger Rückruf bei k | Hat Retrieval jede bekannte förderfähige Variante beibehalten? |
| Begrenzungsgenauigkeit | Welcher Anteil der zurückgegebenen Varianten erfüllt alle harten Einschränkungen? |
| Gültigkeitsdauer lebender Staaten | Waren Preis und Aktie bei der Präsentation nicht abgelaufen? |
| Nicht unterstützter Forderungssatz | Hat die Antwort eine Produkttatsache behauptet, die von Beweisen abwesend ist? |
| Berichtigung der Wiedereinziehung | Haben Timeout-, Lösch- und Konfliktfälle den angegebenen sicheren Zustand erreicht? |
Mischen Sie "Ich bevorzuge diesen Stil" nicht mit harten Eignungsmetriken. OpenAI berichtet ebenfalls über die Produktgenauigkeit bei der Einkaufsbewertung, ob empfohlene Produkte die Benutzeranforderungen erfüllen, und warnt gleichzeitig davor, dass der aktuelle Preis und die Verfügbarkeit immer noch falsch sein können (siehe Artikel 4 Absatz 1 Buchstabe a).OpenAI Shopping Forschung).
Checkliste der Durchführung
- Etablieren Sie kanonische Produkt- und Varianten-IDs für PIM-, ERP- und Storefront-Systeme.
- Beschriften Sie jedes Feld als indexiert, live oder abgeleitet, mit einer Quelle und Frischeregel.
- Normalisieren Sie Einheiten und Taxonomien, ohne Originalwerte zu löschen.
- Trennen Sie harte Einschränkungen, Präferenzen und Unbekannte in separate Strukturen.
- Kombinieren Sie strukturiertes, lexikalisches und semantisches Abrufen vor der Live-Validierung.
- Anwendung von Kompatibilitäts- und Richtlinienregeln deterministisch.
- Geben Sie Beweise, Zeitstempel und fehlgeschlagene Einschränkungen mit jedem Kandidaten zurück.
- Revalidieren Sie das ausgewählte Angebot vor dem Warenkorb oder Checkout.
- Testen Sie veraltete, fehlende, widersprüchliche und zeitgesteuerte Datenpfade.
- Versionshalterungen, so dass Ranking-Änderungen mit dem gleichen Katalogzustand verglichen werden können.
- Senden Sie nicht unterstützte oder sicherheitsrelevante Kompatibilitätsansprüche an eine qualifizierte Überprüfung.
Wo Intelliger und OATI passen
Die Commerce-Architektur von Intelliger ist derzeit eine Blaupause, keine Behauptung, dass eine Produktion Commerce Graph, Merchant Agent Runtime oder Agent Search Console für Kunden bereitgestellt wird. Das Zieldesign platziert normalisierte Katalogfakten in einem Commerce-Graphen, löst volatilen Zustand durch Händlerkonnektoren auf und stellt Agenten beweiskräftige Fähigkeiten zur Verfügung.
OATI ist eine separate Open-Standard-Entwicklervorschau für die Autorisierung und Aufzeichnung von Folgeaktionen von Agenten. Seine Schemata, SDKs, CLI, Konformitätssuite, lokale Sandboxen und ein öffentlicher Trust / Lookup-Vertical-Slice sind heute verfügbar. Unabhängige Überprüfung, ein vollständiger Richtlinien-Compiler, Beweis- und Streit-Workflows, eine Kunden-Gateway-Flotte und zwei Unternehmen Produktionsakzeptanz bleiben unvollständig. OATI-Übersicht, Dokumentation und öffentliches Repository für die aktuelle Grenze.
Sicherheitsrelevante Eignungs-, Autorisierungs- und Zahlungsdesigns erfordern eine fachkundige Überprüfung vor der Verwendung in der Produktion.
Wenn Sie einen großen Katalog in einen Agenten-Discovery-Service verwandeln, Bringen Sie eine Kategorie und ihre Fehlerfälle in eine Intelliger-Architekturüberprüfung.