Đơn vị 7 / 11

MLOps và triển khai: Chuyển mô hình từ phòng thí nghiệm sang sản xuất

Lợi nhuận:

  • Khả năng nhận ra những thách thức đặc biệt của ML liên quan đến bộ ba và gói mô hình dữ liệu mã và trình bày mô hình trực tuyến hoặc theo đợt tùy theo nhu cầu kinh doanh.
  • Khả năng triển khai các mô hình triển khai dần dần và khôi phục (bóng tối, canary, A/B, khôi phục) và thêm kế hoạch khôi phục đã được thử nghiệm cho mỗi lần triển khai
  • Khả năng giữ liên kết số liệu-mã-dữ liệu của mô hình được đưa vào sản xuất có thể theo dõi được bằng CI/CD và sổ đăng ký mô hình được kiểm soát ngưỡng đánh giá

Để một mô hình đạt được độ chính xác 95% trong sổ ghi chép chỉ là một nửa câu chuyện. Nửa còn lại—thường là phần khó khăn—là đưa mô hình đó đến tay người dùng thực theo cách đáng tin cậy, có thể mở rộng và bảo trì được. MLOps (Hoạt động học máy: nguyên tắc đưa, vận hành và duy trì các mô hình ML vào sản xuất) kết hợp các phương pháp thực hành DevOps của công nghệ phần mềm với những thách thức riêng của ML. Trong phần này, chúng tôi đề cập đến các bước chuyển mô hình sang sản xuất và cách trí tuệ nhân tạo hỗ trợ trong quá trình này.

Tại sao ML khác với phần mềm thông thường?

Trong phần mềm thông thường, hành vi nằm trong mã; Nếu mã không thay đổi thì hành vi sẽ không thay đổi. Trong ML, hành vi phụ thuộc vào cả mã, dữ liệu và mô hình. Ba khía cạnh này tạo ra những thách thức bổ sung cho MLOps:

  • Trôi dữ liệu: Dữ liệu trong quá trình sản xuất di chuyển ra khỏi dữ liệu trong quá trình đào tạo theo thời gian; mô hình trở nên lỗi thời.
  • Bạn cần phiên bản ba thứ: Mã, dữ liệu và mô hình—cả ba.
  • Thất bại thầm lặng: Một mô hình có thể thất bại mà không gặp sự cố, không đưa ra lỗi, chỉ bằng cách đưa ra những dự đoán không chính xác. Việc nắm bắt điều này đòi hỏi phải có sự giám sát.

Đó là lý do tại sao có sự khác biệt lớn giữa "mô hình hoạt động" và "mô hình sẵn sàng sản xuất".

Đóng gói và trình bày mẫu

Bước đầu tiên trong việc đưa mô hình vào sản xuất là đóng gói nó: tệp mô hình, các thư viện cần thiết, mã tiền xử lý và thông tin phiên bản cùng nhau thành một tổng thể có thể tái tạo. Ở đây, việc chứa đựng (ví dụ: Docker: đặt ứng dụng vào một hộp riêng biệt với tất cả các phần phụ thuộc của nó) là tiêu chuẩn; Nó loại bỏ vấn đề "nó đang hoạt động trên máy của tôi".

Hai mô hình cơ bản phục vụ mô hình:

  • Trực tuyến/thời gian thực (trực tuyến): Mô hình nằm sau API, trả về dự đoán tức thì cho mọi yêu cầu đến. Độ trễ thấp là rất quan trọng.
  • Lô: Mô hình xử lý các tập dữ liệu lớn theo định kỳ (ví dụ: tạo điểm cho tất cả khách hàng vào ban đêm). Độ trễ là không liên quan, hiệu quả là quan trọng.

Cái nào đúng tùy thuộc vào nhu cầu kinh doanh: đề xuất trực tuyến ngay lập tức, điểm rủi ro hàng tháng theo đợt.

Mẹo: "Thời gian thực" là chi phí chứ không phải mặc định. Lô rẻ hơn và đơn giản hơn nhiều nếu kết quả sẽ được sử dụng trong vòng vài giờ. Bạn có thực sự cần một câu trả lời ngay lập tức? Hãy hỏi điều đó trước.

Chiến lược phân phối an toàn

Việc mở trực tiếp một mô hình mới cho tất cả lưu lượng truy cập là rất rủi ro; Nếu sai thì mọi người đều bị ảnh hưởng. Mô hình phân phối an toàn:

  • Triển khai bóng: Mô hình mới nhận được lưu lượng truy cập sản xuất nhưng dự đoán của nó không được hiển thị cho người dùng mà chỉ được ghi lại. Nó được so sánh với mô hình cũ để xem liệu nó có an toàn với dữ liệu thực hay không.
  • Triển khai Canary: Mô hình mới lần đầu tiên được triển khai cho một tỷ lệ nhỏ lưu lượng truy cập (ví dụ: 5%); Nếu không có vấn đề gì thì tăng dần.
  • Thử nghiệm A/B: Hai mô hình được trình bày song song cho người dùng thực và các số liệu kinh doanh (chuyển đổi, số nhấp chuột) được so sánh.
  • Rollback: Khả năng quay lại phiên bản cũ nhanh chóng nếu model mới hoạt động kém. Mỗi lần triển khai nên có một kế hoạch khôi phục.
Thận trọng: Việc triển khai mà không có kế hoạch khôi phục sẽ không hoàn tất. Khả năng quay lại phiên bản cũ trong vòng vài phút sẽ bảo vệ người dùng khi mẫu mới hoạt động không mong muốn trong quá trình sản xuất. Kiểm tra điều này trước khi triển khai.

Cách tiếp cận yếu/Cách tiếp cận mạnh mẽ

Yếu: "Mô hình này đã thử nghiệm tốt, chúng tôi đã đưa nó vào hoạt động, chúng tôi đã mở nó cho tất cả mọi người."

Güçlü: "Chúng tôi đã chứa mô hình, gắn nhãn nó là một phiên bản. Đầu tiên, chúng tôi chạy nó ở chế độ tối với lưu lượng sản xuất trong 3 ngày, so sánh dự đoán với mô hình cũ — độ lệch có thể chấp nhận được. Sau đó, chúng tôi mở mô hình với 5% canary, theo dõi số liệu thông lượng và độ trễ. Khi không có vấn đề gì, chúng tôi tăng dần lên 100%. Chúng tôi đã thử nghiệm lệnh khôi phục trước đó."

Sự khác biệt: cách tiếp cận mạnh mẽ là dần dần, đo lường và có thể đảo ngược. Rủi ro được hạn chế ở mọi bước.

CI/CD và tự động hóa

CI/CD (Tích hợp liên tục / Triển khai liên tục: quy trình tự động kiểm tra và phát hành các thay đổi mã) trong ML không chỉ bao gồm mã mà còn cả các bước dữ liệu và mô hình. Quy trình ML CI/CD tốt: chạy thử nghiệm khi mã thay đổi, thực hiện xác thực dữ liệu, đào tạo lại mô hình (nếu cần), kiểm tra ngưỡng đánh giá và chỉ tiến hành triển khai nếu ngưỡng được giữ nguyên. Nguyên tắc “đào tạo tự động, triển khai theo ngưỡng” giúp mô hình xấu không thể âm thầm rò rỉ vào sản xuất.

AI rất hữu ích khi thiết lập các quy trình này: viết bản nháp tệp cấu hình (YAML), trường hợp thử nghiệm, tập lệnh triển khai. Nhưng bạn xác định ngưỡng phân phối (bất kỳ số liệu nào vượt quá giá trị được công bố) và chính sách khôi phục; đây là những quyết định rủi ro kinh doanh.

Cơ sở hạ tầng tái tạo

Để tái tạo hành vi của một mô hình trong sản xuất, sổ đăng ký mô hình: một bản ghi lưu giữ mô hình nào đã được đào tạo với dữ liệu và mã nào cũng như số liệu nào nó nhận được. Đối với mỗi mô hình sản xuất, những thông tin sau cần được theo dõi: phiên bản dữ liệu huấn luyện, phiên bản mã (git commit), siêu tham số, điểm đánh giá và ngày triển khai. Khi có vấn đề phát sinh, bạn sẽ có thể trả lời câu hỏi "mô hình nào đưa ra dự đoán này, với dữ liệu nào?" trong vòng vài phút. Chúng ta sẽ đào sâu vấn đề này ở bài 11.

ba trường hợp nhỏ

Trường hợp 1 - Vấn đề do phân phối bóng. Một mô hình đề xuất đã đánh bại mô hình cũ trong quá trình thử nghiệm. Người ta nhận thấy việc chạy nó với lưu lượng sản xuất ở chế độ tối tạo ra đề xuất rất kém cho một phân khúc người dùng cụ thể (người dùng mới) — dữ liệu thử nghiệm không thể hiện đầy đủ phân khúc này. Mô hình đã được sửa mà không bao giờ được hiển thị cho người dùng. Nếu nó được mở trực tiếp, trải nghiệm người dùng mới sẽ bị gián đoạn.

Trường hợp 2 - Phân phối không thể hủy bỏ. Một nhóm đã triển khai mô hình định giá mới cho tất cả lưu lượng truy cập mà không có kế hoạch khôi phục. Người mẫu bất ngờ định giá một số sản phẩm rất rẻ. Việc hoàn nguyên về phiên bản cũ mất hàng giờ vì quá trình này chưa sẵn sàng. Đã có sự mất mát nghiêm trọng về thu nhập. Sau đó, thử nghiệm khôi phục bắt buộc đã được thêm vào mỗi lần triển khai.

Trường hợp 3 - Dữ liệu trôi dạt im lặng. Một mô hình lừa đảo xuất hiện trong nhiều tháng mà không có bất kỳ sai sót nào. Nhưng chiến thuật của những kẻ lừa đảo đã thay đổi (dữ liệu trôi dạt) và khả năng thu hồi mô hình đã âm thầm giảm xuống. Không ai để ý vì không có sự giám sát. Sau khi ban giám sát phân phối dự báo được thành lập, sự trôi dạt đã sớm lộ rõ. Chúng ta sẽ đề cập đến việc giám sát ở bài 8.

Mẫu có thể sao chép

Viết dự thảo kế hoạch triển khai cho mô hình này. Mô hình: [nó làm gì], cách sử dụng: [trực tuyến hay theo đợt?] Nên bao gồm:1) Đóng gói (vùng chứa, phiên bản)2) Chiến lược triển khai gia tăng (bóng tối/canary/A-B) và lý do3) Số liệu cần theo dõi (kinh doanh + kỹ thuật + độ trễ)4) Kế hoạch khôi phục và cách kiểm tra5) Ngưỡng triển khai (số liệu nào sẽ vượt quá giá trị nào)

Kiểm tra đường dẫn ML CI/CD này:1) Có xác thực dữ liệu trong dòng không?2) Việc triển khai có thể tiếp tục mà không cần giữ ngưỡng đánh giá (không nên)?3) Việc khôi phục có tự động không?4) Dữ liệu+mã+số liệu có được theo dõi trong sổ đăng ký mô hình không? Cấu hình Pline: [config]

Hãy giúp tôi quyết định xem trình bày trực tuyến hay hàng loạt phù hợp với mô hình này. Kết quả sẽ được sử dụng trong bao lâu: [tức thì / phút / giờ / ngày] Khối lượng yêu cầu dự kiến: [number] Có hạn chế về độ trễ không: [ms]Bạn muốn đề xuất cái nào về mặt chi phí và độ phức tạp và tại sao?

Viết quy trình khôi phục cho mô hình này.- Số liệu/ngưỡng nào gây ra hiệu suất kém? - Các bước khôi phục là gì?- Quá trình khôi phục sẽ mất bao lâu (mục tiêu)?- Làm cách nào để kiểm tra quy trình này trước khi sản xuất?

Bảng mẫu trình bày

tiêu chí

Trực tuyến (thời gian thực)

sự chậm trễ

Quan trọng (ms)

không đáng kể

Cách sử dụng

Cần phản hồi ngay lập tức

Điểm định kỳ

Chi phí

cao

thấp

sự phức tạp

cao

thấp

ví dụ

Khuyến nghị trực tiếp, lừa đảo

Điểm rủi ro hàng tháng

Những lỗi thường gặp

  • Phân phối mà không có kế hoạch thu hồi. Mô hình sai ảnh hưởng đến toàn bộ người dùng.
  • Mở cửa trực tiếp cho 100% lưu lượng truy cập. Hạn chế rủi ro với phân phối so le.
  • Không thiết lập giám sát. Mô hình tạo ra lỗi một cách âm thầm, không có lỗi.
  • Trình bày thời gian thực dư thừa. Trong khi phân khối là đủ, chi phí và độ phức tạp sẽ tăng lên.
  • Không liên kết các phiên bản mã dữ liệu mô hình. Bạn không thể tái tạo vấn đề.
  • Phát hành tự động không có ngưỡng phân phối. Người mẫu xấu âm thầm lẻn vào.

Tóm lại

Chuyển mô hình sang sản xuất là một nhiệm vụ kỹ thuật khác và thường khó khăn hơn so với việc đào tạo nó. ML yêu cầu kỷ luật cao hơn vì nó phụ thuộc vào bộ ba mô hình dữ liệu mã: đóng gói và lập phiên bản, mẫu phân phối (trực tuyến/lô) phù hợp với nhu cầu kinh doanh, triển khai dần dần và có thể đảo ngược, CI/CD được kiểm soát theo ngưỡng và đăng ký mô hình. Trí tuệ nhân tạo là một công cụ hỗ trợ đắc lực trong việc tạo mã và cấu hình của cơ sở hạ tầng này; nhưng ngưỡng phân phối, chính sách thu hồi và quyết định rủi ro là của bạn. Việc phân phối không có kế hoạch khôi phục sẽ không hoàn tất.

Nhiệm vụ ứng dụng

Chứa (Docker) một mô hình và gắn nhãn phiên bản cho nó. Quyết định xem bạn sẽ cung cấp trực tuyến hay hàng loạt dựa trên nhu cầu kinh doanh của bạn và viết lời biện minh của bạn. Ghi lại kế hoạch triển khai theo từng giai đoạn (bóng tối hoặc hoàng yến) và quy trình khôi phục đã được thử nghiệm. Đảm bảo ghi lại phiên bản dữ liệu, cam kết mã và điểm đánh giá trong sổ đăng ký mô hình.

danh sách kiểm tra

  • [ ] Mô hình được đóng gói và tạo phiên bản (vùng chứa + nhãn).
  • [ ] Mẫu trình bày (trực tuyến/đợt) được chọn theo nhu cầu kinh doanh.
  • [ ] Chiến lược triển khai theo giai đoạn (bóng tối/chim hoàng yến) đã được triển khai.
  • [ ] Thủ tục khôi phục được viết và thử nghiệm.
  • [ ] CI/CD không tiến hành triển khai trước khi đáp ứng ngưỡng đánh giá.
  • [ ] Sổ đăng ký mô hình chứa liên kết dữ liệu+mã+số liệu.