AI đụng workflow 20 năm — chọn lớp nào mới sống

AI đụng workflow 20 năm — chọn lớp nào mới sống

Hai case study từ Halliburton và Mozilla cho thấy: AI không fail vì model yếu, mà vì team chọn sai lớp can thiệp trong hệ thống đang chạy.

Bạn đang ngồi trước một hệ thống chạy ổn hơn chục năm. Sếp bảo "gắn AI vào đi." Câu hỏi đầu tiên không phải chọn model nào — mà là chạm vào lớp nào của hệ thống. Chọn sai, AI trở thành lớp phức tạp thêm mà chẳng ai muốn bảo trì. Chọn đúng, nó mở khóa được giá trị mà team thủ công không bao giờ đuổi kịp.

Hai case study gần đây — một từ ngành năng lượng, một từ ngành bảo mật trình duyệt — cho thấy rõ điều này.

Bối cảnh: hai đội, cùng thách thức

Halliburton vận hành Seismic Engine — ứng dụng cloud-native xử lý dữ liệu địa chấn. Mỗi workflow yêu cầu cấu hình khoảng 100 tool chuyên biệt, ghép nối thủ công. Người dùng phải vừa hiểu địa vật lý, vừa rành kiến trúc hệ thống. Thời gian thiết lập một workflow: hàng giờ, đôi khi hàng ngày.

Phía bên kia, Mozilla đối mặt với codebase Firefox — hơn 20 năm lịch sử, hàng triệu dòng code, lỗ hổng bảo mật nằm sâu trong những lớp mà ít ai còn nhớ context. Các đợt audit truyền thống (fuzzing, review thủ công) chỉ bắt được một phần. Những lần thử trước với GPT-4 và Claude Sonnet 3.5 theo kiểu read-only — đọc code rồi báo bug — cho ra đống false positive (báo lỗi sai), tốn thời gian verify hơn cả tự tìm.

Cả hai đội đều chung một điểm: hệ thống đã chạy production lâu năm, domain knowledge dày đặc, và AI không thể "thay thế" — chỉ có thể "can thiệp đúng chỗ."

Quyết định: cùng đích, khác cách cắt

Halliburton chọn xây lớp hội thoại phía trên. Dùng Amazon Bedrock Knowledge Bases làm RAG — model trả lời dựa trên tài liệu nội bộ thay vì tự bịa — để chuyên gia mô tả workflow bằng ngôn ngữ tự nhiên. Model không chạm vào engine xử lý bên dưới, chỉ sinh ra cấu hình rồi đẩy xuống. Phần còn lại: Amazon Nova xử lý ngôn ngữ, DynamoDB giữ session state (trạng thái phiên làm việc).

Quyết định cốt lõi: AI chỉ đóng vai lớp dịch — từ ngôn ngữ người sang cấu hình máy. Logic xử lý địa chấn vẫn nguyên vẹn.

Mozilla đi hướng khác hẳn. Thay vì để AI đọc rồi báo cáo, họ xây agentic pipeline (quy trình tự hành) — AI tự viết test case, tự chạy trên hệ thống build, tự xác nhận bug có thật hay không trước khi báo developer. Claude Mythos Preview không chỉ phân tích code, mà tương tác trực tiếp với môi trường thực thi.

Quyết định cốt lõi: AI phải tự verify trước khi report. Đây là lý do tỉ lệ false positive giảm rõ rệt so với mọi lần thử trước.

Hệ quả: phần đẹp và phần ít ai nhắc

Halliburton báo cáo tăng tốc lên đến 95% cho việc tạo workflow. Mozilla tìm được 271 lỗ hổng chưa biết trong Firefox 150, một số tồn tại gần 20 năm. Con số ấn tượng — nhưng nếu dừng ở đó thì bạn đang đọc press release, không phải case study.

Phần ít ai nhắc ở Halliburton: để RAG hoạt động, họ phải chuẩn hóa toàn bộ tài liệu của khoảng 100 tool — mô tả tham số, ràng buộc, use case hợp lệ. Nếu tài liệu nội bộ lộn xộn, RAG sẽ trả ra cấu hình sai mà người dùng không nhận ra. Dịch sang bối cảnh team Việt Nam: giả sử bạn muốn gắn AI lên hệ thống ERP nội bộ có 50 module — bước đầu tiên không phải chọn model, mà là kiểm kê documentation từng module. Không có bước này, AI chỉ hallucination — bịa cấu hình trông hợp lý nhưng sai chi tiết.

Phần ít ai nhắc ở Mozilla: agentic pipeline tốn chi phí inference gấp nhiều lần kiểu read-only. Mỗi lần AI tự viết test, tự chạy, tự đánh giá là một chuỗi API call liên hoàn. Model cũ hơn đã thử kiểu đọc-và-báo nhưng fail. Chỉ khi model đủ mạnh kết hợp pipeline tự xác minh, kết quả mới đáng tin. Rút ra: agentic pipeline không phải plug-and-play. Nếu team chưa có CI/CD đủ vững để AI tự chạy test trong sandbox, thì workflow kiểu Halliburton — AI sinh config, người duyệt — an toàn hơn nhiều.

Bài học: chọn tầng tán trước khi trồng cây mới

Hệ thống legacy giống rừng già — mỗi tầng tán có vai trò riêng, chặt bừa một tầng là cả hệ sinh thái chao đảo. Từ hai case study, mình đúc ra ba câu hỏi cần trả lời trước khi đưa AI vào workflow đang chạy:

1. AI sẽ đứng ở tầng nào?

2. Domain knowledge nằm ở đâu?

3. Team có đủ guardrail cho lớp AI đó chưa?

Áp dụng: giả sử team bạn 6 người

Team 6 người ở Việt Nam, đang vận hành data pipeline nội bộ với 30-40 bước xử lý, mỗi bước cần config riêng. Hai hướng đi:

Hướng 1 — Lớp dịch (low-risk): Dùng Amazon Bedrock Knowledge Bases hoặc open-source alternative như LlamaIndex kết hợp vector database để xây chatbot nội bộ. Đầu vào: tài liệu mô tả từng bước pipeline. Đầu ra: config gợi ý, người duyệt trước khi apply. Mốc thử nghiệm: một sprint.

Hướng 2 — Lớp tự hành (high-risk, high-reward): Xây agentic pipeline cho phần test và QA. AI viết test case cho từng bước, tự chạy trên staging, báo kết quả. Cần CI/CD ổn định và sandbox riêng. Mốc thử nghiệm: hai đến ba sprint.

Đa số team nên bắt đầu từ hướng 1. Không phải vì hướng 2 kém — mà vì hướng 1 buộc bạn kiểm kê documentation trước, và bước đó có giá trị kể cả khi AI không hoạt động như kỳ vọng.

Cái bẫy quen thuộc

Mình thấy một pattern lặp: team đọc case study, thấy con số đẹp, lao thẳng vào hướng agentic mà bỏ qua bước kiểm kê tài liệu. Kết quả? AI generate config trông hợp lý nhưng sai ở chi tiết nhỏ — đúng kiểu cây ngoại lai chen vào rừng bản địa: nhìn xanh tốt, nhưng phá gốc rễ bên dưới. Một team ở TPHCM kể với mình: mất khoảng hai tuần debug vì AI gợi ý sai thứ tự bước trong ETL pipeline. Nguyên nhân gốc? Documentation nội bộ thiếu ràng buộc thứ tự giữa các bước.

Bản chất thật sự: AI không thất bại vì model yếu. Nó thất bại vì team chưa biết rõ hệ thống của chính mình.

---

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

Nguồn tham khảo