Bài 2 — Khi nào nên nâng cấp lên Agentic (và khi nào KHÔNG)

Nâng cấp sai chỗ là cách nhanh nhất để đốt tiền token và làm hỏng một quy trình đang chạy tốt. Bài này cho bạn một khung ra quyết định định lượng, thay vì cảm tính "nghe AI hay nên thử".

Tín hiệu NÊN nâng cấp

• Bot RPA của bạn hay fail vì input phi cấu trúc: email tự do, PDF scan, tên cột thay đổi. Bạn tốn nhiều giờ maintain selector/regex.
• Quy trình có nhánh ngoại lệ nhiều hơn nhánh chính: bạn viết 50 câu if-else mà vẫn sót case.
• Bước xử lý cần "hiểu ý": phân loại ticket theo nội dung, tóm tắt, trích xuất thông tin từ văn bản.
• Con người đang làm thủ công phần "đọc và quyết định" giữa các bước tự động.

Tín hiệu KHÔNG nên nâng cấp

• Quy trình đã ổn định, input cố định: đừng sửa cái đang chạy tốt.
• Yêu cầu chính xác tuyệt đối, không được sai lần nào: tính lương, chuyển khoản, đối soát số dư.
• Khối lượng khổng lồ, biên lợi nhuận mỏng: chi phí token nhân lên triệu lần sẽ giết ROI.
• Không có cách kiểm chứng kết quả agent: nếu bạn không thể verify output tự động, rủi ro lỗi âm thầm rất cao.

Công thức ROI nhanh

Giá trị nâng cấp = (Số case RPA fail/tháng × Chi phí xử lý thủ công mỗi case)
                   + (Giờ maintain tiết kiệm × đơn giá kỹ sư)
                   − (Chi phí token/tháng)
                   − (Chi phí xây + vận hành agent)

Nếu > 0 và đủ lớn để bù rủi ro → nên làm.

Ví dụ số cụ thể

• RPA fail 400 email/tháng, mỗi email nhân viên xử lý mất 4 phút → ~27 giờ/tháng.
• Đơn giá 150.000đ/giờ → ~4.000.000đ/tháng chi phí thủ công.
• Thêm LLM đọc email: ~400 × 2.000đ token = 800.000đ/tháng.
• Tiết kiệm ròng ~3.200.000đ/tháng, chưa kể giảm sai sót. → Nên làm.

Ma trận 2x2 quyết định

              Input phi cấu trúc CAO
                      ▲
   Giữ RPA + LLM  |  Agentic đầy đủ
   trích xuất     |  (agent tự lập KH)
  ────────────────┼────────────────► Ngoại lệ / độ mở của quy trình CAO
   Giữ RPA thuần  |  RPA + rule
   (đừng đụng)    |  engine
                  |

• Góc dưới-trái: RPA thuần, đừng đụng.
• Góc trên-trái: chỉ cần LLM làm bước trích xuất, phần còn lại giữ RPA.
• Góc trên-phải: cần agent thực sự tự lập kế hoạch.

Các bước ra quyết định

• Đo baseline: tỷ lệ fail hiện tại, giờ maintain, giờ thủ công xen giữa.
• Xác định điểm đau chính: input phi cấu trúc hay logic phức tạp?
• Chọn mức nâng cấp tối thiểu đủ dùng: ưu tiên "RPA + LLM một bước" trước khi nhảy lên agent đầy đủ.
• Tính ROI theo công thức trên.
• Kiểm tra tính verify được: có cách nào tự động kiểm output không?
• Chốt phạm vi pilot: chọn 1 quy trình rủi ro thấp để thử.

Khung tư duy: "Bậc thang nâng cấp"

Đừng nhảy thẳng từ RPA lên agent tự trị. Leo từng bậc:

• RPA thuần → 2. RPA + 1 lệnh gọi LLM (trích xuất/phân loại) → 3. RPA điều phối nhiều LLM có tool → 4. Agent tự lập kế hoạch có RPA làm tool. Mỗi bậc chỉ leo khi bậc dưới không đủ.

Sai lầm thường gặp

• Nâng cấp vì "trend", không vì điểm đau: dẫn tới hệ thống phức tạp hơn mà chẳng giải quyết gì.
• Bỏ qua chi phí ẩn: token, vận hành, giám sát, xử lý khi agent "ảo giác".
• Nhảy thẳng lên agent tự trị: bỏ qua bước hybrid rẻ và an toàn hơn.
• Không đo baseline trước: sau nâng cấp không chứng minh được lợi ích, khó xin ngân sách tiếp.
• Chọn pilot ở quy trình quan trọng nhất: nên chọn quy trình rủi ro thấp để học.

Bài 3 sẽ dựng môi trường và chọn công cụ để bắt đầu ghép LLM vào RPA hiện có.