1. 你们项目中协同过滤算法的应用场景是什么？主要解决了什么问题？
答案：
在我们的 web-company 前端项目中，协同过滤算法主要用于为用户推荐产品或新闻。例如，在 src/utils/recommender.ts 文件中实现了基于用户行为（如浏览、点赞、收藏）的推荐逻辑。
协同过滤帮助我们根据用户的兴趣和行为，为其推荐其他用户喜欢的产品或新闻，提高了用户的活跃度和转化率，解决了“千人一面”的推荐问题。
2. 你们实现的是基于用户的协同过滤还是基于物品的协同过滤？为什么这样选择？
答案：
我们主要实现了基于物品的协同过滤（Item-based Collaborative Filtering）。
原因是：
- 用户数量远大于产品/新闻数量，基于物品的协同过滤计算量更小，易于维护相似度矩阵。
- 用户的兴趣变化较快，而物品的属性和相似度相对稳定，推荐结果更精准。
具体实现见src/utils/recommender.ts，通过分析用户对产品/新闻的行为，计算物品之间的相似度，为用户推荐相似物品。
3. 协同过滤算法的数据来源和流程在你们项目中是怎样的？前后端如何配合？
答案：
- 数据来源：用户的浏览、点赞、收藏等行为数据，前端通过 API（如
src/api/like.ts、viewRecord.ts）上传到后端（如web-server/controllers/web/likeController.js、viewRecord.js）。 - 流程：
- 前端收集用户行为并上传到后端数据库。
- 后端定期统计用户-物品的交互数据，计算物品相似度矩阵。
- 前端在需要推荐时（如进入产品详情页），调用后端推荐接口，获取推荐列表并展示。
- 简单场景下，前端也可用本地数据做实时推荐（如
recommender.ts）。
4. 你们是如何处理协同过滤中的“冷启动”问题的？
答案：
- 新用户冷启动：对于新注册用户，我们采用热门产品/新闻推荐或基于用户注册信息的内容推荐，直到用户有足够行为数据。
- 新物品冷启动：新上线的产品/新闻会优先推荐给活跃用户或在相关分类下曝光，收集初始反馈后再纳入协同过滤推荐。
- 项目中在
recommender.ts里有 fallback 逻辑，如果用户行为数据不足，则返回热门或最新产品/新闻。
5. 你们如何评估协同过滤推荐效果？在项目中做过哪些优化？
答案：
- 评估方式：通过用户点击率、转化率、用户停留时长等指标评估推荐效果。
- 优化措施：
- 增加了物品相似度的加权（如浏览、点赞、收藏权重不同）。
- 对推荐结果做了去重和多样性处理，避免推荐内容过于单一。
- 对冷启动用户采用混合推荐策略。
- 在
recommender.ts中实现了缓存和异步加载，提升了前端推荐的性能和体验。
