Skip to content
EasyAlo
11 phút đọc

Chatbot AI mà website có thể tin được

Nối một mô hình ngôn ngữ mất một buổi chiều. Phần việc thật là quyết định chatbot được nói gì, kiến thức của nó đến từ đâu và điều gì xảy ra khi nó không biết.

Nhóm sản phẩm xem lại hội thoại chatbot, kho kiến thức và quy tắc chuyển tiếp cho trợ lý trên website
ai · web

Chatbot hiện là tính năng dễ demo nhất và cũng dễ làm sai nhất. Một model, một API key và một nút nổi ở góc phải là đủ để tạo ra thứ gây ấn tượng khi trình bày nhưng không đáng tin khi chạy thật, vì bản demo không bao giờ hỏi điều gì xảy ra khi câu trả lời bị bịa, khi hết quota, hoặc khi khách hỏi về một mức giá vừa thay đổi tuần trước.

Phiên bản đáng phát hành thường hẹp hơn nhiều so với hình dung ban đầu. Nó trả lời một tập câu hỏi đã xác định, dựa trên nội dung doanh nghiệp kiểm soát được, nói thẳng khi không giúp được, và chuyển hội thoại cho con người theo một đường mà thật sự có người theo dõi.

1. Xác định công việc trước khi chọn model

“Một chatbot cho website” không phải là phạm vi. Hãy xem những câu hỏi mà nhóm đang trả lời hằng ngày qua email, chat và điện thoại, rồi nhóm chúng lại. Phần lớn website phát hiện chỉ một số ít ý định chiếm đa số lượt hỏi: công ty làm gì, dịch vụ có phù hợp với tình huống này không, khoảng giá và thời gian, quy trình triển khai, tuyển dụng, và cách gặp một người thật.

Danh sách đó quyết định mọi thứ phía sau — kiến thức chatbot cần, những câu trả lời buộc phải chính xác, và ranh giới nơi nó nên dừng. Nó cũng đặt một kỳ vọng trung thực: một trợ lý website xử lý tốt bảy trong mười câu hỏi thường gặp là thành công. Một trợ lý cố trả lời mọi thứ sẽ sai trước mặt khách hàng.

  • Thu thập khoảng một trăm câu hỏi thật từ các kênh hiện có trước khi viết dòng prompt đầu tiên.
  • Nhóm chúng thành các ý định, và đánh dấu ý định nào chỉ có một câu trả lời đúng.
  • Quyết định điều chatbot không bao giờ được làm: báo giá có tính ràng buộc, hứa thời hạn, nhận thanh toán, thay đổi dữ liệu.
  • Định nghĩa thước đo thành công: giải quyết xong mà không cần người, hoặc chuyển tiếp kèm đủ bối cảnh.
  • Chỉ định ai sở hữu nội dung câu trả lời, vì chính quyền sở hữu nội dung giữ cho chatbot đúng.
Ràng buộc chặt nhất thường lại là ràng buộc hữu ích nhất. Một chatbot chỉ được nói trong phạm vi doanh nghiệp đã công bố dễ tin hơn nhiều so với một chatbot được phép ứng biến.

2. Trả lời câu hỏi đã biết một cách xác định, để model lo phần còn lại

Những câu hỏi chỉ có một đáp án đúng thì không nên để model sinh ra. Giờ làm việc, phạm vi dịch vụ, thông tin liên hệ và các bước quy trình nên nằm trong một bộ câu trả lời được biên tập sẵn mà đội nội dung sửa trực tiếp. Khớp câu hỏi với bộ này trước cho ra cùng một đáp án mọi lần, không tốn chi phí mỗi lượt gọi, và sửa được trong vài phút mà không cần đổi mã.

Model xứng đáng có chỗ ở phần còn lại: câu hỏi diễn đạt theo cách không lường trước, câu hỏi gộp hai chủ đề, và câu hỏi cần một bản tóm tắt thay vì một dữ kiện. Đặt model làm lớp thứ hai thay vì cửa vào giúp giảm chi phí, giảm độ dao động của câu trả lời và khiến các kịch bản lỗi dễ suy luận hơn nhiều.

  • Biên tập sẵn câu trả lời cho mọi câu hỏi có đáp án chính xác, và để đội nội dung sở hữu chúng.
  • Chuẩn hoá câu hỏi — chữ hoa chữ thường, dấu, ký tự đặc biệt, từ đồng nghĩa phổ biến — trước khi khớp.
  • Đặt ngưỡng độ tin cậy cho việc khớp trực tiếp, và đẩy mọi thứ dưới ngưỡng sang model.
  • Cache câu trả lời đã sinh cho các câu hỏi lặp lại, khoá theo phần văn bản đã chuẩn hoá.
  • Ghi log lớp nào đã trả lời, để tỷ lệ giữa câu trả lời biên tập sẵn và câu trả lời sinh ra luôn nhìn thấy được.

3. Neo câu trả lời vào nội dung doanh nghiệp kiểm soát

Một model không có tài liệu nguồn sẽ viết ra những đoạn văn trôi chảy về một công ty mà nó không biết. Neo nội dung nghĩa là câu trả lời được dựng từ các đoạn nội dung của chính bạn — trang dịch vụ, mô tả quy trình, case study đã công bố, bộ câu trả lời biên tập sẵn — và prompt yêu cầu model chỉ trả lời trong phạm vi được cung cấp.

Điều này khiến chất lượng nội dung trở thành yếu tố quyết định chất lượng chatbot. Nếu hai trang nêu hai thời gian triển khai khác nhau, chatbot sẽ chọn một cách rất tự tin. Chuẩn bị kho kiến thức thường là phần lớn nhất và ít hào nhoáng nhất của dự án, và bỏ qua nó là lý do phổ biến nhất khiến một bản thử nghiệm không bao giờ lên production.

  • Chỉ truy xuất một số ít đoạn nội dung liên quan cho mỗi câu hỏi, thay vì gửi toàn bộ tài liệu.
  • Yêu cầu model chỉ trả lời từ ngữ cảnh được cấp và nói rõ khi câu hỏi không nằm trong đó.
  • Xử lý các điểm mâu thuẫn trong nội dung nguồn trước khi phát hành; chatbot sẽ phơi ra từng cái một.
  • Hiển thị trang nguồn cạnh câu trả lời để khách kiểm chứng và đọc tiếp.
  • Lập chỉ mục lại khi nội dung thay đổi, và coi chỉ mục cũ là một lỗi production.
Neo nội dung giảm việc bịa đặt nhưng không loại bỏ hoàn toàn. Mọi câu trả lời có con số, có cam kết hoặc có yếu tố pháp lý vẫn cần một cách diễn đạt do người phê duyệt.

4. Thiết kế đường thất bại trước khi thiết kế đường thuận lợi

Có ba thất bại chắc chắn xảy ra: nhà cung cấp model sẽ có lúc không khả dụng, quota hoặc ngân sách sẽ có lúc cạn, và sẽ có khách hỏi điều ngoài phạm vi. Mỗi tình huống cần một phản hồi được thiết kế, vì hành vi mặc định — một vòng xoay tải, một thông báo lỗi kỹ thuật, hoặc một phỏng đoán đầy tự tin — đều tệ hơn một lời thừa nhận thẳng thắn.

Mô hình đứng vững là một chuỗi dự phòng kèm circuit breaker. Khi nhà cung cấp lỗi hoặc trả về lỗi quota, hãy ngừng gọi, phục vụ bằng bộ câu trả lời biên tập sẵn và mở đường chuyển tiếp. Cần phân biệt lỗi tạm thời, xứng đáng thử lại sau vài giây, với quota đã cạn, xứng đáng nghỉ lâu hơn và kiểm tra trước khi quay lại. Trong lúc đó, hãy nói với khách một câu trung thực.

  • Tách lỗi tạm thời của nhà cung cấp khỏi tình trạng cạn quota, và giãn thời gian thử lại khác nhau cho từng loại.
  • Mở circuit breaker sau nhiều lần lỗi liên tiếp, dùng chung giữa các replica thay vì cục bộ trong từng tiến trình.
  • Luôn giữ một chế độ trả lời bằng nội dung biên tập sẵn, chạy được khi model hoàn toàn không khả dụng.
  • Mở đường chuyển tiếp cho người thật kèm theo hội thoại, tới một kênh có người chịu trách nhiệm.
  • Giới hạn số lượt hỏi theo khách, giới hạn độ dài hội thoại và độ dài phản hồi để chặn chi phí.
  • Nói rõ với khách khi trợ lý đang bị giới hạn, thay vì để nó thất bại trong im lặng.

5. Coi mọi đầu vào là không đáng tin, rồi cải tiến từ hội thoại thật

Mọi thứ khách gõ vào đều là dữ liệu không đáng tin, và nội dung mà model truy xuất về cũng vậy. Những chỉ dẫn được cài trong một tin nhắn hoặc một tài liệu có thể tìm cách ghi đè prompt hệ thống, moi thông tin cấu hình hoặc kéo chatbot ra ngoài vai trò của nó. Hãy giữ API key ở phía server, không cho chatbot quyền ghi dữ liệu, và kiểm tra mọi đầu ra mà một hệ thống khác sẽ hành động dựa trên đó.

Sau khi phát hành, vòng cải tiến quan trọng hơn việc chọn model. Hãy đọc hội thoại thật mỗi tuần, nhóm các lần trả lời sai, và sửa đúng chỗ: thiếu một câu trả lời biên tập sẵn, một trang nội dung mâu thuẫn, một prompt cho phép quá nhiều, hoặc một lượt chuyển tiếp không ai trả lời. Phần lớn thứ làm nên một chatbot tốt là công việc nội dung và ranh giới, được làm lặp lại đều đặn.

  • Giữ thông tin xác thực của nhà cung cấp ở server; trình duyệt không bao giờ gọi trực tiếp tới model.
  • Cho trợ lý quyền chỉ đọc, không có khả năng thay đổi dữ liệu hay nhận thanh toán.
  • Giả định nội dung truy xuất về có thể chứa chỉ dẫn cài cắm, và ràng buộc prompt tương ứng.
  • Lưu hội thoại có thời hạn, che dữ liệu cá nhân, và công bố việc lưu trữ này trong chính sách.
  • Xem lại một mẫu hằng tuần: trả lời đúng, trả lời sai, từ chối, chuyển tiếp, khách bỏ giữa hội thoại.
  • Kiểm thử bằng một bộ câu hỏi cố định trước mỗi thay đổi, để một lần sửa prompt không âm thầm làm hỏng thứ khác.
Hãy nói với khách rằng họ đang trò chuyện với một trợ lý và cách gặp người thật. Việc công bố chỉ tốn một câu, nhưng ngăn được loại hiểu lầm mà chất lượng model cao đến đâu cũng không sửa được.

Checklist trước khi đưa chatbot lên website đang chạy

  • Danh sách ý định trong phạm vi, kèm danh sách rõ ràng những việc chatbot không bao giờ được làm.
  • Câu trả lời biên tập sẵn cho mọi câu hỏi chỉ có một đáp án đúng, do đội nội dung sở hữu.
  • Câu trả lời được neo vào nội dung của chính bạn, có hiển thị nguồn cho khách.
  • Các điểm mâu thuẫn trong nội dung nguồn đã được xử lý trước khi phát hành.
  • Có chế độ dự phòng vẫn trả lời được khi nhà cung cấp model không khả dụng.
  • Xử lý riêng lỗi tạm thời và tình trạng cạn quota, có circuit breaker.
  • Có đường chuyển tiếp tới kênh của người thật, với người chịu trách nhiệm theo dõi.
  • Có giới hạn số lượt hỏi, giới hạn độ dài phản hồi và ngưỡng chi phí mỗi ngày.
  • Thông tin xác thực chỉ nằm ở server, trợ lý không có quyền ghi dữ liệu.
  • Có nhịp đọc hội thoại hằng tuần và một bộ câu hỏi cố định chạy trước mỗi thay đổi.

Nguồn tham khảo

Cùng bắt đầu

Biến góc nhìn thành hành động.

Trao đổi với Easy Alo