即刻App年轻人的同好社区
下载
工程师的日常
计算机工程师的逸闻趣事。
431837人已经加入
- 早上地铁上读到 Andrew Ng 关于评估（evals）的一篇文章，让我重新思考了很多。
他说很多团队会因为觉得前期评估工作量太大，而迟迟不开始。但评估不一定要等到系统稳定后再做，也不需要一次性铺得很完备。哪怕只是从 5 个样本、一个粗糙的指标开始，都可以逐步积累、持续改进。
我深有同感。在我们当前的开发节奏下，项目推进非常快，需求层出不穷，很多时候都是“先上线、再修补”。作为项目负责人，我需要权衡技术和产品需求，我也确实很清楚评估机制的重要性。但现实是：每一轮迭代周期都很短，大家优先关注的是功能是否可交付、流程能否跑通，评估这一块就很容易被搁置，成为“之后有空再做”的任务。
但这种“之后再做”的方式，其实是把这头“评估的大象”越养越大。比如一开始如果我们能在每一轮加入几个样本评估、设计一个简单的成功判别逻辑，其实可以很快形成最初的反馈闭环；但如果一直等着“评估体系完整再做”，最后就会变成一次性需要投入大量精力去还“技术债”的局面。
而且我们也越来越发现，光靠人判断模型效果是撑不住的。模型行为越来越复杂，输出越来越长，团队成员对“什么是好”的标准也会逐渐分歧，没有一套基本的自动评估体系，后期维护和优化的效率会明显下降。
评估这件事，其实不是额外的负担，而是基础建设的一部分。与其把它看成一个庞大的、压在头顶的大项目，不如将它“拆象为块”，在每一轮迭代中做一点点。每多加 5 个样本，每补一个自动 check，就能逐渐缩小模型和人之间的评判差距，也能让系统在长期中更稳、更准。
写下来，一方面提醒自己：不要被“完美主义”或“时间压力”劝退评估的必要性；另一方面也希望未来的每一个项目中，都能更早地为评估预留出空间。
Andrew 原文链接见下图（发现有链接发不出来🤣）
5 27
