Riccardo Vitale

While at Google I worked on a big project involving several people and teams in London, New York, and Mountain View. The project was to adapt the Text-to-Speech system at the time under development into other European languages. We started developing a system for the initial data collection of the required data for the training. We did so by creating a data pipeline that would automatically get all the samples collected from the BigTables into an aggregation pipeline written in Python. This system would clean all the data and produce a training set for the voice training.

Under the linguistics point of view, we worked hard on adapting the engine to support each language's unique features around text normalization, syllabification and verbalization. All these efforts produced noticeable results in the quality of the voice and in the overall rating metrics.

In Thought Machine we wanted to provide next level banking experience by providing an insightful look at the user's personal finance. One of the features we wanted to launch was the possibility to look at one's personal expense categories. We developed a classification engine through Python and the scientific stack (Numpy, Scipy, Scikit-Learn, Pandas) to account for this. We started with a simple Naive Bayes classifier (bag of words model), and the results were already encouraging, but we kept exploring other algorithms too: SVM, Logistic Regression, Random Forest.

Eventually we utilized an ensemble of these models to benefit from the better accuracy of the classifiers in some categories (i.e. the Naive Bayes classifier would be better at classifying transactions of category X vs Logistic Regression which would be better at classifying Y).

This component was the core for other bits of ML insights we provided, such as intelligent alerts on spending, cash flow prediction, user clustering, and so on.

One of my responsibilities in Skimlinks was to launch the data collection for one of our main products, Skimwords, which used NLP to recognize products in a page and drive content monetization. This process was very error prone, slow and quite manual. Ideally it would have had to be launched every day but the process itself was taking ~32 hours to process ~30 million items.

I improved the existing process, written in Python, to a more structured and tested component. After the overall execution was more reliable, I introduced parallelization in the data collection component, which would make use of multiprocessing in order to overcome Python's natural issues with multithreading. This brought down the running time while allowing to add more product feeds into the system, thanks to the gain in execution speed. The total running time was brought down to ~12 hours for ~40 million items.

This was the hard limit for how the component was designed in terms of tech stack. So, for the next iteration, I started working on a complete rewrite of the tool in Go, to exploit the excellent parallelization paradigm it offers. Rewriting the component brought down the execution time to ~8 hours for ~60 million items