Tư duy thiết kế LLM Workflow | Thực tế có nhiều nghiệp vụ không cần AI tự quyết định

Bài viết này dành cho những người phụ trách lập kế hoạch sản phẩm hoặc nghiệp vụ, trình bày cách tổ chức xử lý AI nhiều bước dưới dạng workflow, từ góc nhìn của đội ngũ phát triển.

Khi xây dựng kế hoạch ứng dụng AI, kiến trúc agent có khả năng tự vận hành thường dễ trở thành lựa chọn đầu tiên.

Agent có thể tự đánh giá tình huống, lựa chọn công việc cần làm và tiếp tục xử lý. Điều đó rất hấp dẫn.

Tuy nhiên, khi cụ thể hóa nghiệp vụ cần xử lý, câu chuyện thường trở thành như sau:

“Trước tiên trích xuất các trường dữ liệu từ file đính kèm, đối chiếu với master khách hàng, tóm tắt nội dung, rồi đăng ký vào hệ thống.”

Thứ tự đã được xác định.

Nếu thứ tự đã được xác định, không có lý do gì phải để AI tự suy nghĩ xem nên làm theo thứ tự nào.

Điểm phân chia chỉ là “ai quyết định thứ tự”

Xử lý nhiều bước có sử dụng AI có hai hình thức. Khác biệt chỉ nằm ở một điểm.

• Workflow — con người viết thứ tự xử lý vào code
• Agent — AI tự quyết định thứ tự xử lý tại thời điểm thực thi

Một điểm dễ gây nhầm lẫn là: dùng workflow không có nghĩa là không dùng AI.

Ngay trong ví dụ phía trên, AI vẫn đảm nhiệm các bước như “trích xuất trường dữ liệu” và “tóm tắt nội dung”.
Thứ được cố định là thứ tự các công đoạn, không phải nội dung bên trong từng công đoạn.

Và khi thứ tự được cố định, hai điều sau sẽ thay đổi.

Vì số lần gọi AI cho mỗi trường hợp được xác định trước, có thể tính được chi phí và thời gian xử lý cho mỗi trường hợp. Nhân con số này với số lượng xử lý mỗi tháng, bạn có thể ước tính chi phí vận hành.

Vì input và output của từng công đoạn được xác định, có thể viết test cho từng công đoạn.

Trong trường hợp agent, số lần gọi AI và thứ tự xử lý có thể thay đổi tùy theo yêu cầu, nên hai yếu tố trên chỉ có thể được ước tính trong một khoảng.
Đây chính là cái giá của tính linh hoạt.

Điểm cần lưu ý
Nếu tách riêng hai vấn đề “phạm vi giao cho AI” và “chủ thể quyết định thứ tự”, việc thảo luận sẽ nhanh hơn.
Dù có bao nhiêu công đoạn sử dụng AI, nếu thứ tự đã được xác định thì đó vẫn là workflow.
Nếu quyết định “dùng agent” mà không phân biệt hai vấn đề này, một trình tự vốn đã được xác định có thể lại thay đổi ở mỗi lần chạy.

Chia thành từng công đoạn là cách chuẩn bị cho thất bại

Trong xử lý nhiều bước, chắc chắn sẽ có lúc một công đoạn nào đó thất bại.
API bên ngoài có thể không phản hồi, hệ thống quá tải dẫn đến timeout, hoặc server có thể khởi động lại.

Trong hệ thống được tổ chức dưới dạng workflow, kết quả của các công đoạn đã hoàn thành sẽ được lưu lại.

Trích xuất (xong) → Đối chiếu (xong) → Tóm tắt (xong) → Đăng ký (thất bại)
                                                        ↑ Chỉ chạy lại bước này

Ngay cả khi lỗi xảy ra ở công đoạn thứ 5, các công đoạn từ 1 đến 4 không cần chạy lại.

Ngược lại, nếu toàn bộ xử lý được gom thành một khối lớn, lợi ích này sẽ mất đi.
Nếu lỗi xảy ra ở bước cuối, toàn bộ quá trình phải chạy lại. Các lần gọi AI cũng phải thực hiện lại, đồng nghĩa với việc chi phí đó cũng phát sinh lại.

Vì vậy, cách chia ranh giới giữa các công đoạn trở thành một hạng mục thiết kế. Một tiêu chí tham khảo là tách thành công đoạn mới mỗi khi có một lần tương tác với hệ thống bên ngoài.
Nếu đặt việc gọi AI và ghi vào database trong cùng một công đoạn, khi chỉ thao tác ghi database thất bại, bạn sẽ phải thực hiện lại cả lần gọi AI.

Tuy nhiên, nếu chia quá nhỏ, lượng kết quả trung gian phải lưu và truyền giữa các công đoạn sẽ tăng lên.
Kết quả của mỗi công đoạn có giới hạn về kích thước có thể lưu, vì vậy dữ liệu lớn như hình ảnh hoặc PDF nên được đặt trong dịch vụ lưu trữ file và chỉ truyền tham chiếu giữa các công đoạn. Cách truyền dữ liệu này cần được quyết định trước.

Có thể viết cả việc “chờ” như một phần của quy trình

Quy trình nghiệp vụ luôn có những khoảng thời gian phải chờ.

Chờ đến sáng ngày làm việc tiếp theo. Chờ cấp trên phê duyệt. Chờ phản hồi từ đối tác.

Khi được tổ chức dưới dạng workflow, trạng thái chờ này có thể được giữ lại như một phần của quá trình xử lý. Có hai kiểu chờ.

Chờ theo thời gian — thời điểm kết thúc chờ đã được xác định, chẳng hạn “gửi nhắc nhở sau 3 ngày làm việc”. Thời gian chờ tối đa có thể thiết lập được nêu là 1 năm. Trong thời gian chờ, tiến trình không chiếm slot thực thi đồng thời, nên có thể để số lượng lớn case chờ song song.

Chờ một sự kiện — chờ một sự kiện không biết chính xác khi nào sẽ xảy ra, chẳng hạn “chờ đến khi nút phê duyệt được nhấn”. Khi notification hoặc phê duyệt đến, workflow sẽ tiếp tục từ công đoạn đó.

Điều này đặc biệt hữu ích trong nghiệp vụ phê duyệt.

Giữa lúc gửi yêu cầu và lúc được phê duyệt thường có một khoảng trống dài do lịch trình của con người.
Vì khoảng trống này có thể được giữ lại như một phần của quy trình, không cần tách “chương trình tiếp nhận yêu cầu” và “chương trình chạy sau khi phê duyệt” thành hai chương trình riêng, rồi tự quản lý trạng thái ở giữa bằng một bảng riêng.

Vì có thể viết toàn bộ dưới dạng một luồng duy nhất, việc theo dõi từng case hiện đang tiến đến đâu cũng trở nên dễ dàng hơn.

Mặt khác, chính vì có cơ chế chờ nên nếu không đặt thời hạn, tiến trình có thể tiếp tục tồn tại mà không kết thúc.
Một case đã chờ phê duyệt suốt một tháng thì nên xử lý thế nào? Tự động từ chối, gửi nhắc nhở, hay đưa vào danh sách cần xử lý của người phụ trách?

Đây không phải lựa chọn kỹ thuật mà là quy tắc nghiệp vụ, vì vậy phía lập kế hoạch cần quyết định từ trước.

Điểm cần lưu ý
Nhìn từ bên ngoài, một tiến trình đang chờ sẽ giống như trạng thái “không có gì xảy ra”.
Nếu không có màn hình cho người phụ trách biết từng case đang chờ điều gì, sẽ phát sinh các câu hỏi như “hệ thống đang dừng hay vẫn đang chạy?”.
Nếu đưa trạng thái chờ vào thiết kế, màn hình danh sách các case đang chờ cũng nên được đưa vào yêu cầu hệ thống.

Thiết kế công đoạn sao cho chạy hai lần cũng không bị hỏng

Một công đoạn bị lỗi có thể được tự động retry.

Điều đó có nghĩa là một xử lý vốn dự kiến chỉ chạy một lần có thể chạy hai lần.
Các hướng dẫn thiết kế công khai cũng cho rằng lý tưởng nhất là mỗi công đoạn nên được thiết kế sao cho dù chạy nhiều lần vẫn cho cùng một kết quả.

Mức độ ảnh hưởng hoàn toàn khác nhau tùy theo loại công đoạn.

Ba dòng bên dưới mới là vấn đề. Và đây không chỉ là câu chuyện về implementation.

Viết rằng “kiểm tra xem đã thực hiện hay chưa” nghe có vẻ đơn giản, nhưng thế nào được xem là cùng một xử lý lại là một định nghĩa nghiệp vụ.

Một khách hàng trong cùng một tháng chỉ được có một hóa đơn hay không? Nếu cùng số tiền thì vẫn có thể là hai hóa đơn khác nhau hay không?
Trước khi thiết kế, cần xác nhận xem trong dữ liệu nghiệp vụ có tồn tại một identifier đủ để thực hiện việc phân biệt này hay không.
Nếu không tồn tại, cần xây dựng chính cơ chế cấp identifier.

Ngoài ra, một số API bên ngoài, chẳng hạn dịch vụ thanh toán, có cơ chế chỉ chấp nhận một lần đối với request có cùng identifier.
Nếu có thể sử dụng cơ chế này thì thường đáng tin cậy hơn việc tự xây logic kiểm tra trùng lặp, vì vậy nên đưa tiêu chí này vào checklist khi lựa chọn dịch vụ.

Kết luận: Kết hợp cả hai là cách thực tế nhất

Nếu đặt workflow và agent thành bài toán chỉ được chọn một trong hai, quyết định sẽ trở nên khó khăn.

Trong thực tế, cấu trúc hợp lý là cố định toàn bộ luồng bằng workflow, và chỉ sử dụng agent ở những công đoạn mà không thể dự đoán trước trình tự xử lý.

Tiếp nhận (cố định) → Nghiên cứu (agent) → Chờ phê duyệt (cố định) → Đăng ký / Thông báo (cố định)

Không hiếm nghiệp vụ chỉ cần tính linh hoạt ở một công đoạn duy nhất.
Với công đoạn đó, đặt giới hạn số vòng trao đổi và giữ phần luồng bên ngoài ở trạng thái cố định.

Với cấu trúc này, ngay cả khi phần agent không hoạt động như mong đợi, chỉ cần thay công đoạn đó bằng điều kiện hoặc xử lý cố định.
Nếu ngay từ đầu biến toàn bộ quy trình thành agent, việc thay thế như vậy sẽ trở nên khó khăn.

Khi sắp xếp lại các tiêu chí so sánh, có thể thấy rằng lợi thế nổi bật của agent nằm ở việc xử lý “input ngoài dự kiến”.
Nghiệp vụ có thực sự cần khả năng đó hay không? Công đoạn nào mới thực sự cần nó? Làm rõ hai điểm này chính là công việc của phía lập kế hoạch.

Bài viết này được tổng hợp dựa trên kinh nghiệm phát triển của chúng tôi và các thông tin công khai. Thông số kỹ thuật và giới hạn của từng dịch vụ được cập nhật liên tục, vì vậy cách thiết kế tối ưu cũng có thể thay đổi theo thời gian. Chúng tôi cũng nhận tư vấn về thiết kế AI workflow.