In PAI-Rec, each service and experiment must be associated with a recommendation scenario, such as waterfall recommendations on the homepage, in-cart recommendations that you may like, and related recommendations on the details page. The following section describes related terms.
Recommendation scenario
When you create a recommendation scenario, we recommend that you use a name that can indicate the page location of the recommendation scenario. For example, in the following figure, the word "homepage" contained in the scenario description "waterfall recommendations on the homepage" indicates the location of the scenario, and "waterfall" indicates that users can scroll down the homepage to browse recommendations.
The Traffic Code field is reserved for recommendation requests that are not routed to the PAI-Rec system. This is a common scenario. If you have a self-managed recommendation system, you may first switch 10% to 20% recommendation traffic of the scenario you created to the PAI-Rec system. When the PAI-Rec system achieves the desired effects, you may gradually switch more traffic to the PAI-Rec system. In the following example, the traffic of the HomePageRec scenario is routed to the PAI-Rec system by default. The value selfhold in the Traffic Code column indicates the traffic that is routed to your self-managed recommendation system and the value thirdparty indicates the traffic that is routed to a third-party recommendation system.
The following figure shows the traffic configurations for six users. According to user-defined traffic allocation logic, the Traffic Code field is set to selfhold for User a and User b, which means that the recommendation results for the two users are obtained from your self-managed recommendation system. The Traffic Code field is set to PAI-REC for User c and User d, which means that the recommendation results for the two users are obtained from the PAI-Rec system. The Traffic Code field is set to thirdparty for User e and User f, which means that the recommendation results for the two users are obtained from a third-party recommendation system.
Lab and experiment layer
After the recommendation requests of users are routed to the PAI-Rec system, the PAI-Rec system divides these recommendation requests into buckets. The PAI team of Alibaba Cloud designs labs, experiment layers, experiment groups, and experiments based on common A/B testing schemes in the industry. A lab contains experiment layers, an experiment layer contains experiment groups, and an experiment group contains experiments.
A lab is a collection of traffic. You can create one or more labs, among which a base lab is required. If you create only one lab, this lab must be used as a base lab for fallback. Traffic is preferentially matched with and routed to non-base labs. If no lab is matched, traffic is then routed to the base lab. Therefore, you can create only one lab for fallback.
You can create a fallback lab with relatively simple recall and ranking logic and non-base labs with commonly used complex recall and ranking logic. In this way, when traffic surges, some traffic can be routed to the base lab to ensure the stability of the recommendation system.
The preceding figure shows the configurations of a base lab. The following section describes the parameters:
Lab Name: a custom lab name.
Description: the detailed description of the lab.
Lab Type:
Base Lab: A base lab is required, whereas non-base labs are optional.
Non-base Lab: Traffic is preferentially matched with and routed to non-base labs. If the model of the base lab is simple but the model of non-base labs is complex, you can create two labs. The base lab can also be implemented by using popular and random fallback logic.
Runtime Environment: the runtime environment of the recommendation engine. Valid values: Daily, Staging, and Production.
Bucketing Method:
UID-based Bucketing: Bucketing is performed based on the last digits of UIDs.
Hashed UID-based Bucketing: Bucketing is performed based on the hash values of UIDs.
Condition-based Bucketing: Bucketing is performed based on a key-value expression, such as gender=man.
Buckets: the number of buckets in this lab. The value is 100 in this example.
Traffic Allocation: the numbers of the buckets allocated to this lab, which can be set to 0-99.
Layering: the experiment layer. In most cases, the following layers are configured: recall, filter, coarse_rank, and rank.
Test Users: The traffic of test users can be directly routed to this lab without matching.
Manually Enter: You can enter multiple user IDs and separate them with commas (,).
User Group ID: Select a user group that is created on the User Group Management page.
Experiment group and experiment
You can create multiple experiment groups for each experiment layer, and create multiple experiments for each experiment group. If multiple algorithm engineers need to perform recall or ranking experiments, you can create multiple experiment groups to separate these experiments.
In most cases, an experiment group contains multiple experiments. In the example shown in the following figure, two experiments swing and etrec are configured and the experiment dssm is under testing. The traffic proportion of dssm is set to 0%, and this experiment is in the online state. This configuration helps obtain recommendation effects by using the configured whitelist.
