Tránh "nhập lệnh, ra rác": Áp dụng tư duy khoa học vào dự án AI và Dữ liệu

Đây là bài viết thứ hai trong series "Ghi chú Tháp ngà" (Ivory Tower Notes) của tôi. Ở bài viết đầu tiên, tôi đã đề cập đến vấn đề: cách mọi dự án dữ liệu và AI bắt đầu. Lần này, chủ đề là phương pháp luận, và lý do tại sao hiện tượng "nhập lệnh, ra rác" (prompt in, slop out) lại thường xảy ra khi chúng ta bỏ qua bước này.

Nhập lệnh, ra rác

Tôi đã phải mỉm cười khi một trong những kết nối của tôi bình luận "Bạn đã gửi cho tôi thứ rác rưởi của AI" (AI Slop) dưới một bài đăng ngẫu nhiên có hàng trăm lượt thích. Bài đăng đó chứa một ma trận quyết định, đưa ra hướng dẫn về nền tảng nào nên sử dụng cho các khối lượng công việc dữ liệu cụ thể, mặc dù với các tiêu chí còn gây tranh cãi. Bỏ qua chất lượng, nó trông thực sự rất ấn tượng.

Sự thích thú của tôi không dừng lại ở đó khi tôi nghĩ về việc AIS, hay "AI Slop", nên được thêm như một nút bấm trên tất cả các mạng xã hội ngay bên cạnh nút thích.

Nếu bất kỳ ai của YouTube đọc được bài này, đây là một ý tưởng tính năng thay vì hỏi mọi người "Bạn có cảm thấy đây là rác rưởi của AI không?".

Dù vậy, YouTube đã đánh trúng vào khía cạnh "cảm giác" vì chúng ta đều có xu hướng đưa ra quyết định dựa trên cảm xúc, thường là đánh đổi tư duy phản biện.

Tại sao chúng ta lại phải đầu tư năng lượng vào chủ nghĩa kinh nghiệm, chủ nghĩa duy lý và sự hoài nghi khi chúng ta đã có AI? Các thời hạn chót không đứng về phía chúng ta, và chúng ta có công cụ mới này cung cấp đầu ra cho chúng ta, bất chấp hiệu ứng "nhập lệnh, ra rác".

Minh họa phương pháp luận

Nhưng hãy giả sử bạn thực sự quan tâm đến việc so sánh Nền tảng A và Nền tảng B về khả năng Học máy (ML), vì bạn nhận thấy hai nhóm dữ liệu trong công ty đang sử dụng các nền tảng riêng biệt cho các trường hợp sử dụng ML gần như giống hệt nhau. Mục tiêu của bạn là tổng hợp một cái nhìn khách quan về cả hai và đề xuất giảm chi phí phát triển bằng cách chỉ giữ lại một nền tảng.

Bây giờ thì sao? Làm thế nào để bạn xác định xem có nên gộp chung khối lượng công việc ML hay không?

Chắc chắn không chỉ dựa vào AI, mà là dựa vào...

Con đường tìm kiếm

Và thế là bạn lại quay lại những ngày tháng "Tháp ngà", nơi bạn được dạy rằng mọi khám phá đều được bao phủ bởi "Phương pháp luận":

Vấn đề → Giả thuyết → Kiểm chứng giả thuyết → Kết luận

Hơn nữa, bạn được dạy rằng việc tìm ra vấn đề là một nửa công việc, và nghệ thuật để đạt được điều đó nằm ở việc đặt ra những câu hỏi tốt để thu hẹp nó lại thành một điều gì đó cụ thể và có thể kiểm chứng được.

Do đó, bạn lấy câu hỏi mơ hồ "Chúng ta có nên gộp chung vào một nền tảng ML không?", và bạn viết lại nó cho đến khi nó trở thành một câu hỏi mà một bài kiểm tra có thể trả lời được:

Nền tảng A có chạy pipeline dự đoán tỷ lệ rời bỏ (churn pipeline) của chúng ta với độ chính xác tương đương và chi phí thấp hơn so với Nền tảng B không?

Bây giờ bạn đã xác định được một chủ đề, một sự so sánh và những thứ bạn có thể đo lường, điều này đủ để biến một câu hỏi kinh doanh thành một giả thuyết có thể kiểm chứng.

Nhưng trước tiên, bạn làm bài tập về nhà và thu thập thêm thông tin, chẳng hạn như chi phí hiện tại của Nền tảng B cho mỗi công việc, độ chính xác mà nó đạt được, và cách nó được thiết kế (ví dụ: dữ liệu, thuật toán và siêu tham số mà nó sử dụng), để bạn có thể tái tạo pipeline trên Nền tảng A.

Sau đó, trước khi các ý kiến về câu hỏi của bạn bắt đầu đổ về, bạn tuyên bố:

Nếu chúng ta chạy cùng một pipeline dự đoán tỷ lệ rời bỏ trên Nền tảng A thay vì Nền tảng B, sử dụng dữ liệu, thuật toán và siêu tham số giống hệt nhau, thì chi phí trung bình cho mỗi công việc sẽ giảm ít nhất 15%, trong khi độ chính xác trung bình vẫn nằm trong phạm vi 1 điểm phần trăm của Nền tảng B.

Với công thức "nếu... thì" này, bạn đã quản lý để làm im lặng (ít nhất là một số) câu trả lời mang tính ý kiến, biết rằng PoC (Bằng chứng khái niệm) sẽ đến tiếp theo. Vì vậy, để kiểm tra giả định đã nêu, bạn thiết kế và chạy PoC, nơi bạn chỉ thay đổi biến độc lập, đó là nền tảng. Cùng với điều này, bạn đóng băng các biến điều khiển: tập dữ liệu, thuật toán và siêu tham số, đồng thời đo lường chi phí và độ chính xác, là các biến phụ thuộc của bạn.

Bạn cũng lặp lại quá trình chạy nhiều lần để tách tín hiệu khỏi nhiễu bằng cách thu thập nhiều điểm dữ liệu, xem xét cách một lần chạy duy nhất có thể bị lệch bởi nhiễu môi trường (ví dụ: bộ nhớ đệm), và bạn muốn tránh tình huống đó. Sau đó, bạn tính đến nhiều sắc thái hơn, ví dụ như kích hoạt các lần chạy vào các thời điểm khác nhau trong ngày (sáng, chiều hoặc đêm), để tiếp xúc cả hai nền tảng với cùng một hỗn hợp điều kiện.

Cuối cùng, bạn thu thập tất cả kết quả và đánh giá dữ liệu dựa trên giả thuyết của mình, điều này dẫn bạn đến một trong ba kết quả sau:

Kết quả 1: Dữ liệu hỗ trợ giả thuyết của bạn*. Các lần chạy nhiều lần cho thấy Nền tảng A rẻ hơn ít nhất 15% và độ chính xác vẫn nằm trong ngưỡng đã định. (Chỉ để lưu ý: dữ liệu sẽ hỗ trợ, nhưng không chứng minh giả thuyết của bạn, tức là nó sẽ cung cấp cho bạn lý do để giữ nó, điều mà trong khoa học gần giống với một câu "có" nhất có thể).

Kết quả 2: Dữ liệu bác bỏ giả thuyết của bạn. Các lần chạy nhiều lần cho thấy Nền tảng A không đáp ứng một hoặc cả hai tiêu chí; nó chỉ rẻ hơn 5%, hoặc chi phí giảm nhưng độ chính xác giảm xuống dưới ngưỡng đã định.

Kết quả 3: Các lần chạy của bạn quá nhiễu để có thể kết luận theo cách nào, và câu trả lời duy nhất là tiếp tục kiểm tra trước khi rút ra bất kỳ kết luận nào.

Bất kể kịch bản nào bạn rơi vào, bạn có những phát hiện: bạn đã xác nhận phán đoán có căn cứ của mình, học được điều gì đó mới, hoặc phát hiện ra rằng bạn cần tiếp tục kiểm tra.

Và để rõ ràng về ví dụ ngắn này: hai kết luận đầu tiên sẽ không cho bạn đèn xanh để gộp hai nền tảng. Thực tế doanh nghiệp (và một đánh giá kỹ lưỡng) lộn xộn hơn một chút so với thế, và có nhiều dữ liệu hơn (được thu thập và đánh giá) ảnh hưởng đến con người và quy trình hơn là những gì một PoC phạm vi hẹp có thể giải quyết được.

Được rồi, chúng ta có thể dừng việc nói về phương pháp luận ở đây, vì hầu hết các bạn có lẽ đang đọc các bước ở trên và tự hỏi...

Điều kỳ quặc nào đây? AI ở đâu trong tất cả những thứ này?

Tôi chỉ có thể tưởng tượng điều gì đó giống như: "MCP, khung tác tử (agentic frameworks), tác tử (agents)..." đang chạy qua đầu bạn khi đọc các bước ở trên. Hoàn toàn đồng ý, tất cả đều là những thứ tốt, và đây là cách bạn có thể tăng tốc quá trình.

Tuy nhiên, chỉ đơn giản là đăng tải đầu ra của AI từ một câu lệnh như "Hãy cho tôi tổng quan về cách Nền tảng A so sánh với Nền tảng B cho khối lượng công việc ML" là nơi rác rưởi xuất hiện, và "nếu bạn không thực hiện thao tác trực tiếp, ý kiến của bạn về nó rất có thể hoàn toàn sai".

"Nếu bạn không thực hiện thao tác trực tiếp, ý kiến của bạn về nó rất có thể hoàn toàn sai."

Sự phù hợp và ảnh hưởng tích cực không đến từ những bài đăng AI đẹp mắt hay đồ họa thông tin trong bài thuyết trình, và chúng có thể làm hỏng các mối quan hệ công việc.

Khi bạn đã đang gây ảnh hưởng và muốn được nhìn nhận như một thẩm quyền, việc chia sẻ quan điểm và phát hiện từ các thử nghiệm thực tế và kinh nghiệm đã được chứng minh của chính mình sẽ hiệu quả hơn.

Thay vì bắt đầu bài đăng của bạn bằng "Đây là nơi bạn nên sử dụng Nền tảng A thay vì Nền tảng B cho...", hãy thử điều gì đó cụ thể hơn (nếu nó đúng, tất nhiên):

"Khi chúng tôi (tôi) thay đổi [biến độc lập] để xem nó ảnh hưởng như thế nào đến [biến phụ thuộc], trong khi giữ [biến điều khiển] giống nhau, phát hiện của chúng tôi (tôi) là..."

Và sau đó hãy xem xem số lượng người theo dõi của bạn có tăng lên không, và báo cáo lại những phát hiện đó.

Cảm hứng cho bài viết này đến từ một bài báo của Croatia của Giáo sư Mladen Šolić, "Uvod u znanstveni rad" (Giới thiệu về Nghiên cứu Khoa học, 2005). Tôi lần đầu đọc nó khi còn là sinh viên, và nó vẫn là một trong những lời giải thích rõ ràng nhất về cách tiến hành nghiên cứu khoa học mà tôi từng gặp.

Cảm ơn bạn đã đọc. Nếu bạn thấy bài viết này có giá trị, hãy thoải mái chia sẻ nó với mạng lưới của bạn. 👏 Kết nối để đọc thêm những câu chuyện trên Medium ✍️ và LinkedIn 🖇️.