Sổ tay tương tác, chẳng hạn như jupyter, rất cần thiết cho sự phát triển trí tuệ nhân tạo/máy học (AI/ML), nhưng lại không phù hợp với môi trường sản xuất. Do đó, việc chuyển đổi sổ ghi chép thành một hệ thống phần mềm được thiết kế tốt là một bước bắt buộc trong mọi dự án ML. Nhưng đáng chú ý là thiếu công cụ để hỗ trợ các nhà phát triển với bản dịch như vậy, ngoài bản dịch cơ bản nbconvert tiện ích. 

Ngay cả trước khi Jupyter được phát triển, các nhà toán học, nhà nghiên cứu và nhà phân tích đã sử dụng môi trường phát triển tương tác “kiểu sổ tay” (ví dụ: Toán học). Để khám phá dữ liệu và phân tích thống kê, phản hồi và trực quan hóa ngay lập tức là điều cần thiết để biết liệu một quy trình công việc nhất định có dẫn đến một mô hình hoạt động hay không. 

Có ba vấn đề mà các nhà khoa học dữ liệu thường gặp phải khi cố gắng chuyển từ mô hình sang nguyên mẫu ML sẵn sàng sản xuất:

1. Chạy mã ML theo các khoảng thời gian được lên lịch thông thường (dịch vụ cron) hoặc dịch vụ web linh hoạt và có thể mở rộng; 
2. Áp dụng mã cho các bộ dữ liệu lớn hơn không vừa với một nút máy tính (điện toán phân tán) liền mạch trong sổ ghi chép; Và 
3. Tìm các tính năng tiện lợi của IDE phù hợp để phát triển các cơ sở mã lớn. Bản thân Jupyter thiếu nhiều “tiện nghi sinh vật” của các IDE thân thiện với sự phát triển hiện đại.

Một làn sóng lớn các công cụ gần đây đã xuất hiện để giải quyết những lo ngại này – từ sổ ghi chép thay thế Jupyter mạnh mẽ như Ghi chú sâu và Hex; lập lịch cron như Xưởng làm giấy; và các thiết lập đám mây đầy đủ dịch vụ như Databricks. Tuy nhiên, tất cả những công cụ này đều có một điểm chung: chúng được xây dựng xung quanh sổ ghi chép và hỗ trợ sử dụng sổ ghi chép trong cài đặt sản xuất. Khi sử dụng bất kỳ công cụ nào trong số này, bạn sẽ gặp phải hai vấn đề: 1.) cấu trúc mã trong sổ ghi chép giống nhau (thường là “mã spaghetti” khó bảo trì) và 2.) môi trường mà sổ ghi chép được lên lịch chạy trong đó là nhân sổ ghi chép (trình thông dịch ngôn ngữ lập trình được tối ưu hóa cho khả năng tương tác của nhà phát triển thay vì hiệu quả thời gian chạy). 

Mặc dù trình thông dịch mã tương tác vô cùng hữu ích cho việc phân tích dữ liệu khám phá (EDA) và báo cáo, nhưng chúng không phù hợp với mã sản xuất chất lượng vì một số lý do:

1. Không có khai thác kiểm tra;
2. Máy tính xách tay không khuyến khích mô-đun hóa và khuyến khích viết kịch bản spaghetti;

Lưu ý: Trong khi bạn có thể về mặt kỹ thuật nhập mọi thứ_else trong một tế bào và phát triển trong Everything_else.py, điều này a) hiếm khi được thực hiện trong thực tế và b) khiến việc lặp lại sổ tay ban đầu với các sơ đồ và bảng phù hợp với EDA trở nên khó khăn hơn. 

1. Khả năng chịu lỗi: Nếu một phần (chức năng, ví dụ) của sổ ghi chép bị lỗi hoặc máy tính khởi động lại, các nhà khoa học dữ liệu cần có khả năng tiếp tục công việc từ điểm dừng cuối cùng so với bắt đầu lại từ đầu. Các công cụ như Airflow/Luigi tồn tại vì lý do này;
2. Xử lý nhiều yêu cầu đến hơn (tỷ lệ theo chiều ngang khác với khả năng mở rộng do Spark cung cấp); Và 

Lưu ý: Người ta có thể xây dựng một dịch vụ web có thể mở rộng xung quanh sổ ghi chép (ví dụ: https://www.qwak.ai), nhưng trên thực tế, đó là điều mà các nhà khoa học dữ liệu thường yêu cầu các kỹ sư giúp thực hiện. 

1. Đánh giá mã và lập phiên bản cho sổ ghi chép là vấn đề. Hỗ trợ IDE ngày càng tốt hơn nhưng vẫn không tốt bằng mã “bình thường”.

Nhưng có lẽ thách thức lớn nhất cần vượt qua là khoảng cách ngày càng lớn giữa khoa học dữ liệu và phần còn lại của hệ thống doanh nghiệp. Ví dụ: nhóm công nghệ tiếp thị điển hình sẽ được duy trì bởi nhóm kỹ sư của chính nó, khiến khoa học dữ liệu trở thành mắt xích yếu nhất.   

Chúng ta cần giảm tắc nghẽn quy trình làm việc và giúp khoa học dữ liệu nhận ra tiềm năng đầy đủ của dữ liệu 

Chúng ta cần tách biệt rõ ràng giữa môi trường phát triển khoa học dữ liệu và ngăn xếp sản xuất để giải quyết thỏa đáng các lĩnh vực quan tâm tương ứng. Các công cụ hiện có cố gắng thực hiện cả hai đã được chứng minh là chỉ thỏa hiệp với cả hai môi trường. Yêu cầu các nhà khoa học dữ liệu chú ý hơn đến các mối quan tâm kỹ thuật trong quá trình phát triển sẽ làm giảm đáng kể năng suất của quy trình làm việc. Và việc thay đổi cơ bản cách thức hoạt động của khoa học dữ liệu là không thực tế. Vì vậy, câu hỏi đặt ra là: có thể thu hẹp khoảng cách bằng một công cụ duy nhất không? 

LineaPy cũng là một trong những công cụ mới xuất hiện gần đây nhưng được xây dựng với sự chú ý đặc biệt đến khoảng cách công cụ này. Nó cung cấp cho các nhà khoa học dữ liệu một cách để làm việc chính xác như hiện tại, đồng thời gặt hái những lợi ích của 'công cụ' kỹ thuật tốt đi kèm với ngăn xếp sản xuất. LineaPy không cố gắng thay đổi khoa học dữ liệu hoặc môi trường ngăn xếp sản xuất, mà cố gắng hoạt động như một cầu nối rất cần thiết (Nó có thể được sử dụng trong các môi trường máy tính tương tác như Jupyter Notebook/Lab hoặc IPython). 

Sự tồn tại của một công cụ như LineaPy cho thấy rằng có thể tôn trọng sự tách biệt giữa các mối quan tâm trong khi vẫn thu hẹp khoảng cách giữa phát triển và sản xuất. Nói chung, chúng ta nên tránh gian lận bồi thẩm đoàn các công cụ hiện có phục vụ các mục đích được xác định rõ ràng để làm việc khác. Khi chúng ta làm điều này, chúng ta tạo ra nhiều sự thất vọng hơn là những vấn đề mà chúng ta đang giải quyết.
 
 
Mike Arov là kỹ sư máy học chính tại PostClick, một giải pháp hàng đầu cho chuyển đổi quảng cáo kỹ thuật số.