Hugo: Ben, chào mừng đến với DataFramed.
Ben: Cảm ơn Hugo, thật tuyệt khi có mặt ở đây và tôi rất mong được trò chuyện với bạn hôm nay về Convoy và khoa học dữ liệu.
Hugo: Tôi hoàn toàn đồng ý. Rất vui khi có bạn ở đây, và trong hành trình khám phá trên DataFramed về khoa học dữ liệu là gì và có thể trở thành gì, tôi thực sự hào hứng được nói chuyện với bạn hôm nay về công việc của bạn tại Convoy và vai trò mà khoa học dữ liệu có thể đóng trong việc cách mạng hóa ngành vận tải đường bộ, có lẽ là một trong những ngành có tác động lớn nhất ở Bắc Mỹ. Nhưng trước hết, tôi muốn nói về bạn.
Ben: Ừ, cảm ơn.
Nhà khoa học dữ liệu là gì?
Hugo: Mọi người luôn hỏi tôi, nhà khoa học dữ liệu thực sự làm gì? Ben, các đồng nghiệp của bạn nghĩ bạn làm gì?
Ben: Câu hỏi hay đấy. Tôi nghĩ thuật ngữ "nhà khoa học dữ liệu" thực sự rất mơ hồ. Nó có nghĩa khác nhau với mỗi người. Tôi đến với khoa học dữ liệu từ cả nền tảng khoa học tự nhiên và khoa học xã hội. Tôi cũng rẽ ngang qua Silicon Valley trước khi lấy bằng tiến sĩ kinh tế. Vì vậy, với tôi, tôi dành khoảng nửa ngày trong các cuộc họp bàn về khoa học vận hành nền tảng của chúng tôi như thế nào, hoặc cách chúng tôi phát triển phương pháp tiếp cận khoa học dữ liệu ở đây, hoặc các câu hỏi cụ thể như thiết kế thí nghiệm. Tôi dành khoảng nửa thời gian để cố vấn cho các nhà khoa học dữ liệu khác, như giúp một bạn junior thiết kế thí nghiệm cho một chiến dịch hoặc, ví dụ, xây dựng mô hình sống sót để hiểu giữ chân khách hàng.
Rồi tôi dành thêm nửa thời gian nữa làm cá nhân đóng góp, suy nghĩ về những khía cạnh thúc đẩy nền tảng của chúng tôi và cố gắng tạo tác động bằng cách sửa thứ đang “cháy”. Ví dụ nghĩ về những thứ như đấu giá, ghép cặp hay định giá và các vấn đề kiểu đó. Bất kỳ ai biết làm toán sẽ nhận ra là như vậy cộng ra thành ba nửa, nhưng tôi làm ở startup nên mọi thứ không cộng lại thành một đâu.
Hugo: Tôi hiểu quá. Ở DataCamp, đôi khi tôi còn cảm thấy mình đang vận hành như một tổng vô hạn ấy. Và vì nền tảng của bạn là vật lý, bạn từng nói với tôi là với các nhà vật lý chỉ có ba con số thôi, đúng không?
Ben: Đúng. Là 0, 1 và vô cực, còn lại chỉ là vấn đề tỉ lệ. Câu đùa cũ ấy mà.
Sự nghiệp khoa học dữ liệu của Ben
Hugo: Chính xác. Vậy bạn đã đến với khoa học dữ liệu như thế nào?
Ben: Câu hỏi hay đấy, và tôi nghĩ là tôi luôn làm việc với phần mềm, dữ liệu, toán, thống kê và mô hình. Sau khi DJ Patil đặt ra thuật ngữ này và nó lan truyền, ai đó ở bộ phận marketing tái định danh tôi thành nhà khoa học dữ liệu, nhưng ngay từ thời đại học tôi đã viết phần mềm để hiểu các câu hỏi khoa học rồi. Việc “đậm chất khoa học dữ liệu” đầu tiên tôi làm là viết một chương trình để hiểu sự thư giãn hố va chạm cho McKinnon, một nhà khoa học hành tinh tuyệt vời ở Đại học Washington, và hồi đó ban nhạc Frankie rất nổi, và vì chúng tôi làm về thư giãn hố va chạm nên tôi đặt tên chương trình của mình là Frankie. Gần đây hơn, sau khi làm tiến sĩ, tôi ở Đại học Chicago và được tuyển về Amazon. Khi đó khoảng năm 2012. Từ thời điểm ấy, tôi thực sự chuyển từ việc trong học thuật sang áp dụng vào công nghiệp.
Hugo: Vậy giờ bạn làm nhà khoa học dữ liệu ở Convoy?
Ben: Đúng vậy.
Convoy
Hugo: Hãy nói một chút về Convoy làm gì, sứ mệnh là gì?
Ben: Đây là một ví dụ điển hình cho việc phần mềm dễ xâm nhập vào một ngành đã thành hình hơn là một ngành đã thành hình tự đưa phần mềm vào. Ngành vận tải hàng hóa đã tồn tại từ lâu. Ở Mỹ, đây là một thị trường siêu lớn, cỡ 800 tỷ đô. Có một vấn đề là hầu hết các chủ hàng thì phân mảnh mạnh... xin lỗi, là các hãng vận tải. Hãng vận tải là các công ty xe tải, họ có một hoặc nhiều xe. Và các hãng vận tải rất phân mảnh, ở phân vị 95 thì hãng có chừng hai hoặc ba xe. Cách các chủ hàng kết nối với họ là qua các nhà môi giới, và các nhà môi giới vận hành bằng công nghệ từ thập niên 1980. Tức điện thoại và máy fax. Ở Convoy, chúng tôi đang tiên phong một cách tiếp cận mới gọi là vận tải kỹ thuật số, nơi chúng tôi dùng công nghệ, đặc biệt là khoa học dữ liệu, để làm cho toàn bộ quy trình tốt hơn cho mọi bên, vì việc ghép đúng hãng vận tải với đúng chuyến hàng của chủ hàng là cực kỳ quan trọng, khi đó mọi thứ vận hành trơn tru hơn. Vậy nên chúng tôi cần định giá, ghép cặp và tự động hóa toàn bộ quy trình, và điều đó sẽ cách mạng hóa cấu trúc chi phí của ngành. Với tất cả các bạn đang nghe, đồng thời là người tiêu dùng, hầu hết những thứ bạn mua phải trải qua tám hay mười chuyến xe tải để đến tay bạn. Nên nếu chúng tôi có thể giảm chi phí vận tải, giá cả hy vọng sẽ cạnh tranh hơn với những gì bạn mua.
Hugo: Vậy ở thực tế thì điều này trông thế nào cho... bạn nói các hãng vận tải là tài xế?
Ben: Hãng vận tải... Định nghĩa cũng hơi phức tạp vì nhiều người là chủ xe tự doanh, kiểu như “giấc mơ Mỹ”. Họ có thể là... Ví dụ ở Tây Bắc Thái Bình Dương, có thể là một người nhập cư Nga sang đây với hai bàn tay trắng rồi gây dựng thành chủ xe với một chiếc xe, rồi khi thành công hơn, họ có thể mở rộng đội xe, và đó là điều Convoy cố gắng giúp các chủ xe tự doanh làm. Hoặc có thể là một công ty vận tải vừa và lâu năm. Thường họ có một hoặc nhiều xe. Một cá nhân khó mà mở rộng quá khoảng 20 xe vì khi đó hậu cần trở nên phức tạp và bạn phải xử lý nhân sự, v.v.
Hugo: Chắc chắn rồi. Vậy Convoy ở thực tế trông như thế nào với các hãng vận tải? Họ dùng ứng dụng hay...
Ben: Ừ, câu hỏi hay. Cách chính họ tương tác với chúng tôi là qua ứng dụng Convoy, và chúng tôi có quy trình giới thiệu giúp họ rất dễ cung cấp bộ thông tin của mình. Như bảo hiểm và giấy phép, rồi chúng tôi kích hoạt tài khoản của họ. Khi đó họ sẽ thấy các đề nghị được phân phối dựa trên loại chuyến hàng họ nói là họ thích. Ví dụ họ có thể nói, "Này, tôi thích chạy trên hành lang I-5," rồi họ có thể nhận chuyến trong ứng dụng và không cần nói chuyện với ai. Rất hiệu quả.
Họ cũng có thể đấu giá cho chuyến hàng. Nếu họ không thích mức giá của chúng tôi, hoặc họ cạnh tranh với hãng khác cho một chuyến, họ có thể đặt giá, giá có thể tăng hoặc giảm theo điều kiện thị trường, và điều khác chúng tôi làm rất tốt cho họ là giả sử họ nhận một chuyến từ San Francisco đến Los Angeles, nếu chúng tôi thấy vậy thì nói, "Này, chúng tôi có một chuyến từ Los Angeles quay về nơi bạn vừa đến hoặc đi nơi khác." Chúng tôi ghi nhận điều đó để cố gắng giữ cho họ luôn chạy và kiếm tiền, để xe rỗng ít hơn, vì hóa ra xe tải chạy rỗng khoảng 40% thời gian, điều này vừa hại môi trường vừa bất lợi cho tài xế.
Hugo: Vâng, tôi hình dung có mọi kiểu biến thể của bài toán người chào hàng mà bạn đang cố giải, bạn không nhất thiết muốn một tài xế lái một chiếc xe rỗng từ Seattle xuống Bay Area chỉ để rồi chở hàng đi nơi khác. Bạn muốn tìm cách để... Chuyến đi của họ được tối ưu theo lượng hàng họ chở?
Ben: Đúng rồi. Khi chúng tôi có thêm thanh khoản trên nền tảng, việc giải các bài toán kiểu này ngày càng dễ, về cơ bản là giữ các hãng vận tải gần như luôn trong trạng thái di chuyển.
Hugo: Thật thú vị. Một lý do tôi thấy điều này cuốn hút là vì khi nghĩ về vai trò của khoa học dữ liệu trong công nghiệp hiện đại, chúng ta thường nghĩ tới công nghệ, một ngành sinh ra cùng làn sóng dữ liệu. Trong khi bạn đang nói về cách mạng hóa một ngành có trước tất cả hạ tầng công nghệ này.
Ben: Chính xác. Và nếu chúng tôi thành công với những gì đang làm, chúng tôi sẽ thay đổi cấu trúc chi phí cho một ngành lớn ảnh hưởng đến rất nhiều người Mỹ. Một sự thật đáng kinh ngạc tôi học được ở Convoy là công việc phổ biến nhất ở khoảng 45 bang là tài xế xe tải. Điều này ảnh hưởng đến rất nhiều người về việc làm, và cũng ảnh hưởng đến mọi người tiêu dùng. Nó có thể tạo ra tác động tích cực lớn đến cuộc sống của nhiều người, đặc biệt là với chính tài xế xe tải, chúng tôi giúp họ điều hành doanh nghiệp dễ hơn, phát triển doanh nghiệp đó và giảm rất, rất nhiều ma sát trong cách họ vận hành.
Khoa học dữ liệu tại Convoy
Hugo: Chắc chắn rồi. Vậy khoa học dữ liệu đóng vai trò then chốt như thế nào trong sứ mệnh của Convoy?
Ben: Khoa học dữ liệu là trung tâm những gì chúng tôi làm. Thực tế, từ ngày đầu mở cửa, chúng tôi đã tự động hóa. Vậy nên chúng tôi phải giải nhiều vấn đề hấp dẫn với rất nhiều kinh tế học, cực kỳ quan trọng là dự đoán giá vì chúng tôi cần định giá đúng cho chủ hàng. Thường chúng tôi ký hợp đồng dài hạn với họ và cũng phải định giá đúng cho các hãng vận tải. Rồi chúng tôi cần giải bài toán ghép cặp để ghép đúng hãng với đúng chuyến. Vì như thế kết quả tốt hơn cho mọi bên. Ví dụ, “đúng” có thể là ít quãng rỗng hơn, tức thời gian chạy không để đến điểm đầu chuyến, và cả điểm đến cũng quan trọng. Chúng tôi quan tâm đến đấu giá và toàn bộ cơ chế chấp nhận giá cho các hãng vận tải, cũng như nhiều điều khác liên quan vòng đời hãng vận tải, và đảm bảo mọi thứ diễn ra tốt đẹp sau khi hãng nhận chuyến. Có rất nhiều vấn đề như vậy.
Hugo: Nghe như một doanh nghiệp có thể gặp bài toán “con gà và quả trứng”, theo nghĩa là để thuyết phục chủ hàng tham gia, bạn cần có hãng vận tải, và để thuyết phục hãng vận tải bạn cần có chủ hàng.
Ben: Đúng, đó là điều khó cho bất kỳ nền tảng nào. Có một bài viết rất hay của Simon Rothman, một trong các nhà đầu tư vòng Series A của chúng tôi, ông ấy viết rằng về cơ bản bạn phải khởi động hai công ty cùng lúc. Tức là bạn phải bootstrap cả phía cung và cầu đồng thời, và điều này rất khó vì chúng tôi phải giữ cân bằng.
Vì may mắn, chúng tôi có đội ngũ bán hàng tuyệt vời, họ rất giỏi tạo ra nhu cầu chất lượng, rồi chúng tôi nhanh chóng xây dựng phía cung để giữ mọi thứ cân bằng, và đó là thứ chúng tôi theo dõi. Bất kỳ nền tảng nào cũng lo điều đó. Họ nghĩ rất nhiều về thanh khoản và duy trì cân bằng. Giống như bạn vào một trang hẹn hò, giả sử bạn là dị tính, nếu ở đó không có phụ nữ thì trải nghiệm hẹn hò tệ. Bạn cần số lượng nam và nữ cân bằng.
Hugo: Lý do điều này hiện lên trong đầu tôi là trước đây chúng tôi gặp thách thức tương tự ở DataCamp thời kỳ đầu, vừa thu hút học viên vừa mời giảng viên, vì giảng viên muốn có khán giả và học viên muốn giảng viên tốt nhất, đúng không?
Ben: Đúng vậy. Và còn có hiệu ứng mạng. Khi chạy rồi, những doanh nghiệp này có xu hướng tăng trưởng theo cấp số nhân, rất phấn khích. Nghĩa là nếu làm đúng, bạn sẽ thấy mình mất ngủ.
Hugo: Chắc chắn rồi. Bạn nói với tôi một trong những điều quan trọng là đội bán hàng thật mạnh, vậy đội khoa học dữ liệu được tích hợp vào công ty như thế nào, chẳng hạn với đội bán hàng?
Ben: Ừ. Một trong những điều lớn chúng tôi có thể làm là giúp họ hiểu về định giá, như cách đấu giá cho chuyến hàng, nên đấu giá chuyến nào, và đó là vài cách chúng tôi làm việc rất sát với họ. Định giá là một việc cực kỳ phức tạp, và có đủ kiểu động lực khuyến khích xung quanh. Nói ra thì phải mất hàng giờ.
Hugo: Chúng ta đã bàn, kiểu như xoay quanh vai trò của khoa học dữ liệu. Cụ thể thì những câu hỏi khoa học dữ liệu nào bạn cần trả lời trong công việc?
Ben: Một điều rất hay ở Convoy trong văn hóa của chúng tôi là rất hướng dữ liệu, nên chúng tôi làm vô số thí nghiệm như mọi người khác trong ngành, hoặc ít nhất là các bên hàng đầu. Vậy nên cách chúng tôi trả lời câu hỏi thường là thông qua thí nghiệm, và đó là cách duy nhất để giải. Chúng tôi làm rất nhiều A/B test. Chúng tôi đã đầu tư mạnh xây dựng một khung A/B test rất tốt cho phép chúng tôi lặp nhanh các thí nghiệm, có nhiều cách chạy A/B test như Bayesian hoặc frequentist, và Bayesian hay phân tích tuần tự sẽ cho bạn câu trả lời nhanh hơn nhiều. Chúng cũng giúp việc thảo luận kết quả với quản lý sản phẩm dễ hơn.
Kiểm thử A/B
Hugo: Lùi lại một chút, bạn có thể đưa ví dụ về một A/B test mà bạn thực hiện không?
Ben: Tuyệt. Kiểu thí nghiệm A/B thường là xem luồng UX mới có hoạt động tốt hơn không. Ví dụ... Một trong những điều chúng tôi quan tâm là khi tài xế hoàn thành chuyến đi thì họ tự động tải tài liệu của họ lên. Gọi là BOL, bill of lading. Nếu chúng tôi ra mắt một quy trình mới để cải thiện và làm nó dễ hơn, chúng tôi có thể chạy thí nghiệm, để một nửa hãng vận tải dùng công nghệ cũ, một nửa dùng công nghệ mới, rồi sau một thời gian chúng tôi có thể nói với một xác suất nào đó liệu quy trình mới có hiệu quả hơn không.
Hugo: Ví dụ tuyệt vời và cũng mô tả rất hay về A/B test. Tôi muốn hỏi thêm. Bạn nói phương pháp Bayesian hội tụ nhanh hơn hoặc cho kết quả nhanh hơn phương pháp frequentist. Tôi biết tôi đang hỏi khó, nhưng bạn có thể, cho những người không chuyên, mô tả ngắn gọn sự khác nhau giữa thống kê frequentist, thứ có lẽ nhiều người quen thuộc hơn, và phương pháp Bayesian mà bạn đang nói đến trong trường hợp này không?
Ben: Chắc chắn rồi. Cách tiếp cận đầu tiên thực sự với thống kê là phương pháp Bayesian, do Thomas Bayes phát triển, ông ấy thực ra là một mục sư. Ý tưởng của ông hoạt động rất giống trực giác của bạn: bạn bắt đầu với một bộ niềm tin tiên nghiệm về điều gì đó, như quy trình mới của tôi tốt hơn, giả sử nó sẽ đem lại 10% tăng trưởng. Rồi theo thời gian khi bạn quan sát dữ liệu, bạn cập nhật các niềm tin đó. Việc cập nhật Bayesian sẽ hội tụ về cái gọi là hậu nghiệm, tức là phân phối mà chúng ta kỳ vọng phần tăng sẽ có.
Góc nhìn frequentist... Trước khi nói tiếp, phương pháp Bayesian rất khó tính toán cho đến khoảng hai thập kỷ trước. Chúng ta chưa có tài nguyên tính toán. Kể từ đó đã có những cải tiến lớn, và việc tính các mô hình này dễ hơn nhiều. Trước đó bạn chỉ có thể giải các trường hợp đặc biệt. Nên những người như R.A. Fisher đã rất phê phán phương pháp Bayesian, và họ phát triển phương pháp frequentist vào đầu những năm 1900, nếu tôi nhớ đúng. Ở đó, ý tưởng là có một giá trị thật của tham số, và nếu tôi lấy mẫu đủ nhiều, khi có thêm dữ liệu, nó sẽ hội tụ về sự thật.
Vậy nên frequentist hay nói về giá trị P và khoảng tin cậy, và đó là kiểm định giả thuyết truyền thống bạn thường biết. Trong thế giới frequentist, bạn phải nói với quản lý marketing rằng, "Với điều kiện giả thuyết không đúng, xác suất tôi quan sát được một hiệu ứng lớn như đã thấy hoặc lớn hơn là 5,7%." Rồi bạn sẽ tranh luận vì quan điểm truyền thống về ý nghĩa thống kê là dùng mức ý nghĩa 5% để nói rằng kết quả có ý nghĩa. Trong trường hợp này, nếu bạn là người chuẩn mực thì sẽ không thể bác bỏ giả thuyết không, nhưng quản lý marketing có thể nói, "5,7% rất gần 5%, hay ta dùng mức ý nghĩa 10% đi." Và bạn rơi vào rắc rối. Trong khi với phương pháp Bayesian, bạn có thể nói với quản lý sản phẩm rằng, "Có 94,3% hay 98% khả năng biến thể A tốt hơn biến thể B," và đó là cuộc trò chuyện dễ hơn nhiều.
Hugo: Trong ví dụ bạn nói, biến thể A và B, hay tham số chúng ta xem xét sẽ là số người tải thành công toàn bộ giấy tờ của họ?
Ben: Đúng.
Hugo: Là hàm của UX bất kỳ trông thế nào.
Ben: Đúng. Tức là bất kỳ thứ gì bạn đang thử nghiệm. Như luồng công việc mới của tôi có tỷ lệ nhấp cao hơn hay tỷ lệ hoàn tất thanh toán cao hơn không? Nó có giảm churn không? Bất cứ điều gì bạn quan tâm. Vâng. Tôi nghĩ phương pháp Bayesian giúp việc trò chuyện với quản lý sản phẩm dễ hơn nhiều, ngoài ra... Trong các nghiên cứu mô phỏng của chúng tôi, chúng tôi thấy nó hội tụ nhanh hơn nhiều. Với doanh nghiệp của chúng tôi. Trải nghiệm của bạn có thể khác, và nếu bạn ở châu Âu thì “kilomet” của bạn có thể khác.
Hugo: Tôi nhớ Dave Robinson từng viết vài bài cho Stack Overflow về A/B testing theo Bayesian ở đó, và cho thấy với các thí nghiệm của họ thì không nhất thiết hội tụ nhanh hơn. Tôi cần kiểm tra lại, và chúng ta có thể đưa vào phần ghi chú.
Ben: Ừ. Cũng có một số bài blog rất hay của Evan Miller về chủ đề này.
Các kỹ thuật và phương pháp khác: Kinh tế lượng và máy học
Hugo: Bạn có nhắc đến thiết kế thí nghiệm. Đó là một tiếp cận rất thú vị, vì tôi nghĩ không nhiều người kỳ vọng thiết kế thí nghiệm và các phương pháp này lại đóng vai trò lớn như vậy trong việc tái tạo ngành vận tải đường bộ bằng khoa học dữ liệu. Các kỹ thuật và phương pháp nào khác các bạn quan tâm?
Ben: Ừ, trước khi tiếp tục tôi muốn... để kết lại A/B testing là, có rất nhiều “khôn ngoan truyền đời” về ngành vận tải. Công ty chúng tôi là nửa startup công nghệ và nửa cựu binh ngành vận tải, họ có nhiều kiến thức và trực giác trả giá bằng mồ hôi, nhưng không phải lúc nào cũng đúng hoặc chính xác. Bằng cách làm thí nghiệm, chúng tôi có thể cụ thể hóa mọi thứ hơn nhiều.
Hugo: Điều này có khía cạnh chính trị và xã hội nào không, theo nghĩa là rất nhiều người đã ở trong ngành lâu năm, có quyền lực nhất định và kiến thức khó nhọc tích lũy, và có quan điểm rằng startup công nghệ có thể đến và “gây xáo trộn” và cần có ứng xử xã hội phản ánh điều đó?
Ben: Ừ. Tôi chỉ có thể nói trong khuôn khổ văn hóa của Convoy, và chúng tôi có một văn hóa rất mang tính đội nhóm. Cảm giác như khi tôi chơi trong đội khúc côn cầu tốt, và tôi nghĩ cả hai phía đều trân trọng thứ họ mang đến. Bạn thậm chí có thể có hai cựu binh ngành không đồng ý về điều gì đó. Ở Convoy chúng tôi cố tránh các bất đồng không thể giải quyết bằng... để tôi nói lại. Nếu một bất đồng không thể giải quyết bằng tranh luận trí tuệ với lý thuyết hoặc dữ kiện, thì chúng tôi chạy thí nghiệm. Thay vì ngồi tranh cãi bế tắc.
Hugo: Vậy còn gì nữa? Những kỹ thuật và phương pháp nào khác các bạn muốn dùng?
Ben: Ừ, chúng tôi là một nhóm khoa học dữ liệu thực dụng, ứng dụng. Chúng tôi cố giải các bài toán kinh doanh cụ thể trong thời gian ngắn. Nên chúng tôi dùng các bộ công cụ tiêu chuẩn như bạn kỳ vọng. Về công nghệ, chúng tôi rất trung lập, mọi người dùng công cụ tốt nhất cho công việc, có thể là R hoặc Python, cả hai đều có điểm mạnh và yếu. Tôi nghĩ biết cả hai là tốt. Còn về phương pháp cụ thể, đôi khi máy học là tốt nhất, đặc biệt khi cần dự đoán điều gì đó, như dự đoán ai đó có tải BOL hay, ví dụ, là một hãng vận tải tốt không. Khi đó bạn có thể xây logistic regression hoặc một bộ phân loại tăng cường nào đó. Nhưng có lúc bạn cần hiểu nếu A gây ra B, có thể chúng tôi không chạy được thí nghiệm, khi đó quay về thế giới thống kê ứng dụng và làm một dạng phân tích hồi quy. Thành công đầu tiên của tôi ở Convoy là trước khi tôi vào, họ đã phát hành một tính năng mà không A/B test, và họ muốn biết liệu tính năng mới có giúp ích không, và tôi có thể dùng gói causal impact do Google phát triển với Bayesian structural time series để chỉ ra tính năng mới có tác động tích cực.
Hugo: Tuyệt vời. Và đó là trên dữ liệu đã thu thập?
Ben: Đúng. Chúng tôi có dữ liệu hiện có, và bạn phải đi kiểm tra để đảm bảo mọi thứ tốt nhất có thể giống như được gán ngẫu nhiên. Một trong những đặc trưng then chốt của thí nghiệm là bạn cần gán ngẫu nhiên vào điều trị, và bạn cũng cần thỏa các điều kiện khác như việc gán là cá nhân, xác suất và không bị nhiễu. Đây là các thuật ngữ kỹ thuật. Nếu bất kỳ điều nào thất bại, bạn quay lại thế giới dữ liệu quan sát, và bạn sẽ dùng các phương pháp thống kê ứng dụng hoặc kinh tế lượng để cố tạo ra thứ “tốt như” gán ngẫu nhiên để rồi có thể đưa ra phát biểu nhân quả về việc A có gây ra B hay không.
Hugo: Bạn nhắc lại giúp tôi kinh tế lượng là gì?
Ben: Ồ, kinh tế lượng là bộ công cụ thống kê mà các nhà kinh tế phát triển để xử lý các vấn đề kinh tế. Với thế giới kinh doanh, các công cụ đó siêu hữu ích vì hầu hết vấn đề của chúng ta mang tính kinh tế, và ví dụ kinh điển là xử lý thứ như chọn mẫu và các dạng nội sinh khác, nơi các kết quả được đồng xác định trong mô hình. Ví dụ kinh điển: nếu bạn cố hiểu liệu tăng quy mô lực lượng cảnh sát có giảm tội phạm không, bạn có thể coi tội phạm là hàm của số cảnh sát, nhưng số cảnh sát cũng là hàm của mức tội phạm. Đó là ví dụ của tính đồng thời. Chọn mẫu, khi bạn bắt đầu tìm, bạn sẽ thấy ở khắp nơi, ví dụ như tôi cố chạy thí nghiệm xem lớp học nhỏ có cải thiện đọc hiểu không, nhưng tất cả phụ huynh “sang chảnh” khăng khăng cho con vào lớp nhỏ, và giờ bọn trẻ ở lớp nhỏ thông minh hơn, và bạn có sai lệch chọn mẫu.
Hugo: Vậy kinh tế lượng đã tạo ra một loạt công cụ để xử lý các thách thức kiểu này?
Ben: Đúng. Đặc biệt, có một nhóm công cụ quen thuộc với các nhà kinh tế nhưng không quen với nhà khoa học dữ liệu ngoài kinh tế, đó là dữ liệu bảng (panel). Các công cụ này rất tốt để xử lý cái mà nhà kinh tế gọi là dị biệt cá thể. Nếu tôi nhìn vào hành vi của hãng vận tải hoặc chuyến hàng, chúng có những “tính khí” cá nhân mà tôi không quan sát được, và nếu tôi có thể quan sát một hãng theo thời gian, dữ liệu bảng cho tôi các phương pháp tuyệt vời để loại bỏ các hiệu ứng cá thể không quan sát được có thể làm nhiễu ước lượng của tôi.
Hugo: Rất thú vị. Có vẻ như, nếu tôi sai hãy sửa, bạn đang nói rằng có cả một loạt công cụ do các nhà kinh tế lượng phát triển có thể được tận dụng trong khoa học dữ liệu nhưng chưa được dùng nhiều trong thế giới khoa học dữ liệu?
Ben: Đúng. Tôi thích máy học và nó rất tuyệt, nhưng cũng có những vấn đề mà nó không giải được và tôi nghĩ mọi người quá chú trọng máy học đến mức bỏ qua các phương pháp kinh tế lượng vốn thường rất hữu ích và có thể giải các vấn đề mà máy học không giải được. Tôi nhớ từng nói chuyện với ai đó ở Uber trước khi tôi vào Convoy và anh ta nói họ gặp những vấn đề không thể giải bằng máy học mà chỉ có thể giải bằng cách xây một mô hình kinh tế lượng cấu trúc, rất phức tạp, thường mất khoảng một năm hoặc hơn để xây và vận hành tốt. Nhưng bạn cố mô hình hóa toàn bộ quá trình hành vi và hàm tiện ích, và khi xong bạn có một mô hình rất giàu và mạnh nơi bạn có thể dự đoán tốt các kết quả phản sự kiện.
Hugo: Hay quá. Và đó là ở Uber à?
Ben: Ừ. Thực ra là trong buổi phỏng vấn của tôi với họ, tôi phỏng vấn với họ trước khi đến Convoy.
Dữ liệu địa không gian, chất lượng và xe tự hành
Hugo: Nghe như là... Chúng ta đã bàn về máy học, kinh tế lượng, thiết kế thí nghiệm và phương pháp Bayesian cho A/B test. Có vẻ bạn có rất nhiều dữ liệu địa lý, dữ liệu địa không gian và chuỗi thời gian của dữ liệu địa không gian. Điều này có vai trò gì trong công việc của bạn không?
Ben: Có. Tôi nghĩ dữ liệu đó rất quan trọng và chúng tôi mới bắt đầu mở khóa những gì nó có thể làm, nhưng chúng tôi dùng nó trong ứng dụng theo nhiều cách để cải thiện trải nghiệm của hãng vận tải. Ví dụ, khi một hãng đến lấy hàng, chúng tôi có thể tự động check-in dựa trên dữ liệu địa không gian. Một số cơ sở xếp hàng rất kém, và nếu họ giữ xe đợi quá lâu họ phải trả cái gọi là phí detention. Chúng tôi có thể tự động chi trả detention khi hãng đủ điều kiện thay vì bắt họ làm một quy trình giấy tờ nặng nề, không khác mấy việc nộp đơn bảo hiểm ở Mỹ.
Hugo: Điều khiến tôi nghĩ đến khi bạn nói có tất cả dữ liệu mà có lẽ bạn chưa khám phá hết tiềm năng, là có thể có tiềm năng cho đủ loại nghiên cứu xã hội liên quan đến dữ liệu bạn thu được?
Ben: Ừ. Tôi nghĩ có rất nhiều câu hỏi thú vị chúng tôi có thể trả lời về ghép cặp, nền tảng và đấu giá mà tôi muốn đào sâu hơn. Chắc chắn có thể viết rất nhiều bài báo học thuật về chủ đề này.
Hugo: Những dự án khoa học dữ liệu nào cụ thể tại Convoy mà bạn tham gia khiến bạn thấy tác động lớn hoặc nói lên điều gì đó về xã hội?
Ben: Câu hỏi hay. Tôi ở Convoy hơn một năm và công ty hơn hai năm tuổi. Tôi chủ yếu tập trung vào định giá và thí nghiệm. Tôi nghĩ một trong những thí nghiệm thú vị nhất chúng tôi chạy là ngay sau khi tôi bắt đầu, chúng tôi chạy một thí nghiệm cho phép truy cập ưu tiên vào chuyến hàng cho các hãng chất lượng cao hơn, và chất lượng lại giảm. Mọi người sốc. Như, khoan, chúng ta cho người chất lượng cao truy cập sớm công việc mà chất lượng lại giảm? Chuyện gì vậy? Vô lý. Một quản lý tệ có thể nói, "Này nhà khoa học dữ liệu, cậu ngốc quá." May là chúng tôi có quản lý khoa học dữ liệu rất tốt ở đây, Ziad Ismail, người xây dựng văn hóa dữ liệu tuyệt vời. Anh ấy để chúng tôi đào sâu. Tôi bắt đầu nghĩ về văn liệu ghép cặp trong kinh tế học. Giả thuyết của tôi là vì chúng tôi đã thu hẹp tập hãng vận tải vào một tập nhỏ hơn, dù chất lượng cao hơn, chất lượng ghép cặp công việc lại giảm. Chúng tôi xác minh được điều đó rồi làm phân tích hồi quy để cho thấy chất lượng ghép cặp có tác động nhân quả đến chất lượng. Đó là một khám phá rất hào hứng vì tôi nghĩ nó cho thấy ghép cặp quan trọng thế nào trên nền tảng của chúng tôi.
Hugo: Tuyệt vời. Để tôi diễn giải, chỉ cho các nhân viên chất lượng cao truy cập sớm vào chuyến hàng khiến việc ghép họ với chủ hàng, tức chất lượng của thuật toán ghép, giảm theo một nghĩa nào đó và điều đó gây giảm chất lượng của các hãng?
Ben: Đúng. Chất lượng của việc thực hiện công việc giảm vì có một tập nhỏ hơn các hãng đủ điều kiện, và dù họ tốt hơn, việc có ít người hơn để có thể ghép với công việc lại lấn át việc họ chất lượng cao hơn.
Hugo: Tôi nghĩ có một loài kiến Brazil nào đó có 30%... tôi không nói đây là tương đồng trực tiếp, nhưng giả sử có 30% kiến trong mỗi đàn không làm gì. Nếu bạn loại bỏ 30% đó và quay lại một ngày sau, lại có 30% kiến khác không làm gì. Tôi không nói có chủ hàng hay hãng vận tải không làm gì, mà là có một lực ổn định nào đó ở đây. Thật thú vị là nó lại đi ngược, thứ trực giác tưởng như sẽ... bạn nghĩ sẽ tạo ra chất lượng tốt hơn lại tạo ra chất lượng tệ hơn.
Ben: Ừ. Đây là ví dụ tuyệt vời vì sao thí nghiệm lại quan trọng. Khi chúng tôi chạy thí nghiệm, chúng tôi có truyền thống hay là mọi người bỏ phiếu xem kết quả nào sẽ thắng. Như vậy cả công ty cùng tham gia thí nghiệm, và thường đội UX sẽ tặng bánh donut hoặc sticker ngầu cho người thắng. Chúng tôi có nhiều thí nghiệm như vậy nơi điều bạn kỳ vọng không xảy ra vì rất dễ yêu thích một tính năng mà bạn nghĩ tuyệt vời còn thực tế là ngày càng khó tìm ra thứ sẽ thúc đẩy nền tảng tiến lên.
Hugo: Ở một nghĩa nào đó, những thí nghiệm này giống như bạn đang vận hành một phòng thí nghiệm, đúng không?
Ben: Đúng, chúng tôi đang làm vậy. Tập trung vào các câu hỏi kinh doanh của chúng tôi.
Hugo: Nếu câu hỏi này đi quá sâu vào chiến lược công ty hay thông tin riêng tư thì cứ nói. Tôi chỉ tò mò là bạn đánh giá chất lượng của hãng vận tải hay chất lượng của một lần giao hàng như thế nào?
Ben: Có một vấn đề trên toàn ngành vận tải là khoảng 10% thời gian khi một hãng đã cam kết nhận chuyến thì họ không xuất hiện hoặc báo vào phút chót là họ không nhận nữa, và thường là cái cớ “xe tôi hỏng”. Xe tải không hỏng 10% thời gian. Nghĩa là ai đó đã trả họ một chuyến giá cao hơn. Có những hãng làm vậy thường xuyên, và có những hãng, tôi xem dữ liệu của họ đã chạy 100, 300 chuyến và hầu như không bao giờ bỏ chuyến. Vậy “bỏ chuyến” là một trong các thành phần chính chúng tôi dùng để đo chất lượng vì nó siêu tốn kém cho chúng tôi khi xảy ra, vì chúng tôi cam kết cung cấp trải nghiệm vận chuyển chất lượng cao cho chủ hàng, nên chúng tôi phải đi tìm xe khác nhận chuyến vào phút chót, rất tốn kém.
Hugo: Hợp lý. Có xem xét nào liên quan đến sự xuất hiện của xe tự hành hay xe tải tự hành trong toàn công ty không?
Ben: Ừ. Tôi nên nói còn có những điều khác chúng tôi nghĩ về chất lượng như—
Hugo: Ồ xin mời, đúng rồi.
Ben: Tỷ lệ đúng giờ của tài xế, chúng tôi cố gắng để họ dùng ứng dụng là rất quan trọng vì điều đó cho phép chúng tôi giảm chi phí tuân thủ và an toàn. Tất cả những thứ đó đều rất quan trọng, nhưng trong thí nghiệm cụ thể tôi nhắc đến, bỏ chuyến là điều chính tôi quan tâm. Chúng tôi thấy nếu có thể khiến các hãng bắt đầu dùng ứng dụng thì đủ thứ tốt đẹp xảy ra và có thể xảy ra. Vậy nên một điều nữa chúng tôi làm với tư cách nhà khoa học dữ liệu là rất “kinh tế học”, đó là nghĩ cách cấu trúc các khuyến khích trên nền tảng để có được hành vi chúng tôi muốn. Ví dụ là nếu một hãng dùng ứng dụng, họ được trả nhanh. Tức là chúng tôi trả cùng ngày còn chuẩn ngành là trả trong khoảng 30 ngày sau khi làm xong, nghĩa là họ thường bán khoản phải thu cho công ty bao thanh toán và mất thêm 3%. Vậy là chúng tôi thực chất cho họ tăng lương 3% nếu họ... khoảng 2-3% cho factoring. Chúng tôi cho họ tăng 2-3% nếu họ dùng ứng dụng.
Hugo: Vâng. Vừa là tăng lương, vừa giúp họ có tài sản thanh khoản hơn nữa đúng không?
Ben: Đúng. Tôi không biết bạn thế nào chứ tôi làm việc thì muốn được trả tiền, và nếu phải chờ 30 ngày thì chẳng dễ chịu. Tôi còn phải mua thực phẩm, trả tiền nhà và phụ tùng xe đạp.
Hugo: Còn về sự xuất hiện của xe tự hành và xe tải tự hành. Đó có phải là điều các bạn đang chủ động nghĩ tới ở Convoy không?
Ben: Có. Chúng tôi chắc chắn đang chủ động nghĩ về điều đó và tôi biết các nhà sáng lập đã dành nhiều thời gian thông qua mạng lưới của họ để kết nối chặt chẽ và nắm bắt vấn đề này. Cuối cùng, khi xe tải tự hành xuất hiện, có lẽ theo từng giai đoạn với các mức tự động hóa khác nhau, họ vẫn sẽ cần kết nối với hàng hóa, và chúng tôi có một nền tảng làm điều đó. Mục tiêu của chúng tôi là có thể tích hợp điều đó vào phía cung của nền tảng.
Tính đa diện trong khoa học dữ liệu
Hugo: Chúng ta nói rất nhiều về tác động của khoa học dữ liệu đối với vận tải, liên quan đến công việc bạn làm ở Convoy, và như chúng ta... đã tiếp cận khoa học dữ liệu từ nhiều hướng khác nhau. Rõ ràng có rất nhiều thứ góp phần vào lĩnh vực này, và riêng bạn, bạn có nền tảng... bạn là một nhà kinh tế tính toán, cựu vật lý gia, và trước đây là nhà nghiên cứu tại Amazon. Vậy câu hỏi là, tất cả các lĩnh vực và trải nghiệm này đóng vai trò như thế nào trong vai trò nhà khoa học dữ liệu của bạn?
Ben: Tôi nghĩ không bao giờ là thừa công cụ, và khi tôi là một nhà vật lý trẻ, tôi rất may mắn được làm việc với John Wheeler, và ông ấy từng nói, bên cạnh việc “nhập hồn” Niels Bohr, ông nói, "Đừng bao giờ trích dẫn điều gì cho đến khi bạn biết câu trả lời." Đây là một Wheelerism nổi tiếng, ý ông là bạn nên có cảm nhận đâu là câu trả lời đúng cho vấn đề khoa học của bạn. Có một ví dụ nổi tiếng với Feynman, Feynman đến và nghĩ mình đã chứng minh được điều gì đó và Wheeler nói anh sai rồi, Feynman rất khó chịu vì sao Wheeler làm được bài toán này, Feynman vừa làm xong và nghĩ là lần đầu tiên. Hóa ra Feynman tính sai. Kiến thức vật lý của Wheeler quá sâu nên ông biết chắc là sai, không hợp lý. Vậy nên nếu bạn chạy thí nghiệm đo lift của chiến dịch thư trực tiếp mà được 10%, có lẽ là sai. Bạn sẽ không kỳ vọng điều đó đúng. Tôi nghĩ vật lý rất hữu ích theo cách đó ở khoản tháo vát và bồi đắp toán, đặc biệt là đại số tuyến tính. Tôi nghĩ đại số tuyến tính cực kỳ quan trọng để thành công trong khoa học dữ liệu, có lẽ còn hơn giải tích. Kinh tế học cho tôi công cụ lý thuyết để suy nghĩ về vấn đề kinh doanh cũng như công cụ kinh tế lượng để đối chiếu lý thuyết với dữ liệu. Thời gian làm kỹ sư phần mềm cho tôi kỹ năng phần mềm để biến thống kê thành mã. Ở bất cứ nơi nào bạn làm việc, hy vọng bạn đang tích lũy kỹ năng mới và học hỏi. Tôi nghĩ điều đó cực kỳ quan trọng với nhà khoa học dữ liệu. Văn hóa ở Amazon cũng dạy một cách rất “người lớn” để nghĩ về vấn đề. Có ý thức cấp bách, tập trung vào tác động, rất giống như làm tiến sĩ nơi bạn học cách tự hỏi suốt ngày, thứ mình đang làm có giúp mình hoàn thành tiến sĩ không, nếu không thì bạn đang làm sai thứ.
Hugo: Tôi nhớ bạn có một bài nói rất hay ở Data Science Pop-Up Seattle, tên là Tính đúng đắn trong khoa học dữ liệu. Tôi thích vì bạn định hướng những kiểu sai lầm thường gặp và chúng ta có thể làm gì như một lĩnh vực để sửa chúng nhằm xây dựng một ngành được xác lập rõ ràng, mà hiện tại có lẽ là một tập hợp mơ hồ các kỹ thuật, khái niệm và ứng dụng. Vậy bạn có thể nói về những sai lầm lớn mà bạn thấy các nhà khoa học dữ liệu đang mắc ngày nay không?
Ben: Tôi rất vui vì bạn thích bài nói đó.
Hugo: Tôi thích lắm, và chúng tôi sẽ đưa vào phần ghi chú để mọi người nghe xong đều xem.
Ben: Tuyệt. Trước hết, hy vọng khán giả sẽ thích, và tôi nghĩ tính đúng đắn của mô hình khoa học là cực kỳ quan trọng, và nhiều người, đặc biệt khi mới bắt đầu, nghĩ rằng ồ mã chạy xong, cho ra một con số, chắc là đúng. Khoan đã. Bạn phải chắc đó là con số đúng. Có một khung nhận thức luận để nghĩ về điều này, xuất phát từ ngành hạt nhân, gọi là kiểm chứng, thẩm định và định lượng bất định (verification, validation and uncertainty quantification). Tôi mang ơn Robert Rosner, người hướng dẫn sau tiến sĩ của tôi và quan trọng hơn là cựu giám đốc Argonne, đã giới thiệu tôi với VV & UQ. Về cơ bản có ba phần. V đầu tiên là verification. Đó là đảm bảo mã của bạn triển khai đúng mô hình. Bất kể mô hình có đúng không. Nghĩa là bạn nên làm những thứ như unit test, cũng có thể tạo dữ liệu tổng hợp bằng phương pháp Monte Carlo với các tham số đã biết và đảm bảo bạn thu được kết quả kỳ vọng và làm những việc như vậy để đảm bảo mã đúng. Validation là đảm bảo mô hình của bạn có độ trung thực với thực tại, nên làm những thứ như chạy thí nghiệm sau đó để đảm bảo mô hình đại diện chính xác cho thực tế. Uncertainty quantification là nghĩ về giới hạn của mô hình. Bạn đã đưa ra giả định gì? Chúng có đúng không? Liệu có sóng thần ập đến quét sạch nhà máy điện hạt nhân của bạn không? Có lẽ bạn nên tính cho tình huống đó. Tôi nghĩ đó là vài điều cơ bản. Tôi thích hỏi các kỹ sư BI khi phỏng vấn họ, làm sao họ biết SQL của mình đúng, và họ thường nhìn tôi như đây là câu hỏi siêu kỳ quặc. Nhưng SQL là tối quan trọng, hoặc bất kỳ thứ gì bạn dùng để trích xuất dữ liệu, vì nếu bạn lắp ghép một tập dữ liệu rác, thì không có gì bạn làm sẽ tốt lên. Kể cả bạn dùng thống kê siêu xịn, bạn cũng không sửa được việc bạn lắp dữ liệu sai. Vậy nên quan trọng là rất phương pháp luận và kiểm tra khi bạn ghép dữ liệu để nó đúng, bạn nên nghĩ về kế hoạch join, thử trên các tập con dữ liệu và đảm bảo các thống kê tổng hợp có ý nghĩa và phân phối phù hợp. Kiểm tra những thứ hợp lý như bạn không nhận được 10% lift trong chiến dịch thư trực tiếp. Điều khác cũng rất quan trọng là mô hình đi vào triển khai, nghĩa là bạn có thể cần kiểm thử tích hợp, hoặc các kiểm thử khác để đảm bảo thứ trong production trung thực với thứ phát triển trong nghiên cứu.
Khoa học dữ liệu trong môi trường sản xuất
Hugo: Vậy ở nơi bạn từng làm hoặc ở Convoy bây giờ, nhà khoa học dữ liệu đứng ở đâu trong việc đưa thứ họ làm vào sản xuất?
Ben: Điều đó thay đổi nhiều theo tổ chức và nhóm, ở một số nơi nhà khoa học dữ liệu chỉ làm nghiên cứu thuần rồi ném qua tường và kỹ thuật sẽ làm phép màu. Cách đó có vấn đề, những thứ thường mất mát trong dịch chuyển. Nhiều kỹ sư không vui nếu bạn đưa họ mã R. Hy vọng họ vui với Python. Ở Convoy, chúng tôi cố gắng để nhà khoa học dữ liệu sở hữu mô hình của mình end-to-end, và chúng tôi có một nền tảng máy học cho phép triển khai mô hình. Chúng tôi chưa hoàn toàn ở đó, còn việc phải làm, nhưng tôi nghĩ như vậy tốt cho tất cả vì khi đó kỹ sư chỉ cần gọi vào dịch vụ dữ liệu để lấy kết quả họ cần. Cách chúng tôi tổ chức ở Convoy cũng rất thuận lợi cho khoa học dữ liệu tốt là chúng tôi được nhóm vào các nhóm sản phẩm cùng cộng tác chặt chẽ, nhưng một nhóm sản phẩm sẽ có một quản lý sản phẩm, một hoặc nhiều nhà khoa học dữ liệu và một nhóm kỹ sư. Điều tuyệt nữa là các quản lý sản phẩm của chúng tôi đều siêu kỹ thuật. Hầu hết có bằng thạc sĩ khoa học máy tính hoặc tương đương, MBA tốt, và họ đều viết được SQL. Có một quản lý sản phẩm ở đây, trong phỏng vấn tôi hỏi một câu SQL liên quan đến left outer join, và anh ấy giải trong khoảng 60 giây. Tôi nghĩ anh ấy chán ví dụ này rồi, nhưng đó là tầm cỡ PM ở đây. Họ kỹ thuật, hướng dữ liệu, viết được SQL, hiểu thống kê bậc đại học, và điều đó rất hữu ích vì họ trở thành những người ủng hộ làm khoa học dữ liệu đúng đắn, rồi chúng tôi có nhiều hoạt động xã hội bổ sung để đảm bảo các nhà khoa học dữ liệu tiếp tục kết nối và cộng tác theo chiều ngang. Ví dụ, chúng tôi tổ chức buổi brown bag về khoa học dữ liệu. Chúng tôi có các buổi kỹ thuật 1:1 nơi tôi gặp các nhà khoa học dữ liệu khác và đảm bảo họ đi đúng hướng và trả lời mọi câu hỏi kỹ thuật họ có để họ không bị chặn.
Hugo: Tôi cũng nghĩ một quản lý sản phẩm kỹ thuật, như bạn nói, có rất nhiều lợi ích nhưng một điểm lớn là họ thực sự có thể trò chuyện với bạn, đúng không?
Ben: Đúng. Họ rất đầu tư vào việc hướng dữ liệu. Họ biết nếu viết kế hoạch cho một tính năng mới, họ cần làm việc với nhà khoa học dữ liệu để có kế hoạch Stack Overflow hay kế hoạch nào đó để kiểm chứng và thẩm định ý tưởng. Họ đều là những người ủng hộ dùng dữ liệu, và tôi nghĩ chúng tôi đặt tiêu chuẩn rất cao cho PM, nhưng điều đó tối quan trọng ở một tổ chức như thế này nơi họ có thể tham gia cuộc trò chuyện về dữ liệu, vì thường họ là người thúc đẩy câu hỏi nghiên cứu. Một ví dụ về việc họ hướng dữ liệu thế nào là Ziad Ismail, giám đốc sản phẩm. Anh ấy viết SQL. Ý tôi là, anh này thức khuya viết SQL để hiểu doanh nghiệp và có kiến thức sâu về dữ liệu trong kho dữ liệu của chúng tôi như bất kỳ ai.
Hugo: Hay thật. Về phần bạn, tôi phải nói, bạn có một bộ công cụ rất ấn tượng về thống kê, kinh tế lượng và kỹ thuật khoa học dữ liệu. Tôi tò mò phương pháp hay kỹ thuật ưa thích của bạn trong khoa học dữ liệu là gì?
Ben: Ừ, câu hỏi hay, và nó giống như hỏi con chim ưa thích của bạn là gì hay máy ảnh nào. Thành ngữ người Anh chắc là “một sợi dây dài bao nhiêu?”
Hugo: Và không ai trả lời được.
Ben: Đúng không? Vậy nên tôi thường thích...
Hugo: Vâng, bạn quan tâm gì? Bạn thích gì?
Ben: ... dùng công cụ tốt nhất cho công việc. Tôi chắc chắn... Tôi xuất thân từ chương trình tiến sĩ rất mạnh về phương pháp dữ liệu bảng, như ở UCL nơi tôi học có những người như Richard Blundell và những người khác thúc đẩy lĩnh vực này. Vậy nên điểm mạnh của tôi là dùng phương pháp dữ liệu bảng. Nhưng tôi cũng thích nhiều công cụ ML cốt lõi. Nó thực sự phụ thuộc vào bài toán. Tôi muốn dùng công cụ tốt nhất. Thứ tôi thấy vui nhất không phải là dùng công cụ, mà là giải các bài toán thú vị. Cuối cùng tôi là một nhà khoa học ứng dụng. Tôi từng làm nhiều vấn đề từ vũ trụ học lượng tử đến tin sinh học đến vận tải đường bộ, và những thứ khác. Vậy nên có những bài toán thú vị là điều quan trọng và tìm đúng công cụ để giải là quan trọng. Bên cạnh công cụ là dữ liệu và phần mềm.
Tương lai của khoa học dữ liệu
Hugo: Chúng ta đã bàn rất nhiều về khoa học dữ liệu hiện đại. Tương lai của khoa học dữ liệu trông như thế nào với bạn?
Ben: Tôi nghĩ chúng ta đang ở thời điểm tuyệt vời. Nếu bạn có kỹ năng toán và thống kê, có quá nhiều dữ liệu đang bùng nổ ở khắp nơi. Tôi nghĩ chúng ta sẽ có thời gian rất vui và thú vị cho đến khi Elon Musk tìm ra cách cho tất cả chúng ta thất nghiệp.
Hugo: Từ giờ đến lúc đó sẽ thế nào?
Ben: Sẽ có lúc các công cụ tự động hóa đi nhiều mô hình đơn giản. Bạn bắt đầu thấy các công ty cố bán các mô hình churn hàng hóa và những thứ như vậy, mà tôi nghĩ có thể gây vấn đề vì cuối cùng dữ liệu của mỗi công ty là độc nhất và bạn nên tự xây mô hình churn của mình từ đầu, nhưng bạn có lẽ sẽ thấy nhiều mô hình hàng hóa hơn và nhiều công cụ tự động hóa các “trái thấp” của khoa học dữ liệu. Vậy nên để có sự nghiệp thành công và hạnh phúc, bạn muốn tiến lên cao hơn trong chuỗi giá trị, nơi có những thứ không thể bị thay thế bởi tự động hóa như tự động hóa feature engineering. Ví dụ, ở một công ty trước đây tôi làm là Context Relevant, họ đã tiến khá xa trong việc tự động hóa feature engineering cho một lớp vấn đề lớn.
Hugo: Những kỹ năng nào bạn gợi ý cho các nhà khoa học dữ liệu mới vào nghề và cả dày dạn phát triển để không bị tự động hóa “cướp” việc?
Ben: Điều đầu tiên là bạn không bao giờ biết quá nhiều toán. Tôi nghĩ đó là thứ rất đáng đầu tư, và bắt đầu từ sớm. Khi tôi dạy ở Galvanize, nơi họ chạy bootcamp khoa học dữ liệu, tôi có thể bù đắp thiếu lập trình cho ai đó trong tám tuần. Tôi không thể bù đắp thiếu toán trong tám hay mười hai tuần. Đó là nhiều năm học. Vậy nên bạn nên liên tục đầu tư vào toán. Tôi nghĩ sau đó bạn muốn làm chủ các thuật toán cốt lõi, rồi bạn cần tiếp tục đọc. Rất nhiều người ngừng đọc khi vào ngành, và đặc biệt với người cấp cao hơn, bạn muốn chọn chuyên sâu nào đó phù hợp sở thích. Vậy thí nghiệm là thứ tôi đặc biệt quan tâm, cũng như phương pháp Bayesian, và đây đều là những thứ tôi đào sâu hơn nhiều trong những năm gần đây. Tôi biết nhiều người đang lao vào deep learning, đó là một không gian rất cạnh tranh. Vậy tôi nghĩ còn nhiều lĩnh vực khác thú vị và quan trọng trong khoa học dữ liệu. Nếu bạn muốn vào deep learning, cứ vào. Nhưng tôi nghĩ có lợi ích khi hơi “nghịch dòng”.
Lời kêu gọi hành động
Hugo: Tôi cũng nghĩ vậy. Với tất cả những điều đã nói, bạn có lời kêu gọi cuối cùng nào cho cả các nhà khoa học dữ liệu mới vào nghề và đã thành danh không?
Ben: Điều chính tôi muốn nói với người muốn vào khoa học dữ liệu là hiểu rằng bạn đang chuẩn bị cho mình một cuộc đời học hỏi và đó là chạy marathon, không phải chạy nước rút. Giống như lấy bằng tiến sĩ. Bạn cần giữ nhịp. Đây là thứ có thể mất nhiều năm để hoàn thành. Vậy nên bạn cần tiếp tục đầu tư. Có lẽ bạn nên xem Netflix ít hơn vào buổi tối và dành nhiều thời gian hơn đọc sách, bài báo liên quan, viết mã, chơi với mô hình, và nếu bạn không có sự hào hứng với dữ liệu thì có lẽ có nơi khác khiến bạn hạnh phúc hơn.
Hugo: Vậy là cứ học, cứ đọc, cứ làm.
Ben: Đúng. Với tôi, và tôi nghĩ với nhiều người trong nghề, dữ liệu giống như một câu chuyện trinh thám của Agatha Christie, có một bí ẩn ở đó và tôi muốn mở khóa nó, giải nó và tìm ra liệu có phải Đại tá Mustard trong phòng khách với cây nến hay không.
Hugo: Tuyệt vời, Ben. Vậy là bạn đang sống cuộc đời khoa học dữ liệu như tiểu thuyết trinh thám.
Ben: Ừ. Đại khái vậy.
Hugo: Tuyệt quá. Tôi rất đồng cảm vì dữ liệu cứ “cho” mãi. Tôi có một đồng nghiệp luôn nói rằng bạn cần lắng nghe dữ liệu của mình. Nó sẽ lên tiếng miễn là bạn lắng nghe, đúng không?
Ben: Đúng. Tôi cũng thấy... Khi bạn nói trước đó về những sai lầm mọi người mắc phải, một sai lầm tôi thấy nhiều nhà khoa học mắc là họ nhảy vào mô hình hóa quá sớm mà không làm EDA. EDA là thuật ngữ nổi tiếng của Tukey cho phân tích dữ liệu khám phá. Rất đáng dành thời gian cho EDA, vì bạn sẽ phát hiện những điều bất ngờ. Khi tôi vào Convoy, tôi bắt đầu làm EDA trên dữ liệu và phát hiện một số vấn đề làm sạch dữ liệu và ngoại lai chưa được xử lý, và chúng tôi sửa chúng và cải thiện khoảng 10% mô hình định giá. Đó là hiệu năng “miễn phí”.
Hugo: Rất đáng suy ngẫm. Làm EDA, phân tích dữ liệu khám phá, vì rất dễ bị cám dỗ nhảy vào xây mô hình ngay và những thứ kiểu đó, nhưng tôi luôn khuyến khích mọi người cố gắng trực quan hóa dữ liệu theo 100 cách khác nhau và xem các thống kê tóm tắt trước khi làm bất cứ điều gì khác.
Ben: Đúng. Và tôi cố dạy học viên một cách tiếp cận rất phương pháp luận, tiêu chuẩn hóa, và đó là một trong những điều tôi nghĩ CRISP-DM rất hay, tức quy trình chuẩn công nghiệp cho khai phá dữ liệu, và có lẽ là quy trình làm việc tốt nhất tôi từng thấy cho một dự án khoa học dữ liệu, và rất tốt khi đi qua tất cả các bước để không bỏ sót gì. Bạn bắt đầu bằng việc hiểu vấn đề kinh doanh, rồi hiểu dữ liệu bạn có. Chuẩn bị dữ liệu. Mô hình hóa, đánh giá và triển khai. Và ở bất kỳ điểm nào, bạn có thể phát hiện một sai sót buộc phải quay lại xử lý ở bước trước. Bạn bắt đầu mô hình và nhận ra, ôi, tôi chưa làm feature engineering đúng, hoặc tôi cần thêm một đặc trưng để nắm bắt hành vi cốt lõi nơi mô hình đang thất bại. Rất tốt khi làm có hệ thống như vậy để bạn không lặp lại công sức hoặc bỏ sót bước, và cuối cùng liên quan đến tính đúng đắn, điều chúng ta cũng đã chạm tới, tôi muốn tìm cách kết hợp CRISP-DM và VV & UQ, và khi đó bạn ở trong một thiết lập rất mạnh, chuyên nghiệp và trưởng thành.
Hugo: Tuyệt vời. Điều đó thực sự nói lên một cấu trúc có hệ thống cho những gì khoa học dữ liệu tương lai có thể trông như hoặc tích hợp.
Ben: Đúng. Phần còn lại là mô hình hóa là phần vui và đi đến câu trả lời, nhưng những thứ trước đó cực kỳ quan trọng và chiếm khoảng 80% thời gian của bạn. Làm sạch dữ liệu, chuẩn bị. Rồi mô hình hóa thì khá nhanh và như kiểu lên “phê” rồi “bụp”, đâu mất tiêu? Tôi nghĩ chúng ta sẽ thấy nhiều công cụ hơn hy vọng sẽ làm nhanh giai đoạn tiền mô hình, vì đó là nơi bạn sẽ có được cải thiện năng suất lớn, nếu bạn có thể nhanh hơn ở giai đoạn đó. Vậy nên đó là nơi tốt để đầu tư. Bạn nên học những thứ như UNIX và dùng thật giỏi các công cụ dòng lệnh và công nghệ hay nền tảng khác sẽ giúp bạn chuẩn bị dữ liệu để mô hình nhanh hơn.
Hugo: Chính xác. Ben, thật là một niềm vui được mời bạn tham gia chương trình.
Ben: Cảm ơn Hugo. Thật vui khi có mặt ở đây và chúc bạn mọi điều tốt đẹp với chương trình.
Hugo: Cảm ơn bạn.
