Tác giả: Alden Do Rosario
Với sự rối ren lớn xung quanh OpenAI vài ngày trước đó, nhiều chuyên gia và doanh nghiệp đang đặt ra câu hỏi:
Liệu bạn có nên có một Kế hoạch B, chỉ đơn giản là để đối mặt với mọi khả năng xảy ra?
“Cuộc biến động quản lý gần đây tại OpenAI có ý nghĩa lớn, và chúng tôi không có độ tin cậy rằng tình hình đã ổn định hoàn toàn” – Báo cáo GAI Insights.
Đối với những người tham gia vào các trường hợp sử dụng doanh nghiệp sản xuất, điều này đã là một điều hiển nhiên từ Ngày 1.
Bởi vì chúng tôi đã phải thích nghi với các vấn đề gặp phải không đều như OpenAI API tạm thời bị tắt hoặc gặp vấn đề về giới hạn tần suất.
Sự đàn hồi cơ bản trong hệ thống của bạn sử dụng OpenAI API gần như là điều dễ dàng nếu bạn đang sử dụng nó cho bất kỳ trường hợp sử dụng sản xuất nào.
Bây giờ, doanh nghiệp phải xem xét các tình huống tận thế lớn hơn nhiều mà ai đó có thể chẳng bao giờ nghĩ đến.
Trong bài đăng blog này, tôi muốn đề cập đến bốn cấp độ của các kịch bản tận thế và thời gian chết, mà luôn có lợi ích khi có chiến lược dự phòng.
Vì vậy, không chần chừ nữa, hãy bắt đầu.
Kịch bản 1: OpenAI API Tạm Thời Tắt.
Về vấn đề này, hầu hết chúng ta đã quen thuộc, cho dù đó là API tạm thời bị tắt trong vài giờ hoặc trong một số trường hợp bị giới hạn về tần suất.
Và đây gần như là điều cơ bản để lập kế hoạch và kiểm soát cho vấn đề này.
Làm thế nào để Lập Kế Hoạch và Kiểm Soát Điều Này?
Cách tốt nhất là có chiến lược dự phòng đối với các nhà cung cấp OpenAI khác như Microsoft Azure.
Nếu bạn đã lưu trữ trên Microsoft Azure, bạn có thể triển khai đa khu vực và bảo vệ mình khỏi bất kỳ vấn đề tạm thời và gián đoạn nào.
Điều này gần như giống như cân bằng tải và chiến lược dự phòng cổ điển mà những người trong thế giới DevOps đã quen thuộc rất nhiều.
Tình huống tương tự có thể xảy ra với vấn đề giới hạn tần suất, nơi nhiều triển khai Azure có thể được cân bằng tải nhanh chóng để giảm nhẹ vấn đề giới hạn tần suất.
Tôi đã thấy một số nhà phát triển sử dụng nhiều tài khoản OpenAI để vượt qua vấn đề giới hạn tần suất – nhưng chiến lược cân bằng tải Azure OpenAI sẽ được coi là tốt hơn (và nằm trong các điều khoản và điều kiện!)..
Kịch bản 2: Mô Hình OpenAI Bị Ngừng Phục Vụ Vĩnh Viễn.
Đây là một tình huống ít người mong đợi, nhưng hoàn toàn có khả năng xảy ra. OpenAI gần như giống như một phòng thí nghiệm nghiên cứu, và họ không có nghĩa vụ tạo ra các mô hình lâu dài.
Thực tế, họ rất rõ ràng về việc hầu hết các sản phẩm đều ở dạng alpha hoặc beta. Và họ không giả tạo về điều này.
Ví dụ, chúng tôi đã đầu tư một lượng nguồn lực đáng kể vào việc tạo ra các sản phẩm dựa trên tính năng ChatGPT Plugins. Và hiện nay, có khả năng cao rằng tính năng plugin sẽ bị ngừng phục vụ vĩnh viễn.
Hiện tại, có khả năng kỹ thuật rằng một số tính năng cao cấp từ OpenAI mà sản phẩm của bạn phụ thuộc vào có thể quietly biến mất trong các phiên bản sau này. Có thể rằng tính năng đó không phổ biến hoặc quá đắt để chạy và có thể đơn giản bị ngừng phục vụ.
Làm thế nào để Lập Kế Hoạch và Kiểm Soát Điều Này?
Nếu có thể, hãy có một số chiến lược dự phòng cho mô hình nếu nó biến mất.
Ví dụ, nếu bạn đang phụ thuộc vào ChatGPT-4, hãy tích hợp hỗ trợ cho Llama-2 vào hệ thống của bạn.
Mặc dù nó có thể không có hiệu suất giống như ChatGPT-4, nhưng nó có thể là một mô hình thay thế trong hệ thống của bạn.
Thực tế, một số khách hàng thậm chí có thể muốn mô hình dự phòng đó cụ thể. Ví dụ, khi chúng tôi triển khai Llama-2 như một chiến lược dự phòng trong nền tảng của mình, một số khách hàng muốn nó làm tùy chọn chính do tỷ lệ giá/hiệu suất của nó.
Gợi ý: Llama-2 là một trong những mô hình tốt nhất – theo tỷ lệ đô la – cho quyết định LLM!
Kịch bản 3: OpenAI — Công ty — Biến Mất.
Khi tình hình rối loạn xung quanh OpenAI và drama về Ban Giám đốc diễn ra, một trong những nỗi sợ là:
Liệu OpenAI có thể biến mất như một công ty?
Điều này chắc chắn nghe có vẻ rất khả thi, nhưng chúng ta đã thấy một số tình huống tương tự ngoạn mục. Trong thực tế, ngay trong năm 2022, chúng ta đã có một tình huống như vậy (Tôi không cần phải nói bạn biết cái nào!)
Điều gì sẽ xảy ra trong hệ thống của bạn nếu api.openai.com chính nó trả về một lỗi “404 – Không Tìm Thấy”?
Làm thế nào để Lập Kế Hoạch và Kiểm Soát Điều Này?
Điều này tương tự như Kịch bản 2 nơi mô hình chính nó biến mất. Và tôi giả định rằng một chiến lược dự phòng nào đó như sử dụng Microsoft Azure OpenAI sẽ là một bước khởi đầu tốt.
Microsoft có lịch sử làm việc với các Doanh nghiệp. Vì vậy, không có cách nào họ sẽ không hỗ trợ một sự chuyển giao trơn tru cho bất kỳ tình huống tận thế nào như vậy.
Kịch bản 4: GPT-4 Bị Cấm
Một lần nữa, đây có lẽ là một trong những sự kiện ít khả thi nhất, nhưng không bao giờ nói không bao giờ. (Đây là lý do Tại Sao OpenAI bị cấm!)
Trong tình huống này, sản phẩm của bạn có thể kỹ thuật có thể phụ thuộc vào một số tính năng có thể bị cấm theo luật pháp của chính phủ hoặc các biện pháp bảo vệ và rào cản khác
Sau đó, chiến lược dự phòng của bạn sẽ là gì?
Làm thế nào để Lập Kế Hoạch và Kiểm Soát Điều Này?
Một lựa chọn có thể là một LLM tự lưu trữ.
Nhưng câu trả lời chính xác cho điều này có thể rất cụ thể đối với trường hợp sử dụng của bạn và mọi người cần những câu trả lời khác nhau cho điều này.
Bây giờ có lẽ là thời điểm tốt để xem xét ứng dụng của bạn và xem liệu có bất kỳ tính năng cụ thể nào có thể bị cấm không.
Kết luận
Tôi chắc chắn rằng mọi người có thể nghĩ đến các tình huống khác mà họ nên lập kế hoạch. Việc lập kế hoạch “giảm rủi ro” này gần như giống như việc mua bảo hiểm.
Và nhiều điều này rất cụ thể cho ứng dụng và việc sử dụng sản xuất cụ thể của bạn.
Bạn có thể không cần lập kế hoạch cho TẤT CẢ hoặc thậm chí là BẤT KỲ trong số những kịch bản này. Nhưng những người làm DevOps và MLOps rất quen thuộc với những tình huống như vậy.
Khi Trí tuệ Nhân tạo sinh sản được triển khai vào các trường hợp sử dụng sản xuất, các bên liên quan sẽ hỏi về khả năng chịu đựng.
Giống như “thời gian chết máy chủ”, chúng ta sẽ cần chuẩn bị cho khả năng chịu đựng của Trí tuệ Nhân tạo.
Và OpenAI vừa mới đánh thức cả thế giới với tình huống đó.
Nếu bạn đã xây dựng ứng dụng Trí tuệ Nhân tạo riêng của mình, bạn đã thực hiện những kế hoạch dự phòng nào trong hệ thống của mình?
Và quan trọng hơn, nếu bạn đã mua ứng dụng Trí tuệ Nhân tạo từ các nhà cung cấp, họ có thực hiện những kế hoạch dự phòng như vậy trong hệ thống của họ không? Đó là một câu hỏi quan trọng để đặt ra.
Kế hoạch B của bạn là gì?
