From Snowflake to AI: Predictions and LLMs on the Commerce Data Model

When the CDO asks in the quarterly review, "where do we stand on AI?", the honest answer is rarely a single use case — it's a map. On that map, three maturity stages sit side by side: deterministic calculations (revenue by region, stock coverage, margin per SKU), probabilistic predictions (CLV, churn probability, next-best-action), and LLM-driven decisions (service co-pilot with order history, generated product descriptions, semantic search across the catalogue). Across Snowflake projects at foobar Agency, we see that clients need all three — but rarely operate at the same level in each. This post closes the data series and shows what Snowflake Cortex and Snowpark ML deliver today, where LLMs add weight on structured commerce data, and which prerequisites need to be in place before the data model becomes the contract between classical models and language models.

The three maturity stages differ not in the data they consume but in the question they answer. Deterministic calculation answers "how much?" and "when?" — precise, reproducible, traceable in any dashboard. Probabilistic prediction answers "how likely?" — it delivers expected values with confidence intervals, carried by feature engineering and a trained model. LLM-driven decision answers "what fits here?" — it processes unstructured text, combines it with structured context and returns an answer that varies in form.

In Snowflake, the foundation for all three sits in the same lakehouse architecture. dbt-modelled marts-layer tables feed deterministic reports, Snowpark ML trains and versions prediction models, and Snowflake Cortex exposes LLM functions directly as SQL — `COMPLETE` for responses, `EMBED_TEXT_768` and `EMBED_TEXT_1024` for vector representations, `EXTRACT_ANSWER` for question-answering on unstructured text, `SUMMARIZE` for summarisation. The models run managed within the Snowflake region; custom models can be operated through Snowpark Container Services.

Architecturally, this means the data model becomes the contract. The same marts-layer tables that train the CLV model deliver the context for the service co-pilot. The same product and category embeddings that drive semantic search (see Series 1, Post 4 — Semantic and agentic search) deliver candidates for the LLM-driven answer. Skip this separation and you build a dedicated pipeline for every use case — and lose the scaling.

Snowflake Cortex makes pre-trained models available as managed SQL functions. The models run inside the Snowflake security perimeter; data does not leave the Snowflake region when the chosen function is available there. For commerce projects, four function classes are relevant from our perspective.

First: `COMPLETE` calls a language model with a prompt and optional conversation context. Available models range from Snowflake's own Arctic through Mistral and Meta Llama to Anthropic models — selection depends on region and pricing. Practically usable for product description drafts from PIM attributes, categorisation of free-text service requests, and analysis of review text.

Second: `EMBED_TEXT_768` and `EMBED_TEXT_1024` produce vector embeddings from text. Combined with Snowflake's vector data type and the `VECTOR_COSINE_SIMILARITY` function, embedding-based search and recommendation pipelines can be expressed entirely in SQL — without a separate vector database. For mid-sized catalogues (up to low millions of SKUs), this is a pragmatic path. For very large catalogues or sub-100-ms requirements, a specialised vector engine remains relevant.

Third: `EXTRACT_ANSWER` answers questions from supplied text context. For service co-pilots and FAQ flows, this is the most honest variant — the answer is forced to come from the supplied context, not from the model's memory. The hallucination risk drops because the model has no source in which to roam freely.

Fourth: `SUMMARIZE` and helper functions like `TRANSLATE` or `SENTIMENT`. These sit in the second row — not because they're unimportant, but because they appear as building blocks in larger pipelines rather than as use-case drivers.

Those who need more control — custom models, custom tokenisers, custom inference logic — go through Snowpark Container Services. That's the variant for industrial clients with existing ML investments who don't want to migrate to managed models but want to use Snowflake as their data and compute platform.

LLMs deliver the strongest leverage where structured commerce data meets unstructured queries or unstructured text. Three use cases recur in DACH projects.

Embedding-based search and recommendation. Product and category text is converted into vectors with `EMBED_TEXT_768`, stored in a marts-layer table, and matched at search time against the embedding of the query. This complements — rather than replaces — the classical SKU and facet search from Series 1, Post 4. In B2C, the pattern works for discovery-heavy assortments (furniture, fashion, drugstore). In the B2B industrial context from Series 2, Post 3, it returns hits for queries that fail in classical full-text search — for example "replacement part for fuse that failed after rain".

Generative product descriptions from PIM data. From structured attributes (materials, dimensions, norms, application fields), a prompt with `COMPLETE` produces a first draft of a description. The value does not lie in final quality — that's an editorial job — but in scaling across catalogues with tens of thousands of SKUs and multiple languages. Prerequisite: a PIM data set that maintains the relevant attributes cleanly. Without clean input, the model hallucinates because specifics are missing.

Service co-pilot with order and service history as context. A service request comes in — the co-pilot pulls the customer's order history, recent service tickets and related product master data in a Snowflake query, and passes them along with the incoming request as context to `COMPLETE` or `EXTRACT_ANSWER`. The model doesn't formulate a free suggestion but an answer anchored in the context. Hallucination risk drops, service quality rises, without each agent walking through every data source by hand.

What unites these three use cases: they access the same data model. The same customer, order and product tables that feed deterministic reports are the source of the LLM context. If the data model from Series 2, Post 1 — Foundation holds, the LLM use cases hold.

"Is this GDPR-compliant?" is the most frequent question in the AI workshop and the most imprecise one. GDPR compliance is not a switch but a bundle of data residency, processing agreements, access controls, and the question of who is ultimately empowered, legally, to access what. Three mechanisms should be named in every Cortex project.

Region pinning. Snowflake Cortex LLM functions are available regionally — not every function in every region. Pinning to an AWS or Azure EU region keeps inference there. Before rollout, check which function is available in the target region and which model sits behind `COMPLETE`; otherwise cross-region inference can quietly become active and replicate data into other regions.

Schrems II and the CLOUD Act. An EU region with a US hyperscaler does not fully resolve the Schrems II question. US providers are subject to US law — including for data physically located in Frankfurt. Where strict sovereignty is required (public sector, critical infrastructure, certain regulated industries), the architecture must be evaluated with legal counsel and possibly sovereign cloud providers. For most commerce projects, the combination of EU region, data processing agreement and consistent pseudonymisation in the marts layer is workable — but not "automatically".

Hallucination control as a GDPR concern. An LLM answer that invents personal data ("Ms Schmidt ordered last week") is not a malfunction — it is, in case of doubt, a GDPR incident. Whoever exposes LLMs to customer data needs retrieval-augmented generation with unambiguous sources, eval sets for hallucination detection, and logging that traces the source of every answer.

What doesn't hold: the marketing line "is GDPR-compliant" without concrete mechanisms. What does hold: region pinning, data residency, pseudonymisation in the data model, defined models, documented processing agreements.

Not every use case deserves an LLM. A CLV prediction on RFM features is a gradient-boosting model — not an LLM job. A stock-coverage calculation is a SQL query — not an LLM job. An LLM justifies itself when three conditions coincide: the input is unstructured or the output varies linguistically, the problem has high heterogeneity (each request is different), and structured context is available.

Forcing LLMs onto use cases where a deterministic or probabilistic model is stronger, cheaper, and more auditable builds in a risk that surfaces at the first audit. Conversely, forcing classical models onto use cases that need real language processing produces workarounds that collapse with every new assortment or language. The maturity logic from Section 1 is not a hierarchy — it's an assignment.