Author: Chen Yicun, senior algorithm engineer of Ele. me Data Operation Department, shared on Ctrip personalized recommendation and ARTIFICIAL intelligence Meetup. He joined Ele. me in 2016 and is now engaged in big data mining and algorithm-related work, including recommendation system and user portrait.

With the development of mobile Internet, users’ usage habits become increasingly fragmented. How to let users find the products they want in the limited access time has become an important responsibility of the evolution of search/recommendation system. As a unicorn in the food delivery field, Ele. me has millions of daily active users. How to use data mining/machine learning methods to explore potential users and increase user engagement has become an urgent problem to be solved.

Personalized recommendation system through the study of user’s interest preference, personalized calculation, to find the user’s interest point, so as to guide users to find their own information needs. A good recommendation system can not only provide users with personalized services, but also establish a close relationship with users, so that users rely on the recommendation.

This sharing introduces how Ele. me builds a fast iterative recommendation system from zero to one, including recommendation model and feature engineering, log processing and effect evaluation, as well as deeper scene selection and intention recognition from the perspective of product form.

On Ctrip personalized recommendation and Artificial intelligence Meetup, the above parts have been explained as a whole. In this paper, the online implementation of model ordering and feature calculation will be specifically explained, and the shuffling logic related to business rules will be supplemented to restore and show the Ele. me food recommendation system in detail.

First, model sequencing

1. Design process

For any external request, the system builds a QueryInfo(query request), extracts UserInfo(user information), ShopInfo(merchant information), FoodInfo(food information), and ABTest configuration information from various data sources, and then invokes Ranker sort. Here is the basic flow of sorting (as shown below) :

  • Call RankerManager, initialize Ranker:

  1. According to the ABTest configuration information, build the sorter Ranker;

  2. Retrieve ScorerManger, specify the required Scorer(can be more than one); At the same time, Scorer will obtain the corresponding Model from ModelManager and verify it.

  3. Enlist the FeatureManager to specify and validate the Features required by the Scorer.

  • InstanceBuilder was used to summarize the Features of all Scorer and calculate the Features required by EntityInfo(restaurant/food) ranking.

  • Score EntityInfo and sort Records as needed.



    • It is important to note that any Model Model must be presented or invoked as a Scorer. Mainly based on the following considerations:

    • Model iteration: for example, multiple versions of the same Model can be derived based on time, location, data sampling, etc.

    • Model parameters: such as weight and round setting in combination mode (see the next section), whether the model supports parallelization, etc.

    • Feature parameters: Feature Feature calculation parameters, such as distance in different cities with different segmentation parameters.

    2. Sorting logic

    For machine learning or learning sequencing, the combination of multiple models (Bagging, Voting, Boosting, etc.) tends to produce stable and efficient predictions. Therefore, for the current food recommendation project, the framework, combined with ABTest system, supports three combination modes including Single, Linear and Multi, as described below:

    • Single: single mode, only one Scorer is used for ranking and scoring;

    • Linear: a linear weighted model specifying a series of Scorer and their corresponding weights, and a weighted sum;

    • Multi: Specifies the Scorer in each round and sorts only the top N entries in the previous round.

    Specific instructions are as follows:

    Single mode: rankType=single

    For a single mode, there is only one Scorer, and there is no mixing, so it is only necessary to sort the Scorer’s score. Therefore, detailed expansion will not be carried out here. The ABTest configuration format is as follows:

    Linear weighting mode: rankType= Linear

    For linear weighted mode, on the basis of single mode configuration, weight of each Scorer needs to be configured in ABTest, as shown in the following table:

    When the LinearRanker is initialized, it checksums and initializes all the Scorer markers. Then follow these steps to sort the restaurant/food list, as shown below (left) :

    • Feature calculator InstanceBuilder calls ScorerList to obtain all required Feature features and remove the weight.

    • InstanceBuilder features all restaurants/foods, see feature Calculation;

    • All the Scorer in the ScorerList rated all the restaurants/foods in order;

    • You take the weighted sum of all the Scorer scores and sort them.

    Multi-round sorting mode: rankType=multi

    For multi-round sorting mode, one Scorer is set for each round, and top=Num restaurants/food in the previous round is sorted. Therefore, round and Num of each Scorer need to be set in ABTest, as shown in the following table.

    MultiRanker initialization and feature calculation are similar to LinearRanker. See the steps in the figure above (right) :

    • Feature calculator InstanceBuilder calls ScorerList to obtain all required Feature features and remove the weight.

    • InstanceBuilder features all restaurants/foods, see feature Calculation;

    • Scorer scores top=Num restaurants/food by round;

    • Rank top=Num restaurants/food by the current Scorer’s score.

    Repeat steps 3 and 4 until all rounds have been completed.

    During the initialization phase, Ranker specifies algorithm version (algoVersion), sort type (rankType), sort level (rankLevel), and associated ScorerList (ScorerList) based on the ABTest configuration information.

    3. Model definition

    For any Model online, The ModelManager gets the corresponding instance and functionality through the following process (as shown below) :

    • Model instantiation constructor BaseModel() and validation function validate();

    • Abstract getFieldNames()/getFeatures() are obtained by FeatureManager.

    • Abstract predict(Map) is obtained by importing the features of the Model

    For the iteration and update of Model, as well as the subsequent Online Learning, the corresponding services are connected with ModelManager to achieve.




    As shown in the figure above, for any Model that can be called directly by the Scorer, the following interface needs to be implemented:

    1. BaseModel() and init() are available for ModelManager to instantiate the Model.

    2. GetFieldNames ()/getFeatures() for feature items available to the Scorer/InstanceBuilder;

    3. Predict (Map<K, V> values) and PREDICT (List<Map<K, V> values)&#8232

    2. Feature calculation

    1. Design process

    Different from offline model training, online feature calculation requires low delay, high reuse and strong expansion, as follows:

    • Low latency: For different Query requests, it can quickly calculate the current eigenvalues, including real-time extraction of relevant data from various DB, Redis, ES and other data sources for calculation;

    • High reuse: For features of the same type or the same operation, it should have high reuse and avoid repeated development, such as feature cross operation, extraction of basic fields from USER/SHOP, etc.

    • Strong scaling: Features can be implemented quickly and easily, with low coupling and reduced development costs.

    According to the above system design requirements, the following figure shows the design process of feature calculation and the description of feature base class.




    Specific instructions are as follows:

    • FeatureManager: FeatureManager for feature management. Features include:

    A. Feature management: including custom features, basic features, real-time features, composite features, etc. B. Feature import: custom feature static code registration, other feature database import; C. Feature construction: CompsiteFeature type feature construction.

    • InstanceBuilder: Feature builder for calculating restaurant/food features as follows:

    A. Obtain the Feature list from each Scorer, remove repetition, rely on calculation, and finally initialize; B. Calculate the eigenvalues of each EntityInfo hierarchically and in parallel (ETL will be considered later for Online Learning).

    2. Feature definition

    The above figure shows the description of the feature base class. The following is the description of the specific fields and methods:

    • Type: Feature type, including Query, shop and food, represents Feature dimension (granularity) of Feature.

    • Operate: CompositeFeature exclusive, feature operation, specify the current feature behavior, such as ADD, MAPGET, etc.

    • Name: feature name.

    • Weight: weight, simple linear model parameter;

    • RetType: type of the returned field.

    • DefValue: indicates the default return value of a feature.

    • Level: CompositeFeature exclusive, current feature hierarchy, used for feature hierarchy calculation;

    • Operands: CompositeFeature exclusive, feature operands, pre-feature directly dependent;

    • Dependencies: CompositeFeature exclusive, feature dependent;

    • *init(): feature initialization function;

    • *initOther(QueryInfo): real-time initialization when InstanceBuilder is called, that is, passing in the current characteristic parameter;

    • Evaluate (QueryInfo, EntityInfo, StringBuilder): Evaluate the restaurant/food dimension.

    According to the design process and base class definition in the above two sections, we can implement a custom feature very quickly and easily. The specific process is as follows (Score, corresponding to the class name XXXFeature) :

    Feature class implementation:

    • Establish XXXFeature and inheritance BaseFeature/CompositeFeature;

    • Implement init(), set type\name(defValue\weight optional), etc.

    • Implement initOther(), set characteristic parameters, including infoMap;

    • Implement Evaluate (), which includes the detailed logic for evaluating the characteristics of the return value.

    Feature Registration:

    • Register with FeatureManager, or in the backend feature management system.

    • Since plaintext constants are not allowed in your code, you need to add a constant definition in FeatureConsts.

    3. Feature classification

    (1) Basic Features:

    Basic features can be obtained online from SHOP/USER by configuring feature names, such as shop_meta_, user_meta_, and food_meta_. Details are described in the following table. These features are essentially equivalent to feature operators (compound features).

    (2) Real-time features:

    Real-time features are derived from real-time calculation of Kafka and Storm logs and stored in Redis, such as user food search and click information, as shown in the following table.

    (3) Custom features:

    In addition to CompositeFeature, all XXxfeatures are self-defined features, which are not mentioned here.

    (4) CompositeFeature:

    Complex operations that combine user characteristics, such as the following table (in part)

    Shuffle logic

    1. Shuffle type

    In many cases, the results based on the algorithm model can give the best results at the data level, but it cannot guarantee that the recommendation results are in line with people’s cognition. For example, based on the logic of CTR estimation, the recommendation results tend to favor merchants/food that users have ordered or purchased, which makes the recommendation lack of enough interest. Therefore, in order to ensure the correlation between the recommendation results and users, we will retain the results of the algorithm model. At the same time, in order to ensure that the results conform to cognition, we artificially add rules to shuffle the results. Finally, in order to expand users’ interest points and guide users to choose, non-relevant merchants/food will be manually introduced, which will be one of our subsequent optimization points. Some of the shuffling logic that works online in the Guess you Like module is detailed below, and the other shuffling rules are similar.

    Restaurant Category shuffle:

    Considering the restaurant ordering, in order to avoid the problem of clustering restaurants of the same category, we set the restaurant category shuffling, the basic rules are as follows:

    For top = SHOP_CATE_TOPNUM restaurants, do not allow restaurants of the same category to exceed MAX_SHOP_SHOPCNT continuously.

    Restaurant recommended food reshuffle:

    In the restaurant list, we always want the merchant at the top of the list to have better presentation and higher quality. For the 1* restaurant +3* food mode, the overall effect of the page will be greatly reduced if the food in the front row restaurant is missing (less than 3), so we formulated the food number shuffle, and the specific rules are as follows:

    All 1 food restaurant bottom; For top=SHOP_FOODCNT_TOPNUM restaurant, food number < SHOP_FOODCNT_FOODCNT(3) restaurant reduced right

    Restaurant name shuffle:

    Normally, the recommendation needs to expand and guide the user’s interest points to avoid clustering, such as covered rice restaurants. Similarly, we do not want to cluster restaurants with the same or similar names, such as chain stores, Zhending Chicken and so on. In view of this problem, considering the irregularity of restaurant names, we made a structural classification of all restaurant names through word segmentation and statistics, for example, all “XXX Yellow Braised Chicken” was listed as “Yellow Braised Chicken” and “Starbucks XX Store” was listed as “Starbucks”. After similar to the restaurant category shuffle, do rearrangement, the specific rules are as follows:

    Top =SHOP_FLAG_TOPNUM (top=SHOP_FLAG_TOPNUM, top= SHOP_FLAG_SPAN

    2. Online logic

    As can be seen from the previous section, there are mutual constraints among all shuffling cards, that is, shuffling cards cannot be parallel but serial, and different sorting results will result from who comes first and who comes last. Therefore, the impact and priority of each shuffling card on sorting need to be considered here:

    • Impact degree: that is, the intensity of the rearrangement of the original list. For example, for an area with few chain stores, the impact degree of name shuffling will be small; otherwise, for example, if there are 25 Zhending chickens around the company, the impact degree will be larger;

    • Priority: that is, the importance of shuffling. For example, if the number of food in the restaurant in the front row is less than the specified amount, its essence is a waste of page exposure, so it is necessary to shuffle the number of food.

    Given the serial logic of shuffling cards, shuffling cards further back has higher priority. In order to flexibly change the shuffle rules on the line, the System combined with Huskar System(Online Configuration Modification System) can change the shuffle logic quickly and easily. An example configuration is shown below.

    [
{"name": "recfoods", "topnum": 15, "foodcnt": 3}, 
{"name": "category", "topnum": 15, "shopcnt": 2}, 
{"name": "shopflag", "topnum": 20, "span": 3, "exclude": "XXX"}},
{"name": "recfoods", "topnum": 15, "foodcnt": 3},
{"name": "dinner","topnum":5,"interval": ["10:30~12:30","16:30~18:30"]},
{"name": "mixture","topnum":12, "include": "XXX"}
]Copy the code

    Four,

    For an Internet enterprise in the period of rapid business growth, how to build a fast iterative recommendation system in the shortest time is a realistic problem in front of us. The sharing from hungry? Their business, with the common problems in the recommendation system and solutions, from the perspective of product form is given, including the recommended model and the characteristics of the engineering, log processing and evaluation, selection and intention recognition and deeper scenes, such as various online practice, tries to restore from the overall and details and show the essence of the recommendation system, In order to provide help for your future work.