Recommender System Re-ranking: List-Level Optimization Under Multiple Constraints

1. Re-ranking in the Recommendation Pipeline

Re-ranking operates at the list level, unlike pointwise ranking which scores items independently. It takes the top 200–300 candidates from fine ranking, along with user/context features and constraint configurations, and outputs a final ordered list plus feature logs for offline training. In engineering, it runs as one or more Processors in the realtime engine after fine ranking; compute-intensive listwise models can be extracted to a separate service without changing upstream/downstream contracts.

2. Overall Architecture

2.1 Inputs and Outputs

Inputs: candidate list (with attributes, final scores, multi-objective predictions), user/profile/context features, constraint rules from config center and ops platform.

Outputs: final list (e.g., 200 items cached for refresh/pagination) and feature logs (filter reasons, position changes, quota fulfillment, penalty scores, ops intervention tags) merged into the data warehouse.

2.2 Re-ranking Pipeline

The pipeline executes strategies in this order:

Filtering & Deduplication – general filters, cluster dedup, position-aware pre-checks; shrinks candidate set early.

Blending & Quota Control – content-type blending (e.g., video insertion), quality-tier quotas; placed before diversity.

Diversity Re-ranking – MMR-style greedy with cumulative penalty and distance decay.

Operator Intervention – pinning, forced insertion; placed before final validation so earlier soft strategies don't override ops positions.

Validation & Remediation – full hard-constraint verification; local repairs if constraints broken (e.g., diversity moving vulgar content to first screen).

2.3 Logic Organization (Single Processor)

All strategies implement a common interface and run sequentially inside one RerankProcessor. The mutable candidate list is passed through each strategy. RerankContext holds candidates, user profile, config, cross-strategy state, and feature logs. Strategies are built from config per request. Exceptions are isolated: soft-optimization failures can be skipped; hard-constraint failures still proceed to final validation which may trigger degradation.

public class RerankContext { private List candidates; private UserProfile userProfile; private RerankConfig config; private RerankState state; private List featureLog; } public interface RerankStrategy { String getName(); boolean isEnabled(RerankContext ctx); void apply(RerankContext ctx); } public class RerankProcessor extends Processor { @Override public Response process(ExecutionContext ec) { Response response = callNextProcessor(ec); List strategies = ec.getRerankStrategies(); RerankContext ctx = buildRerankContext(ec, response.getResult()); for (RerankStrategy s : strategies) { if (!s.isEnabled(ctx)) continue; try { s.apply(ctx); } catch (Exception e) { log.error("rerank strategy [{}] failed", s.getName(), e); ctx.getFeatureLog().add(RerankLog.error(s.getName(), e.getMessage())); } } new ConstraintValidator(ctx).validateAndRepair(); ec.addFeatureLog("rerank", ctx.getFeatureLog()); response.setResult(ctx.getCandidates()); return response; } }

2.4 Hard Constraints vs. Soft Optimizations

Hard Constraints – binary pass/fail, must be satisfied: safety/compliance (blacklist, takedown), pinning, position rules (no vulgar in first screen), quota floors (video ≥10%). Deterministic, rule-based, highest priority.

Soft Optimizations – continuous metrics, tunable via parameters (e.g., penalty λ): diversity dispersion, format distribution, personalized matching. Heuristic/greedy, approximate optimum.

Pipeline design: hard constraints early (filter, quota), soft in middle (diversity), ops intervention after soft but before final validation, final validation guards safety/compliance.

2.5 Configuration, A/B Testing, Feature Logs

All switches and parameters (penalties, quotas, thresholds) managed in config center with hot reload, per-scene/experiment values.

Every change (new strategy, param tweak, pipeline reorder) validated via A/B test on business and ecosystem metrics.

Feature logs capture every adjustment (filter reason, original/final position, quota status, diversity penalty, ops tags) for offline analysis and future listwise model training.

3. Filtering and Deduplication

3.1 General Filtering

Content-side: content blacklist (ops-specified takedown), title sensitive-word filter (politics/porn/violence), clickbait pattern filter, title length filter, link/domain blacklist, staleness filter (e.g., news ≤48h).

User-side: read-history filter (recently viewed/recommended), negative-feedback filter (explicit dislike/block), exposure-decay (lower weight for 7-day unclicked exposures – soft adjustment).

Implementation: single linear scan; if post-filter candidates fall below threshold, alert and trigger fallback. Note: these filters also run in earlier stages (recall, etc.); re-ranking serves as final compliance gate.

3.2 Cluster Deduplication

At ingestion, hierarchical clustering on text similarity or entity-keyword grouping assigns a

cluster_id</sub>. In re-ranking, only top 1–2 highest-scored items per cluster retained (configurable: major events keep 2, ordinary 1; can also retain different formats). Differs from general filtering: items are individually qualified but redundant at list level.</p><h3>3.3 Position-Aware Constraints</h3><p>Rules vary by position (first screen stricter). Example: vulgarity tiers (0=normal, 1=mild, 2=moderate, 3=severe – tier 3 blocked at ingestion). First 10 positions: only tier 0 allowed; positions 11–M (e.g., 30): limited tier 1 with proportion cap; after M: tiers 1–2 allowed within configured caps. Because removals cause subsequent items to shift forward, the filter iterates until list stabilizes. Since later blending/diversity reshuffle positions again, final validation must re-check position constraints. Same pattern applies to other position-sensitive rules (e.g., first-screen video floor, quality-tier floor).</p><h2>4. Content Blending and Quota Control</h2><h3>4.1 Why Blending?</h3><p>Fine ranking scores often favor dominant formats (e.g., text over video), causing format imbalance and reduced consumption diversity. Blending enforces reasonable format distribution while preserving personalization.</p><h3>4.2 Video Blending</h3><p>Typical setup: video floor ≥10% (hard). Additional soft/hard rules: minimum gap of N text items between videos (e.g., 3), first-screen bounds (e.g., 1–2 videos in top 5–6). Algorithm: scan positions sequentially; at each slot check current video ratio, gap, first-screen constraints; if insertion needed, pull highest-scored video from later in list. Quota-driven approach adapts dynamically to candidate composition. If constraints conflict or candidates insufficient, repair by priority or degrade – never admit non-compliant content to meet quota.</p><h3>4.3 Multi-Format Unified Blending</h3><p>For multiple formats (text, video, gallery, Q&A, live), abstract framework: <strong>type ID</strong> per item; <strong>quota management</strong> per type per scene; <strong>unified insertion</strong> – at each position compute each type's quota gap, insert highest-scored item from type with largest gap, respecting per-type gap and position constraints (e.g., live only in specific slots).</p><h3>4.4 Content Quality Quotas</h3><p>Items graded at ingestion into Tier 1 (premium), Tier 2 (normal), Tier 3 (low-quality/clickbait). Fine ranking may over-promote Tier 3 due to inflated CTR, causing "bad money drives out good." Policy: top N (e.g., 10) Tier 1 ≥ X% (e.g., 50%) – hard; subsequent groups of M items: Tier 1+2 ≥ Y% (e.g., 80%), Tier 3 ≤ Z% (e.g., 20%). Stricter on home feed, relaxed on secondary feeds.</p><h2>5. Diversity Re-ranking</h2><h3>5.1 Necessity</h3><p>Fine ranking's user-profile input tends to produce homogeneous blocks (same category/author), narrowing interests (filter bubbles) and causing fatigue, hurting long-term retention. Diversity re-ranking trades off some relevance for richness; strength controlled by parameters, tuned via A/B test.</p><h3>5.2 Cumulative Penalty MMR Variant</h3><p>Classic MMR: <code>S(i) = rel(i) - λ * max_{s∈S} sim(i,s)

. This variant uses cumulative penalty with distance decay:

P(i) = Σ_{s∈S} sim(i,s) * γ^{d(i,s)} S(i) = rel(i) - λ * P(i)

Symbols: i =candidate, S =selected set, sim =similarity, d =position distance, γ ∈(0,1) decay (e.g., 0.9), λ =penalty coefficient, rel(i) =fine-rank final_score. Greedy selection: start with empty selected set; for each output position, compute S(i) for candidates, pick highest, move to selected, repeat until target length (e.g., 100) or candidates exhausted.

Key parameters: λ (diversity-relevance trade-off, tuned per system via A/B test), γ (decay, limits influence of distant selected items), candidate window K (only top-K by fine-rank score considered each round, e.g., 50; reduces compute and prevents large deviation; if no hard-constraint-satisfying candidate in window, expand search or fall back to repair).

5.3 Four-Dimensional Similarity

Similarity fused from:

Category – L1/L2 taxonomy; same L1 base penalty, extra if L2 also matches; hierarchical weights configurable.

Publisher – same publisher high similarity (1.0); authoritative/head publishers penalized less (quality content tolerates adjacency).

Keyword – Jaccard or TF-IDF cosine on keyword sets.

Custom – extensible dimensions: source type (original/repost/UGC), tone (serious/entertainment/educational), geo tags, etc.

Fusion: weighted sum sim(i,s) = Σ w_k * sim_k(i,s) fed into cumulative penalty. Weights configurable per product (news: category heavy; social: publisher heavy).

5.4 Dynamic Parameters

λ, dimension weights, K adjusted per context: new users (noisy profile) → increase λ; veteran users → decrease λ. Broad-interest users (many tags) → lower λ; narrow-interest → raise λ. Scene differences: home feed higher λ; search results lower λ; related-reading lower or off based on homogeneity and experiment results.

6. Operator Intervention & Strategy Conflicts

6.1 Pinning

Ops configures in CMS with scope (global/segment/scene). At re-ranking, pinned items placed at positions 1,2,3… (max ~3 to limit personalization damage). Duplicates in candidate list removed. Pinned items still pass safety/compliance checks; exempt from diversity/soft adjustments; conflicts with business hard constraints resolved in favor of pinning (with alert log). Pinned items need not be in fine-rank candidates; fetched directly from content store.

6.2 Forced Insertion

For campaigns, onboarding, specials. Configured in CMS with ratio, position range, time window. Differs from pinning: multiple items, flexible positions. Strategies: proportional (e.g., 10%), fixed slots (4,9,14), random in range. Previously used proportional + minimum gap. Inserted items shift organic items down; if list length capped, tail truncated and position/quota constraints re-validated. Safety/compliance and dedup still apply.

6.3 Strategy Priority

Safety/compliance (blacklist filter)

Operator intervention (pin, forced insert)

Business hard constraints (position, quota)

Soft optimizations (diversity, distribution, personalization)

Higher priority results immutable by lower. Pipeline execution order ≠ priority order; later strategies cannot override higher-priority constraints. Position constraints containing safety rules inherit top priority.

6.4 Validation & Repair

Final ConstraintValidator runs full hard-constraint checks: filter residues, first-screen vulgarity, quota fulfillment, ops pin/insert compliance, duplicate detection. On violation, local repair (swap with later compliant item, verify both positions; if none, remove and backfill; move pinned items back, re-check affected quotas). Repair iterations capped to avoid thrashing. Unresolvable hard conflicts resolved by priority or degradation; safety violations block output. All repairs, relaxations, degradations logged and alerted. Validator uses same request config as upstream strategies to avoid rule drift. Can be implemented as final RerankStrategy but must execute last and not be swallowed by generic exception handling. A/B tests may vary business constraints; safety floor never disabled by experiment.

7. Engineering & Evolution

7.1 Strategy Configuration

Strategies toggled via config; per-scene/experiment strategy sets. Safety checks non-toggleable via normal experiment switches. Parameters (penalties, quotas, thresholds) in config center with experiment/user-tier overrides, hot-reload. Config changes follow canary rollout with versioning and rollback.

7.2 Monitoring & Observability

Strategy-level: filter counts/rates (alert on spikes), video insert volume/ratio, quality-tier distribution, diversity position-shift magnitude/effective λ, ops trigger/exposure volumes, validation/repair outcomes.

Result-level: final list category/author/format distributions vs. historical baselines; alert on distribution shifts.

Performance: total latency (avg/P99), per-stage latency, candidate-shortage alerts, error rates.

Business: A/B test metrics (CTR, dwell, negative feedback, retention) and ecosystem metrics (premium exposure, vulgar ratio, consumption diversity).

7.3 Performance & Degradation

Complexity: filter O(N), quota O(N×T), diversity naive O(L²×K×D) (N=candidates~300, T=quota types, L=output length, K=window, D=similarity dims). Optimizations: precompute similarity matrix O(N²×D) time/space; incremental penalty maintenance; process only first M (e.g., 100) positions, append rest unchanged. Target: millisecond-level; budget set by end-to-end SLA, candidate size, impl, load test. If over budget, simplify strategies.

Degradation: soft-optimization failures → skip + alert. Hard-constraint failures → independent validation; if unconfirmed/unrepairable → strict degradation (return safety-verified fallback or short/empty list). Business hard constraints → priority-based handling + alert. Full re-ranking unavailable → fine-rank results must still pass minimal safety filter + hard constraints before return; if minimal path also down → strict degradation (no raw passthrough). Severe candidate shortage → alert + supplement from hot cache or user cache.

7.4 From Rules to Model-Based Re-ranking

Listwise ranking models: DL model scores entire candidate list jointly; captures inter-item complementarity, sequence effects. Challenges: high inference cost, difficult training data construction, lower interpretability.

RL-based re-ranking: Frame as sequential decision; action=position pick, reward=long-term user feedback (dwell, interaction, retention). Challenges: expensive online exploration, unstable training.

Hybrid rule-model: Model handles soft optimizations; rules enforce hard constraints (filter, pin, quota) and final validation. Model optimizes, rules guarantee controllability.

8. Summary

Re-ranking is a constraint-driven list-level optimization: fine ranking supplies scored candidates; re-ranking applies prioritized hard constraints, safeguards compliance, then optimizes soft objectives to produce a final list satisfying business rules and user experience. Core paradigm shift: pointwise → listwise. Core taxonomy: hard constraints vs. soft optimizations. Four canonical strategy families: filtering, quota/blending, diversity, operator intervention. In one sentence: re-ranking constructs the final display list from fine-rank's quality candidates under multiple hard constraints via soft optimizations, balancing business rules and user experience.