Chatbot theo quy tắc vs chatbot LLM trong tự động hóa hỗ trợ khách hàng

Vấn đề chúng ta đang giải quyết trong hỗ trợ khách hàng

Tự động hóa hỗ trợ khách hàng có một mục tiêu thực tế: trả lời nhiều khách hàng hơn cho đúng, nhanh hơn, mà không làm đội ngũ cạn kiệt. Điều đó nghĩa là phải quyết định những yêu cầu nào phần mềm có thể xử lý an toàn, và những yêu cầu nào cần đến con người.

Chatbot hoạt động tốt nhất khi mục tiêu của khách hàng rõ ràng và các bước tiêu chuẩn: trạng thái đơn hàng, giờ mở cửa, đặt lại mật khẩu, cập nhật địa chỉ giao hàng trước khi vận chuyển, hoặc giải thích chính sách hoàn trả. Đây là các cuộc trò chuyện có khối lượng lớn, lặp lại, nơi tốc độ quan trọng hơn tính độc đáo của lời đáp.

Chúng gây ra vấn đề khi khách hàng rơi vào trường hợp ngoại lệ, khi chính sách có ngoại lệ, hoặc khi tình huống cần phán xét. Một bot tự tin đưa câu trả lời sai có thể khiến bạn mất tiền (hoàn tiền, chargeback), mất uy tín (khiếu nại công khai) và tốn thời gian (nhân viên dọn dẹp hậu quả). Đó là lý do cuộc tranh luận giữa theo quy tắc và LLM quan trọng: thực ra là về kết quả có thể dự đoán được, chứ không phải lời văn hoa mỹ.

Tính nhất quán quan trọng hơn câu trả lời khéo léo vì hỗ trợ là một phần của sản phẩm. Khách hàng muốn cùng một câu trả lời dù họ nói chuyện với ai, và nhân viên cần bot tuân theo cùng quy tắc. Một câu trả lời “hữu ích” mà vi phạm chính sách thì không hề hữu ích.

Cách thực tế để nhìn vấn đề là quyết định bạn muốn bot làm gì hàng ngày. Với hầu hết đội ngũ, đó là một hỗn hợp: xử lý triệt để các yêu cầu lặp lại hàng đầu, thu thập thông tin đúng trước khi chuyển giao, giảm thời gian chờ mà không giảm chất lượng câu trả lời, và luôn phù hợp với chính sách và thông tin sản phẩm hiện tại.

Hãy coi chatbot là một bước trong quy trình hỗ trợ, không phải toàn bộ quy trình. Kết quả bạn muốn là ít vé hơn và ít sai sót hơn, chứ không phải nhiều cuộc trò chuyện hơn.

Chatbot theo quy tắc và LLM bằng ngôn ngữ đơn giản

Khi mọi người so sánh chatbot theo quy tắc và LLM, họ đang so sánh hai cách khác nhau để quyết định phải nói gì.

Chatbot theo quy tắc tuân theo kịch bản. Bạn định nghĩa intent (ý định của khách, như “đặt lại mật khẩu” hay “tình trạng hoàn tiền”), rồi map mỗi intent thành cây quyết định. Bot đặt câu hỏi, kiểm tra câu trả lời và chuyển sang bước tiếp theo. Nó dễ dự đoán vì chỉ nói những gì bạn viết.

Chatbot LLM hoạt động giống một người viết linh hoạt hơn. Nó đọc tin nhắn khách, dùng ngữ cảnh hội thoại và sinh ra câu trả lời bằng ngôn ngữ tự nhiên. Nó xử lý cách diễn đạt lộn xộn và câu hỏi nhiều phần tốt hơn, nhưng cũng có thể phỏng đoán, giải thích quá mức, hoặc đi xa khỏi chính sách nếu bạn không giới hạn nó.

Các thiết lập lai phổ biến vì hỗ trợ cần cả an toàn và ngôn ngữ tự nhiên. Một phân chia hữu ích như sau:

• Quy tắc quyết định điều gì được phép (đủ điều kiện, hoàn tiền, bước xác minh, từ ngữ bắt buộc).
• LLM giúp phần cách diễn đạt (tông giọng, giải thích ngắn, tóm tắt ca trước khi chuyển giao).

Ví dụ, quy tắc xác nhận đơn hàng còn trong thời hạn trả hàng, sau đó LLM soạn một tin nhắn thân thiện khớp với giọng thương hiệu.

Cách chọn nhanh:

• Dùng chủ yếu quy tắc khi chính sách chặt chẽ, lỗi tốn kém và câu hỏi lặp lại.
• Dùng chủ yếu LLM khi câu hỏi đa dạng, ngôn ngữ khách không đoán trước được, và tiêu chí chuyển giao rõ ràng.
• Dùng cả hai khi bạn cần câu trả lời đúng theo chính sách nhưng vẫn muốn cuộc trò chuyện tự nhiên hơn.

Độ chính xác: lỗi thường gặp và biểu hiện của nó

Trong hỗ trợ, “độ chính xác” không chỉ là cung cấp thông tin đúng. Nó gồm ba điều cùng lúc: câu trả lời đúng, bao phủ đúng nhu cầu thực của khách (không trả lời nửa vời), và tuân thủ chính sách (quy tắc hoàn tiền, giới hạn an ninh, tuân thủ).

Chatbot theo quy tắc và LLM thường thất bại theo những cách khác nhau và có thể dự đoán trước.

Bot theo quy tắc thường phá vỡ khi thực tế không khớp với cây quyết định. Xuất hiện câu hỏi mới không có nhánh, khách dùng từ ngữ bất ngờ, hoặc bot chọn intent sai. Trải nghiệm là những câu trả lời đóng hộp không liên quan, menu lặp, hoặc “Vui lòng chọn một trong các tùy chọn này” dù khách đã giải thích vấn đề.

Bot LLM hay thất bại ở chỗ tự tin. Chúng có thể phỏng đoán chính sách, bịa đặt bước, hoặc lẫn lộn chi tiết sản phẩm. Trải nghiệm tệ hơn vì nghe có vẻ hữu ích nhưng sai. Một vấn đề khác là trôi chính sách: bot trả lời khác nhau giữa các cuộc chat, đặc biệt khi nó cố “tử tế” và nới lỏng quy tắc (ví dụ, đề nghị hoàn tiền ngoài hạn).

Để đo độ chính xác, dùng vé cũ thực tế và chấm kết quả, không phải cảm nhận. Gắn nhãn mẫu chat và theo dõi:

• Giải quyết chính xác (có giải quyết vấn đề khách không?)
• Tuân thủ chính sách (có hứa điều gì không nên hứa không?)
• Tỷ lệ chuyển giao (có chuyển khi cần không?)
• Tỷ lệ liên hệ lại trong 24–72 giờ (khách có quay lại không?)

Đôi khi câu trả lời chính xác nhất là một “tôi không biết” an toàn. Nếu câu hỏi chạm tới truy cập tài khoản, ngoại lệ thanh toán hoặc cần xác minh, chuyển giao rõ ràng tốt hơn phỏng đoán rủi ro. Một bot tốt xây dựng niềm tin bằng cách biết giới hạn và chuyển đúng người với đầy đủ ngữ cảnh.

Chi phí bảo trì: thời gian xây dựng so với nỗ lực duy trì

Sự khác biệt chi phí lớn nhất giữa bot theo quy tắc và LLM không nằm ở lần xây đầu tiên. Mà là chuyện xảy ra sau khi sản phẩm, giá cả và chính sách của bạn bắt đầu thay đổi.

Bot theo quy tắc tốn nhiều ở giai đoạn đầu vì bạn phải vẽ các luồng: intent, cây quyết định, ngoại lệ và các trigger chính xác để gửi hội thoại theo từng nhánh. Đó là công việc tỉ mỉ nhưng cho hành vi dự đoán được.

Bot LLM thường cảm thấy khởi động nhanh hơn vì bạn có thể chỉ vào trung tâm trợ giúp hoặc tài liệu nội bộ và viết hướng dẫn, rồi tinh chỉnh từ các cuộc chat thực. Đổi lại là kiểm soát liên tục.

Theo thời gian, công việc dịch chuyển:

• Bot theo quy tắc cần chỉnh sửa khi có thay đổi (bậc phí vận chuyển mới, đổi tên gói, ngoại lệ trong chính sách hoàn tiền).
• Bot LLM cần duy trì nguồn (tài liệu, macro, ghi chú sản phẩm) và rào chắn (hướng dẫn, guardrail), cùng kiểm tra định kỳ để đảm bảo câu trả lời vẫn khớp chính sách.

Ai chịu trách nhiệm duy trì quan trọng. Hệ thống quy tắc thường buộc support ops và product phải đồng thuận về các quy tắc chính xác, rồi ai đó triển khai và kiểm thử thay đổi. Hệ thống LLM có thể cập nhật nhiều hơn bởi support ops nếu knowledge base được sở hữu tốt, nhưng kỹ thuật vẫn cần cho truy xuất an toàn, ghi log và xử lý chuyển giao.

Các chi phí mà đội thường quên cho tới khi ra mắt gồm kiểm thử hồi quy sau thay đổi chính sách, giám sát câu trả lời rủi ro, xem xét hội thoại để đánh giá tông giọng và tuân thủ, và cập nhật nguồn khi phát hiện khoảng trống mới.

Tần suất thay đổi quyết định tổng chi phí. Nếu chính sách thay đổi hàng tuần, một cây quy tắc cứng sẽ nhanh trở nên đắt đỏ. Nếu chính sách ít thay đổi nhưng phải chính xác (như quy tắc bảo hành), bot theo quy tắc có thể rẻ hơn theo thời gian.

Giữ câu trả lời phù hợp chính sách

Bot hỗ trợ chỉ “tốt” khi nó theo cùng quy tắc mà nhân viên của bạn tuân thủ. Cách nhanh nhất để mất niềm tin là bot hứa hoàn tiền, thay đổi địa chỉ hoặc chia sẻ thông tin tài khoản theo cách chính sách không cho phép.

Bắt đầu bằng việc ghi ra những gì bot được phép làm mà không cần con người. Tập trung vào hành động, không chỉ chủ đề. “Có thể giải thích cách hoàn tiền hoạt động” khác với “có thể cấp hoàn tiền” hoặc “có thể huỷ đăng ký”. Càng nhiều quyền bot có thể thay đổi (tiền, truy cập, dữ liệu cá nhân), quy tắc càng phải chặt.

Dùng một nguồn duy nhất cho văn bản chính sách và macro. Nếu chính sách hoàn tiền nằm rải rác trong nhiều tài liệu và ghi chú của nhân viên, bạn sẽ có câu trả lời không thống nhất. Đặt văn bản đã được duyệt ở một nơi và tái sử dụng khắp nơi (chat, email, kênh nhắn tin). Đây là điểm mà bot theo quy tắc và LLM thường khác nhau: quy tắc ép buộc từ ngữ chính xác, còn LLM cần rào chắn mạnh để tránh trôi.

Rào chắn để giữ câu trả lời đúng chính sách

Rào chắn tốt thì đơn giản, rõ ràng và dễ kiểm thử:

• Đoạn văn được duyệt cho các chủ đề nhạy cảm (hoàn tiền, bảo hành, chargeback, truy cập tài khoản)
• Các khẳng định bị cấm (như “ngày giao hàng đảm bảo” hoặc “hoàn tiền ngay lập tức”)
• Các từ miễn trừ bắt buộc (kiểm tra danh tính, thời gian xử lý, điều kiện đủ)
• Các trường có cấu trúc mà bot phải thu thập trước khi thực hiện hành động (mã đơn hàng, email, 4 chữ số cuối)
• Quy tắc “không chắc thì chuyển giao” kích hoạt sớm

Phiên bản hóa và truy vết

Chính sách thay đổi. Hãy coi chúng như phần mềm: phiên bản hoá và ghi log phiên bản nào được dùng cho mỗi câu trả lời. Nếu khách tranh cãi về điều bot nói tuần trước, bạn có thể xem chính xác văn bản chính sách bot đã theo.

Ví dụ: một cửa hàng thương mại điện tử cập nhật thời hạn trả hàng từ 30 xuống 14 ngày. Với phiên bản hoá, bot có thể trả lời dựa trên ngày đặt hàng và bạn có thể kiểm tra các trường hợp biên sau đó.

Luồng chuyển giao không khiến khách bực bội

Một chatbot tốt bằng giá trị của việc chuyển giao. Khi mọi người cảm thấy bị kẹt trong vòng lặp, họ ngừng tin tưởng kênh đó. Dù bạn chọn bot theo quy tắc hay LLM, hãy thiết kế chuyển giao như một phần bình thường của trải nghiệm, không phải là thất bại.

Bắt đầu với các trigger rõ ràng để chuyển sang người thật mà không bắt khách hàng vòi vĩnh. Trigger phổ biến gồm độ tự tin thấp, từ khoá như “hoàn tiền”, “chargeback”, “pháp lý”, “hủy”, cảm xúc tiêu cực mạnh, giới hạn thời gian không tiến triển, hoặc nhiều lần thất bại ở cùng bước.

Khi chuyển giao xảy ra, đừng bắt khách lặp lại. Chuyển một gói ngữ cảnh ngắn gọn tới nhân viên:

• Tóm tắt ngắn gọn vấn đề bằng ngôn ngữ đơn giản
• Thông tin khách đã biết (tên, tài khoản, mã đơn)
• Những gì bot đã hỏi và người dùng đã trả lời
• Các bước đã thử và kết quả
• Các file, ảnh chụp màn hình hoặc mã lỗi đã chia sẻ

Đặt kỳ vọng trong một câu: chuyện gì sẽ xảy ra tiếp và mất khoảng bao lâu. Ví dụ: “Tôi đang gửi tới chuyên viên hỗ trợ. Thời gian chờ thông thường khoảng 5 phút. Bạn có thể tiếp tục nhắn ở đây.”

Làm cho chuyển giao có thể đảo ngược. Nhân viên thường muốn bot xử lý các bước thường quy (thu thập log, các bước khắc phục cơ bản, lấy thêm thông tin) trong khi họ tập trung vào ngoại lệ. Một nút “gửi khách danh sách kiểm tra do bot hướng dẫn” đơn giản tiết kiệm thời gian và giữ dịch vụ nhất quán.

Cuối cùng, theo dõi lý do chuyển giao. Gắn tag lý do (độ tự tin thấp, yêu cầu chính sách, khách giận, thiếu dữ liệu) và xem lại các lý do hàng đầu hàng tuần. Vòng phản hồi đó là cách bot tiến bộ mà không trở nên rủi ro.

Từng bước: chọn và triển khai chatbot phù hợp

Bắt đầu nhỏ có mục đích. Tự động hoá vài câu hỏi lặp lại trước, rồi cải thiện từ transcript thực. Cách này hiệu quả dù bạn chọn bot theo quy tắc hay LLM, vì phần khó không phải là mô hình mà là quyết định về chính sách, chuyển giao và đo lường.

Kế hoạch triển khai thực tế

1. Chọn 3–5 loại vé có khối lượng cao và rủi ro thấp. Khởi đầu tốt: trạng thái đơn hàng, đặt lại mật khẩu, giờ mở cửa, tóm tắt chính sách hoàn tiền. Tránh những thứ có thể gây mất tiền hoặc thay đổi tài khoản cho đến khi bạn tin tưởng luồng.

2. Định nghĩa thành công trước khi xây. Chọn 2–3 chỉ số theo dõi hàng tuần, như tỷ lệ giải quyết không cần người, CSAT sau chat, và số phút tiết kiệm trên ca làm việc của nhân viên.

3. Viết quy tắc chính sách và danh sách ngắn “không bao giờ làm”. Ví dụ: không xác nhận danh tính mà không có bước xác minh, không hứa ngày giao không thấy, không yêu cầu số thẻ đầy đủ.

4. Xây các đường chính và một fallback thực tế. Soạn câu trả lời lý tưởng, rồi thêm chế độ lỗi lịch sự khi bot không chắc: nhắc lại những gì hiểu, hỏi một câu làm rõ, hoặc đề nghị chuyển giao. Nếu dùng LLM, giữ các chủ đề nhạy cảm neo vào các đoạn đã duyệt.

5. Chạy pilót với khách thật, rồi mở rộng. Giữ giới hạn (một kênh, một đội, một tuần). Xem transcript hàng ngày, gắn lỗi (intent sai, thiếu dữ liệu, rủi ro chính sách), cập nhật luồng, rồi mới thêm chủ đề.

Sai lầm phổ biến và bẫy cần tránh

Cách nhanh nhất để thất vọng với chatbot theo quy tắc hay LLM là coi chúng như cùng một công cụ. Chúng thất bại khác nhau, nên bẫy cũng khác.

Một sai lầm hay gặp là trộn “những gì bot phải làm” (chính sách) với “nên nói thế nào” (tông giọng) trong một mớ hướng dẫn. Tông giọng linh hoạt. Chính sách thì không. Giữ chính sách rõ ràng, có thể kiểm thử (hạn hoàn tiền, kiểm tra danh tính, điều gì không bao giờ hứa), rồi để bot áp dụng giọng thân thiện lên trên.

Bẫy rủi ro cao khác là để bot trả lời câu hỏi liên quan tài khoản mà không có cổng kiểm soát cứng. Nếu người dùng hỏi “Đơn hàng của tôi ở đâu?”, bot không nên đoán. Nó nên yêu cầu xác minh hoặc chuyển tới hệ thống an toàn có thể lấy dữ liệu chính xác.

Cần cảnh giác các mô hình trước khi ra mắt:

• Không có fallback thực, nên bot cứ đoán khi không chắc
• Chỉ kiểm thử các câu hỏi lịch sự, rõ ràng và bỏ qua câu giận dữ hoặc mơ hồ
• Cho phép bot sáng tạo ngoại lệ và ưu đãi đặc biệt
• Không có vòng xem lại con người, khiến sai lặp lại mãi
• Không chuyển toàn bộ transcript cho nhân viên, buộc khách lặp lại

Ví dụ đơn giản: khách viết “App của bạn trừ tiền tôi hai lần. Sửa ngay.” Nếu bot không sẵn sàng cho cảm xúc và tính cấp bách, nó có thể trả lời FAQ thanh toán chung. Tốt hơn là lời xin lỗi ngắn, một câu hỏi làm rõ (phương thức thanh toán và thời gian), và bước tiếp theo rõ ràng: bắt workflow đúng hoặc chuyển giao.

Danh sách kiểm tra nhanh trước khi bật

Trước khi bật tự động hóa hỗ trợ cho tất cả khách, coi bot như một nhân viên mới: cần đào tạo, ràng buộc và giám sát. Đây là cách nhanh nhất để tránh chuyển giao không cần thiết và sai phạm chính sách, dù bạn chọn theo quy tắc hay LLM.

• Nguồn câu trả lời được khoá. Bot chỉ trả lời từ nội dung chính sách đã duyệt (quy tắc hoàn tiền, thời gian vận chuyển, điều khoản bảo hành, quy tắc an ninh). Nếu không tìm được khớp, nó nói vậy và đề nghị chuyển giao.
• Chuyển giao rõ ràng và luôn có. Định nghĩa trigger (ngôn ngữ giận dữ, vấn đề truy cập tài khoản, tranh chấp thanh toán, yêu cầu pháp lý, “điều đó không giúp”), đảm bảo “nói chuyện với người” hoạt động bất kỳ lúc nào.
• Bạn có thể kiểm toán mọi cuộc hội thoại. Lưu câu hỏi người dùng, câu trả lời bot, nguồn đã dùng (hoặc “không”), và kết quả (giải quyết, chuyển giao, bỏ dở).
• Bạn có thói quen xem xét hàng tuần. Trong tháng đầu, xem lại các nhóm lỗi lớn nhất (chính sách sai, trả lời không đầy đủ, ngôn ngữ không rõ, định tuyến sai) và biến thành các sửa có thể kiểm thử.
• Cập nhật chính sách có kế hoạch kiểm thử. Khi chính sách thay đổi, cập nhật nội dung nguồn và chạy lại một tập câu chat bắt buộc qua (yêu cầu hoàn tiền, đổi địa chỉ, trì hoãn giao hàng, đặt lại mật khẩu, khách giận).

Ví dụ thực tế: chat hỗ trợ cho thương mại điện tử

Hãy tưởng tượng một nhãn hàng ecommerce nhỏ với ba yêu cầu chat hàng đầu: “Đơn hàng của tôi đâu?”, “Tôi cần đổi địa chỉ giao hàng”, và “Tôi muốn hoàn tiền.” Đây là nơi so sánh theo quy tắc vs LLM trở nên rất thực tế.

Với trạng thái đơn hàng, bot theo quy tắc thường là tuyến đầu an toàn nhất. Nó hỏi mã đơn và email, kiểm tra trạng thái đơn với nhà vận chuyển, rồi trả lời nhất quán: vị trí hiện tại, khoảng thời gian giao dự kiến, và làm gì nếu gói hàng trễ. Không phỏng đoán.

Đổi địa chỉ cũng là luồng phù hợp cho quy tắc vì quy tắc rõ ràng. Bot kiểm tra đơn còn chưa giao, xác nhận địa chỉ mới rồi cập nhật. Nếu đơn đã gửi, nó dừng lại và đưa bước tiếp theo đúng (liên hệ nhà vận chuyển hoặc tạo trả hàng sau khi giao).

Bot LLM hữu ích nhất khi tin nhắn của khách lộn xộn hoặc cảm xúc. Nó có thể diễn đạt lại yêu cầu của khách, thu thập chi tiết còn thiếu và tóm tắt ca cho nhân viên. Mục tiêu không phải là kéo dài hội thoại mà là chuyển giao sạch hơn.

Hoàn tiền là nơi cần chuyển giao và từ ngữ kiểm soát chặt. Bot nên chuyển khi quyết định phụ thuộc vào ngoại lệ hoặc bằng chứng: hàng hư hỏng (cần ảnh), gói mất sau khi đã scan “đã giao”, yêu cầu ngoài cửa sổ chính sách, dấu hiệu chargeback hoặc đơn giá trị cao.

Để giữ câu trả lời phù hợp chính sách, coi thông điệp hoàn tiền cuối cùng là mẫu đã kiểm soát, không phải văn tự do bot tự do viết. Cho LLM chỉ điền các ô đã được duyệt (ngày, mã đơn, bước tiếp theo) trong khi văn bản chính sách giữ cố định.

Bước tiếp theo: xây dựng hệ thống tự động hóa hỗ trợ bền vững

Chọn một lát hỗ trợ có khối lượng cao và rủi ro thấp (trạng thái đơn, đặt lại mật khẩu, đổi địa chỉ) và chỉ tự động hóa phần đó. Mở rộng dựa trên thứ thực sự giảm vé và tiết kiệm thời gian nhân viên.

Chọn kiểu theo mức rủi ro, không phải theo sở thích. Với câu trả lời mang tính thực tế, nặng chính sách, quy tắc hay luồng có cấu trúc thường thắng. Với câu hỏi lộn xộn (“tôi nên làm gì tiếp theo?”), LLM có thể giúp, nhưng chỉ với rào chắn. Nhiều đội chọn lai: quy tắc cho phần phải chính xác, LLM cho soạn câu, tóm tắt và định tuyến.

Kế hoạch xây dựng đơn giản bạn có thể dùng cho mọi kênh:

• Thu thập đầu vào rõ ràng trong chat (chuyện gì xảy ra, mã đơn, email)
• Quy tắc định tuyến (thanh toán, vận chuyển, kỹ thuật) với tuỳ chọn chuyển giao người
• Kiểm tra xác thực cho yêu cầu liên quan tài khoản
• Nhật ký kiểm toán cho những gì bot nói và dữ liệu nó dùng
• Mẫu đã duyệt cho các chủ đề nhạy cảm (hoàn tiền, quyền riêng tư, huỷ)

Nếu bạn muốn triển khai các luồng đó mà không xây mọi thứ từ đầu, AppMaster (appmaster.io) có thể dùng để mô hình dữ liệu, xây quy trình hỗ trợ với logic kinh doanh trực quan và kết nối chuyển giao chat tới hệ thống backend theo dõi yêu cầu và phiên bản chính sách.