CH16-01: AI Workloads in E-Commerce Mental Model

Goal

Chapter 15 introduced the customer-facing commerce platform: browsing, search, cart, checkout, orders, notifications, and delivery tracking. AI workloads sit on top of that platform, but they do not all have the same shape.

Some AI capabilities influence product discovery. Some protect checkout from fraud. Some forecast demand. Some help support agents answer questions. Some help sellers improve catalog content. These workloads may all use models, but they have different data, latency, safety, explainability, and operating needs.

The durable idea for this chapter is:

Start by naming the AI workload, then name the data, decision, risk, and operating loop around it.

The Short Version

The easy question is:

Where do we add AI?

The better architecture question is:

Which business decision or user experience are we improving, and what control loop makes it safe to operate?

In commerce, AI should be treated as a portfolio of capabilities:

Commerce Outcome	AI Capability	Architecture Shape
Help customers discover products.	Recommendations and ranking.	Low-latency serving, experimentation, event data, catalog quality.
Improve search relevance.	Semantic search, ranking, query understanding.	Search indexes, relevance tuning, catalog metadata, click feedback.
Personalize experiences.	Offers, content, sorting, product suggestions.	Consent, customer context, segmentation, real-time or near-real-time features.
Protect checkout.	Fraud and abuse detection.	Low-latency risk scoring, explainability, audit, human review, false-positive control.
Plan operations.	Demand forecasting.	Historical orders, inventory, seasonality, batch processing, forecast accuracy.
Help support agents.	Retrieval-augmented assistant.	Authorized retrieval, citations, policy grounding, tool use, audit logs.
Help sellers.	Seller assistant and content suggestions.	Seller-specific authorization, catalog tools, moderation, approval paths.
Protect content quality.	Content moderation.	Safety classifiers, review workflows, evidence, appeal handling.

This table is not a product list. It is a reminder that each AI workload has a different job.

Workload Shape Before Model Name

Use this mental model:

Commerce outcome
	-> AI capability
	-> Data source
	-> Decision or response
	-> Risk of being wrong
	-> Serving path
	-> Evaluation and monitoring loop

The model name comes late in this chain. A recommendation model, a fraud model, and a customer support assistant may all use machine learning, but they are not one architecture.

Recommendations may run in a product page request and need low latency. Fraud detection may run during checkout and needs strong audit and false-positive handling. A support assistant may use Azure OpenAI with retrieval over approved policies and order data, but it must preserve support-agent permissions and avoid exposing data from another customer.

Training, Inference, Retrieval, Tools, and Review

Commerce AI usually combines several patterns:

Pattern	What It Means
Offline training	A model is trained from historical data, such as orders, clicks, returns, or fraud outcomes.
Online inference	An application asks a model or service for a prediction during a user flow.
Retrieval-augmented generation	An assistant retrieves approved knowledge before generating an answer.
Tool use	An assistant calls controlled APIs, such as order lookup or refund request creation.
Human review	A person reviews uncertain, risky, or policy-sensitive outcomes.
Feedback loop	User behavior, agent feedback, business outcomes, and safety findings improve later versions.

You do not need to master every AI implementation detail yet. The architectural point is that each pattern creates responsibilities: data quality, identity, authorization, latency, monitoring, cost, safety, and rollback.

Example: Recommendations Versus Support Assistant

A product detail page requests recommendations. The system needs customer context, product catalog data, inventory signals, interaction history, and a low-latency serving path. The design should measure clicks, conversion, add-to-cart rate, revenue impact, unavailable-item promotion, latency, and cost. It should support experimentation because a recommendation model can improve one metric while hurting another.

A support assistant answering policy questions has a different shape. It needs approved policy documents, order context, customer context, support-agent authorization, citations, refusal behavior, and audit logs. It may use Azure OpenAI for language generation and Azure AI Search for retrieval, but the important architecture question is whether the assistant can see only what the current support agent is allowed to see and whether its answer can be verified.

Both are AI workloads. They should not share one generic design.

AI as a Product Capability

An AI workload should have owners, metrics, feedback loops, and rollback plans.

Ask:

Who owns this AI capability?
What business outcome should improve?
What data is allowed to influence the decision?
What happens when the model is uncertain or wrong?
Who can change prompts, models, features, retrieval indexes, or tool schemas?
How are quality, safety, latency, and cost monitored?
How can the team disable or roll back a harmful version?

These questions make AI architecture concrete. They also prevent the common mistake of treating AI as a feature demo instead of a production system.

Common Mistakes

Treating AI as one shared service with one architecture.
Optimizing for model quality while ignoring data permissions, user consent, and operating loops.
Adding an assistant without defining what it can see, say, or do.
Measuring clicks while ignoring safety, support quality, returns, or customer trust.
Shipping prompt, model, index, or feature changes without rollback.

If Someone Asks You

How would you categorize AI workloads in an e-commerce platform?

A good answer is:

I would separate them by workload shape. Recommendations, search relevance, personalization, fraud detection, forecasting, support assistants, seller assistants, and moderation all have different data sources, latency needs, risks, explainability requirements, and operating loops. I start by naming the business outcome and decision, then the data, serving path, controls, evaluation metrics, and rollback plan. The model is only one part of the architecture.

What You Should Remember

AI architecture starts with the workload shape, not the model name.

Questions to Check Understanding

Which commerce AI workloads need online inference?
Which workloads need stronger explainability or audit evidence?
Why is experimentation part of the architecture conversation?