AI-Suche für E-Commerce: Retrieval, Live State und Evaluation

12 Minuten Lesezeit

KI-Suche für E-Commerce sollte weitgehend aus stabilen Katalog-Fakten abrufen, eng gegen den Live-Commerce-Status validieren und nur geeignete Varianten einstufen. Das Sprachmodell kann Absichten interpretieren und Kompromisse erklären. Es sollte keinen Preis erfinden, Inventar ableiten oder Kompatibilitätsregeln außer Kraft setzen. Bewerten Sie die endgültige Antwort und ihre Beweise, nicht nur Vektor-Rückruf.

Dieser Leitfaden richtet sich an relevante Ingenieure und Commerce-Architekten, die nach Shopping-Agenten oder Konversations-Storefronts suchen. Er bietet Ihnen eine getippte Pipeline, ein Fehlermodell und eine Testvorrichtung, die nach einem Index-, Prompt-, Einbettungs- oder Reranker-Wechsel reproduziert werden kann.

Es befindet sich im breiteren Intelliger Agentic Commerce Architektur Guide, wo Retrieval eine Phase in einer geregelten Handelsreise ist.

Definieren Sie zuerst den Suchvertrag

"KI-Suche" nennt oft mehrere nicht verwandte Merkmale. Hier ist ein System gemeint, das natürlichsprachliche Einkaufsabsichten in überprüfbare Produktkandidaten umwandelt.

• Vorsätzliche Extraktion erzeugt typisierte Einschränkungen, Präferenzen und ungelöste Fragen.
• Abruf findet einen Pool mit hohem Rückruf unter Verwendung strukturierter, lexikalischer und semantischer Signale.
• Live-State Resolution erhält aktuelle Angebot Fakten von maßgeblichen Dienstleistungen.
• Ranking und Präsentation bestellt berechtigte Artikel und legt Nachweise vor.

Der indexierte Korpus sollte stabile beschreibende Fakten enthalten: Produktidentität, Variantenattribute, Spezifikationen, Kompatibilitätsbeziehungen, Kategorie und Herkunft des Inhalts. Preis, Inventar, Förderfähigkeit, Lieferschätzung und Transaktionszustand sind volatil. Holen Sie sie zur Laufzeit mit expliziten Zeitstempeln und Ablauf ab.

Diese Trennung entspricht der Richtung der aktuellen Commerce-Protokolle. Googles Universal Commerce Protocol modelliert die Produkterkennung als Fähigkeit und unterstützt API-, A2A- und MCP-Bindungen, anstatt die Erkennung auf verschrottete Seiten zu reduzieren.Google UCP Engineering ÜbersichtOpenAI beschreibt Feeds als Katalogdarstellung und warnt davor, dass Einkaufsrecherche immer noch Fehler bezüglich des aktuellen Preises und der Verfügbarkeit machen kann.OpenAI Shopping Forschung).

Verwenden Sie ein typisiertes Zustandsmodell

Behandeln Sie eine Suchanfrage als Zustandsmaschine, nicht als einen Modellaufruf:

received -> clarified -> retrieved -> state_checked -> eligible -> ranked -> presented

Jede Phase kann mit einem benannten Ergebnis enden: needs_clarification, no_match, state_unavailable, policy_denied oder partial_resultsEin benannter Zustand ist leichter zu erholen als fließend, aber nicht unterstützte Prosa.

type HardConstraint = {
  field: string;
  op: 'eq' | 'in' | 'gte' | 'lte' | 'compatible';
  value: string | number | boolean | string[];
};

interface SearchRequest {
  requestId: string;
  query: string;
  category?: string;
  hard: HardConstraint[];
  preferences: Array<{ field: string; value: unknown; weight: number }>;
  context: { country: string; postalCode?: string; currency: string };
  requestedAt: string;
}

interface RetrievedVariant {
  variantId: string;
  lexicalScore: number;
  semanticScore: number;
  structuredMatch: boolean;
  stableFacts: Record<string, unknown>;
  sourceVersion: string;
}

interface CheckedVariant extends RetrievedVariant {
  live: {
    priceMinor: number;
    currency: string;
    purchasable: boolean;
    inventoryState: 'available' | 'unavailable' | 'unknown';
    observedAt: string;
    expiresAt: string;
  };
  failedConstraints: string[];
}

Die unknown Timeouts, Ausfälle von Berechtigungen und unvollständige regionale Daten sind kein Beweis für die Nichtverfügbarkeit, aber sie sind auch keine Erlaubnis, Bestände zu versprechen.

Abrufen mit komplementären Signalen

Lexical Retrieval bleibt wertvoll. Es verarbeitet Modellnummern, Materialien, Standards und exakte Phrasen, die durch Einbettungen verwischt werden können. Semantisches Retrieval hilft bei Anforderungen wie "ruhig genug für Anrufe" oder "einfach in einem Zug zu packen". Strukturierte Filter setzen Kategorie, Größe, Spannung, Zertifizierung und andere typisierte Anforderungen durch.

Eine praktische Pipeline ist:

async function search(request: SearchRequest): Promise<CheckedVariant[]> {
  validateIntent(request);

  const [lexical, semantic] = await Promise.all([
    lexicalIndex.search(request.query, request.category, 120),
    vectorIndex.search(request.query, request.category, 120),
  ]);

  const fused = reciprocalRankFuse(lexical, semantic);
  const structurallyValid = fused
    .map(loadStableFacts)
    .filter((v) => satisfiesIndexedConstraints(v, request.hard))
    .slice(0, 40);

  const offers = await offerService.batchGet({
    variantIds: structurallyValid.map((v) => v.variantId),
    market: request.context,
  });

  return structurallyValid
    .map((v) => attachAndValidateOffer(v, offers, request))
    .filter((v) => v.failedConstraints.length === 0)
    .sort((a, b) => finalScore(b, request) - finalScore(a, request));
}

Die Zahlen sind Ausgangspunkte, keine universellen Einstellungen. Stimmen Sie die Kandidatentiefe mit Ihrem Bewertungssatz und Latenzbudget ab. Notieren Sie die Kandidaten-IDs in jeder Phase. Ohne Spuren auf Stufe könnte ein fehlendes Ergebnis ein Intent-Parser-Fehler, ein Abruffehler, eine Live-State-Ablehnung oder ein Reranker-Defekt sein.

Ein Modell kann eine explizite Alternative vorschlagen, aber die Antwort muss nennen, was sich geändert hat. Zum Beispiel: "Keine wasserdichte Variante EU 44 ist derzeit unter 150 € erhältlich. Diese beiden übersteigen das Budget um 12 € und 19 €."

Live-Zustand nach dem Abruf auflösen

Der Aufruf von Preis- und Inventardiensten für jeden indexierten Artikel ist teuer und langsam. Der Aufruf für keinen ist unsicher. Lösen Sie den Live-Status für den begrenzten Pool, der stabile Einschränkungen übersteht.

Verwenden Sie einen Angebotsvertrag, der Folgendes beinhaltet:

• exakte Variante und Marktidentität
• Preis in kleineren Einheiten und Währung
• Semantik der Steuereinbeziehung
• Verfügbarkeits- oder Kaufbarkeitszustand
• Absatzförderungsbedingungen, nicht nur ein Werbelabel
• Annahmen für den Bestimmungsort der Lieferung
• Beobachtungs- und Ablaufzeitstempel
• Source Request oder Trace Identifier

Die Verfügbarkeitsspezifikation von Google Merchant Center erfordert unterstützte Werte und Konsistenz zwischen eingereichten Produktdaten, Zielseiten und Checkout.Verfügbarkeit von Google MerchantEin agentenorientierter Dienst sollte ebenfalls Divergenzen erkennen, anstatt sie zu rationalisieren.

Cache-Live-Status nur innerhalb eines deklarierten Frische-Budgets. Das Budget kann je nach Feld und Betrieb variieren. Ein 5-Minuten-Browse-Cache kann für eine Warnmeldung mit geringem Bestand akzeptabel sein, während die Erstellung eines Warenkorbs eine sofortige Verlängerung erfordern kann. Speichern Sie die Beobachtungszeit, nicht nur eine TTL in der Cache-Infrastruktur, damit nachgelagerte Systeme das Alter bestimmen können.

Revalidieren Sie vor dem Warenkorb oder der Kasse die gewählte Variante.

Rank förderfähige Ergebnisse, nicht plausible Prosa

Eine nützliche Endpunktzahl kann Retrieval-Relevanz, Präferenzanpassung, Evidenzvollständigkeit und geschäftsneutrale Qualitätssignale kombinieren.

function finalScore(v: CheckedVariant, r: SearchRequest): number {
  if (v.failedConstraints.length > 0 || !v.live.purchasable) return -Infinity;
  return (
    0.3 * normalize(v.lexicalScore) +
    0.3 * normalize(v.semanticScore) +
    0.25 * preferenceFit(v, r.preferences) +
    0.15 * evidenceCompleteness(v)
  );
}

Diese Gewichtungen sind illustrativ. Lernen oder stimmen Sie sie auf beurteilte Daten ab, dann testen Sie sie nach Segmenten. Ein globaler Durchschnitt kann Fehler für Long-Tail-Kategorien, nicht-englische Abfragen oder kompatibilitätsschwere Produkte verbergen.

Geben Sie einen kurzen Kandidaten mit matchReasons, tradeoffs, failedAlternatives Die Konversationsschicht kann diese Daten in eine Antwort umwandeln, aber ein Prüfer sollte Behauptungen ablehnen, die im Ergebnisvertrag fehlen.

Für Katalogmodellierungsdetails verwenden Sie den Begleiter E-Commerce Produkt Discovery GuideFür die Großkatalogmechanik siehe Produktsuche im KatalogmaßstabFür die Verlagsseite der Agent-Sichtbarkeit siehe KI-Suchoptimierung für Agentic Commerce.

Ausfall- und Wiederherstellungsfälle

Intent Parser ändert "etwa $ 200" in eine harte Kappe. Behandle die ungefähre Sprache als Präferenz, es sei denn, der Benutzer bestätigt eine Grenze, füge Kontrastfälle zum Parser-Testsatz hinzu.

Die semantische Suche lässt eine exakte SKU fallen. Führen Sie lexikalisches und semantisches Abrufen in parallelen und Sicherungsreihen aus.

Reranker fördert einen nicht verfügbaren Artikel. Machen Sie die Berechtigung zu einem Filter oder einer unendlichen Strafe außerhalb des gelernten Modells.

Inventardienstzeiten für die Hälfte des Pools. Verifizierte Ergebnisse zurückgeben, wenn noch genügend übrig sind, und die Antwort partiell kennzeichnen; wenn keine verifiziert sind, eingeben state_unavailable; Ersetzen Sie keine zwischengespeicherten "verfügbaren" Werte nach ihrem Ablauf.

Promotion ist kundenspezifisch. Geben Sie den entsprechenden authentifizierten Kontext erst nach Zustimmung und Autorisierung weiter Wenn kein Kontext existiert, geben Sie den normalen Preis zurück und beschreiben Sie die Aktion als bedingt.

Index- und Angebotsservice widersprechen sich bei der Variantenidentität. Unterdrücken Sie die Aufzeichnung, senden Sie einen Abgleich und bewahren Sie beide Quellversionen auf.

Die Antwort zitiert den falschen Kandidaten. Geben Sie jeder Tatsache eine Varianten-ID und validieren Sie generierte Ansprüche gegen die Beweise dieses Kandidaten.

Lieferdatum ändert sich vor dem Checkout. Revalidieren Sie mit dem genauen Ziel und der ausgewählten Erfüllungsmethode. Geben Sie das neue Datum zur Bestätigung an, wenn es die Auswahl wesentlich ändert.

Bewerten Sie den gesamten Pfad reproduzierbar

Ein Einbettungs-Benchmark ist keine E-Commerce-Suchauswertung. Einfrieren eines Index-Snapshots, Abspielen autoritativer Live-Antworten und Einstellen der Uhr. Jeder Testfall sollte erwartete förderfähige Varianten, verbotene Varianten und akzeptable Klarstellungen angeben.

{
  "id": "adapter-240v-germany",
  "clock": "2026-08-11T10:00:00Z",
  "query": "travel adapter for a 240V laptop, delivery to Berlin by Friday",
  "context": { "country": "DE", "postalCode": "10115", "currency": "EUR" },
  "mustInclude": ["adapter-77-eu"],
  "mustExclude": ["adapter-12-us-only"],
  "requiredEvidence": ["voltage", "plugCompatibility", "delivery.earliestDate"],
  "maximumOfferAgeSeconds": 120
}

Verwenden Sie die folgende Scorecard:

Slice-Ergebnisse nach Kategorie, Gebietsschema, Abfragelänge, Kopf-gegen-Schwanz-Inventar und Einschränkungszahl. Fügen Sie jeden Produktionsvorfall als minimierte Regressionsvorrichtung hinzu. Führen Sie bei jeder Änderung deterministische Schichten aus und reservieren Sie langsamere menschliche Urteile für Präferenzqualität und Erklärungsnützlichkeit.

Checkliste der Durchführung

• Deklarieren Sie, welche Felder indiziert, live und abgeleitet werden.
• Version Product Identity Mappings und Source Records.
• Stellen Sie harte Einschränkungen, Präferenzen und Unbekannte separat dar.
• Sicherung des lexikalischen, semantischen und strukturierten Abrufs.
• Verfolgen Sie Kandidaten-IDs und Ablehnungsgründe in jeder Phase.
• Batch-Fetch Live-Zustand für einen begrenzten Kandidatenpool.
• Konserve unknown und Ablauf statt Boolesche Verfügbarkeit zu erzwingen.
• Durchsetzung der Förderfähigkeit außerhalb des generativen Modells.
• Revalidieren Sie vor dem Warenkorb, der Kasse oder einer anderen Folgemaßnahme.
• Überprüfen Sie generierte Ansprüche gegen kandidatenspezifische Beweise.
• Freeze-Katalog, Live-Antworten und Zeit in Release-Fixes.
• Überprüfen Sie Sicherheits-, Datenschutz- und Zahlungsintegrationen mit qualifizierten Experten.

Die Intelliger Grenze

Intelliger's Commerce Graph, Merchant Agent Runtime, Connector Network und Agent Search Console sind Zielarchitektur, keine ausgelieferte Kundeninfrastruktur. Die Blaupause wendet die hier beschriebene Aufteilung an: stabiles Katalogwissen in einem Graphen, flüchtiger Zustand aus autoritativen Händlersystemen und Ergebnisdateneingabeauswertung.

OATI ist eine Open-Standard-Entwicklervorschau für Folgeaktionen von Agenten. Implementierte Assets umfassen Schemata, TypeScript SDK, tragbare Python- und Go-Kerne, CLI, Konformitätstests, lokale Commerce- und RWA-Sandboxen, eine Envoy-Referenz und einen vertikalen Public Trust/Lookup-Slice. Ein vollständiger Richtlinien-Compiler, unabhängige Überprüfung, Evidenz- und Streit-Workflows, eine Kunden-Gateway-Flotte und Produktionsakzeptanz über zwei Unternehmen hinweg sind unvollständig. Aktuelle Details sind in der OATI-Übersicht, Entwicklerdokumente und GitHub Repository.

Wenn Ihr Team einen echten Abfragesatz und Katalog-Snapshot hat, Fordern Sie eine Intelliger Search Architecture Review an und bringen Sie die Fehlerfälle, kein Demo-Skript.