Cách đặt bài toán AI cho đúng: đừng bắt máy nhận ra, hãy bắt máy đọc trạng thái
Phần lớn dự án AI hỏng vì đặt sai câu hỏi cho máy, không phải vì mô hình yếu. Cách đặt lại bài toán: bốn ví dụ thật, quy luật chung và năm bước làm theo.
Phần lớn dự án AI (Artificial Intelligence) tôi thấy hỏng không hỏng vì mô hình yếu. Chúng hỏng vì câu hỏi giao cho máy là câu hỏi sai.
Và cách sửa thường giống nhau: thôi bắt máy nhận ra một vật là vật gì, chuyển sang bắt máy đọc một trạng thái đơn giản gắn với một hành động cụ thể.
Bài này kể bốn lần tôi làm đúng việc đó, rút ra quy luật chung, đưa ra năm bước để anh chị tự làm, và nói rõ những trường hợp cách này không dùng được.
Các hình trong bài là hình minh hoạ, không phải ảnh chụp thực tế.
Vì sao câu hỏi sai lại là lỗi phổ biến nhất?
Vì nó không trông giống một lỗi.
Khi một tổ chức muốn dùng AI, câu hỏi tự nhiên nhất là mô tả lại bằng lời thứ mà một người sẽ nhìn: “cho tôi biết trên băng chuyền có món gì”, “cho tôi biết khay nào sắp hết”, “cho tôi biết bàn nào đang trống”.
Nghe rất hợp lý. Nhưng những câu đó mô tả cách con người nhìn, không phải thông tin tối thiểu để ra quyết định. Và khoảng cách giữa hai thứ đó thường lớn gấp nhiều lần.
Nhà cung cấp thì ít khi chỉ ra khoảng cách ấy. Vì bài toán càng phức tạp, hợp đồng càng lớn. Nhận câu hỏi khó và báo giá theo độ khó là chuyện dễ hơn nhiều so với ngồi lại với khách để rút gọn câu hỏi — nhất là khi rút gọn xong thì giá trị hợp đồng cũng giảm theo.
Đây là chỗ tôi cho rằng thị trường đang chệch: người bán bán độ phức tạp, người mua cần kết quả.
Bốn lần đặt lại bài toán
Một: băng chuyền, từ “món gì” sang “màu gì”
Một chuỗi lẩu băng chuyền hỏi chúng tôi: có nhận diện và đếm được món ăn chạy trên băng không?
Chúng tôi thử. Hàng trăm món, nhiều món nhìn từ trên xuống gần như giống nhau, lướt qua khung hình trong hai giây. Muốn máy phân biệt được thì phải có ảnh của từng món ở đủ điều kiện, phải có người gán nhãn hết, nhân với số nhà hàng. Chi phí chuẩn bị dữ liệu vượt xa giá trị của việc đếm.
Chúng tôi quay lại hỏi: nhà hàng cần biết điều gì? Không phải biết trên băng có bao nhiêu đĩa thịt bò. Mà là trên băng có đủ đồ so với lượng khách đang ngồi hay chưa.
Câu đó không cần nhận ra món. Chỉ cần đếm đĩa và biết đĩa thuộc nhóm nào. Chúng tôi đề nghị phân nhóm bằng màu đĩa — và nhà hàng thay toàn bộ đĩa trên cả chuỗi để làm được việc đó.
Chi tiết dự án này tôi kể ở bài Khách hỏi đếm món, chúng tôi đề nghị đổi đĩa.
Hai: quầy đồ ăn, từ “còn bao nhiêu” sang “ba mức”
Một chuỗi nhà hàng khác muốn theo dõi tình trạng các khay trên quầy tự chọn.
Câu hỏi tự nhiên là “khay còn bao nhiêu phần trăm”. Nhưng con số phần trăm không dẫn tới hành động nào cả — người bếp không làm gì khác nhau giữa 41% và 44%.
Cái họ cần là ba mức gắn với ba hành động: có đủ đồ thì không phải làm gì, còn vừa đồ thì chuẩn bị bổ sung, hết đồ thì đã muộn.
Và trong ba mức đó, mức ở giữa mới là sản phẩm. Một hệ thống chỉ báo “hết” thì vô dụng, vì lúc nó báo thì khách đã đứng trước khay rỗng. Tôi viết kỹ ở bài Giám sát quầy đồ ăn bằng AI.
Ba: bàn ăn, từ “bàn thế nào” sang “có người, có bát đĩa”
Bài toán: biết bàn nào cần dọn, và đo xem sau khi khách rời thì bao lâu bàn được dọn xong.
Nếu hỏi máy “bàn này đang ở trạng thái nào” thì đó là một câu hỏi mở, khó định nghĩa và khó nghiệm thu. Đặt lại thành hai câu hỏi đóng thì dễ hơn hẳn: trên bàn có người không, và trên mặt bàn có bát đĩa không. Ghép hai câu trả lời lại là ra trạng thái.
Điều thú vị: giá trị lớn nhất của hệ thống này hoá ra không phải việc phân loại, mà là nói cho nhân viên biết bàn nào vừa có khách rời đi — một việc mắt họ không nhìn thấy được khi đang ở khu khác. Bài Giám sát bàn ăn bằng AI nói kỹ hơn.
Bốn: cửa ra vào, từ “ai” sang “hướng nào”
Đếm khách ra vào để biết trong quán đang có bao nhiêu người.
Nếu đặt thành bài toán nhận diện — biết từng người là ai, ai đã vào ai chưa ra — thì vừa nặng, vừa chạm vào dữ liệu cá nhân của khách, vừa không cần thiết.
Đặt lại: kẻ một vạch ảo ở cửa, bám theo từng người và ghi nhận hướng cắt qua vạch. Máy không cần biết người đó là ai. Nó chỉ cần biết cùng một người vừa đi từ phía nào sang phía nào. Chi tiết ở bài Đếm khách ra vào nhà hàng bằng AI.
Quy luật rút ra
Bốn lần, cùng một nước đi. Viết thành bảng thì thấy rõ:
| Dự án | Câu hỏi ban đầu | Câu hỏi sau khi đặt lại |
|---|---|---|
| Băng chuyền | Món này là món gì? | Đĩa này màu gì? |
| Quầy đồ ăn | Khay còn bao nhiêu phần trăm? | Đủ, vừa, hay hết? |
| Bàn ăn | Bàn này đang thế nào? | Có người không, có bát đĩa không? |
| Cửa ra vào | Người này là ai? | Đi hướng nào qua vạch? |
Cột bên phải có ba đặc điểm chung, và đó chính là quy luật:
Một: câu trả lời là một trạng thái, không phải một danh tính. Màu, mức, có hay không, hướng nào. Những thứ này ổn định hơn nhiều so với việc nhận ra một vật cụ thể, vì chúng dựa trên dấu hiệu thô mà camera đọc được dù ánh sáng đổi, góc đổi, vật hơi khác đi.
Hai: mỗi trạng thái nối thẳng tới một hành động. “Còn vừa đồ” nghĩa là đi lấy đồ. “Bàn có bát đĩa, không có người” nghĩa là ra dọn. Nếu một trạng thái không dẫn tới hành động nào thì nó không đáng đo.
Ba: số lượng trạng thái rất ít. Ba, bốn, nhiều lắm là sáu. Không phải hàng trăm.
Và một điều nữa, khó chịu hơn nhưng quan trọng: cột bên phải rẻ hơn cột bên trái rất nhiều — rẻ hơn về dữ liệu, về thời gian, về chi phí duy trì. Đó là lý do nó chạy được thật, lâu dài, ở nhiều chi nhánh, chứ không chỉ chạy đẹp trong buổi demo.
Năm bước để tự đặt lại một bài toán
Đây là cách tôi làm. Anh chị làm được mà không cần biết kỹ thuật.
- 1Viết ra hành độngKhi có thông tin, ai sẽ làm gì khác đi so với hôm nay?
- 2Đi ngược về thông tin tối thiểuĐể làm hành động đó, ít nhất cần biết gì?
- 3Tìm dấu hiệu đơn giản hơnVị trí, màu, có hay không, hướng: càng thô càng rẻ
- 4Hỏi khách đổi được gìĐổi màu đĩa, dán vạch, đặt lại khay
- 5Chốt mức chính xác theo hậu quảSai thì chuyện gì xảy ra? Ghi bằng văn bản trước khi ký
Bước 1. Viết ra hành động, không viết ra câu hỏi
Đừng bắt đầu bằng “tôi muốn biết X”. Bắt đầu bằng: khi có thông tin, ai sẽ làm gì khác đi so với hôm nay?
Nếu không trả lời được câu này, dừng lại. Chưa đáng làm dự án.
Câu trả lời phải cụ thể tới mức nêu được tên vị trí công việc và hành động: “người bếp đi lấy khay bổ sung”, “quản lý ca gọi thêm người vào khung mười một giờ”. Không phải “để quản lý tốt hơn”.
Bước 2. Đi ngược từ hành động về thông tin tối thiểu
Hỏi: để làm hành động đó, ít nhất cần biết gì?
Người bếp cần biết khay nào sắp hết — không cần biết còn đúng bao nhiêu gam. Quản lý cần biết giờ nào đông — không cần biết từng khách là ai.
Bước này thường cắt được phần lớn yêu cầu ban đầu. Cắt được càng nhiều càng tốt.
Bước 3. Tìm dấu hiệu đơn giản hơn để đọc thông tin đó
Đây là bước sáng tạo, và là chỗ nhà cung cấp giỏi tạo ra khác biệt.
Bốn loại dấu hiệu dễ đọc nhất, theo thứ tự từ rẻ tới đắt:
| Dấu hiệu | Ví dụ | Độ khó |
|---|---|---|
| Vị trí | Khay ở ô số 7 là khay gì — biết trước, không cần nhận | Dễ nhất |
| Màu | Đĩa đỏ, đĩa vàng, đĩa trắng | Dễ |
| Có hay không | Có người ngồi không, có bát đĩa không | Dễ |
| Hướng và chuyển động | Đi vào hay đi ra, đứng yên hay di chuyển | Trung bình |
| Hình dạng cụ thể của vật | Đây là món gì, người này là ai | Khó nhất |
Quy tắc: leo lên bảng này càng cao càng tốt. Mỗi bậc leo lên tiết kiệm được rất nhiều dữ liệu, thời gian và tiền.
Bước 4. Hỏi xem khách có đổi được gì ở phía họ không
Đây là bước hay bị bỏ qua nhất, và là bước tạo ra kết quả lớn nhất.
Đôi khi bài toán chỉ giải được nếu ngoài đời thay đổi một chút: đổi màu đĩa, dán một vạch trên sàn, đặt lại vị trí khay, đổi hướng lối đi, thêm một đèn chiếu ở cửa.
Việc của người bán là nói ra điều đó sớm, rõ ràng, kèm lý do — chứ không im lặng rồi cố làm cho xong bằng công nghệ đắt hơn.
Và việc của chủ đầu tư là cân nhắc nghiêm túc. Ở dự án băng chuyền, nếu nhà hàng không chịu thay đĩa thì hoặc phải làm phương án đắt và kém chính xác, hoặc dự án dừng. Họ chịu thay, và đó mới là điều quyết định dự án thành công — không phải phần kỹ thuật của chúng tôi.
Bước 5. Chốt mức chính xác theo hậu quả của việc sai
Câu hỏi không phải “làm sao cho thật chính xác” mà là “sai thì chuyện gì xảy ra”.
| Hậu quả khi sai | Mức chính xác cần |
|---|---|
| Sai tiền của khách, sai quyết định pháp lý | Gần như tuyệt đối, và phải có cách đối chiếu độc lập |
| Người ra kiểm tra một lần vô ích | Vừa phải là dùng được |
| Lệch nhẹ một con số thống kê trong hàng nghìn lượt | Sai lẻ tẻ không đổi kết luận |
Chốt mức này bằng văn bản, trước khi ký, kèm cách nghiệm thu. Bài Độ chính xác của AI nghĩa là gì nói kỹ về cách đọc một con số độ chính xác.
Khi nào cách này không dùng được?
Phần này dài hơn tôi muốn, nhưng phải viết. Một phương pháp mà không nói giới hạn thì là quảng cáo.
Khi danh tính chính là thứ cần biết. Kiểm soát ra vào phải biết người này là ai. Chấm công phải biết ai đã đến. Đọc biển số để tính phí phải đọc đúng biển số. Những bài toán này không rút gọn được, vì thông tin cần chính là thông tin khó.
Khi phải đọc nội dung. Trích thông tin từ hồ sơ, tóm tắt văn bản, tra cứu quy định — đây là họ bài toán khác hẳn, và không có “trạng thái đơn giản” nào thay thế được việc đọc hiểu.
Khi hậu quả của sai sót không đảo ngược được. Nếu một lần sai gây thiệt hại không sửa được, thì việc rút gọn bài toán để đổi lấy chi phí thấp là đánh đổi sai. Lúc đó phải làm đúng bài toán khó, hoặc không làm.
Khi không có dấu hiệu đơn giản nào tồn tại. Có những việc thật sự đòi phân biệt tinh vi, và không có màu nào, vị trí nào, hướng nào thay thế được. Khi đó câu trả lời trung thực là: bài toán này đắt, và đây là lý do. Nói thẳng thế tốt hơn là hứa rẻ rồi làm không xong.
Khi khách không đổi được gì ở phía họ. Có những hiện trường không sửa được — mặt bằng đi thuê, quy trình bị ràng buộc bởi quy định, thiết bị không thay được trong ngân sách. Lúc đó bước 4 đóng lại, và phải quay về phương án đắt hơn.
Tôi nêu đủ năm trường hợp vì trong nghề, người bán dễ rơi vào cái bẫy ngược lại: có một phương pháp hay rồi thì nhìn bài toán nào cũng thấy áp dụng được.
- Câu trả lời là một trạng thái, không phải danh tính
- Mỗi trạng thái nối thẳng tới một hành động
- Chỉ cần vài trạng thái, không phải hàng trăm
- Hiện trường đổi được một chút
- Danh tính chính là thứ cần biết
- Phải đọc hiểu nội dung văn bản
- Sai một lần là không đảo ngược được
- Không có dấu hiệu đơn giản nào thay thế
- Khách không đổi được gì ở phía họ
Dấu hiệu bài toán đang được đặt sai
Nếu anh chị đang cầm một đề xuất trên tay, đây là những dấu hiệu đáng dừng lại:
Đề xuất liệt kê tính năng thay vì nêu một việc cụ thể. Hai mươi tính năng thường có nghĩa là chưa ai xác định được việc nào đáng làm trước.
Không ai trả lời được “sau khi có thông tin thì ai làm gì khác đi”. Đây là dấu hiệu nặng nhất.
Số lượng trạng thái hoặc nhãn lên tới hàng chục, hàng trăm. Càng nhiều nhãn, càng nhiều dữ liệu phải gán, càng dễ sai và càng khó nghiệm thu.
Tiến độ dành rất ít thời gian cho chuẩn bị dữ liệu. Phần này thường là phần dài nhất. Bài Dữ liệu: chỗ mọi dự án AI mắc lại nói riêng về chuyện đó.
Không có mục nào về việc gì cần thay đổi ở phía chủ đầu tư. Gần như mọi dự án chạy được thật đều đòi một thay đổi nào đó ở hiện trường hoặc quy trình. Một đề xuất hứa “không ảnh hưởng gì tới vận hành hiện tại” thường là đề xuất chưa khảo sát kỹ.
Cái giá của việc đặt lại bài toán
Nói cho công bằng: đặt lại bài toán không miễn phí, và cái giá không rơi vào một phía.
Phía nhà cung cấp mất một phần doanh thu, vì bài toán đơn giản hơn thì hợp đồng nhỏ hơn. Đây là lý do thật khiến ít nơi làm.
Phía chủ đầu tư phải chịu thay đổi một thứ ở phía mình, và phải bỏ công định nghĩa cho rõ mình cần gì. Việc này mất vài buổi làm việc nghiêm túc, không phải một cuộc họp.
Đổi lại, cả hai được một hệ thống chạy được lâu dài. Theo tôi đó là cuộc trao đổi có lợi cho cả hai — nhưng chỉ khi cả hai cùng nhìn xa hơn một hợp đồng.
Ba câu nên hỏi nhà cung cấp — kể cả chúng tôi
Sau khi có thông tin này, ai trong đơn vị chúng tôi sẽ làm gì khác đi? Nếu nhà cung cấp không trả lời được bằng một vị trí công việc và một hành động cụ thể, họ chưa hiểu đơn vị anh chị.
Có cách nào đặt bài toán đơn giản hơn không, kể cả nếu chúng tôi phải thay đổi gì đó? Câu này mời họ nói ra thứ làm giảm giá trị hợp đồng của chính họ. Cách họ trả lời cho biết nhiều điều.
Hệ thống phải phân biệt bao nhiêu loại, và ai gán nhãn cho từng loại? Con số này dự báo khá chính xác độ khó và chi phí thật của dự án.
Câu hỏi thường gặp
Đặt lại bài toán như vậy có làm mất tính năng không?
Có, và đó là chủ ý. Cái mất là những tính năng nghe hay nhưng không ai dùng. Cái được là một hệ thống chạy ổn định và được dùng hàng ngày. Với dự án đầu tiên, tôi cho rằng đổi như vậy là đáng.
Nếu sau này muốn mở rộng thì sao?
Mở rộng từ một bài toán đơn giản đang chạy tốt dễ hơn nhiều so với sửa một bài toán phức tạp đang chạy kém. Dữ liệu tích luỹ được từ giai đoạn đầu cũng là vốn cho giai đoạn sau.
Ai là người nên đặt lại bài toán — chúng tôi hay nhà cung cấp?
Cả hai, ngồi cùng nhau. Chủ đầu tư biết hành động nào cần xảy ra; nhà cung cấp biết dấu hiệu nào máy đọc được dễ. Không bên nào tự làm được một mình, và đây là lý do tôi cho rằng buổi làm việc đầu tiên quan trọng hơn bản chào giá đầu tiên.
Cách này áp dụng cho trợ lý AI xử lý văn bản được không?
Được, ở tầng nguyên tắc. Thay vì hỏi “trợ lý này làm được gì”, hãy hỏi “cán bộ sẽ làm khác đi việc gì”. Với khu vực công, tôi viết riêng ở bài Ứng dụng AI trong cơ quan nhà nước: thực tế đến đâu và bài Trợ lý AI cho cán bộ.
Làm sao biết bài toán đã đủ đơn giản?
Khi anh chị mô tả được nó cho một người không làm kỹ thuật trong một câu, và người đó hiểu ngay máy phải trả lời cái gì. Nếu phải giải thích ba câu trở lên, thường là chưa đủ gọn.
Nếu anh chị đang cầm một đề xuất AI và ngờ rằng bài toán đang được đặt phức tạp hơn cần thiết, gửi tôi phần mô tả phạm vi — bỏ hết tên đơn vị, tên nhà cung cấp và giá. Tôi đọc và nói thẳng chỗ nào theo tôi có thể rút gọn được.
Tôi trả lời tất cả, và không gửi tài liệu quảng cáo.