题目重点：定义下拉候选的意图、召回排序、在线服务、反馈与隐私边界，明确题目未明确产品细节。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练场景为用户在搜索框键入前缀时，系统推荐 5 个可点击的应用/条目；具体原题可能是另一种下拉推荐，须先向面试官确认。
- 假设有前缀、设备语言、合规允许的上下文和用户同意范围；不把敏感个人数据默认用于训练或跨设备传输。
解题路线
- 先问清推荐目标：是补全查询、推荐应用还是个性化候选？定义点击率、成功完成率、延迟、覆盖与错误推荐的守护指标；确定 P95 延迟及是否离线可用。
- 候选召回可用前缀索引/Trie 和热门候选，按语言、可用性、权限、政策过滤；冷启动使用非个性化热门与编辑规则。
- 排序层组合 prefix 匹配、历史使用和上下文信号；训练要处理曝光偏差与负样本定义，按时间/用户切分离线验证，再小流量实验。
- 在线链路先返回快速安全候选，复杂个性化可异步刷新但避免列表抖动；缓存键包含前缀、语言、地区与模型版本，端上与服务端能力按隐私和时延取舍。
- 记录曝光/点击/完成事件时去重并遵守同意；监控无结果率、P95、坏例、偏差与隐私投诉，模型回退到安全基线。
手动走一遍
用户输入 `ph`：前缀索引取候选，过滤不可用项，排序后显示 5 条。若用户继续输入 `pho`，旧请求的晚到响应不能覆盖新前缀；请求附序号或取消旧请求。无历史用户只看本地化热门候选。
规模与取舍
前缀召回取决于索引结构和候选数；不能脱离数据规模宣称固定 O(1)。在线预算可分解为网络、召回、过滤、排序和呈现，候选数先截断以控制最坏延迟。
易错点与追问
容易失分的边界
- 不确认‘下拉’对象就把一种产品场景冒充原题。
- 只谈模型，不定义曝光、点击和成功的事件口径。
- 把个性化历史直接传服务端，忽略同意与权限。
- 旧请求乱序导致列表回跳。
- 离线 NDCG 上升就声称真实体验改善，未做在线指标/坏例验证。
继续深挖
- 如果必须在设备端运行，索引/模型大小与更新频率如何取舍？
- 怎样处理输入中的拼写错误、多语言和拼音？
- 如何评估推荐造成的曝光偏差？
- 热门候选缓存失效或模型服务超时如何降级？
