题目重点：先完成可评估推荐系统，再说明LLM能改变的交互与取舍。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练目标采用听完率/满意度与探索多样性，真实产品可能关注播放时长、订阅或收藏，需先确认。
- LLM Agent可理解自然语言偏好并调用授权推荐工具；不能自行编造曲库歌曲或替用户执行未授权操作。
解题路线
- 事件包括曝光、播放、skip、完播、收藏与上下文，保留曝光偏差；召回采用协同、内容、最近播放与热门等多路，再精排并重排多样性。
- 冷用户通过明确兴趣与受控探索建立偏好；冷歌用音频/文本metadata embedding和有限曝光。候选需过滤版权地区/年龄/已下架状态，最终推荐前再校验。
- LLM把“轻快但不要高音”转成结构化查询，调用catalog/recommend tools并给简短解释。排序可用成熟模型，LLM不用对全曲库逐首打分；对话偏好更新需明确持久或仅本会话。
- offline按时间切分并防同用户泄漏，比较ranking与覆盖；online实验监控skip、满意、长尾曝光与延迟。与无LLM基线比较真实增益，避免“更自然”替代可观测目标。
手动走一遍
用户要“适合跑步的法语歌”：Agent解析语言/场景，从曲库返回合法IDs；发现冷启动则问一个关键偏好，避免无限追问。假设1千万曲，每请求全量LLM推理不可行；先召回500、排序50，LLM只基于最终少量结果解释。数字是训练容量例。
规模与取舍
召回索引、排序候选数和生成token共同决定成本；实时请求服务与离线训练/embedding更新分离。延迟预算给每阶段，超时返回传统推荐。
易错点与追问
容易失分的边界
- 离线只测点击会奖励标题党或高曝光内容，需区分用户满意和偏差。
- LLM推荐不存在的歌，即便解释流畅也失败。
继续深挖
- 用户一句话撤销历史偏好时，怎样调整会话与长期profile？
- 如何让推荐解释可追溯到偏好/特征，避免暴露敏感推断？
