Maggie: Bebek Tercüman Yapay Zeka Girişiminin Efsanesi

TL;DR Özeti

• Bir sınıf arkadaşımla otoparkta tanıştım ve kaybolan 10 dolarlık banknot yüzünden birbirimize bağlandım. Bilmediğim şey ise sınıf arkadaşımın bebek ağlamalarını tercüme eden bir model yaptığı ve bir kurucu ortak aradığıydı. Dr. Peter Scheurman'ın Venture Lab'ı sayesinde iş ortakları olarak tanışabildik, çalışacak bir yerimiz oldu ve şirketimizi kurduk.
• Birkaç hafta içinde modelin etrafında bir sunucu ve ebeveynlerin bebeklerinin feryatlarını tercüme etmek için kullanabileceği bir Android uygulaması oluşturdum. Ancak gecikme korkunçtu; kimse ağlayan bir çocuğu kucağında tutarken sunucunun açılmasını veya ses dosyalarının yüklenmesini beklemek istemez.
• Bu yüzden modeli uygulamaya koymaya karar verdik, ancak sığamayacak kadar büyüktü. Bu, doğruluğu belirgin bir şekilde azaltmadan niceleme yoluyla boyutunun küçültülmesi ve uygulamayı çökertmeden cihazda gereken modelin girdilerinin nasıl oluşturulacağının bulunması anlamına geliyordu. Bize çok değerli TensorFlow, Android ve başlangıç tavsiyeleri veren Pete Warden olmasaydı bunu başaramazdık.
• Ancak artık model cihazda olduğundan ulaşamayacağımız bir yerdeydi. Performansını nasıl ölçeriz? Başarı neye benziyor? Performansı değerlendirmek için gereken tüm bilgileri elde etmek amacıyla modelin etrafında bir kayıt tutma, izleme ve kullanıcı geri bildirimi katmanı oluşturdum. Bu veriler bir volan yarattı; her çeviri yeni etiketli eğitim verileri oluşturdu; artık veri kümemizi minimum çabayla büyütüyorduk.
• Uygulama çalışıp izlenmeye başladıktan sonra bir ikilemle karşılaştık: Bir çeviri mi yoksa daha fazla çeviri mi gösterilsin? İçgüdü en doğru çeviriyi göstermenizi söylüyor; sonuçta doğru olma ihtimali en yüksek olan çeviri bu. Peki ya çeviri yalnızca %70 oranında güvenilirse? Peki ya yüzde 60 ya da yüzde 50? Bu, insanların uygulamayı gerçekte nasıl kullandıklarını ve harika bir özelliği keşfettiklerini görmemize yardımcı olan ince bir sorundu.
• Çocuğunuz kollarınızda ağlarken telefonunuzu bulup uygulamayı açmanın çok zor olduğu ortaya çıktı. Bu nedenle, Google Home akıllı hoparlörünü kullanarak, el değmeden çeviri yapabilen bir bebek telsizi Homer yaptık.
• Ancak akıllı hoparlör bizi kurtarmaya yetmedi. Paramız ve gücümüz bitti, yaşam koşulları bizi eve geri götürdü ve bebek tercümanımız rafa kaldırıldı.

Önsöz

İşe yönelik bir yapay zeka özelliği üzerinde çalışmaya başladım çünkü hantal, eski bir uzman aracı atlama fırsatını gördüm ve elbette her start-up'ın bir yapay zeka start-up'ı olması gerekiyor. Bu özelliğin prototipini oluştururken tuhaf bir şekilde tanıdık birkaç sorunla karşılaştım. Böylece günlüklerime baktım ve benim ve bir arkadaşımın pandemi öncesi oluşturduğumuz bebek tercümanı Maggie'yi buldum. Neredeyse yedi yıl geçti ve her ne kadar son teknoloji önemli bir ilerleme kaydetmiş olsa da, yapay zeka testlerini ve üretim dağıtımını sıkıntıya sokan aynı sorunlar hala hafifletilemeyen bir bela olmaya devam ediyor. Yapay zekayı üretme yolunda sık karşılaşılan sorunları göstermek için Maggie'den aldığım notlar, düşünceler ve kodlar üzerine bir düşünceyi burada bulabilirsiniz. Umarım faydalı bulursunuz.

Maggie nedir?

Maggie, Simpsonlar'ın aynı isimli dizideki en küçük çocuğunun adıdır. Maggie henüz konuşmayı öğrenmemiş bir bebek. Maggie'nin amcası Herb, kötü bir iş kararının ardından dibe vurur ve Simpsonlar'ın yanına taşınır. Yeğeninden ve ailenin onun konuşamamasından duyduğu hayal kırıklığından ilham alarak mucizevi bir şekilde çalışan bir bebek tercümanı yaratır. Benzer şekilde, bir bebek tercümanı oluşturma fikri, arkadaşım Chris'in aklına, konuşmayı güçlükle çeken kız kardeşiyle olan ilişkisinden geldi. Bu nedenle uygulamamıza Maggie adını verdik.

Chris o sırada bir bebek laboratuvarında çalışıyordu ve belirli bir yaş aralığındaki çocukların çıkarabileceği ses yelpazesinde fizyolojik sınırlamalar olduğunu fark etti. Bu içgörüden yola çıkarak eğitim verilerini topladı ve bebek ağlamaları için bir sınıflandırma modeli oluşturdu; bu etkileyici bir başarıydı çünkü kendisi hiçbir Bilgisayar Bilimleri deneyimi olmayan bir Fizik bölümü öğrencisiydi.

Tüm sınıfın kampüsteki binalardan biri için LEED sertifikası üzerinde çalıştığı bir sınıfı (Mühendislik Hizmeti Öğrenimi) paylaştık. Onu sınıfa kaykayla giren, mutlu ve şanslı bir adam olarak hatırlıyorum. İlk etkileşimimiz sınıfın dışında, bir bakkalın karanlık otoparkında onu arazi bisikletine binmek için hazırlanırken gördüm. Arabamın yanına park etmişti ve konuştuk. Sonra yanında buruşmuş bir kağıt fark ettim, aldım, para olduğunu fark ettim ve ona parasını düşürdüğünü söyledim. Onun olmadığını söyledi ama ben ona saklamasını söyledim. Ne kadar olduğunu bilmiyorduk; otopark çok karanlıktı. 1$, 10$ veya 100$. Ona 100 dolar olmasını umduğumu söyledim. 10 dolardı. Ancak bu ilk etkileşim aramızda yeterince güven oluşturdu ve birkaç hafta içinde ikimiz de UC Merced'in startup kuluçka merkezi Venture Lab'da çalışırken benden bebek tercümanını dağıtmak için bir uygulama geliştirmemi istedi. Venture Lab olmasaydı işbirliği yapmayı asla düşünmezdik. Kesinlikle rastgele sınıf arkadaşlarıma Android uygulamaları geliştirdiğimi söylemedim, o da bebek çeviri modeliyle övünmedi. Şahsen üçüncü alanların hafife almamanız gereken manyetik bir büyüsü var.

Bir modelim var ve işe yarıyor. Şimdi ne olacak?

Çalışan bir model oluşturmamıza rağmen. Chris onu nasıl konuşlandıracağını çözemedi. Bu 2017'nin başlarıydı ve bunu gösteren çok fazla kurs veya rehber yoktu. TensorFlow'daki akıl hocası Android üzerinde dağıtım yapılmasını önerdi ancak mobil geliştirmeyi öğrenmek çok uzak bir köprüydü. Android'i tanıyordum ve Play Store'da birden fazla uygulama kullanmıştım ancak bu benim için bile zorlayıcı bir durumdu. Yani ben kolay olanı yaptım.

Modeli bir sunucuya koydum ve ona API çağrıları yaptım. Modeli bir Flask sunucusunda yürütmek şaşırtıcı derecede kolaydı: TensorFlow'u içe aktarın, modeli yerel diskten yükleyin (modeli daha sonraya kadar sürümü kolay olacak şekilde dağıtmayı bile düşünmedim) ve istekleri BT. Ama bazı sorunlar vardı:

• İsteğin modelin beklediği girdiye dönüştürülmesi gerekiyordu ve biz bu işi yapmak için paylaşılan bir paket oluşturmadık. Chris modeli eğittiğinden ve ben de sunucuyu oluşturduğumdan beri, bu bir hata kaynağı haline geldi.
• İlk istek her zaman yavaştı; AppEngine'de barındırıyorduk ve boştaki sunucu sayısını sıfırda bırakmıştım (varsayılan), çünkü bu kadar uzun bir kurulum gerektiren bir sunucuyla hiç çalışmadım. Yeni sunucuların başlatılması yalnızca bir saniye sürerken neden boş sunuculara para harcayasınız ki? Modelin yüklenmesi ve çalıştırılması uzun zaman aldı, bu nedenle sunucularımızı 7/24 boşta tutmak zorunda kaldık. Bir bebeğin ne zaman ağlamaya başlayacağını bilemezsiniz, bu da daha yüksek bir konaklama faturası anlamına gelir.
• Bu yavaş başlangıç, entegrasyon testini büyük bir baş ağrısı haline getirdi ve ben de manuel testlere geri döndüm. Testlerin geçmesi için dakikalarca beklemek dayanılmazdı. Sunucuyu çalışırken yeniden yüklemeyle başlatmak ve her işlemden önce manuel olarak test etmek daha hızlıydı.
• Dağıtım ve sürüm kontrolü zordu. Başlangıçta, bir tür sürüm kontrolü istediğim için modeli repo ile dağıtmıştım, ancak bunun dağıtım kolaylığından ödün verdiğini hemen fark ettim. Her model güncellemesi, sunucunun dağıtılmasını ve tüm kümenin yeniden başlatılmasını gerektiriyordu; bu da sunucuların yeni modeli yüklemesi gerektiğinden zaman alıyordu.

Bu sorunlara rağmen işe yaradı. Model giriş ayrıştırıcısının ve transformatör kodunun paylaşılması ilk sorunu çözdü. Modeli bir kara kutu gibi ele almak ve onunla alay etmek, onun etrafında entegrasyon testleri oluşturmayı kolaylaştırdı. Bu testler, taklitler doğru olduğu sürece sunucu ile model arasında beklenmeyen hizalamaların olmamasını sağlayacaktır. Artık geliştirme sırasında sahte doğruluğu sağlayabilecek model arayüzleri var. Modeller için dağıtım ve sürüm kontrolü, günümüzde çoğu kullanım durumu için yeni çözümler gerektiren bir sorun değildir.

Öte yandan, gecikme ve kullanılabilirlik sorunları sonunda bizi modeli uçtaki uygulamaya dağıtmaya itti. Bunun, ağ gecikmesini ortadan kaldırma, telefonun çok daha hızlı CPU'sunu kullanma ve uygulamayı arka planda çalışır durumda tutma gibi faydaları oldu; bu da başlangıç gecikmesi sorunumuzu çözdü ve barındırma maliyetlerimizi düşürdü. Ama elbette yeni sorunlar da vardı.

Modeli nereye koyacağız?

Modeli nereye koyacağımızı tartışarak çok zaman harcadık. Telefonun hızını ve kesinliğini istiyorduk ama sunucunun güvenliğini ve kurulum kolaylığını da istiyorduk. Başlangıçta modeli sunucuya koymak ilgi çekiciydi:

• Güncellenmesi ve dağıtılması kolaydı.
• Kullanıcı sayısını sınırlamadı; o zamanlar TensorFlow çıkarım kitaplıklarını yalnızca Android'in belirli sürümleri destekliyordu, bu nedenle modeli telefona koymak daha az kullanıcı anlamına geliyordu.
• Daha fazla seçenek sunuyordu; sunucunun API'si akıllı hoparlörler, web siteleri ve bebek monitörleri tarafından kullanılabiliyordu.
• Kimsenin modeli çalması konusunda endişelenmenize gerek yoktu.

Ancak olumsuzluklar birikmeye devam etti:

• Yavaştı; Kayıtların yüklenmesi, yazıya geçirilmesi ve ardından modelin çalıştırılması uzun zaman aldı.
• Kesinti riski, uygulamayı daha az ilgi çekici hale getirdi; kullanıcılarımız %100 kullanılabilirliğe ihtiyaç duyuyordu; Uygulamanın en çekici yanı, eşiniz, ebeveynleriniz vb. yokken de yanınızda olmasıydı; anlaşılmaz ağlayan bir çocukla yalnız kaldığınızda da oradaydı.
• Pahalıydı; Tüm bu işleri yapmak için gereken makineler, her şeyi ödemek için Google Cloud kredilerini kullanması gereken bir startup için pahalıydı.

Sonunda, ilk iki nokta nedeniyle modeli uygulamaya koymaya karar verdik; çevrilmesini beklemek zorunda kalıyorsanız veya ara sıra kapanıyorsa uygulama ilgi çekici değildi. Kollarınızda ağlayan yeni doğmuş bir bebek varken, birkaç saniyelik gecikme sonsuzluk gibi gelir. Ancak bir sonraki bölümde anlatacağım gibi modeli telefona takmanın bazı sorunları vardı.

Bundan çıkardığım ders, çözüm ölçeklenebilir olmasa, size gelecekte büyüme sağlamasa veya fikri mülkiyetinizi riske atsa bile, en iyi kullanıcı deneyimi için optimizasyon yapmanız gerektiğidir. Şirketler, özellikle güven kazanması ve marka oluşturması gereken yeni şirketlerse, kullanıcı deneyimlerine göre yaşar ve ölürler.

Kenardan Masallar

Modeli telefona koymak çok sayıda teknik zorluğu beraberinde getirdi. Bazıları şu anda yok ama çoğu var. Biz en son noktadaydık. Android için TensorFlow henüz yeni çıkmıştı; genel sürüm Şubat 2017'deydi ve ben uygulamayı Mart ayında geliştiriyordum. Ancak TensorFlow'dan Pete Warden'ın azmi ve bol miktarda yardımıyla modelin uygulamada çalışmasını sağlamayı başardık.

İlk sorun, modeli APK paketine almaktı. O zamanlar Android'in 50 MB'lık bir APK sınırı ve kurulumdan sonra bileşenleri indirerek uygulamaların daha büyük olmasına olanak tanıyan bir uzantı özelliği vardı. Ancak, modelin bir sunucuda gösterilmesi anlamına geldiğinden uzantı özelliğinin güvensiz olduğunu düşündüm. Bu nedenle, her katmanın tüm girdi ve çıktılarının doğruluğunu azaltmayı içeren bir teknik olan uygulamayı niceleştirmeye karar verdik.

Bizim durumumuzda, tüm kayan nokta sayılarını tam sayılara dönüştürdük, bu da modelin boyutunu önemli ölçüde azalttı ve daha hızlı hale getirdi, ancak aynı zamanda doğruluğu da azalttı. Chris, farklı niceleme şemalarıyla modelin birkaç yinelemesinden geçti ve sonunda doğruluktaki azalmaya rağmen tamsayı nicelemede karar kıldı. Model yeni ebeveynlerden daha iyi performans gösterdiği sürece faydalıydı. Bonus: Güncelleme sorununu çözdü; her model güncellemesi için yüzlerce MB veri indirmek, tarifeli internet bağlantılarında zorlu bir istekti, ancak birkaç MB yönetilebilirdi (bugünlerde insanlar düzenli olarak telefonlarına GB'larca video içeriği indirdikleri için bu bana çok saçma geliyor) ).

Daha sonra küçük sorunların uzun bir kuyruğu geldi. Bunlardan en büyüğü, Android ile birlikte gelen farklı Java sürümleri tarafından desteklenen FFT kitaplıklarının, modelin üzerinde eğitildiği aynı spektrogramı üretmemesiydi. Modeli bir C++ FFT kütüphanesi kullanarak eğittik ve farklı renk ve boyutlarda spektrogramlar üretti. Gizli araçlar olduğundan hem C++ hem de Java sürümleri şeffaf olmayan bir şekilde yazılmıştı ve değiştirilmeleri zordu. Başka bir hızlı karar: Java FFT spektrogramlarını kullanarak modeli yeniden eğitmeye karar verdik. Bu, tüm ses dosyalarını spektrogramlara dönüştürmek ve ardından arkadaşımın eski Macbook'unda günler süren eğitim sürecini yürütmek anlamına geliyordu. Ancak sorun çözüldü ve bu süre zarfında başka bir şeye odaklanabildim.

Ancak uygulama donmaya ve çökmeye devam etti. Kaydı belleğe yüklemenin ve ardından spektrogramı bellekte oluşturmanın kötü bir fikir olduğu ortaya çıktı. Uygulama telefonun kaynaklarının çoğunu tüketiyordu. Çözüm diske kaydetmek ve akış yapmaktı. Diske kaydetmek kolaydı; akış kısmı zordu çünkü ses hafızadan çıktığında diskte başına her şey gelebilirdi. Başka bir program onu okuyabilir ve değiştirebilir; silinebilir, kaydedilemeyebilir vb.… Bu uç durumlar genellikle web'de mevcut değildir; kullanıcınızla izole bir kanalınız vardır ancak cihazlarda yoktur. İlk etapta bunu yapmak için yeterli alan olduğundan emin olmak ve uygulamadan sonra temizlik yapmak beklenmedik bir zorluktu. Daha sonra öğrendiğime göre, telefonun uygulamanızı yüklemek için yeterli hafızası varsa, onu çalıştırmak için de yeterli hafızası olduğuna inanmanın yanlış bir varsayım olduğunu öğrendim.

Son olarak, cihazın kendisi de bir rakipti; Android telefonlar çok çeşitli CPU'lar, bellek miktarları ve en önemlisi mikrofonlarla birlikte gelir. CPU ve bellek sorunu, gerekli Android sürümünün en son sürüme ayarlanması ve en iyisinin beklenmesiyle çözülebilir; en kötü senaryo yavaş bir uygulamaydı; kaynak gereksinimlerini doğrudan Android'de ayarlamanın bir yolu yok. Asıl sorun, mikrofonlardaki çeşitli niteliklerin hesaba katılmasıydı; Android, uygulamanızın yüklü olduğu cihazlarda mikrofonlara ihtiyaç duymanıza izin veriyor ancak mikrofon türüne izin vermiyor.

Bu sorunu çözmeye çalışmadım. O zamanlar çok sayıda test telefonum vardı ve ucuz telefonlarla ilgili tahminlerin ne kadar kötü olduğunu fark ettim. Artık bir çözüm bulmak için zaman olmadığına karar verdim; mümkün olan en kısa sürede faaliyete geçmeye çalışıyorduk. Bazen bir sorunun en iyi çözümü, onu not edip devam etmektir. Şimdi bu sorunun bizi nihai ürüne, akıllı bir konuşmacı olan Homer'a yönlendirdiğinin farkındayım.

Teknik zorlukların üstesinden gelindiğinde (veya kaçınıldığında), daha zor olan tahmin kalitesi sorununa geçtik. Model uygulamada yaşadığı için performansı konusunda kördük. Kötü performans gösterip göstermediğini ancak uygulama sayfasındaki yorumlar veya kaldırma işlemleri aracılığıyla anlayabiliriz; o zamana kadar artık çok geç. Bu nedenle, model etrafında bir günlük sarmalayıcı, izleme, veri toplama ve geri bildirim oluşturmak kritik önem taşıyordu.

Bir mi yoksa Birçok mu?

Model, bebeğin çıkardığı sesleri (aç, rahatsız, acı içinde, uykulu ve gazlı) kategorize etmek için spektrogramları ve diğer birkaç bilgiyi aldı; bunlar çevirilerdi. Tüm olası kategorilerin bir listesini döndürdü; her kategori, modelin söz konusu çeviriye ne kadar güvendiğini temsil eden bir yüzdeye sahipti. Tüm yüzdelerin toplamı 100'e ulaşıyor; eğer en doğru çeviri %90 oranında açsa, diğer beş kategorinin toplamı %10'a varan doğruluklara sahip olacaktır.

Başlangıçta karşılaştığımız soru, tüm çevirilerin mi (en doğrudan en aza doğru sıralanmış şekilde) yoksa yalnızca bir çevirinin mi görüntüleneceğiydi. Daha fazla çeviriyle insanların kafasını karıştırmak istemediğim için yalnızca bir tanesini göstermeyi seçtim ve bunu oluşturmak daha kolaydı (tembellik Agile'ın temel taşıdır). Ancak ilk kullanıcı grubumuzda sorunlarla karşılaştık.

Model kesin olduğunda (%80'in üzerinde) öneri işe yaradı; ebeveynlerden şikayet almadık. Ama her zaman bu kadar kendinden emin değildi. Çeviri doğruluğu %80'in altında olduğunda ebeveyn veya tahmin kadar iyiydi. Bu, uygulamanın amacına aykırıdır; yeni bir ebeveynin çocuklarını sakinleştirmeye yönelik panikli girişimlerinden daha doğru çeviriler sunmalıdır. Ve öyle de oldu, 2. veya 3. çevirilerin isabetli olması şaşırtıcı değil. Bunu yüz yüze görüşmeler aracılığıyla öğrendik; yüz yüze görüşmeler ölçeklenemez ve zaman alıcıdır ancak son derece yoğun bilgi içerir; Her gün bir tane yapabiliyorsanız yapın. Bebek ağlıyordu ve uygulama düşük güvenilirlikle yanlış çeviriyi gösteriyordu, ancak diğer çevirileri denerdik (onları günlüklerde gördük) ve işe yararlardı.

Bu bana mantıksız geldi çünkü uygulamayı bir çevirmen olarak düşünüyordum; Bir şeyi tercüme etmenin tek bir yolu olmalı, değil mi? Yanlış. Uygulama, yeni ebeveynler ve bakıcıların ilk önce neyi denemeleri gerektiğine karar vermeleri için bir keşif aracıydı. Bebeğimin gazını çıkarmaya çalışmalı mıyım? Aç mı? En son ne zaman kestirdi? Her ebeveyn, bebeği ağlamaya başladığında bu kontrol listesini gözden geçirir. Uygulamamız bu keşfi hızlandırdı; ebeveynler bunu bu şekilde kullandı ve birden fazla çeviriyi kullanıma sunduğumuzda aldığımız geri bildirimler de bu oldu. Bu harika özellik değildi, ancak uygulamayı kesinlikle bir hileden günlük kullanım aracına, eş gittiğinde veya büyükanne ve büyükbabalar uyurken güvenilir bir arkadaşa dönüştürdü.

Bu verilere dayanarak hızla daha fazla çeviri görüntülemeye karar verdik. İşin püf noktası kaç tane olduğunu bulmaktı. Tüm çevirilerin (beş kategorinin tümü) görüntülenmesi, uygulamanın her seferinde aynı çevirileri tekrarlıyormuş gibi görünmesini sağladı. Her yemek aradığınızda Google size aynı dört restoranı gösterseydi ne düşünürdünüz? İlk üç çeviriye karar verdik; bu bölüm görseli ve bölüm verileri.

İnsanlar bazı nedenlerden dolayı üç numaraya eğilimlidirler. Veriler, modelin diğer çevirilere olan güveninin üçüncü çeviriden sonra önemli ölçüde düştüğünü gösterdi. İlk çevirinin güveni %70 olsaydı, 2. çevirinin güveni %20, üçüncünün güveni %9 ve geri kalanların güveni de %1'in altında olurdu. Bu yüzden bu çevirileri bıraktık. Çıkarılan bu çevirilerin doğru olma ihtimali küçüktü, ancak bunları dahil etmek uygulamanın tekrarlı görünmesine neden olma riski taşıyordu. Seçim, 100 kullanıcıdan 1'inin tamamen yanlış olan çeviriler alması veya tüm kullanıcıların gereksiz çeviriler görmesi ve uygulamanın tahmin ettiğini düşünmesiydi. Kolay bir seçimdi.

Elbette, geriye dönüp baktığımda, bunu çok kollu bir haydut kullanarak test etmeliydim - uygulamanın beş farklı sürümünü yayınlayın, her seçim için bir tane, örneğin bir çeviri göster, iki göster, üç göster vb. ve insanları yavaşça taşıyın. uygulamanın en iyi sonuçları veren sürümüne. Birincil başarı ölçütü, kaç kişinin yeşil onay işaretine (çeviriden memnun) tıkladığı olacaktır. Ancak bu kadar erken bir aşamada doğru kararı verdiğimize ve daha da önemlisi kararı doğru şekilde verdiğimize inanıyorum. Açık fikirliydik, hiçbir kararı somut olarak değerlendirmedik (burada ego yok), sürekli kullanıcılarımızla görüştük ve doğru gelmese bile onları dinledik.

İş Başında Öğrenme

Her etkileşim gelişmek ve etkilemek için bir fırsattır. Bu girişimin başlangıcından beri endişem, modelin şanslı olmasıydı; bekar bir baba veya anneye bebeklerinin gazlı olduğu ve bebeklerini geğirerek öldürdüğü için ağladığı söylendi. Pek olası değil ama her kullanıcının bebeğinin sağlığından kendimizi sorumlu hissettik. Bu nedenle uygulamaya geri bildirim özelliği ekleyerek lansmanı erteledik.

Her çeviriden sonra size bunun ne kadar faydalı olduğu soruldu; atlanamayan bir sayfa. Daha sonra uygulama kullanıcı geri bildirimini, model çıktısını, cihaz tipini ve spektrogramı yükledi. Başlangıçta ses dosyasını yükledim ancak mikrofonun çok fazla arka plan gürültüsünü yakaladığını hemen fark ettim. Kullanıcılarımızın gizliliği açısından yalnızca spektrogramı yüklemeyi seçiyoruz. O zamanlar bilmediğim şey, daha düşük kalitede ve biraz zorlukla da olsa, bir spektrogramı tersine çevirebileceğiniz ve sesi yeniden oluşturabileceğinizdi. Bu bizim volanımızdı.

Ancak bu son versiyona yol açan tartışmaları ve birçok taslağı atlıyorum. Hangi verilerin toplanacağına, başarının nasıl ölçüleceğine ve başarının nasıl tanımlanacağına karar vermek zordur ancak bu, küçük adımlarla gerçekleştirebileceğiniz ve geliştirebileceğiniz yinelenen bir süreçtir. Aldığım en iyi tavsiye başarının neye benzediğini tanımlamaktı ya da eğer bu çok zorsa başarısızlığın neye benzediğini tanımlamaktı (benim için başarısızlığı tanımlamak başarıdan çok daha kolaydır; ne istediğimi asla bilmiyorum ama ne istediğimden eminim) kaçınmak istediğim şey) ve spesifik olun. Bu yanıttan, çabalarınızı değerlendirmek için kullanabileceğiniz ölçümleri çıkarın; başarısızlık, bebekleri uygulamayı kullanamayacak kadar yaşlanmadan önce kullanıcıları kaybetmekse, ardından uygulamanın kullanıcının telefonundaki ortalama ömrünü ölçün. Ancak bu tanımların ve ölçümlerin statik olmadığını, değişeceğini unutmayın. Sadece karar vermeniz ve çalışmayı bırakana kadar onlara bağlı kalmanız gerekiyor. Onlardan bir şeyler öğrenmeyi bıraktığınızda veya en azından onlardan bir şeyler öğrenmek zorlaştığında, onlar da çalışmayı bırakacaktır. Amaç bu, öğrenmek ve gelişmek, gerisi detaydır.

AI/ML çağında bir şirketin en değerli dijital varlığı model değil, kendisine emanet edilen verilerdir. Bu verileri tercihen şeffaf ve etik bir şekilde büyütmek, başarının devamı için kritik öneme sahiptir. Bu nedenle, her kullanıcı etkileşimi, dönüşüm oranlarına bakılmaksızın değer yaratma anı olarak değerlendirilmelidir. Dolayısıyla her etkileşimin kullanıcıyı etkilemesi ve geri dönme isteği uyandırması gerekir. Hayranlık uyandıran ve ilham veren bir şey inşa ettik; Kaba taslağımı alıp onu rahatlatıcı ve kullanımı keyifli bir uygulamaya dönüştüren harika bir tasarımcımız Teresa Ibarra vardı. Ve her çeviri bir sonrakini daha iyi hale getiriyordu.

Son

Yaptığımız son şey Homer'dı. Uygulama kullanıcılarıyla onlarca yüz yüze görüşme yaptıktan ve daha da fazla kişiyi aradıktan sonra, ağlayan çocuğunuzu kucağınızda tutarken telefonunuzu aramanın, ekran kilidini açmanın, uygulamamızı bulmanın, açmanın ve çevir'e tıklamanın zor ve zahmetli olduğunu fark ettik. Bunu anlamamız neden bu kadar uzun sürdü? Yirmili yaşlarında iki bekar, çocuksuz adamdık - bırakın ağlamalarını dindirmeyi, bir bebeği en son ne zaman kucağıma aldığımı hatırlamıyorum. Biz de akıllı hoparlör kullanarak bir bebek telsizi yapmaya karar verdik. Raspberry Pi'den bir kit sipariş ettim ve üstünde büyük mavi bir düğme bulunan özel bir Google Home hoparlörü yaptım.

Chris'in modeli bebek telsizi şirketlerine satma konusunda harika bir vizyonu vardı, ancak bu şirketlerden ilgi göremiyorduk, o halde neden akıllı bir hoparlör kullanarak kendi bebek telsizimizi yapmıyoruz? Google Home'u oluşturduktan sonra, başlangıçta çevirmeni çalıştırmak için bir bash betiği oluşturdum. Çevirmen, 'Tamam, Google, tercüme et' tetikleyici ifadesini tercüme etmek için Google Home'un SDK'sını kullandı. Çevirmen, mikrofonlardan sesi okuyan, bunu bir spektrograma dönüştüren ve daha sonra çevrilmek üzere bir sunucuya gönderen bir Python betiğiydi. İşleri çevik tuttum ve işe yaradı ! Sonunda muhteşem uygulamamıza kavuştuk ama bu şirketi kurtarmadı.

Bir yarışmadan kazandığımız para ödülü olan finansmanımız bitti. Hayat ikimizin de üzerine hızla akıyordu. Üniversiteden mezun olduk ve ikimiz de eve döndük; ben Bay Area'da bir işi kabul ettim ve Chris, Teksas'taki hasta annesine bakmak için ayrıldı. Başlatma başarısız oldu.

Startup'lar zor ve yürek parçalayıcıdır. Bunları yarı zamanlı yapamazsınız. Hissesi olan herkesin tam zamanlı çalışması gerekiyor ya da başka birine yer açmak için ayrılması gerekiyor. Veya hırslarınızı küçültmeniz, belki de tamamen terk etmeniz gerekir. Şimdi, yarı zamanlı olarak kârlı bir şekilde çözülebilecek sorunlar var ama bunlar değerli mi? Seni heyecanlandırıyorlar mı?

Android'de ML modellerini dağıtmanın ne kadar acı verici olduğunun yanı sıra bir şey öğrendiysem, o da çözdüğünüz sorunla gerçekten ilgilenmeniz gerektiğidir. Finansal risklere ve muazzam fırsat maliyetine rağmen tam zamanlı olarak bu işe girişme cesaretini bulmanız gerekiyor. Bunun üzerinde çalışmak için teknik işimden vazgeçmem mümkün değildi. Yeni ebeveynlere ve çaresiz babalara yardım etmeyi seviyordum; teknoloji öğrenmek ve inşa etmek heyecan vericiydi ama mezun olduktan sonra neden 8. Bölüm'deki sıkışık dairemize geri döndüğümü babama nasıl açıklayabilirdim? Bu kadar uzun süre Sosyal Yardımla yaşadıktan sonra altı haneli bir maaşı nasıl geri çevirebilirim?

Peki ya risk sermayesi? Neden para toplamayı denemedin? Gerçek şu ki, risk sermayedarları yalnızca sizi, gittiğiniz okulu veya çalıştığınız şirketi tanıyorlarsa telefonu açarlar. Ne inşa ettiğiniz umurlarında değil - kârlı olmanız dışında, inovasyonunuz küçük bir ayrıntıdır - VC'ler önce kuruculara ve ekiplere, sonra da ürünlere yatırım yapar. Ancak çoğu, iyi kurucuları veya ekipleri nasıl seçeceklerini bilmiyor, bu yüzden bunu elit okullardaki veya FAANG'daki kabul memurlarının yapmasına izin veriyorlar.