Tại sao các phi công AI của bạn vẫn bị tắc trước khi giao hàng?
Các phi công AI không bao giờ được đưa vào sản xuất tiêu tốn nhiều hơn ngân sách của họ. Đây là chi phí thực tế và cách ngừng vòng lặp này.
Hầu hết các công ty thử nghiệm AI đều có một khu nghĩa trang
Đó là một thư mục chứa các bản trình bày, vài kênh Slack bị bỏ hoang, và ba hoặc bốn dự án thử nghiệm hoạt động tốt trong demo nhưng sau đó ngừng hoạt động một cách im lặng. Không ai đã giết chúng. Chúng chỉ chưa bao giờ vượt qua ranh giới để trở thành công việc hàng ngày.
Câu chuyện thoải mái là những dự án thử nghiệm này rẻ tiền, nên tổn thất không lớn. Nhưng câu chuyện này sai lầm. Một dự án thử nghiệm không được đưa vào sản xuất sẽ tốn kém hơn nhiều so với hóa đơn xây dựng nó, và những chi phí lớn nhất hoàn toàn không xuất hiện trên hóa đơn.
Chi phí thực tế mà một dự án thử nghiệm tiêu thụ
Bắt đầu từ những gì bạn có thể đếm được. Một dự án thử nghiệm tiêu thụ thời gian của kỹ sư, phí của nhà cung cấp, và sự chú ý của những người đồng ý thử nghiệm nó. Nhưng những người thử nghiệm một dự án thử nghiệm thường không phải là nguồn lực dư thừa. Họ thường là những nhân viên mạnh nhất vì họ hiểu rõ quy trình đến mức có thể đánh giá xem AI có giúp được hay không. Mỗi giờ họ dành để đánh giá một công cụ không đưa ra sản phẩm là một giờ lấy đi từ công việc mà chỉ họ mới làm được.
Sau đó là công việc xử lý dữ liệu. Hầu hết các dự án thử nghiệm nghiêm túc yêu cầu ai đó làm sạch hồ sơ, gắn nhãn ví dụ, hoặc kết nối với hệ thống trực tiếp. Công sức này thực sự và bền vững - nhưng chỉ nếu dự án thử nghiệm thành công. Khi nó ngừng hoạt động, dữ liệu đã được làm sạch sẽ trở nên lỗi thời và tích hợp bị tắt. Bạn đã trả tiền để xây dựng một tài sản rồi lại để nó hết hạn.
Chi phí không xuất hiện trên bảng tính
Phần đắt đỏ nhất là những gì một dự án thử nghiệm ngừng hoạt động gây ra cho mọi người theo dõi nó.
Nạn nhân đầu tiên là uy tín. Khi một công cụ hứa hẹn được trình bày cho đội ngũ rồi biến mất, mọi người học được rằng các dự án AI chỉ là màn trình diễn. Lần tiếp theo bạn đề xuất một dự án, những nhân viên mạnh nhất - chính là những người bạn cần - sẽ từ chối tham gia vì họ đã chứng kiến kết cục này. Bạn không bắt đầu dự án thử nghiệm mới từ con số không. Bạn bắt đầu nó từ dưới không, chống lại sự hoài nghi mà chính bạn tạo ra.
Nạn nhân thứ hai là thời gian. Trong khi dự án thử nghiệm của bạn bị kẹt trong tình trạng đánh giá, các mô hình cơ bản vẫn được cải thiện và đối thủ cạnh tranh tiếp tục đưa sản phẩm ra thị trường. Lợi thế mà bạn hy vọng sẽ nắm bắt chỉ tồn tại trong demo. Nó nằm ở những tháng ngày tích lũy học hỏi chỉ bắt đầu khi hệ thống thực sự phụ thuộc vào người dùng. Một dự án thử nghiệm không bao giờ được đưa vào sản xuất sẽ không mang lại cho bạn điều đó.
Lý do các dự án thử nghiệm bị đình trệ
Các dự án thử nghiệm hiếm khi thất bại vì công nghệ không hoạt động. Chúng bị đình trệ vì những vấn đề tồn tại ngay từ trước khi viết một dòng mã:
- Không có chủ sở hữu có quyền đưa vào sản xuất. Một dự án thử nghiệm được tài trợ bởi "khai sáng" nhưng không phải bởi đội ngũ sẽ vận hành nó không có con đường nào đến sản xuất.
- Thành công chưa bao giờ được xác định rõ ràng. Nếu không ai đồng ý trước về kết quả nào sẽ chứng minh sự thành công, mọi kết quả đều trông ấn tượng và khiến mọi người muốn tiếp tục khám phá.
- Phần cuối cùng bị bỏ qua. Quyền truy cập, giám sát, xử lý lỗi và hỗ trợ được coi là những việc sau này, vì vậy một nguyên mẫu hoạt động vẫn còn nhiều tháng mới an toàn để sử dụng.
- Dự án thử nghiệm chỉ giải quyết vấn đề trong demo. Nó xử lý tốt trường hợp đơn giản và bỏ qua 30% dữ liệu bẩn thỉu chiếm phần lớn công việc thực tế.
Lưu ý rằng không có vấn đề nào trong số này là vấn đề về mô hình. Chúng là những quyết định về quyền sở hữu, phạm vi và cam kết - được đưa ra ngay từ đầu.
Thực hiện các dự án thử nghiệm như thể chúng sẽ được đưa vào sản xuất
Giải pháp là ngừng coi một dự án thử nghiệm như một câu hỏi về công nghệ và bắt đầu xem nó như giai đoạn đầu tiên của quá trình sản xuất. Trước khi bắt đầu, hãy chỉ rõ người sẽ sở hữu công cụ trong môi trường sản xuất và cho họ quyền phủ quyết. Viết ra con số duy nhất sẽ kích hoạt việc đưa vào sử dụng và con số sẽ kích hoạt việc ngừng hoạt động sạch sẽ. Đưa các công việc cuối cùng - truy cập, giám sát, xử lý lỗi khi mô hình sai - vào phạm vi dự án thử nghiệm, chứ không phải sau nó. Chọn một luồng công việc thực tế với khối lượng thực tế, thay vì một màn trình diễn.
Điều này sẽ chậm lại quá trình khởi động, và đó chính là ý nghĩa của nó. Một số ít các dự án thử nghiệm được xây dựng để đưa vào sản xuất sẽ vượt trội so với một đường ống bận rộn các thí nghiệm không bao giờ rời khỏi phòng thí nghiệm, cả về kết quả và sự tin tưởng bạn giữ với đội ngũ của mình.
Tại Hercules A, đây là điều đầu tiên chúng tôi tìm kiếm khi nỗ lực AI của khách hàng bị đình trệ - không phải một mô hình tốt hơn, mà là thiếu chủ sở hữu và đường biên hoàn thành chưa được xác định. Công nghệ hiếm khi là điểm nghẽn.
Một dự án thử nghiệm không thành công vì nó hoạt động tốt. Nó thành công vì mọi người bắt đầu phụ thuộc vào nó và sẽ nhận thấy nếu nó biến mất. Bất cứ điều gì ngắn hơn cũng là một chi phí bạn đã trả và chưa tính toán.