Commerce AI Trainingsdaten: Ergebnisse Beat Chats

13 Minuten Lesezeit

Die einfachsten KI-Trainingsdaten für einen Commerce-Agenten sind oft am wenigsten nützlich. Agententeams sammeln Gespräche, weil Gespräche leicht zu sehen sind. Ein Benutzer fragt nach einem Produkt, der Agent durchsucht Optionen, ruft Werkzeuge an und gibt eine Antwort. Das Transkript sieht aus wie die natürliche Trainingsaufzeichnung.

Für den Handel ist es nur die vordere Hälfte der Geschichte.

Die nützliche Frage ist nicht nur, was der Agent gesagt hat. Es ist, welchen Zustand der Agent beobachtet hat, welche Aktion er ausgewählt hat, welches Ergebnis er vorhergesagt hat, was die Handelssysteme ausgeführt haben und was später passiert ist. Hat der Artikel pünktlich geliefert? Hat der Käufer ihn behalten? Wurde die Zahlung rückgängig gemacht? Hat der Händler das Angebot eingehalten? Hat ein angeblich kompatibler Teil eine Rückkehr verursacht?

Ein Gespräch kann Sprache und Präferenzausdruck lehren. Eine verifizierte Flugbahn kann Konsequenzen lehren.

Das macht das langfristige Commerce Learning Objekt:

state + action + predicted outcome + verified actual outcome

Es zu bauen ist schwieriger als Chat-Logs zu speichern. Es ist auch viel vertretbarer als Infrastruktur.

Warum Chat-Transkripte schwache KI-Trainingsdaten sind

Angenommen, ein Käufer sagt einem Agenten:

Find a quiet dishwasher under EUR 650 that fits a 45 cm cabinet.
I need delivery and installation in Berlin this week.

Das Transkript kann zeigen, dass der Agent drei Optionen vergleicht und Produkt B empfiehlt.

• welche Katalogversion der Agent abgefragt hat;
• welche Varianten die 45 cm-Einschränkung überschritten haben;
• ob Inventar und Installation live kontrolliert wurden;
• welcher Preis und welche Lieferschätzung angegeben wurden;
• ob ein Mandat Checkout autorisiert;
• was der Kaufmann angenommen hat;
• ob die Erfüllung das versprochene Datum erfüllt hat;
• ob der Käufer das Produkt zurückgegeben hat;
• warum der Käufer die Produkte A und C abgelehnt hat.

Das Transkript kann sogar eine selbstbewusste Prosa enthalten, die mit dem Ergebnis des Werkzeugs kollidiert.

OpenTelemetry definiert Traces als Pfad einer Anfrage durch eine Anwendung und Protokolle als Aufzeichnungen von Ereignissen. Signaldokumentation Eine Commerce-Trajektorie kann diesen Trace-Kontext verwenden, benötigt aber auch Geschäftsidentitäten und Ergebniszustände, die Tage oder Monate später eintreffen können.

Modell einer Trajektorie als verknüpfte Datensätze

Eine nützliche Commerce-Trajektorie verbindet mehrere getippte Datensätze, ohne sie zu einem riesigen JSON-Dokument zu zwingen.

Intent
  -> observed state
  -> candidates
  -> plan and prediction
  -> authority and policy decision
  -> tool calls and results
  -> offer and transaction
  -> payment and fulfillment events
  -> return, dispute or retention outcome

Verwenden Sie stabile Identifikatoren und unveränderliche Ereignisreferenzen:

type CommerceTrajectory = {
  trajectoryId: string
  traceId: string
  buyerContextRef: string
  intentRef: string
  stateSnapshotRef: string
  candidateSetRef: string
  selectedActionRef: string
  predictionRef?: string
  mandateRef?: string
  decisionRef?: string
  transactionRef?: string
  receiptRefs: string[]
  outcomeRefs: string[]
  schemaVersion: string
  createdAt: string
}

Die Referenzen können auf Datensätze verweisen, die unter verschiedenen Zugriffskontrollen geführt werden. Ein Händler kann Bestelldetails behalten, ein Zahlungsanbieter kann einen eigenen Abwicklungszustand besitzen und die Agentenplattform kann nur Digests oder zweckbeschränkte Funktionen behalten.

Das W3C Empfehlung PROV-O Commerce-Systeme werden domänenspezifische Objekte benötigen, aber das Provenienzvokabular hilft zu bewahren, wer einen Anspruch produziert hat, welche Aktivität ihn verwendet hat und welche Datensätze daraus resultieren.

Erfassungszustand zum Entscheidungszeitpunkt

Ein Ergebnis kann nicht interpretiert werden, ohne dass der Staat die Entscheidung verwendet.

Für Produktauswahl, Aufzeichnung oder Referenz:

• normalisierte harte Einschränkungen und weiche Präferenzen;
• Kandidatenkennungen und Katalogversionen;
• Preis-, Inventar- und Lieferbemerkungen mit Zeitstempeln;
• Kompatibilitätsnachweise;
• Status der Händlerfähigkeit;
• Vertrauens- und Autoritätsstaat;
• Richtlinienversion;
• Markt und Währung;
• für den Vorschlag verwendete Modell- und Werkzeugversionen.

Kopieren Sie keine veränderliche Produktzeile und nennen Sie sie historischen Zustand. Speichern Sie eine unveränderliche Momentaufnahme, eine versionierte Referenz oder einen Digest plus wiederherstellbare Quellennachweise.

{
  "snapshotId": "state:01K2C91",
  "observedAt": "2026-08-11T10:14:22Z",
  "market": "DE",
  "catalogVersion": "catalog:2026-08-11T10:00Z",
  "candidates": [
    {
      "variantId": "variant:dw-451-silver",
      "priceMinor": 62900,
      "currency": "EUR",
      "inventory": 3,
      "deliveryDate": "2026-08-14",
      "installationAvailable": false,
      "sourceDigests": ["sha256:aa81...", "sha256:07fc..."]
    }
  ]
}

Das Beispiel ist absichtlich explizit über installationAvailable: falseWenn der Agent das Produkt weiterhin empfiehlt, können die Gutachter feststellen, ob Absichts-Parsing, Ranking oder Erklärung fehlgeschlagen sind.

Speichern Sie die Vorhersage, bevor Sie das Ergebnis sehen

Outcome Learning wird viel weniger nützlich, wenn die Vorhersage nach dem Eintreffen des Ergebnisses rekonstruiert wird.

type OutcomePrediction = {
  predictionId: string
  actionId: string
  modelVersion: string
  predictedAt: string
  estimates: {
    transactionSuccess: number
    onTimeFulfillment: number
    returnWithin30Days: number
    expectedBuyerUtility: number
  }
  featureSnapshotDigest: string
  uncertainty?: Record<string, number>
}

Diese Werte sind illustrativ. Produktionsteams benötigen kalibrierte Definitionen, Zeithorizonte und Grundwahrheitsregeln. "Transaktionserfolg" könnte bedeuten, dass der Checkout akzeptiert, die Zahlung abgewickelt oder die Bestellung erfüllt wird. Wählen Sie eine und kodieren Sie sie im Schema.

Versionieren Sie das Modell, die Merkmale und die Kalibriermethode. Ansonsten kombiniert ein Genauigkeitsdiagramm Vorhersagen, die verschiedene Dinge bedeuten.

Ein Modell kann eine hohe Wahrscheinlichkeit einer erfolgreichen Zahlung vorhersagen, während ein deterministisches Mandat den Betrag ablehnt.

Ergebnisse mit autoritativen Systemen überprüfen

Ein Agent, der sagt "der Auftrag ist angekommen" ist kein verifiziertes Erfüllungsereignis.

type VerifiedOutcome = {
  outcomeId: string
  transactionId: string
  outcomeType:
    | 'payment-settled'
    | 'payment-reversed'
    | 'order-fulfilled'
    | 'delivery-late'
    | 'item-returned'
    | 'dispute-opened'
  status: 'observed' | 'corroborated' | 'contested'
  source: {
    system: string
    recordId: string
    assurance: 'merchant-record' | 'provider-record' | 'bilateral'
  }
  observedAt: string
  effectiveAt: string
  evidenceDigest: string
}

Eine Überprüfung macht nicht jede externe Aussage wahr. Ein signiertes Händlerereignis beweist, was der Händler unterschrieben hat. Ein Anbieter-Abrechnungsprotokoll enthält stärkere Beweise für den Zahlungsstatus als ein Modell-Transkript, aber es kann immer noch korrigiert oder rückgängig gemacht werden. Ein Lieferscan beweist nicht, dass der Käufer den richtigen Artikel erhalten hat.

Verwende explizite Zusicherungs- und Streitzustände. Verknüpfungskorrekturen statt Überschreiben der früheren Beobachtung. Hier helfen Handlungsquittungen: Sie binden Identität, Autorität, Transaktion, Entscheidung und Ausführung von Beweisen. Sie beweisen nicht allein das spätere Ergebnis der realen Welt.

AP2 folgt der gleichen allgemeinen Trennung. Seine Spezifikation verbindet Checkout- und Zahlungsmandate mit entsprechenden Quittungen, so dass die Parteien rekonstruieren können, was während eines Streitfalls autorisiert und beobachtet wurde. AP2-StreitbeilegungsabschnittEine Commerce-Ergebnisschicht muss diesen Transaktionsnachweis noch mit Erfüllungs-, Rückgabe- und Streitfällen verbinden.

Behalten Sie Aktionseingänge und Ergebnisse getrennt

Das Zusammenfügen einer Quittung und eines Ergebnisses in einen Datensatz schafft zwei Probleme.

Zuerst kommen die Ergebnisse später. Eine Zahlung kann akzeptiert werden, dann fehlschlagen oder rückgängig gemacht werden. Eine Bestellung kann erfüllt und dann zurückgegeben werden. Das Umschreiben der Quittung zerstört die Geschichte dessen, was das System zum Zeitpunkt der Ausführung wusste.

Zweitens sind Autorität und Erfolg unterschiedliche Dimensionen. Eine unautorisierte Aktion kann ein kommerziell erfolgreiches Ergebnis hervorbringen. Eine autorisierte Aktion kann operativ fehlschlagen. Der Datensatz sollte beide bewahren.

Action Receipt
  transaction: txn-418
  authority: allowed
  execution: submitted
  observed_at: T0

Outcome Event
  transaction: txn-418
  payment: settled
  effective_at: T1

Outcome Event
  transaction: txn-418
  order: returned
  effective_at: T2

Diese Append-only-Form unterstützt die Auswertung, ohne vorzugeben, dass der endgültige Status von Anfang an bekannt war.

Lernen Sie von Trajektorien, ohne die Kausalität zu erfinden

Eine Flugbahn zeichnet auf, was nach einer Aktion passiert ist. Sie beweist nicht, dass die Aktion das Ergebnis verursacht hat.

Produkt B kann eine niedrigere Rücklaufquote haben, weil es verschiedenen Kunden angeboten wurde. Ein Händler kann bessere Erfüllungsergebnisse haben, weil es einfachere Regionen bedient. Eine Agentenversion scheint die Konversion während einer saisonalen Aktion zu verbessern.

Verwenden Sie Ergebnisdaten für mehrere Analyseebenen:

1. Deskriptiv: Welche Ergebnisse folgten welchen Entscheidungen?
2. Predictive: Können Zustand und Aktion ein Ergebnis auf ausgehaltenen Daten vorhersagen?
3. Kontrafaktisch: Was hätte bei einer anderen Aktion passieren können?
4. Kausal: Verändert eine Intervention das Ergebnis?

Die letzten beiden erfordern stärkere Annahmen oder Experimente.

Auswahlwahrscheinlichkeiten oder Ranglisten sollten gegebenenfalls beibehalten werden. Randomisierte Explorationen können, wenn sie ethisch und wirtschaftlich akzeptabel sind, bei der Einschätzung von Alternativen helfen. Harte Sicherheits-, Autoritäts- und rechtliche Zwänge bleiben außerhalb der Exploration. Kein Experiment sollte testen, ob die Überschreitung eines Zahlungsmandats die Umrechnung verbessert.

Erstellen Sie Etiketten, die die Geschäftsrealität überleben

Naive Labels produzieren naive Agenten.

purchase_completed = true kann einen Agenten für eine Bestellung belohnen, die zehn Minuten später storniert wurde. refund = true kann eine Goodwill-Rückerstattung, Betrugsumkehrung und zurückgegebenes defektes Produkt als dasselbe Ergebnis behandeln. no_return_after_30_days kann zensiert werden, weil das Rückkehrfenster länger ist.

Etikettenverträge definieren:

label: retained_purchase_45d
entity: order_line
positive_when:
  - fulfillment_status == delivered
  - no_return_record_by == delivery_time + 45d
exclusions:
  - merchant_return_window_days > 45
  - outcome_evidence_status == contested
version: 1

Verzögerte Etiketten, Korrekturen und Abdeckung verfolgen: Ein Modell, das nur auf Transaktionen mit vollständigen Ergebnissen trainiert wurde, kann systematische Verzerrungen erben, wenn schwierige Händler oder Regionen eine schlechtere Instrumentierung haben.

Negative Ergebnisse erfordern Details. Rücksendungen, die durch Größe, Kompatibilität, Schaden, Lieferverzögerung oder Käuferpräferenz verursacht werden, lehren unterschiedliche Lektionen. Zwingen Sie das Modell nicht, den Grund aus der Kundendienstprosa zu schließen, wenn ein strukturierter Rückgabecode existiert.

Datenschutz und Datenrechte sind Teil des Schemas

Die reichste Flugbahn ist nicht automatisch die rechtmäßige oder angemessene.

Ein nützlicher Datenvertrag sollte beigefügt werden:

• Datenverantwortlicher und beitragende Partei;
• Zweck der Sammlung;
• zulässige Verwendungen, einschließlich der Frage, ob eine Musterschulung zulässig ist;
• Aufbewahrungs- und Löschungspolitik;
• Mieter- und Händlergrenzen;
• Kategorien personenbezogener Daten;
• Aggregations- oder De-Identifizierungsanforderungen;
• geografische Beschränkungen;
• Verweise auf Beweise und Zustimmung.

Die Händler-Feed-Bedingungen von OpenAI definieren beispielsweise, wie eingereichte Händlerinhalte innerhalb von OpenAI-Diensten verwendet werden können, und fügen Anforderungen hinzu, wenn Feedinhalte personenbezogene Daten enthalten. OpenAI Merchant Feed Bedingungen.

Eine Plattform darf Preise, Kundenverhalten oder operative Schwächen eines Händlers nicht an einen anderen weitergeben. Verwenden Sie explizite Zustimmung, Isolation, Aggregation, Mindestkohortengrößen und zweckgebundene Feature-Generierung. Einige Daten sollten niemals die Händlergrenze verlassen.

Vermeiden Sie standardmäßig die Speicherung vollständiger Eingabeaufforderungen, extrahieren Sie die für den genehmigten Zweck erforderlichen strukturierten Mindestfunktionen, bewahren Sie erforderlichenfalls Beweisreferenzen auf und wenden Sie separate Zugriffskontrollen auf rohe Gespräche an.

Instrument der Trajektorie über Dienste hinweg

Verwenden Sie eine Trace- oder Transaktionskennung für Agent Runtime, Resolver, Policy, Gateway, Merchant Connector, Payment und Outcome Services. Semantische Konventionen Handelsspezifische Konventionen sollten stabile Geschäftskennungen hinzufügen, ohne sensible Werte in Metriken mit hoher Kardinalität aufzunehmen.

trace_id: technical request path
trajectory_id: learning episode
transaction_id: governed commercial action
order_id: merchant execution object
receipt_id: signed action evidence
outcome_id: later verified observation

Diese Identifikatoren können Eins-zu-viele-Beziehungen haben. Eine Trajektorie kann mehrere Tool-Aufrufe und Transaktionen enthalten. Ein Auftrag kann mehrere Outcome-Ereignisse erzeugen. Gehen Sie nicht davon aus, dass eine einzelne verteilte Trace offen bleibt, bis eine Rückkehr Wochen später eintrifft. Verknüpfen Sie spätere Traces durch dauerhafte Geschäftskennungen.

Fehlerfälle, die es wert sind, jetzt entworfen zu werden

Backfill- und Korrekturtests sind ebenso wichtig wie die Aufnahme von Lebendtieren.

Checkliste der Durchführung

• Behandeln Sie Gespräche als einen Input-Stream, nicht den Transaktionsrekord.
• Definieren Sie stabile Absichten, Kandidaten, Aktionen, Transaktionen und Ergebnisidentitäten.
• Erfassen Sie unveränderliche Zustandsreferenzen zum Entscheidungszeitpunkt.
• Notieren Sie Vorhersagen vor den Ergebnissen mit Modell- und Feature-Versionen.
• Separate Autoritätsentscheidungen, Handlungseingänge und spätere Ergebnisse.
• Überprüfen Sie die Ergebnisse mit benannten autoritativen Quellen.
• Repräsentieren Sie ausdrücklich Zusicherungen, Korrekturen und umstrittene Staaten.
• Verwenden Sie nur Append-Ereignisse anstelle von veränderlichen Endstatusfeldern.
• Definieren Sie Etikettenverträge, Horizonte, Ausschlüsse und Abdeckung.
• Vermeiden Sie kausale Behauptungen aus Beobachtungsbahnen allein.
• Verfolgen Sie den Kontext und verknüpfen Sie langlebige Ereignisse über Business IDs.
• Bewahren Sie rohe Eingabeaufforderungen unter strengerem Zugriff und Aufbewahrung auf als strukturierte Funktionen.
• Anbringen von Zweck, Einwilligung, Aufbewahrung und Schulungsrechten an Datenprodukte.
• Isolieren Sie Händlerdaten und regeln Sie jede händlerübergreifende Aggregation.

Das Intelliger-Ziel und das aktuelle Produkt

Intelligers Agentic-Commerce-Blueprint schlägt ein Outcome Ledger, Commerce World Model, Decision Engine und Privacy-governed Commerce Data Network vor. Das Ziel-Lernobjekt ist der in diesem Artikel beschriebene verknüpfte Zustand, die Aktion, das vorhergesagte Ergebnis und das verifizierte tatsächliche Ergebnis. Diese Fähigkeiten würden Simulation, Routing, Betrugserkennung, Händlerempfehlungen und Modellverhalten verbessern.

Sie sind Roadmap-Architektur, keine bereitgestellten Produktansprüche. Die aktuelle Entwicklervorschau von OATI kann signierte Transaktionsobjekte erstellen, deterministische Commerce-Einschränkungen auswerten, Quittungen generieren und Referenz-Commerce-Flows ausführen. Der dauerhafte Evidenzarbeiter, Produktionsabgleich, Ergebnis-Ledger, Weltmodell und händlerübergreifendes Lernnetzwerk sind unvollständige oder Zielzustandskomponenten. Unabhängige kryptographische und Protokollüberprüfung bleibt offen.

Diese Grenze erklärt auch die Produktthese. Ein promptes Archiv wird mit der Nutzung größer, aber vieles davon ist repetitiv, sensibel und losgelöst von der Geschäftsrealität. Eine gesteuerte Flugbahn verbindet die Entscheidung mit Beweisen darüber, was folgte. Wenn Intelliger das Recht erhält, diesen Datensatz durch echte Händlerintegrationen, explizite Berechtigungen und verifizierte Ergebnisse zu erstellen, kann es etwas lernen, was ein Gespräch allein nie offenbart: ob die Wahl des Agenten funktioniert hat.

Diese Trajektorien werden nur dann vertrauenswürdig, wenn signierte Aktionsquittungen erstellen den Transaktionsaufzeichnungsvorgang. Die Agentic Commerce Plattform Thesis erklärt, wie verifizierte Ergebnisse Routing- und Entscheidungssysteme unterstützen können, ohne Chat-Logs durch Annahme in einen Datengraben zu verwandeln.