Mở Rộng Hệ Thống Hỗ Trợ Thẻ Giúp Khách Hàng (COTA) Của Uber Với Tính Năng Deep Learning

Nga Dương
08/04/2020 - 10:00 516     0

COTA là sự hợp tác đa chức năng giữa Học máy ứng dụng, Nền tảng hỗ trợ khách hàng của Uber và các nhóm Michelangelo và Uber AI Labs, với sự đóng góp của Piero Molino, Viresh Gehlawat, Yi-Chia Wang, Joseph Wang, Eric Chen, Paul Mikesell, Alex Sergeev , Mike Del Balso, Chintan Shah, Christina Grimsley, Taj Singh, Jai Malkani, Fran Bell và Jai Ranganathan.

Đầu năm nay, chúng tôi đã giới thiệu hệ thống hỗ trợ thẻ giúp khách hàng (COTA) của Uber, một công cụ tận dụng các kỹ thuật học máy và xử lý ngôn ngữ tự nhiên (NLP) để đề xuất phản hồi thẻ hỗ trợ (Loại liên hệ và trả lời) cho các đại lý hỗ trợ khách hàng, với “Loại liên hệ” là danh mục vấn đề mà thẻ được chỉ định và “Trả lời” các đại lý mẫu sử dụng để phản hồi . Sau khi tích hợp nó vào Nền tảng hỗ trợ khách hàng của chúng tôi, COTA v1 đã giảm hơn 10% thời gian giải quyết thẻ bằng tiếng Anh trong khi cung cấp dịch vụ với mức độ hài lòng của khách hàng tương tự hoặc cao hơn.

Đối với Uber, COTA v1 chỉ là khởi đầu. Trong nỗ lực cải thiện hiệu suất COTA, chúng tôi đã tiến hành các thử nghiệm ngoại tuyến cho thấy học sâu (deep learning) tăng độ chính xác dự đoán của Top-1 lên 16 phần trăm (từ 49% đến 65%) cho mô hình Loại liên hệ và 8% (từ 47% đến 55 %) cho mô hình Trả lời (để biết thêm chi tiết, vui lòng tham khảo bài viết thẻ KDD của chúng tôi), một kỳ công thực sự với sự phức tạp của các nhiệm vụ này.

Nhận được những kết quả đáng khích lệ này, chúng tôi đã quyết định đưa các mô hình học  sâu của mình vào nền tảng học máy trong nội bộ của Uber, Michelangelo. Chúng tôi đã thực hiện điều này bằng cách xây dựng Đường ống học sâu dựa trên Spark (hệ thống xử lý dữ liệu hàng loạt) để tạo ra thế hệ thứ hai của COTA (COTA v2) bằng cách sử dụng cơ sở hạ tầng hiện có của Michelangelo. Do hiệu suất mô hình giảm dần theo thời gian, chúng tôi cũng đã xây dựng một đường ống để tự động quản lý mô hình và đào tạo lại và dừng lưu hành các mô hình để luôn cập nhật chúng mọi lúc.

Sau khi tích hợp với Michelangelo, các thử nghiệm trực tuyến của chúng tôi xác thực rằng hệ thống học sâu COTA v2 hoạt động tốt hơn đáng kể so với hệ thống COTA v1 thẻ các số liệu chính, bao gồm hiệu suất mô hình, thời gian xử lý thẻ và sự hài lòng của khách hàng.

Thế hệ đầu tiên của COTA: thách thức và cơ hội

Trong khi COTA v1 tăng tốc độ phân giải thẻ hỗ trợ, có hai lĩnh vực chính chúng tôi đã xác định để cải thiện. Đầu tiên, COTA v1 đã tiến hành lấy mẫu âm tính theo cách quá phức tạp khiến việc đào tạo các mô hình của chúng tôi trở nên khó khăn. Kết hợp với sự phụ thuộc trong các bảng dữ liệu cụ thể, yếu tố này cuối cùng đã khiến việc đào tạo lại COTA trở thành một công việc đáng kể. Mặc dù không thể không vượt qua, nhưng mức độ khó khăn của nhiệm vụ đang diễn ra này, theo thời gian, có thể trở thành sự nản lòng mỗi khi tiến hành việc bảo trì thường xuyên.

Thứ hai, việc triển khai ban đầu của chúng tôi không đủ mở rộng để được sử dụng bởi các mô hình NLP trong tương lai. Kể từ đó, chúng tôi đã nỗ lực để phát triển quy trình triển khai học tập sâu, mở ra cánh cửa không chỉ cho các mô hình của chúng tôi mà còn cho những người từ tất cả các đội khác tại Uber.

Tại sao lại là “học sâu” ?

Thành công của COTA v1 đã thúc đẩy chúng tôi đầu tư thêm vào kho công nghệ của mình và khám phá các giải pháp hỗ trợ giải quyết khác. Phục vụ hơn 600 thành phố trên toàn thế giới, hỗ trợ nhiều ngôn ngữ và tạo điều kiện cho năm kênh liên lạc, bộ phận hỗ trợ khách hàng của Uber, tiếp cận khách hàng trên khắp các doanh nghiệp của chúng tôi bao gồm việc chia sẻ phương tiện, Uber Eats (ứng dụng vận chuyển thức ăn), xe đạp công cộng và Uber Freight (mô hình vận tải). Phạm vi và quy mô kinh doanh của chúng tôi đã làm tăng thêm sự phức tạp to lớn cho thách thức mà chúng tôi gặp phải. Do đó, số cách phân loại và giải quyết các thẻ hỗ trợ theo thứ tự hàng ngàn. Ngoài ra, sự tăng trưởng của Uber, đòi hỏi chúng ta phải lặp đi lặp lại với tốc độ chưa từng thấy. Một giải pháp hoạt động ngày hôm nay có thể không hoạt động trong một vài tháng nếu chúng ta không tính đến sự tăng trưởng kinh doanh.

Học sâu đã cách mạng hóa nhiều lĩnh vực như dịch máy, nhận dạng giọng nói, thị giác máy tính và hiểu ngôn ngữ tự nhiên và đã đạt được hiệu suất ngang bằng hoặc vượt trội so với các chuyên gia thẻ con người trong một số nhiệm vụ nhất định. Ví dụ, các mô hình học tập sâu đã vượt trội hơn con người trong một số nhiệm vụ phân loại và nhận dạng hình ảnh. Đối với nhiệm vụ sử dụng hình ảnh võng mạc để phát hiện bệnh mắt tiểu đường, Google đã chỉ ra rằng các thuật toán học sâu thực hiện ngang tầm với các bác sĩ nhãn khoa. Thành công gần đây của AlphaGo chứng minh rằng các thuật toán học sâu kết hợp với học tăng cường thậm chí có thể đánh bại cả những người chơi cờ vây người giỏi nhất thế giới trong trò chơi cờ thường phức tạp nhất của loài người.

Dựa trên những ví dụ này và nhiều hơn nữa, học sâu dường như là một lựa chọn tự nhiên cho sự phát triển của COTA v2. Thật vậy, thông qua các thử nghiệm ngoại tuyến, chúng tôi thấy rằng các mô hình học sâu có thể cung cấp dự đoán độ phân giải thẻ chính xác hơn nhiều so với COTA v1.

Chuyển sang COTA v2 với “học sâu”

Tóm lại, COTA v1 được xây dựng với các kỹ thuật NLP truyền thống dựa trên mô hình hóa chủ đề và kỹ thuật học máy kết hợp các tính năng văn bản, phân loại và số, như trong Hình 1 (a), bên dưới:

Hình 1. (a) Kiến trúc mô hình của COTA v1 tận dụng mô hình chủ đề, kỹ thuật tính năng kỹ thuật truyền thống và thuật toán xếp hạng theo điểm, trong khi (b) COTA v2 hỗ trợ kiến trúc học sâu với hỗn hợp các tính năng đầu vào.

Để trích xuất các tính năng văn bản, Đường ống NLP được xây dựng để xử lý các thông điệp thẻ đến. Mô hình chủ đề (một loại mô hình thống kê để khám phá các "chủ đề" trừu tượng xảy ra trong một bộ sưu tập tài liệu) đã được sử dụng để trích xuất tính năng đại diện từ tính năng văn bản. Kỹ thuật tính năng bổ sung đã được sử dụng để tạo ra sự tương tự cosine. Khi mỗi tính năng được thiết kế, tất cả các tính năng được đưa vào thuật toán xếp hạng theo điểm nhị phân để dự đoán các phản hồi Loại liên hệ và Trả lời.

Hình 1 (b) mô tả kiến trúc học sâu mà chúng tôi đã sử dụng cho COTA v2. Tính năng văn bản trải qua quá trình tiền xử lý NLP điển hình như làm sạch văn bản và mã thông báo (không hiển thị) và mỗi từ trong thẻ được mã hóa bằng cách sử dụng một lớp nhúng (không hiển thị) để chuyển từ thành biểu diễn dày đặc chạy tiếp qua các lớp chập mã hóa toàn bộ văn bản. Các tính năng phân loại được mã hóa bằng cách sử dụng một lớp nhúng để nắm bắt sự gần gũi giữa các loại khác nhau. Các tính năng số được chuẩn hóa hàng loạt để ổn định quá trình đào tạo. Các thử nghiệm ngoại tuyến của chúng tôi cho thấy hệ thống học sâu COTA v2 thực hiện tốt hơn một cách có hệ thống (cải thiện 8-16%) so với COTA v1 cho cả hai nhiệm vụ riêng lẻ là xác định Loại liên hệ hoặc Trả lời độc lập và nhiệm vụ chung là dự đoán Loại liên hệ và Trả lời cùng một lúc.

Hình 2. Các sơ đồ t-SNE mô tả các nhúng được học bởi các mô hình học sâu cho a) từ và b) các loại liên hệ.

Hình 2, ở trên, cho thấy phương pháp giảm kích thước (t-SNE) của các phần nhúng mà chúng ta đã học thông qua các mô hình học sâu. Ví dụ, trong Hình 2 (a), chúng tôi hình dung một số từ khóa dành riêng cho Uber và quan sát thấy rằng “Xe” và “Phương tiện” rất gần nhau trong việc nhúng biểu đồ t-SNE. Các từ liên quan đến thanh toán, chẳng hạn như phí dụng, tín dụng, và giá thẻ, cũng được nhóm lại với nhau trong biểu đồ.

Hình 2 (b) biểu thị các nhúng được học cho các loại liên hệ với mỗi điểm dữ liệu tương ứng với một loại liên hệ duy nhất. Các loại liên hệ được mã hóa màu thành ba nhóm chính: Người ngồi xe, Người lái xe, và Người khác (ví dụ: người ăn, nhà hàng, v.v.). Biểu đồ t-SNE cho thấy sự phân nhóm rõ ràng của các loại liên hệ liên quan đến người ngồi và người lái. Những hình dung trực quan này xác nhận rằng mô hình đang học các biểu diễn hợp lý và gợi ý rằng nó có khả năng nắm bắt các mối tương quan và kết nối ngữ nghĩa giữa các từ và mối quan hệ giữa các loại liên hệ.

Nói tóm lại, học sâu có thể cải thiện độ chính xác dự đoán top 1 của giải pháp lên 16% (từ 49% đến 65%) cho mô hình Kiểu liên hệ và 8% (từ 47% đến 55%) cho mô hình Trả lời so với COTA v1 , có thể trực tiếp cải thiện trải nghiệm hỗ trợ khách hàng.

Những thách thức và giải pháp để triển khai COTA v2

Do hiệu suất mạnh mẽ của các mô hình học sâu trong phân tích ngoại tuyến của chúng tôi, chúng tôi đã quyết định tích hợp hệ thống COTA v2 vào sản xuất. Tuy nhiên, do sự phức tạp của việc tích hợp cả chuyển đổi NLP và đào tạo học tập sâu, cũng như sử dụng một lượng lớn dữ liệu đào tạo, việc triển khai các mô hình học sâu COTA v2 của chúng tôi đi kèm với những thách thức hợp lý.

Trong trường hợp lý tưởng nhất, chúng tôi muốn tận dụng Spark cho các biến đổi NLP theo kiểu phân tán. Tính toán Spark thường được thực hiện bằng cách sử dụng các cụm CPU (bộ xử lý trung tâm - Central Processing Unit). Mặt khác, đào tạo học sâu chạy hiệu quả hơn trên cơ sở hạ tầng dựa trên GPU (bộ xử lý đồ họa - Graphics Processing Unit). Để giải quyết tính hai mặt này, chúng tôi cần tìm ra cách sử dụng cả chuyển đổi Spark và đào tạo GPU, cũng như xây dựng một Đường ống thống nhất để đào tạo và phục vụ mô hình học sâu.

Một thách thức khác mà chúng tôi đã giải quyết là xác định cách duy trì sự mới mẻ của mô hình dựa trên tính chất năng động của hoạt động kinh doanh Uber. Để giải quyết vấn đề này, một đường ống dẫn là cần thiết để thường xuyên đào tạo lại và triển khai lại các mô hình.

Để giải quyết thử thách đầu tiên, chúng tôi đã xây dựng một đường ống học sâu dữ liệu Spark (DLSP) học tập sâu để tận dụng cả Spark cho các biến đổi NLP và GPU để đào tạo học sâu. Đối với thử thách thứ hai, chúng tôi đã tích hợp một công cụ lập lịch công việc nội bộ và xây dựng Đường ống mô hình quản lý vòng đời (MLMP) trên DLSP, cho phép chúng tôi lên lịch và chạy từng công việc với tần suất cần thiết. Hai đường ống này cho phép chúng tôi không chỉ đào tạo và triển khai các mô hình học tập sâu vào hệ thống sản xuất Uber, mà còn đào tạo lại và làm mới các mô hình để giữ cho chúng hoạt động tốt nhất

Trong hai phần tiếp theo, chúng ta sẽ thảo luận thẻ  hai đường ống chi tiết hơn.

COTA v2 dựa trên đường ống học sâu dữ liệu Spark

Khi thiết kế DLSP, chúng tôi muốn phân công nhiệm vụ cho CPU và GPU dựa trên phần cứng nào sẽ hiệu quả nhất. Xác định đường ống thành hai giai đoạn, một cho xử lý trước Spark và một cho học sâu, dường như là cách tốt nhất để phân bổ tải công việc. Bằng cách mở rộng khái niệm thẻ Spark Pipeline (Đường ống Spark), chúng tôi có thể phục vụ các mô hình cho cả dịch vụ dự đoán theo đợt và dự đoán thời gian thực bằng cơ sở hạ tầng hiện có của chúng tôi.

Đào tạo

Đào tạo mô hình được chia thành hai giai đoạn, như trong Hình 3 (a), bên dưới:

  1. Biến đổi tiền xử lý bằng Spark: Chúng tôi tận dụng các cụm Spark lớn để thực hiện xử lý trước dữ liệu và phù hợp với các biến đổi cần thiết cho cả đào tạo và phục vụ. Tất cả các biến đổi được thực hiện trên dữ liệu trong quá trình tiền xử lý được lưu dưới dạng biến áp Spark, sau đó được sử dụng để xây dựng Đường ống Spark cho quá trình phục vụ. Quá trình tiền xử lý phân tán trong cụm Spark nhanh hơn nhiều so với tiền xử lý dữ liệu trên một máy GPU nút đơn. Chúng tôi tính toán cả các phép biến đổi được trang bị (các phép biến đổi yêu cầu dữ liệu bền vững, ví dụ: String Indexer) và các phép biến đổi không được trang bị (ví dụ: làm sạch các thẻ HTML từ các chuỗi, v.v.) trong cụm Spark.
  2. Đào tạo học sâu bằng cách sử dụng TensorFlow (thư viện phần mềm mã nguồn mở): Sau khi quá trình tiền xử lý từ bước (1) hoàn tất, chúng tôi tận dụng dữ liệu được tiền xử lý trước để đào tạo mô hình học sâu bằng cách sử dụng TensorFlow. Mô hình được đào tạo từ giai đoạn này sau đó được hợp nhất với đường ống Spark (Spark Pipeline) được tạo ở bước (1). Điều này tạo ra Spark Pipeline cuối cùng bao gồm các máy biến áp tiền xử lý và mô hình TensorFlow, có thể được sử dụng để chạy dự đoán. Chúng tôi có thể kết hợp Đường ống Spark với mô hình TensorFlow bằng cách triển khai một loại máy biến áp đặc biệt có tên là TFTransformer, đưa mô hình TensorFlow vào Spark. Điều quan trọng cần lưu ý là vì tất cả các Spark Transformers đều được hỗ trợ bởi các triển khai Java, nên bộ chuyển đổi màn hình LCD có mẫu này.

Hình 3. Chúng tôi đã xây dựng một kiến trúc Spark Pipeline học sâu cho a) các mô hình đào tạo và b) phục vụ các yêu cầu.

Phục vụ

Hình 3 (b) mô tả cách chúng tôi phục vụ mô hình được đào tạo bằng cách sử dụng Spark Pipeline học sâu cho cả dịch vụ dự đoán theo đợt và dịch vụ dự đoán thời gian thực. Đường ống Spark được xây dựng từ đào tạo chứa cả máy biến áp tiền xử lý và biến đổi TensorFlow. Chúng tôi đã mở rộng Michelangelo để hỗ trợ phục vụ Spark Pipelines chung và sử dụng cơ sở hạ tầng triển khai và để phục vụ mô hình học tập sâu. Đường ống được sử dụng để phục vụ chạy trên Máy ảo Java (JVM - Java Virtual Machine). Hiệu suất chúng ta thấy trong khi phục vụ có độ trễ p95 <10ms, điều này cho thấy lợi thế của độ trễ thấp khi sử dụng cơ sở hạ tầng phục vụ JVM hiện có cho các mô hình học sâu. Bằng cách mở rộng Spark Pipelines để đóng gói các mô hình học sâu, chúng tôi có thể tận dụng tốt nhất cả thế giới CPU và GPU: 1) tính toán phân tán các biến đổi Spark và phục vụ Spark Pipelines có độ trễ thấp bằng CPU và 2) tăng tốc đào tạo mô hình học tập sâu sử dụng GPU.

Quản lý vòng đời của mô hình Đường ống: giữ cho các mô hình luôn mới

Để ngăn hiệu suất mô hình COTA v2 bị phân rã theo thời gian, chúng tôi đã xây dựng Đường ống quản lý vòng đời mô hình (MLMP) trên DLSP của chúng tôi. Cụ thể, chúng tôi đã tận dụng công cụ lập lịch công việc nội bộ của Uber - Piper để xây dựng Đường ống đầu cuối để đào tạo lại và triển khai lại các mô hình của chúng tôi với tần suất cố định.

Hình 4. Đường ống quản lý vòng đời mô hình của chúng tôi bao gồm sáu công việc, bao gồm Data ETL, Spark Transformations và Model Merging.

Hình 4, ở trên, mô tả dòng chảy của đường ống này. Tổng cộng có sáu công việc, nó sử dụng các API (Application Programming Interface - giao diện lập trình ứng dụng)  hiện có từ Michelangelo để đào tạo lại mô hình. Các công việc này tạo thành một biểu đồ chu kỳ có hướng (DAG) với sự phụ thuộc được chỉ định bởi các mũi tên:

  1. Dữ liệu ETL (Extract Transform Load - quá trình làm thế nào dữ liệu được đưa vào từ các nguồn dữ liệu vào kho dữ liệu): Điều này liên quan đến việc viết một trích xuất dữ liệu, chuyển đổi cơ bản và tải công việc (ETL) để chuẩn bị dữ liệu. Nó thường lấy dữ liệu từ một số nguồn dữ liệu khác nhau, chuyển đổi nó thành định dạng đúng và đưa nó vào cơ sở dữ liệu Hive
  2. Chuyển đổi Spark: Bước này chuyển đổi dữ liệu thô (văn bản, phân loại, số, v.v.) thành định dạng Tensor để nó có thể được sử dụng bởi biểu đồ TensorFlow cho đào tạo mô hình. Việc chuyển đổi cơ bản sử dụng động cơ Spark - Spark Engine -  thông qua Michelangelo theo kiểu điện toán phân tán. Các máy biến áp được lưu vào một cửa hàng mô hình.
  3. Truyền dữ liệu: Các cụm máy tính có CPU thực hiện các phép biến đổi Spark. Đào tạo học sâu đòi hỏi GPU để tăng tốc tiến độ. Do đó, chúng tôi chuyển dữ liệu đầu ra từ Bước 2 sang cụm GPU.
  4. Đào tạo học tập sâu: Một khi dữ liệu được chuyển đến các cụm GPU. Công việc ở đây là kích hoạt để mở một phiên GPU với bộ chứa Docker tùy chỉnh và bắt đầu quá trình đào tạo học tập sâu. Sau khi đào tạo xong, một tệp mô hình TensorFlow được lưu vào kho lưu trữ mô hình.
  5. Sáp nhập mô hình: Các máy biến áp Spark từ Bước 2 và mô hình TensorFlow từ Bước 4 được hợp nhất để tạo thành mô hình cuối cùng.
  6. Triển khai mô hình: Mô hình cuối cùng được triển khai và model_id được tạo như một tham chiếu đến mô hình mới được triển khai. Các dịch vụ siêu nhỏ bên ngoài có thể đạt điểm cuối bằng cách sử dụng khung phục vụ của Thrift bằng cách tham chiếu model_id.

Kiểm tra trực tuyến: COTA v1 so với COTA v2

Để xác thực hiệu suất của các mô hình học sâu COTA v2 mà chúng tôi đã quan sát ngoại tuyến, chúng tôi đã thực hiện kiểm tra trực tuyến trước khi triển khai hệ thống.

Chiến lược thử nghiệm

Để ngăn ngừa sai lệch lấy mẫu có sẵn, chúng tôi đã tiến hành thử nghiệm A / A trước khi chúng tôi bật thử nghiệm A / B, như trong Hình 5 bên dưới:

(Thử nghiệm A / A là chiến thuật sử dụng thử nghiệm A / B để thử nghiệm hai phiên bản giống hệt nhau của một trang với nhau. Thử nghiệm A / B, còn được gọi là thử nghiệm phân tách hoặc thử nghiệm xô - split testing or bucket testing - là phương pháp so sánh hai phiên bản của trang web hoặc ứng dụng với nhau để xác định phiên bản nào hoạt động tốt hơn).

Hình 5. Chiến lược thử nghiệm tổng thể để so sánh các hệ thống COTA v1 và COTA v2.

Trong cả hai thử nghiệm A / A và A / B, thẻ hỗ trợ được phân ngẫu nhiên vào các nhóm kiểm soát và điều trị dựa trên mức chia 50/50. Trong giai đoạn thử nghiệm A / A, cả hai nhóm kiểm soát và điều trị đều nhận được dự đoán từ cùng một mô hình COTA v1. Trong khi ở giai đoạn thử nghiệm A / B, nhóm điều trị được phục vụ bởi các mô hình học tập sâu COTA v2.

Các kết quả

Chúng tôi đã chạy thử nghiệm A / A trong một tuần và thử nghiệm A / B trong khoảng một tháng. Hình 6, bên dưới, mô tả hai số liệu chính mà chúng tôi theo dõi: độ chính xác của mô hình (chúng tôi sử dụng mô hình Loại liên hệ làm ví dụ ở đây) và thời gian xử lý trung bình trên mỗi thẻ. Như được hiển thị trong Hình 6 (a), không có sự khác biệt thẻ hiệu suất mô hình trong giai đoạn thử nghiệm A / A, trong khi có một bước nhảy lớn sau khi chúng tôi bật thử nghiệm A / B. Những kết quả này xác nhận rằng hệ thống học sâu của COTA v2 cung cấp các giải pháp chính xác hơn cho các đại lý so với COTA v1.

Thời gian xử lý trung bình trên mỗi thẻ thấp hơn nhiều đối với nhóm điều trị trong suốt giai đoạn thử nghiệm A / B, như trong Hình 6 (b). Một quan sát bổ sung từ Hình 6 (a) là hiệu suất mô hình giảm dần theo thời gian, nêu bật sự cần thiết của quản lý mô hình Đường ống MLMP được hiển thị trong Hình 5. (Lưu ý: để đảm bảo tính nhất quán, chúng tôi đã không đào tạo lại các mô hình trong suốt quá trình thí nghiệm).

Thử nghiệm trực tuyến của chúng tôi một lần nữa chứng minh rằng việc cung cấp đủ dữ liệu đào tạo cho các mô hình học sâu COTA v2 của chúng tôi có thể vượt trội hơn đáng kể so với các mô hình học máy cổ điển COTA v1.

Hình 6. Các số liệu chính từ kiểm tra trực tuyến: a) độ chính xác của mô hình và b) thời gian xử lý trung bình trong cả hai thử nghiệm A / A và A / B trên cơ sở hàng ngày.

Một phân tích thống kê cho thấy trong quá trình thử nghiệm A / A không có sự khác biệt có ý nghĩa thống kê giữa thời gian xử lý trung bình của các nhóm kiểm soát và điều trị, trong khi có sự khác biệt có ý nghĩa thống kê trong thử nghiệm A / B. Đây là mức giảm tương đối 6,6%, tăng tốc thời gian giải quyết thẻ và cải thiện tính chính xác của các đề xuất giải quyết thẻ của chúng tôi. Ngoài ra, chúng tôi cũng đã đo điểm hài lòng của khách hàng và nhận thấy sự cải thiện nhẹ do sử dụng COTA v2.

Ngoài việc cải thiện trải nghiệm hỗ trợ khách hàng, COTA v2 cũng sẽ tiết kiệm cho công ty hàng triệu đô la mỗi năm bằng cách hợp lý hóa quy trình giải quyết thẻ hỗ trợ.

Bước tiếp theo

Với hiệu suất mạnh mẽ của các mô hình học sâu của chúng tôi trong COTA v2, chúng tôi dự định sẽ sử dụng dự đoán loại vấn đề trong tương lai để xác định đại lý hỗ trợ khách hàng nào định tuyến một thẻ nhất định, vì các đại lý đó thường có chuyên môn thẻ một loại vấn đề cụ thể. Những cập nhật này sẽ tăng khả năng chúng tôi xác định đúng đại lý để giải quyết một thẻ trong lần định tuyến đầu tiên, cải thiện hiệu quả của toàn bộ hệ thống hỗ trợ thẻ.

Chúng tôi cũng đang xem xét các tính năng cho phép chúng tôi phản hồi nhanh hơn với các thẻ chỉ yêu cầu thông tin, ví dụ: các thẻ đặt ra câu hỏi như làm cách nào để cập nhật ảnh đại diện Uber của tôi? thông tin (hướng dẫn trong trường hợp này). Đây có thể chỉ là một tập hợp con nhỏ của một vài phần trăm của tất cả các thẻ hỗ trợ khách hàng, nhưng có thể được COTA v2 giải quyết tự động mà không cần sự giám sát của đại lý. Hợp lý hóa các phản ứng tĩnh này sẽ giúp khách hàng tiết kiệm thời gian và trao quyền cho các đại lý tập trung vào các thẻ thách thức hơn, cung cấp dịch vụ chăm sóc khách hàng tốt hơn.

Nguồn : THEO SAGA.VN
Nga Dương
Nga Dương