Phỏng vấn

Yoav Naveh, Đồng sáng lập kiêm Đồng CEO của Reindeer – Loạt bài phỏng vấn

mm
Thêm Unite.AI vào các nguồn ưu tiên của bạn trên Google
Yoav Naveh, Co-Founder and Co-CEO of Reindeer

Yoav Naveh là Đồng sáng lập kiêm Đồng CEO của Reindeer, với kinh nghiệm xây dựng các công ty công nghệ, mở rộng quy mô doanh nghiệp và đầu tư vào các nhà sáng lập. Trước khi thành lập Reindeer, ông xây dựng ConvertMedia, tiếp tục công việc tại Taboola và đầu tư thông qua INT3. Hiện nay, ông tập trung giúp các doanh nghiệp chuyển từ triển khai AI riêng lẻ sang sử dụng các tác tử có thể xử lý công việc vận hành phức tạp, học hỏi từ chuyên môn của con người và duy trì độ tin cậy khi quy trình kinh doanh thay đổi.

Reindeer phát triển các tác tử AI dành cho doanh nghiệp, phục vụ những hoạt động cốt lõi trong các lĩnh vực như tài chính, chuỗi cung ứng, logistics và dịch vụ dùng chung. Nền tảng của công ty kết hợp việc thực thi quy trình làm việc với phản hồi từ chuyên gia, khâu đánh giá và sự phê duyệt của con người, nhờ đó các tác tử có thể thích ứng với những trường hợp ngoại lệ và chính sách không ngừng thay đổi. Trong cuộc phỏng vấn này, Naveh thảo luận về những hạn chế của mô hình triển khai phụ thuộc nhiều vào kỹ thuật, cách chuyển hóa tri thức tổ chức thành ngữ cảnh cho tác tử, cũng như công tác quản trị và đo lường cần thiết để giảm tổng công sức của con người theo thời gian.

Sau khi xây dựng ConvertMedia, mở rộng hoạt động tại Taboola và đầu tư vào các nhà sáng lập khác thông qua INT3, vấn đề nào đã thôi thúc ông quay lại khởi nghiệp, và điều đó đã định hình quyết định đồng sáng lập Reindeer ra sao?

Thị trường AI quá sôi động để chúng tôi có thể đứng ngoài cuộc. Tôi và người đồng sáng lập Yair đặc biệt quan tâm đến khoảng cách giữa mức độ hữu ích của AI khi mỗi người sử dụng riêng lẻ và những khó khăn mà doanh nghiệp vẫn gặp phải khi áp dụng AI trên quy mô lớn. Công nghệ đang phát triển với tốc độ đáng kinh ngạc, nhưng hầu hết các tổ chức vẫn chật vật chuyển tiềm năng ấy thành những thay đổi thiết thực trong hoạt động.

AI sẽ làm thay đổi cách các công ty vận hành, nhưng để đạt được điều đó cần nhiều hơn là công nghệ tốt hơn. Cần có những nhà lãnh đạo sẵn sàng suy nghĩ lại về cách thức công việc được thực hiện, cùng một phương thức thiết thực để đưa AI vào hoạt động thường nhật mà không tạo thêm những tầng phức tạp mới.

Thách thức đó đã định hình Reindeer. Chúng tôi xây dựng một nền tảng giúp doanh nghiệp triển khai từ tác tử đầu tiên đến cả một đàn tác tử biết học hỏi từ phản hồi của con người và ngày càng hoàn thiện theo thời gian. Mục tiêu của chúng tôi là thu hẹp khoảng cách giữa tiềm năng của AI và việc ứng dụng AI trong thực tế, giúp các công ty chuyển đổi những hoạt động cốt lõi thành lực lượng vận hành bằng AI tác tử mà không phải xây dựng lại hoặc liên tục bảo trì từng tác tử.

Ông từng lập luận rằng mô hình kỹ sư triển khai trực tiếp có nguy cơ biến AI doanh nghiệp thành một ngành dịch vụ cần nhiều nhân lực. Việc bố trí kỹ sư làm việc gắn bó với khách hàng tạo ra giá trị lâu dài ở đâu, và khi nào cách làm này trở thành sự phụ thuộc khiến khách hàng không thể mở rộng quy mô?

Các kỹ sư triển khai trực tiếp (FDE) rất hữu ích khi cần tích hợp phức tạp và đưa những tác tử đầu tiên vào vận hành thực tế. Vấn đề bắt đầu khi chính các quy trình công việc thay đổi, còn FDE thì trở thành lực lượng cần thiết thường trực để duy trì hoạt động của các tác tử thực hiện những công việc đó. Điều này đặc biệt đúng khi mở rộng quy mô. Mô hình FDE hiệu quả khi có 5 tác tử. Nhưng khi có một trăm tác tử, mô hình này không còn phù hợp.

Nếu mỗi quy trình làm việc mới hoặc tình huống ngoại lệ bất ngờ đều đòi hỏi thêm nhân lực kỹ thuật, thì bạn không mở rộng quy mô phần mềm mà đang tăng quy mô lực lượng lao động đắt đỏ.

Hầu hết các công ty triển khai FDE đều khẳng định rằng cuối cùng các kỹ sư của họ sẽ chuyển sang những nhiệm vụ khác. Doanh nghiệp cần yêu cầu bằng chứng xác thực trước khi ký hợp đồng đòi hỏi phải có FDE. Chúng ta đã thấy RPA trở nên mong manh ra sao khi các quy trình kinh doanh thay đổi. Không nên cho rằng các tác tử được xây dựng thủ công sẽ khác.

Quy trình làm việc trong doanh nghiệp thường có những trường hợp ngoại lệ không được ghi chép và các nhóm áp dụng những cách làm mâu thuẫn nhau. Reindeer ghi nhận cách công việc thực sự được thực hiện như thế nào, đồng thời phân biệt tri thức tổ chức hữu ích với những thói quen không nên tự động hóa ra sao?

Hầu hết doanh nghiệp sở hữu lượng tri thức tổ chức khổng lồ nhưng chưa được ghi chép ở bất cứ đâu. Tri thức ấy nằm trong đầu người lao động. Ban đầu, các tác tử của chúng tôi chỉ có một phần kiến thức; chúng học hỏi thông qua những tình huống thực tế và hỏi ý kiến chuyên gia trong lĩnh vực khi gặp phải tình huống chưa từng biết.

Tuy nhiên, học hỏi từ một nhân viên không có nghĩa là sao chép hành vi của họ một cách máy móc. Hệ thống của chúng tôi phân biệt các trường hợp ngoại lệ riêng lẻ với những khuôn mẫu lặp đi lặp lại, đồng thời đề xuất những thay đổi có phạm vi rộng hơn để con người phê duyệt.

Chúng tôi không tìm cách tự động hóa mọi thói quen. Mục tiêu của chúng tôi là chuyển hóa tri thức tổ chức có giá trị thành năng lực thông minh đáng tin cậy mà không buộc các kỹ sư phải dự đoán trước mọi tình huống.

Hầu hết các công ty phát triển AI tác tử đều bắt đầu bằng việc ghi chép, sau đó lập trình quy trình dựa trên các cuộc phỏng vấn và việc xem xét tỉ mỉ dữ liệu quá khứ. Nhưng trên thực tế, cách học một quy trình hiệu quả nhất diễn ra mỗi khi có thành viên mới gia nhập nhóm: họ không học thuộc dữ liệu của cả một năm hay một quy trình vận hành tiêu chuẩn (SOP) dài 3.000 trang. Họ học một vài kỹ năng, xem một vài ví dụ, bắt đầu làm việc, đặt câu hỏi khi gặp điều chưa hiểu và dần tích lũy kiến thức. Đó chính là quy trình chúng tôi xây dựng.

AI tác tử cũng tạo cơ hội để các công ty hình dung lại quy trình thay vì chỉ tự động hóa quy trình theo cách đang vận hành. Các nhóm chỉ có con người, hoạt động tự động hóa dựa trên quy tắc và phần mềm truyền thống đều định hình quy trình theo những giới hạn riêng của mình. Bằng cách để các tác tử học hỏi cùng chuyên gia, Reindeer giúp doanh nghiệp suy nghĩ lại về cách một quy trình nên vận hành, bao gồm những cách làm nào cần giữ lại, cách làm nào nên loại bỏ, và ở khâu nào tác tử hay con người có thể tạo ra giá trị lớn nhất.

Khi nói các tác nhân của Reindeer liên tục học hỏi trong môi trường vận hành thực tế, cụ thể điều gì thay đổi: trọng số mô hình, bộ nhớ, logic quy trình hay các chính sách rõ ràng? Anh có thể kể một trường hợp ngoại lệ giúp tác nhân xử lý khác đi những trường hợp tương tự trong tương lai không?

Những gì thay đổi là ngữ cảnh và kỹ năng của tác nhân: logic quy trình, chính sách và hướng dẫn về thời điểm áp dụng từng nội dung.

Hãy lấy một tác nhân xử lý hóa đơn làm ví dụ. Tác nhân nhận được hóa đơn cao hơn 4% so với đơn đặt hàng và không tìm thấy chính sách nào áp dụng cho trường hợp đó. Thay vì xử lý hóa đơn, tác nhân chuyển vụ việc lên chuyên gia. Chuyên gia giải thích rằng nhà cung cấp này được chấp thuận áp dụng ngoại lệ đối với phụ phí nhiên liệu. Tác nhân xử lý xong trường hợp đó, còn lời giải thích được lưu làm ngữ cảnh chỉ dành riêng cho nhà cung cấp ấy.

Nếu loại ngoại lệ tương tự lại xuất hiện với các nhà cung cấp khác và những chuyên gia khác cũng xử lý theo cùng một cách, hệ thống sẽ đề xuất thay đổi chính sách, chẳng hạn như “chấp nhận phụ phí nhiên liệu lên đến 5% khi hợp đồng cho phép”. Đề xuất đó phải trải qua quá trình kiểm thử và được con người phê duyệt trước khi tác nhân áp dụng. Câu trả lời của một chuyên gia giải quyết một trường hợp. Một xu hướng lặp lại qua nhiều trường hợp có thể trở thành cơ sở để xây dựng quy tắc mới.

Quyết định của một nhân viên có thể phù hợp với một khách hàng hoặc giao dịch cụ thể nhưng không thích hợp để áp dụng thành quy tắc chung. Anh xác định thế nào khi nào phản hồi nên chỉ được xem là ngoại lệ một lần, và khi nào nên trở thành đề xuất thay đổi chính sách?

Chúng tôi tách biệt việc giải quyết một trường hợp cụ thể với việc thay đổi cách tác nhân vận hành về sau.

Một nhân viên có thể chấp thuận ngoại lệ cho một khách hàng, nhưng điều đó không có nghĩa là ngoại lệ tương tự nên được áp dụng rộng rãi. Tôi thậm chí cho rằng hai nhân viên khác nhau có thể đưa ra cách giải quyết khác nhau cho cùng một ngoại lệ của khách hàng. Hệ thống của chúng tôi đánh giá các tình huống, nhận diện những xu hướng lặp lại, dung hòa các mâu thuẫn và tìm kiếm những xung đột tiềm ẩn với các chính sách hiện hành.

Khi có bằng chứng ủng hộ một thay đổi rộng hơn, chúng tôi cho tác nhân chạy qua nền tảng đánh giá của mình—có thể gọi đó là một “Truman Show” dành cho các tác nhân—rồi đề xuất cập nhật để con người phê duyệt.

Mục tiêu là học hỏi từ con người, chứ không sao chép quyết định của họ một cách mù quáng. Nếu không, bạn chỉ đang tự động hóa những sai lầm.

Một tác nhân có thể cải thiện qua những trường hợp gần đây nhưng lại kém tin cậy hơn trong các tình huống trước đây nó từng xử lý đúng. Một thay đổi được đề xuất phải vượt qua quy trình kiểm thử và phê duyệt nào trước khi được đưa vào vận hành, và các bạn phát hiện cũng như khắc phục tình trạng suy giảm hiệu năng như thế nào?

Học hỏi liên tục mà không có cơ chế quản trị sẽ rất nguy hiểm, vì vậy mọi thay đổi được đề xuất đều phải vượt qua ba lớp bảo vệ: kiểm thử hồi quy, phê duyệt của con người và ngưỡng độ tin cậy quyết định khi nào tác nhân được tự xử lý.

Kiểm thử là bước đầu tiên, và việc này khó hơn tưởng tượng vì công việc vận hành không có đáp án chuẩn cố định. Chúng tôi chọn các trường hợp tiêu biểu từ phản hồi của chuyên gia, xác định tiêu chí so sánh kết quả rồi chạy lại những trường hợp đó với cả tác nhân hiện tại lẫn phiên bản được đề xuất. Các hành động gây ra tác động phát sinh, chẳng hạn như gửi email, được chạy trong một trình mô phỏng xây dựng từ những lần chạy trước; các trường hợp kiểm thử không còn phù hợp với chính sách hiện hành sẽ bị loại bỏ. Để đo lường chính xác tác động của một thay đổi, các tác nhân phải tin rằng chúng đang hoạt động trong thế giới thực và hành động của chúng thực sự tạo ra hệ quả—chẳng hạn như ghi một bản ghi vào SAP hoặc gửi email cho khách hàng. Đó là cách duy nhất để xây dựng một khuôn khổ đánh giá thực sự cho từng tác nhân.

Sau đó, một quản lý sẽ xem xét thay đổi, bằng chứng làm căn cứ cho thay đổi và kết quả kiểm thử, rồi có thể phê duyệt, điều chỉnh hoặc từ chối. Cách tác nhân vận hành sẽ không thay đổi cho đến khi có phê duyệt.

Ngưỡng độ tin cậy giúp bảo vệ doanh nghiệp sau khi thay đổi được đưa vào vận hành. Tác nhân chỉ tự xử lý khi mức độ tin cậy vượt ngưỡng; mọi trường hợp thấp hơn ngưỡng đều được chuyển cho chuyên gia. Các nhóm vận hành tự điều chỉnh ngưỡng này, nhờ đó họ có thể bắt đầu một cách thận trọng và trao cho tác nhân nhiều quyền tự chủ hơn khi thành tích xử lý của tác nhân ngày càng được cải thiện.

Nếu chất lượng giảm sau một thay đổi, hệ thống sẽ tự động siết chặt các ngưỡng rà soát để có thêm nhiều trường hợp được chuyển cho chuyên gia; phản hồi của họ sẽ giúp phát hiện vấn đề thông qua chính vòng lặp đã đề xuất thay đổi đó. Mỗi thay đổi chính sách đều được quản lý phiên bản, có thể truy nguyên và được ghi nhật ký, nhờ đó nhóm có thể biết nội dung nào đã thay đổi, ai phê duyệt và vì sao, đồng thời khôi phục phiên bản trước.

Giảm khối lượng công việc của đội ngũ kỹ thuật vẫn có thể khiến các nhóm vận hành phải dành nhiều công sức để rà soát ngoại lệ và sửa lỗi cho tác nhân. Các bạn đo lường thế nào để biết Reindeer giảm tổng công sức cần thiết của con người, thay vì chỉ chuyển phần việc đó sang một nhóm khác?

Thực tế là hầu hết các công ty hiện đã có một nhóm nhân viên thực hiện công việc này thủ công. Mục tiêu của chúng tôi không phải chuyển khối lượng công việc ấy sang một nhóm khác, mà là giảm dần theo thời gian. Chúng tôi chọn những người giàu kinh nghiệm nhất trong nhóm hiện có và giúp họ hướng dẫn tác nhân xử lý ngoại lệ cũng như tự đưa ra quyết định tốt hơn.

Vấn đề với mô hình FDE là mô hình này thường chuyển công việc từ những nhân viên vận hành có chi phí tương đối thấp sang các kỹ sư đắt đỏ. Như vậy không giải quyết được bài toán nhân lực mà còn khiến chi phí tăng lên. Reindeer không đưa kỹ sư vào phương trình đó. Thay vào đó, chúng tôi đo lường thành công bằng mức độ gia tăng của khối lượng công việc mà các tác nhân có thể tự xử lý theo thời gian, cũng như mức độ giảm thiểu sự can thiệp của con người trong toàn bộ quy trình.

Chúng tôi theo dõi ba chỉ số: tỷ lệ các trường hợp được tác nhân xử lý trọn vẹn từ đầu đến cuối mà không cần con người can thiệp, số lần chuyên gia phải tham gia xử lý mỗi trường hợp và tổng thời gian xử lý mỗi trường hợp, tính gộp cả tác nhân lẫn con người. Nếu chỉ số thứ ba không giảm, thì chúng tôi chỉ đang chuyển công việc từ chỗ này sang chỗ khác.

Anh có thể kể về một trường hợp triển khai tại Hellmann Worldwide Logistics hoặc Papaya Global, giải thích những thay đổi từ lúc ra mắt đến khi vận hành liên tục không? Độ chính xác, tỷ lệ ngoại lệ, thời gian xử lý và mức độ can thiệp của con người cần thiết đã thay đổi ra sao?

Hellmann Worldwide Logistics là ví dụ điển hình về cách các tác nhân có thể cải thiện hoạt động thực tế theo thời gian. Nhóm định giá của công ty đã dành rất nhiều thời gian để xử lý thủ công các yêu cầu vận chuyển qua email, bảng tính và những tài liệu khác; thường phải mất nhiều ngày mới lập được báo giá.

Chúng tôi bắt đầu với khoảng 20 yêu cầu mẫu để tìm hiểu quy trình làm việc và huấn luyện tác nhân. Sau đó, các chuyên gia định giá của Hellmann bắt đầu trực tiếp làm việc với hệ thống, đưa ra phản hồi và giúp hệ thống xử lý các trường hợp ngoại lệ. Chúng tôi theo dõi độ chính xác và tốc độ trong suốt quá trình thử nghiệm, đồng thời tiếp tục giám sát hiệu suất sau khi tác nhân được đưa vào vận hành thực tế.

Hiện nay, các yêu cầu thông thường được xử lý tự động, còn những trường hợp phức tạp hơn được chuyển cho nhóm phụ trách. Điều quan trọng là tác nhân nhận biết khi thiếu thông tin thay vì tự suy đoán, nhờ đó nhân viên có thể can thiệp khi thực sự cần đến chuyên môn của họ.

Kết quả là thời gian xử lý báo giá được rút ngắn, các tác vụ nhập dữ liệu thủ công giảm đi và nhân viên có thêm thời gian làm việc trực tiếp với khách hàng. Hellmann cũng ghi nhận tỷ lệ thắng báo giá tăng lên. Mục tiêu không phải là loại bỏ con người khỏi quy trình, mà là liên tục giảm khối lượng công việc thường lệ cần đến sự can thiệp của họ.

Qua cách tiếp cận này, anh nhận thấy những giới hạn nào? Đặc điểm nào của một quy trình làm việc cho thấy quy trình đó đã sẵn sàng sử dụng tác nhân thích ứng, và đặc điểm nào cho thấy doanh nghiệp nên thiết kế lại quy trình trước hoặc tiếp tục dùng hình thức tự động hóa thông thường?

Không phải quy trình nào cũng cần tác nhân AI. Cơ hội phù hợp nhất là những quy trình lặp đi lặp lại, có khối lượng lớn và đòi hỏi khả năng đánh giá theo ngữ cảnh, đặc biệt là khi thông tin nằm rải rác trên nhiều hệ thống và nhân viên thường xuyên phải xử lý các trường hợp ngoại lệ.

Bài học rõ ràng nhất từ các dự án triển khai của chúng tôi là một chức năng mới đang hình thành trong doanh nghiệp, tương tự như cách bộ phận vận hành doanh thu ra đời cùng với CRM, còn DevOps phát triển cùng với điện toán đám mây. Khi chuyển từ sử dụng một vài tác nhân sang cả một đội ngũ tác nhân, các công ty cần một cá nhân hoặc một nhóm quản lý chúng như trưởng bộ phận quản lý nhân sự: chịu trách nhiệm về các KPI và ROI, quyết định tác nhân nên đảm nhận công việc nào và không nên làm việc nào, đồng thời phê duyệt những thay đổi của chúng. Các công ty đã xây dựng chức năng này hiện đang tiến nhanh nhất và cũng là những công ty có vị thế tốt nhất để giành chiến thắng.

Những cách làm không thống nhất không phải là lý do để chờ đợi. Các chuyên gia bất đồng trong hầu hết mọi hoạt động, và hệ thống của chúng tôi được thiết kế để chỉ ra những mâu thuẫn đó rồi chuyển chúng thành đề xuất chính sách. Giải quyết các mâu thuẫn ấy là một phần công việc của người phụ trách, và đó cũng là một lý do nữa để thiết lập vai trò này trước khi mở rộng quy mô triển khai tác nhân.

Bản thân cách tiếp cận này cũng có giới hạn. Các hoạt động cốt lõi sẽ không được tự động hóa hoàn toàn, và đó cũng không phải mục tiêu của chúng tôi. Tác nhân mở rộng phạm vi xử lý từng bước, còn những trường hợp rủi ro cao được chủ ý giao cho con người xử lý.

Khi các mô hình nền tảng và công cụ xây dựng tác nhân ngày càng cải tiến, anh dự đoán những khâu nào trong quá trình triển khai tại doanh nghiệp sẽ trở thành hàng hóa phổ thông, và Reindeer đang xây dựng lợi thế nào ngày càng vững chắc sau mỗi lần triển khai vào vận hành thực tế?

Các mô hình nền tảng sẽ ngày càng có thể thay thế lẫn nhau khi trở nên rẻ hơn, nhanh hơn và mạnh hơn. Việc xây dựng các tác nhân cơ bản và kết nối chúng với hệ thống doanh nghiệp cũng đang trở nên dễ dàng hơn.

Nhưng xây dựng một tác nhân không đồng nghĩa với việc khiến nó hoạt động đáng tin cậy trong một doanh nghiệp phức tạp theo thời gian.

Lợi thế cạnh tranh thực sự nằm ở kiến thức độc quyền về cách doanh nghiệp vận hành trên thực tế—một mục tiêu luôn thay đổi. Mỗi trường hợp phát sinh trong quá trình vận hành thực tế đều tạo cơ hội để tác nhân của chúng tôi học hỏi, xử lý các trường hợp ngoại lệ trong tương lai và giảm sự can thiệp của con người.

Các mô hình sẽ rẻ hơn. Việc xây dựng tác nhân sẽ dễ dàng hơn.

Những bên chiến thắng sẽ loại bỏ được hạ tầng kỹ thuật tốn kém, vốn đòi hỏi con người phải duy trì hoạt động và tính phù hợp của các tác nhân theo thời gian.

Cảm ơn anh về cuộc phỏng vấn rất thú vị. Độc giả muốn tìm hiểu thêm về các tác nhân AI thích ứng dành cho doanh nghiệp, tự động hóa vận hành và khả năng học hỏi dưới sự hướng dẫn của con người có thể truy cập Reindeer.

Antoine là một nhà lãnh đạo có tầm nhìn và đối tác sáng lập của Unite.AI, được thôi thúc bởi niềm đam mê bền bỉ trong việc định hình và thúc đẩy tương lai của AI và công nghệ robot. Là doanh nhân đã thành lập nhiều công ty, ông tin rằng AI sẽ làm thay đổi xã hội sâu sắc như điện năng và thường hào hứng nói về tiềm năng của các công nghệ đột phá và trí tuệ nhân tạo tổng quát (AGI).

Với vai trò là một nhà tương lai học, ông dành tâm huyết khám phá cách những đổi mới này sẽ định hình thế giới. Ông cũng là người sáng lập Securities.io, một nền tảng tập trung đầu tư vào các công nghệ tiên tiến đang định nghĩa lại tương lai và tái định hình toàn bộ các ngành.