Re-ranking configuration

The re-ranking (Sort) stage runs after the ranking stage. In this stage, you can reorder items, diversify results, and add rules such as window rules.

How to configure

Re-ranking is configured through SortConfs in the configuration overview. SortConfs is a []object structure that supports multiple re-ranking strategies. PAI-Rec provides the following built-in strategies: BoostScoreSort, BoostScoreByWeight, ItemRankScore, DiversityRuleSort, DPPSort, and MultiRecallMixSort.

Common re-ranking configurations

Each re-ranking configuration uses some of these common parameters. They are described here only and are not repeated in the individual re-ranking sections.

Configuration example:

{
    "SortConfs": [
        {
            "Name": "",
            "SortType": ""
        }
    ]
}

Boost score re-ranking (BoostScoreSort)

After the ranking model runs, each item has a score returned by the model. Business requirements sometimes call for adjusting this score, which is the boost operation.

A boost has two configuration parts:

• Set the condition rules. These rules use item or user attributes, such as category or gender, to determine whether an item matches the condition.

• Set the boost expression. Currently, expressions apply only to score. For example: score * 1.2, score * 0.5, and so on.

Configuration example

{
    "SortConfs": [
        {
            "Name": "BoostScoreSort",
            "SortType": "BoostScoreSort",
            "Debug": false,
            "BoostScoreConditions": [
                {
                    "Conditions": [
                        {
                            "Name": "sex",
                            "Domain": "item",
                            "Type": "string",
                            "Value": "gender",
                            "Operator": "equal"
                        }
                    ],
                    "Expression": "score * 2"
                }
            ]
        }
    ]
}

The preceding configuration doubles the score of each item whose sex feature equals male.

The following table describes FilterParamConfig:

For details about condition settings, see AdjustCountFilter .

Weight-based boost re-ranking (BoostScoreByWeight)

When you boost items, each item may have a different weight. This weight is a field in the item table. Use the weight field to boost the score.

The score is calculated as weight * item.score.

Configuration example

{
    "SortConfs": [
        {
            "Name": "BoostScoreByWeight",
            "SortType": "BoostScoreByWeight",
            "TimeInterval": 172800,
            "BoostScoreByWeightDao": {
                "AdapterType": "hologres",
                "HologresName": "pai_rec",
                "HologresTableName": "test",
                "ItemFieldName": "item_id",
                "WeightFieldName": "weight"
            }
        }
    ]
}

BoostScoreByWeightDao

Item score re-ranking (ItemRankScore)

ItemRankScore sorts items in descending order by item score. This strategy is built into the engine and can be used directly in SortNames.

Diversity re-ranking (DiversityRuleSort)

When recommendation results are returned, they must match user interests and also be diverse. Items from different categories or with different attributes can be mixed in the output.

The rules are configured as follows:

Recommendation diversity and diversification rules

Key terms:

1. Diversification dimension: an item attribute used for diversification, such as category, author, or tag.

2. Diversification policy:

   • Minimum interval k: a diversification dimension can appear at most k times in a row.

   • Maximum occurrences m: within a window of size n, items that share the same diversification dimension cannot appear more than m times.

Diversification logic:

• Diversification rules apply only within the results of a single request. Cross-request diversity is not considered.

• Multiple diversification dimensions are supported.

• Each diversification dimension supports multiple diversification policies, and each policy takes its own parameters (k, m, n).

Configuration example

{
    "SortConfs": [
        {
            "Name": "DiversityRuleSort",
            "SortType": "DiversityRuleSort",
            "DiversitySize": 100,
            "DiversityRules": [
                {
                    "Dimensions": ["spfl"],
                    "WindowSize": 10,
                    "FrequencySize": 1
                }
            ],
            "ExcludeRecalls": [
                "ColdStartVideoVectorRecall",
                "LinUcbRecall_default2"
            ],
            "Conditions": [
                {
                    "Name": "spflPick",
                    "Domain": "user",
                    "Type": "string",
                    "Value": "",
                    "Operator": "equal"
                }
            ]
        }
    ]
}

This re-ranking type must be used together with the ExcludeRecalls parameter.

DiversityRules

The following example shows exclusion rules and the search depth:

Items that match tag=t1 must not appear in output positions 1, 2, 3, and 4. The items in positions 1, 2, 3, and 4 must still meet the diversification rules, but none of them can have tag=t1.

{
    "Name": "DiversityRuleSort",
    "SortType": "DiversityRuleSort",
    "DiversityRules": [
        {
            "Dimensions": [
                "tag"
            ],
            "WindowSize": 5,
            "FrequencySize": 1
        }
    ],
    "ExclusionRules": [
        {
            "Positions": [
                1,2,3,4
            ],
            "Conditions": [
                {
                    "Name": "tag",
                    "Domain": "item",
                    "Type": "string",
                    "Value": "t1",
                    "Operator": "equal"
                }
            ]
        }
    ],
    "ExploreItemSize" : 200
}

When the engine searches for items that meet the diversity rules, an item is returned by default only if it meets all rules. If an item fails any diversity rule, the engine searches for the next item until it finds one that meets all rules. If no item in the candidate set meets all rules, the first item searched is returned.

An alternative policy assigns a weight to each diversity rule. If no item in the candidate set meets all rules, the engine returns the item with the highest total weight of the rules it meets. If multiple items tie, the engine returns the one in the earliest position.

The following configuration includes weights:

{
    "Name": "DiversityRuleSort",
    "SortType": "DiversityRuleSort",
    "DiversityRules": [
        {
            "Dimensions": [
                "tag"
            ],
            "WindowSize": 5,
            "FrequencySize": 1,
            "Weight": 1
        },
        {
            "Dimensions": [
                "category"
            ],
            "WindowSize": 3,
            "FrequencySize": 1,
             "Weight": 3
        }
    ],
    "ExclusionRules": [
        {
            "Positions": [
                1
            ],
            "Conditions": [
                {
                    "Name": "tag",
                    "Domain": "item",
                    "Type": "string",
                    "Value": "t1",
                    "Operator": "equal"
                }
            ]
        }
    ]
}

Multi-value dimension diversification (MultiValueDimensionConf)

By default, each item attribute in Dimensions is treated as a single-value attribute. The engine compares the string values exactly to determine whether two items belong to the same dimension. In some cases, however, an item attribute is multi-value. For example, a product can belong to multiple categories or carry multiple tags, such as tag = "sports,news,tech". Use MultiValueDimensionConf to declare such a dimension as a multi-value dimension. The engine then splits the attribute value by the delimiter before it evaluates the diversification rules.

Diversification logic: for a multi-value dimension, two items are considered "identical" in that dimension if they share any single value, so the diversification rules apply to them. For a regular (single-value) dimension, two items are considered identical only when their values are exactly equal. When a diversification rule specifies multiple Dimensions, two items are treated as being in the same dimension only if they are considered identical in all of the dimensions.

Configuration example

{
  "SortConfs": [
    {
      "Name": "DiversityRuleSort",
      "SortType": "DiversityRuleSort",
      "DiversityRules": [
        {
          "Dimensions": ["tag"],
          "WindowSize": 5,
          "FrequencySize": 1
        }
      ],
      "MultiValueDimensionConf": [
        {
          "DimensionName": "tag",
          "Delimiter": ","
        }
      ]
    }
  ]
}

The preceding configuration declares the tag attribute of an item as a multi-value field separated by commas, such as "sports,news,tech". The engine splits the value by comma before it diversifies. Within a window of size 5, two items are considered duplicates if their tag values share any single tag, and such an item can appear at most once.

Usage notes

• MultiValueDimensionConf supplements the dimensions already defined in DiversityRules. A dimension name configured here takes effect only if it also appears in Dimensions.

• Configure only the multi-value attributes. Dimensions that are not listed here are still matched exactly as single-value attributes.

• Multiple multi-value dimensions are supported.

Diversity re-ranking V2 (DiversityRuleSortV2)

DiversityRuleSortV2 is an enhanced version of DiversityRuleSort (V1). It inherits all diversification capabilities of V1 and adds the cross-page diversification (Cross-Page Diversity) feature, which resolves the issue that diversification rules stop working between adjacent pages in pagination scenarios.

{
  "SortConfs": [
    {
      "Name": "DiversityRuleSortV2",
      "SortType": "DiversityRuleSortV2",
      "DiversitySize": 100,
      "DiversityRules": [
        {
          "Dimensions": ["category"],
          "WindowSize": 10,
          "FrequencySize": 1
        }
      ],
      "ExcludeRecalls": ["ColdStartRecall"],
      "Conditions": [
        {
          "Name": "user_level",
          "Domain": "user",
          "Type": "string",
          "Value": "vip",
          "Operator": "equal"
        }
      ]
    }
  ]
}

{
  "SortConfs": [
    {
      "Name": "DiversityRuleSortV2",
      "SortType": "DiversityRuleSortV2",
      "DiversitySize": 100,
      "DiversityRules": [
        {
          "Dimensions": ["category"],
          "WindowSize": 6,
          "FrequencySize": 1
        },
        {
          "Dimensions": ["author"],
          "IntervalSize": 2
        }
      ],
      "CrossPageDiversity": {
        "Enable": true,
        "LastItemIdsParam": "last_page_item_ids",
        "DiversityDaoConf": {
          "AdapterType": "featurestore",
          "FeatureStoreName": "my_fs",
          "FeatureStoreViewName": "item_feature_view",
          "DistinctFields": ["category", "author"],
          "CacheTimeInMinutes": 60,
          "CacheSize": 100000
        }
      }
    }
  ]
}

Traffic control re-ranking (TrafficControlSort)

Traffic control builds a traffic distribution system that balances platform interests with long-term value. It does so by designing and optimizing algorithms, strategies, and systems.

Benefits of traffic control:

• Effective boosting: traffic control is a traffic intervention feature built on the PAI-Rec recommendation system architecture. It precisely adjusts traffic for the item pools that you select without disrupting the overall recommendation logic.

• Measurable results: unlike traditional weighting, traffic control uses measurable metrics such as the impressions and impression share of an item pool as its control targets, which makes quantitative boosting easier to achieve.

• Easy to manage: traffic control implements business goals as tasks. You can create a separate traffic control task for each type of traffic intervention requirement, which makes management flexible. You can start or end a task at any time.

• Simple to operate: create a task and configure information such as the task goal. The system then adjusts traffic distribution automatically based on your configuration, so continuous observation and monitoring is not required.

For the traffic control algorithm tuning guide, see Tuning guide. For detailed traffic control settings, see Traffic control workflow.

Configuration example:

{
    "Name": "TrafficControlSort",
    "SortType": "TrafficControlSort",
    "PIDConf": {
        "DefaultKp": 5,
        "DefaultKi": 1,
        "DefaultKd": 1
    }
}

Main PID calculation logic:

PIDConf

DPPSort

For more information about the DPP (Determinantal Point Process) diversification algorithm, see An intuitive understanding of the recommendation diversity algorithm based on determinantal point processes.

Prerequisites: The DPP algorithm requires embedding vectors for items. The embedding vectors must represent the content of the items themselves, and the similarity between embeddings must reflect content-level similarity rather than similarity on other levels, such as behavior. For example:

• Recommended: embeddings derived from item images, from text descriptions, or from a combination of static item content such as categories and attributes

• Not recommended: embeddings produced by training a model on user behavior data

The dimension that you want to diversify must be reflected in the embedding. For example, to make the recommendation list diverse in item price, the price feature must be included when the model is trained to generate the embedding vectors. Otherwise, the expected result cannot be achieved.

Configuration example:

{
    "SortConfs": [
        {
            "Name": "DPPSort",
            "SortType": "DPPSort",
            "DPPConf": {
                "Name": "DPPSort",
                "DaoConf": {
                    "AdapterType": "hologres",
                    "HologresName": "geeko_rec"
                },
                "TableName": "item_embedding_metric_learning",
                "TableSuffixParam": "embedding_date",
                "TablePKey": "product_id",
                "EmbeddingColumn": "embedding",
                "Alpha": 4.5,
                "NormalizeEmb": "false",
                "WindowSize": 10
            }
        }
    ]
}

DPPConf

SSDSort

For more information about the SSD diversification algorithm, see Improving the diversity of recommendation results: an analysis of MMR/DPP/SSD principles.

Prerequisites: The SSD algorithm requires embedding vectors for items. The embedding vectors must represent the content of the items themselves, and the similarity between embeddings must reflect content-level similarity rather than similarity on other levels, such as behavior. For example:

Recommended: embeddings derived from item images, from text descriptions, or from a combination of static item content such as categories and attributes

Not recommended: embeddings produced by training a model on user behavior data

The dimension that you want to diversify must be reflected in the embedding. For example, to make the recommendation list diverse in item price, the price feature must be included when the model is trained to generate the embedding vectors. Otherwise, the expected result cannot be achieved.

Configuration example:

{
    "SortConfs": [
        {
            "Name": "SSDSort",
            "SortType": "SSDSort",
            "SSDConf": {
                "Name": "SSDSort",
                "DaoConf": {
                    "AdapterType": "hologres",
                    "HologresName": "geeko_rec"
                },
                "TableName": "item_embedding_metric_learning",
                "TablePKey": "item_id",
                "EmbeddingColumn": "embedding",
                "Gamma": 0.25,
                "UseSSDStar": true,
                "NormalizeEmb": "false",
                "MinScorePercent": 0.1,
                "CandidateCount": 200,
                "WindowSize": 5
            }
        }
    ]
}

SSDConf

Multi-channel recall re-ranking (MultiRecallMixSort)

In most cases, a recommendation system uses multiple recall channels. Based on business operation requirements, you may need to mix the output by recall channel type. For example:

• The cold-start recall channel requires a specific number of exposures

• A specific recall channel requires specific positions

• You can also use an item feature as a condition to control the output position or quantity.

To output a recall channel by proportion, use the following configuration: the number of ColdStartRecall items accounts for 10% of the total.

{
    "SortConfs": [
        {
            "Name": "MixSort",
            "SortType": "MultiRecallMixSort",
            "RemainItem": false,
            "MixSortRules": [
                {
                    "MixStrategy": "random_position",
                    "NumberRate": 0.1,
                    "RecallNames": [
                        "ColdStartRecall"
                    ]
                }
            ]
        }
    ]
}

To output a recall channel at fixed positions, use the following configuration: the items with the highest scores in GlobalHotRecall are selected first to fill the fixed positions, and the remaining items are sorted by score and fill the remaining positions.

{
    "SortConfs": [
        {
            "Name": "MixSort",
            "SortType": "MultiRecallMixSort",
            "RemainItem": false,
            "MixSortRules": [
                {
                    "MixStrategy": "fix_position",
                    "Positions": [1,3,5],
                    "RecallNames": [
                        "GlobalHotRecall"
                    ]
                }
            ]
        }
    ]
}

Use condition filters to select items, and then control the quantity by proportion.

{
    "SortConfs": [
        {
            "Name": "MixSortByItemFeature",
            "SortType": "MultiRecallMixSort",
            "RemainItem": false,
            "MixSortRules": [
                {
                    "MixStrategy": "random_position",
                    "NumberRate": 0.1,
                    "Conditions": [
                        {
                            "Name": "gender",
                            "Domain": "item",
                            "Type": "string",
                            "Value": "man",
                            "Operator": "equal"
                        }
                    ]
                }
            ]
        }
    ]
}

Use condition filters to select items, and then fill the fixed positions.

{
    "SortConfs": [
        {
            "Name": "MixSortByItemFeature",
            "SortType": "MultiRecallMixSort",
            "RemainItem": false,
            "MixSortRules": [
                {
                    "MixStrategy": "fix_position",
                    "Positions": [3,5,7],
                    "Conditions": [
                        {
                            "Name": "gender",
                            "Domain": "item",
                            "Type": "string",
                            "Value": "man",
                            "Operator": "equal"
                        }
                    ]
                }
            ]
        }
    ]
}

Condition routing re-ranking (ConditionSort)

ConditionSort routes requests to different re-ranking strategies based on user attribute conditions. When different user groups require different re-ranking logic, you can configure condition rules to route requests to the corresponding re-ranking strategy. If no condition matches, the default re-ranking strategy is used.

Condition routing rules are evaluated in the configured order. The engine runs the first re-ranking strategy whose condition is met and skips the remaining conditions.

Configuration example:

{
  "SortConfs": [
    {
      "Name": "ConditionSort",
      "SortType": "ConditionSort",
      "ConditionSortConfs": {
        "SortConfs": [
          {
            "Conditions": [
              {
                "Name": "user_level",
                "Domain": "user",
                "Type": "string",
                "Value": "vip",
                "Operator": "equal"
              }
            ],
            "SortName": "VipDiversitySort"
          },
          {
            "Conditions": [
              {
                "Name": "is_new_user",
                "Domain": "user",
                "Type": "int",
                "Value": 1,
                "Operator": "equal"
              }
            ],
            "SortName": "NewUserBoostSort"
          }
        ],
        "DefaultSortName": "DefaultDiversitySort"
      }
    }
  ]
}

The preceding configuration works as follows: when the user attribute user_level equals vip, the VipDiversitySort re-ranking strategy is used; when the user attribute is_new_user equals 1, the NewUserBoostSort re-ranking strategy is used; if none of the preceding conditions match, DefaultDiversitySort is used as the default re-ranking strategy.

FilterParamConfig is configured as follows:

How to use

The re-ranking configuration is similar to the recall configuration. After the configuration is complete, provide a SortNames parameter that is used by scenario. SortNames is a Map[string]object structure in which each key is a scenario and each scenario corresponds to a group of re-ranking strategies.

{
    "SortNames": {
        "${scene_name}": [
            "ItemRankScore"
        ]
    }
}

• ${scene_name} is the scenario name. If multiple scenarios use the same configuration, set this parameter to "default".

• ItemRankScore: the custom name of the re-ranking strategy that is defined in SortConfs.