AI doanh nghiệp đã có sự chuyển dịch. Vài năm trước, việc thuyết phục ban lãnh đạo thậm chí chỉ để thử nghiệm học máy (machine learning) đã là một cuộc chiến đầy cam go. Giờ đây, ngân sách đã sẵn có. Các dự án thí điểm được phê duyệt. Các trường hợp sử dụng chất đống trên lộ trình phát triển. Tuy nhiên, quá nhiều dự án trong số này kết thúc như những cuộc thử nghiệm tốn kém mà không bao giờ thay đổi được cách thức vận hành thực tế của doanh nghiệp. Các mô hình thì không vấn đề gì. Vấn đề nằm ở mọi thứ khác.
Nơi các dự án thí điểm "chết yểu"
Ai cũng thích xem demo. Bản mẫu dự đoán tỷ lệ rời bỏ khách hàng với độ chính xác đáng kinh ngạc. Ban lãnh đạo gật đầu. Nguồn vốn đổ về. Rồi sau đó là sự im lặng. Bản thử nghiệm khái niệm (PoC) được phê duyệt, nhưng tiến độ bị đình trệ. Chuyện gì đã xảy ra?
Các nhóm kinh doanh nhìn chằm chằm vào bảng điều khiển và không thể hiểu làm thế nào để nó khớp với quy trình làm việc hàng ngày của họ. Luồng dữ liệu cung cấp cho mô hình là một bản trích xuất thủ công nhất thời mà không ai chịu trách nhiệm quản lý. Các quy định tuân thủ thay đổi giữa chừng. Hệ thống yêu cầu dữ liệu đầu vào sạch mà CRM chưa bao giờ tạo ra. AI hoạt động tốt trong notebook. Nhưng tổ chức lại không biết phải làm gì với nó.
Đây là một thất bại trong việc triển khai. Một mô hình đạt độ chính xác 95% có thể thắng một cuộc thi hackathon. Nhưng nếu 5% còn lại gây ra những cơn ác mộng về kiểm toán hoặc vi phạm an toàn, bộ phận vận hành sẽ đóng nó lại. Các kỹ sư ăn mừng các cột mốc kỹ thuật. Các đơn vị kinh doanh chờ đợi những kết quả không bao giờ tới. Khoảng cách giữa hai bên chính là nơi các dự án chết yểu.
Khoảng cách về sự thấu hiểu
Hãy gọi đúng tên của nó. Các giám đốc điều hành muốn tăng trưởng doanh thu hoặc giảm chi phí. Bộ phận vận hành muốn tốc độ mà không gây ra sự hỗn loạn. Các nhóm dữ liệu muốn các lược đồ (schemas) hợp lý. Các kỹ sư muốn thời gian hoạt động (uptime) và các API sạch. Không có mong muốn nào trong số này tự nhiên mà khớp với nhau.
Nếu để mặc, mỗi nhóm sẽ tối ưu hóa cho những thứ khác nhau. Một kỹ sư có thể dành hàng tuần để giảm độ trễ của một endpoint dự đoán, trong khi nhóm bán hàng vẫn xuất mọi thứ ra Excel vì giao diện người dùng (UI) gây khó hiểu cho họ. Một nhà khoa học dữ liệu có thể ám ảnh với chữ số thập phân thứ tư của AUC, trong khi nhóm kho bãi đã ghi nhận các giá trị null trong một trường dữ liệu quan trọng suốt sáu tháng qua. Không ai sai cả. Họ chỉ đang nói những ngôn ngữ khác nhau.
Sự thiếu đồng nhất này là lý do lớn nhất khiến AI bị đình trệ sau giai đoạn thí điểm. Đó không phải là do thiếu hụt GPU. Đó không phải là do thiếu các tiến sĩ. Đó là sự thiếu vắng một người có thể đứng giữa các nhóm này và xây dựng một thực tế chung.
Các Forward Deployed Engineers thực sự làm gì
Forward Deployed Engineers chính là chiếc cầu nối đó. Họ không thay thế các nhà khoa học dữ liệu hay kỹ sư nền tảng của bạn. Họ làm việc xuyên suốt các nhóm kinh doanh, kỹ thuật, dữ liệu và sản phẩm để khắc phục những ma sát trong tổ chức vốn sẽ giết chết công nghệ trước khi nó kịp được triển khai.
Khi một FDE tham gia vào một dự án, họ bắt đầu bằng cách đặt ra những câu hỏi gây khó chịu. Một buổi sáng thứ Ba thành công sẽ trông như thế nào đối với người sử dụng công cụ này? Ba hệ thống cũ nào thực sự cung cấp luồng dữ liệu này? Điều gì sẽ xảy ra với quy trình nếu mô hình sai? Họ chuyển đổi các câu trả lời thành các quyết định kỹ thuật để các nhóm không lãng phí hàng tháng trời xây dựng sai giải pháp.
Trong một dự án điển hình, một FDE sẽ:
- Làm rõ các mục tiêu với các bên liên quan thay vì chấp nhận những chỉ thị mơ hồ
- Đi thực tế tại hiện trường quy trình để tìm ra các nút