CH16-03: Target Architecture for Recommendations, Search, and Assistants

Goal

The previous section defined requirements by use case. This section sketches how those requirements can become an Azure architecture for recommendations, search relevance, assistants, data pipelines, model serving, and operations.

The architecture should not be one giant AI pipeline. It should have shared foundations and workload-specific serving paths. Recommendations, search ranking, fraud scoring, forecasting, and assistants can share data, governance, monitoring, and platform practices, but they should not all be deployed and operated as one capability.

The durable idea is:

A useful AI platform connects data pipelines, model lifecycle, serving paths, application integration, and operations.

The Short Version

The easy architecture is:

Put a model behind an API and call it from the website.

The stronger architecture is:

Build shared AI foundations, then design separate serving paths for each commerce workload.

Azure AI Foundry can help teams build, evaluate, deploy, and manage AI applications and models. Azure OpenAI Service provides access to generative models through Azure. Azure AI Search can support retrieval over indexed product, policy, support, or knowledge content. Analytics platforms such as Data Lake Storage, Databricks, Synapse, Fabric, or Azure Machine Learning may support feature engineering, training, experimentation, and evaluation depending on the workload.

Do not worry about the exact service mix yet. Focus on the responsibility layers.

Layered Target Architecture

Commerce data and events
	-> Analytics, feature, and retrieval pipelines
	-> AI platform foundations
	-> Workload-specific serving APIs
	-> Storefront, seller, support, and operations experiences
	-> Monitoring, evaluation, safety, and cost feedback

Data and Feature Foundations

The data foundation gathers and prepares the signals each workload needs:

Product catalog: titles, descriptions, images, taxonomy, attributes, price, and availability.
Interaction events: impressions, searches, clicks, carts, purchases, returns, ratings, and feedback.
Orders and checkout: order state, payment events, fulfillment state, refunds, and fraud-review outcomes.
Inventory and operations: stock levels, warehouses, replenishment, delivery promises, and substitutions.
Support and policy knowledge: policy articles, support cases, approved responses, escalation outcomes, and refund rules.
Seller data: listings, seller performance, policy status, content quality, and support interactions.

These signals may flow through the analytics platform created in Chapter 12. Some workloads need batch features. Some need streaming or near-real-time features. Some need retrieval indexes that are refreshed when product, policy, or support content changes.

The foundation should include data ownership, lineage, consent, retention, and quality checks. AI serving depends on data trust.

AI Platform Foundations

Shared platform capabilities may include:

Capability	Why It Matters
Model and prompt lifecycle	Prompts, model versions, feature definitions, and retrieval indexes are deployable changes.
Evaluation	Teams need test sets, regression checks, safety tests, and quality gates before rollout.
Retrieval infrastructure	Assistants need approved indexes, metadata filters, freshness rules, and citation behavior.
Access control	AI workloads must respect customer, seller, support-agent, and employee boundaries.
Observability	Teams need traces, latency, errors, model calls, retrieval quality, tool calls, safety events, and cost.
Experimentation	Recommendations, ranking, and personalization need A/B tests and safe rollout controls.
Cost reporting	Training, inference, embeddings, indexing, logging, and evaluation need owners and budgets.

This is the difference between a demo and a platform. A demo proves a model can answer. A platform proves the answer can be operated.

Workload-Specific Serving Paths

Each workload still needs its own serving path.

Recommendations

A product detail page or home page requests recommendations from a recommendation-serving API. The API uses product, inventory, interaction, customer-context, and experiment data where allowed. It must respond quickly and degrade safely if the recommendation service is unavailable.

The application should be able to fall back to popular products, category-level recommendations, or no recommendation panel rather than failing the page.

Search Relevance

Search relevance combines catalog indexes, ranking signals, query understanding, and feedback loops. Azure AI Search may support search over product data, while ranking logic and personalization may use additional model outputs or features.

The design should separate search availability from experimental ranking changes. A bad ranking experiment should not take down product search.

Assistants

A support assistant or seller assistant may use Azure OpenAI for language generation and Azure AI Search for retrieval over approved knowledge. It may call internal APIs through a controlled tool layer.

This serving path must preserve role context. A support agent assistant can retrieve policy and order context for an assigned case. A seller assistant can retrieve that seller's catalog and policy guidance. A customer assistant should not see internal support notes or another customer's order data.

Fraud and Forecasting

Fraud scoring may sit near checkout or post-order review. It needs low latency, audit evidence, and manual review paths for uncertain cases. Demand forecasting is often batch or scheduled and feeds planning workflows rather than customer-facing requests.

These workloads may share data foundations, but their serving and risk profiles are very different.

Example: Product Page and Support Assistant

A product detail page requests recommendations while the customer browses. The request should be fast. The model can use allowed customer context, product metadata, inventory availability, and current experiment assignment. If the service fails, the page still loads.

A support assistant retrieves policy and order context. It should include citations, avoid unsupported claims, follow support-agent authorization, and log which sources were used. If the assistant is uncertain, it should escalate to a human or suggest a safe next step.

Both experiences may use shared monitoring, evaluation, identity, and cost reporting. They should not share one uncontrolled serving path.

Experimentation Versus Production

AI teams need room to experiment, but production serving needs discipline.

Separate:

Experimental datasets from approved production features.
Offline notebooks from production pipelines.
Test prompts from approved prompt versions.
Evaluation indexes from production retrieval indexes.
Shadow or canary experiments from full rollout.

This separation protects the customer experience. It also makes it easier to explain which version influenced a business outcome.

Common Mistakes

Mixing experimentation datasets directly into production serving.
Treating prompt orchestration, model choice, and retrieval index changes as informal edits.
Building one team-owned AI pipeline that product, support, seller, and fraud teams cannot operate safely.
Sharing one serving path for recommendations, support assistants, fraud, and forecasting.
Forgetting fallback behavior when an AI service is slow or unavailable.

If Someone Asks You

What would a target Azure architecture for e-commerce AI include?

A good answer is:

I would include commerce data and event pipelines, feature and retrieval preparation, AI platform foundations, workload-specific serving APIs, application integration, evaluation, monitoring, safety controls, and cost reporting. Azure AI Foundry, Azure OpenAI, Azure AI Search, analytics storage, model endpoints, identity, Key Vault, and Azure Monitor may each play a role. I would separate recommendations, search, fraud, forecasting, and assistants because they have different latency, risk, authorization, and operating needs.

What You Should Remember

AI architecture needs both platform foundations and workload-specific serving paths.

Questions to Check Understanding

Which parts of the architecture are shared platform capabilities?
Which parts should remain workload-specific?
Why should experimentation and production serving be separated?