Maggie: Câu chuyện về một em bé dịch thuật khởi nghiệp AI

Tóm tắt TL;DR

• Tôi gặp một người bạn cùng lớp ở một bãi đậu xe và nhờ một tờ 10 USD bị mất. Điều tôi không biết là bạn cùng lớp của tôi đã xây dựng một mô hình dịch tiếng khóc của trẻ em và đang tìm người đồng sáng lập. Nhờ có Phòng thí nghiệm liên doanh của Tiến sĩ Peter Scheurman , chúng tôi đã có thể gặp nhau với tư cách là đối tác kinh doanh, có một nơi làm việc và thành lập công ty của mình.
• Trong vài tuần, tôi đã xây dựng một máy chủ xung quanh mô hình này và một ứng dụng Android mà các bậc cha mẹ có thể sử dụng để dịch tiếng khóc của con mình. Nhưng độ trễ rất khủng khiếp — không ai muốn đợi máy chủ quay hoặc tải tệp âm thanh lên trong khi đang bế một đứa trẻ đang khóc.
• Vì vậy, chúng tôi quyết định đưa mô hình vào ứng dụng nhưng nó quá lớn nên không vừa. Điều này có nghĩa là thu nhỏ kích thước của nó thông qua lượng tử hóa mà không làm giảm đáng kể độ chính xác và tìm ra cách tạo ra đầu vào mà mô hình yêu cầu trên thiết bị mà không làm hỏng ứng dụng. Chúng tôi không thể làm được điều đó nếu không có Pete Warden , người đã cho chúng tôi những lời khuyên quý giá về TensorFlow, Android và khởi nghiệp.
• Nhưng bây giờ mô hình đã có trên thiết bị, nó nằm ngoài tầm với của chúng tôi. Làm thế nào để chúng ta đo lường hiệu suất của nó? Thành công trông như thế nào? Tôi đã xây dựng một lớp ghi nhật ký, giám sát và phản hồi của người dùng xung quanh mô hình để nắm bắt tất cả thông tin cần thiết nhằm đánh giá hiệu suất. Dữ liệu này tạo ra một bánh đà; mọi bản dịch đều tạo ra dữ liệu đào tạo được gắn nhãn mới — chúng tôi hiện đang phát triển tập dữ liệu của mình mà không tốn nhiều công sức.
• Khi ứng dụng đang hoạt động và được theo dõi, chúng tôi gặp phải tình huống khó xử: hiển thị một hoặc nhiều bản dịch? Bản năng mách bảo hãy đưa ra bản dịch chính xác nhất - xét cho cùng thì đó là bản dịch có nhiều khả năng đúng nhất. Nhưng nếu bản dịch chỉ có độ tin cậy 70% thì sao? Thế còn 60% hay 50% thì sao? Đây là một vấn đề tế nhị giúp chúng tôi biết mọi người thực sự sử dụng ứng dụng như thế nào và phát hiện ra một tính năng tuyệt vời.
• Hóa ra rất khó để tìm thấy điện thoại của bạn và mở ứng dụng trong khi con bạn đang khóc trong vòng tay bạn. Vì vậy, chúng tôi đã tạo ra một thiết bị giám sát trẻ em, Homer , sử dụng loa thông minh Google Home — các bản dịch miễn phí bằng tay.
• Tuy nhiên, loa thông minh không đủ để cứu chúng tôi. Chúng tôi hết tiền và hơi nước, hoàn cảnh sống đẩy chúng tôi về nhà, và chiếc máy phiên dịch của đứa con bé bỏng của chúng tôi đã bị đặt lên kệ.

Lời nói đầu

Tôi bắt đầu nghiên cứu tính năng AI cho công việc vì tôi nhìn thấy cơ hội để vượt qua một công cụ chuyên môn cũ kỹ, cồng kềnh và tất nhiên, mọi công ty khởi nghiệp đều cần phải là công ty khởi nghiệp về AI . Trong khi tạo mẫu cho tính năng này, tôi gặp phải một số vấn đề quen thuộc một cách kỳ lạ. Vì vậy, tôi xem qua nhật ký của mình và tìm thấy Maggie, cô bé phiên dịch mà tôi và một người bạn đã xây dựng trước đại dịch. Đã gần bảy năm trôi qua, và những vấn đề tương tự gây khó khăn cho việc triển khai sản xuất và thử nghiệm AI vẫn là một tai họa không thể giải quyết được, mặc dù công nghệ tiên tiến đã đạt được những tiến bộ đáng kể. Đây là phản ánh về các ghi chú, suy nghĩ và mã của tôi từ Maggie để chứng minh những vấn đề thường gặp trên con đường sản xuất AI. Tôi hy vọng bạn tìm thấy nó hữu ích.

Maggie là gì?

Maggie là tên của đứa con út của gia đình Simpsons trong bộ phim cùng tên. Maggie là một em bé chưa học nói. Chú của Maggie, Herb, chạm đáy sau một quyết định kinh doanh tồi tệ và chuyển đến sống với gia đình Simpsons. Anh ấy đã tạo ra một dịch giả trẻ em có thể hoạt động một cách kỳ diệu sau khi lấy cảm hứng từ cháu gái của mình và sự thất vọng của gia đình vì cô bé ít nói. Theo cách tương tự, ý tưởng xây dựng một dịch vụ dịch thuật dành cho trẻ em đến với bạn tôi, Chris từ mối quan hệ của anh ấy với em gái, người gặp khó khăn trong việc tiếp thu lời nói. Do đó, chúng tôi đặt tên ứng dụng của mình là Maggie.

Lúc đó Chris đang làm việc tại một phòng thí nghiệm dành cho trẻ em và anh ấy nhận ra rằng có những hạn chế về mặt sinh lý đối với phổ âm thanh mà trẻ em trong một độ tuổi nhất định có thể tạo ra. Từ hiểu biết sâu sắc này, anh ấy đã thu thập dữ liệu đào tạo và xây dựng mô hình phân loại tiếng khóc của trẻ sơ sinh — một thành tích ấn tượng vì anh ấy học chuyên ngành Vật lý và không có kinh nghiệm về CS.

Chúng tôi chia sẻ một lớp học - Học tập Dịch vụ Kỹ sư - nơi cả lớp làm việc về chứng chỉ LEED cho một trong các tòa nhà trong khuôn viên trường. Tôi nhớ đến anh ấy như một chàng trai vui vẻ, may mắn cưỡi ván dài vào lớp. Lần tương tác đầu tiên của chúng tôi là ở bên ngoài lớp học, trong bãi đậu xe tối tăm của một cửa hàng tạp hóa, nơi tôi thấy anh ấy đang chuẩn bị đi chiếc xe đạp địa hình của mình. Anh ấy đậu xe cạnh xe tôi và chúng tôi đã nói chuyện. Sau đó, tôi để ý thấy có tờ giấy nhàu nát bên cạnh anh ấy, tôi nhặt nó lên, nhận ra đó là tiền và nói với anh ấy rằng anh ấy đã đánh rơi tiền. Anh ấy nói đó không phải của anh ấy nhưng tôi bảo anh ấy hãy giữ nó. Chúng tôi không biết nó là bao nhiêu; bãi đậu xe quá tối. 1 đô la, 10 đô la hoặc 100 đô la. Tôi nói với anh ấy rằng tôi hy vọng nó là 100 đô la. Đó là 10 đô la. Nhưng lần tương tác đầu tiên đó đã tạo dựng đủ niềm tin giữa chúng tôi đến mức chỉ trong vài tuần, khi cả hai chúng tôi đều đang làm việc tại Venture Lab — vườn ươm khởi nghiệp tại UC Merced — anh ấy đã yêu cầu tôi xây dựng một ứng dụng để triển khai công cụ dịch thuật con của anh ấy. Nếu không có Venture Lab, chúng tôi sẽ không bao giờ nghĩ đến việc hợp tác. Tôi chắc chắn không đi khắp nơi nói với những người bạn cùng lớp ngẫu nhiên rằng tôi xây dựng ứng dụng Android, anh ấy cũng không đi khoe khoang về mô hình dịch thuật của con mình. Có một sức hút kỳ diệu đối với không gian thứ ba trực tiếp mà bạn không nên đánh giá thấp.

Tôi có một mô hình và nó hoạt động. Giờ thì sao?

Mặc dù đã xây dựng một mô hình hoạt động. Chris không thể tìm ra cách triển khai nó. Đó là đầu năm 2017 và không có nhiều khóa học hoặc hướng dẫn chứng minh điều này. Người cố vấn của anh tại TensorFlow đã đề xuất triển khai trên Android, nhưng việc học phát triển thiết bị di động là một cầu nối quá xa. Tôi biết Android và đã triển khai nhiều ứng dụng trên Play Store, nhưng ngay cả đối với tôi, đây cũng là một điều quá khó khăn. Vì vậy, tôi đã làm điều dễ dàng.

Tôi đặt mô hình trên máy chủ và thực hiện lệnh gọi API tới nó. Việc thực thi mô hình trong máy chủ Flask dễ dàng một cách đáng ngạc nhiên: nhập TensorFlow, tải mô hình từ đĩa cục bộ (tôi thậm chí còn không nghĩ đến việc triển khai mô hình theo cách mà nó sẽ dễ dàng tạo phiên bản cho đến sau này) và trỏ các yêu cầu tới Nó. Nhưng có một số vấn đề:

• Yêu cầu phải được chuyển đổi thành đầu vào mà mô hình mong đợi và chúng tôi không tạo gói dùng chung để thực hiện công việc này. Vì Chris đã đào tạo mô hình và tôi đã tạo máy chủ nên điều này trở thành nguồn gốc của lỗi.
• Yêu cầu đầu tiên luôn chậm; chúng tôi đang lưu trữ trên AppEngine và tôi đã để số lượng máy chủ không hoạt động ở mức 0 (mặc định) vì tôi chưa bao giờ làm việc với máy chủ yêu cầu thiết lập lâu như vậy. Tại sao phải chi tiền cho các máy chủ nhàn rỗi khi chỉ mất một giây để khởi động máy chủ mới? Việc tải và chạy mô hình mất nhiều thời gian, vì vậy chúng tôi phải để máy chủ của mình ở trạng thái rảnh 24/7. Bạn không biết khi nào em bé sẽ bắt đầu khóc, điều đó có nghĩa là chi phí tổ chức sẽ cao hơn.
• Sự khởi đầu chậm chạp này khiến việc kiểm tra tích hợp trở thành một vấn đề đau đầu, đến mức tôi phải quay lại kiểm tra thủ công. Chờ đợi vài phút để vượt qua bài kiểm tra thật không thể chịu nổi. Sẽ nhanh hơn khi khởi động máy chủ bằng tính năng tải lại nóng và kiểm tra thủ công trước mỗi lần xác nhận.
• Việc triển khai và kiểm soát phiên bản rất phức tạp. Ban đầu, tôi đã triển khai mô hình bằng kho lưu trữ vì tôi muốn có một số hình thức kiểm soát phiên bản, nhưng tôi nhanh chóng nhận ra rằng điều này đang làm mất đi tính dễ dàng triển khai. Mọi cập nhật mô hình đều yêu cầu triển khai máy chủ và khởi động lại toàn bộ cụm, việc này mất thời gian vì máy chủ phải tải mô hình mới.

Bất chấp những vấn đề này, nó đã hoạt động. Chia sẻ trình phân tích cú pháp đầu vào mô hình và mã biến áp đã giải quyết được vấn đề đầu tiên. Việc coi mô hình như một hộp đen và mô phỏng nó giúp việc xây dựng các thử nghiệm tích hợp xung quanh nó trở nên dễ dàng hơn. Những thử nghiệm này sẽ đảm bảo không có sai lệch ngoài dự kiến giữa máy chủ và mô hình — miễn là các bản mô phỏng chính xác. Hiện nay, có các giao diện mô hình có thể đảm bảo tính chính xác của mô hình trong quá trình phát triển. Việc triển khai và kiểm soát phiên bản cho các mô hình không phải là vấn đề đòi hỏi các giải pháp mới cho hầu hết các trường hợp sử dụng hiện nay.

Mặt khác, các vấn đề về độ trễ và tính khả dụng cuối cùng đã thúc đẩy chúng tôi triển khai mô hình trên ứng dụng ở biên. Điều này có lợi trong việc loại bỏ độ trễ mạng, sử dụng CPU nhanh hơn nhiều của điện thoại và giữ cho ứng dụng chạy ở chế độ nền, giúp giải quyết vấn đề về độ trễ khởi động và giảm chi phí lưu trữ của chúng tôi. Nhưng tất nhiên, có những vấn đề mới.

Đặt mô hình ở đâu?

Chúng tôi đã dành rất nhiều thời gian để tranh luận nên đặt mô hình ở đâu. Chúng tôi muốn tốc độ và sự chắc chắn của điện thoại nhưng lại khao khát sự bảo mật và dễ triển khai của máy chủ. Ban đầu, việc đưa mô hình lên máy chủ rất hấp dẫn:

• Thật dễ dàng để cập nhật và triển khai.
• Nó không giới hạn số lượng người dùng - vào thời điểm đó, chỉ một số phiên bản Android nhất định hỗ trợ thư viện suy luận TensorFlow, do đó, việc đưa mô hình lên điện thoại đồng nghĩa với việc sẽ có ít người dùng hơn.
• Nó cung cấp nhiều tùy chọn hơn — API của máy chủ có thể được sử dụng bởi loa thông minh, trang web và thiết bị giám sát trẻ em.
• Không phải lo lắng về việc ai đó đánh cắp mô hình.

Nhưng nhược điểm cứ chồng chất:

• Nó rất chậm; tải lên các bản ghi âm, sao chép chúng và sau đó chạy mô hình mất nhiều thời gian.
• Nguy cơ ngừng hoạt động khiến ứng dụng kém hấp dẫn hơn — người dùng của chúng tôi cần có sẵn 100%; Điều hấp dẫn nhất của ứng dụng này là nó ở đó dành cho bạn khi vợ/chồng, cha mẹ bạn, v.v., không có mặt - nó ở đó dành cho bạn khi bạn ở một mình với một đứa trẻ đang khóc khó hiểu.
• Nó đắt; Máy móc cần thiết để thực hiện tất cả công việc này rất đắt đối với một công ty khởi nghiệp cần sử dụng tín dụng Google Cloud để thanh toán mọi thứ.

Cuối cùng, chúng tôi quyết định đưa mô hình vào ứng dụng do hai điểm đầu tiên - ứng dụng không hấp dẫn nếu bạn phải đợi nó dịch hoặc nếu nó thỉnh thoảng bị lỗi. Một vài giây chờ đợi dường như là vô tận khi bạn bế một đứa trẻ sơ sinh đang khóc trên tay. Nhưng việc đưa kiểu máy lên điện thoại có vấn đề, như tôi sẽ mô tả trong phần tiếp theo.

Bài học tôi rút ra từ điều này là bạn nên tối ưu hóa để có trải nghiệm người dùng tốt nhất — ngay cả khi giải pháp đó không thể mở rộng, không mang lại cho bạn sự phát triển trong tương lai hoặc gây rủi ro cho IP của bạn. Các công ty sống và chết nhờ trải nghiệm người dùng, đặc biệt nếu họ là những công ty mới cần tạo dựng niềm tin và xây dựng thương hiệu.

Những câu chuyện từ rìa

Việc đưa mô hình lên điện thoại gặp rất nhiều khó khăn về mặt kỹ thuật. Một số trong số chúng hiện không tồn tại, nhưng hầu hết thì có. Chúng tôi đã ở đỉnh cao. TensorFlow cho Android vừa mới ra mắt - bản phát hành công khai vào tháng 2 năm 2017 và tôi đang xây dựng ứng dụng vào tháng 3. Nhưng với sự kiên trì và rất nhiều sự trợ giúp từ Pete Warden tại TensorFlow, chúng tôi đã làm cho mô hình hoạt động được trong ứng dụng.

Vấn đề đầu tiên là lấy mô hình trong gói APK. Vào thời điểm đó, Android có giới hạn APK là 50 MB và tính năng mở rộng cho phép ứng dụng có dung lượng lớn hơn bằng cách tải xuống các thành phần sau khi cài đặt. Tuy nhiên, tôi cho rằng tính năng mở rộng này không an toàn vì nó có nghĩa là hiển thị mô hình trên máy chủ. Vì vậy, chúng tôi quyết định lượng tử hóa ứng dụng — một kỹ thuật liên quan đến việc giảm độ chính xác của tất cả đầu vào và đầu ra của mỗi lớp.

Trong trường hợp của chúng tôi, chúng tôi đã chuyển đổi tất cả các số dấu phẩy động thành số nguyên, điều này làm giảm đáng kể kích thước của mô hình và làm cho mô hình nhanh hơn nhưng cũng làm giảm độ chính xác. Chris đã trải qua nhiều lần lặp lại mô hình với các sơ đồ lượng tử hóa khác nhau và cuối cùng đã giải quyết được lượng tử hóa số nguyên mặc dù độ chính xác đã giảm. Nó hữu ích miễn là mô hình hoạt động tốt hơn so với mô hình mới. Phần thưởng: nó đã giải quyết được vấn đề cập nhật - tải xuống hàng trăm MB dữ liệu cho mỗi bản cập nhật mẫu máy đòi hỏi khắt khe về kết nối internet có đồng hồ đo, nhưng một vài MB có thể quản lý được (điều này đối với tôi bây giờ có vẻ ngớ ngẩn vì ngày nay mọi người thường xuyên tải xuống hàng GB nội dung video trên điện thoại của họ ).

Sau đó là một chuỗi dài các vấn đề nhỏ. Vấn đề lớn nhất là các thư viện FFT được hỗ trợ bởi các phiên bản Java khác nhau đi kèm với Android đã không tạo ra cùng một biểu đồ phổ mà mô hình đã được đào tạo. Chúng tôi đã đào tạo mô hình bằng thư viện C++ FFT và nó tạo ra các biểu đồ phổ với màu sắc và kích thước khác nhau. Là những công cụ bí mật, cả hai phiên bản C++ và Java đều được viết không rõ ràng và khó sửa đổi. Một quyết định nhanh chóng khác: chúng tôi quyết định đào tạo lại mô hình bằng cách sử dụng biểu đồ phổ Java FFT. Điều này có nghĩa là chuyển đổi tất cả các tệp âm thanh thành ảnh phổ và sau đó chạy quá trình đào tạo, quá trình này mất nhiều ngày trên Macbook cũ của bạn tôi. Nhưng vấn đề đã được giải quyết và tôi có thể tập trung vào việc khác trong thời gian đó.

Nhưng ứng dụng cứ bị treo và bị treo. Hóa ra việc tải bản ghi vào bộ nhớ rồi tạo biểu đồ phổ trong bộ nhớ là một ý tưởng tồi. Ứng dụng này đã ngốn rất nhiều tài nguyên của điện thoại. Giải pháp là lưu vào đĩa và truyền phát. Lưu vào đĩa thật dễ dàng; phần phát trực tuyến rất khó vì một khi âm thanh rời khỏi bộ nhớ, bất cứ điều gì cũng có thể xảy ra với nó trên đĩa. Một chương trình khác có thể đọc và sửa đổi nó; nó có thể bị xóa, có thể không lưu được, v.v.… Những trường hợp đặc biệt này thường không tồn tại trên web - bạn có một kênh riêng biệt với người dùng của mình nhưng không có trên thiết bị. Đảm bảo có đủ không gian để thực hiện việc này ngay từ đầu và dọn dẹp sau ứng dụng là một thử thách không ngờ tới. Sau này tôi phát hiện ra rằng đó là một giả định sai lầm khi tin rằng nếu điện thoại có đủ bộ nhớ để cài đặt ứng dụng của bạn thì nó cũng có đủ bộ nhớ để chạy ứng dụng đó.

Cuối cùng, bản thân thiết bị này đã là một đối thủ— Điện thoại Android có nhiều loại CPU, dung lượng bộ nhớ và quan trọng nhất là micrô. Vấn đề về CPU và bộ nhớ có thể được giải quyết bằng cách đặt phiên bản Android được yêu cầu lên phiên bản mới nhất và hy vọng điều tốt nhất; trường hợp xấu nhất là ứng dụng chạy chậm - không có cách nào để trực tiếp đặt yêu cầu tài nguyên trong Android. Vấn đề thực sự là tính đến các đặc tính khác nhau của micrô - Android cho phép bạn yêu cầu micrô trên các thiết bị cài đặt ứng dụng của bạn chứ không phải loại micrô.

Tôi đã không cố gắng giải quyết vấn đề này. Tôi đã có nhiều điện thoại thử nghiệm vào thời điểm đó và nhận thấy những dự đoán tệ hơn trên điện thoại giá rẻ. Tôi quyết định rằng bây giờ không còn thời gian để tìm giải pháp nữa - chúng tôi đang cố gắng khởi động càng sớm càng tốt. Đôi khi, giải pháp tốt nhất cho một vấn đề là ghi lại nó và tiếp tục. Bây giờ tôi nhận ra vấn đề này đã chỉ cho chúng tôi hướng đi của sản phẩm cuối cùng - Homer, một chiếc loa thông minh.

Khi những khó khăn kỹ thuật đã được khắc phục (hoặc tránh được), chúng tôi chuyển sang vấn đề khó hơn về chất lượng dự đoán. Vì mô hình này tồn tại trên ứng dụng nên chúng tôi không biết được hiệu suất của nó. Nếu nó hoạt động kém, cách duy nhất chúng tôi có thể biết là thông qua nhận xét trên trang ứng dụng hoặc lượt gỡ cài đặt; đến lúc đó thì đã quá muộn. Do đó, việc xây dựng trình bao bọc nhật ký, giám sát, thu thập dữ liệu và phản hồi xung quanh mô hình là rất quan trọng.

Một hay Nhiều?

Mô hình đã lấy các ảnh phổ và một số thông tin khác để phân loại những âm thanh mà em bé phát ra - đói, khó chịu, đau đớn, buồn ngủ và đầy hơi, đây là những bản dịch. Nó trả về một danh sách tất cả các danh mục có thể có, trong đó mỗi danh mục có tỷ lệ phần trăm thể hiện mức độ tin cậy của mô hình đối với bản dịch cụ thể đó. Tất cả các tỷ lệ phần trăm cộng lại bằng 100 - nếu bản dịch chính xác nhất đạt 90%, thì năm loại còn lại sẽ có độ chính xác cộng lại lên tới 10%.

Câu hỏi mà chúng tôi phải đối mặt ngay từ đầu là liệu có nên hiển thị tất cả các bản dịch (được sắp xếp từ chính xác nhất đến ít nhất) hay chỉ một bản dịch. Tôi đã chọn chỉ hiển thị một bản dịch vì tôi không muốn khiến mọi người nhầm lẫn với nhiều bản dịch hơn và việc xây dựng bản dịch này đơn giản hơn (sự lười biếng là nền tảng của Agile). Tuy nhiên, chúng tôi gặp phải sự cố với nhóm người dùng đầu tiên.

Khi mô hình chắc chắn (trên 80%), đề xuất đã có hiệu quả—chúng tôi không nhận được khiếu nại nào từ phụ huynh. Nhưng không phải lúc nào nó cũng tự tin như vậy. Khi độ chính xác của bản dịch dưới 80% thì phụ huynh hay đoán mò cũng được. Điều này làm mất đi mục đích của ứng dụng; nó sẽ cung cấp những bản dịch chính xác hơn những nỗ lực hoảng loạn của một bậc cha mẹ mới để xoa dịu con mình. Và điều đó đã xảy ra, không có gì đáng ngạc nhiên khi bản dịch thứ 2 hoặc thứ 3 lại hoàn hảo. Chúng tôi phát hiện ra điều này thông qua các cuộc phỏng vấn trực tiếp - các cuộc phỏng vấn trực tiếp không thể mở rộng quy mô và tốn thời gian nhưng cực kỳ dày đặc thông tin; nếu bạn có thể làm một việc hàng ngày, hãy làm nó. Đứa bé sẽ khóc và ứng dụng sẽ hiển thị bản dịch sai với độ tin cậy thấp, nhưng chúng tôi sẽ thử các bản dịch khác (chúng tôi đã thấy chúng trong nhật ký) và chúng sẽ hoạt động.

Điều này trái ngược với tôi vì tôi coi ứng dụng này như một công cụ dịch thuật; chỉ nên có một cách để dịch một cái gì đó, phải không? Sai. Ứng dụng này là một công cụ khám phá dành cho những người mới làm cha mẹ và người chăm sóc để xác định xem họ nên thử điều gì trước tiên. Tôi có nên cố gắng ợ con tôi không? Anh ấy có đói không? Lần cuối cùng anh ấy ngủ trưa là khi nào? Mọi bậc cha mẹ đều phải trải qua danh sách kiểm tra này khi con họ bắt đầu khóc. Ứng dụng của chúng tôi đã đẩy nhanh quá trình khám phá này; đó là cách các bậc cha mẹ đã sử dụng nó và đó là phản hồi mà chúng tôi nhận được khi triển khai nhiều bản dịch. Đây không phải là tính năng nổi bật nhưng chắc chắn đã biến ứng dụng này từ một mánh lới quảng cáo thành một công cụ sử dụng hàng ngày, một người bạn đồng hành đáng tin cậy khi vợ/chồng đi vắng hoặc ông bà đang ngủ.

Được hỗ trợ bởi dữ liệu này, chúng tôi nhanh chóng quyết định hiển thị nhiều bản dịch hơn. Bí quyết là tìm ra có bao nhiêu. Việc hiển thị tất cả các bản dịch—tất cả năm danh mục—làm cho ứng dụng có vẻ như luôn lặp lại cùng một bản dịch. Bạn sẽ nghĩ gì nếu Google hiển thị cho bạn bốn nhà hàng giống nhau mỗi khi bạn tìm kiếm đồ ăn? Chúng tôi đã quyết định chọn ra ba bản dịch tốt nhất - phần này là phần nghệ thuật và phần là dữ liệu.

Mọi người thiên về số ba vì lý do nào đó. Dữ liệu cho thấy độ tin cậy của mô hình đối với các bản dịch khác giảm đáng kể sau bản dịch thứ ba. Nếu bản dịch đầu tiên có độ tin cậy là 70% thì bản dịch thứ hai sẽ có 20%, bản thứ ba là 9% và phần còn lại dưới 1%. Vì vậy, chúng tôi đã bỏ những bản dịch này. Có một khả năng nhỏ là những bản dịch bị loại bỏ này là chính xác, nhưng việc thêm chúng vào có nguy cơ khiến ứng dụng trông lặp đi lặp lại. Lựa chọn là cứ 100 người dùng thì có 1 người nhận được bản dịch sai hoặc tất cả người dùng sẽ thấy những bản dịch vô dụng và cho rằng ứng dụng đang đoán. Đó là một sự lựa chọn dễ dàng.

Tất nhiên, với nhận thức muộn màng, lẽ ra tôi nên thử nghiệm điều này bằng cách sử dụng một công cụ chia nhiều nhánh - phát hành năm phiên bản khác nhau của ứng dụng, một phiên bản cho mỗi lựa chọn, ví dụ: hiển thị một bản dịch, hiển thị hai, hiển thị ba, v.v. và từ từ di chuyển mọi người lên phiên bản ứng dụng có kết quả tốt nhất. Số liệu thành công chính sẽ là số lượng người đã nhấp vào dấu kiểm màu xanh lục (hài lòng với bản dịch). Nhưng ở giai đoạn đầu như vậy, tôi tin rằng chúng tôi đã đưa ra quyết định đúng đắn và quan trọng hơn là chúng tôi đã đưa ra quyết định đúng đắn. Chúng tôi có tư tưởng cởi mở, chúng tôi không coi bất kỳ quyết định nào là cụ thể (không có cái tôi ở đây), chúng tôi liên tục kiểm tra với người dùng của mình và chúng tôi lắng nghe họ, ngay cả khi điều đó cảm thấy không đúng.

Học tập trong công việc

Mỗi tương tác là một cơ hội để cải thiện và gây ấn tượng. Nỗi lo lắng của tôi ngay từ khi bắt đầu dự án kinh doanh này là người mẫu chỉ may mắn thôi, rằng sẽ có một ông bố hoặc bà mẹ đơn thân được thông báo rằng con họ đang khóc vì họ đầy hơi và họ ợ con mình đến chết. Khó có thể xảy ra, nhưng chúng tôi cảm thấy có trách nhiệm đối với sức khỏe của mỗi em bé người dùng. Vì vậy, chúng tôi đã trì hoãn việc ra mắt bằng cách thêm tính năng phản hồi vào ứng dụng.

Sau mỗi bản dịch, bạn sẽ được hỏi mức độ hữu ích của nó - một trang không thể bỏ qua. Sau đó, ứng dụng tải lên phản hồi của người dùng, đầu ra của mô hình, loại thiết bị và biểu đồ phổ. Ban đầu, tôi tải tệp âm thanh lên nhưng nhanh chóng nhận ra rằng micrô thu được rất nhiều tiếng ồn xung quanh. Vì quyền riêng tư của người dùng, chúng tôi chọn chỉ tải lên biểu đồ phổ. Điều tôi không biết lúc đó là bạn có thể đảo ngược biểu đồ phổ và tái tạo lại âm thanh, mặc dù với chất lượng kém hơn và gặp một số khó khăn. Đây là bánh đà của chúng tôi.

Tuy nhiên, tôi đang bỏ qua các cuộc tranh luận và nhiều bản thảo dẫn đến phiên bản cuối cùng này. Việc quyết định dữ liệu nào cần thu thập, cách đo lường thành công và cách xác định thành công là một việc khó, nhưng đó là một quá trình lặp đi lặp lại mà bạn có thể thực hiện theo từng bước nhỏ và cải thiện. Lời khuyên tốt nhất mà tôi nhận được là hãy xác định thành công trông như thế nào hoặc, nếu điều đó quá khó, thì thất bại trông như thế nào (đối với tôi, định nghĩa thất bại dễ hơn nhiều so với thành công - tôi không bao giờ biết mình muốn gì, nhưng tôi chắc chắn về điều đó. những gì tôi muốn tránh) và phải cụ thể. Từ câu trả lời đó, hãy rút ra các số liệu bạn có thể sử dụng để đánh giá nỗ lực của mình - nếu thất bại khiến người dùng mất đi trước khi con họ quá già để sử dụng ứng dụng, thì hãy đo thời gian tồn tại trung bình của ứng dụng trên điện thoại của người dùng. Nhưng hãy nhớ rằng những định nghĩa và số liệu này không cố định - chúng sẽ thay đổi. Bạn chỉ cần quyết định và bám sát chúng cho đến khi chúng ngừng hoạt động. Chúng sẽ ngừng hoạt động khi bạn ngừng học hỏi từ chúng hoặc ít nhất là khi việc học từ chúng trở nên khó khăn hơn. Đó là mục tiêu, để học hỏi và cải thiện, phần còn lại là chi tiết.

Trong thời đại AI/ML, tài sản kỹ thuật số có giá trị nhất của công ty là dữ liệu được giao phó chứ không phải mô hình. Việc phát triển dữ liệu này - tốt nhất là theo cách minh bạch và có đạo đức - là rất quan trọng để tiếp tục thành công. Do đó, mọi tương tác của người dùng phải được coi là thời điểm tạo ra giá trị bất kể tỷ lệ chuyển đổi như thế nào. Vì vậy, mọi tương tác đều phải khiến người dùng ấn tượng và muốn quay lại. Chúng tôi đã xây dựng một cái gì đó thật tuyệt vời và truyền cảm hứng; chúng tôi có một nhà thiết kế tuyệt vời, Teresa Ibarra , người đã lấy bản phác thảo thô của tôi và trau chuốt nó thành một ứng dụng nhẹ nhàng và thú vị khi sử dụng. Và mỗi bản dịch đều làm cho bản dịch tiếp theo tốt hơn.

Kết thúc

Thứ cuối cùng chúng tôi xây dựng là Homer. Sau khi thực hiện hàng chục cuộc phỏng vấn trực tiếp với người dùng ứng dụng và gọi điện cho nhiều người hơn nữa, chúng tôi nhận thấy rằng việc tìm kiếm điện thoại, mở khóa màn hình, tìm ứng dụng của chúng tôi, mở ứng dụng và nhấp vào dịch trong khi bế đứa con đang khóc của bạn thật khó khăn và bất tiện. Tại sao chúng ta phải mất quá lâu để nhận ra điều này? Chúng tôi là hai chàng trai độc thân, không có con ở độ tuổi đôi mươi - tôi không thể nhớ lần cuối cùng tôi bế một đứa bé là khi nào chứ đừng nói đến việc xoa dịu tiếng khóc của nó. Vì vậy, chúng tôi quyết định chế tạo một thiết bị giám sát trẻ em bằng loa thông minh. Tôi đã đặt mua một bộ sản phẩm từ Raspberry Pi và chế tạo một chiếc loa Google Home tùy chỉnh với một nút lớn màu xanh lam ở trên cùng.

Chris đã có tầm nhìn tuyệt vời về việc bán mô hình này cho các công ty thiết bị giám sát trẻ em, nhưng chúng tôi không thu hút được sự chú ý của các công ty này, vậy tại sao không chế tạo thiết bị giám sát trẻ em của riêng mình bằng loa thông minh? Sau khi xây dựng Google Home, tôi đã tạo một tập lệnh bash để chạy trình dịch khi khởi động. Người dịch đã sử dụng SDK của Google Home để dịch cụm từ kích hoạt 'Được rồi, Google, dịch'. Trình dịch là một tập lệnh Python đọc âm thanh từ micrô, biến nó thành biểu đồ phổ và sau đó gửi nó đến máy chủ để dịch. Tôi giữ mọi thứ nhanh nhẹn và nó đã hoạt động ! Cuối cùng chúng tôi đã có được ứng dụng tuyệt vời của mình, nhưng nó không cứu được công ty.

Chúng tôi đã hết tiền - số tiền thưởng mà chúng tôi đã giành được từ một cuộc thi. Cuộc sống nhanh chóng đè nặng lên cả hai chúng tôi. Chúng tôi tốt nghiệp đại học và cả hai đều về nhà - tôi nhận một công việc ở Bay Area, còn Chris rời đi để chăm sóc người mẹ ốm yếu của anh ấy ở Texas. Việc khởi động thất bại.

Khởi nghiệp thật khó khăn và đau lòng. Bạn không thể làm chúng bán thời gian. Mọi người có cổ phần cần phải làm việc toàn thời gian hoặc cần rời đi để nhường chỗ cho người khác. Hoặc bạn phải thu nhỏ tham vọng của mình, có thể từ bỏ chúng hoàn toàn. Hiện tại, có những vấn đề có thể được giải quyết một cách có lợi khi làm việc bán thời gian - nhưng liệu chúng có đáng giá không? Họ có kích thích bạn không?

Nếu tôi học được điều gì - ngoài việc gặp khó khăn khi triển khai các mô hình ML trên Android - thì đó là bạn thực sự cần quan tâm đến vấn đề mình đang giải quyết. Bạn cần có đủ can đảm để cam kết thực hiện nó toàn thời gian bất chấp rủi ro tài chính và chi phí cơ hội to lớn. Không đời nào tôi lại từ bỏ công việc kỹ thuật của mình để làm việc này. Tôi thích giúp đỡ những người mới làm cha mẹ và những người cha tuyệt vọng; học hỏi và xây dựng công nghệ này thật là thú vị, nhưng làm sao tôi có thể giải thích với bố lý do tại sao tôi lại chuyển về căn hộ chật chội ở Khu 8 sau khi tốt nghiệp? Làm sao tôi có thể từ chối mức lương sáu con số sau khi sống nhờ Phúc lợi quá lâu?

Còn vốn mạo hiểm thì sao? Tại sao bạn không thử quyên tiền? Thực tế là các VC chỉ nhấc máy nếu họ biết bạn, trường bạn đã học hoặc công ty bạn làm việc. Họ không quan tâm đến những gì bạn đã xây dựng - ngoại trừ việc nó mang lại lợi nhuận, sự đổi mới của bạn chỉ là một chi tiết nhỏ - các quỹ đầu tư mạo hiểm đầu tư vào người sáng lập và nhóm trước tiên, sau đó là sản phẩm. Nhưng hầu hết trong số họ không biết cách chọn những người sáng lập hoặc đội ngũ giỏi, vì vậy họ để các nhân viên tuyển sinh tại các trường ưu tú hoặc FAANG làm việc đó.