LangChain: Blog
92

Thủ thuật

Bài học thực tế từ việc triển khai AI Agent trong dịch vụ khách hàng tại Lyft, Vodafone và LATAM Airlines

(giờ Việt Nam)

Tóm tắt AI

LangChain tổng hợp kinh nghiệm triển khai AI Agent từ ba tập đoàn lớn, nhấn mạnh chiến lược bắt đầu từ quy mô nhỏ, tích hợp hệ thống chặt chẽ và thiết lập cơ chế kiểm soát của con người để tối ưu trải nghiệm khách hàng.

Bản dịch AI

Customer Experience (CX) Agents in Production: Lessons from Lyft, Vodafone, and LATAM Airlines

Trải nghiệm khách hàng (CX) đã trở thành một trong những lĩnh vực phát triển nhanh nhất đối với các tác nhân AI (agents), một phần vì ROI (tỷ suất hoàn vốn) tương đối dễ đo lường. Phản hồi nhanh hơn có thể cải thiện tỷ lệ chuyển đổi, giảm bớt các yêu cầu leo thang (escalations) giúp tiết kiệm chi phí trên mỗi lượt liên hệ, và việc giải quyết vấn đề thành công hơn sẽ giúp giữ chân khách hàng.

Khi các tác nhân CX đi vào vận hành thực tế, thách thức chuyển từ việc xây dựng sang cải thiện cách thức hoạt động của chúng. Các đội ngũ đang học hỏi từ những tương tác thực tế, tinh chỉnh hành vi của tác nhân và quyết định khi nào một cuộc hội thoại nên trở thành một quy trình làm việc có cấu trúc. Ngày càng nhiều, họ cũng sử dụng các tương tác đó để cải thiện trải nghiệm khách hàng nói chung.

Những đội ngũ đi đầu đang coi các tác nhân như những hệ thống sản xuất đòi hỏi phải được kiểm thử, triển khai, giám sát và lặp lại liên tục. Bài viết này xem xét cách tiếp cận đó đang hình thành như thế nào tại ba công ty:

Dựa trên các ví dụ bổ sung từ Cisco và Podium, chúng ta sẽ khám phá các trường hợp sử dụng đang nổi lên trong lĩnh vực trải nghiệm khách hàng, những thách thức về kỹ thuật và vận hành mà các đội ngũ gặp phải trong quá trình sản xuất, cũng như cách LangSmith, Deep Agents và LangGraph hỗ trợ cải tiến liên tục trong suốt Vòng đời phát triển tác nhân (Agent Development Lifecycle).

Các mô hình mới nổi trong các tác nhân Trải nghiệm khách hàng

Các tác nhân tự phục vụ hướng tới người tiêu dùng thường là điểm khởi đầu dễ thấy nhất. Chúng tương tác trực tiếp với khách hàng thông qua trò chuyện hoặc giọng nói, hỗ trợ các tác vụ như thanh toán, truy cập tài khoản, khiếu nại và đặt lịch hẹn. Giá trị của chúng tương đối dễ đo lường: phản hồi nhanh hơn có thể cải thiện tỷ lệ chuyển đổi, trong khi việc giải quyết vấn đề thành công hơn có thể giảm các yêu cầu leo thang và giảm chi phí hỗ trợ. Ví dụ, AI Employee của Podium phản hồi các khách hàng tiềm năng cho các đại lý ô tô, nhà thầu HVAC và các doanh nghiệp địa phương khác. Đối với những công ty này, việc phản hồi trong vòng năm phút mang lại tỷ lệ chuyển đổi khách hàng tiềm năng cao hơn 46% so với việc phản hồi trong vòng một giờ.

Các tác nhân hỗ trợ (copilots) cho nhân viên tuyến đầu có thể là một trường hợp sử dụng có đòn bẩy cao hơn nữa. Thay vì nói chuyện trực tiếp với khách hàng, các tác nhân này làm việc cùng với nhân viên con người và đưa ra hành động tốt nhất tiếp theo. Tổ chức CX của Cisco sử dụng cách tiếp cận này cho các kỹ sư mạng. Hệ thống của họ thu hẹp hàng ngàn kết quả tiềm năng xuống còn một vài kết quả quan trọng nhất, vì vậy ngay cả một yêu cầu mơ hồ như “giúp tôi với” cũng có thể được định hướng đến đúng vấn đề.

Các nền tảng tự phục vụ xuất hiện khi bộ phận kỹ thuật không còn đủ sức xây dựng mọi tác nhân. Nền tảng của Lyft cho phép các đội ngũ vận hành và quản lý sản phẩm tạo ra một tệp cấu hình và câu lệnh (prompt), sau đó khởi chạy một tác nhân hỗ trợ mới mà không cần sự tham gia của kỹ sư học máy. Podium đã xây dựng một hệ thống tương tự dựa trên các nguyên tắc cơ bản giống như họ sử dụng nội bộ. Điều này cho phép một kiến trúc nền tảng hỗ trợ nhiều trường hợp sử dụng khác nhau, từ bán hàng ô tô đến hỗ trợ bảo hành HVAC.

Định tuyến ngữ nghĩa (semantic routing) và phân loại (triage) trở nên quan trọng khi các yêu cầu của khách hàng không đầy đủ hoặc mơ hồ. LATAM Airlines đã thấy điều này với Concierge. Ban đầu, 13% tin nhắn được phân loại là nằm ngoài phạm vi xử lý. Sau khi xem xét các cuộc hội thoại, nhóm nhận thấy 95% là nhu cầu chính đáng của hành khách mà tác nhân chưa được thiết kế để xử lý, bao gồm các câu hỏi về làm thủ tục bay và hành lý. Việc bổ sung một chuyên gia chăm sóc khách hàng đã giảm tỷ lệ ngoài phạm vi từ 13% xuống còn 1%.

Evals (các bài đánh giá) trở thành ngôn ngữ chung giữa các đội ngũ kỹ thuật và chuyên môn. Khi ngày càng có nhiều người tham gia xây dựng tác nhân, các đội ngũ cần một cách nhất quán để xác định thế nào là hành vi tốt và xác định xem một tác nhân đã sẵn sàng để triển khai hay chưa. Evals biến kiến thức chuyên môn thành các tiêu chí cụ thể, có thể kiểm thử được mà các kỹ sư, quản lý sản phẩm và đội ngũ vận hành có thể sử dụng để xem xét hiệu suất và hướng dẫn cải tiến.

Lyft đã gặp phải điều này sau khi mở rộng việc phát triển tác nhân cho những người không phải là kỹ sư. Nền tảng không còn là rào cản chính; chất lượng câu lệnh và đánh giá mới là yếu tố quyết định. Nhóm đã giới thiệu một khung viết câu lệnh có cấu trúc và các kiểm tra tự động để phát hiện các hướng dẫn mâu thuẫn và các luồng hội thoại không đầy đủ trước khi chúng được đưa vào sản xuất.

Cùng với nhau, các mô hình này cho thấy công việc thay đổi như thế nào khi các tác nhân CX đạt đến giai đoạn sản xuất. Ba đội ngũ sau đây minh họa cách các tổ chức đang thiết kế, đánh giá và cải thiện các hệ thống này ở quy mô lớn.

Ba đội ngũ với các tác nhân CX trong giai đoạn sản xuất

Lyft: Biến kỹ thuật hỗ trợ thành một nền tảng tự phục vụ

AI Assist của Lyft hỗ trợ hành khách và tài xế trong các vấn đề như truy cập tài khoản, yêu cầu bồi thường thiệt hại, xem xét phí và tranh chấp thu nhập. Khối lượng chuyến đi mà Lyft điều phối đòi hỏi một hệ thống tác nhân để hỗ trợ. Lyft điều phối 79 triệu chuyến đi mỗi tháng, trong khi AI Assist xử lý khoảng 270.000 tương tác hàng tháng trên bảy hoặc nhiều hơn các tác nhân đang vận hành. Hệ thống đã đạt được tỷ lệ chuyển hướng (deflection rate) 65% và tỷ lệ giải quyết bằng AI là 35%.

Lyft đặt ra tiêu chuẩn cao một cách có chủ đích cho việc giải quyết vấn đề, yêu cầu tác nhân phải giải quyết vấn đề từ đầu đến cuối thay vì chỉ đơn giản là ngăn khách hàng liên hệ với con người. Đối với các quy trình phức tạp như yêu cầu bồi thường thiệt hại của tài xế, điều đó có thể bao gồm việc thu thập thông tin và hình ảnh, truy xuất dữ liệu thông qua các công cụ, áp dụng các tín hiệu gian lận, đưa ra quyết định và giải thích kết quả cho tài xế (tất cả trong vòng 15 phút).

Kiến trúc tác nhân

Hệ thống hiện tại của Lyft sử dụng kiến trúc đa tác nhân dựa trên bộ định tuyến (router-based) được xây dựng trên LangGraph. Một meta-agent (tác nhân cấp cao) phân loại từng yêu cầu đến và định tuyến nó đến một tác nhân phụ chuyên biệt, với các luồng riêng biệt cho hành khách và tài xế. Mỗi tác nhân phụ tự nó là một đồ thị trạng thái LangGraph hoàn chỉnh được đăng ký dưới dạng một nút đồ thị con (subgraph node).

Khi một tác nhân xác định ý định (intent agent) nhận thấy giữa cuộc hội thoại rằng yêu cầu cần một trình xử lý chuyên biệt hơn (ví dụ: chuyển từ tác nhân ý định chung của tài xế sang tác nhân yêu cầu bồi thường thiệt hại), nó sẽ trả quyền kiểm soát lại cho meta-agent để định tuyến lại. Điều này ngăn chặn việc cuộc hội thoại bị ép buộc đi sai hướng.

Lyft chia các tác nhân của mình thành hai loại:

Cách tiếp cận này đã giảm thời gian cần thiết để phát triển một tác nhân từ khoảng sáu tháng cho tác nhân tài xế đầu tiên của Lyft xuống còn khoảng hai tuần cho một tác nhân có thể cấu hình mới.

Cách Lyft xây dựng các bài đánh giá (Evals)

Khi nền tảng trở nên dễ sử dụng hơn, chất lượng câu lệnh và đánh giá bắt đầu trở thành những nút thắt cổ chai.

Lyft đã xây dựng một vòng lặp đánh giá kết nối giữa phát triển và sản xuất. Trước khi ra mắt, nhóm chạy các cuộc hội thoại mô phỏng, đa lượt, trong đó một LLM đóng vai khách hàng đối đầu với tác nhân. Mỗi mô phỏng được xác định dựa trên một tác vụ, tính cách người dùng và môi trường phản ánh những gì tác nhân có khả năng gặp phải trong thực tế. Quỹ đạo kết quả có thể được đánh giá bằng cách kết hợp các xác nhận dựa trên mã và các LLM giám khảo, bao gồm việc liệu tác nhân có đưa ra sự nhượng bộ đúng đắn, leo thang phù hợp hay giải quyết vấn đề trong số lượt hội thoại dự kiến hay không.

Sự đa dạng của các kịch bản ngoại tuyến đó rất quan trọng. Lyft sử dụng đánh giá ngoại tuyến như một cổng kiểm soát ra mắt, cho phép nhóm di chuyển nhanh chóng mà không cần coi khách hàng thực tế là các trường hợp thử nghiệm. Một tác nhân chỉ tiến tới giai đoạn sản xuất khi nó đáp ứng ngưỡng chất lượng yêu cầu.

Nhóm đã sớm nhận ra rằng các chỉ số đánh giá chung chung là không đủ. Các thước đo ban đầu như độ hữu ích của phản hồi, tính tự nhiên của cuộc hội thoại, sự phù hợp khi sử dụng công cụ và sự đầy đủ của cuộc hội thoại tạo ra điểm số, nhưng không cho nhóm biết cần thay đổi điều gì.

Thay vào đó, Lyft đã làm việc với các chuyên gia vận hành và chất lượng để xây dựng các tiêu chí đánh giá (rubrics) hẹp, cụ thể theo hành vi dựa trên cách các tương tác hỗ trợ thực sự nên diễn ra. Nhóm cũng chuyển từ điểm số vô hướng rộng sang kết quả đạt hoặc không đạt đơn giản hơn.

Ví dụ, một tiêu chí đánh giá về giáo dục kiểm tra xem tác nhân có cung cấp nội dung giáo dục hữu ích khi nó có thể giải quyết vấn đề hay không, nhưng sẽ leo thang khi rõ ràng là nó không thể. Tác nhân sẽ thất bại nếu nó lặp lại cùng một nội dung giáo dục quá nhiều lần, leo thang trước khi thực hiện nỗ lực hỗ trợ hợp lý hoặc bao gồm một lỗi thực tế.

Một tiêu chí đánh giá leo thang riêng biệt xác định hành vi mong đợi khi người dùng yêu cầu gặp con người. Tác nhân nên từ chối một lần, sau đó leo thang sau khi có yêu cầu lặp lại. Nó sẽ thất bại nếu leo thang ngay lập tức, từ chối leo thang sau yêu cầu thứ hai, leo thang trước khi cung cấp thông tin cần thiết hoặc tiếp tục trong vài lượt sau khi rõ ràng là nó không thể giúp đỡ.

Những tiêu chí này hữu ích hơn các điểm số chất lượng chung chung vì mỗi thất bại đều chỉ ra một thay đổi cụ thể về sản phẩm, câu lệnh hoặc quy trình làm việc.

Lyft cũng hiệu chỉnh các LLM giám khảo của mình dựa trên các đánh giá viên con người. Nhóm thu thập các nhãn từ con người và lặp lại trên mỗi giám khảo cho đến khi đạt được tỷ lệ đồng thuận đủ cao. Điều này mang lại cho nhóm sự tự tin rằng các điểm số tự động phản ánh các tiêu chuẩn mà các đội ngũ vận hành và chất lượng của họ sẽ tự áp dụng.

Người dùng mô phỏng cũng đòi hỏi mức độ hiệu chỉnh tương tự. Những khách hàng do LLM tạo ra đầu tiên của Lyft quá mạch lạc, kiên nhẫn và hợp tác, tạo ra tỷ lệ đạt ngoại tuyến trên 90% không phản ánh hành vi thực tế. Người dùng thực thường viết các câu rời rạc, bỏ qua ngữ cảnh, lặp lại chính mình hoặc đến với một mục tiêu cụ thể như đảm bảo được hoàn tiền hoặc vượt qua tác nhân.

Để làm cho đánh giá ngoại tuyến thực tế hơn, Lyft đã tinh chỉnh người dùng mô phỏng của mình dựa trên các câu chữ thực tế của khách hàng và giới thiệu các tính cách như người tìm kiếm hoàn tiền, người hoài nghi AI và người dùng quyết tâm gặp con người. Làm cho khách hàng mô phỏng bớt "bóng bẩy" hơn khiến việc đánh giá khó khăn hơn, nhưng cũng làm cho kết quả ngoại tuyến dự đoán chính xác hơn về hiệu suất thực tế.

Khi một tác nhân ra mắt, vòng lặp đánh giá tương tự tiếp tục trực tuyến. Mọi lệnh gọi đều được theo dõi trong LangSmith trên khắp các giai đoạn phát triển, thử nghiệm (staging) và sản xuất, bao gồm cả lập luận của tác nhân, nội dung giáo dục mà nó truy xuất và các công cụ mà nó đã gọi. Điều này cho phép nhóm xác định liệu một thất bại đến từ định tuyến, ngữ cảnh, thực thi công cụ hay phản hồi cuối cùng.

AI AgentTrải nghiệm khách hàngTriển khai AIDoanh nghiệpLangChain
Đọc bài gốc

Bài viết được AI dịch và tổng hợp tự động từ LangChain: Blog. Liên kết bài gốc ở phía trên. Dữ liệu đồng bộ qua API công khai được ghi nguồn tại AI HOT (canonical) ↗. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.