System Architecture

Chapter 5

Problem Solution and Forecasting Results

For Retail Demand Forecasting

5.1 Introduction

In this section we present (a) a system architecture for the solution of the RDF problem, (b) the technological approach that we followed for the construc- tion of a software prototype and (c) an analysis of the different modelling decisions that had to be made. The software prototype was based on the aforementioned system architecture. Finally, the modelling decisions regard the different ways to decompose a RDF problem into sub-problems.

FIGURE5.1: System Architecture Design

4.2.1. Also, the same module will provide the function of removing outliers, that would otherwise reduce the quality of the dataset.

TheTrain Modelmodule encapsulates all the functions that are related to the production of forecasting models. Those may be models from the the- ory of statistical forecasting or from the theory of machine learning. As in- put to the training algorithm, the module receives a set of preprocessed data records. A produced model is stored in the appropriate location of the mod- els repository according to

• what is the algorithm of the model

• when it was produced

• which part of the dataset it was trained on

• the set of stores on which it can be applied

• the set items on which it can be applied

there exist several options on what events may trigger the process of train- ing. These are (a) training driven by the insertion of new data records (b) training driven by a decrease in evaluation metrics (c) training driven by the user and (d) training driven by clock. The choice of the necessary triggers will be further discussed in section5.1.3.

TheQuery Processingmodule is responsible for the expansion of the query with the necessary features, so that it can become the input to a forecasting

model. A query is a triplet of the form (StoreID,ItemCode,SaleDate), which in natural language means: "What will be the quantity sold for the product with code< ItemCode> on date <SaleDate> for the store <StoreID>". In or- der to apply a model on the query, values must be inserted for the features mentioned in section 4.2.1. Since the prediction regards a future date, only some of the features will be known, while other will have to be estimated.

For instance, the trigonometric time features are completely known at the time of prediction but the total number of baskets is not. In either case, fu- ture values for all features (estimated or actual) are stored insecondary tables.

The generation of the secondary tables was driven by thefunctional dependen- cies that exist between features and portions of the key. Thus, it is possible to create a secondary table for every non-empty subset of the primary key {StoreID, ItemCode, SaleDate} that are 2³ − 1 = 8. Because only a few of these subsets are meaningful, the final system will require fewer than 8 sec- ondary tables.

TheCampaigns/Closing Daysmodule encapsulates the future value impu- tation for a certain set of features. These features regard the promotion of products (Marketing Campaigns), closing days for stores (CloseDaysAfter) and product prices (Amount). The value imputation for these features has to be done by the retail industry itself, as it is the agent that decides (or has a good understanding of) what these values will be ahead of time. As it was men- tioned in the previous paragraph, these features are also to be inputed in the related secondary tables.

The External Data module is responsible for the accumulation of exter- nal data such as the weather. Specifically, the module will have to produce certain weather features such astemperature, humidity, air direction and rain.

As the weather depends on (a) the time and (b) the location, these features should be stored in the secondary table that was produced from the (Sale- Date,StoreID). This is justified because the geographical featureslongitudeand latitudeare functionally dependent onStoreID. An important note is that the external data features should be extracted for all the past dates of the sales history as well, in order to participate in the training process. Otherwise, the model will not recognize these features, as they were not present at the time of training.

TheSelect and Apply Model for Predictionmodule receives as input the out- put of the moduleQuery Processing, that is the preprocessed query that has been enriched with the features mentioned in subsection4.2.1. Then, it’s re- sponsibility is to choose the appropriate model for the given query. Assume that in the models repositoryM there exists one forecasting model for each StoreID such thatM ={model_StoreID=1, model_StoreID=2, .., model_StoreID=N}. In this scenario, the module will have to extract theStoreID portion of the key in order to select the appropriate model. This is formalized as

Select the modelm_ID such thatID=query.StoreID

The decision of having one model per store is only one among many dif- ferent modeling decisions. Another modeling decision would be to have one model per (store,item). This would produce more models, as there are more (store,item) than stores. However, each model would be trained on signifi- cantly less data. It becomes clear that the way in which a model is matched to the query depends on such modelling decisions. The different set of mod- elling decisions, as well as these trade-offs that each offer, will be further explained in section5.1.3.

Other aspects of model selection are (a) the algorithm that produced the model and (b) the query horizon. Different algorithm may be better suited to answer queries for different sets of products, so it is possible to have a mod- els repository with different algorithmic models e.g. ARIMA and Random Forest. Finally, a model may be trained to give optimal responses for a fixed horizon.

For instance, assume a set of models{m_A1, m_A2, ..., m_A7}, wherem_A1 has been trained to answer queries for the next day(horizon= 1),m_A2 has been trained to answer queries that are two days ahead(horizon = 2)and so on.

In this case, the module will have to extract the query’s target date in order to compute the horizonh. Having computed the horizonh, it can then select the appropriate modelm_Ah. After a model has been selected, it is applied on the query to produce the forecast. The forecast, accompanied with a prediction confidence interval, is then returned to the user.

The last module in this architecture is the Evaluate System Performance module. The purpose of this module is to evaluate the forecasting perfor- mance of the system as a whole ( the lower level functionality ofmodel eval- uationis encapsulated in the module Train Model). In order to evaluate the overall performance, the module compares records between the databases Historical Sales DataandPredictions Data.

The way in which these databases are compared will be demonstrated in the following scenario. Assume that the system has estimated the salesˆsfor a specific (product,store) and for the two following weeks,sˆ= (ˆs₁,sˆ₂, ..,sˆ₁₄). The estimated sales sˆare then stored in the Predictions Data database. After a certain number of weeks, the actual sales s = (s1, s2, .., s14) for the same time period, store and product have been inserted in the Retail Industry’s database. Via the moduleAdd Sales Data, the new records are preprocessed and inserted in the system’s databaseHistoricalSalesData. The actual sales (s₁, s₂, .., s₁₄), as well as the estimated sales(ˆs₁,ˆs₂, ..,sˆ₁₄)are then available to the module. The module can now apply any of the evaluation metric men- tioned in section2.4.9. The evaluation results are needed for estimating more accurately the confidence intervals that accompany forecasts.