매기: 아기 번역기 AI 스타트업의 이야기

핵심요약, DR 요약 나는 주차장에서 같은 반 친구를 만났고 잃어버린 10달러 지폐에 대해 담보를 받았습니다. 내가 몰랐던 것은 내 반 친구가 아기의 울음소리를 번역하는 모델을 만들고 공동 창립자를 찾고 있다는 것이었습니다. 의 덕분에 우리는 비즈니스 파트너로 만나고, 일할 곳을 찾고, 회사를 시작할 수 있었습니다. Peter Scheurman 박사 Venture Lab 몇 주 만에 저는 모델을 중심으로 서버를 구축하고 부모가 아기의 통곡을 번역하는 데 사용할 수 있는 Android 구축했습니다. 그러나 지연 시간은 끔찍했습니다. 서버가 가동될 때까지 기다리거나 우는 아이를 안고 오디오 파일을 업로드할 때까지 기다리는 사람은 아무도 없습니다. 앱을 그래서 우리는 모델을 앱에 넣기로 결정했지만 너무 커서 맞지 않았습니다. 이는 정확도를 눈에 띄게 줄이지 않고 양자화를 통해 크기를 줄이고, 앱을 충돌시키지 않고 기기에 필요한 모델 입력을 생성하는 방법을 알아내는 것을 의미했습니다. 우리에게 귀중한 TensorFlow, Android 및 스타트업 조언을 제공한 없었다면 이 일을 해낼 수 없었을 것입니다. Pete Warden이 그러나 이제 모델이 장치에 있으므로 우리의 손이 닿지 않는 곳에 있었습니다. 성능을 어떻게 측정합니까? 성공은 어떤 모습인가요? 성능을 판단하는 데 필요한 모든 정보를 캡처하기 위해 모델 주변에 로깅, 모니터링 및 사용자 피드백 계층을 구축했습니다. 이 데이터는 플라이휠을 만들었습니다. 번역할 때마다 새로운 레이블이 지정된 훈련 데이터가 생성되었습니다. 이제 우리는 최소한의 노력으로 데이터 세트를 늘리고 있었습니다. 앱이 작동하고 모니터링되자 우리는 딜레마에 빠졌습니다. 하나 또는 여러 개의 번역을 표시해야 할까요? Instinct는 가장 정확한 번역을 보여주겠다고 말합니다. 결국 그것이 가장 정확할 가능성이 높은 번역입니다. 하지만 번역 신뢰도가 70%에 불과하다면 어떻게 될까요? 60% 또는 50%는 어떻습니까? 이는 사람들이 실제로 앱을 어떻게 사용하는지 확인하고 킬러 기능을 발견하는 데 도움이 되는 미묘한 문제였습니다. 아이가 품에 안겨 울고 있는 동안 휴대폰을 찾아 앱을 여는 것이 매우 어렵다는 것이 밝혀졌습니다. 그래서 우리는 Google Home 스마트 스피커를 사용하여 손으로 직접 번역할 수 있는 베이비 모니터 를 만들었습니다. Homer 하지만 스마트 스피커만으로는 우리를 구할 수 없었습니다. 우리는 돈과 증기가 바닥났고, 생활 환경이 우리를 집으로 데려갔고, 우리의 아기 번역가는 선반에 놓였습니다. 머리말 투박하고 오래된 전문 도구를 우회할 수 있는 기회를 보고 업무용 AI 기능 작업을 시작했고, 물론 모든 스타트업은 스타트업이어야 합니다. 이 기능의 프로토타입을 작성하는 동안 몇 가지 이상하고 친숙한 문제에 직면했습니다. 그래서 저는 일기장을 뒤져 팬데믹 이전에 저와 친구가 만든 아기 번역가인 매기를 발견했습니다. 거의 7년이 지났고, 최신 기술이 상당한 발전을 이루었음에도 불구하고 AI 테스트 및 프로덕션 배포를 괴롭혔던 동일한 문제는 여전히 완화되지 않은 문제입니다. 다음은 AI를 생산하는 과정에서 발생하는 일반적인 문제를 보여주기 위해 Maggie가 작성한 메모, 생각 및 코드를 반영한 것입니다. 도움이 되셨기를 바랍니다. AI 매기는 무엇입니까? 매기는 같은 이름의 쇼에 등장하는 심슨 가족의 막내 이름입니다. 매기는 아직 말하는 법을 배우지 못한 아기입니다. 매기의 삼촌인 허브는 잘못된 사업 결정으로 바닥을 치고 심슨 가족과 함께 이사합니다. 그는 조카의 언어 부족으로 인한 좌절감과 조카에게서 영감을 얻어 기적적으로 일하는 아기 번역기를 만들었습니다. 비슷한 방식으로, 내 친구 Chris는 말을 잘 알아듣는 데 어려움을 겪는 여동생과의 관계에서 아기 번역기를 만들겠다는 아이디어를 얻었습니다. 따라서 우리는 앱 이름을 Maggie로 지정했습니다. 당시 아기 연구실에서 일하고 있었는데, 특정 연령대의 어린이들이 낼 수 있는 소리의 스펙트럼에는 생리학적 한계가 있다는 것을 알아냈습니다. 이 통찰력을 바탕으로 그는 훈련 데이터를 수집하고 아기 울음소리에 대한 분류 모델을 구축했습니다. 이는 CS 경험이 없는 물리학 전공자였기 때문에 인상적인 업적이었습니다. 크리스는 우리는 전체 학급이 캠퍼스 건물 중 하나에 대한 LEED 인증에 대해 작업한 하나의 수업인 엔지니어 서비스 학습을 공유했습니다. 나는 그를 롱보드를 타고 수업에 참석했던 낙천적인 사람으로 기억합니다. 우리의 첫 번째 상호 작용은 교실 밖, 식료품점의 어두운 주차장에서 이루어졌습니다. 그곳에서 나는 그가 더트바이크를 탈 준비를 하는 것을 보았습니다. 그는 내 차 옆에 주차했고 우리는 이야기를 나누었습니다. 그러다가 나는 그 사람 옆에 구겨진 종이 몇 장이 있는 것을 발견하고 그것을 집어들더니 그것이 돈이라는 것을 알아차리고 그에게 돈을 떨어뜨렸다고 말했습니다. 자기 것이 아니라고 했는데 내가 보관하라고 했어요. 우리는 그것이 얼마인지 몰랐습니다. 주차장이 너무 어두웠어요. 1달러, 10달러, 100달러. 나는 그에게 그것이 100달러였으면 좋겠다고 말했습니다. 10달러였습니다. 하지만 그 첫 번째 상호 작용은 우리 사이에 충분한 신뢰를 쌓았고 몇 주 만에 우리 둘 다 UC Merced의 스타트업 인큐베이터인 Venture Lab에서 일하는 동안 그는 나에게 아기 번역기를 배포할 앱을 구축해 달라고 요청했습니다. Venture Lab이 없었다면 우리는 협업을 꿈도 꾸지 못했을 것입니다. 나는 분명히 무작위 학우들에게 내가 안드로이드 앱을 만든다고 말하지 않았고, 그도 자신의 아기 번역 모델에 대해 자랑하지 않았습니다. 과소평가해서는 안 되는 대면 공간에는 자석 같은 마법이 있습니다. 모델이 있는데 작동합니다. 이제 뭐? 작업 모델을 구축했음에도 불구하고. Chris는 배포 방법을 알 수 없었습니다. 2017년 초였는데, 이를 입증하는 강좌나 가이드가 많지 않았습니다. TensorFlow의 멘토는 Android 배포를 권장했지만 모바일 개발을 배우는 것은 너무 먼 일이었습니다. 나는 Android를 알고 Play 스토어에 여러 앱을 배포했지만 나에게도 이것은 무리였습니다. 그래서 저는 쉬운 일을 했습니다. 모델을 서버에 올려 놓고 API를 호출했습니다. Flask 서버에서 모델을 실행하는 것은 놀라울 정도로 쉬웠습니다. TensorFlow를 가져오고, 로컬 디스크에서 모델을 로드하고(나중에 버전을 쉽게 지정할 수 있는 방식으로 모델을 배포하는 것에 대해서는 생각조차 하지 않았습니다), 요청을 다음 위치로 지정합니다. 그것. 하지만 몇 가지 문제점이 있었습니다. 요청은 모델이 기대하는 입력으로 변환되어야 했고, 우리는 이 작업을 수행하기 위한 공유 패키지를 만들지 않았습니다. Chris가 모델을 훈련시키고 서버를 만들었기 때문에 이것이 오류의 원인이 되었습니다. 첫 번째 요청은 항상 느렸습니다. 우리는 AppEngine에서 호스팅하고 있었고 이렇게 긴 설정이 필요한 서버를 사용한 적이 없었기 때문에 유휴 서버 수를 0(기본값)으로 두었습니다. 새 서버를 시작하는 데 1초밖에 걸리지 않는데 왜 유휴 서버에 돈을 소비합니까? 모델을 로드하고 실행하는 데 오랜 시간이 걸렸기 때문에 서버를 연중무휴로 가동해야 했습니다. 아기가 언제 울기 시작할지 알 수 없으므로 호스팅 비용이 더 많이 듭니다. 이러한 느린 시작으로 인해 통합 테스트가 큰 골칫거리가 되었고, 결국 수동 테스트를 다시 시작하게 되었습니다. 테스트가 통과될 때까지 몇 분씩 기다리는 것은 참을 수 없는 일이었습니다. 핫 리로드를 통해 서버를 가동하고 각 커밋 전에 수동으로 테스트하는 것이 더 빨랐습니다. 배포 및 버전 관리가 까다로웠습니다. 처음에는 어떤 형태로든 버전 제어를 원했기 때문에 리포지토리를 사용하여 모델을 배포했지만 이로 인해 배포 용이성이 희생된다는 것을 금방 깨달았습니다. 모든 모델 업데이트에는 서버를 배포하고 전체 클러스터를 다시 시작해야 했는데, 서버가 새 모델을 로드해야 했기 때문에 시간이 걸렸습니다. 이러한 문제에도 불구하고 효과가 있었습니다. 모델 입력 파서와 변환기 코드를 공유하면 첫 번째 문제가 해결되었습니다. 모델을 블랙박스로 취급하고 모형화하면 모델을 중심으로 통합 테스트를 구축하는 것이 더 쉬워졌습니다. 이러한 테스트는 모의가 정확하다면 서버와 모델 사이에 예상치 못한 정렬 오류가 없는지 확인합니다. 이제 개발 중에 모의 정확성을 보장할 수 있는 모델 인터페이스가 있습니다. 모델의 배포 및 버전 제어는 오늘날 대부분의 사용 사례에 대한 새로운 솔루션이 필요한 문제가 아닙니다. 반면, 지연 시간과 가용성 문제로 인해 결국 엣지의 앱에 모델을 배포하게 되었습니다. 이는 네트워크 대기 시간을 제거하고, 휴대폰의 훨씬 더 빠른 CPU를 사용하고, 앱을 백그라운드에서 계속 실행하여 시작 대기 시간 문제를 해결하고 호스팅 비용을 낮추는 이점이 있었습니다. 그러나 물론 새로운 문제도 있었습니다. 모델을 어디에 둘 것인가? 우리는 모델을 어디에 둘 것인지 토론하는 데 많은 시간을 보냈습니다. 우리는 전화기의 속도와 확실성을 원했지만 서버의 보안과 배포 용이성을 원했습니다. 처음에는 모델을 서버에 올리는 것이 매력적이었습니다. 업데이트와 배포가 쉬웠습니다. 사용자 수에 제한이 없었습니다. 당시에는 특정 Android 버전만 TensorFlow 추론 라이브러리를 지원했기 때문에 모델을 휴대폰에 적용하는 것은 사용자 수가 적다는 것을 의미했습니다. 이는 더 큰 선택성을 제공했습니다. 서버의 API는 스마트 스피커, 웹 사이트 및 베이비 모니터에서 사용될 수 있습니다. 누군가가 모델을 훔칠까봐 걱정할 필요가 없었습니다. 하지만 단점은 계속해서 쌓였습니다. 느렸습니다. 녹음 파일을 업로드하고, 이를 복사하고, 모델을 실행하는 데 오랜 시간이 걸렸습니다. 중단 위험으로 인해 앱의 매력이 떨어졌습니다. 사용자에게는 100% 가용성이 필요했습니다. 이 앱의 가장 매력적인 점은 배우자, 부모 등이 없을 때 당신을 위해 거기에 있었다는 것입니다. 당신이 헤아릴 수 없이 우는 아이와 혼자 있을 때 당신을 위해 거기에 있었습니다. 그것은 비쌌다. 이 모든 작업을 수행하는 데 필요한 머신은 모든 비용을 지불하기 위해 Google Cloud 크레딧을 사용해야 하는 스타트업에게는 비용이 많이 들었습니다. 결국 우리는 처음 두 가지 사항 때문에 앱에 모델을 넣기로 결정했습니다. 번역이 나올 때까지 기다려야 하거나 가끔 다운되는 경우 앱이 설득력이 없었습니다. 울고 있는 신생아를 품에 안고 있을 때는 몇 초의 대기 시간이 영원처럼 느껴집니다. 그러나 다음 섹션에서 설명하겠지만 모델을 휴대폰에 적용하는 데는 문제가 있었습니다. 제가 여기서 얻은 교훈은 솔루션이 확장 가능하지 않거나 향후 성장을 제공하지 못하거나 IP에 위험이 있더라도 최고의 사용자 경험을 위해 최적화해야 한다는 것입니다. 기업은 사용자 경험에 따라 살고 죽습니다. 특히 신뢰를 얻고 브랜드를 구축해야 하는 신생 기업이라면 더욱 그렇습니다. 가장자리로부터의 이야기 모델을 휴대폰에 연결하는 데에는 기술적인 어려움이 많았습니다. 그 중 일부는 현재 존재하지 않지만 대부분은 존재합니다. 우리는 최첨단에 있었습니다. Android용 TensorFlow는 거의 출시되지 않았습니다. 공개 릴리스는 2017년 2월이었고 저는 3월에 앱을 구축하고 있었습니다. 하지만 TensorFlow의 의 인내와 많은 도움으로 우리는 모델이 앱에서 작동하도록 할 수 있었습니다. Pete Warden 첫 번째 문제는 APK 패키지에서 모델을 가져오는 것이었습니다. 당시 안드로이드에는 APK 제한이 50MB였으며, 설치 후 구성 요소를 다운로드하여 앱 크기를 늘릴 수 있는 확장 기능이 있었습니다. 그러나 확장 기능은 모델을 서버에 노출시키는 것을 의미하므로 안전하지 않다고 생각했습니다. 그래서 우리는 모든 계층의 모든 입력과 출력의 정확도를 줄이는 기술인 앱을 양자화하기로 결정했습니다. 우리의 경우 모든 부동 소수점 숫자를 정수로 변환하여 모델의 크기를 크게 줄이고 속도를 높였지만 정확도도 떨어졌습니다. Chris는 다양한 양자화 체계를 사용하여 모델을 여러 번 반복한 후 정확도 감소에도 불구하고 마침내 정수 양자화에 정착했습니다. 모델이 새 상위 모델보다 더 나은 성능을 발휘하는 한 유용했습니다. 보너스: 업데이트 문제를 해결했습니다. 모델 업데이트마다 수백 MB의 데이터를 다운로드하는 것은 데이터 요금제 인터넷 연결에서는 어려운 일이었지만 몇 MB는 관리할 수 있었습니다. (오늘날 사람들이 정기적으로 휴대폰에 GB의 비디오 콘텐츠를 다운로드하기 때문에 이것은 어리석은 것 같습니다. ). 그런 다음 사소한 문제가 길게 이어졌습니다. 가장 큰 문제는 Android와 함께 제공되는 다양한 Java 버전에서 지원되는 FFT 라이브러리가 모델이 학습한 것과 동일한 스펙트로그램을 생성하지 않았다는 것입니다. 우리는 C++ FFT 라이브러리를 사용하여 모델을 교육했으며 다양한 색상과 크기의 스펙트로그램을 생성했습니다. 비밀 도구이기 때문에 C++ 및 Java 버전 모두 불투명하게 작성되었으며 수정하기 어려웠습니다. 또 다른 빠른 결정: Java FFT 스펙트로그램을 사용하여 모델을 재교육하기로 결정했습니다. 이는 모든 오디오 파일을 스펙트로그램으로 변환한 다음 훈련 과정을 실행하는 것을 의미했으며, 내 친구의 오래된 Macbook에서 며칠이 걸렸습니다. 그런데 문제가 해결됐고, 그 시간 동안은 다른 일에 집중할 수 있었어요. 하지만 앱이 계속 멈추고 충돌이 발생했습니다. 기록을 메모리에 로드한 다음 메모리에 스펙트로그램을 생성하는 것은 나쁜 생각이었습니다. 앱이 휴대전화의 리소스를 많이 잡아먹고 있었습니다. 해결책은 디스크에 저장하고 스트리밍하는 것이었습니다. 디스크에 저장하는 것은 쉬웠습니다. 스트리밍 부분은 오디오가 메모리를 떠나면 디스크에서 어떤 일이 일어날 수 있기 때문에 어려웠습니다. 다른 프로그램이 이를 읽고 수정할 수 있습니다. 삭제될 수도 있고, 저장하지 못할 수도 있습니다. 이러한 극단적인 경우는 일반적으로 웹에 존재하지 않습니다. 사용자와 격리된 채널이 있지만 장치에는 없습니다. 처음에 이 작업을 수행할 공간이 충분한지 확인하고 앱을 사용한 후 정리하는 것은 예상치 못한 도전이었습니다. 휴대폰에 앱을 설치하기에 충분한 메모리가 있으면 앱을 실행하기에 충분한 메모리가 있다고 믿는 것은 잘못된 가정이라는 것을 나중에 알게 되었습니다. 마지막으로 기기 자체가 적이었습니다. Android 휴대폰에는 다양한 CPU, 메모리 용량, 그리고 가장 중요한 마이크가 함께 제공됩니다. CPU 및 메모리 문제는 필요한 Android 버전을 최신으로 설정하고 최선의 결과를 얻으면 해결될 수 있습니다. 최악의 시나리오는 앱 속도가 느린 것이었습니다. Android에서 리소스 요구 사항을 직접 설정할 수 있는 방법이 없습니다. 진짜 문제는 마이크의 다양한 품질을 고려하는 것이었습니다. Android에서는 앱이 설치된 기기에 마이크를 요구할 수 있지만 마이크 유형은 요구할 수 없습니다. 나는 이 문제를 해결하려고 노력하지 않았습니다. 그 당시 나는 많은 테스터 휴대폰을 가지고 있었고 값싼 휴대폰의 예측이 얼마나 더 나빴는지 깨달았습니다. 지금은 해결책을 찾을 시간이 없다고 판단했습니다. 가능한 한 빨리 출시하려고 노력하고 있었습니다. 때로는 문제에 대한 최선의 해결책은 문제를 기록하고 계속 진행하는 것입니다. 이제 나는 이 문제가 우리에게 최종 제품인 스마트 스피커인 Homer의 방향을 제시했다는 것을 깨달았습니다. 기술적인 어려움이 극복(또는 방지)되면 예측 품질이라는 더 어려운 문제로 넘어갔습니다. 모델이 앱에 상주했기 때문에 우리는 그 성능을 알 수 없었습니다. 성능이 좋지 않은 경우 우리가 알 수 있는 유일한 방법은 앱 페이지의 댓글이나 제거를 통해서입니다. 그때는 너무 늦습니다. 따라서 모델에 대한 로그 래퍼, 모니터링, 데이터 수집 및 피드백을 구축하는 것이 중요했습니다. 하나인가, 아니면 다수인가? 모델은 스펙트로그램과 기타 몇 가지 정보를 사용하여 아기가 내는 소리(배고픈 소리, 불편한 소리, 고통스러운 소리, 졸리는 소리, 가스가 나는 소리)를 분류했습니다. 이러한 것들이 번역되었습니다. 가능한 모든 범주의 목록을 반환했으며, 각 범주에는 해당 특정 번역에 대한 모델의 신뢰도를 나타내는 백분율이 포함되어 있습니다. 모든 백분율의 합은 100이 됩니다. 가장 정확한 번역이 90%에 달했다면 나머지 5개 범주의 정확도는 합이 10%가 됩니다. 초기에 우리가 직면했던 질문은 모든 번역을 표시할지(가장 정확한 것부터 가장 적은 것까지) 아니면 하나만 표시하는 것이었습니다. 더 많은 번역으로 사람들을 혼란스럽게 하고 싶지 않았기 때문에 하나만 보여 주기로 결정했고, 이것을 구축하는 것이 더 간단했습니다(게으름은 Agile의 초석입니다). 그러나 첫 번째 사용자 그룹에서 문제가 발생했습니다. 모델이 확실했을 때(80% 이상) 제안은 효과가 있었습니다. 우리는 부모로부터 불만을 접수하지 않았습니다. 그러나 항상 그렇게 자신감이 있었던 것은 아닙니다. 번역 정확도가 80% 미만이면 부모나 추측만큼 좋은 것입니다. 이는 앱의 목적을 상실합니다. 아이를 달래려는 초보 부모의 겁에 질린 시도보다 더 정확한 번역을 제공해야 합니다. 그리고 놀랍게도 두 번째나 세 번째 번역이 정확했습니다. 우리는 대면 인터뷰를 통해 이를 발견했습니다. 대면 인터뷰는 확장이 불가능하고 시간이 많이 걸리지만 정보 밀도가 매우 높습니다. 매일 하나씩 할 수 있다면 그렇게 하세요. 아기는 울고 앱은 신뢰도가 낮은 잘못된 번역을 표시하지만 우리는 다른 번역을 시도했고(로그에서 본) 작동했습니다. 나는 앱을 번역기로 생각했기 때문에 이것은 나에게 반직관적이었습니다. 무언가를 번역하는 방법은 한 가지뿐이어야 합니다. 그렇죠? 잘못된. 이 앱은 새로운 부모와 보호자가 무엇을 먼저 시도해야 할지 결정할 수 있는 탐색 도구였습니다. 아기에게 트림을 시켜야 할까요? 배고픈가요? 그가 마지막으로 낮잠을 잔 게 언제였나요? 모든 부모는 아기가 울기 시작할 때 이 체크리스트를 확인합니다. 우리 앱은 이 탐색 속도를 높였습니다. 부모님들이 그렇게 사용하셨고, 여러 번역본을 출시한 후 받은 피드백도 마찬가지였습니다. 이것이 킬러 기능은 아니었지만 앱을 특수 효과에서 일상적으로 사용하는 도구, 배우자가 없거나 조부모가 자고 있을 때 신뢰할 수 있는 동반자로 확실히 바꿔 놓았습니다. 이 데이터를 바탕으로 우리는 더 많은 번역을 표시하기로 신속하게 결정했습니다. 비결은 얼마나 많은지 알아내는 것이 었습니다. 모든 번역(5개 카테고리 모두)을 표시하면 앱이 매번 동일한 번역을 반복하는 것처럼 보이게 되었습니다. 당신이 음식을 검색할 때마다 구글이 똑같은 레스토랑 4곳을 보여준다면 여러분은 어떻게 생각하시겠습니까? 우리는 상위 3개 번역, 즉 이 부분은 아트와 부분 데이터를 결정했습니다. 사람들은 어떤 이유에서든 숫자 3에 관심을 갖습니다. 데이터에 따르면 다른 번역에 대한 모델의 신뢰도는 세 번째 번역 이후 크게 떨어졌습니다. 첫 번째 번역의 신뢰도가 70%라면 두 번째 번역은 20%, 세 번째 번역은 9%, 나머지는 1% 미만이 됩니다. 그래서 우리는 이러한 번역을 삭제했습니다. 삭제된 번역이 정확할 가능성은 적었지만 이를 포함하면 앱이 반복적으로 보일 위험이 있었습니다. 선택은 사용자 100명 중 1명이 모두 잘못된 번역을 받거나 모든 사용자가 쓸모 없는 번역을 보고 앱이 추측하고 있다고 생각하는 것이었습니다. 쉬운 선택이었습니다. 물론, 돌이켜보면 멀티암 밴디트(multi-arm bandit)를 사용하여 이것을 테스트했어야 했습니다. 다섯 가지 다른 버전의 앱을 출시하고 각 선택에 대해 하나씩(예: 하나의 번역 표시, 두 개 표시, 세 개 표시 등) 천천히 사람들을 마이그레이션합니다. 최상의 결과를 얻은 앱 버전을 선택하세요. 주요 성공 지표는 녹색 확인 표시(번역에 만족함)를 클릭한 사람의 수입니다. 하지만 저는 그러한 초기 단계에서 우리가 올바른 결정을 내렸다고 믿습니다. 그리고 더 중요한 것은 우리가 올바른 방식으로 결정을 내렸다는 것입니다. 우리는 개방적이었고 어떤 결정도 구체적인 것으로 간주하지 않았으며(여기에는 자존심이 없음) 사용자를 지속적으로 확인하고 옳지 않다고 느껴지더라도 사용자의 의견에 귀를 기울였습니다. 직장에서 학습 모든 상호작용은 발전하고 감동을 줄 수 있는 기회입니다. 이 벤처를 시작할 때 제가 걱정했던 점은 모델이 운이 좋았을 뿐이고, 아기가 가스가 차서 트림을 해서 죽는다는 말을 듣는 싱글 아빠나 엄마가 있을 것이라는 점이었습니다. 그럴 것 같지는 않지만, 우리는 각 사용자의 아기의 행복에 대한 책임감을 느꼈습니다. 그래서 앱에 피드백 기능을 추가하여 출시를 연기했습니다. 번역이 끝날 때마다 건너뛸 수 없는 페이지가 얼마나 도움이 되었는지 질문을 받았습니다. 그런 다음 앱은 사용자 피드백, 모델 출력, 장치 유형 및 스펙트로그램을 업로드했습니다. 처음에는 오디오 파일을 업로드했지만 마이크가 배경 소음을 많이 포착한다는 것을 금방 깨달았습니다. 사용자의 개인정보 보호를 위해 스펙트로그램만 업로드하도록 선택했습니다. 그 당시 제가 몰랐던 것은 비록 품질이 낮고 약간의 어려움이 있기는 하지만 스펙트로그램을 역전시켜 오디오를 재구성할 수 있다는 것이었습니다. 이것이 우리의 플라이휠이었습니다. 그러나 나는 이 최종 버전으로 이어진 논쟁과 여러 초안을 건너뛰었습니다. 어떤 데이터를 수집할지, 어떻게 성공을 측정할지, 어떻게 성공을 정의할지 결정하는 것은 어렵지만, 작은 단계를 거쳐 개선할 수 있는 반복적인 프로세스입니다. 제가 받은 최고의 조언은 성공이 어떤 것인지 정의하고, 그것이 너무 어렵다면 실패가 어떤 것인지 정의하라는 것이었습니다. (나에게는 성공보다 실패를 정의하는 것이 훨씬 쉽습니다. 저는 제가 원하는 것이 무엇인지는 모르지만 확신합니다. 피하고 싶은 것) 구체적으로 설명하세요. 해당 답변에서 노력을 판단하는 데 사용할 수 있는 측정항목을 도출하세요. 아기가 너무 커서 앱을 사용할 수 없게 되기 전에 사용자를 잃는 것이 실패라면 사용자 휴대폰에서 앱의 평균 수명을 측정하세요. 하지만 이러한 정의와 지표는 고정되어 있지 않으며 변경될 것이라는 점을 명심하세요. 그들이 작동을 멈출 때까지 결정하고 고수하기만 하면 됩니다. 당신이 그들로부터 배우기를 멈추거나 적어도 그들로부터 배우기가 더 어려워지면 그들은 작동을 멈출 것입니다. 그것이 목표이고, 배우고 개선하는 것입니다. 나머지는 세부 사항입니다. AI/ML 시대에 기업의 가장 가치 있는 디지털 자산은 모델이 아니라 맡겨진 데이터입니다. 투명하고 윤리적인 방식으로 이러한 데이터를 늘리는 것이 지속적인 성공을 위해 매우 중요합니다. 따라서 모든 사용자 상호작용은 전환율에 관계없이 가치 창출 순간으로 처리되어야 합니다. 따라서 모든 상호작용은 사용자에게 깊은 인상을 주고 다시 방문하고 싶게 만들어야 합니다. 우리는 놀라움과 영감을 주는 무언가를 만들었습니다. 훌륭한 디자이너 있었는데, 그는 저의 조잡한 초안을 사용하여 편안하고 즐겁게 사용할 수 있는 앱으로 다듬었습니다. 그리고 모든 번역이 다음 번역을 더 좋게 만들었습니다. Teresa Ibarra가 끝 우리가 마지막으로 만든 것은 호머였습니다. 앱 사용자들과 수십 번 직접 인터뷰하고 더 많은 사람들에게 전화를 한 결과, 우리는 휴대폰을 찾고, 화면 잠금을 해제하고, 앱을 찾아 열고, 우는 아이를 안고 번역을 클릭하는 것이 힘들고 불편하다는 것을 깨달았습니다. 이것을 깨닫는 데 왜 그렇게 오랜 시간이 걸렸습니까? 우리는 20대의 미혼이고 아이가 없는 두 남자였습니다. 마지막으로 아기를 안아본 게 언제인지 기억도 나지 않습니다. 그래서 우리는 스마트 스피커를 활용해 베이비 모니터를 만들기로 결정했습니다. 나는 Raspberry Pi에서 키트를 주문하고 상단에 큰 파란색 버튼이 있는 맞춤형 Google Home 스피커를 만들었습니다. Chris는 이 모델을 베이비 모니터 회사에 판매하려는 훌륭한 비전을 가지고 있었지만 우리는 이들 회사의 관심을 끌지 못했습니다. 그렇다면 스마트 스피커를 사용하여 자체 베이비 모니터를 만드는 것은 어떨까요? Google Home을 구축한 후 시작 시 번역기를 실행하는 bash 스크립트를 만들었습니다. 번역가는 Google Home의 SDK를 사용하여 'Okay Google, 번역'이라는 트리거 문구를 번역했습니다. 번역기는 마이크에서 오디오를 읽고 이를 스펙트로그램으로 변환한 다음 번역하기 위해 서버로 보내는 Python 스크립트였습니다. 나는 모든 것을 민첩하게 유지했고 ! 마침내 킬러 앱이 탄생했지만 회사를 구하지는 못했습니다. 효과가 있었습니다 우리는 대회에서 얻은 상금인 자금이 부족했습니다. 인생은 우리 둘 모두에게 빠르게 닥쳐왔습니다. 우리는 대학을 졸업하고 둘 다 집으로 떠났습니다. 저는 Bay Area에서 일자리를 얻었고 Chris는 텍사스에 있는 아픈 어머니를 돌보기 위해 떠났습니다. 시동에 실패했습니다. 스타트업은 힘들고 가슴 아프다. 파트타임으로 할 수는 없습니다. 스테이크를 가진 모든 사람은 전임으로 일하거나 다른 사람을 위한 공간을 마련하기 위해 떠나야 합니다. 아니면 야망을 축소하거나 완전히 버려야 할 수도 있습니다. 이제 시간제로 수익성 있게 해결할 수 있는 문제가 있습니다. 하지만 그럴만한 가치가 있습니까? 그것들이 당신을 흥분시키나요? Android에 ML 모델을 배포하는 것이 얼마나 어려운 일인지 외에 제가 배운 것이 있다면, 해결 중인 문제에 정말로 관심을 기울여야 한다는 것입니다. 재정적 위험과 엄청난 기회 비용에도 불구하고 전임으로 헌신할 용기를 찾아야 합니다. 이 일을 하기 위해 기술직을 포기할 방법은 없었습니다. 나는 새로운 부모와 절망적인 아빠를 돕는 것을 좋아했습니다. 기술은 배우고 구축하는 데 신나는 일이었지만, 졸업 후 비좁은 섹션 8 아파트로 다시 이사하게 된 이유를 아버지에게 어떻게 설명할 수 있겠습니까? 그렇게 오랫동안 복지 생활을 하고 있는데 어떻게 여섯자리 연봉을 거절할 수 있겠습니까? 벤처 캐피탈은 어떻습니까? 왜 돈을 모으려고 하지 않았나요? 현실은 VC가 귀하, 귀하가 다녔던 학교 또는 귀하가 근무한 회사를 아는 경우에만 전화를 받는다는 것입니다. 그들은 당신이 무엇을 구축했는지 신경 쓰지 않습니다. 수익성이 부족하고 혁신은 사소한 세부 사항입니다. VC는 창립자와 팀에 먼저 투자하고 제품은 나중에 투자합니다. 하지만 대부분 좋은 창업자나 팀을 고르는 방법을 모르기 때문에 명문대학 입학사정관이나 FAANG에게 맡기곤 합니다.