Xây dựng AI chăm sóc khách hàng ecommerce: Ưu tiên tool hơn RAG

AI chăm sóc khách hàng tùy chỉnh làm được gì mà chatbot không làm được?

AI chăm sóc khách hàng tùy chỉnh cho ecommerce là một mô hình ngôn ngữ được kết nối với các hệ thống riêng của cửa hàng thông qua những tool như tra cứu đơn hàng, tìm kiếm sản phẩm, kiểm tra chính sách và chuyển tiếp cho nhân viên. Nó trả lời dựa trên dữ liệu trực tiếp và thực hiện các hành động đã được định nghĩa, thay vì chỉ lặp lại những câu trả lời FAQ chung chung.

Khác biệt thực tế nằm ở nguồn tạo ra câu trả lời:

• Chatbot: đối chiếu câu hỏi với nội dung soạn sẵn hoặc kho kiến thức được dán vào hệ thống.
• Agent: quyết định cần gọi tool nào, đọc kết quả rồi trả lời dựa trên dữ liệu đó. Nếu đơn hàng bị giao trễ, agent sẽ nói đúng như vậy vì nó vừa kiểm tra thông tin trực tiếp.

Agent tùy chỉnh hay chatbot có sẵn cho ecommerce?

Quy tắc kinh nghiệm của tôi: nếu phần lớn ticket chỉ là câu hỏi “đơn hàng của tôi đang ở đâu?” và helpdesk của bạn đã có tích hợp tra cứu đơn hàng, hãy mua widget. Nên xây dựng giải pháp tùy chỉnh khi logic của bạn đặc thù hoặc câu trả lời nằm rải rác trên nhiều hệ thống.

Ưu tiên tool, dùng RAG sau: Agent được kết nối như thế nào?

Agent trên netalith.com được xây dựng trực tiếp trên OpenAI API bằng function tools. Nó truy vấn dữ liệu blog, dịch vụ, sản phẩm và dự án theo thời gian thực. Hệ thống không sử dụng RAG.

Lý do là tính cập nhật. Danh mục sản phẩm, tồn kho và giá thay đổi liên tục. Một vector index được tạo từ dữ liệu xuất vào tối hôm trước có thể tự tin báo giá của ngày hôm qua. Còn việc gọi tool sẽ đọc bản ghi hiện tại.

RAG vẫn phù hợp với các tài liệu dài, không có cấu trúc rõ ràng như sách hướng dẫn hoặc tài liệu chính sách chi tiết. Tuy vậy, tôi vẫn khuyên nên cung cấp RAG như một tool trong số nhiều tool khác, thay vì biến nó thành toàn bộ kiến trúc.

Tool được định nghĩa bằng JSON schema, và hướng dẫn function calling của OpenAI khuyến nghị luôn bật strict mode để các tham số khớp với schema.

Một lưu ý về phạm vi: agent trên website của chúng tôi xử lý các nhu cầu trước khi mua hàng. Agent tư vấn, đề xuất sản phẩm, gửi link thanh toán, xác định nhu cầu của khách truy cập và thu thập thông tin liên hệ để đội ngũ hỗ trợ xử lý. Hỗ trợ sau mua hàng cũng dùng cùng mô hình, với việc bổ sung tool tra cứu đơn hàng và đổi trả. Nếu muốn triển khai cho cửa hàng của bạn, dịch vụ phát triển AI của chúng tôi có cung cấp agent chăm sóc khách hàng.

Bộ tool cần có cho agent hỗ trợ ecommerce

Dưới đây là dạng thể hiện của một tool trong định dạng tool phẳng của Responses API:

{
  "type": "function",
  "name": "lookup_order",
  "description": "Look up one order's status and tracking. Call only after the customer has given both the order number and the email on the order.",
  "parameters": {
    "type": "object",
    "properties": {
      "order_number": { "type": "string" },
      "email": { "type": "string" }
    },
    "required": ["order_number", "email"],
    "additionalProperties": false
  },
  "strict": true
}

Cạm bẫy ở đây là: schema nghiêm ngặt chỉ đảm bảo hình dạng của tham số, chứ không đảm bảo người gọi có quyền xem đơn hàng đó. Việc phân quyền phải được xử lý ở backend. Nếu email không khớp với đơn hàng, tool sẽ trả về “not found” và agent sẽ nói rằng không thể tìm thấy thông tin khớp. Đừng bao giờ dựa vào prompt để kiểm soát ai được xem dữ liệu nào.

Hãy triển khai các tool chỉ-đọc trước. Sau đó bổ sung từng tool ghi một, chỉ khi bạn đã xem xét các transcript thực tế.

Ngăn agent tự bịa chính sách như thế nào?

Đây là rủi ro cần định hướng cho toàn bộ thiết kế. Vào tháng 2, một cơ quan tài phán tại British Columbia xác định Air Canada phải chịu trách nhiệm sau khi chatbot trên website cung cấp cho khách hàng thông tin sai về giá vé dành cho trường hợp có người thân qua đời. Cơ quan này bác bỏ lập luận cho rằng chatbot phải tự chịu trách nhiệm về câu trả lời của mình. Bản tóm tắt của American Bar Association là một tài liệu ngắn đáng đọc. Bài học dành cho cửa hàng là: mọi điều agent nói về hoàn tiền, thời gian giao hàng và bảo hành đều thuộc trách nhiệm của doanh nghiệp.

Những quy tắc tôi luôn đưa vào hệ thống:

• Câu trả lời về chính sách chỉ được lấy từ kết quả của policy tool. Không có kết quả thì không trả lời: agent phải nói rằng chưa thể xác nhận và đề nghị kết nối với nhân viên.
• Không hứa giảm giá, hoàn tiền hoặc ngoại lệ bằng văn bản tự do. Những việc này phải được xử lý bằng action tool có giới hạn hoặc do nhân viên quyết định.
• Mọi cuộc hội thoại và lần gọi tool đều được ghi log, để bạn có thể xác định chính xác hệ thống đã nói gì và vì sao.
• Mỗi tuần, một người phải đọc mẫu transcript. Đây không phải việc tùy chọn.

Chuyển cho nhân viên: Khi nào agent phải dừng lại?

Hãy chuyển cho nhân viên khi có yêu cầu hoàn tiền hoặc chargeback, nội dung liên quan đến pháp lý hoặc an toàn, khách hàng đang tức giận, cùng một câu hỏi không được giải quyết sau hai lần, hoặc đơn hàng có giá trị cao.

Bản chuyển tiếp nên là một bản tóm tắt ngắn, không phải toàn bộ transcript: khách hàng là ai, họ muốn gì, agent đã kiểm tra những gì và còn thiếu bước nào. Agent của chúng tôi cũng hoạt động theo cách này. Agent xác định nhu cầu của khách truy cập, thu thập thông tin liên hệ và gửi bản tóm tắt cho đội ngũ hỗ trợ. Agent không tiếp quản live chat vì website của chúng tôi không cần tính năng đó.

Với cửa hàng có lượng ticket hỗ trợ lớn, tính năng nhân viên tiếp quản trực tiếp có thể quan trọng hơn. Tính năng này có thể xây dựng được, nhưng hãy quyết định ngay từ đầu vì nó sẽ làm thay đổi kiến trúc hệ thống.

Cần đo lường gì sau khi triển khai?

Cần làm gì để xây dựng một agent như vậy?

1. Xuất dữ liệu ticket của vài tháng gần nhất và xếp hạng các loại ticket theo số lượng.
2. Đối chiếu từng loại ticket phổ biến với một tool và một nguồn dữ liệu.
3. Triển khai các tính năng chỉ-đọc trước: tìm kiếm sản phẩm, trạng thái đơn hàng và chính sách.
4. Thêm các action yêu cầu khách hàng xác nhận.
5. Hàng tuần xem xét transcript và tinh chỉnh mô tả tool cùng các lớp kiểm soát.

Vì tool chỉ là lớp kết nối mỏng trên API của nền tảng, logic của agent có thể dùng cho Shopify, WooCommerce, BigCommerce, Odoo và các backend marketplace. Chỉ lớp tool cần thay đổi.

Nếu muốn xây dựng AI chăm sóc khách hàng tùy chỉnh cho cửa hàng, phạm vi và chi phí sẽ phụ thuộc vào nền tảng cùng loại ticket của bạn. Gửi thông tin qua biểu mẫu nhận báo giá miễn phí và chúng tôi sẽ cho bạn biết phương án nào thực tế.