AI không chỉ trả lời, AI phải biết chọn

AI không chỉ trả lời, AI phải biết chọn

Case study hay không nằm ở thành tích. Nó nằm ở quyết định, ràng buộc, tiêu chí dừng và cách team đo được hệ quả sau khi triển khai AI.

Bạn có dám để AI chọn ca trực cuối tuần cho cả team không?

Câu hỏi nghe hơi căng, vì chọn sai là có người bực, khách hàng chờ, SLA méo mặt, còn trưởng nhóm thì ngồi gỡ drama lúc 11 giờ đêm. Nhưng đây chính là chỗ nhiều team đang hiểu lệch về AI trong công việc: cứ nghĩ AI giỏi là phải viết hay hơn, tìm nhanh hơn, trả lời tự nhiên hơn.

Mấy thứ đó hữu ích. Nhưng khi bước vào vận hành thật, giá trị lớn hơn nằm ở một câu khác: AI giúp mình ra quyết định tốt hơn dưới nhiều ràng buộc hay không?

Không phải model nào đang ồn ào nhất. Không phải demo nào trông mượt nhất. Mà là sau khi đưa vào workflow, team có chọn đúng việc cần làm, đúng lúc, với chi phí và rủi ro chấp nhận được không.

Sơ đồ minh họa cho bài AI không chỉ trả lời, AI phải biết chọn

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

Case study không phải phần tráng miệng PR

Mình thấy nhiều case study doanh nghiệp giống một set menu bị chụp mỗi món tráng miệng: hình đẹp, số đẹp, câu chuyện đẹp. Nhưng nếu bạn đang phải triển khai cho team, thứ cần xem không phải là ánh đèn sân khấu, mà là bếp đã đổi quy trình ra sao.

Một case đáng đọc nên trả lời được 4 câu:

  1. Trước đó quyết định nào đang bị nghẽn?
  2. AI được đưa vào để gợi ý, tìm kiếm, hay tối ưu quyết định?
  3. Ràng buộc thật là gì: chi phí, thời gian, công bằng, compliance, hay năng lực con người?
  4. Nếu kết quả xấu, team dừng ở đâu?

Nguồn từ AWS về mathematical optimization — tối ưu toán học, tức tìm quyết định tốt nhất trong một tập lựa chọn rất lớn dưới các ràng buộc cụ thể — gợi một điểm hay: không phải mọi bài toán AI đều là dự đoán hoặc sinh nội dung. Có những bài toán bản chất là chọn.

Chọn tuyến giao hàng sao cho vừa rẻ vừa đúng hẹn. Chọn cách điều phối robot để không va nhau. Chọn lịch trực y tế sao cho đủ người, công bằng, đúng quy định. Những việc này không thể chỉ dựa vào trực giác của một người quản lý nhiều kinh nghiệm, vì số phương án khả thi quá nhiều.

Nói thẳng ra thì: LLM giúp bạn nói và hiểu; optimization giúp bạn chọn trong mê cung phương án.

Ba kiểu AI trong vận hành: đừng gọi nhầm món

Nếu team bạn đang bàn chuyện đưa AI vào workflow, mình sẽ không bắt đầu bằng câu hỏi dùng model nào. Mình sẽ hỏi: bạn đang cần món khai vị, phần chính, hay món phụ?

| Nhu cầu trong team | Cách AI phù hợp | Dấu hiệu dùng đúng |
|---|---|---|
| Tìm thông tin nhanh hơn | Search/RAG — truy xuất tri thức từ tài liệu nội bộ | Giảm thời gian săn tài liệu, tăng độ nhất quán câu trả lời |
| Viết/tóm tắt/soạn thảo | LLM — model ngôn ngữ sinh nội dung | Giảm việc lặp lại, nhưng vẫn có review của người |
| Chọn phương án tốt nhất | Mathematical optimization — tối ưu quyết định có ràng buộc | Có objective rõ, constraint rõ, đo được trade-off |

Aderant là một ví dụ khá đời thường cho nhóm đầu tiên. Team Cloud Engineering 38 người của họ phải hỗ trợ một sản phẩm cloud trong ngành legal, thông tin nằm rải ở sáu hệ thống vendor. Trước khi có lớp tìm kiếm hợp nhất, mỗi lượt tra cứu thủ công có thể mất 30–45 phút. Với hơn 200 support ticket và nhu cầu hỗ trợ vận hành toàn cầu, vấn đề không phải là thiếu người chăm chỉ. Vấn đề là thông tin bị xé nhỏ.

Khi họ triển khai một helper bot để unify search — gom tìm kiếm qua nhiều hệ thống — kết quả được báo là thời gian search nhanh hơn 90% và documentation nhanh hơn 75%. Con số đáng chú ý, nhưng bài học thực dụng hơn là: họ không bắt đầu bằng việc để AI tự xử ticket; họ bắt đầu bằng việc giảm ma sát tìm thông tin.

Đó là một quyết định triển khai khá tỉnh.

Quyết định mới cho practitioner: chọn theo loại nghẽn, không theo độ hot

Đổi góc nhìn: thay vì hỏi AI nào mạnh nhất, hãy hỏi workflow đang nghẽn ở tầng nào.

Ví dụ cụ thể: giả sử team bạn có 6 người làm vận hành SaaS B2B. Mỗi ngày có ticket từ khách hàng, log ở một nơi, runbook ở nơi khác, lịch trực nằm trong spreadsheet, còn kiến thức cũ nằm trong Slack.

Bạn có thể chọn 3 hướng:

1. Làm bot hỏi đáp nội bộ

Phù hợp khi người trong team mất thời gian tìm tài liệu. Đây là bài toán search/RAG. RAG nghĩa là cho model truy xuất tài liệu liên quan trước khi trả lời, giống đưa đúng hồ sơ cho người xử lý trước khi họ kết luận.

Ưu: dễ pilot, thấy tác dụng nhanh.
Nhược: nếu tài liệu rác, bot sẽ trả lời rác có vẻ tự tin.

2. Dùng LLM để soạn ticket update và runbook

Phù hợp khi team viết lặp lại nhiều: incident note, postmortem nháp, release summary.

Ưu: tiết kiệm thời gian soạn thảo.
Nhược: dễ biến thành lớp văn vẻ che mất thông tin thiếu chính xác.

3. Dùng optimization để xếp lịch trực hoặc phân bổ việc

Phù hợp khi có nhiều ràng buộc: ai nghỉ phép, ai đang on-call tuần trước, khách hàng nào cần SLA cao, task nào cần senior.

Ưu: xử được bài toán nhiều phương án, giảm thiên vị cảm tính.
Nhược: phải định nghĩa objective — mục tiêu tối ưu — và constraint — ràng buộc — thật rõ. Nếu nhập sai luật chơi, kết quả vẫn sai rất đều.

Điểm nhiều team hiểu sai là xem cả ba như cùng một thứ tên là AI. Nhưng chọn nhầm loại AI giống gọi set menu mà tưởng món nào cũng là phần chính: no thì có no, nhưng không chắc đúng bữa.

Một buổi thử nhỏ: đo quyết định, không đo cảm giác

Nếu là team practitioner, bạn có thể thử trong một buổi chiều với bài toán nhỏ, không cần đụng production ngay.

Chọn một workflow có lịch sử dữ liệu đủ gần, ví dụ:

Sau đó tạo một bảng đơn giản:

Decision: cần chọn cái gì?
Inputs: dữ liệu nào được phép dùng?
Constraints: điều gì không được vi phạm?
Objective: tối ưu cho cái gì?
Human override: ai được quyền sửa?
Stop rule: khi nào dừng thử nghiệm?

Một ví dụ minh họa:

Decision: phân công 40 ticket tồn đọng
Inputs: mức độ ưu tiên, khách hàng, kỹ năng engineer, workload hiện tại
Constraints: không ai nhận quá 8 ticket, ticket enterprise cần senior review
Objective: giảm ticket quá hạn, cân bằng tải giữa các engineer
Human override: lead support duyệt trước khi giao thật
Stop rule: nếu hơn 3 ticket bị phân sai kỹ năng, dừng pilot

Ở đây, bạn chưa cần xây hệ thống long-term memory hay agent nhiều tầng. Bạn chỉ cần biến một quyết định mơ hồ thành một bài toán có đầu vào, luật chơi và tiêu chí dừng.

Guardrail: ba dấu hiệu nên phanh lại

AI trong vận hành không hỏng theo kiểu nổ tung ngay. Nó hay hỏng kiểu lịch sự: output trông hợp lý, dashboard xanh, nhưng người dùng cuối thấy bực hơn.

Mình sẽ đặt ba vạch phanh:

Một: không giải thích được vì sao chọn.
Nếu hệ thống đề xuất lịch trực nhưng không chỉ ra ràng buộc nào dẫn tới lựa chọn đó, team sẽ mất niềm tin rất nhanh.

Hai: tối ưu một chỉ số và phá chỉ số khác.
Ví dụ giảm thời gian phản hồi ticket nhưng dồn toàn ticket khó cho hai người senior. Số đẹp, team cháy.

Ba: dữ liệu đầu vào không phản ánh thực tế.
Nếu bảng skill của engineer cập nhật lần cuối từ năm ngoái, hệ thống phân việc sẽ giống gọi món theo thực đơn cũ: món đã hết vẫn cứ hiện ngon lành.

Với các use case kiểu Cohere và RWS về language intelligence cho enterprise, bài học cũng tương tự: model mạnh là một phần, nhưng giá trị thật nằm ở việc nó được đặt vào quy trình có kiểm soát, có dữ liệu đúng, có người chịu trách nhiệm. Còn câu chuyện SPV trong đầu tư từ TechCrunch lại nhắc mình một ý ngoài lề nhưng hợp vận hành: đôi khi đổi cấu trúc triển khai quan trọng không kém bản thân tài sản. Trong AI cũng vậy, cách đóng gói workflow quyết định việc nó có vào được tổ chức hay không.

Khi nào nên scale?

Đừng scale vì demo được khen. Scale khi có đủ 5 tín hiệu này:

Sau khi đọc các case study kiểu này, điều mình muốn bạn đổi cách nghĩ là: đừng hỏi AI đã làm được gì ấn tượng; hãy hỏi nó đã cải thiện quyết định nào, trong ràng buộc nào, với hệ quả nào.

Nếu câu trả lời vẫn là chung chung, khoan gọi đó là transformation. Có khi mới chỉ là món khai vị được bày trên đĩa rất đẹp thôi.

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

Nguồn tham khảo