Maggie: La saga de una startup de IA para traductores de bebés

Resumen de TL;DR

• Conocí a un compañero de clase en un estacionamiento y me uní por un billete de 10 dólares perdido. Lo que no sabía era que mi compañero de clase había construido un modelo que traducía los llantos de los bebés y estaba buscando un cofundador. Gracias al Venture Lab del Dr. Peter Scheurman , pudimos reunirnos como socios comerciales, tener un lugar para trabajar y lanzar nuestra empresa.
• En unas pocas semanas, construí un servidor en torno al modelo y una aplicación para Android que los padres podían usar para traducir los gemidos de sus bebés. Pero la latencia fue terrible: nadie quiere esperar a que un servidor se active o cargue archivos de audio mientras sostiene a un niño llorando.
• Entonces decidimos poner el modelo en la aplicación, pero era demasiado grande para caber. Esto significó reducir su tamaño mediante la cuantificación sin reducir notablemente la precisión y descubrir cómo generar las entradas que el modelo necesitaba en el dispositivo sin bloquear la aplicación. No podríamos haberlo hecho sin Pete Warden , quien nos brindó valiosos consejos sobre TensorFlow, Android y la puesta en marcha.
• Pero ahora que el modelo estaba en el dispositivo, estaba fuera de nuestro alcance. ¿Cómo medimos su desempeño? ¿Cómo se ve el éxito? Creé una capa de registro, monitoreo y comentarios de los usuarios alrededor del modelo para capturar toda la información necesaria para juzgar el desempeño. Estos datos crearon un volante; cada traducción creaba nuevos datos de entrenamiento etiquetados; ahora estábamos aumentando nuestro conjunto de datos con un esfuerzo mínimo.
• Una vez que la aplicación estuvo funcionando y siendo monitoreada, tuvimos un dilema: ¿mostrar una o varias traducciones? El instinto dice que se muestre la traducción más precisa; después de todo, esa es la que tiene más probabilidades de ser correcta. Pero ¿qué pasa si la traducción tiene sólo un 70% de confianza? ¿Qué pasa con el 60% o el 50%? Este fue un problema sutil que nos ayudó a ver cómo la gente realmente usaba la aplicación y descubrió una característica excelente.
• Resulta que es muy difícil encontrar tu teléfono y abrir la aplicación mientras tu hijo llora en tus brazos. Entonces, creamos un monitor para bebés, Homer , usando un altavoz inteligente de Google Home: traducciones manos libres.
• Sin embargo, el altavoz inteligente no fue suficiente para salvarnos. Nos quedamos sin dinero y sin fuerzas, las circunstancias de la vida nos obligaron a regresar a casa y nuestro bebé traductor quedó en el estante.

Prefacio

Comencé a trabajar en una función de IA para el trabajo porque vi la oportunidad de eludir una herramienta experta antigua y torpe y, por supuesto, toda empresa emergente debe ser una empresa emergente de IA . Mientras creaba el prototipo de esta característica, encontré algunos problemas extrañamente familiares. Entonces revisé mis diarios y encontré a Maggie, la bebé traductora que yo y un amigo construimos antes de la pandemia. Han pasado casi siete años y los mismos problemas que plagaron las pruebas de IA y el despliegue de producción siguen siendo una plaga absoluta, aunque el estado del arte ha logrado avances significativos. Aquí hay una reflexión sobre mis notas, pensamientos y código de Maggie para demostrar los problemas comunes en el camino hacia la producción de IA. Espero que le sea útil.

¿Qué es Maggie?

Maggie es el nombre de la hija menor de los Simpson del programa del mismo nombre. Maggie es una bebé que aún no ha aprendido a hablar. El tío de Maggie, Herb, toca fondo después de una mala decisión comercial y se muda con los Simpson. Milagrosamente construye un bebé traductor que funciona después de inspirarse en su sobrina y la frustración de la familia por su falta de habla. De manera similar, a mi amigo Chris se le ocurrió la idea de crear un traductor para bebés debido a su relación con su hermanita, quien tenía problemas para aprender a hablar. Por eso llamamos a nuestra aplicación Maggie.

Chris estaba trabajando en un laboratorio para bebés en ese momento y descubrió que había limitaciones fisiológicas en el espectro de sonidos que podían emitir los niños dentro de un cierto rango de edad. A partir de esta información, recopiló datos de entrenamiento y construyó un modelo de clasificación para los llantos de los bebés, una hazaña impresionante, ya que estudiaba Física y no tenía experiencia en informática.

Compartimos una clase, Aprendizaje de servicio de ingenieros, donde toda la clase trabajó en la certificación LEED para uno de los edificios del campus. Lo recuerdo como el chico despreocupado que iba en longboard a clase. Nuestra primera interacción fue fuera del aula, en el oscuro estacionamiento de una tienda de comestibles, donde lo vi preparándose para andar en su moto de cross. Había estacionado al lado de mi auto y hablamos. Entonces vi un papel arrugado a su lado, lo recogí, noté que era dinero y le dije que se le había caído el dinero. Dijo que no era suyo, pero le dije que se lo quedara. No sabíamos cuánto era; El estacionamiento estaba demasiado oscuro. $1, $10 o $100. Le dije que esperaba que fueran 100 dólares. Fueron $10. Pero esa primera interacción generó suficiente confianza entre nosotros que en unas pocas semanas, mientras ambos trabajábamos en Venture Lab, la incubadora de startups en UC Merced, me pidió que creara una aplicación para implementar su traductor bebé. Sin Venture Lab, nunca hubiéramos pensado en colaborar. Ciertamente no anduve diciéndoles a compañeros de clase al azar que creo aplicaciones para Android, ni él se jactó de su modelo de traducción para bebés. Hay una magia magnética en los terceros espacios en persona que no debes subestimar.

Tengo un modelo y funciona. ¿Ahora que?

A pesar de construir un modelo funcional. Chris no sabía cómo implementarlo. Esto fue a principios de 2017 y no había muchos cursos o guías que lo demostraran. Su mentor en TensorFlow recomendó implementar en Android, pero aprender sobre desarrollo móvil fue ir demasiado lejos. Conocía Android y había implementado varias aplicaciones en Play Store, pero incluso para mí, esto fue exagerado. Entonces hice lo fácil.

Puse el modelo en un servidor y le hice llamadas API. Ejecutar el modelo en un servidor Flask fue sorprendentemente fácil: importar TensorFlow, cargar el modelo desde el disco local (ni siquiera pensé en implementar el modelo de una manera que fuera fácil de versionar hasta más tarde) y apuntar las solicitudes a él. Pero hubo algunas trampas:

• La solicitud tuvo que transformarse en la entrada que esperaba el modelo y no creamos un paquete compartido para realizar este trabajo. Desde que Chris entrenó el modelo y yo creé el servidor, esto se convirtió en una fuente de errores.
• La primera solicitud siempre fue lenta; estábamos alojando en AppEngine y había dejado la cantidad de servidores inactivos en cero (el valor predeterminado) porque nunca había trabajado con un servidor que requiriera una configuración tan larga. ¿Por qué gastar dinero en servidores inactivos cuando solo tomó un segundo iniciar servidores nuevos? Cargar y ejecutar el modelo llevó mucho tiempo, por lo que tuvimos que tener nuestros servidores inactivos las 24 horas del día, los 7 días de la semana. No sabes cuándo un bebé va a empezar a llorar, lo que significa una factura de hospedaje más alta.
• Este lento comienzo hizo que las pruebas de integración fueran un gran dolor de cabeza, hasta el punto de que recurrí a las pruebas manuales. Esperar minutos para que pasaran las pruebas era insoportable. Fue más rápido activar el servidor con recarga en caliente y probarlo manualmente antes de cada confirmación.
• La implementación y el control de versiones fueron complicados. Inicialmente, había implementado el modelo con el repositorio porque quería algún tipo de control de versiones, pero rápidamente me di cuenta de que esto estaba sacrificando la facilidad de implementación. Cada actualización del modelo requirió implementar el servidor y reiniciar todo el clúster, lo que llevó tiempo porque los servidores tenían que cargar el nuevo modelo.

A pesar de estos problemas, funcionó. Compartir el analizador de entrada del modelo y el código del transformador resolvió el primer problema. Tratar el modelo como una caja negra y burlarse de él facilitó la creación de pruebas de integración a su alrededor. Estas pruebas garantizarían que no hubiera desalineaciones inesperadas entre el servidor y el modelo, siempre y cuando las simulaciones fueran precisas. Ahora, existen interfaces modelo que pueden garantizar una corrección simulada durante el desarrollo. La implementación y el control de versiones de modelos no es un problema que requiera soluciones novedosas para la mayoría de los casos de uso hoy en día.

Por otro lado, los problemas de latencia y disponibilidad finalmente nos obligaron a implementar el modelo en la aplicación en el borde. Esto tuvo el beneficio de eliminar la latencia de la red, usar la CPU mucho más rápida del teléfono y mantener la aplicación ejecutándose en segundo plano, lo que resolvió nuestro problema de latencia de inicio y redujo nuestros costos de alojamiento. Pero claro, hubo nuevos problemas.

¿Dónde poner el modelo?

Pasamos mucho tiempo debatiendo dónde colocar el modelo. Queríamos la velocidad y la certeza del teléfono, pero ansiamos la seguridad y la facilidad de implementación del servidor. Inicialmente, poner el modelo en el servidor resultó atractivo:

• Fue fácil de actualizar e implementar.
• No limitaba la cantidad de usuarios; en ese momento, solo ciertas versiones de Android admitían las bibliotecas de inferencia de TensorFlow, por lo que poner el modelo en el teléfono significaba menos usuarios.
• Ofrecía una mayor opcionalidad: la API del servidor podía ser utilizada por parlantes inteligentes, sitios web y monitores para bebés.
• No tenía que preocuparme de que alguien robara el modelo.

Pero las desventajas siguieron acumulándose:

• Fue lento; cargar las grabaciones, transcribirlas y luego ejecutar el modelo llevó mucho tiempo.
• El riesgo de una interrupción hizo que la aplicación fuera menos atractiva: nuestros usuarios necesitaban 100% de disponibilidad; Lo más atractivo de la aplicación era que estaba ahí para ti cuando tu cónyuge, tus padres, etc. no estaban; estaba ahí para ti cuando estabas solo con un niño que lloraba inescrutablemente.
• Era caro; Las máquinas necesarias para hacer todo este trabajo eran costosas para una startup que necesitaba usar créditos de Google Cloud para pagar todo.

Al final, decidimos poner el modelo en la aplicación debido a los dos primeros puntos: la aplicación no era convincente si había que esperar a que se tradujera o si ocasionalmente no funcionaba. Unos segundos de latencia parecen una eternidad cuando tienes en brazos a un recién nacido llorando. Pero poner el modelo en el teléfono tuvo sus problemas, como describiré en la siguiente sección.

La lección que aprendí de esto es que debes optimizar para obtener la mejor experiencia de usuario, incluso si la solución no es escalable, no te brinda crecimiento futuro o pone en riesgo tu propiedad intelectual. Las empresas viven y mueren por su experiencia de usuario, especialmente si son empresas nuevas que necesitan ganarse la confianza y construir una marca.

Cuentos desde el borde

Poner el modelo en el teléfono supuso una montaña de dificultades técnicas. Algunos de ellos no existen ahora, pero la mayoría sí. Estábamos a la vanguardia. TensorFlow para Android apenas había salido: el lanzamiento público fue en febrero de 2017 y yo estaba creando la aplicación en marzo. Pero con perseverancia y mucha ayuda de Pete Warden de TensorFlow, logramos que el modelo funcionara en la aplicación.

El primer problema fue conseguir el modelo en el paquete APK. En ese momento, Android tenía un límite de APK de 50 MB y una función de extensión que permitía que las aplicaciones fueran más grandes mediante la descarga de componentes después de la instalación. Sin embargo, consideré que la función de extensión era insegura ya que significaba exponer el modelo en un servidor. Entonces, decidimos cuantificar la aplicación, una técnica que implica reducir la precisión de todas las entradas y salidas de cada capa.

En nuestro caso, convertimos todos los números de coma flotante en números enteros, lo que redujo significativamente el tamaño del modelo y lo hizo más rápido, pero también redujo la precisión. Chris pasó por varias iteraciones del modelo con diferentes esquemas de cuantificación y finalmente se decidió por la cuantificación de números enteros a pesar de la reducción en la precisión. Fue útil siempre que el modelo funcionara mejor que los nuevos padres. Bonificación: resolvió el problema de la actualización: descargar cientos de MB de datos en cada actualización de modelo era una tarea difícil con conexiones a Internet medidas, pero algunos MB eran manejables (esto me parece una tontería ahora, ya que la gente descarga regularmente GB de contenido de video en sus teléfonos hoy en día). ).

Luego vino una larga cola de problemas menores. El mayor problema fue que las bibliotecas FFT compatibles con las diferentes versiones de Java incluidas con Android no producían el mismo espectrograma en el que se entrenó el modelo. Entrenamos el modelo utilizando una biblioteca FFT de C++ y produjo espectrogramas con diferentes colores y dimensiones. Al ser herramientas secretas, tanto la versión C++ como la Java se escribieron de forma opaca y eran difíciles de modificar. Otra decisión rápida: decidimos volver a entrenar el modelo utilizando los espectrogramas FFT de Java. Esto significó transformar todos los archivos de audio en espectrogramas y luego ejecutar el proceso de capacitación, que tomó días en la vieja Macbook de mi amigo. Pero el problema se resolvió y pude concentrarme en otra cosa durante ese tiempo.

Pero la aplicación seguía bloqueándose y fallando. Resulta que cargar la grabación en la memoria y luego crear el espectrograma en la memoria fue una mala idea. La aplicación estaba acaparando muchos recursos del teléfono. La solución fue guardar en el disco y transmitir. Guardar en disco fue fácil; La parte del streaming fue difícil porque, una vez que el audio salía de la memoria, podía pasarle cualquier cosa en el disco. Otro programa puede leerlo y modificarlo; se puede eliminar, es posible que no se pueda guardar, etc.… Estos casos extremos generalmente no existen en la web: tienes un canal aislado con tu usuario, pero no en los dispositivos. Asegurarse de que hubiera suficiente espacio para hacer esto en primer lugar y limpiar después de la aplicación fue un desafío inesperado. Más tarde descubrí que es una suposición errónea creer que si el teléfono tenía suficiente memoria para instalar su aplicación, entonces tenía suficiente memoria para ejecutarla.

Por último, el dispositivo en sí era un adversario: los teléfonos Android vienen con una amplia variedad de CPU, cantidades de memoria y, lo más importante, micrófonos. El problema de la CPU y la memoria podría resolverse configurando la versión requerida de Android a la última y esperando lo mejor; el peor de los casos era una aplicación lenta: no hay forma de establecer los requisitos de recursos directamente en Android. El verdadero problema fue tener en cuenta las diversas calidades de los micrófonos: Android le permite requerir micrófonos en los dispositivos en los que está instalada su aplicación, pero no el tipo de micrófono.

No intenté resolver este problema. Tenía muchos teléfonos de prueba en ese momento y noté cuán peores eran las predicciones en los teléfonos baratos. Decidí que no había tiempo para encontrar una solución ahora: estábamos intentando lanzarlo lo antes posible. A veces, la mejor solución a un problema es tomar nota del mismo y seguir adelante. Ahora me doy cuenta de que este problema nos encaminó hacia el producto final: Homero, un orador inteligente.

Una vez superadas (o evitadas) las dificultades técnicas, pasamos al problema más difícil de la calidad de la predicción. Dado que el modelo vivía en la aplicación, estábamos ciegos a su rendimiento. Si funcionó mal, la única forma de saberlo es a través de comentarios en la página de la aplicación o desinstalaciones; Para ese entonces será demasiado tarde. Por lo tanto, era fundamental crear un contenedor de registros, monitoreo, recopilación de datos y retroalimentación en torno al modelo.

¿Uno o muchos?

El modelo tomó espectrogramas y algunos otros fragmentos de información para categorizar los sonidos que hacía el bebé: hambriento, incómodo, con dolor, somnoliento y con gases, estas fueron las traducciones. Arrojó una lista de todas las categorías posibles, y cada categoría tenía un porcentaje que representaba la confianza que tenía el modelo en esa traducción en particular. Todos los porcentajes suman 100: si la traducción más precisa tuviera un 90%, entonces las otras cinco categorías tendrían precisiones que suman un 10%.

La pregunta que enfrentamos desde el principio fue si mostrar todas las traducciones (ordenadas de más precisa a menos) o solo una. Opté por mostrar solo una porque no quería confundir a la gente con más traducciones, y era más sencillo construirla (la pereza es la piedra angular de Agile). Sin embargo, tuvimos problemas con nuestro primer grupo de usuarios.

Cuando el modelo fue seguro (más del 80%), la sugerencia funcionó: no recibimos quejas de los padres. Pero no siempre fue tan seguro. Cuando la precisión de la traducción era inferior al 80%, era tan buena como la de los padres o las adivinanzas. Esto anula el propósito de la aplicación; debería ofrecer traducciones más precisas que los intentos de pánico de un nuevo padre por calmar a su hijo. Y así fue, no es sorprendente que la segunda o tercera traducción fueran acertadas. Descubrimos esto a través de entrevistas en persona: las entrevistas en persona no se pueden escalar y requieren mucho tiempo, pero contienen mucha información; Si puedes hacer uno diariamente, hazlo. El bebé lloraba y la aplicación mostraba la traducción incorrecta con poca confianza, pero probábamos las otras traducciones (las vimos en los registros) y funcionaban.

Esto fue contradictorio para mí porque pensé en la aplicación como un traductor; Sólo debería haber una forma de traducir algo, ¿verdad? Equivocado. La aplicación fue una herramienta de exploración para que los nuevos padres y cuidadores determinaran qué deberían probar primero. ¿Debería intentar hacer eructar a mi bebé? ¿Tiene hambre? ¿Cuándo fue la última vez que tomó una siesta? Todos los padres revisan esta lista de verificación cuando su bebé comienza a llorar. Nuestra aplicación aceleró esta exploración; así es como lo usaron los padres, y esa es la retroalimentación que recibimos una vez que implementamos múltiples traducciones. Esta no fue la característica principal, pero ciertamente convirtió la aplicación de un truco a una herramienta de uso diario, un compañero confiable cuando el cónyuge no está o los abuelos están dormidos.

Con el respaldo de estos datos, rápidamente decidimos mostrar más traducciones. El truco consistía en calcular cuántos. Mostrar todas las traducciones (las cinco categorías) hacía que la aplicación pareciera que repetía las mismas traducciones cada vez. ¿Qué pensarías si Google te mostrara los mismos cuatro restaurantes cada vez que buscas comida? Nos decidimos por las tres traducciones principales: en parte arte y en parte datos.

La gente se inclina por el número tres por alguna razón. Los datos mostraron que la confianza del modelo en otras traducciones cayó significativamente después de la tercera traducción. Si la primera traducción tuviera una confianza del 70%, la segunda tendría un 20%, la tercera un 9% y el resto por debajo del 1%. Entonces, eliminamos estas traducciones. Había una pequeña posibilidad de que estas traducciones eliminadas fueran precisas, pero al incluirlas se corría el riesgo de que la aplicación pareciera repetitiva. La elección era que 1 de cada 100 usuarios recibiría traducciones todas incorrectas, o que todos los usuarios verían traducciones inútiles y pensarían que la aplicación estaba adivinando. Fue una elección fácil.

Por supuesto, en retrospectiva, debería haber probado esto usando un bandido de múltiples brazos: lanzar cinco versiones diferentes de la aplicación, una para cada opción, por ejemplo, mostrar una traducción, mostrar dos, mostrar tres, etc., y migrar lentamente a las personas. a la versión de la aplicación que tuvo mejores resultados. La principal métrica de éxito sería cuántas personas hicieron clic en la marca de verificación verde (contentas con la traducción). Pero en una etapa tan temprana, creo que tomamos la decisión correcta y, lo que es más importante, tomamos la decisión de la manera correcta. Teníamos una mentalidad abierta, no considerábamos ninguna decisión como concreta (aquí no hay egos), contactábamos constantemente a nuestros usuarios y los escuchábamos, incluso si no nos parecía bien.

Aprendizaje en el trabajo

Cada interacción es una oportunidad para mejorar e impresionar. Mi preocupación desde el inicio de esta empresa fue que el modelo simplemente tuviera suerte, que hubiera un padre o una madre solteros a los que les dijeran que su bebé estaba llorando porque tenía gases y lo eructaran hasta matarlo. Es poco probable, pero nos sentimos responsables del bienestar del bebé de cada usuario. Por eso, retrasamos el lanzamiento agregando una función de comentarios a la aplicación.

Después de cada traducción, se le preguntaba qué tan útil era: una página que no se podía omitir. Luego, la aplicación cargó los comentarios de los usuarios, el resultado del modelo, el tipo de dispositivo y el espectrograma. Inicialmente, subí el archivo de audio, pero rápidamente me di cuenta de que el micrófono capturaba mucho ruido de fondo. Para la privacidad de nuestros usuarios, elegimos cargar solo el espectrograma. Lo que no sabía entonces es que se puede revertir un espectrograma y reconstruir el audio, aunque con peor calidad y con cierta dificultad. Este fue nuestro volante.

Sin embargo, me estoy saltando los debates y los múltiples borradores que llevaron a esta versión final. Decidir qué datos recopilar, cómo medir el éxito y cómo definirlo es difícil, pero es un proceso iterativo que se puede realizar en pequeños pasos y mejorar. El mejor consejo que recibí fue definir cómo es el éxito o, si esto es demasiado difícil, cómo es el fracaso (para mí, es mucho más fácil definir el fracaso que el éxito; nunca sé lo que quiero, pero estoy seguro de lo que quiero evitar) y ser específico. A partir de esa respuesta, obtenga las métricas que puede utilizar para juzgar sus esfuerzos: si el fracaso es perder usuarios antes de que su bebé sea demasiado mayor para usar la aplicación, entonces mida la vida útil promedio de la aplicación en el teléfono del usuario. Pero tenga en cuenta que estas definiciones y métricas no son estáticas: cambiarán. Sólo tienes que decidir y apegarte a ellos hasta que dejen de funcionar. Dejarán de funcionar cuando dejes de aprender de ellos o al menos cuando se vuelva más difícil aprender de ellos. Ese es el objetivo, aprender y mejorar, el resto son detalles.

En la era de la IA/ML, el activo digital más valioso de una empresa son los datos que se le confían, no el modelo. Aumentar estos datos, preferiblemente de manera transparente y ética, es fundamental para el éxito continuo. Por lo tanto, cada interacción del usuario debe tratarse como un momento de generación de valor, independientemente de las tasas de conversión. Por lo tanto, cada interacción debe dejar al usuario impresionado y con ganas de regresar. Construimos algo que sorprendió e inspiró; Tuvimos una gran diseñadora, Teresa Ibarra , que tomó mi borrador crudo y lo pulió hasta convertirlo en una aplicación que era relajante y divertida de usar. Y cada traducción mejoró la siguiente.

El fin

Lo último que construimos fue Homero. Después de realizar docenas de entrevistas en persona con usuarios de la aplicación y llamar a aún más personas, nos dimos cuenta de que buscar su teléfono, desbloquear la pantalla, encontrar nuestra aplicación, abrirla y hacer clic en traducir mientras sostiene a su hijo llorando es difícil e inconveniente. ¿Por qué nos llevó tanto tiempo darnos cuenta de esto? Éramos dos chicos solteros y sin hijos de veintitantos años; no recuerdo la última vez que sostuve a un bebé en brazos, y mucho menos alivió sus lamentos. Entonces, decidimos construir un monitor para bebés usando un altavoz inteligente. Pedí un kit de Raspberry Pi y construí un altavoz Google Home personalizado con un gran botón azul en la parte superior.

Chris tenía una gran visión de vender el modelo a empresas de monitores para bebés, pero no estábamos ganando terreno con estas empresas, así que ¿por qué no construir nuestro propio monitor para bebés utilizando un altavoz inteligente? Después de construir Google Home, creé un script bash para ejecutar el traductor al inicio. El traductor utilizó el SDK de Google Home para traducir la frase desencadenante "Está bien, Google, traduce". El traductor era un script de Python que leía el audio de los micrófonos, lo convertía en un espectrograma y luego lo enviaba a un servidor para su traducción. ¡Mantuve las cosas ágiles y funcionó ! Finalmente tuvimos nuestra aplicación estrella, pero no salvó a la empresa.

Nos quedamos sin financiación: el dinero del premio que habíamos ganado en un concurso. La vida se nos venía encima rápidamente a los dos. Nos graduamos de la universidad y ambos nos fuimos a casa: yo acepté un trabajo en el Área de la Bahía y Chris se fue para atender a su madre enferma en Texas. El inicio falló.

Las startups son difíciles y desgarradoras. No puedes hacerlos a tiempo parcial. Todos los que tienen una participación deben trabajar a tiempo completo o deben irse para dejar espacio para otra persona. O tienes que reducir tus ambiciones, tal vez abandonarlas por completo. Ahora bien, existen problemas que pueden resolverse de manera rentable a tiempo parcial, pero ¿valen la pena? ¿Te emocionan?

Si aprendí algo, además de lo complicado que es implementar modelos de aprendizaje automático en Android, es que realmente debes preocuparte por el problema que estás resolviendo. Es necesario encontrar el coraje para comprometerse a tiempo completo a pesar de los riesgos financieros y el tremendo costo de oportunidad. De ninguna manera iba a dejar mi trabajo tecnológico para trabajar en esto. Me encantaba ayudar a nuevos padres y papás desesperados; Era emocionante aprender y construir la tecnología, pero ¿cómo podía explicarle a mi padre por qué me mudaba de nuevo a nuestro pequeño apartamento de la Sección 8 después de graduarme? ¿Cómo podría rechazar un salario de seis cifras después de vivir tanto tiempo de la asistencia social?

¿Qué pasa con el capital riesgo? ¿Por qué no intentaste recaudar dinero? La realidad es que los capitalistas de riesgo solo contestan el teléfono si te conocen, la escuela a la que fuiste o la empresa en la que trabajaste. No les importa lo que usted haya construido; salvo que sea rentable, su innovación es un detalle menor: los capitalistas de riesgo invierten primero en fundadores y equipos y, al final, en los productos. Pero la mayoría de ellos no saben cómo elegir buenos fundadores o equipos, por lo que dejan que los responsables de admisiones de las escuelas de élite o FAANG lo hagan.