Bài 3 — Scripted flow và LLM tự do: chọn đúng công cụ cho đúng việc

Scripted flow vs LLM tự do: đánh đổi cốt lõi của CAI PM

Đây là quyết định kiến trúc quan trọng nhất bạn sẽ đưa ra. Chọn sai, bạn sẽ có một bot hoặc quá cứng nhắc, hoặc quá bất ổn định. Chọn đúng, bạn có sản phẩm vừa mượt vừa an toàn.

Hai thái cực

Scripted flow (luồng kịch bản): cuộc hội thoại đi theo các bước định sẵn dạng cây quyết định. Bot hỏi A → nếu trả lời X thì sang B, nếu Y thì sang C. Giống form thông minh biết nói chuyện.

• Ưu điểm: đoán trước được (predictable), an toàn, dễ tuân thủ quy định, dễ test, rẻ khi vận hành.
• Nhược điểm: cứng, không xử lý được câu lệch kịch bản, viết luồng tốn công, dễ tạo cảm giác "máy móc".

LLM tự do (generative): dùng mô hình ngôn ngữ lớn trả lời linh hoạt theo ngữ cảnh, không cần luồng cố định.

• Ưu điểm: linh hoạt, hiểu ngôn ngữ tự nhiên tốt, xử lý câu ngoài kịch bản, trả lời tự nhiên.
• Nhược điểm: khó đoán trước, có thể hallucinate (bịa thông tin), khó kiểm soát tuân thủ, tốn token/chi phí, khó test triệt để.

Khung quyết định: khi nào dùng cái nào

Dùng bảng tiêu chí này để chọn theo từng tác vụ (không phải chọn một lần cho cả bot):

Nguyên tắc vàng: dùng scripted flow cho phần rủi ro cao và có quy trình chuẩn; dùng LLM cho phần hiểu ngôn ngữ và trò chuyện linh hoạt.

Kiến trúc hybrid (thực tế nhất)

Sản phẩm tốt hiếm khi thuần một bên. Mô hình hybrid phổ biến:

• LLM/NLU ở đầu vào: hiểu câu nói tự nhiên của người dùng, phân loại intent, trích entity.
• Scripted flow ở phần thực thi rủi ro: khi đã xác định người dùng muốn "chuyển tiền", chuyển sang luồng kịch bản chặt chẽ (xác nhận số tiền, người nhận, OTP).
• LLM có kiểm soát ở phần trả lời: viết lại câu trả lời cho tự nhiên nhưng dựa trên nội dung đã được duyệt (RAG — chỉ trả lời từ tài liệu tin cậy).

Ví dụ cụ thể

Bot đặt vé máy bay:

• Khách: "Tui muốn bay Sài Gòn ra Hà Nội cuối tuần này, rẻ rẻ thôi" → LLM hiểu ý, trích from, to, date_range, preference=cheap.
• Chọn chuyến và thanh toán → scripted flow cứng: xác nhận từng thông tin, hiển thị giá cuối, yêu cầu đồng ý điều khoản. Tuyệt đối không để LLM tự "ứng biến" bước trừ tiền.
• Khách hỏi "đi Hà Nội tháng này thời tiết sao?" → LLM trả lời thoải mái vì rủi ro thấp.

Kiểm soát LLM: các "dây an toàn"

Khi dùng LLM, PM phải yêu cầu các cơ chế: guardrails (chặn chủ đề cấm), grounding/RAG (chỉ trả lời từ nguồn tin cậy để giảm bịa), system prompt chặt chẽ định nghĩa vai trò và giới hạn, và fallback sang scripted khi câu hỏi chạm vùng rủi ro.

Checklist ra quyết định

• [ ] Đã phân loại từng tác vụ theo mức rủi ro nếu bot sai?
• [ ] Các bước liên quan tiền/pháp lý/danh tính đã dùng scripted flow chưa?
• [ ] LLM đã bị ràng vào nguồn dữ liệu (RAG) thay vì trả lời tự do?
• [ ] Có guardrail chặn chủ đề cấm và hành vi ngoài phạm vi?
• [ ] Đã có kế hoạch test cho phần LLM (vốn khó test hơn scripted)?

Sai lầm thường gặp

• "LLM hóa" toàn bộ bot vì thấy nó thông minh — dẫn tới bot bịa thông tin ở đúng chỗ nguy hiểm nhất.
• Giữ mọi thứ scripted vì sợ rủi ro — bot cứng nhắc, người dùng gõ lệch một chữ là hỏng.
• Để LLM tự thực thi hành động nhạy cảm (hoàn tiền, khóa tài khoản) không qua bước xác nhận cứng.
• Không có RAG/grounding khiến LLM trả lời chính sách công ty bằng thông tin bịa.

Bài sau ta chuyển sang phần "con người": khi nào và làm thế nào để bot bàn giao cho nhân viên thật một cách mượt mà.