Low-code là sự cường điệu mới nhất và mọi người dường như háo hức nhảy vào cuộc sau những con số đầy hứa hẹn do Gartner và Forrester đưa ra. Mã thấp được trình bày như là thứ cuối cùng, tất cả trong thế giới phát triển, mang theo những tiêu đề dụ nhấp chuột này chẳng hạn như “Thời đại mã hóa sắp kết thúc”. Điều này luôn khiến tôi cười thầm một chút, bởi vì bạn nghĩ ai đang mã hóa những nền tảng mã thấp đó?
Đừng hiểu sai ý tôi, các nền tảng mã nguồn thấp rất hứa hẹn và mở ra nhiều cơ hội mới, nhưng chúng cũng có những hạn chế riêng.
Khi bạn xem xét điểm mạnh và điểm yếu của các nền tảng mã thấp hoặc thậm chí không có mã, bạn thực sự thấy rõ rằng bản thân chúng không phù hợp với các trường hợp sử dụng AI.
Trong bài viết này, tôi sẽ giải thích cho bạn lý do tôi nói điều này. Tuy nhiên, tôi không muốn làm ảnh hưởng quá nhiều đến cuộc diễu hành của bạn và tôi sẽ đưa ra một số đề xuất về cách bạn có thể tận dụng sức mạnh của nền tảng mã nguồn ngắn, đồng thời chọn công cụ phù hợp cho trường hợp sử dụng AI của mình. Nhưng trước tiên, hãy đi sâu vào lịch sử của low-code một chút và điều gì đã cho phép chúng trở nên phổ biến như hiện tại.
Lịch sử của mã thấp
Một trong những lý do chính khiến tôi chắc chắn rằng nền tảng mã thấp không phải là giải pháp hoàn hảo sẽ khiến các nhà phát triển và nhà khoa học dữ liệu trở nên không cần thiết là vì thực tế nó không phải là mới.
Thuật ngữ mã thấp có thể được một nhà phân tích của Forrester đặt ra lần đầu tiên vào năm 2014, nhưng nguồn gốc của nó bắt nguồn từ việc lập trình luồng dữ liệu vào những năm 60. Năm 1966, Bert Sutherland xuất bản luận án tiến sĩ mang tên “Đặc tả đồ họa trực tuyến của quy trình máy tính” trong đó ông đã trình bày một trong những khung lập trình luồng dữ liệu đồ họa đầu tiên. Lập trình luồng dữ liệu tập trung vào việc biểu diễn mã dưới dạng biểu đồ có hướng của luồng dữ liệu giữa các “hoạt động”. Vào thời điểm đó, nó vẫn còn khá phức tạp, nhưng khái niệm này thực sự khá giống với hoạt động của các nền tảng mã thấp ngày nay!
Khi chúng ta nhảy vọt vài thập kỷ tới thập niên 90, chúng ta sẽ sử dụng cái gọi là ngôn ngữ lập trình thế hệ thứ tư (4GL). Chúng vẫn là ngôn ngữ lập trình nhưng nhắm đến người dùng không rành về kỹ thuật. Các ngôn ngữ cơ sở dữ liệu như SQL được phát triển với ý tưởng rằng người dùng chỉ cần nhập các câu tiếng Anh bình thường mô tả dữ liệu họ cần, thay vì phải hướng dẫn máy tính chính xác cách tìm nạp dữ liệu đó. Các ngôn ngữ 4GL này thiếu giao diện trực quan phù hợp, nhưng chúng đã có một bước tiến vượt bậc trong việc khiến việc lập trình trở nên dễ hiểu hơn đối với những người không có nền tảng CNTT.
Thập niên 90 cũng tạo ra một dạng nền tảng mã ngắn nguyên thủy khác: các công cụ phát triển người dùng cuối. Phát triển người dùng cuối tập trung vào việc cung cấp cho người dùng cuối của một ứng dụng các phương tiện để tạo ra ứng dụng đó. Điều này nghe có vẻ phức tạp nhưng Microsoft Excel thực sự là một ví dụ tuyệt vời về điều này. Excel mang đến cho những người không phải là lập trình viên cơ hội viết “chương trình” đại diện cho các mô hình dữ liệu rất phức tạp.
Với nhu cầu ngày càng tăng của các công ty để cung cấp nhiều ứng dụng hơn với tốc độ nhanh hơn, nền tảng low-code gia nhập thị trường thành công vào đầu những năm 2010, xây dựng trên nền tảng của các khuôn khổ đã đề cập trước đó. Với việc khan hiếm các nhà phát triển chất lượng, đây là thời điểm hoàn hảo và không có gì ngạc nhiên khi các nền tảng low-code đã phát triển nhanh chóng và tạo ra nhiều sự cường điệu.
Forbes thậm chí còn gọi các nền tảng mã thấp là “cực kỳ đột phá”. Trong vài năm gần đây, họ chắc chắn đã tạo được nhiều làn sóng trong bối cảnh kỹ thuật số và làm cho việc phát triển ứng dụng trở nên dễ tiếp cận hơn với công chúng. Tuy nhiên, là một công cụ tuyệt vời để phát triển ứng dụng, không có nghĩa là nó sẽ là công cụ tuyệt vời cho các trường hợp sử dụng AI.
Tại sao low-code không phù hợp hoàn hảo với AI (hiện tại)
Vì thế chúng ta ở đây; chúng tôi có những nền tảng mã nguồn thấp tuyệt vời như Mendix hoặc Outsystems giúp các công ty cung cấp ứng dụng mới một cách nhanh chóng mà không cần phải thuê nhiều nhà phát triển đang khan hiếm. Tuy nhiên, mã thấp không phù hợp để nâng cao các ứng dụng này bằng AI. Tại sao? Vâng, có vô số lý do nhưng sau đây là những lý do tôi coi là chính:
- Rất nhiều chi phí và độ trễ tăng lên
- Không linh hoạt
- Bảo trì khó khăn
Hãy khám phá điều này nhiều hơn một chút.
Chi phí chung và độ trễ
Bằng cách trừu tượng hóa tất cả mã thành các khối có thể kéo và thả, sẽ tạo ra rất nhiều chi phí và kéo theo đó là độ trễ tăng lên.
Nền tảng mã thấp được tạo ra để dễ sử dụng và phát triển nhanh chóng, đơn giản là chúng không được tạo ra để đạt được hiệu quả và tốc độ. Đối với các ứng dụng đơn giản thì điều đó hoàn toàn bình thường, nhưng đối với AI thì đây thực sự có thể là một công cụ chặn. Ví dụ: hãy nghĩ về một mô hình đề xuất sử dụng AI để đề xuất các mục hoặc chủ đề cho người dùng ứng dụng. Một mô hình như vậy cần có khả năng đưa ra đề xuất trong phạm vi mili giây để có hiệu quả, nếu không bạn sẽ mất khách hàng. Amazon thậm chí còn ghi nhận rằng cứ mỗi 100 ms độ trễ lại khiến họ phải trả giá 1% doanh số bán hàng!
Trên hết, các mô hình AI có xu hướng nặng hơn nên bạn thường không thể chịu được quá nhiều độ trễ từ nền tảng mà bạn đang chạy mô hình trên đó.
Tất nhiên, không phải mọi mô hình AI đều cần độ trễ thấp, một số có thể chỉ chạy ở chế độ nền trong nhiều giờ, nhưng đó có phải là những mô hình mà bạn thậm chí muốn đặt đằng sau một ứng dụng mã thấp không? Có lẽ vậy, nhưng tôi nghĩ phần lớn các trường hợp sử dụng AI đằng sau ứng dụng di động hoặc web sẽ yêu cầu độ trễ thấp để mang lại kết quả tốt. Đặc biệt với những người dùng mong đợi thời gian phản hồi cực kỳ nhanh hiện nay.
Thiếu tính linh hoạt
Khi bạn cần thứ gì đó chưa có trong mẫu mã ngắn, rất có thể bạn sẽ gặp phải tình trạng thiếu tính linh hoạt mà các nền tảng này vốn có. Xét rằng các trường hợp sử dụng AI nói chung khá cụ thể và phụ thuộc nhiều vào loại dữ liệu có sẵn cũng như cách lưu trữ và xử lý dữ liệu đó, AI sẽ khó bao gồm trong các mẫu được xác định trước. Bạn có thể sẽ cần đến mã tùy chỉnh để làm cho mô hình hoạt động và việc thêm mã tùy chỉnh đó theo cách nó hoạt động với phần còn lại trong mẫu có thể sẽ tốn nhiều thời gian hơn so với việc viết mã đầy đủ trực tiếp. Và khi đến phần viết mã tùy chỉnh, bạn sẽ gặp phải vấn đề là bạn cần phải làm việc với ngôn ngữ mà nền tảng low-code đang sử dụng. Thông thường, những ngôn ngữ nền tảng này không phải là ngôn ngữ lập trình thông thường mà bạn sử dụng cho AI.
Bảo trì khó khăn
Mã thấp không thực sự phù hợp với tính chất lặp lại của Khoa học dữ liệu. Các mô hình liên tục cần được đào tạo lại hoặc điều chỉnh để có thể theo kịp dữ liệu mới được cung cấp theo thời gian. Tuy nhiên, các ứng dụng mã thấp buộc bạn phải sử dụng các mẫu này và có thể khó điều chỉnh. Ngay cả bên ngoài các trường hợp sử dụng AI, các ứng dụng mã thấp nổi tiếng là khó cập nhật để phù hợp với các yêu cầu kỹ thuật đang thay đổi. Không chỉ vậy, nếu các mô hình của bạn được duy trì trong môi trường mã thấp, điều này có nghĩa là mỗi khi một mô hình cần được cập nhật thì toàn bộ ứng dụng cũng cần được cập nhật phải không? Điều này gây ra nhiều chi phí không cần thiết và thực sự có thể dẫn đến các mô hình lỗi thời trong sản xuất vì ngưỡng cập nhật chúng đúng cách là quá cao. Nếu bạn quan tâm đến vấn đề này, Ben Hosking đã viết một bài viết rất hay về cơn ác mộng bảo trì của các ứng dụng mã thấp.
Low-code và AI có thể phối hợp với nhau như thế nào
Mặc dù nền tảng low-code có thể không phù hợp nhất với AI nhưng điều đó không có nghĩa là AI và low-code không thể hoạt động cùng nhau. Nền tảng mã thấp rất tuyệt vời để phát triển các ứng dụng có thể mở rộng một cách nhanh chóng và chỉ là vấn đề thời gian trước khi các công ty quyết định phát triển các ứng dụng đó muốn cải tiến nó bằng AI. Có lẽ bạn sẽ không tìm thấy các công cụ phù hợp để thực hiện điều đó trong chính nền tảng mã thấp, nhưng có những ứng dụng chuyên lưu trữ và phục vụ các mô hình có thể hoạt động hiệu quả khi kết hợp với nền tảng mã thấp. Điều quan trọng là tìm ra công cụ tốt nhất cho mỗi công việc. Một nền tảng mã ngắn tốt để phát triển ứng dụng nói chung và một công cụ tốt để lưu trữ và phục vụ các mô hình AI cần chạy phía sau ứng dụng.
Điều quan trọng nhất khi đặt AI đằng sau một ứng dụng mã thấp là mã AI của bạn cần có thể gọi được từ ứng dụng của bạn. Để làm như vậy, tốt nhất là bạn nên đặt mã AI của mình đằng sau một API. Bằng cách đó, bạn có thể chỉ cần gửi yêu cầu từ ứng dụng mã thấp của mình tới API, API này sẽ chạy mã AI.
Vì API rất phổ biến nên hầu hết các nền tảng mã nguồn thấp đều có các thành phần được tạo sẵn mà bạn có thể sử dụng để thực hiện lệnh gọi API, điều này giúp bạn dễ dàng thiết lập kết nối. Điều này chỉ để lại vấn đề thực sự lấy mã của bạn đằng sau API và lưu trữ nó ở đâu đó.
Bạn có thể tự mình thực hiện việc này từ đầu nhưng cũng có thể sử dụng các công cụ tự động đặt mã của bạn sau một API như AWS Lambda, Azure Functions hoặc UbiOps. Nếu bạn quyết định sử dụng một công cụ, có nhiều lựa chọn khác nhau và lựa chọn nào phù hợp nhất tùy thuộc vào trường hợp sử dụng của bạn. Các chức năng của đám mây hoạt động rất nhanh nhưng bị giới hạn về loại mã có thể chạy và có xu hướng yêu cầu một chút kiến thức chung về CNTT.
UbiOps là một công cụ được thiết kế đặc biệt để phân phối mã khoa học dữ liệu và cũng tự động thiết lập API cho bạn. Nó nhắm mục tiêu nhiều hơn vào các nhà khoa học dữ liệu thực tế. Nếu bạn muốn xem cách thực sự hoạt động khi sử dụng UbiOps để cải thiện ứng dụng của bạn bằng AI, bạn có thể xem qua bài viết này.
Nhìn chung, các nền tảng low-code thực sự là những công cụ tuyệt vời, nhưng lại không tuyệt vời (riêng chúng) cho mục đích AI. AI tình cờ là thứ được chăm sóc tốt hơn thông qua mã thích hợp, mặc dù có sự trợ giúp của một số công cụ tiện dụng giúp bạn đưa nó vào hoạt động. Chỉ cần nhớ tìm kiếm một công cụ phù hợp nhất với nhu cầu của bạn và tìm cách kết hợp tất cả lại với nhau!
Bài viết này ban đầu xuất hiện trên buổi trưa và được tái bản với sự cho phép.
