Tuyển tập PoC failure case

Nếu như mọi người để ý trên báo chí, truyền thông thì sẽ nhận ra được một điều, đó là những tin đưa thông tin đại loại: một công ty ABC nào đó bắt đầu thử nghiệm, hoặc thử nghiệm thành công PoC AI làm cái này cái kia thì rất nhiều. Những thông tin như: công ty ABC đã thành công ứng dụng AI vào cái này nọ cái kia thì lại rất ít.

Có bao giờ mọi người đặt ra câu hỏi:
1. Tại sao lại nhiều project PoC thất bại như vậy?
2. Các kiểu thất bại PoC?
3. Đánh giá PoC như thế nào?
4. Chuẩn bị và tiến hành PoC như thế nào để không bị thất bại?

Trong bài viết này mình sẽ nêu ra một số ví dụ về việc làm PoC bị thất bại thế nào để cho người đi sau không bị đi theo vết xe đổ đó nữa.

1. Không kiểm tra expectation của POC, nên POC ngon mà bị khách chê phò
2. POC ko deliver đúng hạn hoặc chất lượng phò thật
3. POC không chứng minh được hiểu quả kinh tế nên khách không đầu tư làm tiếp
4. POC cần qua A/B test để chứng minh hiệu quả, nhưng khách không dám chịu risk để chạy A/B test
5. POC xong khách gật gù OK xong biến mất không có lý do (có thể do COVID)
6. ML researcher bị giao làm software engineer luôn, không có kinh nghiệm nên code như shit
7. Engineer không biết code ML, code như shit
8. Data không đủ hoặc chất lượng quá phò
9. ML researcher ko tính được performance khi deploy thực tế
10. Khách hàng thất tình đéo muốn làm nữa (mới gặp xong!)
11. Key member trong team thất tình đéo muốn làm nữa (cũng mới gặp :D)
12. Key member ghét cty và quit
13. Hồi mới vô nghề, tự tin thái quá với chút kiến thức ít ỏi. nên khi thảo luận về chuyên môn hay có tranh cãi để ý kiến của mình đúng mà ko nghe ý kiến của người khác. Có lần team member nói model mình build ra Under-Fitting vì dự đoán trên tập train data mà điểm thấp lè tè. Mình gân cổ cãi lại và có chút thái độ ko hài lòng với team member. Không vui thì hợp tác trong lúc làm việc nó cũng ko còn nhiều. Sau này mới nhìn lại thấy góp ý về model under-fitting là đúng. bài học: giao tiếp là cực kỳ quan trọng để thúc đẩy teamwork. Nó đòi hỏi mình phải luôn question những gì mình làm, nhìn vào sự yếu kém kiến thức của bản thân và hãy luôn học hỏi lẫn nhau. Không nên gân cổ bảo vệ quan điểm của mình. Đôi khi chiến thắng 1 quan điểm cá nhân thì sẽ mất đi 1 người bạn và có thêm 1 kẻ thù trong công việc.
14. Làm gì làm, data là quan trọng nhất. Ko ai làm sẵn data để mình chỉ có mỗi việc build model. Hồi mới vô nghề, mình cứ chăm làm model, không chịu EDA xem nó có phù hợp bài toán ko? có khả thi khi build model không? liệu có data nào khác mình có thể khai thác không? Liệu xài data này thì lên production có được không? etc. Không chịu học nhiều về engineering để có thể chủ động giao tiếp với các team khác và khai thác data mình cần. nên sau 1/2 năm train model miệt mài, project bị close. Sau lần đó, mình thay đổi cách tiếp cận làm ML: Data tốt, model đơn giản, code dc test kỹ. Nên nhớ: Garbage in, bargage out.
15. Review model thật kỹ trc khi report. Hồi đó làm data, leak 1 phần label vào trong feature nên điểm test score cao chất ngất. Khi nhận ra dc thì nhìn lại cũng có vô số rắc rối đi kèm. Mệt nhất là vác mặt đi giải thích. Bài học là: Khi điểm số cao thì phải question ngay. Đời không ngon ăn như mình nghĩ.

… +986 lý do để bất kỳ 1 dự án nào chết, chả liên quan gì đến AI hay không.

Share

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *