Von Snowflake zu KI: Predictions und LLMs am Commerce-Datenmodell

Wenn der CDO im Quartalsmeeting fragt, "wo steht unsere KI?", dann ist die ehrliche Antwort selten ein einzelner Use Case — sondern eine Landkarte. Auf dieser Landkarte liegen drei Reifegrade nebeneinander: deterministische Berechnungen (Umsatz nach Region, Lagerreichweite, Marge pro SKU), probabilistische Predictions (CLV, Churn-Wahrscheinlichkeit, Next-Best-Action) und LLM-gestützte Entscheidungen (Service-Co-Pilot mit Order-Historie, generierte Produkttexte, semantische Suche im Katalog). In Snowflake-Projekten bei foobar Agency sehen wir, dass Kunden alle drei brauchen — aber selten gleichzeitig in der gleichen Liga spielen. Dieser Beitrag schließt die Daten-Serie ab und zeigt, was Snowflake Cortex und Snowpark ML heute liefern, wo LLMs auf strukturierten Commerce-Daten tragen und welche Voraussetzungen erfüllt sein müssen, bevor das Datenmodell zum Vertrag zwischen klassischen Modellen und Sprachmodellen wird.

Die drei Reifegrade unterscheiden sich nicht im Datenstand, sondern in der Frage, die sie beantworten. Deterministische Berechnung beantwortet "Wie viel?" und "Wann?" — präzise, reproduzierbar, in jedem Dashboard nachvollziehbar. Probabilistische Prediction beantwortet "Wie wahrscheinlich?" — sie liefert Erwartungswerte mit Konfidenzintervallen, getragen von Feature-Engineering und einem trainierten Modell. LLM-gestützte Entscheidung beantwortet "Was passt hier?" — sie verarbeitet unstrukturierte Texte, kombiniert sie mit strukturiertem Kontext und gibt eine Antwort, die in der Form variiert.

In Snowflake liegt das Fundament für alle drei in der gleichen Lakehouse-Architektur. dbt-modellierte marts-Tabellen versorgen die deterministischen Berichte, Snowpark ML trainiert und versioniert die Prediction-Modelle, und Snowflake Cortex stellt LLM-Funktionen direkt als SQL bereit — `COMPLETE` für Antworten, `EMBED_TEXT_768` und `EMBED_TEXT_1024` für Vektor-Repräsentationen, `EXTRACT_ANSWER` für Question-Answering auf unstrukturierten Texten, `SUMMARIZE` für Zusammenfassungen. Die Modelle laufen verwaltet in der Snowflake-Region; eigene Modelle lassen sich über Snowpark Container Services betreiben.

Architektonisch heißt das: Das Datenmodell wird zum Vertrag. Die gleichen marts-Tabellen, die das CLV-Modell trainieren, liefern den Kontext für den Service-Co-Piloten. Die gleichen Produkt- und Kategorie-Embeddings, die die semantische Suche tragen (siehe Serie 1, Post 4 — Semantische und agentische Suche), liefern Kandidaten für die LLM-gestützte Antwort. Wer diese Trennung nicht sauber zieht, baut für jeden Use Case eine eigene Pipeline — und verliert die Skalierung.

Snowflake Cortex stellt vortrainierte Modelle als verwaltete SQL-Funktionen bereit. Die Modelle laufen innerhalb der Snowflake-Security-Perimeter; die Daten verlassen die Snowflake-Region nicht, wenn die gewählte Funktion in der Region verfügbar ist. Für Commerce-Projekte sind aus unserer Sicht vier Funktionsklassen relevant.

Erstens: `COMPLETE` ruft ein Sprachmodell mit Prompt und optionalem Konversations-Kontext auf. Verfügbare Modelle reichen von Snowflakes eigenem Arctic über Mistral und Meta Llama bis zu Anthropic-Modellen — die Auswahl hängt an Region und Pricing. Praktisch nutzbar für Produktbeschreibungs-Entwürfe aus PIM-Attributen, Kategorisierung freier Service-Anfragen, Auswertung von Review-Texten.

Zweitens: `EMBED_TEXT_768` und `EMBED_TEXT_1024` erzeugen Vektor-Embeddings aus Texten. In Kombination mit Snowflakes Vector-Datentyp und der `VECTOR_COSINE_SIMILARITY`-Funktion lassen sich Embedding-basierte Such- und Empfehlungsstrecken vollständig in SQL formulieren — ohne separate Vektor-Datenbank. Für mittlere Katalog-Größen (bis in den niedrigen Millionenbereich an SKUs) ist das ein pragmatischer Pfad. Für sehr große Kataloge oder Sub-100-ms-Anforderungen bleibt eine spezialisierte Vector-Engine relevant.

Drittens: `EXTRACT_ANSWER` beantwortet Fragen aus einem mitgelieferten Textkontext. Für Service-Co-Piloten und FAQ-Strecken ist das die ehrlichste Variante — die Antwort kommt zwingend aus dem übergebenen Kontext, nicht aus dem Modellgedächtnis. Halluzinations-Risiko sinkt, weil das Modell keine Quelle hat, in der es frei wandern könnte.

Viertens: `SUMMARIZE` und Hilfsfunktionen wie `TRANSLATE` oder `SENTIMENT`. Diese liegen in der zweiten Reihe — nicht weil sie unwichtig sind, sondern weil sie als Bausteine in größeren Pipelines auftauchen, nicht als Use-Case-Treiber.

Wer mehr Kontrolle braucht — eigene Modelle, eigene Tokenizer, eigene Inference-Logik — geht über Snowpark Container Services. Das ist die Variante für Industrie-Kunden mit bestehenden ML-Investitionen, die nicht auf verwaltete Modelle migrieren wollen, sondern Snowflake als Daten- und Compute-Plattform nutzen.

LLMs liefern den größten Hebel dort, wo strukturierte Commerce-Daten auf unstrukturierte Anfragen oder unstrukturierte Texte treffen. Drei Use Cases sehen wir in DACH-Projekten besonders häufig.

Embedding-basierte Suche und Empfehlung. Produkt- und Kategorie-Texte werden mit `EMBED_TEXT_768` in Vektoren überführt, in einer marts-Layer-Tabelle abgelegt und zur Suchzeit gegen das Embedding der Anfrage abgeglichen. Das ergänzt — nicht ersetzt — die klassische SKU- und Facetten-Suche aus Serie 1, Post 4. Im B2C trägt das Muster bei Discovery-lastigen Sortimenten (Möbel, Mode, Drogerie). Im B2B-Industrie-Kontext aus Serie 2, Post 3 liefert es Treffer für Suchanfragen, die in der klassischen Volltextsuche scheitern — etwa "Ersatzteil für Sicherung, die nach Regen ausgefallen ist".

Generative Produktbeschreibungen aus PIM-Daten. Aus strukturierten Attributen (Materialien, Maße, Normen, Anwendungsfeldern) erzeugt ein Prompt mit `COMPLETE` einen ersten Beschreibungs-Entwurf. Der Wert liegt nicht in der finalen Qualität — die übernimmt die Redaktion — sondern in der Skalierung über Kataloge mit zehntausenden SKUs und mehreren Sprachen. Voraussetzung: ein PIM-Datenstand, der die relevanten Attribute sauber führt. Ohne saubere Eingangsdaten halluziniert das Modell, weil ihm Spezifika fehlen.

Service-Co-Pilot mit Order- und Service-Historie als Kontext. Eine Service-Anfrage trifft ein — der Co-Pilot zieht in einer Snowflake-Abfrage die Order-Historie des Kunden, die letzten Service-Tickets, die zugehörigen Produktstammdaten und gibt sie mit der eingehenden Anfrage als Kontext an `COMPLETE` oder `EXTRACT_ANSWER`. Das Modell formuliert keinen freien Vorschlag, sondern eine Antwort, die im Kontext verankert ist. Halluzinations-Risiko sinkt, Servicequalität steigt, ohne dass jeder Bearbeiter selbst alle Datenquellen abklappert.

Was diese drei Use Cases verbindet: Sie greifen auf das gleiche Datenmodell zu. Die gleichen Customer-, Order- und Product-Tabellen, die die deterministischen Reports speisen, sind die Quelle für den LLM-Kontext. Wenn das Datenmodell aus Serie 2, Post 1 — Foundation trägt, tragen die LLM-Use-Cases.

"Ist das DSGVO-konform?" ist die häufigste Frage im KI-Workshop und die unpräziseste. DSGVO-Konformität ist kein Schalter, sondern ein Bündel aus Datenresidenz, Verarbeitungs-Vereinbarungen, Zugriffskontrollen und der Frage, wer im Zweifel rechtlich worauf zugreifen kann. Drei Mechanismen sollten in jedem Cortex-Projekt benannt sein.

Region-Pinning. Snowflake Cortex-LLM-Funktionen sind regional verfügbar — nicht jede Funktion in jeder Region. Wer auf eine AWS- oder Azure-EU-Region pinnt, hält die Inferenz dort. Vor dem Roll-out gehört geprüft, welche Funktion in der Zielregion verfügbar ist und welches Modell hinter `COMPLETE` läuft; Cross-Region-Inference kann sonst unbemerkt aktiv sein und Daten in andere Regionen replizieren.

Schrems II und CLOUD Act. Eine EU-Region beim US-Hyperscaler löst die Schrems-II-Frage nicht restlos. US-Anbieter unterliegen US-Recht — auch für Daten, die physisch in Frankfurt liegen. Wer hier strikt souverän braucht (öffentlicher Sektor, kritische Infrastruktur, einzelne regulierte Industrien), muss die Architektur mit Rechtsabteilung und ggf. Sovereign-Cloud-Anbietern bewerten. Für die meisten Commerce-Projekte ist die Kombination aus EU-Region, Auftragsverarbeitungs-Vereinbarung und konsequenter Pseudonymisierung im marts-Layer tragfähig — aber sie ist es nicht "automatisch".

Halluzinations-Kontrolle als DSGVO-Anliegen. Eine LLM-Antwort, die personenbezogene Daten erfindet ("Frau Schmidt hat letzte Woche bestellt"), ist keine Fehlfunktion — sie ist im Zweifel ein DSGVO-Vorfall. Wer LLMs auf Kundendaten loslSt, braucht Retrieval-Augmented Generation mit eindeutigen Quellen, Eval-Sets für Halluzinations-Detection und Logging, das die Quelle jeder Antwort nachvollziehbar macht.

Was nicht trägt: das Versprechen "ist DSGVO-konform" als Marketing-Aussage ohne konkrete Mechanismen. Was trägt: Region-Pinning, Datenresidenz, Pseudonymisierung im Datenmodell, definierte Modelle, dokumentierte Verarbeitungs-Vereinbarungen.

Nicht jeder Use Case verdient ein LLM. Eine CLV-Prediction auf RFM-Features ist ein Gradient-Boosting-Modell — kein LLM-Job. Eine Lagerreichweiten-Berechnung ist eine SQL-Abfrage — kein LLM-Job. Ein LLM rechtfertigt sich, wenn drei Bedingungen zusammenkommen: Die Eingabe ist unstrukturiert oder die Ausgabe ist sprachlich variabel, das Problem hat hohe Heterogenität (jede Anfrage ist anders), und der Kontext aus strukturierten Daten ist verfügbar.

Wer LLMs auf Use Cases setzt, bei denen ein deterministisches oder probabilistisches Modell stärker, billiger und besser auditierbar ist, baut sich ein Risiko ein, das im ersten Audit auffällt. Wer umgekehrt klassische Modelle auf Use Cases zwingt, die echte Sprachverarbeitung brauchen, baut Workarounds, die mit jedem neuen Sortiment oder jeder neuen Sprache wieder zerfallen. Die Reifegrad-Logik aus Section 1 ist keine Hierarchie — sie ist eine Zuordnung.