Air Canada và chatbot trả lời sai chính sách: AI được phép hứa điều gì với user?

Ngày 11 tháng 11 năm 2022, Jake Moffatt vào website Air Canada để tìm vé từ Vancouver đến Toronto sau khi bà của mình qua đời.

Moffatt hỏi chatbot về bereavement fare — mức giá dành cho người phải di chuyển gấp vì người thân sắp mất hoặc vừa qua đời. Chatbot trả lời rằng nếu đã bay rồi, Moffatt vẫn có thể nộp đơn xin áp dụng mức giá này trong vòng 90 ngày kể từ ngày xuất vé.

Trong câu trả lời còn có một đường link dẫn tới trang chính sách của Air Canada.

Cơ mà trang đó lại viết điều ngược lại: chính sách không áp dụng cho yêu cầu được gửi sau khi chuyến đi đã hoàn tất.

Moffatt tin chatbot, mua vé theo giá thông thường rồi gửi đơn vào ngày 17 tháng 11. Air Canada từ chối hoàn phần chênh lệch vì Moffatt không làm đúng chính sách trên website.

Nguồn: Moffatt v. Air Canada, 2024 BCCRT 149

Chatbot trả lời, user bỏ tiền thật

Sau nhiều tháng không giải quyết được với Air Canada, Moffatt đưa vụ việc tới Civil Resolution Tribunal của British Columbia. Vụ này được xử lý theo quy trình small claims;

Theo phán quyết, Air Canada cho rằng hãng không thể bị buộc chịu trách nhiệm về thông tin do chatbot cung cấp. Thành viên tribunal Christopher Rivers nhận xét rằng lập luận ấy chẳng khác nào coi chatbot là một pháp nhân riêng và gọi đây là một lập luận “remarkable”.

Tribunal không chấp nhận việc đẩy trách nhiệm sang chatbot. Chatbot là một phần trên website Air Canada, nên Air Canada chịu trách nhiệm về thông tin nó đưa ra cũng như thông tin trên một trang web tĩnh.

Lập luận “user có thể bấm vào link để đọc chính sách đúng” cũng không cứu được hãng. Air Canada không giải thích được vì sao user phải biết trang policy đáng tin hơn chatbot, hoặc vì sao user có trách nhiệm kiểm tra chéo hai phần trên cùng một website.

Kết quả, tribunal xác định Air Canada đã cung cấp thông tin sai một cách bất cẩn và yêu cầu hãng trả tổng cộng 812,02 CAD: 650,88 CAD tiền bồi thường, 36,14 CAD tiền lãi trước phán quyết và 125 CAD phí tribunal.

Nguồn: Civil Resolution Tribunal và phân tích của McCarthy Tétrault

812,02 CAD không phải một thiệt hại lớn với một hãng hàng không. Nhưng câu trả lời của chatbot đã ảnh hưởng trực tiếp tới việc Moffatt có mua chuyến bay gấp ấy hay không. Moffatt cho biết mình sẽ không bay nếu biết phải trả toàn bộ giá vé, và tribunal chấp nhận lời trình bày này dựa trên việc Moffatt đã tìm hiểu mức giá rồi làm theo hướng dẫn.

Từ góc nhìn product, đây là ranh giới đáng để quan sát kỹ. Một câu trả lời về giờ mở cửa có thể giúp user tìm thông tin. Một câu trả lời rằng user đủ điều kiện nhận ưu đãi, có thể được hoàn tiền hoặc không phải trả một khoản phí có thể khiến user bấm Thanh toán.

Chatbot lúc ấy không chỉ tìm hộ một đoạn content. Nó đang thay mặt doanh nghiệp nói user được hưởng quyền lợi gì.

Chưa đủ dữ liệu để gọi đây là hallucination

Case này thường được kể lại như một ví dụ AI hallucination. Cách gọi đó dễ hiểu, nhưng hồ sơ công khai không cho biết chatbot của Air Canada hoạt động thế nào. Chính phán quyết cũng ghi nhận Air Canada không cung cấp thông tin về bản chất của chatbot.

Nó có thể đã sinh một câu trả lời mới. Nó cũng có thể dùng content cũ, một rule sai hoặc một kho câu trả lời không được cập nhật khi policy thay đổi. Mình không có dữ liệu để chốt nguyên nhân kỹ thuật.

Nếu team vội kết luận đây là lỗi model, giải pháp rất dễ dừng ở việc sửa prompt, đổi model hoặc tăng confidence threshold. Trong khi điều nhìn thấy rõ từ bên ngoài là chatbot nói user có thể nộp đơn sau chuyến đi, còn trang policy nói không. Thậm chí chatbot còn gắn link tới chính trang đang mâu thuẫn với câu trả lời của nó.

Một chatbot rule-based vẫn có thể gây ra lỗi này. Một hệ thống RAG lấy được tài liệu nhưng lấy nhầm phiên bản cũng có thể gây ra lỗi này. Model trả lời rất tự tin hay hơi dè dặt cũng không thay đổi việc user đã được hướng dẫn làm một việc mà doanh nghiệp sau đó từ chối công nhận.

Vì vậy, trước khi chọn model, team cần xác định một việc cơ bản hơn:

Trong hệ thống, đâu là nguồn duy nhất có quyền xác định chính sách hoàn tiền?

Nếu trang policy được sửa vào thứ Hai nhưng knowledge base của chatbot chỉ được cập nhật vào cuối tháng, sản phẩm đã chấp nhận một khoảng thời gian có hai câu trả lời. Nếu content được copy vào prompt, FAQ, script của support và chatbot, mỗi bản copy lại là một chỗ có thể cũ đi.

Với những policy ảnh hưởng trực tiếp tới giá, hoàn tiền hay điều kiện sử dụng dịch vụ, mình sẽ không để model tự viết lại rule từ một mớ tài liệu rồi hy vọng câu trả lời vẫn tương đương. Chatbot có thể giải thích cho dễ hiểu, nhưng kết luận đủ điều kiện hay không đủ điều kiện nên đến từ một nguồn đã được doanh nghiệp công nhận — chẳng hạn một rule service hoặc một policy record có version rõ ràng.

Dùng một policy record có version rõ ràng không tạo ra màn demo hấp dẫn bằng chatbot nói chuyện tự nhiên. Nó giúp câu trả lời của chatbot và trang policy cùng dựa trên một rule.

Chia câu hỏi theo hậu quả nếu chatbot trả lời sai

Một cách scope chatbot khá phổ biến là liệt kê chủ đề: hành lý, đổi vé, check-in, hoàn tiền, loyalty. Cách chia này tiện cho backlog, nhưng chưa nói được câu nào chatbot có thể tự trả lời và gặp câu nào thì chatbot phải dừng để chuyển sang kênh khác.

Trong cùng chủ đề hoàn tiền, hai câu hỏi có hậu quả rất khác nhau:

• “Tôi tìm form yêu cầu hoàn tiền ở đâu?”
• “Vé của tôi chắc chắn được hoàn bao nhiêu tiền?”

Câu đầu có thể được trả lời bằng một link đã kiểm tra. Câu sau cần biết loại vé, thời điểm mua, hành trình, trạng thái chuyến bay và policy đang có hiệu lực. Nếu thiếu một trường mà chatbot vẫn kết luận chắc chắn, câu trả lời nghe trôi chảy chỉ làm lỗi khó nhận ra hơn.

Mình sẽ chia quyền trả lời theo hậu quả của câu trả lời, không chỉ theo topic.

Chatbot có thể tự xử lý những câu hỏi chỉ yêu cầu tìm một thông tin có nguồn rõ ràng và ít ảnh hưởng tới quyết định khó đảo ngược của user. Với câu hỏi về giá, quyền lợi, hoàn tiền hoặc điều kiện hợp đồng, nó chỉ nên kết luận khi hệ thống đã lấy đủ dữ liệu và rule trả về một kết quả xác định. Nếu policy còn mơ hồ, nguồn đang mâu thuẫn hoặc thiếu dữ liệu của user, flow cần chuyển sang người có thẩm quyền xử lý.

Đó không nhất thiết phải là một button Gặp nhân viên xuất hiện sau khi user đã cãi với chatbot mười phút. Fallback có thể xảy ra ngay tại lúc hệ thống nhận ra nó không có quyền đưa ra lời hứa.

Ví dụ, thay vì tự kết luận user sẽ được hoàn tiền, chatbot có thể nói rằng dữ liệu hiện có chưa đủ để xác định quyền lợi, đưa đúng trang policy rồi giữ nguyên context khi chuyển sang support. User có thể phải chờ lâu hơn một chút. Đổi lại, họ chưa bỏ tiền dựa trên một quyền lợi không tồn tại.

Evals phải chạy lại khi policy thay đổi

Giả sử team đã sửa câu trả lời cụ thể về bereavement fare. Bài toán vẫn chưa xong.

Policy sẽ tiếp tục đổi. User cũng không hỏi đúng câu đã có trong test case. Họ có thể hỏi “Tôi bay ngày mai rồi nộp giấy tờ sau được không?”, “Tôi đã mua vé sáng nay thì sao?” hoặc “Cứ đặt trước, sau đó hãng trả lại phần chênh lệch đúng không?”. Ba cách hỏi khác nhau có thể đang kiểm tra cùng một rule.

Một bộ eval cho flow này cần lấy các rule quan trọng làm điểm xuất phát, sau đó tạo nhiều cách hỏi và nhiều bộ dữ liệu nằm sát điều kiện được chấp nhận hoặc bị từ chối. Kết quả không chỉ chấm xem câu trả lời có nhắc đúng keyword hay không. Team cần kiểm tra chatbot có:

• kết luận đúng theo phiên bản policy hiện hành;
• hỏi thêm khi thiếu dữ liệu để xác định quyền lợi;
• không tự bịa ra deadline, số tiền hoặc ngoại lệ;
• dẫn tới đúng nguồn và không mâu thuẫn với nguồn đó;
• chuyển sang support khi hệ thống không thể đưa ra kết luận chắc chắn.

Mỗi lần policy đổi, các eval liên quan phải chạy lại trước khi bản mới được dùng. Nếu một policy record có version, log của chatbot cũng nên lưu được câu trả lời đã dựa trên version nào. Đến lúc có complaint, team mới lần lại được hôm đó hệ thống biết gì thay vì mở website hiện tại rồi bảo “bây giờ có thấy sai đâu”.

Metric cũng cần đi xa hơn số ticket đã deflect. Chatbot có thể giảm contact rate rất đẹp bằng cách tự tin trả lời mọi thứ. Yêu cầu của Moffatt không biến mất sau phiên chat; Moffatt phải trao đổi với Air Canada trong nhiều tháng rồi đưa vụ việc tới tribunal.

Với nhóm câu hỏi có hậu quả tài chính, team nên đọc lại sample hội thoại, theo dõi số lần câu trả lời bị human agent sửa, số complaint phát sinh sau phiên chat và những policy nào thường khiến chatbot phải fallback. Đây là phần vận hành kéo dài sau release, không phải một vòng UAT làm xong rồi cất chatbot vào góc.

Doanh nghiệp vẫn chịu trách nhiệm cho câu trả lời của chatbot

Air Canada nói sẽ cập nhật chatbot sau khi Moffatt phản ánh. Nhưng đến lúc tribunal ra phán quyết vào tháng 2 năm 2024, câu hỏi không còn là ai sẽ sửa một đoạn text. Câu hỏi là doanh nghiệp có chịu trách nhiệm cho kênh mà chính mình đặt trước mặt user hay không.

Tribunal đã trả lời rất gọn: có.

Team làm chatbot vì thế cần một owner cho độ chính xác của từng nhóm policy, một nguồn có thẩm quyền để chatbot dựa vào và một quy trình buộc eval chạy lại khi nguồn đó thay đổi. Model provider có thể chịu trách nhiệm về hạ tầng hay chất lượng theo hợp đồng với doanh nghiệp. Còn với user, câu trả lời vẫn xuất hiện dưới tên sản phẩm của mình.

Trước khi cho AI trả lời một câu hỏi về giá, quyền lợi hoặc hoàn tiền, mình sẽ thử đổi chatbot thành một nhân viên đang viết email cho khách hàng. Nếu doanh nghiệp phải thực hiện điều người nhân viên ấy vừa xác nhận, chatbot cũng không nên được phép nói câu đó khi chưa có dữ liệu và rule để chống lưng.

Trong case Air Canada, một đường link đúng nằm ngay bên dưới câu trả lời sai vẫn không đủ. User không có nhiệm vụ làm QA cho website trước khi mua vé.

Bài gốc trên Substack: https://henrypham.substack.com/p/air-canada-va-chatbot-tra-loi-sai