生成式推荐进入架构与对齐深水区：今日多篇论文聚焦生成式推荐系统的核心工程挑战。LinkedIn和阿里巴巴分别从排序和召回角度，重构注意力机制与索引架构以提升效率与效果；Netflix则提出更鲁棒的后训练对齐方法，旨在解决RLHF在推荐场景中的不适用性。这表明业界正从范式探索转向解决落地中的具体瓶颈。; 智能体与因果推理提升系统可解释性与公平性：研究趋势显示出超越传统“用户-物品”二元交互的框架探索。中科大的三方智能体框架首次引入物品智能体，旨在平衡多方利益；LinkedIn的工作则强调显式建模“

📭 今日无更新：今日未收录新的精选论文，暂无趋势分析。

LLM驱动的智能检索与推理：今日多篇论文聚焦于利用大语言模型（LLM）和智能体（Agent）技术，革新推荐系统的信息检索与决策过程。核心趋势是从静态的相似度匹配，转向动态、可解释、具备自主信息获取能力的“思考式”检索与推理，例如通过工具调用弥补信息鸿沟，或借鉴认知科学理论优化记忆召回。; 图神经网络（GNN）的增强与优化：工业界持续探索如何提升GNN在推荐场景下的鲁棒性与表达能力。今日亮点在于通过引入“原型”等全局上下文信息，来缓解GNN对局部噪声敏感和缺乏全局视野的问题，为图模型在复杂工业图（

工业推荐排序全面转向 Scaling 工程化。阿里 SORT 订单+6.35%，快手 FlashEvaluator 和 SOLAR 分别优化评估器与注意力效率，字节 HAP 实现粗排计算预算自适应分配。生成式推荐进入目标对齐阶段，多模态去冗余与因果去偏粒度持续细化。36 篇论文深度解读。

多模态融合走向实用化：工业界开始系统性地将视觉信息深度整合到推荐核心链路（如召回），超越传统的文本主导模式，通过领域微调、多阶段对齐等具体技术提升融合效果，以应对电商等富媒体场景的需求。; 系统工程的科学化与可预测性：学术界开始将“缩放定律”等系统性分析方法引入推荐系统，旨在为模型规模、数据量与性能之间的关系建立可预测的模型，为重排等关键阶段的资源投入提供科学决策依据，降低试错成本。; 🔧 偏差治理的精细化与动态化：针对序列推荐中的曝光与选择偏差问题，研究从静态的因果纠偏方法向动态、时序感知的

工业级Transformer排序系统优化：今日多篇工业界论文聚焦于将Transformer架构深度适配并优化至推荐系统的排序阶段。核心挑战在于解决工业场景特有的高特征稀疏性、低标签密度和严苛的延迟要求。阿里巴巴的SORT和字节跳动的HAP分别从精排和粗排角度，通过请求中心样本组织、局部注意力、自适应计算预算分配等系统化设计，实现了业务指标显著提升与推理效率的同步优化，标志着Transformer在工业推荐中从“可用”迈向“高效可用”的新阶段。; 多阶段推荐中的精细化样本与计算管理：推荐系统多阶段

生成式推荐走向全链路深度集成：今日多篇论文聚焦生成式推荐范式，核心趋势从单一模块优化转向全链路协同。腾讯的OneRanker实现了生成与排序的架构级融合，清华的APAO则从训练目标层面弥合生成与推理的鸿沟，标志着该领域正从“能用”向“好用、高效”演进。; 工业界聚焦大模型推理效率与系统工程：面对LLM/Transformer带来的计算挑战，工业界论文普遍关注效率优化。快手的FlashEvaluator和SOLAR分别从跨序列并行评估和低秩注意力分解入手，在保证效果的同时显著降低延迟与资源消耗，体

大模型驱动的推荐系统优化：今日多篇论文聚焦于利用大语言模型（LLM）和多模态大语言模型（MLLM）解决推荐系统核心问题。从阿里巴巴的LaSER框架将推理能力内化到稠密检索，到小红书IDProxy用MLLM生成代理嵌入解决冷启动，再到百度与中科院合作优化多模态嵌入预训练，大模型正从内容理解、表示学习到推理决策，深度融入召回与排序环节。; 工业级验证与系统约束考量：工业界论文展现出对生产环境约束的深刻洞察。Dell的RAG部署实证表明，在固定检索深度和延迟约束下，单纯的召回提升可能无法转化为端到端收

本周共收录 23 篇推荐系统相关论文，其中 5 分论文 5 篇，4 分 10 篇，3 分 8 篇，整体质量出色。Generative Recommendation（生成式推荐） 是本周最显著的技术主线，6 篇论文直接聚焦于此，涵盖 Semantic ID 编码、受限解码优化、广告场景部署和多任务统一框架。另一条主线是 LLM 与推荐系统的融合范式——"LLM-as-Rec"（LLM 作为推荐骨干）与"LLM-for-Rec"（LLM 辅助推荐）两条路径本周都有重要进展。工业部署论文占比极高（6 篇含 Online A/B 测试），来自 AliExpress、快手、Apple App Store 等一线平台。

📭 今日无新论文：今日未收录新的推荐系统相关论文，无法进行趋势分析。

本文不是从系统优化角度谈复杂的模型的部署和优化问题，而是从行业成本角度，看线上推理多复杂的模型是可以满足成本及ROI要求的。 做一个假设： • 电商推荐行业，主要是更熟悉成本核算 • 部署标准的Transformer作为排序模型，参考OneTrans结构 • 参数规模对齐qwen2的系列模型，更直观看看能跑哪个尺寸

Roofline model是高性能计算领域用来分析程序性能瓶颈的一个直观模型，因为画出来像一个屋顶形状而得名。如下图，横坐标是算法的计算强度Flop/Byte（算法的浮点计算数除以内存访问量），纵坐标是算力Flop/s，它描述的是如果算法计算强度提升算力线性提升（Memory-Bound），直到算数强度超过硬件的拐点，之后算力逼近硬件的上限（Compute-Bound）。它核心回答了：你的程序到底受什么限制——计算能力还是内存带宽？应该优化哪里？