Una pregunta que me hacen a menudo es cómo demonios pasé de la tecnología de voz y la IA a la banca. Pues bien, aquí va la respuesta.
Texto a voz
El punto culminante de mi carrera anterior fue el lanzamiento y el éxito posterior del sistema de texto a voz de Google. Se puso en marcha en junio de 2012 como parte del nuevo servicio Google Now, que permitía a los usuarios realizar búsquedas por voz complejas y hacer preguntas sencillas al servicio. El lanzamiento fue un éxito y el servicio se utiliza ahora para todas las salidas de voz de Google, incluidas las indicaciones de navegación, la búsqueda por voz interactiva y las tecnologías asistidas por voz. El sistema de texto a voz funciona a través de internet y en el propio dispositivo, y desde 2015 se ha instalado en más de mil millones de dispositivos Android.
La principal contribución de nuestro equipo fue proporcionar una voz que sonara muy natural y agradable. Los usuarios no aceptan una síntesis de voz deficiente: resulta molesta al oído y, por lo general, la desactivan si pueden. Solo desarrollando algo de muy alta calidad el servicio se consideraría utilizable.
¿Cómo se consiguió? El sistema de texto a voz utilizaba el marco de selección de unidades, una tecnología con un largo historial, desarrollada a lo largo de los años por laboratorios e investigadores de clase mundial. Básicamente, se graba una base de datos de voz de un solo hablante. Cada frase se divide en fonemas y estos forman las "unidades" que dan nombre al algoritmo. Los patrones sonoros de una unidad de voz concreta dependen mucho del contexto; por ejemplo, en "top" el sonido /t/ tiene mucha aspiración, mientras que en "stop" la /t/ es de naturaleza muy distinta y es más bien una sección corta (50 ms) de silencio. Debido a estos efectos de contexto, grabar una /t/ y usarla en todas partes sonaría discordante y poco natural. De hecho, hay que grabar miles, y a veces decenas de miles, de cada fonema para obtener suficientes unidades que cubran adecuadamente el espectro de sonidos necesarios.
Una vez recopilada y analizada la base de datos, se compila en un formato de ejecución eficiente. Cuando llega una frase, se convierte en fonemas y luego se busca en la base de datos la "mejor" secuencia, es decir, la que contiene las unidades más apropiadas y que encajan mejor entre sí con la menor discordancia. Hacer esto de forma rudimentaria requeriría horas de procesamiento para una sola frase. Pero una combinación de programación dinámica, indexación inteligente, modelos de datos personalizados, almacenamiento en caché, poda y optimización de búsqueda permite generar una frase unas cien veces más rápido de lo que se tarda en reproducir el audio resultante.
Nada de esto se construyó de la noche a la mañana. De hecho, para cuando lanzamos el sistema de Google en 2012, llevaba trabajando en este problema desde 1989. Una vez bromeé (y luego me arrepentí) en una entrevista diciendo que "Miguel Ángel solo tardó siete años en pintar la Capilla Sixtina". Mis años de formación los pasé en la Universidad de Edimburgo, donde terminé mi doctorado en 1992. Pasé los siguientes 8 años allí, culminando con mi nombramiento como director del Centro de Investigación de Tecnología de Voz de la Universidad en 1999. Durante la mayor parte de este tiempo, trabajé en texto a voz, y el Sistema Festival que coescribí con Alan Black y Richard Caley todavía se utiliza como herramienta de enseñanza e investigación. (Y si quieres pruebas de que alguna vez supe programar, echa un vistazo al archivo de github).
La década de 1990 en la Universidad de Edimburgo fue una época fantástica. La universidad contaba con una comunidad vibrante de IA, aprendizaje automático, tecnología de voz, lingüística, ciencia cognitiva e informática, y era un entorno de aprendizaje maravilloso. Cuando veo la atención que recibe la IA hoy en día, sinceramente no sé muy bien cómo reaccionar: en los años 90 éramos quizás unos pocos cientos en el Reino Unido, casi todos nos conocíamos y manteníamos un perfil bajo, principalmente porque, desde una perspectiva comercial, nada funcionaba realmente. Sin embargo, fue tremendamente divertido. Los problemas conceptuales que debatíamos entonces eran los mismos que hoy: ¿deberían las máquinas tener un código moral? ¿Podrían ser peligrosas? ¿Qué pasará con los empleos de la gente? Y así sucesivamente. Pero eran debates dentro de una comunidad introvertida. Todavía me quedo atónito al ver un artículo sobre IA en la prensa todos los días, con incluso primeros ministros y presidentes opinando al respecto.
La vida en una startup
Fundé mi primera empresa tecnológica, Rhetorical Systems, en el año 2000, y desde el primer momento me di cuenta de que esa era mi vocación. Aparte de un paréntesis en Cambridge entre 2004 y 2006, dejé atrás la vida académica.
La vida en Rhetorical fue la habitual montaña rusa de las startups tecnológicas que se ha documentado muchas veces, así que no me extenderé aquí, salvo para decir que entonces había muy poca orientación sobre cómo hacerlo. Los libros de negocios estaban orientados a las grandes corporaciones, y los pocos libros sobre startups que existían trataban sobre abrir tiendas, restaurantes o negocios "normales". Cualquiera que empiece una empresa ahora al menos cuenta con una gran comunidad y una amplia oferta de material de lectura en el que apoyarse.
Rhetorical desarrolló la tecnología de conversión de texto a voz que yo había inventado previamente en la universidad. Fue un gran éxito en cuanto a calidad, pero no tanto en el ámbito comercial. La razón es que, incluso cuando una tecnología es aceptada, resulta difícil venderla en el mercado general. Es posible que la gente quiera usarla, pero se muestra reacia a pagar por ella. Este problema sigue siendo generalizado en el mercado de la IA: Alexa, Siri y Google Home hacen un uso extensivo de la IA y la tecnología de voz, pero estas son proporcionadas por grandes empresas tecnológicas, no por startups independientes. A menudo, las tecnologías que despliegan las grandes empresas fueron inventadas en startups y llegaron a ellas mediante adquisiciones, por lo que está claro que ambos tipos de empresas se necesitan mutuamente. Inevitablemente, Rhetorical fue adquirida en 2004, tras lo cual pasé dos años en el Departamento de Ingeniería de la Universidad de Cambridge.
En 2006 cofundé Phonetic Arts, esta vez como CEO. Hicimos algo muy similar, pero en esta ocasión el mercado era la industria del entretenimiento. De nuevo, la tecnología era excelente, pero encontrar un cliente que pagara seguía siendo difícil. En 2010 la historia se repitió, esta vez cuando Google me llamó un día para preguntarme si queríamos llegar a un acuerdo. Los 5 meses de tortuosas negociaciones que siguieron podrían llenar un libro, pero el final fue feliz: a finales de 2010, Phonetic Arts fue adquirida, el equipo se unió a Google y se convirtió en el equipo de conversión de texto a voz de Google.
Google fue una experiencia muy divertida y supuso un alivio no tener que preocuparme por pagar las nóminas cada mes. La cultura en Google era fantástica, pero lo que realmente me fascinaba no eran las comidas gratis ni los masajes, sino cómo Google había construido una empresa tan escalable. Aunque hoy en día Google es bastante grande, no siempre fue así. Pero incluso en los primeros tiempos, unos pocos cientos de ingenieros podían crear productos que llegaban a ser utilizados por decenas de millones de personas. Cuando me uní al equipo de Android, solo contaba con 300 ingenieros, pero ya se había instalado en 500 millones de teléfonos.
Hay muchos secretos aquí. Primero, contrata solo a ingenieros excelentes y deja que sean el corazón de la empresa tecnológica. Aunque muchas empresas aspiran a esto, muy pocas lo hacen realmente. En el mejor de los casos, contratan a unas pocas estrellas, pero para los trabajos de ingeniería más "aburridos" o "normales", consideran que no las necesitan. El enfoque de Google era contratar estrellas en todos los niveles y eliminar los trabajos aburridos escribiendo código que realice la tarea automáticamente. Casi no existen procesos manuales en Google.
Segundo, el sistema de integración, despliegue continuo y repositorio único (monorepo). Fue increíble ver a Google con miles de millones de líneas de código en un solo repositorio, todo compilándose y probándose de forma continua y automática. Esto significa que cualquier ingeniero puede reutilizar el código de otro sin tener que pedir permiso ni hacer nada especial; simplemente configuras la dependencia y todo compila y funciona. Google no tiene "código basura" en su base: todo compila, funciona, está documentado y probado. El código está escrito con un estándar excepcionalmente alto y es sencillo de leer y entender. (Compárese esto con el mundo bancario, donde es común encontrar sistemas en los que nadie tiene una comprensión real de cómo funcionan los componentes escritos hace años, ni idea de cómo eliminarlos o reemplazarlos).
Finalmente, cabe señalar que, a menudo, la tecnología desplegada en Google no es particularmente original en sí misma, sino que está ejecutada de forma excepcional en términos de velocidad, estabilidad y disponibilidad (pensemos en Gmail). Pero hacer cosas sencillas bien no es necesariamente fácil: un sistema como Gmail gestiona globalmente volúmenes enormes de correo electrónico y debe funcionar siempre de forma rápida y eficaz. Si pensamos en Gmail como un sistema transaccional, donde cada correo es una transacción, podemos empezar a ver cómo esto se solapa con la banca.
Aunque Google fue genial, quien es emprendedor lo es siempre, y una vez que mi "tiempo" terminó, me fui a finales de 2013. Como un segundo de cocina que ha aprendido en un gran restaurante, sentí que al dejar Google, me llevaba la receta para construir una gran empresa tecnológica. Y con esto en mente, fundé Thought Machine.
Construyendo el equipo
Mi máxima prioridad era crear un equipo de clase mundial y dotarlo de un espíritu de excelencia en ingeniería. La clave para lograrlo es tener una visión de empresa que haga que la gente quiera unirse. Esto es una combinación de un gran entorno de trabajo, un sector interesante, un mercado enorme y potencial de salida a bolsa. No iba a construir una empresa para una adquisición temprana de nuevo. Primero recurrí a antiguos colegas de los que sabía que tenían excelencia en ingeniería y que compartirían mis mismos objetivos empresariales. De esta manera, contraté a Fabian, Pebers y Will, todos provenientes de Google.
Eventualmente te quedas sin candidatos conocidos, así que contraté a un reclutador interno, Hung Lee, quien trabajaría a tiempo completo en la construcción del equipo. Se le ocurrió la idea de organizar un evento donde los candidatos pudieran venir, relacionarse con el equipo y yo pudiera dar una charla sobre la empresa. Fue un éxito instantáneo y hemos seguido contratando de esta manera desde entonces, con más de 1,000 candidatos asistiendo a los eventos de contratación de Thought Machine en los últimos 4 años.
Pensé que era más importante construir un gran equipo antes de decidir el problema exacto...
Eligiendo el problema
El área general era bastante sencilla: con Londres convirtiéndose rápidamente en la capital mundial de las fintech, era la elección obvia. Durante el primer año de Thought Machine, trabajamos con bancos en diversas áreas de las finanzas de consumo. El apetito de los bancos por hacer algo nuevo era evidente y no nos faltaban opciones. Pero estaba claro que la mayoría en el sector fintech operaba en la periferia, y esto se debía a que tocar el núcleo —la mítica plataforma bancaria central— se consideraba inalcanzable. Interconectar con los motores bancarios centrales era difícil, ya que a menudo habían sido construidos décadas atrás en Cobol y funcionaban en mainframes. Estaban muy lejos de una arquitectura de microservicios API alojada en la nube.
Vi el caso de negocio claramente cuando hablé con los bancos retadores (challenger banks). Les llevaría años construir sus propios sistemas bancarios, y comprar a terceros existentes era difícil y costoso, ya que ninguno utilizaba arquitecturas modernas. Había una necesidad clara, o un vacío, en el mercado.
Casi todo el mundo nos dijo que no hiciéramos esto: el núcleo bancario basado en mainframes es una constante; los bancos nunca cambiarían, el problema era demasiado difícil e intratable. Respecto a lo último (¿es difícil el núcleo bancario?), me negué a dar marcha atrás. ¿Por qué iba a ser tan difícil calcular pagos e intereses y registrar los resultados? ¡Y, por supuesto, que tanta gente te diga lo difícil que es solo anima a un ingeniero ambicioso!
Así que Will Montgomery y yo tuvimos una serie de largas charlas, y Will comenzó a construir lo que se convirtió en Vault Core. Después de unos meses teníamos algo y se lo presentamos a algunos bancos. La respuesta fue inmediatamente alentadora, lo que nos llevó a dedicar gradualmente toda la empresa a este producto a lo largo de 2016. A medida que construíamos más y más, el interés comercial creció rápidamente, y entonces vimos que la oportunidad era mucho mayor de lo que habíamos previsto originalmente: no solo construiríamos un motor bancario central en la nube, sino, de hecho, un banco minorista completo, con sistemas de tesorería, informes financieros, CRM, toma de decisiones sobre riesgos crediticios y docenas de otros componentes.
Si uno quisiera ser crítico, podría decir que no hay nada particularmente mágico u original en lo que hacemos; simplemente estamos aplicando las mejores prácticas de la computación en la nube ágil al problema de la banca minorista. Pero ese es precisamente el punto: tienes que empezar con la mentalidad de la computación en la nube y construir el sistema específico desde cero, manteniéndote fiel a esa metodología. No puedes evolucionar desde la forma en que la industria bancaria ha estado operando durante décadas.
Y esa es la historia de cómo pasé de la tecnología de conversión de texto a voz a las plataformas bancarias en la nube.
