RAG für die Preisgestaltung: Erweiterung von E-Commerce-KI-Modellen mit Echtzeit-Datenfeeds

Entdecken Sie, wie Retrieval-Augmented Generation (RAG) in Kombination mit Echtzeit-Preisdaten KI-Halluzinationen verhindern und dynamische Preisintelligenz für den E-Commerce bieten kann.

Was ist RAG für die Preisgestaltung?

RAG (Retrieval-Augmented Generation) für die Preisgestaltung ist ein Architekturmuster, das einem Sprachmodell zum Abfragezeitpunkt aktuelle Marktdaten liefert, statt sich auf im Training Gelerntes zu verlassen. Das Modell ruft aktuelle Preise, Lagerbestände und Aktionen aus einem Suchindex ab und leitet seine Antwort ausschließlich aus diesen Dokumenten ab.

Der Unterschied ist kommerziell entscheidend. Ein Modell, das aus Trainingsdaten antwortet, nennt Ihnen den Preis von vor Monaten. Ein Modell mit Retrieval-Schicht nennt Ihnen den aktuellen Preis, den Marktplatz und ob der Händler lieferfähig ist.

Das Problem statischer KI bei dynamischer Preisgestaltung

Große Sprachmodelle werden mit historischen Daten trainiert. Fragen Sie eine KI "Was kostet ein iPhone 15 Pro im Durchschnitt?", erhalten Sie eine veraltete Antwort. In einem E-Commerce-Umfeld, in dem große Marktplätze laufend neu bepreisen, führen veraltete Daten in Ihren Pricing-Systemen zu Margenverlusten, die sich still über den gesamten Katalog summieren.

Schlimmer noch: Der Fehler bleibt unbemerkt. Das Modell sagt nicht "Ich weiß es nicht", sondern liefert eine selbstbewusste, sauber formatierte und schlicht falsche Zahl — das Verhalten, das üblicherweise als Halluzination bezeichnet wird. Für ein Pricing-Team ist eine selbstbewusst falsche Zahl teurer als gar keine, denn danach wird gehandelt.

Wie funktioniert eine Pricing-RAG-Pipeline?

Eine produktive Pricing-RAG-Pipeline hat vier Stufen:

• Erfassung. Crawler ziehen Produktseiten, Marktplatzangebote und Aktionsdaten in einem Takt, der zur Änderungsgeschwindigkeit der jeweiligen Quelle passt. Schnelldrehende Elektronikkategorien brauchen deutlich engere Intervalle als Möbel.
• Normalisierung und Zuordnung. Rohangebote werden bereinigt, Währungen und Einheiten vereinheitlicht und Angebote einem kanonischen Produkt zugeordnet. Die Hauptarbeit leistet hier der Produktabgleich: ohne ihn erscheint dieselbe SKU als ein Dutzend unzusammenhängender Dokumente.
• Indizierung. Normalisierte Datensätze werden eingebettet und zusammen mit strukturierten Filtern — Kategorie, Marktplatz, Land, Zeitstempel — in einen Vektorspeicher geschrieben.
• Retrieval und Generierung. Zur Abfragezeit filtert das System zuerst über die strukturierten Felder, ruft die verbleibenden Dokumente per semantischer Ähnlichkeit ab und übergibt sie dem Modell als Kontext.

Die Reihenfolge ist entscheidend. Teams, die die strukturierte Filterung überspringen und sich allein auf Embeddings verlassen, erhalten semantisch ähnliche, aber kommerziell irrelevante Produkte — die 256-GB-Variante, wenn nach 128 GB gefragt war.

Welche Daten braucht die Retrieval-Schicht?

Die Retrieval-Qualität ist durch die Feed-Qualität begrenzt. Jeder Datensatz sollte mindestens enthalten:

• Kanonische Produkt-ID und die SKU des Marktplatzes
• Aktueller Preis, Listenpreis und laufende Aktionen
• Verfügbarkeit und Händleridentität
• Erfassungszeitstempel, damit das Modell über Aktualität urteilen kann
• Land und Währung

Den Zeitstempel lassen Teams am häufigsten weg — und bereuen es am häufigsten. Ohne ihn kann das Modell einen vor einer Stunde erfassten Preis nicht von einem aus dem letzten Quartal unterscheiden und hat keine Grundlage, seine Antwort zu relativieren.

Die KI-fertigen Datensätze von Senkrondata sind genau dafür ausgelegt: normalisierte, mit Zeitstempeln versehene Datensätze in JSON, CSV oder Parquet, abgesichert durch ein Datengenauigkeits-SLA von 97,2 % über 500 Mio.+ Datensätze und 23 Länder.

RAG oder Fine-Tuning?

Beide lösen unterschiedliche Probleme, und Pricing-Teams greifen regelmäßig zum falschen.

• Fine-Tuning ändert, wie ein Modell schreibt und argumentiert. Es ist das richtige Werkzeug für Fachvokabular, Ausgabeformat oder einen einheitlichen Stil bei Preisempfehlungen.
• RAG ändert, was ein Modell weiß. Es ist das richtige Werkzeug für alles, was sich nach dem Training ändert — also praktisch jede Zahl in einem Pricing-System.

Ein Modell mit den Preisen des Vormonats zu trainieren macht es nicht aktuell, sondern selbstbewusst veraltet. Wenn Ihre Frage eine bewegliche Zahl enthält, lautet die Antwort Retrieval.

Woran scheitern Pricing-RAG-Projekte?

Vier Fehlerbilder erklären die meisten enttäuschenden Pilotprojekte:

• Veralteter Index, aktuelles Modell. Die Pipeline wird einmal gebaut, der Aktualisierungstakt nie an die Kategoriegeschwindigkeit angepasst. Die Retrieval-Schicht altert still in genau das Problem hinein, das RAG lösen sollte.
• Kein Produktabgleich. Angebote desselben Produkts werden nie zu einer Entität zusammengeführt; das Retrieval liefert Beinahe-Duplikate und das Modell mittelt über Varianten.
• Ungefilterte semantische Suche. Ohne strukturierte Vorfilter liefert "günstigster 55-Zoll-OLED in Deutschland" 65-Zoll-Modelle aus anderen Märkten.
• Keine Herkunftsangabe in der Antwort. Trägt die Antwort weder Marktplatz noch Erfassungszeit, kann sie niemand nachprüfen — und nach der ersten Fehlentscheidung ist das Vertrauen weg.

Wie fängt man an?

Die pragmatische Reihenfolge lautet: erst der Feed, dann der Abgleich, dann der Index, zuletzt der Prompt. Die meisten Teams gehen umgekehrt vor und optimieren wochenlang Prompts auf Daten, die eine korrekte Antwort nie hätten tragen können.

Wenn Sie die Erfassung bereits selbst betreiben, kann unsere Preisüberwachungs-API die Retrieval-Schicht direkt speisen. Wenn Sie bei null starten, verkürzen fertige Datensätze den ersten Meilenstein von Monaten auf Tage.

Den größeren Zusammenhang beschreibt unser Leitfaden zur Beobachtung der Preise von Wettbewerbern.