我碰到过算法同学不愿意进行模型宣讲 就不讲这个逻辑和原理 这种情况就很麻烦 只能产品经理进行模型验证 我自己看了很多论文恶补

【模型宣讲】和 【模型评估】—— 开发阶段的技术方案评审，有些团队的技术方案评审不带产品，如果把产品同学拉进来，那就跟模型宣讲比较类似了。 【模型验证】—— 确实是专业研发流程的一个新的拓展，比传统的所见即所得的测试挑战要大一些。

在推荐列表的场景下，一般会和业务方沟通一个简单的规则引擎用来做降级方案，避免因推荐的服务异常或结果异常导致的生产事故。 例如请求超过业务方要求的响应时间或返回的结果数量异常等等。

关于特征的稳定性具体是如何评估的？一旦出现缺失，是否要写个例外或者干脆就不采用可能缺失的特征，还有就是评估也有可能考虑步骤，项目在运转过程中，如何先于用户发现模型运转的问题（监控模型运行状态）。

每个特征都需要算ks，iv值吗