AI không cứu backlog nếu thiếu đạo diễn

AI không cứu backlog nếu thiếu đạo diễn

Case study từ tòa án Pakistan nhắc một điều hơi trái tai: model mạnh chưa đủ. Giá trị thật nằm ở huấn luyện, kiểm chứng và cách đưa AI vào quy trình.

“Cứ đưa AI vào là năng suất tăng.”

Câu này nghe rất hợp lý, nhất là trong những team đang ngập ticket, hồ sơ, email, biên bản họp, hợp đồng, hoặc backlog kéo dài như series phim chưa biết ngày hết mùa. Nhưng case study từ hệ thống tòa án Pakistan lại tát nhẹ vào niềm tin đó: AI access alone did little — chỉ cấp quyền dùng AI thôi thì không tạo ra khác biệt lớn.

Điểm đáng học không phải là “wow, AI giúp xử lý án tồn”. Điểm đáng học là: AI chỉ bắt đầu có ROI khi tổ chức biết dựng lại phân cảnh công việc quanh nó. Không có người dùng được huấn luyện, không có cách kiểm chứng, không có dữ liệu đúng chỗ, model xịn cũng chỉ như camera đắt tiền đặt giữa phim trường không ai hô “action”.

Sơ đồ minh họa cho bài AI không cứu backlog nếu thiếu đạo diễn

Sơ đồ tóm tắt ý chính của bài viết.

Bối cảnh: không phải team nào cũng thiếu AI, nhiều team thiếu năng lực hấp thụ AI

Pakistan có một bài toán rất thật: theo nghiên cứu được The Decoder đưa lại, nước này có ít hơn 2 thẩm phán trên 100.000 dân, trong khi EU có 22 và England & Wales có 30. Cuối năm 2024, số vụ án đang chờ xử lý là 2,26 triệu, trong đó 82% nằm ở cấp trial courts.

Đây không phải kiểu backlog “Jira hơi đỏ đỏ”. Đây là backlog có tác động trực tiếp tới đời sống người dân.

Trong bối cảnh đó, nhóm nghiên cứu từ ETH Zurich, Imperial College London và New Economic School chạy một thử nghiệm thực địa lớn với 1.559 thẩm phán tại 118 tòa, khoảng một nửa số thẩm phán trial court của Pakistan. Công cụ được dùng là JudgeGPT, một AI assistant xây trên GPT-4, có RAG — retrieval augmented generation, tức cho model tra cứu tài liệu liên quan trước khi trả lời. Kho dữ liệu gồm 129.235 tài liệu: 128.292 phán quyết và 943 luật Pakistan.

Khi thẩm phán hỏi, hệ thống chọn 10 đoạn liên quan nhất rồi tạo câu trả lời có trích dẫn.

Nếu chỉ đọc tới đây, nhiều team sẽ rút ra kết luận vội: “À, vậy mình cần build một RAG assistant cho phòng pháp chế / vận hành / chăm sóc khách hàng.”

Khoan đã. Đoạn hay nằm sau đó.

Quyết định thật sự: không phải “có tool hay không”, mà là “ai được tập dùng tool như thế nào”

Các thẩm phán được chia thành ba nhóm:

| Nhóm | Được dùng JudgeGPT? | Huấn luyện kiểu gì? | Kết quả sử dụng |
|---|---:|---|---|
| Nhóm 1 | Có | 6 buổi 90 phút trong 3 tuần, sau giờ làm, tập trung vào task phù hợp, giới hạn và cách kiểm tra output | Dùng nhiều nhất |
| Nhóm 2 | Có | Seminar chung về công nghệ và luật | Dùng ít hơn nhiều |
| Nhóm 3 | Không | Seminar chung, không có JudgeGPT | Nhóm đối chứng |

Sau 40 tuần, nhóm được huấn luyện mục tiêu đăng nhập gần 60 lần và gửi hơn 200 prompt trung bình. Nhóm chỉ có seminar chung đăng nhập khoảng 20 lần và gửi dưới 50 prompt.

Nói thẳng ra thì: sự khác biệt không nằm ở việc ai được cấp account, mà ở việc ai được học cách đưa AI vào workflow thật.

Đây là cú bẻ góc rất quan trọng cho practitioner. Nhiều công ty Việt Nam đang mua AI tool theo logic “mở quyền cho cả phòng ban rồi xem ai dùng”. Cách đó có thể tạo vài người dùng nhiệt tình, vài demo đẹp, vài slide báo cáo. Nhưng nó hiếm khi tạo thay đổi vận hành bền vững.

Trong case này, training không phải buổi truyền cảm hứng kiểu “AI sẽ thay đổi ngành luật”. Training đi vào ba thứ thực dụng:

Đó mới là phần hậu kỳ quan trọng: không phải quay được nhiều cảnh là có phim hay, mà phải biết cảnh nào giữ, cảnh nào cắt, cảnh nào cần soi continuity.

Hệ quả: ROI đến từ adoption có kiểm soát, không phải từ model name

Theo nguồn chính, các quận có nhiều thẩm phán được huấn luyện hơn đã xử lý được nhiều vụ hơn. Ở mức exposure vừa phải, nghiên cứu ghi nhận thêm khoảng 1.848 vụ được giải quyết. Bài cũng nêu mức return là 38,50 USD cho mỗi 1 USD đầu tư.

Mình không muốn biến con số này thành khẩu hiệu bán hàng. Với bạn đang làm trong công ty, con số đó không có nghĩa là cứ copy JudgeGPT về là ROI tự nhân lên. Bối cảnh tòa án Pakistan rất đặc thù: backlog lớn, ít nhân sự, tài liệu pháp lý có cấu trúc tương đối rõ, và tác vụ tra cứu/phân tích văn bản chiếm nhiều thời gian.

Nhưng bài học vận hành thì rất chuyển được:

AI có giá trị nhất khi nó giảm ma sát ở điểm nghẽn đã đo được, chứ không phải khi nó xuất hiện ở nơi đang ồn ào nhất.

Ví dụ cụ thể: một công ty logistics có thể nghĩ “hãy dùng AI viết email chăm sóc khách hàng”. Nghe dễ. Nhưng nếu điểm nghẽn thật nằm ở việc nhân viên mất 20 phút tra cứu điều khoản bồi thường trong nhiều file PDF, thì assistant viết email chưa chắc tạo tác động lớn. Assistant tra cứu quy định, chỉ ra điều khoản, kèm nguồn để nhân viên kiểm chứng có thể đáng tiền hơn.

Hình dung thế này: bạn có một team 8 người xử lý khiếu nại. Giả sử mỗi người mất nhiều thời gian lục tài liệu nội bộ để trả lời các case lặp lại. Một AI assistant tốt ở đây không cần “nói chuyện như người”. Nó cần trả lời: tài liệu nào, điều khoản nào, có ngoại lệ gì, và nhân viên phải kiểm tra lại ở đâu trước khi gửi khách.

Đây là điểm nhiều team hiểu sai: họ benchmark AI bằng độ trôi chảy của câu trả lời, trong khi người vận hành cần benchmark bằng quyết định có an toàn hơn và nhanh hơn không.

Khung 4 câu hỏi trước khi đưa AI vào backlog

Nếu bạn đang muốn áp dụng case này cho team mình, đừng bắt đầu bằng câu “dùng model nào?”. Bắt đầu bằng bốn câu hỏi này:

1. Backlog nào có chi phí thật?

Không phải mọi backlog đều đáng tự động hóa. Có backlog gây khó chịu, có backlog gây mất tiền, có backlog gây rủi ro pháp lý, có backlog làm khách hàng rời đi.

Hãy chọn một luồng việc mà team có thể mô tả rõ:

Nếu không trả lời được, AI project dễ thành trailer đẹp nhưng phim chính không ai xem.

2. AI nên hỗ trợ quyết định nào, không chỉ tạo nội dung nào?

JudgeGPT không chỉ “viết văn bản pháp lý”. Nó giúp tra cứu tài liệu, chọn đoạn liên quan, tạo câu trả lời có trích dẫn để thẩm phán kiểm tra.

Trong doanh nghiệp, câu hỏi tương tự là:

Nếu AI chỉ viết đoạn chữ cuối cùng, bạn đang tối ưu phần dễ nhìn nhất, chưa chắc tối ưu phần tốn não nhất.

3. Training có dạy giới hạn không?

Một buổi onboarding AI tốt không nên chỉ dạy prompt mẫu. Nó phải dạy cả “đừng dùng trong trường hợp nào”.

Với practitioner, failure mode — kiểu lỗi thường xảy ra trong vận hành — quan trọng hơn danh sách tính năng. Ví dụ:

Training tốt giống như dặn trợ lý dựng phim: cảnh nào được dùng, cảnh nào phải hỏi lại đạo diễn, cảnh nào nhìn hay nhưng sai mạch truyện.

4. Có lớp kiểm chứng nào trước khi output đi ra ngoài?

Nguồn liên quan về SynthID cho thấy một mặt khác của cùng vấn đề: trong vụ ảnh giả liên quan tới Mitch McConnell, watermark của SynthID giúp Snopes xác định ảnh là AI-generated. Watermark — dấu nhận diện ẩn trong nội dung — chỉ hữu ích khi có công cụ kiểm tra và bên tạo nội dung tham gia hệ thống đó.

Bài học không phải là “hãy dùng SynthID cho mọi thứ”. Bài học là: AI trong môi trường nhạy cảm cần lớp kiểm chứng, không chỉ lớp sinh nội dung.

Với văn bản nội bộ, lớp kiểm chứng có thể là:

Nếu tool của bạn không để lại dấu vết kiểm tra, production sẽ rất khó ngủ ngon.

Áp dụng trong một buổi: chạy pilot kiểu “case study nhỏ”

Bạn không cần triển khai toàn công ty. Trong một buổi chiều, có thể làm một pilot gọn như sau:

Bước 1: Chọn một backlog có tài liệu nền.
Ví dụ: xử lý khiếu nại, trả lời câu hỏi nội bộ HR, rà điều khoản hợp đồng, phân loại bug report.

Bước 2: Lấy 30 case cũ.
Không cần nhiều. Chọn case đủ đa dạng: dễ, trung bình, khó, có ngoại lệ.

Bước 3: Viết rubric đánh giá.
Rubric là bảng tiêu chí chấm. Với AI assistant, bạn có thể chấm:

Bước 4: Huấn luyện 3-5 người dùng thật.
Đừng chỉ gửi link. Hãy dành 60-90 phút để chỉ rõ task nên dùng, task không nên dùng, và cách kiểm chứng.

Bước 5: So sánh trước/sau bằng quyết định, không bằng cảm giác.
Đừng hỏi “AI có hay không?”. Hỏi:

Sau pilot, bạn sẽ biết mình cần model tốt hơn, dữ liệu sạch hơn, training kỹ hơn, hay thật ra không nên dùng AI cho luồng đó.

Cái cần đổi trong đầu: mua AI là phần dễ nhất

Case Pakistan đáng chú ý vì nó đặt AI vào một môi trường rất thiếu nguồn lực, rồi cho thấy kết quả không đến từ việc “có GPT-4” đơn thuần. Nó đến từ tổ hợp: dữ liệu đúng, workflow rõ, training sát việc, và kiểm chứng đầu ra.

Sau bài này, nếu bạn đổi một cách nghĩ, mình mong là đổi câu hỏi này:

Thay vì hỏi “tool AI nào đang hot?”, hãy hỏi “quyết định nào trong team đang bị chậm, và AI có thể rút ngắn nó mà vẫn kiểm tra được không?”

AI trong case study không phải nhân vật chính bước ra cứu cả bộ phim. Nó giống một trợ lý hậu kỳ rất mạnh: dùng đúng thì cắt được cảnh thừa, soi được lỗi, đẩy tiến độ; dùng sai thì chỉ làm ổ cứng đầy thêm file render.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo