Khi nào nên dùng AI step, khi nào nên giữ deterministic trong workflow production

BÀI VIẾT THỰC CHIẾN
Khi nào nên dùng AI step, khi nào nên giữ deterministic trong workflow production / ETHANCORP

Bài học ngắn: AI không nên đứng ở mọi chỗ trong workflow production.

Nếu một bước có rule rõ, output phải đúng y hệt mỗi lần, hoặc sai một chút là làm hỏng quy trình phía sau, hãy giữ nó deterministic. Nếu một bước cần hiểu ngôn ngữ tự nhiên, xử lý ngữ cảnh lộn xộn, hoặc biến input mơ hồ thành cấu trúc có ích, lúc đó mới đáng dùng AI.

Nói thẳng: nhiều workflow AI không hỏng vì model dở. Nó hỏng vì team giao cho AI những việc đáng lẽ chỉ cần một node IF, một đoạn regex, hoặc một hàm validation 10 dòng.

Vấn đề thật: reliability gap không nằm ở model

Trong bài Production AI Playbook: Deterministic Steps & AI Steps, n8n mô tả một pattern rất quen: team gắn LLM vào workflow, kết quả demo nhìn ổn, summary nghe tự nhiên, classification có vẻ đúng. Rồi khi chạy thật, edge case bắt đầu xuất hiện.

  • Tên khách hàng có ký tự đặc biệt làm hỏng parsing.
  • Ticket support viết mỉa mai bị phân loại thành feedback tích cực.
  • Email do AI viết nghe rất hay nhưng bịa ra một tính năng sản phẩm không tồn tại.

Đây là AI reliability gap. Nhưng lỗi thường không nằm ở “AI chưa đủ thông minh”. Lỗi nằm ở phần xung quanh model: input bẩn, thiếu validation, routing mơ hồ, context thiếu cấu trúc, và không có lớp kiểm tra output trước khi đẩy xuống bước tiếp theo.

Cách sửa không phải là thêm AI. Thường là dùng ít AI hơn, đúng chỗ hơn.

Rule thực dụng: bước nào có thể viết thành luật thì đừng gọi LLM

Một bước nên là deterministic nếu bạn có thể mô tả nó bằng luật rõ ràng:

  • Nếu email không có @ thì reject.
  • Nếu order value trên 10 triệu thì gắn tag VIP.
  • Nếu country là Việt Nam thì route về sales team A.
  • Nếu date không parse được thì đưa vào error queue.

Những bước này không cần “suy nghĩ”. Chúng cần ổn định. Dùng LLM ở đây là tự tăng chi phí, tăng latency, và thêm một điểm hỏng khó debug.

Ngược lại, AI đáng dùng khi input không gọn thành rule cứng:

  • Phân loại intent từ một đoạn tin nhắn khách hàng dài và lộn xộn.
  • Tóm tắt feedback nhiều đoạn thành các vấn đề chính.
  • Rút thông tin từ email không theo template cố định.
  • Đề xuất phản hồi theo tone và context của cuộc hội thoại.

AI nên xử lý phần mơ hồ. Deterministic logic nên xử lý phần chắc chắn.

Cách thiết kế workflow hybrid cho production

Một workflow AI đáng tin thường không phải “LLM từ đầu đến cuối”. Nó là một chuỗi hybrid:

  1. Normalize input: chuẩn hóa field, format ngày tháng, trim whitespace, bỏ HTML thừa.
  2. Validate input: kiểm tra required fields, kiểu dữ liệu, range hợp lệ.
  3. Enrich context: lấy thêm dữ liệu từ CRM, database, API nội bộ nếu cần.
  4. Call AI: chỉ gửi phần cần AI diễn giải hoặc tạo nội dung.
  5. Validate output: kiểm tra JSON schema, field bắt buộc, độ dài, forbidden claims.
  6. Route deterministically: quyết định bước tiếp theo bằng rule rõ, không để AI tự “muốn làm gì thì làm”.

Điểm quan trọng là AI không được là người cầm lái toàn bộ workflow. AI nên là một worker trong hệ thống. Hệ thống vẫn phải có lan can.

Ví dụ gần với vận hành thật

Giả sử bạn có workflow xử lý inbound lead từ website.

Không nên làm:

  • Gửi toàn bộ payload vào LLM.
  • Bảo AI tự kiểm tra email, tự phân loại lead, tự quyết định route, tự viết phản hồi.
  • Nếu AI trả về sai format thì workflow vẫn tiếp tục chạy.

Cách này demo nhanh, nhưng production dễ vỡ.

Nên làm:

  • Dùng deterministic step để chuẩn hóa name/email/company/source.
  • Dùng regex hoặc validation function để kiểm tra email.
  • Dùng rule để loại spam rõ ràng.
  • Chỉ dùng AI để đọc phần message và phân loại intent: “muốn tư vấn automation”, “hỏi giá”, “support”, “khác”.
  • Dùng schema validation để buộc AI trả về JSON đúng format.
  • Dùng Switch/IF node để route lead theo intent + company size + source.

Workflow này chậm hơn demo 10 phút lúc build, nhưng tiết kiệm hàng giờ debug sau đó.

Bảng quyết định nhanh

Câu hỏi Nếu câu trả lời là “có”
Có rule rõ không? Dùng deterministic.
Cần output giống hệt mỗi lần không? Dùng deterministic.
Sai 5% có làm hỏng downstream không? Dùng deterministic + validation, không để AI quyết định cuối.
Input là text tự nhiên, mơ hồ, nhiều biến thể không? Cân nhắc dùng AI.
Cần tone, tóm tắt, diễn giải, phân loại intent không? AI có đất dụng võ.
Có thể validate output bằng schema không? Nếu không, chưa nên đưa vào production.

30 phút đầu nên làm gì

Nếu bạn đang có một workflow AI chạy chưa ổn, đừng sửa prompt ngay. Làm việc này trước:

  1. Liệt kê toàn bộ step trong workflow: input, output, mục đích từng bước.
  2. Đánh dấu xanh các bước có rule rõ: validation, formatting, lookup, calculation, routing theo field cố định.
  3. Đánh dấu đỏ các bước cần hiểu ngôn ngữ, context, hoặc dữ liệu không cấu trúc.
  4. Kiểm tra mỗi bước đỏ: nếu AI trả sai 10%, hệ thống có vỡ không?
  5. Thêm validation sau AI: JSON schema, required fields, allowlist/denylist, confidence threshold nếu có.
  6. Log output mẫu trong 20–50 execution đầu để xem AI lệch ở đâu.

Sau 30 phút, bạn phải trả lời được một câu: workflow này đang dùng AI vì thật sự cần AI, hay vì team lười viết rule?

Sai lầm thường gặp

  • Dùng LLM cho validation đơn giản: check email, so sánh số, parse date. Đây là việc của code/node thường.
  • Không có output contract: AI trả gì cũng nhận, đến lúc downstream vỡ mới biết.
  • Không tách AI step thành module riêng: prompt, context, schema, retry, fallback bị trộn vào logic chính.
  • Không có fallback: AI lỗi là cả workflow chết, thay vì route sang review queue hoặc path an toàn.
  • Đánh giá bằng cảm giác: “thấy câu trả lời thông minh hơn” nhưng không đo tỷ lệ lỗi, latency, chi phí, rework.

Checklist trước khi đưa AI step vào production

  • Input đã được normalize trước khi gửi vào AI.
  • Prompt có context đủ, không bắt model đoán dữ liệu thiếu.
  • Output có schema rõ và được validate bằng deterministic step.
  • Có fallback khi AI fail, timeout, hoặc trả format sai.
  • Có log để audit input/output của AI step.
  • Có owner chịu trách nhiệm theo dõi quality trong giai đoạn đầu.

Nếu thiếu 3/6 điểm trên, đừng gọi nó là production. Gọi nó là thử nghiệm có thể vỡ.

Kết luận

AI workflow tốt không phải workflow dùng AI nhiều nhất. Nó là workflow biết đặt AI đúng chỗ.

Deterministic step giữ hệ thống ổn định. AI step xử lý phần con người khó viết thành rule. Hai phần này không cạnh tranh nhau. Chúng bổ sung cho nhau.

Việc của operator không phải là hỏi “có nên dùng AI không?”. Câu hỏi đúng là: AI nên đứng ở bước nào, bị kiểm soát bởi rule nào, và khi nó sai thì workflow rơi về đâu?

Đọc thêm nội bộ EthanCorp

Nguồn tham chiếu

Muốn biến nội dung này thành kết quả kinh doanh thật?

Nhận lộ trình automation/integration phù hợp hệ thống hiện tại của bạn.

Scroll to Top