Thay AI bằng code, độ chính xác từ 75% lên 100%: khi nào nên để AI làm, khi nào đừng
Có một câu chuyện nhỏ rất đáng để mình nghĩ lại trước khi giao việc gì đó cho AI. Một nhà máy ở Đông Nam Á muốn làm “dự án AI đầu tiên”. Người làm xây xong trong đúng một buổi chiều, chạy thử ai coi cũng khen. Tới lúc kiểm tra kỹ thì cứ bốn đơn hàng là sai một đơn. Cuối cùng người đó bỏ AI ra khỏi khâu chạy chính, viết code bình thường, và độ chính xác nhảy lên 100%.
Bài học ở đây không phải “AI dở”. Bài học là: biết việc nào nên giao cho AI, việc nào đừng.
Nhà máy đang xử lý đơn hàng bằng cách nào?
Nhà máy này nhỏ, bán hàng cho các nhà bán lẻ trong khu vực. Mấy nhà bán lẻ gửi đơn đặt hàng qua email theo kiểu EDI. Nói cho dễ hiểu, EDI là cách các hệ thống máy tính nhắn đơn hàng cho nhau, và mỗi khách lại viết hơi khác nhau một chút, giống như mỗi vùng một giọng nói vậy.
Nhà máy không có đội IT riêng, ngân sách ít, mà khách thì ngày càng nhiều. Cách họ đang làm là một đoạn macro Excel chạy 24/7 trên một cái máy, đọc từng đơn trong email. Macro mà hư thì không ai hay, cho tới khi thấy đơn hàng không còn hiện ra nữa.
Dự án AI đầu tiên: nghe hợp lý trên giấy
Ý tưởng nghe rất thuận tai: để một bước AI đọc tin EDI, hiểu nó, rồi trả ra một đơn hàng sạch sẽ, khách mới có định dạng khác cũng đọc được luôn.
Người làm dựng đúng như vậy. Email tới, quy trình tự bắt lấy, bước AI đọc nội dung, ra một đơn có đủ các dòng hàng, rồi đổ vào bảng tính và vào hệ thống của nhà máy. Làm có một buổi chiều. Chạy thử thì mượt, ai cũng vui.
Rồi đem đi kiểm tra kỹ: bước mà nhiều người bỏ qua
Trước khi đưa vào chạy thật, người làm tạo một bộ kiểm tra: vài trăm đơn thật, mỗi đơn có sẵn đáp án đúng, và quy trình phải ra đúng đáp án đó mỗi lần. Làm vậy là chuyện bình thường trong nghề phần mềm, nhưng với các dự án AI thì lại hiếm. Nhiều dự án AI chết sau buổi demo cũng vì bỏ bước này.
Kết quả không sát chút nào: dưới 75% đơn được đọc đúng. Cứ bốn đơn thì có một đơn bị thiếu ô, bị bịa ra một giá trị, hoặc âm thầm rớt mất nguyên một dòng hàng. Người làm dùng mô hình tốt nhất lúc đó, sửa câu lệnh nhiều lần, con số chỉ nhích lên chút xíu rồi đứng đó.
Mà một dòng hàng bị rớt đâu phải lỗi kỹ thuật cho vui. Đó là món khách đã đặt, nhưng nhà máy không làm, không giao, không xuất hoá đơn.
Người làm nói thẳng với khách: “Quên AI đi.” Không phải vì công nghệ này dở, mà vì chỗ sai không có giới hạn. Không ai biết đơn nào sẽ sai, không đoán trước được, không đo được thiệt hại tới đâu. Hỏi AI cùng một câu một trăm lần thì không ra một trăm câu giống hệt nhau, vì nó được thiết kế như vậy. Với trợ lý trò chuyện thì không sao. Còn với việc quyết định tuần này nhà máy làm cái gì, đó là rủi ro không có trần.
Làm lại bằng thứ “nhàm chán”: code bình thường
Người làm xin danh sách các định dạng EDI nhà máy thật sự nhận, rồi viết cho mỗi định dạng một bộ đọc riêng. Hơn mười bộ như vậy, mất khoảng một tiếng rưỡi với Claude Code. Điểm mấu chốt là họ dùng AI để viết code, chứ không dùng AI để chạy việc đọc đơn.
Chạy lại đúng bộ kiểm tra cũ: đúng 100% mọi đơn, và sang năm vẫn đúng 100%. Cùng một công cụ, chỉ cần đứng lùi lại một bước là rủi ro lớn biến thành việc làm xong trong một buổi sáng.
Luật dễ nhớ: một câu hỏi trước khi giao việc cho AI
Có hai khái niệm cần nắm, và không khó:
- Xác định (deterministic): cùng đầu vào thì luôn ra cùng kết quả. Ví dụ: một công thức, một bộ đọc dữ liệu, một mô hình tối ưu.
- Ngẫu nhiên (stochastic): cùng đầu vào nhưng câu trả lời hợp lý mà không giống hệt mỗi lần. Mọi mô hình ngôn ngữ đều như vậy, từ cách nó được tạo ra.
Trước khi dùng AI cho một việc vận hành, hãy tự hỏi một câu: “Việc này có đúng một đáp án đúng mà mình kiểm tra được không?”
- Nếu có: dùng code. AI lúc này là cách nhanh nhất để viết code đó, chứ không phải thứ nên chạy việc đó.
- Nếu không có (đọc hiểu, tóm tắt, phân loại, soạn nháp, xếp hạng): đây đúng là chỗ của AI, và chuyện kết quả hơi khác nhau giữa các lần là chấp nhận được.
Áp dụng vào kịch bản tự động của mình
Nếu bạn đang dựng kịch bản tự động trên Make, n8n hay Zapier, thử soi từng bước theo câu hỏi trên:
- Bước có đáp án đúng duy nhất (tách ngày tháng, cộng tiền, lọc theo điều kiện, đổi định dạng, lấy số điện thoại ra khỏi đoạn chữ theo mẫu cố định): ưu tiên dùng bước có sẵn của công cụ, công thức hoặc một đoạn code nhỏ. Cần thì nhờ AI viết đoạn code đó giùm, rồi mình kiểm tra lại.
- Bước cần đọc hiểu, viết lách, tóm tắt, phân loại: giao cho AI, nhưng nên có thêm bước để người xem lại trước khi đi tiếp. Trang thấy kiểu bảng tính làm hàng đợi, có cột trạng thái “chờ duyệt”, rất hợp với chỗ này.
- Trước khi chạy thật: làm bộ kiểm tra như dưới đây.
Năm bước làm bộ kiểm tra
- Chọn một việc bạn định tự động hoá. Đừng ôm nhiều việc cùng lúc.
- Gom ví dụ thật kèm đáp án đúng. Vài chục đến vài trăm dòng, ghi trong một bảng tính là đủ.
- Chạy thử và đếm tỉ lệ đúng. Soi kỹ mấy chỗ sai âm thầm, như thiếu dòng hay bịa số, vì đó là kiểu sai khó thấy nhất.
- Chưa chắc thì đổi cách: chuyển phần có đáp án đúng sang code, hoặc thêm một bước người duyệt.
- Chạy lại đúng bộ kiểm tra đó mỗi lần sửa quy trình, và mỗi khi có khách mới hay định dạng mới.
Nếu bạn không có cách nào biết AI làm sai, thì chưa nên tự động hoá việc đó. Làm bộ kiểm tra trước đã.
Lưu ý khi đọc: các con số 75% và 100% là do chính người làm báo lại, trên bộ kiểm tra của họ. “Đúng 100%” nghĩa là đúng với các định dạng đã biết; nếu có khách gửi một định dạng lạ, vẫn phải viết thêm bộ đọc mới. Hãy xem đây là một trường hợp tham khảo, không phải lời bảo đảm cho mọi trường hợp.
Cuối cùng, người đứng trong phòng họp mà biết hỏi “liệu AI có phải lựa chọn đúng không?” còn đáng giá hơn người chỉ biết công cụ mới nhất. Mà học câu hỏi đó thì ngắn hơn nhiều so với học thêm một công cụ nữa.
Bài viết có tham khảo ý tưởng từ bài I Replaced the AI With Code and Accuracy Went From 75% to 100% của Samir Saci (Data Science Collective) trên Medium.
