Klarna tuyển lại người: use case AI cần bằng chứng vận hành, không chỉ blog vendor

Tháng 2/2024, Klarna công bố trợ lý AI xây trên OpenAI đã xử lý 2,3 triệu cuộc hội thoại trong tháng đầu tiên, tức hai phần ba số chat chăm sóc khách hàng của hãng. Mười lăm tháng sau, CEO của chính công ty này nói đầu tư vào chất lượng hỗ trợ do con người làm mới là con đường tương lai của họ.

Hai phát biểu đó không mâu thuẫn. Chúng cho thấy một quy luật mà ai triển khai AI ở doanh nghiệp cũng sớm muộn gặp phải: demo thì đo bằng phần trăm việc được tự động hóa, còn hệ thống chạy lâu dài thì đo bằng chuyện khi máy sai, ai sửa.

Nếu bạn đang muốn chuyển sang FDE, đây là bài học có giá nhất. Khách hàng sẽ mang đến một danh sách use case lấy từ blog của vendor. Việc của bạn là chỉ ra cái nào đã có bằng chứng vận hành, và cái đó cần những gì để không đổ vỡ khi gặp người dùng thật.

Danh sách của vendor dài, nhưng không phải mục nào cũng có số liệu

Đọc các bài liệt kê use case, bạn dễ nghĩ AI đã có mặt ở mọi ngành. Glean xếp RAG theo ngành: chăm sóc khách hàng dùng RAG để lấy thông tin sản phẩm và lịch sử của khách rồi cá nhân hóa câu trả lời, còn trong pháp lý, hệ thống tìm trong án lệ và văn bản luật để giúp luật sư nghiên cứu và soạn thảo.

Codica liệt kê agent trong tài chính có thể phát hiện bất thường và dấu hiệu gian lận. Tất cả đều hợp lý, nhưng đó là mô tả khả năng chứ chưa phải bằng chứng vận hành.

Một bài trên blog vendor cho bạn biết loại bài toán nào có thể làm được. Nó không cho bạn biết tỷ lệ trả lời sai là bao nhiêu, người dùng có tin hệ thống không, hay ai chịu trách nhiệm khi có sự cố.

Vì thế, khi đọc một use case, nên hỏi năm câu: dữ liệu lấy từ đâu, câu trả lời có chỉ ra nguồn không, ai duyệt trước khi kết quả đến người dùng cuối, khi nào phải dừng để chuyển cho người, và nếu không ai duyệt thì đo bằng gì.

Trả lời năm câu ấy cho từng ví dụ dưới đây, bạn sẽ thấy chúng chia thành vài nhóm rõ rệt.

RAG chạy tốt nhất khi có một người đọc lại

Hai use case mà theblue.ai mô tả đáng xem kỹ, vì chúng có chung một cấu trúc dễ kiểm soát. Use case thứ nhất là hỏi đáp nội bộ: hệ thống trả lời trong vài giây và nêu tên tài liệu đã dùng để trả lời.

Use case thứ hai là bảng câu hỏi tuân thủ hoặc hồ sơ đấu thầu lặp đi lặp lại: RAG soạn nháp từ chính sách và tài liệu kỹ thuật, sau đó chuyên gia rà soát và phê duyệt.

Hai use case này giống nhau ở chỗ máy không phải bên có tiếng nói cuối cùng. Câu trả lời có trích dẫn thì người đọc kiểm tra được. Bản nháp có chuyên gia duyệt thì một câu sai bị chặn lại trước khi ra ngoài, và tra án lệ cũng theo khuôn đó: luật sư vẫn là người nghiên cứu và soạn thảo.

Thử hình dung một trường hợp giả định: công ty phần mềm B2B mỗi quý nhận khoảng 40 bảng hỏi bảo mật, mỗi bảng vài trăm câu, phần lớn lặp lại giữa các bảng. Nếu RAG soạn nháp được phần lớn và chuyên gia chỉ phải sửa những câu khó, thời gian tiết kiệm là có thật, còn rủi ro nằm gọn trong tay một người hiểu việc.

Đó đúng là cấu trúc của một use case dễ được duyệt ngân sách.

Klarna cho thấy agent chăm sóc khách hàng mạnh ở đâu và gãy ở đâu

Theo số liệu hãng tự công bố, mức hài lòng của khách với trợ lý AI ngang với nhân viên người và số yêu cầu lặp lại giảm 25%, dù đó là số của chính công ty chứ không phải của một bên kiểm chứng độc lập.

Tháng 5/2025, CEO Klarna đổi giọng: theo Entrepreneur, hãng tuyển lại nhân viên chăm sóc khách hàng và cam kết khách muốn gặp người thật thì lúc nào cũng có người. Bài học không phải là AI thất bại. Có thể đọc đó là cú chuyển từ thiết kế lấy tự động hóa làm mục tiêu sang thiết kế coi đường chuyển sang người là tính năng bắt buộc.

Thử hình dung khách hỏi về một khoản hoàn tiền, nhưng thông tin hoàn tiền nằm ở hệ thống thanh toán, lịch sử khiếu nại nằm ở hệ thống ticket, nên bot chỉ thấy một phần và trả lời tự tin mà vẫn sai.

Vì thế, với một FDE, câu hỏi đầu tiên ở dự án chăm sóc khách hàng là agent được đọc những hệ thống nào, chứ chưa phải chọn model nào. Câu hỏi thứ hai là agent dựa vào tín hiệu gì để biết mình không đủ thông tin và phải chuyển cho người.

Gợi ý sản phẩm là loại AI có số đo rõ nhất

Với hệ gợi ý, Algolia dẫn số liệu cho rằng gợi ý chiếm tới 31% doanh thu thương mại điện tử, và dẫn lại con số 80% số phim được xem trên Netflix đến từ hệ thống gợi ý. Cả hai đều là số dẫn lại trong bài của một vendor bán công cụ tìm kiếm và gợi ý, nên chỉ nên coi là tham khảo.

Điều đáng học hơn là cách bài toán này vận hành. Không ai duyệt từng gợi ý, nhưng một gợi ý trật thường chỉ khiến người dùng lướt qua, và kết quả đo được bằng hành vi: người dùng có bấm, có mua, có xem tiếp hay không. Hệ thống chạy được hoàn toàn tự động là nhờ vòng phản hồi này, chứ không phải vì model thông minh hơn.

Xếp ba nhóm vào cùng một bảng, bạn sẽ thấy một quy luật mà không bài liệt kê use case nào nói thẳng ra.

Use case	Ngành	Dữ liệu cần	Ai chốt kết quả	Bằng chứng hiện có
Hỏi đáp nội bộ có trích dẫn	Mọi ngành	Tài liệu nội bộ	Người hỏi tự kiểm tra nguồn	Mô tả của vendor
Soạn nháp bảng hỏi tuân thủ, đấu thầu	B2B	Chính sách, tài liệu kỹ thuật	Chuyên gia duyệt	Mô tả của vendor
Tra án lệ, văn bản luật	Pháp lý	Án lệ, luật	Luật sư	Mô tả của vendor
Agent chăm sóc khách hàng	Fintech, bán lẻ	Sản phẩm, lịch sử khách, nhiều hệ thống	Agent, chuyển sang người khi cần	Klarna tự công bố, rồi điều chỉnh năm 2025
Phát hiện bất thường, gian lận	Tài chính	Giao dịch	Phải thiết kế riêng	Mới ở mức danh sách khả năng
Gợi ý sản phẩm	Thương mại điện tử, streaming	Hành vi người dùng	Tự động, đo bằng hành vi	Số liệu dẫn lại, đo được

Quy luật đó là: rủi ro khi sai càng cao thì càng phải có người chốt, còn khi không có người chốt thì phải có một chỉ số đo được hằng ngày. Use case nào thiếu cả hai, như một agent tự trả lời mọi khiếu nại mà không có đường chuyển sang người, thì chính là chỗ dự án dễ phải quay đầu.

Portfolio FDE nên khoe đường chuyển sang người, không phải chatbot

Nếu bạn đang chuẩn bị chuyển sang FDE, đừng xây portfolio bằng một chatbot “hỏi gì cũng trả lời”.

Hãy làm một hệ RAG hẹp trên dữ liệu có thật, chẳng hạn văn bản pháp luật công khai, quy chế của một trường đại học hay tài liệu sản phẩm của một dự án mã nguồn mở, bắt buộc mọi câu trả lời phải dẫn nguồn, rồi công bố tỷ lệ trích dẫn đúng mà bạn tự đo.

Trong CV, một dòng như “thiết kế luồng chuyển sang người khi độ tin cậy thấp, đo tỷ lệ chuyển tiếp hằng tuần” có sức nặng hơn nhiều so với “xây chatbot dùng GPT”.

Khi đọc JD, hãy để ý những nơi nhắc đến evaluation, human-in-the-loop hoặc tích hợp nhiều hệ thống nguồn, vì đó là dấu hiệu công ty đã qua giai đoạn demo và đang đối mặt với vận hành thật.

Còn ở buổi làm việc đầu tiên với khách, hãy hỏi trước khi đề xuất: ai là người chốt câu trả lời hôm nay, và họ sẽ kiểm tra máy bằng cách nào. Câu trả lời cho hai câu hỏi đó gần như quyết định use case đầu tiên nên là gì.

Ca Klarna không chứng minh rằng agent chăm sóc khách hàng là ý tồi. Nó cho thấy rằng ngay cả khi AI đã xử lý được hai phần ba số chat, khách hàng vẫn cần có người ở phía bên kia khi họ muốn.