PaperlayerView exact revision on arXiv

Source-linked AI summary

TGR-EvoDAG: A DAG-based Multi-Agent Code Evolution Framework for Generative Recommendation on Tencent

Junlin He, Junzhang Zhu, Yudong Li, Yihong Tang, Xuefeng Jiang, Wei Ma, Chengxiang Zhuo, Zang Li

arXiv:2610.32326v1cs.AI

TL;DR

Generative Recommendation’s cascaded pipeline poses asymmetric retraining costs and delayed cross-stage gains that current evolution approaches do not handle well. TGR-EvoDAG combines DAG-based search and diagnostic feedback with stage-aware cost planning and downstream co-adaptation. It reports gains on public benchmarks and in Tencent industrial deployment.

  • Problem

    Existing evolution methods lack the combination of domain-specific feedback and cross-stage search needed for GR’s coupled pipeline, where stage costs differ and upstream gains may be delayed.

    Source: §1 · pp. 2–3

  • Method

    TGR-EvoDAG combines Code DAG search and GR diagnostic feedback with stage-aware GPU-hour planning and active downstream co-adaptation.

    Source: §1 · pp. 2–3

  • Results

    TGR-EvoDAG improves offline metrics by up to 37.4% and simulated user satisfaction by 19.7% over the strongest GR baseline, with +12.16% offline Hit@1 and a significant 0.40% online CTR increase in Tencent deployment.

    Source: §1 · p. 3

  • Takeaways & Limitations

    The reported results show autonomous evolution of a complete GR pipeline and gains in Tencent’s commercial media deployment.

    Source: §1 · p. 3

Abstract

from arXiv · show

Large Language Model (LLM) agents have enabled automated code evolution for algorithm discovery. However, current recursive self-improvement (RSI) research for sequential recommendation faces a dilemma: general-purpose frameworks lack domain-specific feedback, while recommender-specific frameworks rely on linear evolution. Crucially, naively integrating them fails when applied to Generative Recommendation (GR). Unlike end-to-end models, GR relies on a module-cascaded pipeline (tokenization, pre-training, and alignment). In this paradigm, existing evolution methods suffer from: i) cost blindness, squandering budgets by ignoring stage-asymmetric retraining overheads; and ii) short-sighted evaluation, discarding promising upstream innovations that temporarily regress metrics before downstream adaptation. To bridge these gaps, we propose TGR-EvoDAG, a multi-agent code evolution framework tailored for GR. TGR-EvoDAG models code evolution as a Directed Acyclic Graph (DAG) to maintain multiple evolution branches and merge complementary innovations, unifying advanced search with rich GR diagnostic feedback. We further introduce stage-aware cost planning to optimize GPU-hour budgets, and active downstream co-adaptation to navigate temporary regressions and unlock cross-stage gains. On public Amazon datasets, TGR-EvoDAG enables the first autonomous evolution of a complete GR pipeline, improving offline metrics by up to 37.4% and Agent4Rec simulated user satisfaction by 19.7% over the strongest baseline. Furthermore, in industrial deployment on Tencent's large-scale commercial media platform, the evolved GR achieves a 12.16% relative improvement in offline Hit@1 and a statistically significant 0.40% increase in online click-through rate (CTR).

1 INTRODUCTION

Generative Recommendation’s cascaded stages create asymmetric retraining costs and delayed gains that existing evolution frameworks handle poorly. TGR-EvoDAG combines DAG search and recommendation-specific feedback with cost planning and downstream co-adaptation; experiments report improvements offline, in simulation, and in deployment.

1 INTRODUCTION

  • GR’s cascaded pipeline creates asymmetric retraining costs and deferred cross-stage gains, so existing frameworks can waste budgets and discard upstream edits after temporary regressions.Tokenizer edits require full-pipeline retraining, whereas Alignment edits rerun only the final segment.Source: §1 · p. 2
  • TGR-EvoDAG represents evolution as a Code DAG and combines advanced search with fine-grained recommendation diagnostics in a collaborative agent workflow.The workflow includes an Operator Selector, Architect-Critic, Coder-Reviewer, Distiller, and Pruner.Source: §1 · pp. 2–3
  • Stage-aware cost planning weighs expected performance gains against actual GPU-hour costs, while active downstream co-adaptation retains regressed upstream branches for adaptation.The framework schedules a downstream child edit when an upstream change lacks a corresponding adaptation.Source: §1 · p. 3
  • The evaluation platform standardizes GR evolution with stage-aware feedback and GPU-hour accounting, using an identical seed codebase for compared frameworks.The paper also reports integration into Tencent’s internal Uppimo platform as an implementation backbone, with public trial planned for the future.Source: §1 · p. 3
  • TGR-EvoDAG improves offline metrics by up to 37.4% and Agent4Rec simulated user satisfaction by 19.7% over the strongest GR baseline; industrial results include +12.16% offline Hit@1 and a significant 0.40% online CTR increase.The online increase was measured in a 14-day A/B test.Source: §1 · p. 3

2 RELATED WORK

Prior code-evolution and recommender-evolution work offer complementary capabilities, but the cited frameworks lack mechanisms for evolving GR’s coupled, cascaded pipeline end to end. The paper positions TGR-EvoDAG as addressing that gap through branch-preserving search and cross-stage adaptation.

LLM-driven Code Evolution

  • General-purpose evolution offers linear inheritance, multi-elite sampling, and explicit tree search, but lacks GR-specific feedback and stage-aware or cross-stage mechanisms.Examples include AIDE and MLE-STAR, population approaches, SELA, Arbor, and CORAL.Source: §2 · p. 3

Generative Recommendation (GR)

  • GR maps items to semantic IDs and uses Tokenizer, Pre-training, and Post-training Alignment stages; upstream edits can temporarily lower metrics before downstream re-adaptation.The cited passage says no prior work autonomously evolves this complete pipeline.Source: §2 · pp. 3–4

Self-Evolving Recommender Systems

  • Recommender-evolution frameworks add domain-specific feedback but use simple search that maintains and merges no parallel branches, limiting their fit to cascaded GR.SERS uses fan-out/fan-in, EvoRec keeps the best variant each round, and Self-EvolveRec samples one parent from elites.Source: §2 · p. 4
  • Auto-RecSys focuses on engineering orchestration for long-running experiments, while its search advances ideas linearly without explicit GPU-hour budgeting, stage-aware planning, or cross-branch merging.The passage describes this focus as complementary to TGR-EvoDAG.Source: §2 · p. 4

3 PRELIMINARIES

Generative Recommendation reformulates next-item prediction as conditional generation of semantic-ID tokens from a user’s interaction history. Training comprises three tightly coupled stages.

3 PRELIMINARIES

  • Generative Recommendation predicts the next item by autoregressively generating its semantic-ID tokens conditioned on the user’s chronological interaction history.The paper identifies the user and item sets as U and I.Source: §3 · p. 4
  • Tokenization discretizes item content into hierarchical semantic IDs, using a tokenizer such as RQ-VAE.Source: §3 · p. 4
  • Generative pre-training trains a sequence-to-sequence Transformer to predict next-item tokens using hierarchical cross-entropy.Source: §3 · p. 4
  • Post-training Alignment uses preference optimization or reinforcement learning to align the model with recommendation objectives such as exact match or prefix similarity.Source: §3 · p. 4

4 TGR-EVODAG

TGR-EvoDAG searches a Code DAG that preserves branches and supports revisiting stages and merging complementary improvements. Its operators and multi-agent pipeline combine structured hypothesis development, implementation, evaluation, cost planning, and adaptive search control.

4 TGR-EVODAG

  • The Code DAG preserves promising branches, permits revisiting earlier pipeline stages, and supports semantic merging of complementary improvements.Each node records provenance, code artifacts, empirical feedback, lessons, and experimental cost.Source: §4 · p. 4

4.1 SEARCH OPERATORS

  • Exploration investigates a distinct hypothesis from one parent, while mutation locally refines one parent’s hypothesis.Source: §4.1 · p. 5
  • Merge combines multiple independent branches by resolving semantic code conflicts and interface dependencies into a unified codebase.Parents are represented by diffs against their lowest common ancestor, paired with hypotheses and distilled lessons.Source: §4.1 · p. 5

4.2 MULTI-AGENT PIPELINE

  • Seven specialized agents execute a five-stage expansion workflow and communicate through structured intermediate records.The agents are an Operator Selector, Architect-Critic pair, Coder-Reviewer pair, Distiller, and Pruner.Source: §4.2 · p. 6
  • The Operator Selector estimates GPU-hour cost from stage-specific historical records and weighs it against anticipated gains when planning edits.It can defer expensive upstream edits until cheaper downstream architectures mature.Source: §4.2 · p. 6
  • The Pruner can tag a regressed upstream branch for downstream adaptation, directing later edits to freeze upstream parameters and mutate downstream architecture.It also prunes paths with irrecoverable collapses.Source: §4.2 · p. 6

5 EXPERIMENTS

Experiments compare TGR-EvoDAG with evolutionary baselines, trace its 39-round search, and test restricted search variants and industrial transfer. Results include offline, simulated-user, and online improvements.

Main Results

  • TGR-EvoDAG beats APAO by +24.7%/+28.5% on Hit@10/@20 and +37.4%/+37.2% on NDCG@10/@20; Agent4Rec Satisfaction improves +19.7% over APAO.It also outperforms the strongest recommender-specific baseline Self-EvolveRec by +21.0% Hit@10 / +32.8% NDCG@10.Source: §5 · p. 7, Table 1 · p. 8

Analysis of Evolution Trajectory

  • Across 39 rounds, the search moves from Hit@10 0.0626 to 0.0869, merging mature branches and recovering from tokenizer regressions through downstream co-adaptation.Figure 3 traces the running best score; the x axis is scaled per phase.Source: §5 · pp. 7–8, Figure 3 · p. 8

Ablation of Search Mechanisms

  • Performance rises monotonically from greedy, multi-elite, and no-cost-planning variants to full TGR-EvoDAG on testset and Agent4Rec metrics.Greedy pruning loses delayed payoffs, multi-elite search lacks cross-branch merging, and uniform budgeting cannot afford upstream tokenizer retraining.Source: §5 · p. 9, Figure 4 · p. 9

Real-World Industrial Deployment

  • +12.16% Hit@1 over APAO is reported for the evolved model in industrial offline evaluation; it also improves Hit@5 by +4.83% and Hit@50 by +0.25%.The champion and APAO were trained from scratch on 10 days of industrial logs.Source: §5 · p. 9, Figure 4 · p. 9

Online A/B Testing

  • +0.40% overall system CTR (p = 0.019) is reported in a 14-day A/B test on 5% of live traffic.The test served more than 1 million users and used CUPED variance reduction and tiered Benjamini-Hochberg correction.Source: §5 · p. 9

Validation of Diagnostic Signals

  • User diagnosis, mathematical probes, and distribution probes guided targeted mutations, including a tokenizer repair that reduced semantic ID collisions from 65.7% to 1.0%.Offline metrics alone did not identify actionable directions in the three described turning points.Source: §5 · p. 9

6 CONCLUSION

The conclusion presents TGR-EvoDAG as a GR evolution framework and reports public-benchmark and Tencent deployment gains. The AI use statement describes limited writing and literature assistance, with author review.

6 CONCLUSION

  • TGR-EvoDAG combines Code DAG search and diagnostic feedback with stage-aware cost planning and active downstream co-adaptation for cascaded GR pipelines.The conclusion reports up to 37.4% offline improvement and 19.7% simulated satisfaction improvement over APAO, plus 12.16% offline Hit@1 and a statistically significant 0.40% online CTR gain in Tencent deployment.Source: §6 · p. 10

AI USE STATEMENT

  • The authors used LLMs to summarize prior baseline work and polish manuscript writing, and report that they manually verified the assisted text and take responsibility for the final content.They state that research ideas, framework algorithms, experimental design, code, and experiments were conceived and implemented by the authors.Source: AI USE STATEMENT · p. 11

A.1 WORKFLOW

The workflow expands the Code DAG through five agent stages, records measured GPU-hour costs, and keeps valid regressions available for downstream adaptation.

A.1 WORKFLOW

  • The Operator Selector chooses an operator and parent set; the Architect, Coder and Reviewer, Distiller, and Pruner produce hypotheses, code and deltas, lessons, and branch status.The Distiller inspects the code delta so its lesson attributes outcomes to a mechanism rather than merely restating the hypothesis.Source: §A.1 · p. 16
  • Rounds consume measured GPU-hours, not estimated costs; failed or interrupted candidates incur the GPU-hours spent before failure, while token use is logged separately.Estimated stage costs inform selection, while actual cost updates the budget and node record.Source: §A.1 · p. 16
  • Valid checkpoints remain selectable even after regressions; upstream metric drops trigger downstream adaptation, while irrecoverable collapses prune the subtree.Adaptation freezes upstream parameters and directs the next child to modify a downstream stage.Source: §A.1 · p. 16
  • Each round selects an operator and parents, develops a hypothesis, implements and reviews code, evaluates it and distills a lesson, then controls the search and co-adaptation.The algorithm updates the graph and remaining budget after pruning or marking a node for downstream adaptation.Source: §A.1 · p. 17

A.2 DATASETS

The experiments use a preprocessed Amazon Office Products dataset and a Tencent industrial dataset, with distinct evaluation setups for public evolution and real-world validation.

A.2 DATASETS

  • Amazon Office experiments use released data with five-core filtering, histories truncated to 20 items, and chronological leave-one-out train, validation, and test splits.All frameworks share the validation split, and the test split is used only once for the final budget-selected checkpoint.Source: §A.2 · p. 18
  • Office Products was chosen because each train/validate cycle takes under one GPU-hour, allowing meaningful evolution rounds within the shared 24 GPU-hour budget.The authors deliberately choose a compact corpus rather than a larger benchmark for this budgeted comparison.Source: §A.2 · p. 18
  • The industrial dataset comes from Tencent’s commercial media platform; offline models share 10 consecutive training-log days and are evaluated on the following day.The data include over 10 million interactions on more than 300 thousand items; the online evolved model is added as a retrieval channel.Source: §A.2 · p. 18

A.3 GR CODEBASE

The shared seed codebase exposes four modules for evolution, from item tokenization through post-training, while retaining common data and evaluation components.

A.3 GR CODEBASE

  • The seed codebase separates item tokenization, backbone, pre-training objective, and pluggable post-training objective, with a shared data loader and beam-search evaluator.All frameworks share the data, splits, evaluation protocol, and budget, while code above the data layer—including tokenization—can change.Source: §A.3 · p. 18
  • The seed tokenizer uses LLAMA-3.1-8B-INSTRUCT item embeddings and a four-level RQ-K-means quantizer, with a de-duplication suffix ensuring an injective item-to-code mapping.Histories flatten into four tokens per item, and a candidate may redesign the tokenizer, requiring downstream backbone retraining.Source: §A.3 · p. 19
  • The seed backbone is a T5-style TIGER encoder-decoder that generates four semantic codes and uses constrained beam search over the valid code trie.Its encoder and decoder each have four layers; Table 3 lists the shared architecture and optimization configuration.Source: §A.3 · p. 19, Table 3 · p. 19
  • TIGER pre-training uses token-level cross-entropy under teacher forcing, and every post-training variant starts from its converged checkpoint.This setup attributes differences among post-training variants to their objectives.Source: §A.3 · p. 20
  • The seed includes SDPO, SPRec, ReReGRPO, and APAO as preference- or reinforcement-based post-training objectives that evolution may recombine or extend.APAO’s prefix weights adapt by exponentiated-gradient updates, emphasizing prefixes most likely to fall out of the beam.Source: §A.3 · p. 20

A.4 EVOLUTION BASELINES

The comparison includes general and recommender-specific evolutionary frameworks, run under a shared codebase, agent, and GPU-hour budget to isolate search-strategy differences.

A.4 EVOLUTION BASELINES

  • All six baselines use the same seed codebase, Claude CLI agent, and 24 GPU-hour budget, so reported differences reflect search strategy rather than environment.Source: §A.4 · p. 20
  • AlphaEvolve evolves whole codebases using evaluator feedback and scalar metrics, while DeepEvolve retrieves external scientific knowledge to inform hypotheses and code refinement.Source: §A.4 · p. 21
  • CORAL uses long-running agents, shared persistent memory, and asynchronous collaboration; Arbor organizes hypotheses, artifacts, evidence, and lessons in a persistent tree.Source: §A.4 · p. 21
  • EvoRec co-evolves the recommendation model and optimization methodology through a dual-track loop, while relying primarily on offline metrics.Source: §A.4 · p. 21
  • Self-EvolveRec combines simulated-user critiques with structural diagnosis and maintains compatibility between its diagnosis tool and evolving model.Source: §A.4 · p. 21

A.5 MULTI-DIMENSION DIAGNOSTICS

A.5 combines offline metrics, deterministic mathematical probes, and simulated-user diagnoses into structured feedback, with diagnostic outputs tailored to the pipeline stages a candidate changes. A.6 defines offline ranking and simulated-user measures and keeps final behavioral evaluation separate from evolution-time feedback.

A.5 MULTI-DIMENSION DIAGNOSTICS

  • The feedback bundle combines offline validation metrics, deterministic mathematical probes, and qualitative user diagnosis, with diagnostic fields emitted stage-aware for SFT and post-training edits.Single-stage candidates receive only SFT fields; diagnostics for post-training are produced only when a candidate modifies that stage.Source: §A.5 · p. 21
  • Mathematical probes measure structural and decoding properties, while an LLM Diagnosis Analyst converts their numeric values into auditable structured diagnoses.The analyst is instructed to ground statements in named metrics and values and populate headline_metrics with 3–6 supporting values.Source: §A.5 · p. 22
  • Candidate probe scripts can add metrics under an agent.* namespace, but cannot overwrite the fixed baseline probe set.The environment reports submitted probe execution status in stage-specific fields.Source: §A.5 · p. 22
  • The qualitative simulator assesses individual recommended items and the top-K list, then a Lead Analyst aggregates per-user reports into a system-level critique.Simulated users have fixed activity, conformity, and diversity traits and assess recommendations conditioned on their interaction histories.Source: §A.5 · p. 23

A.6 METRICS

  • Offline Hit@K measures whether the ground-truth next item appears in the top-K list, while NDCG@K additionally rewards placing it nearer the top.The reported cutoffs are K ∈ {10, 20}; validation metrics are available during evolution and include final-model and per-stage values.Source: §A.5 · p. 21, §A.6 · p. 24
  • Agent4Rec complements next-item metrics with behavior-level measures of exposed-list like precision, satisfied-interest volume, and browsing depth.Agents view up to five pages of four items, rate items on a 1–5 scale, and ratings above 3 count as likes; all three measures are higher-is-better.Source: §A.6 · p. 24
  • Final Agent4Rec evaluation is held out from evolution-time diagnosis, using disjoint user populations and outputs consumed by different parties.Evaluation agents, seeds, and interaction templates are fixed and shared across frameworks, making the reported comparison deterministic and paired.Source: §A.6 · pp. 24–25

Related papers

Loading 2610.32326v1…