1. 问题与动机
电商推荐系统的核心需求是「快速捕捉用户意图变化」。RecGPT-Mobile 直面三个具体痛点：（1）现有 LLM-as-Recommender（如 RecGPT）部署在云端，每次推理需把上行行为序列发送到服务器、再回传 query/排序结果，端到端延迟无法满足用户在手机端「点了一个袜子立刻想看运动鞋」这类秒级兴趣漂移；（2）千万 DAU 量级下纯云端 LLM 推理的算力成本接近线性增长；（3）现有端侧推荐模型（EdgeRec、DIR）仍是 ID-based 浅模型，缺乏 LLM 的语义推理能力，无法把「最近浏览跑鞋 + 加车袜子 + 搜索「跑步装备」」这类复合行为浓缩成一个语义化的下一步搜索 query。
作者把问题形式化为 next-query prediction：根据手机端最近交互行为（浏览、加车、搜索、点击）实时生成下一步用户最可能输入的 query，反向驱动 feed 推荐。这一定义把推荐问题转化为生成式语义任务，天然适配 LLM。
2. 方法详解
整体架构 5 模块：用户行为采集（端侧本地 cache，不上行原始日志）→ Prompt 构造（自适应模板）→ Intent Agent（端侧微调 LLM）→ Item 召回（基于生成 query 触发底层搜索）→ 训练管线（云端 LoRA SFT + 8-bit 量化 + OTA 下发到端侧）。
模型选型：作者对比 Qwen3-0.6B / 4B / 8B / 30B 四种参数量。Base 评测综合得分 0.6B=0.677、4B=0.613，反直觉地小模型 base 评分高于 4B（猜测因为 4B base 在 e-commerce domain 缺乏 supervision 收敛差）。LoRA 微调后所有规模均跃升至 0.78–0.83；INT8 量化后 0.6B+LoRA+Quant=0.794，对比未量化 0.829 仅退化 4%，最终选 0.6B-Quant 部署。
训练数据混合配方（关键点）：60% behavior-driven（购买/搜索日志中真实「行为序列→用户随后输入 query」对）+20% co-purchase（共购关系挖掘的潜在意图）+15% LLM-augmented（云端大模型扩写多样化 query）+5% 人工标注（高质量 anchor）。这一配比把「分布忠实度（行为日志）」「召回扩展性（共购+LLM 增广）」「质量上限（人工）」三者平衡。
自适应 Prompt 构造算法（4 步）：
- 特征抽取：当前会话行为分布、最近性、多样性、频次
- 模板级 adaptation：从模板池中按特征选最优模板
- 结构级 adaptation：增量精调 prompt 各组件
- Budget-aware pruning：在端侧延迟/内存约束内裁剪
触发优化机制：不持续做端侧推理，而是以「intent drift score」决定何时唤起 LLM。该 score 由三部分加权：行为分布熵变化 ΔH、Jaccard similarity（语义重叠）、Jensen-Shannon divergence（分布偏移）。综合得分超过阈值 τ=0.8 才触发推理，省下大量 idle 算力。
训练设置：LoRA rank 适配端侧约束；INT8 对称量化；端侧使用 ONNX Runtime / Qualcomm Hexagon DSP 推理（论文未明确指定后端但提及 mobile inference engine）。
3. 核心技术贡献
(1) 0.6B 端侧 LLM 推荐意图理解：首次系统验证 sub-1B LLM + INT8 量化在工业级推荐意图任务上「相对准确率仅退化 4%」可接受，为后续端云协同推荐打开尺寸下限。机制在于 next-query 任务比 chat 任务对推理深度需求更弱，模式识别+少量推理即可。
(2) 60/20/15/5 训练数据配方：把 behavior-driven 主体（贴合分布）和 LLM-augmented（覆盖长尾）显式分离配比，是 LLM4Rec SFT 数据工程上的可复用 recipe。比纯日志蒸馏 +5–10 个百分点。
(3) Drift-aware 触发机制：引入 ΔH+Jaccard+JSD 三信号融合作为触发器，而非定时/每个事件触发。这把端侧 LLM 算力消耗与「确实有兴趣漂移」事件挂钩，是端侧 LLM 部署的工程关键。
(4) 自适应 Prompt 与结构裁剪：在固定 token budget 下根据用户特征动态选择 prompt 模板和结构，比静态 prompt 在 Ssem/Slogic/Sstyle 三维评估上一致更优。
4. 实验结果分析
离线评测（综合得分越高越好）：
- Qwen3-0.6B：Base 0.677 → LoRA 0.829（+22%）→ LoRA+Quant 0.794
- Qwen3-4B：0.613 → 0.783 → 0.760
- 0.6B 量化版 0.794 已优于 4B base 0.613，证明 LoRA 微调对小模型增益更显著
在线 A/B（淘宝 4 个 feed 场景，1 个月，千万级用户）：
| 场景 | CTR | 支付转化 | GMV |
|---|---|---|---|
| Payment Success | +1.3% | +2.3% | +2.5% |
| Shipment Tracking | +2.4% | +2.9% | +3.0% |
| Shopping Cart | +2.5% | +2.7% | +2.9% |
| Order List | +0.8% | +1.8% | +1.8% |
| 平均 | +1.8% | +2.7% | +2.5% |
有趣现象：Shipment Tracking（物流跟踪页）涨幅最高（GMV +3.0%）——用户在等待物流时心智更开放，端侧实时捕捉「等快递期间产生的次级需求」收益最大；Order List 涨幅最低（CTR +0.8%）——订单页用户已完成购买决策，意图带宽窄。
延迟稳定性：P50–P95 区间在多日测试中保持平稳，反映 INT8 + 触发器组合稳定承载真实环境抖动。
消融：论文未给出每个模块（触发器、自适应 prompt、训练数据配比）的独立 ablation，是评测完整性短板。
5. 局限与未来方向
作者明确指出：
- 模型大小被端侧硬件约束在 0.6B 量级，复杂多步推理任务表现待验证；
- 冷启动（无端侧行为历史）场景未深入讨论，依赖云端兜底；
- 跨设备同步（同一用户多端）未涵盖。
笔者补充：触发器超参 τ=0.8 是 hand-tuned，不同业务可能需重新调优；intent drift score 三信号权重也是手工设计，可考虑 learnable。
6. 工业实践意义
直接可借鉴：
- 端侧 LLM 部署可行性：对于电商/社区/短视频信息流，sub-1B + INT8 已可承载意图理解。社区搜索可考虑同样架构生成「下一步搜索 query」反向驱动 feed。
- 训练数据配方：60/20/15/5 直接套用——主体是真实行为对，少量 LLM 增广扩长尾，极少量人工兜底质量。
- 触发器设计：把端侧 LLM 触发与意图漂移信号挂钩，是控制端侧算力的关键工程实践，可推广到其他端侧大模型场景。
部署考量：
- 端侧延迟：0.6B-INT8 在中端 Snapdragon SoC 单次推理 200–500ms 量级（论文未明确，但稳定 P50–P95 暗示）；
- 内存：0.6B-INT8 ~ 600MB，对多数中高端机型可接受；
- 模型更新：LoRA 增量 OTA 下发，无需重建底模；
- 隐私：端侧本地行为数据不上行，符合数据合规趋势。
坑点：Order List 场景 CTR 只 +0.8%，说明端侧 LLM 不是万能药——用户已做出决策的场景边际收益小，应优先在「用户处于探索/等待状态」的页面部署。