Ai dám thu 2000 USD trong một tháng cho mô hình lớn?

Trải nghiệm xây dựng Hệ thống MLOps trong bốn năm

Như tiêu đề đã nói, tôi đã dành gần bốn năm để xây dựng hệ thống MLOps. Thế giới thay đổi rất nhanh, và với bốn năm kinh nghiệm làm lập trình viên, tôi cảm thấy mình luôn phải cố gắng không bị cuốn vào những công nghệ mới trong lĩnh vực học sâu (LLM), đồng thời cố gắng thích nghi với kỹ thuật phần mềm và tìm kiếm vị trí tốt từ xa.

Bài viết này là một phần tổng kết về những trải nghiệm của tôi trong nhiều năm qua, đồng thời cũng là một cái nhìn của tôi về kỹ thuật và học máy (MLOps). Tôi biết bạn cũng có thể đã từng tự hỏi về những vấn đề tương tự, nhưng tôi sẽ không trả lời bất kỳ câu hỏi nào, chỉ đơn thuần chia sẻ quan điểm của mình.

Năm 2021, tôi bắt đầu nghiên cứu mô hình tiêu thụ năng lượng, đây là lần đầu tiên tôi thực sự đi sâu vào ứng dụng MLOps. Ban đầu, vấn đề khá đơn giản: chúng tôi cần dự đoán lượng điện tiêu thụ hàng ngày của tám thành phố mỗi 24 giờ, nhưng phải dự đoán trước 24 giờ. Dự án này được gọi là dự đoán điện năng ngày hôm sau. Kể từ khi tôi bắt đầu nghiên cứu vấn đề này, số lượng người dùng đã tăng lên, người tiêu dùng bình thường sử dụng nhiều năng lượng hơn, các nhà máy mới cũng đang được xây dựng. Nhu cầu năng lượng cũng thay đổi theo biến động kinh tế. Tất cả điều này đều có nghĩa là nhiều hơn nữa các mô hình trôi dạt và dữ liệu trôi dạt.

Sau một thời gian, tôi đã xác định được một loạt các thuật toán mà tôi sử dụng cho mô hình dự đoán. Sau khi thử nghiệm các mô hình học sâu và dựa trên cây, tôi phát hiện ra rằng thành công nhất là LightGBM và XGBoost (cùng với mô hình học sâu tích hợp).

Các mô hình dựa trên cây gặp vấn đề ở chỗ, chúng thường bị giới hạn bởi dữ liệu bạn cung cấp. Ví dụ, nếu bạn cố gắng dự đoán mức tiêu thụ năng lượng ngày đầu tiên của mùa hè, và mức tiêu thụ tối đa trong ngày cùng kỳ năm ngoái là 600 đơn vị, thì trừ khi bạn tùy chỉnh đúng vấn đề, dự đoán của bạn sẽ không vượt quá 600 đơn vị. Tuy nhiên, khi các sự kiện và đặc trưng ổn định và phân phối đầu ra không thay đổi nhiều, các mô hình dựa trên cây có thể cung cấp kết quả dự đoán xuất sắc.

Thật lòng mà nói, phần lớn kinh nghiệm của tôi lúc đó đến từ Kaggle. Tôi đã dành khoảng chín tháng để nghiên cứu các cuộc thi dự đoán, tạo ra các tính năng mới và thử nghiệm các mô hình khác nhau. Mô hình tôi đưa ra đạt điểm 7/10, và tôi biết rằng nếu tôi cạnh tranh với các chuyên gia thực sự, họ có thể đánh bại mô hình của tôi một cách dễ dàng.

Dự đoán tiêu thụ năng lượng trong tương lai là một trải nghiệm kỳ lạ, đặc biệt là khi có quá nhiều yếu tố ảnh hưởng đến việc sử dụng điện – thời tiết, cuối tuần và ngày làm việc, kỳ nghỉ, thậm chí cả thời gian cầu nguyện. Việc sống ở một nơi có bốn mùa rõ rệt như Thổ Nhĩ Kỳ còn làm tăng thêm độ phức tạp. Tôi không phải là một nhà sản xuất mô hình hoàn hảo, tôi cố gắng để mô hình của mình thích ứng với những thay đổi đột ngột. Ví dụ, nếu nhiệt độ duy trì ổn định ở 25°C trong hai tháng liên tiếp, sau đó giảm đột ngột 5°C trong một ngày, mô hình thường giả định rằng mức tiêu thụ điện sẽ giống như những ngày 25°C trước đó, nhưng thực tế không phải vậy. Hành vi của con người thay đổi theo mùa, và việc dự đoán những thay đổi tinh tế này rất khó khăn. Sau đó, còn có những sự kiện không thể đoán trước như trận đấu bóng đá quốc gia – chúc may mắn với việc xây dựng mô hình!

Vậy tôi đã làm gì để giải quyết vấn đề trôi dạt mô hình và dữ liệu? Trong năm qua, tôi đã tạo ra hàng trăm tính năng, sử dụng XGBoost và LightGBM để xây dựng một số mô hình dựa trên cây, và sử dụng dữ liệu năm ngày trước để kiểm tra chúng. MLFlow là công cụ chính trong quy trình sản xuất mô hình hàng ngày. Mặc dù nó có thể không phải là cách hoàn hảo để kiểm chứng mô hình, nhưng nó thực sự cải thiện kết quả dự đoán dài hạn. Ít nhất, khi tiêu thụ điện năng ổn định và mô hình thích ứng tốt, nó đã cung cấp cho tôi một lựa chọn an toàn.

Để đơn giản hóa quy trình, tôi đã xây dựng một hệ thống hoàn chỉnh, mỗi sáng trích xuất dữ liệu thông qua API, tạo ra các tính năng, chọn mô hình và dự đoán. Các kịch bản tự động tôi xây dựng chỉ mất một phút để chạy. Tuy nhiên, ngay cả khi có kịch bản tự động, bạn vẫn phải theo dõi chặt chẽ kết quả dự đoán, đặc biệt là trong những ngày lễ quốc gia hoặc sự kiện bất ngờ.

Một trải nghiệm kỳ lạ của tôi là tranh luận với quản lý của mình về sự trôi dạt đột ngột trong kết quả dự đoán. Ông ấy cho rằng nếu thời tiết mùa hè đột ngột giảm xuống, việc dự đoán tiêu thụ điện năng ngày hôm sau sẽ dễ dàng hơn vì số lượng điều hòa đang hoạt động sẽ giảm. Ông ấy thậm chí còn điều chỉnh thủ công một số dự đoán, nhưng kết quả lại ngược lại. Điều này cơ bản đã kết thúc cuộc tranh luận của chúng tôi. Mặc dù tôi tin rằng có những ngày mà việc điều chỉnh thủ công có thể mang lại kết quả dự đoán tốt hơn, nhưng mô hình thường phát hiện ra những mô hình mà chúng ta không phát hiện ra.

Sau đó, tôi chuyển sang làm nền tảng MLOps trong lĩnh vực chăm sóc sức khỏe. Tôi đã dành rất nhiều thời gian để tìm kiếm công việc có thể làm MLOps, và cuối cùng tôi may mắn tìm được một công ty khởi nghiệp về chăm sóc sức khỏe, nơi tôi trở thành kỹ sư toàn thời gian đầu tiên ở đó. Tôi có kinh nghiệm về mô hình chăm sóc sức khỏe, nên cảm thấy ngành này rất phù hợp. Tôi tìm thấy họ, và họ cũng tìm thấy tôi, hoàn toàn là do may mắn.

Trải qua ba năm làm việc tại đây là một hành trình đầy thách thức, chủ yếu vì tôi đã chuyển từ tập trung vào mô hình sang viết nền tảng. Tôi luôn là người thích nghiên cứu, tôi thực hiện các kết quả từ các bài báo và học hỏi càng nhiều càng tốt từ Kaggle, giáo sư và học giả. Ví dụ, tôi rất tò mò về sự khác biệt giữa mô hình học sâu và mô hình bảng, đặc biệt là tại sao học sâu thường gặp khó khăn khi xử lý dữ liệu bảng, trong khi các mô hình dựa trên cây lại tỏ ra hiệu quả. Tôi đã đọc các bài báo, thảo luận về chủ đề này trên X/reddit, và tôi là kiểu người như vậy. Nhưng khi tôi chuyển sang viết nền tảng, tôi mới nhận ra rằng tôi cần học rất nhiều về việc viết mã sản phẩm. Tôi đã làm hỏng nhiều thứ trong những tháng đầu tiên.

Trong những tháng đầu tiên, chúng tôi đánh giá mô hình trong các notebook Jupyter, tôi đọc một số bài báo về cách đánh giá sâu hơn các mô hình chăm sóc sức khỏe, cũng xem xét sự thiên vị về giới tính và chủng tộc. Công việc ban đầu rất thú vị, nhưng sau đó chúng tôi phải tích hợp tất cả nội dung vào một nền tảng. Đó là khi tôi bắt đầu hiểu về lập trình hướng đối tượng, thiết kế hệ thống và nguyên tắc kỹ thuật phần mềm truyền thống. Tôi không phải là kỹ sư khoa học máy tính, nên tôi học dần dần.

Đời sống khởi nghiệp rất căng thẳng, thời gian làm việc dài, độ dốc học hỏi cao. Hệ thống chúng tôi xây dựng sử dụng MongoDB, Python, RabbitMQ, S3 và AWS – một pipeline khá chuẩn. Nền tảng của chúng tôi nhằm mục đích xác minh các mô hình chăm sóc sức khỏe, đạt được sự phê duyệt của FDA và đảm bảo mọi thứ được thực hiện đúng. Dữ liệu đến từ các đối tác, nhưng các nhà cung cấp mô hình chưa bao giờ xem dữ liệu gốc, vì họ không nên có quyền truy cập. Vì vậy, mục tiêu kinh doanh của chúng tôi là xác minh các mô hình dựa trên dữ liệu hộp đen và chuẩn bị các tài liệu cần thiết cho FDA.

Để nền tảng của chúng tôi đạt được mục tiêu, nó cần hỗ trợ tất cả các loại hình ảnh y tế, xác minh bất kỳ mô hình thị giác máy nào và phát hiện ra các sự thiên vị mô hình có thể tồn tại. Trong ba năm qua, trọng tâm của nền tảng này cũng đã thay đổi. Năm đầu tiên, mục tiêu của chúng tôi là triển khai và xác minh mô hình. Năm thứ hai, chúng tôi đã thêm chức năng chú thích, hỗ trợ dữ liệu chăm sóc sức khỏe và thực hiện tích hợp đám mây. Đến năm thứ ba, chúng tôi nhận ra rằng chúng tôi cần tập trung vào một số nhu cầu cụ thể của khách hàng.

Một thách thức là tách logic của nền tảng khỏi mã nguồn cụ thể cho khách hàng. Chúng tôi dành thời gian viết mã nguồn cụ thể cho khách hàng, mã nguồn này giúp 80% tính năng trên nền tảng có lợi, nhưng đôi khi chúng tôi phải thực hiện logic cụ thể cho khách hàng cụ thể. Điều này đã gây ra nhiều tranh luận về việc chúng tôi nên tăng cường nền tảng bằng các chức năng cụ thể cho khách hàng, hay nên tách rời chúng. Nếu chúng tôi tăng cường nền tảng bằng quá nhiều chức năng cụ thể cho khách hàng, nó có thể trở nên phức tạp và lộn xộn. Mặt khác, khi mã nguồn của khách hàng cần truy cập dữ liệu của nền tảng, việc tách rời có thể gây ra tình huống phức tạp.

Tôi vẫn không chắc chắn về cách phân biệt MLOps, MLE, kỹ thuật back-end và logic kinh doanh. Có thể không có câu trả lời duy nhất, nhưng tôi nghĩ rằng chúng tôi đã làm tốt trong việc duy trì và phát triển nền tảng.

Gần đây, tôi đã tham gia phỏng vấn cho một vị trí MLOps trong ngành ngân hàng, và 90% thời gian tôi dành để viết mã. Người quản lý phỏng vấn tôi là người đã chuyển từ DevOps sang MLOps, và tôi tin rằng ông ấy đã phát triển một số mô hình học máy. Đối với ông ấy, mô hình chỉ là một container Docker có đầu ra cụ thể, bạn cần phải quản lý, theo dõi và ghi lại công việc. Đối với một số người, đây mới chính là kỹ thuật MLOps thực sự. Tôi hoàn toàn đồng ý với điều này.

Nhóm của ông ấy đang triển khai mô hình trên Apache Airflow, và ông ấy hỏi tôi về kinh nghiệm của tôi trong lĩnh vực này. Tôi nghĩ đến việc: như gợi ý trong câu hỏi, mô hình tôi đã huấn luyện / triển khai trong vấn đề điện năng là mô hình hàng ngày, vì vậy tôi không cần theo dõi mô hình, tôi chỉ cần dự đoán. Tôi không cần kiểm tra xem mô hình có luôn hoạt động hay không, cũng không cần kiểm tra throughput hoặc latency.

Mô hình tôi sử dụng trong vấn đề MLOps chăm sóc sức khỏe là mô hình dựa trên dự án, không cần liên tục xây dựng mô hình, và nó là cục bộ, vì vậy vấn đề an ninh không phải là vấn đề chính.

Nhóm của ông ấy không viết mã, ít nhất là trong giai đoạn hiện tại. Tôi nhận ra điều này trong quá trình phỏng vấn, và điều này thật kỳ lạ.

Những năm qua, một vấn đề khác luôn ám ảnh tôi: tôi là ai? Tôi là kỹ sư MLOps, kỹ sư học máy, nhà nghiên cứu học máy hay kỹ sư back-end? Trong một nhóm nhỏ hoặc công ty khởi nghiệp, bạn cần phải có tất cả những kỹ năng này. Bạn đã từng nghe về “kỹ sư 10x”? Những vị trí kỳ lạ yêu cầu bạn công bố bài báo NeurIPS và viết mã Node.js? Anh em, tại sao lại như vậy? Tôi đã thấy nhiều sự kết hợp kỳ lạ như vậy. Không phải khoe khoang, nhưng dưới đây là những công việc tôi đã làm:

• Viết một bài báo tiền xuất bản trong thời gian thực tập tại Stanford = Nhà nghiên cứu học máy
• Xây dựng mô hình bảng và CV = Nhà khoa học dữ liệu
• Triển khai một mô-đun Auto-ML, cho phép đào tạo / tinh chỉnh tức thì các mô hình phát hiện, phân loại và phân đoạn đối tượng, và quản lý phiên bản = Kỹ sư phần mềm Python, Kỹ sư học máy
• Phát triển thư viện giải thích cho mô hình CNN sử dụng Grad-CAM = Nhà nghiên cứu học máy
• Hỗ trợ mô hình sử dụng FastAPI và tích hợp với ứng dụng front-end = Kỹ sư back-end
• Thiết kế và triển khai một nền tảng sử dụng Docker, RabbitMQ, MongoDB và các công cụ khác = Kỹ sư MLOps

Tất nhiên, những thuật ngữ này có thể thay đổi, và một kỹ sư MLE giỏi phải là một kỹ sư phần mềm giỏi, nhưng tôi nên là vai trò nào? Tôi cảm thấy mình đã bị lừa bởi câu nói “Học nhiều hơn, nhận nhiều hơn”.

Nhưng tôi đã học được điều gì? Tôi có phải là một kỹ sư 10x không chuyên môn không? Lợi ích là, tôi có thể ứng tuyển cho các vị trí khoa học dữ liệu, MLOps, MLE và kỹ sư back-end Python, với trọng tâm là học máy. Và tôi đã tham gia phỏng vấn cho tất cả các vị trí này. Nhưng vấn đề là gì? Trong quá trình phỏng vấn, họ không luôn tin tưởng vào phạm vi kinh nghiệm của tôi. Họ hỏi nhiều câu hỏi, và ngay cả khi tôi có những câu trả lời tốt, một số người phỏng vấn vẫn cố gắng loại tôi ra. Nếu bạn không đưa ra được câu trả lời cụ thể mà họ muốn, bạn sẽ bị loại.

Tôi đã gặp trường hợp này trong một cuộc phỏng vấn với một công ty toàn cầu về khoa học dữ liệu. Đối với tất cả các chủ đề tôi đề cập, anh ta đều chất vấn tôi, và liên tục chuyển đổi bối cảnh, khiến tôi cảm thấy như một kẻ ngốc. Khi anh ta phát hiện ra rằng tôi đưa ra câu trả lời không tốt sau ba giờ phỏng vấn, anh ta nói: “Tôi đã biết.” Tôi không biết anh ta biết gì? Tất nhiên, tôi không phải là chuyên gia trong mọi lĩnh vực, nhưng điều này cũng khiến tôi rất khó chịu.

Còn một lần, tôi đã được phỏng vấn bởi một người rất thông minh – người đã từng làm việc tại một công ty nổi tiếng và có bằng tiến sĩ từ một trong mười trường đại học hàng đầu. Anh ta rất thông minh, và tôi hy vọng rằng sau mười năm, tôi sẽ trở thành người như anh ta. Anh ta rất tử tế, và tôi rất tôn trọng anh ta. Tôi đã nói với anh ta về kinh nghiệm và những việc tôi đã làm, và hỏi anh ta tôi có thể làm gì thêm. Nhưng bạn biết không? Anh ta mong đợi tôi có nhiều kinh nghiệm hơn trong lĩnh vực LLM, anh ta nói: “Tôi không có ngân sách để đầu tư vào tiềm năng; tôi cần nhân viên có đủ kinh nghiệm trong chủ đề cụ thể này.” Đúng, nhưng như vậy tôi nên làm gì? Tôi nên theo đuổi từng xu hướng học sâu mới và nghiên cứu chúng với mục đích kiếm tiền? Điều này có khả thi không? Bạn có thể mong đợi điều gì từ một người chỉ có bốn năm kinh nghiệm?

Tôi không biết. Thật sự, tôi không biết. Điều tôi biết là:

FOMO (sợ bỏ lỡ) thực sự tồn tại trong lĩnh vực học máy.

Nếu bạn cố gắng học MLE, kiến thức và kinh nghiệm về MLOps, kỹ thuật phần mềm hoặc DevOps có thể không giúp bạn tự tin hơn.

Từ khóa:

• Hệ thống MLOps
• Khoa học dữ liệu
• Kỹ thuật học máy
• Chăm sóc sức khỏe
• Apache Airflow