A Topic Modeling using LDA on the White Paper on Artificial Intelligence: a European approach to excellence and trust

This month the European Union Commission released a White Paper from called “White Paper on Artificial Intelligence: a European approach to excellence and trust”. The idea of this white paper was to establish the guidelines for the EU regarding Artificial Intelligence (AI).

For those who don’t know the report recognizes that the EU is now behind the USA and China when we discuss AI systems and user data, and the document tries to give some perspectives in the usage of AI in industrial data, where the EU has a great advantage in comparison with those regions.

I won’t discuss the political aspects of the document, but there are some good summaries like this one from Covington Digital Health and this one also from them.

I’ve read the report and at least for me was very disappointing, especially due to the fact that state members from the EU contain far better initiatives.

The reason that I found the report disappointing it’s because the EU Commission instead to look the best of some local initiatives like Finland (that made a very deep report that talks about AI in business, self-regulation and capturing values like moral, ethics and policies as north star); or Estonia (that contains an ambitious plan to implement most of the initiatives in public sector to increase their efficiency and give a proper return to the taxpayers) the Commission just put trigger/effect words regarding only risks and regulation as we’ll see below.

On top of that, considering the importance of AI in nowadays and the problems and endeavors that EU will face in a foreseeable future (e.g. aging population and the economic and social impacts, a challenging economic environment with central banks delaying financial crisis via Quantitative Easingan open tariff warbetween two of biggest players, and so on) the report takes in consideration too much focus in privacy and risks with almost no mention in innovation, usage in public sector or even in potentialities of AI. 

The report speaks for itself, but my point here it’s just to bring some charts and some analysis over the text contained in the report. 

First of all, let’s check as usual the most common words in the report:

As expected, the word {data} is the top 1 (sorry, but there’s no AI without data). Along the patch we have some interesting sequence {eu, systems, risks} that I consider that is the drivers of all report (I’ve read the full report).

Using a simple vanilla Word Cloud, we have:

Again, as we can see the words with more frequency in the report were {eu, ai, data, system, risk}. 

But as I told before I really dislike Word Clouds and other kinds of word frequencies, so I decided to use a TF-IDF through all document to check the real importance of each word inside of the document. For a matter of simplicity, I took only the top 30 terms. 

As expected we have the same words in top {ai, data, systems, risks} but we have some notable mentions like: a) the world {regulatory} in front of {human}; b) the word {commission} in front of {citizens} and {innovation} and c) the word {digital} out of top 10.

But spare words can be misleading in some instance, so let’s take a look in the most frequent word bigrams contained in the report:

In the top 3, we have {ai, systems}, {ai, applications} and {use, ai} that are the drivers of the report. Not a surprising result. After those word n-grams we have some interesting combinations like {fundamental,  rights}, {regulatory,  framework} and {personal, data}. 

Let’s take a look in the trigram compositions:

If the bigrams takes a history about regulatory framework over AI systems, the 3 grams gives a clearer history about the major points of the report that are: i) {highrisk, ai, applications}, ii) {remote, biometric, identification} and } iii) {regulatory, biometric, ai}.

Using a simple LDA analysis in 7 arbitrarily chosen topics, we had the following topics and those main with their Intertopic Distance Map:

Topics found via LDA:

Topic #1:

{europe, ensure, assessment, law, economic, member, conformity}

Topic #2:

{systems, requirements, safety, product, existing, information, ensuring}

Topic #3:

{ai, data, use, applications, legal, national, highrisk}

Topic #4:

{risks, products, services, public, certain, authorities, enforcement}

Topic #5:

{eu, ai, commission, european, rules, framework, including}

Topic #6:

{rights, protection, system, relevant, particular, citizens, eg}

Topic #7:

{legislation, ai, liability, digital, need, set, paper}


Today was a short one because I have as the main principle to not talk about politics due to personal reasons, but I believe that with those graphs anyone can at least guess the tonic of the words in the report.

As usual we have all code and data in the repo.

PS: Those are my personal views and this post doesn’t represent anyone else than me. I do not endorse any kind of political affiliation, candidate, or even any kind of political association inside of traditional frameworks. 

A Topic Modeling using LDA on the White Paper on Artificial Intelligence: a European approach to excellence and trust

A small journey in the valley of Natural Language Processing and Text Pre-Processing for German language

Originally posted in MyHammer blog.

TL;DR: If you find yourself in the same situation what I was (i.e. millions of records with labeling problems, no fluency in the language, 200+ classes to predict and all of this in a very specific business segment) invest the maximum amount of time in text pre-processing, generation of word embeddings, and using some language rules/heuristics to refine your corpora.

Warning: Very long post with tons of references. Will take at least 40 min of reading.

A small journey in the German language for Pre-Processing in NLP

This is a summary of a talk that I was to give in Data Council in Berlin last year, but I rather gave a broader one called Low Hanging Fruit Projects in Machine Learning. This post will expand some points of the bullet points that I prepared for this presentation. If you saw my talk about LHF Projects, some of the content will be kind of familiar to you.

Disclaimer Project Report: This is only a project report with additional personal views and experiences, i.e. this is not a post in Towards Data Science, Keynote in O’Reilly Strata conference, best practices talk, Top-10-rule-list-that-you-must-do, Cautionary Tale, cognitive linguistics, applied linguistics, computational linguistics or any other kind of science at all.


With all this hype about language models like BERT, GPT-2, RoBERTa, and others, there is no doubt that NLP is one of the hottest topics nowadays.

NLP is in the center of countless discussions today like for instance, the “dangerous” GPT-2. OpenAI said that it would be dangerous to society and did not report the weights. And that a few months later some good developers managed to replicate all the code and afterwards everyone saw that was a good model that sometimes generates very brittle results.

Debates aside, one positive point today is that there are countless resources that brings the state of the art mixed with everyday applications, for example, like this NLP e-mail list provided by Sebastian Ruder.

However, what I am going to put in the following lines are some small aspects of NLP for the German language regarding the pre-processing part for a text project.

I will put some basic aspects of our journey and some more project-level considerations that deal with natural language processing, where I will try to compile our journey and some other features that I saw during that time.

Los geht’s?

German Language: Respecting the unknown unknowns

A hard lesson that I got during this time was: Language is extremely hard! No Deep Neural Network architecture will rescue you out, no AutoML will solve your problem, no big pre-trained model will be useful unless you do a proper text pre-processing.

If I could choose a single piece of advice of this very long note, probably those following mottos would be the ones for that:

Original Saying:

“ Give me six hours to chop down a tree and I will spend the first four sharpening the ax.” (Abraham Lincoln)

Machine Learning Saying:

“ Give me six hours to deliver a Machine Learning Model and I will spend the first four doing Feature Engineering.”

German NLP Saying:

“ Give me six hours to deliver a German NLP Model and I will spend the first five hours and thirty minutes doing text pre-processing.”:

As a few know, I wasn’t born or raised in any German-speaking country; and this already places a very big initial barrier on some aspects of language such as its nuances and even the understanding of trivial issues such as grammatical structure.

And here, I already put the first tip: If you are not a native speaker of the language, I suggest an understanding of at least an A2 equivalent certificate so that you have an understanding of the basic grammatical structure of the language before dealing directly with that language.

German, unlike my mother (Brazilian Portuguese), has a very different sentence structure in which Portuguese has the SVO (Subject-Verb-Object) structure, and in the German language, this rule is not so common, like for instance, the verbs can be at the end of a sentence.

It may seem small, but for example, for a Portuguese speaker, a negative answer or even a verb action is indicated in the first words of a sentence, not in the end. It forces us to an extra mental load to read the sentence until the end and then have the right context what’s going in the sentence.

In German, this rule is not necessarily true with the disadvantage that as a literate person in Brazilian Portuguese, I have to literally read the sentence completely, do the translation work in order to understand the sentence.

One factor that helped me a lot in that matter was, that since I was dealing with simple service request texts on an internet platform, this somewhat eased things because the textual structure is quite similar when someone wants certain types of services.

In other words, my corpora would be very restricted and would need a very large degree of specialization but in a single domain with a singular corpus.

If it were a type of text that required a very high degree of specialization as a constitutional, legal, or scientific text, in this case, I would have to go a little beyond A2 just as an initial prerequisite.

Obviously, this is not a mandatory requirement, but I see that understanding the language represents 20% + performance of your model that you have only by understanding what makes sense or not in a sentence or even in the form of preprocessing.

Here is the simple tip: Respect the complexities of language, and if the language is one that you are not native respect more and try to understand its structures first before the first line of code. I will explore the language a bit more in a few topics later in this post.

First, let’s take a look at the MyHammer case.

Context: Classification as a triage for a better match between tradesman and consumers

For those who don’t know, MyHammer is a marketplace that unites between Craftsman and consumer that needs some home services with the best quality.

Our main objective is defined by Craftsman receiving relevant jobs to work on and consumers placing jobs that need to be done and receiving good offers for high-quality services.  

To reach that goal, we need to deliver the most suitable job for each craftsman considering their skills, availability, relevance, and potential interestingness in terms of economics.

Our Text Classification project enters in that equation for re-label some jobs that are in different categories inside our platform and help those matches happen. 

In summary, our data hold the following characteristics: 

  • 200+ classes
  • Overlap of keywords between several classes
  • Past data mislabel, and as we created new classes, we didn’t correct the past (this phenomena I call as “Class Drift
  • Tons of abbreviations
  • Hierarchical Data (Taxonomy)  in terms of Business but not related at all in terms of language semantics
  • A lot of classes with 1000+ words per record
  • Dominance of imbalanced data (Top 10 categories have 26% of all data, Bottom 100 has less than 10%)
  • Miscellaneous classes that englobe several categories, and with that arising the entropy interclass

With this scenario, we made the first hard decision about the project that was to invest at least 95% of our time in understanding the language across each class and building a strong pre-processing pipeline. 

In other words: If we understand well our language inside our corpora, we can leverage that even using plain vanilla models to our advantage.

With that in mind, we jump to understand better our language instead of starting to use algorithms and hoping for some very complex algorithm to work. 

Language is Hard

Language is not hard. Language is very hardI don’t want to enter much in details around some hype about it  and the brittleness of the State of the art. 

But personally speaking I strongly believe that we’re far away even to be near to solve that kind of problem that involves language in terms of conversation or even for machines to generate texts sufficiently good enough to pass in a simple essay. 

Language contains tons of aspects and complexities that makes everything hard. In this very good post of Monkeylearn are described some of those complexities like:

polysemy: words that have several meanings

synonymy: different words that have similar meanings

ambiguity: statement or resolution is not explicitly defined, making several interpretations plausible.

phonology: systematic organization of sounds in spoken languages and signs in sign languages

morphology: study of the internal structure of words and forms a core part of linguistic study today.

syntax: Set of rules, principles, and processes that govern the sentence structure in a given language

semantics:  study of meaning in language that is concerned with the relationship between signifiers—like words, phrases, signs, and symbols—and what they stand for in reality, their denotation.

To understand in depth, one of these aspects in depth would demand at least a master’s degree in full time, at least.

The point that I would like to make here is that knowing those aspects and understand that language is hard.

From the beginning, our strategy was to start some statistical approach first to prune out non-relevant words in our corpora. After the heavy-lift work has been done, we would jump to the language/symbolic approach to fine-tune the corpora before going to train models to get a more safe side in terms of NLP modeling. 

Symbolic or statistical, what’s the best approach?

There’s a huge discussion about Symbolic versus Statistical approaches for language occurring nowadays.

Some proponents about the Statistical as a main paradigm are  Yann LeCun and Yoshua Bengio, and on the other side of the debate, it’s Gary Marcus. There are some resources available and some debates about that like this one between LeCun and Marcus  and this thread about it.

For practitioners that are daily in the trenches I would suggest pragmatism and use all tools and methods that solve your problem in an efficient and scalable way.

Here at MyHammer, I adopted a statistical approach for heavy lift work and some language ruling for tuning. Here the quotes from Lexalytics that I like about it: 

[…]The good point about statistical methods is that you can do a lot with a little. So if you want to build a NLP application, you may want to start with this family of methods[…]

[…]Statistical approaches have their limitations. When the era of HMM-based PoS taggers started, performances were around 95%. Well, it seems a very good result, an error rate of 5% seems acceptable. Maybe, but if you consider sentences of 20 words on average, 5% means that each sentence will have a word mislabeled […]

Source: Machine Learning Micromodels: More Data is Not Always Better

Yoav Goldberg in the SpaCy IRL Conference gave a great talk called “The missing elements in NLP”  where I think he excelled in say that as we move from a more linguistics expertise to a more Deep Learning approach to model NLP, we’re going in a path to have less debuggability and a more black-box approach. We can see better this in the following slide:

NLP Tomorrow

After that, I took a very hard decision to stay in some tool for training the Text Classification model that can provide me a certain minimum level of debuggability and transparency. That’s why in the beginning I choose Facebook FastText.

I know that FastText deals with neural networks internally, but as FastText relies a lot on the WordNGrams if I needed to debug some result or convergence problem in the classes I could use simple data analysis to explain why we’re getting some rogue results.

The strategy here was: Let’s do a very extreme pre-processing approach in our corpora to get the leanest corpora as we can, and after this optimization, we can play with different models and see what’s going on.

To exemplify that this figure from Kavita Ganesan explains our point:

Level of Text preprocessing. Source: All you need to know about text pre-processing for NLP and Machine Learning.  https://www.freecodecamp.org/news/all-you-need-to-know-about-text-preprocessing-for-nlp-and-machine-learning-bc1c5765ff67/

Some specifics in Pre-Processing for the German language

Umlauts (ä, ö and ü)  and Encoding

Long German Nouns

As we know that these long nouns can appear according to the situation inside of class our strategy was to analyze the WordNGrams and TF-IDF scores and see the relevance of these words. If word is relevant we did use some rules to break down those words and keep it, if not, remove of the vocabulary.

Part-of-Speech Tagging

  • We used  Part-of-Speech tagging to remove some words of our corpora. Our strategy consisted in a) always keep the verbs, b) placeholder usage to abstract data entities inside our text (ex: In our domain we use placeholders like sqm (square meters) and this placeholder gives some information gain in all particular classes that contains this word; c) as pronouns and conjunctions in our case most of the time do not contains any meaningful info we did cut it out.

For whom is interested in some examples, this table from NLTK is a good start:

German examples. Source: NLTK Universal Part-of-Speech Tagset

Stopwords: Analyze first, cut after…

One of the biggest endeavors in the project was to find a very nice library with consolidated German corpora in a word where the majority of the implementations and SOTA algorithms it’s crafted to English and first citizen language.

(Short Note: this blog post was written in July/2019. During this time we had a great evolution of NLP libraries in German. However, as we consolidate all ideas contained here in our own NLP library we decided not be dependent of those libraries anymore.)

As our task was only a multi-label text classification and we had a good amount of data, we decided to perform an extreme cut out of stopwords because as we’re not going to do any posterior application that heavily relied upon sequence like LSTM or seq2seq, we wouldn’t need to”save words” for our classifier. This gave us more room to use a very unorthodox approach.  

In the work of Silva e Ribeiro called “ The importance of stop word removal on recall values in text categorization“,  the authors showed a positive relation between stopword removal and recall, and we follow that methodology in our work. 

If I could give a specific advice in that matter I would suggest using only out-of-the-box stopwords lists from those packages only if you don’t have time at all to perform analysis in your corpora. Otherwise, always perform the analysis and create your personalized list.

To make my point clear about this matter, I’ll use the example from Chris Diehl.

Chris Diehl in his post called  “Social Signaling and Language Use” provided a linguistic analysis in an e-mail from a company called Enron. This company was involved in a gigantic case of finance/corporate fraud and the whole story it’s described in the documentary “Enron: The Smartest Guys of the Room”.

The analysis consisted of discovering if there’s an existence of a manager-subordinate social relationship.

The original e-mail is presented below:

Doing a skim read, we can see that there’s a clear social relationship that characterizes a subordination. However, if we give this same text to a regular stopwords package, this will be the outcome:

As Chris Diehl pointed out, the terms that matter in this message are function words, not content words. In other words, the removal of these words could mischaracterize the whole message and meaning. For more, I suggest the reading of the entire article written by Chris. 

A great post about the differences in stopwords across several open source packages was made by Gosia Adamczyk in the post called Common pitfalls with the preprocessing of German text for NLP where she showed some differences between those packages.

Source: Common pitfalls with the preprocessing of German text for NLP, Gosia Adamczyk 

The key takeaway that we got here was: Trust in the stopwords from packages but check and if it’s necessary to mix all of them and use some information about your domain to enhance it.

Stopwords as Hyperparameters

In our project, as we’re started to go deeper into our corpora, we discovered very quickly that the normal list of stopwords not only was not suitable for us, but we needed to consolidate the maximum of them to remove from our corpora.

This was necessary because as we’re dealing with such amount of text, we wished to reduce the maximum amount of training time, and having lean corpora was mandatory to deal with that.

The main problem that I see in the current stopwords lists is that it is built on the top of tons of texts that it’s suitable for general purposes (e.g. German Senate corpora, Wikipedia Dump, etc.) but when we need to go in specific domains like Craftsmanship, the coverage of those stopwords lists wasn’t enough and not knowing that caused us a huge source of inefficiency.  I talk about this later on in how the German city names almost broke our classifier.

We followed a strategy to analyze the results and if we noticed some improvement and in the model performance or in gains in processing time, we add more stopwords in the list. Roughly speaking it was kind of “stopwords list as hyperparameters

This example from Lousy Linguist translates my point:

Source: https://twitter.com/lousylinguist/status/1068285983483822085

A single example that occurred to us in how a lack of personalized stopwords list almost broke our classifier.

In some point of time our models started to give very strange results when we received in the text the name Hamburg or München. Basically everytime that a model received those words, the model always gave a single service as a prediction. In other words, it was a clear case of overfitting.

Long story make short: We discovered that when the customers placed a service request for our Craftsman with those two cities in the text, our classifier always returned the same class, no matter if there’s another subset of words contained in the request (i.e. it makes totally sense since when someone needs to move most of the time the cites are placed).

A single example to illustrate that:

  • I would like to move my piano from Hamburg to Köln (Moving service)
  • I would like to paint my apartment. I’m located in downtown Hamburg. (Painting service)

The problem was that for the second case we always ended with the Moving Service classification.

The solution here was to debug the model analyzing the WordNGrams composition for this service, including the cities as stopwords and after that everything worked well. 

There’s no exhaustive list, but if I can to give some hints, I would classify the stopwords lists like this:

  • German states and citiesbayern, baden-württemberg, nordrhein-westfalen, hessen, sachsen, niedersachsen, rheinland-pfalz, thüringen
  • W-Fragewer, was, wann, wo, warum, wie, wozu
  • Pronounsdas, dein, deine, der, dich, die, diese, diesem, diesen, dieser, dieses, dir, du, er, es, euch, eur, eure, ich, ihm, ihn, ihnen, ihr, ihre, mein, meine, meinem, meinen, meiner, meines, mich, mir, sie, uns, unser, unsere, unserem, unseren, unserer, unseres, wir
  • Numbersnull, eins, zwei, drei, vier, fünf, sechs, sieben, acht, neun, zehn, elf, zwölf
  • Ordinalserste, zweite, dritte, vierte, fünfte, sechste, siebte, achte, neunte, zehnte, elfte, zwölfte, dreizehnte
  • Greetingsciao, hallo, bis, später, guten, tag, tschüss, wiederhören, wiedersehen, wochenende, hallo
  • Clarification wordsdass, dafür, daher, dabei, ab, zb, usw, schon, sowie, sowieso, seit, bereits, hierfür, oft, mehr, na

Some lessons along the way…

We had some lessons along the way for our case. The point here is not to define any truths but only exemplify that during the process of data analysis and perform experimentations with our dataset we found something totally different from what we hear about NLP and text pre-processing.

I divide those sections between what did work and what didn’t work.

What didn’t work
  • Lemmatization: Here I think it was the most surprising takeaway. Using Lemmatization as a common  “best” practice, we had 3% decrease in the accuracy in Top@5. The reason behind that was because some categories have some specific subset of words that makes them distinguishable and the Lemmatization was causing an involuntary category binning“. For example, We have some services that despite to have some similarity words in our corpora like  Wunschlackierung (Desired painting), Lackaufbereitung (paint preparation), Unfallreparaturen (accident repairs) and Kratzer im Lack (scratches in the paint); the Lemmatization caused a great loss in the distinguishable aspects of the corpora of a class and as consequence, we faced a harm in the algorithm performance. To solve this problem, we removed the Lemmatization of our pre-processing pipeline.
  • Lemmatization was too slow for our data: Another point that was a deal-breaker is that Lemmatization, even using a very good API as Spicy, took ages for our data in the beginning. Our dataset contains millions of records with text fields that contain dozens or hundreds of words for each line. Even using a 128 CPUs machine took a long time, and as we got this decrease in the model performance, we abandoned that approach. [Note: In the beginning, we used a previous version of spaCy that didn’t contain several improvements in comparison with the current version] 
  • Hyperparametrization of FastText: on the start of this project, we relied a lot in FastText, and we didn’t regret of that. But a huge limiting factor is that FastText has only a few number of meaningful parameters to use as hyperparameters, and here I’m specifically talking about the parameters  Window Size and Dimension that in our data  didn’t show any sign to be meaningful and/or useful in some strategy of grid-search or tuning. 
  • Spark for data pipeline and model building and training: Spark is a cool tool for Data Processing and I really like it, but for NLP all integrations that uses native Scala didn’t provide a minimum in terms of libraries, flexibility and easiness to use for us to rely upon for text pre-processing in German language. I personally think that text processing using linguistic features is one of the weakest points in Spark libraries. We’re still using it, but only for data aggregation and to dump from one place to another.
What worked
  • Own library of Pre-Processing and  Personalized list of Stopwords: This can sound a bit as over-engineering, but this was the only way for us to get the maximum of flexibility for our needs. We just unite all the best of all tools for German NLP like stopwords list, stemming, PoS and so on and craft something that can save us tons of time.
  • Hierarchical Models: This one deserves a special blog post, but for us using the natural ontology of the classes helped a lot in terms of accuracy in Top@5 because using a quasi segmented architecture for our models we naturally prune out the clashes between classes non related but that contains some words in common.
  • Using EDA + TF-IDF score to remove low frequent words: We learned that, for our case, removing low TF-IDF score words helped a lot in terms of experimentation without sacrificing performance. In the beginning, I just create a full list of TF-IDF and as I’ve included more words, I just monitor the performance to see if there’s some loss. My heuristic was: Get the minimum amount of words as possible with a tolerance of model performance in no more than 1%. This can look quite hard metric but at least in the beginning I was more concerned to have very lean corpora instead to have a good performance and a model more complex and brittle.
  • The oldie but Goldie Regex: This worked way better than Lambda and map() in Python for word replacement. The takeaway here is to use lambda and map only if it’s really necessary. 
  • Word Embeddings: We didn’t use embeddings before to force us to stress all possibilities with our corpora and hyperparameters. However, the loss in performance that I had with the removal of low IDF score words and using a personalized list of stopwords, I gained back just plugging embeddings in the model using FastText.

The key takeaway that we took was: Use the best practices as a start point but always check some alternatives because our data can have some specificities that can generate better results.

Final Remarks

If I have to do a wrap-up of all of these things, I would highlight as the main ones:

  1. Recognize your own language and jargon: For us understand that we’re dealing, i.e. web-based texts in the context of Craftsmanship and their language helped us to perform a better pre-processing that enhanced our models;
  2. Make your own corpus/vocabulary/embeddings: Out of the box stopwords lists and common text pre-processing helped a lot but in the end of the day we needed to create our own stopwords list and we used some low TF-IDF score stopwords list to prune out unnecessary words and reduce our corpora and consequently reducing the training time
  3. Do not automate misleading data: In our case one of the capital mistakes in the beginning was to try to automate the data pipeline and cleaning without considering some specifications of our case like jargon and abbreviations. It means: In Text Classification data pre-processing is gold, models are silver. 

Libraries for German NLP

  • German_stopwords: Last commit 3yo, but contains a good set of loosen words and abbreviations  
  • DEMorphy: morphological analyzer for German language (several types of Tagset for dictionary filtering)
  • textblob-de by markuskiller: PoS
  • GermaLemma: First one that uses PoS before Lemma (Spacy will do that out of the box in next version)* tmtoolkit: Wrapper with PoS, Lemmatization and Stemming for German. Good for EDA with Latent Dirichlet Allocation.
  • NLTK: There’s a small trick to use PoS with German
  • StanfordNLP: (for future test)
  • SpaCy: NLP with batteries included (syntactic dependency parsing, named entity recognition, PoS)
  • Python Stopwords: Generic compilation of several Stopwords 


Useful Links
A small journey in the valley of Natural Language Processing and Text Pre-Processing for German language

Por que acredito que no Brasil estamos entrando em uma bolha de Data Science?

TL;DR: Faça uma avaliação racional e pragmática baseada em fatos e informações de mercado antes de escolher uma mudança de carreira ou até mesmo alternativas de investimento em qualificações em Data Science & Machine Learning. 

Eu sei que nos dias de hoje o que eu estou falando pode parecer ser contraintuitivo, ao mesmo tempo que temos empresas anunciando que vão contratar 100 cientistas de dados em um único ano (mesmo sem nenhuma justificativa sólida do porque e principalmente do retorno esperado com essas contratações), ou quando o volume de buscas em “ciência de dados” aumenta em mais de 50% em menos de 3 anos, ou em uma busca simples podemos encontrar mais de 1.500 vagas disponíveis no LinkedIn.

Claro que a minha opinião não é a mais popular atualmente, mas o que eu vejo hoje são os mesmos padrões das bolhas passadas em tecnologia no Brasil.

Quem não se lembra da bolha de Certificações Microsoft? (alguém lembra do famigerado programa Maestro de SQL Server?)

Ou da bolha de certificações Oracle?

Do cursos da dobradinha campeã PHP e MySQL que prometiam os maiores salários do mercado?

Ou das promessas do eldorado de salários e empregabilidade como Web Designer com os cursos de Corel Draw, Dreamweaver e Flash?

E os cursos de frameworks ITIL, COBIT, TOGAF ou BABOK que nos prometiam cargos maravilhosos apenas gerenciando processos de negócios? (Sendo que muita faculdade e cursos livres igualmente picaretas ao invés de ensinarem o básico de código, jogaram uma geração inteira de universitários em frameworks de “gestão” sendo que parte deles não conseguem gerenciar nem mesmo a própria vida financeira).

Tudo o que eu vou colocar aqui diz respeito ao lado da oferta de cientistas de dados, e não da demanda propriamente dita (i.e. isso merece um post especial, mas na prática pouquíssimas empresas sabem o que estão contratando e tem uma galera contratando somente para sinalização). 

Desta forma este post vai ser muito mais voltado para gestão de carreira do que para um retrato de mercado. 

Longe de ser algum tipo de coach ou algo do semelhante, o meu objetivo vai ser convidar o leitor para uma reflexão sobre alguns aspectos que eu julgo como importantes de acordo com algumas observações que eu tenho feito no mercado como um todo de forma empírica.

Alguns aspectos que sinalizam que talvez estamos em uma bolha de Data Science e Machine Learning na minha visão são:

1) O Retorno do Investimento (ROI) em uma formação em DS em relação aos salários não compensa: Eu vou tirar desta análise os MOOCs e cursos sensacionais como o da Fast.ai do Jeremy Howard por um motivo muito simples: Nós no Brasil adoramos um diploma e o nosso sistema educacional foi moldado de uma forma que não promove o autodidatismo, mas promove um modelo baseado em tutoria em que o professor não é um facilitador mas é o responsável e guardião do  conhecimento em si. O que eu quero dizer é que esta análise do ROI vale exclusivamente para cursos de pós-graduação e cursos de extensão. Eu fiz uma pequena pesquisa em alguns cursos e existem algumas formações que custam mais de R$ 30.000. Nada contra o valor em si, porém, vamos falar que o retorno esperado deste investimento seja de 4 anos. Isso dá R$ 625/mês por 4 anos. Em outras palavras: desde o dia em que o curso termina, o nosso recém-formado já precisa de um aumento de pouco mais de R$ 600 só para ficar no empate em relação a sua formação. Ah, e lógico fora o custo de oportunidade do tempo (e.g. tempo de aula, deslocamento, alimentação, etc) e o custo de oportunidade do dinheiro (e.g. usar esse dinheiro em algum investimento, fundo de ações, etc). Tendo em vista uma recessão brutal que tivemos nos últimos anos (e com a renda praticamente estagnada) eu consideraria muito bem uma decisão de investimento (ou endividamento) desde porte sem uma perspectiva de retorno de no mínimo de 2 anos.

2) O mercado está cada vez mais competitivo e a barreira de entrada está quase nula e ao mesmo tempo que isso é bom, isso pode ser um problema. Se eu tivesse que descrever o mercado a frase que mais se assemelha de como eu vejo é Bellum omnium contra omnes, ou guerra de todos contra todos. Se você é Cientista da Computação, você vai competir com Econometristas que sabem mais de modelagem do que você; se você é Estatístico vai competir com Cientistas da Computação que codam mais que você; se você é Econometrista vai competir com Estatísticos que dominam um ferramental matemático/estatístico melhor do que o seu, e todos eles vão competir com pessoas com mestrado e doutorado. O ponto aqui é que a competição vai ficar cada vez mais brutal e isto no longo prazo não é escalável em termos de carreira dado que são disciplinas que demandam tempo para o aprendizado.

3) Assim que o mercado começar a ter a desilusão com contratações erradas e as frustrações corporativas com os cientistas de dados começarem, os processos seletivos vão ficar mais acirrados e não haverá bons espaços para todos. Uma coisa que eu aprendi como contratante em um período da minha carreira foi: A cada decepção devido a uma contratação errada duas medidas brutais entravam em cena: a) os requerimentos, testes e as exigências aumentam muito mais e b)  salário aumentava em proporção dado que a exigência seria a maior caso o candidato fosse aprovado. O que eu quero dizer aqui é que as posições vão começar a sofrer uma escalada insana de habilidades para as melhores posições e o mercado vai ser dividido em “posições boas” e “posições ruins”. Em outras palavras: entrar como Data Scientist ganhando abaixo do mercado só fazendo consulta em SQL e mexendo em macro no Excel é fácil, o difícil é ir para a tigela dos altos salários e usar ferramental moderno para resolução de problemas difíceis.

4) A enxurrada de gente sem a mínima ideia do que é Ciência ou Dados entrando na área: Pensa bem, neste exato momento milhares de pessoas estão entrando no campo sem nenhum tipo de ideia do mercado por conta de hype, influencers, mídia e outras fontes que prometem o eldorado dos altos salários ou descrevem Data Science como a profissão mais sexy do século 21. Isto não é escalável e uma hora grande parte dessas pessoas que estão se aventurando vão ter uma desilusão muito grande dado os motivos no item 3) ou mesmo quando as empresas darem conta que o maluco do Excel que está a milhares de anos da empresa manja mais do negócio e dos números do que toda a galera que fica fazendo script copiado do Towards Data Science no Macbook Pro de retina display com sticker de conferência gringa.

5) Vocês acham mesmo que repentinamente todas as empresas do sistema solar nunca ouviram falar de análise de dados básica ou estatística básica? Que somente agora elas acordaram de um torpor dos últimos 25 anos e elas decidiram que precisam de unicórnios mandados dos céus para salvar as empresas da falência através de insights gerados dos dados? Com ou sem cientistas de dados todos os dias no sistema solar negócios são fechados, vendas são feitas, pessoas compram coisas, e o dinheiro circula de uma mão para a outra.

Mas vamos supor que você me veja como um vendido ou uma pessoa com interesses ocultos por conta do que eu disse. Dessa forma, não acredite em mim, mas sim nas pessoas e instituições atores abaixo; eles sim sabem o que é melhor para a sua carreira:

a) Universidades e alguns professores de cursos de extensão e pós-graduação: Se a sua principal fonte de receita dependesse de um maior volume de alunos possível ou se a sua instituição servisse como o proxy predileto para contratação, você anunciaria que estamos em uma bolha educacional (onde já temos o incrível advento dos diplomas inúteis no Brasil) ou surfaria na onda e ofereceria cursos caça níquel que estão no mínimo 3 anos atrás do mercado? Uma coisa que eu vejo muito são instituições que estiveram dormindo por mais de 5 anos em relação a ciência de dados ou dados em geral que repentinamente abrem um curso de Data Science e Machine Learning com um corpo docente que nunca foi do mercado e com grades que não correspondem com a realidade do que está sendo feito nas empresas e nem cobrem aspectos básicos que todo cientista deveria saber. Novamente não precisam acreditar em mim: Vá nos cursos de extensão e pós-graduação e veja quais deles estão ensinando fundamentos de estatística básica, inferência causal, cálculo, álgebra, etc.

b) Mídia: Não se engane, por trás de todo anuncio de empresas contratando inúmeros cientistas de dados existe um submundo de matérias pagas para gerar algo chamado Brand Awareness. Inúmeras empresas usam a mídia para veicular matérias e “notícias” que favoreçam essas empresas (e.g. a revista faz uma matéria positiva sobre a empresa  A e meses depois uma empresa subsidiada da empresa A paga um anúncio de 300 mil reais para a mesma revista) para dar a percepção de que aquela empresa é legal e que faz coisas incríveis, quando na verdade está apenas vinculando a sua marca positivamente enquanto as vagas reais mesmo estão fechadas (isto quando estas vagas existem).

c) Papo de conferência: Eu como um bom rato de conferência tenho que dar o braço a torcer em que eu caí muito nisso no passado. Eu ia na conferência e deslumbrado com a tecnologia eu já fazia um plano de estudos para a nova ferramenta para Data Science ou Machine Learning. Você volta energizado da conferência para a sua empresa com a expectativa de implantar aqueles cases maravilhosos, mas na realidade você termina fechando ticket de tarefa sem sentido no JIRA.

d) Influencers, tecnologistas e afins: Estes adoram quando você fica mudando de tecnologias assim como muda de roupa por um motivo simples: isto dá mais views no youtube, mais comentários sobre o que está “trendando”, mais artigos em seus blogs no Medium, e mais do que isso: eles ganham credibilidade somente mostrando o que fazer e não fazendo algo corporativamente ou academicamente e pior – tudo isso sem nenhum tipo de risco envolvido caso o que eles recomendem de errado. Ciência e Engenharia são coisas que andam lentamente mas com passos firmes. Uma troca de tecnologia ou mesmo a adoção de novas ferramentas (ao menos em empresas sérias) é um processo que pode levar anos ou deve ter um motivo muito razoável para acontecer. Eu trabalhei em uma empresa que o software de fila só foi trocado depois de muitos problemas de instabilidade, e mesmo com um novo sistema o nosso “failback” ainda ficava nos velhos e sempre confiáveis arquivos texto. O ponto que eu quero deixar aqui é: ao ver influencers, tecnologistas e afins falando sobre novas ferramentas e frameworks que você precisa aprender, desconfie e entenda que as empresas não vão sair de tecnologias estabelecidas em que elas tem corpo de conhecimento e know-how para embarcar na sua aventura como Cientista de Dados “antenado” com o mercado. 

e) Amigos e colegas que já estão no mercado: Uma pequena parte desta galera nunca vai admitir que estão em uma bolha por um motivo simples: esta galera acredita realmente que são excelentes e merecedores de suas posições e salários nababescos. Entretanto, parte destes colegas esquecem dos fatores causais não identificados que os levaram a ter a posição que eles têm hoje. Por exemplo, pode ser tempo de casa, tempo na posição de DS antes do hype do mercado, track record na empresa não relacionado com DS, ou mesmo falta de alguém que tenha um conhecimento técnico mas que também conheça o negócio. E lógico não vamos esquecer que nós seres humanos somos ótimos em subestimar o papel do acaso e da sorte nas nossas vidas. No final do dia somos seres humanos e amamos uma narrativa romantizada da realidade. Agora cair na narrativa é questão de escolha.

Por fim eu quero colocar algumas mentiras que as pessoas contam sobre Data Science e Machine Learning:

As formações não estão caras: Parem pra pensar: uma formação não é somente o valor pago, mas sim o custo de oportunidade e mais o tempo que vai ser investido como eu coloquei anteriormente. Ciência de Dados hoje é uma área muito dinâmica que está mudando muito rápido. Ferramentas em menos de 1 ano ganham direcionamentos totalmente diferentes. Será que vale a pena investir 18 ou 36 meses pagando mais de R$ 1.500 em uma formação e ao final praticamente todos os frameworks ensinados já estão sendo descontinuados ou em outras versões? Tudo isso para que? Conseguir um emprego em uma vaga júnior ou no máximo ter R$ 350 de aumento sendo que você gastou R$ 40 mil em uma formação? Não parece um ROI ideal pra mim.

Há um déficit de cientistas de dados no mercado: Isto é parcialmente verdade. No caso, inúmeras empresas precisam modernizar a maneira com a qual elas fazem análise, dado que algumas ainda estão no paradigma descritivo ou diagnóstico e querem ir para a parte preditiva e prescritiva. Contudo, a não ser que você trabalhe em empresas que realmente estão usando os dados em seus produtos como por exemplo Nubank, Quinto Andar, Pipefy, Movile e etc, grande parte das empresas ainda precisam sair do excel e do combo “média-desvio-padrão-correlação-gráfico-de-pizza”. E não existe absolutamente nada de errado com isso. O ponto e o que o mercado pensa que um cientista de dados tem habilidades de Data Engineer, Data Scientist, Software Engineer, DBA, analista de requisitos tudo no mesmo papel. Então se você pensa que vai chegar na sua posição de Cientista de Dados fazendo análises  em dashboards como no Minority Report enquanto toma um delicioso vinho italiano enquanto escuta Toccata em Ré menor de Bach enquanto tem os seus insights, eu tenho uma péssima notícia: Isto não vai acontecer. No melhor dos casos você vai ficar brigando com DBA para ter acesso no banco de dados, vai encontrar muita defensividade de analistas que não tem um emprego tão sexy quanto o seu, e sem o conhecimento de negócio você vai ser sempre colocado de escanteio pela galera do Excel (esse relato antológico mostra bem isso).

Eu preciso ser Data Scientist para dar certo na vida: Existem muitas coisas bacanas em engenharia fora de Data Science que são tão importantes quanto como DevOps, Site Reliability Engineering, Front/Backend Engineering, Data Engineering, Automation, Incident Response, Mobile Development, Security, Infraestrutura, etc. E acredite são posições que pagam muito bem, exigem conhecimentos que são difíceis de serem adquiridos e sempre terá demanda e impactam diretamente no negócio.

Considerações Finais

Lendo esse relato que beira o pessimismo extremo alguns podem falar “mas poxa, então eu não devo ir para a área de Data Science?” a minha resposta e “vá, mas entenda os principais problemas da área e saiba que este não é o único caminho.Tenha em mente que frustrações de expectativas nos aspectos profissionais e financeiros podem ser uma realidade e poucas pessoas estão falando sobre isso”. Eu penso que sempre haverá espaço para bons profissionais, independente do que fazem e empresas boas sempre contratam pessoas boas mesmo se não tiver o budget, a vaga, ou mesmo a posição propriamente dita. Espero que esse pequeno relato tenha jogado um pouco de racionalidade e luz sobre a carreira em Data Science e sirva ao menos para uma reflexão.


[1] Este post foi descaradamente inspirado no relato de 2010 do Bolha Imobiliária de Brasília que viu o principal problema no seio da economia brasileira em relação à bolha de crédito.

[2] Este escriba recusa-se (ao menos aqui no blogue) a adotar o novo padrão de escrita da internet sentenças com no máximo 7 palavras muito simples. Como eu acredito que os leitores deste blogue são pessoas de capacidade cognitiva avançada, as sentenças vão ficar complexas. Reduzir a complexidade para uma linguagem que promove o emburrecimento dos leitores nunca foi e nunca será o foco aqui.

Por que acredito que no Brasil estamos entrando em uma bolha de Data Science?

Frutas no corredor e viés de disponibilidade em Sistemas de Recomendação

Como alguns dos meus 3 leitores sabem, eu venho fazendo alguns cursos totalmente fora da área de Data Science/Machine Learning como Investigação de Acidentes Aéreos, Medicina Baseada em Evidências, Econometria e Inferência Causal.

Eu vou escrever no futuro sobre o porque eu estou tomando esses cursos (motivo: porque penso estamos em uma bolha de DS/ML); mas o ponto que eu quero colocar aqui é que um dos princípios fundamentais de Medicina Baseada em Evidências está muito relacionado ao entendimento do nível de incerteza e como determinar um tratamento (e principalmente não tratar ninguém se o resultado for frágil).

No momento em que pensamos sistemas de recomendação, sempre imaginamos os cases de sucesso como Netflix, Spotify, Amazon entre outros, em que os sistemas de recomendação alavancaram essas empresas ao sucesso.

Porém, alguns aspectos causais e/ou ausência de entendimento dos fatores aleatórios geralmente não são muito discutidos de forma mais profunda. E esta ausência de discussão também é refletida em papers de conferências importantes como WWW, ACM RecSys e ICML, só para dar alguns exemplos em que tem muita coisa sobre resultados mas fala-se pouco de aspectos de incerteza que possam ter influenciado estes mesmos resultados.

Como consequência podemos ser influenciados a adotar uma postura voltada para os resultados desconsiderando o fato de que estes resultados podem ser fruto apenas do acaso e não de uma competência intrínseca do nosso trabalho.

Neste post eu vou falar especificamente de um fator de incerteza em Sistemas de Recomendação que é o viés de disponibilidade. Este é um problema real que pode acontecer em sistemas produção, em especial em protocolos de avaliação de modelos/sistemas. No final eu vou discutir uma alternativa que minimiza esse problema.

No entanto vamos entrar em uma situação hipotética para exemplificar esse ponto de uma maneira mais acessível.  

Ideias e frutas no corredor…

Imagine a seguinte cena dentro de um escritório: Existe dentro do escritório um corredor no qual as pessoas usam para locomover-se entre dois pontos. A titulo de simplicidade vamos dizer que este corredor é uma passagem comum como qualquer outra.

Um certo dia o time de Recursos Humanos observa um trabalho acadêmico que atesta uma correlação entre melhoria do ambiente de trabalho com o consumo de frutas.

Ato contínuo, após a leitura deste artigo o time do RH pensa em realizar a seguinte intervenção: “Porque não distribuir frutas aqui no escritório para aumentar a satisfação no trabalho?

Em seguida o time do RH pensa em uma forma de implementar esta intervenção: “Por que não deixar algumas frutas disponíveis em um lugar em que todas as pessoas podem ter acesso? Desta forma todos podem passar e pegar a fruta que quiserem”.

Sendo assim o time do RH coloca uma bandeja de frutas diversas no corredor deixando as frutas acessíveis para todas as pessoas de forma livre.

A ideia é a seguinte: A frutas ficarão disponíveis por 3 semanas no corredor. Após este período uma pesquisa de satisfação será realizada para mensurar o nível de bem-estar no trabalho e o efeito dessa nova política de RH dentro da empresa.  

Mensuração e descoberta de ótimos resultados

Três semanas depois o time do RH realiza a pesquisa de satisfação e o resultado foi um aumento de 70% na satisfação dos empregados, afinal de contas, quem não gosta de fruta de graça no trabalho?

Com este ótimo resultado o time do RH implementa como política permanente as frutas disponíveis para todos os empregados.

É neste ponto é onde vemos cases como “Nossa empresa implantou frutas grátis como política e aumentamos satisfação em 70%”, cases aparecem em conferências de RH, inúmeros cases de sucesso e Fanfics no Linkedin, e em alguns casos a pessoa que é responsável pelo projeto vira Chief People Officer com uma porção de promoções de pessoas da equipe na esteira desse sucesso.

Entretanto, vamos olhar em relação ao que não foi dito.  

O acaso sendo medido como competência

Após seis meses o time do RH verifica um nível de estagnação nos indicadores de satisfação mesmo com a implementação da política das frutas no corredor.

Tendo isto em vista o time do RH e o time de People Analytics inicia uma investigação e resolve realizar alguns experimentos, que aqui vamos chamar de “A/B/C Fruit Corridor Experiment”

Neste caso serão 3 cestas de frutas que serão colocados em dias da semana alternados seguindo as seguintes configurações:

·  Cesta 1: Somente bananas

·  Cesta 2: Somente maças

·  Cesta 3: Frutas sortidas

Após 1 mês de experimentos foram obtidos os seguintes resultados:

·  Cesta 1: Somente bananas – Melhoria de + 1%

·  Cesta 2: Somente maçãs – Melhoria de + 2%

·  Cesta 3: Frutas sortidas – Melhoria de + 1%

Realizando uma comparação simples, temos o seguinte quadro:

Policy (intervenção)Resultado (Satisfação)
Implementação da política das frutas+70%
Otimização e experimentos+1%

Podemos ver neste exemplo que mesmo com mais esforço em termos de análise, experimentação, implementação e otimização o ganho foi praticamente marginal.

O que pode ter acontecido neste caso é que as pessoas podem não ter pego as frutas devido ao arranjo de recomendação provido pelo o RH no teste A/B/C mas sim elas consumiram apenas devido ao fato de estarem disponíveis para o consumo.

Em outras palavras: As pessoas oportunisticamente pegaram as frutas apenas devido ao fato de que elas estavam disponíveis.

Como assim disponibilidade?

Nenhum sistema de recomendação em produção corre o risco de não ter algum tipo de viés de disponibilidade. A ação humana ainda carrega um certo grau de não determinismo, o que significa que não importa quão boa seja a recomendação, algumas pessoas irão interagir com o sistema só pelo fato do mesmo estar disponível.

Em todos os sistemas de recomendação em que há uma utilização de forma passiva (i.e. não mandando ativamente recomendações como push notification, email, etc) pode haver um determinado potencial de pessoas utilizando de forma oportunístico.

Exemplos práticos de aspectos oportunisticos não relacionados com a recomendação em si:

  • Quantas vezes estávamos sem sede, mas paramos em um bebedouro para apenas tomar um pouco de água para nos manter hidratados?
  • Quantas vezes não tínhamos muita coisa para jogar no lixo, mas acabamos dispensando na lixeira mais próxima?
  • Quantas vezes ao passar em um lugar turístico não pegamos uma comida de rua apenas pelo fato de estarmos no lugar?

Estes são casos de utilização oportunística devido a um potencial viés de disponibilidade.  

Uma simples alternativa

Para medir inicialmente o viés da disponibilidade eu gosto de usar sempre um baseline randômico no começo de todo o projeto. Desta forma eu (a) me certifico do papel da aleatoriedade na recomendação (ou de outros elementos causais não identificados e/ou variáveis de confusão) e (b) com essa informação disponível eu consigo mensurar melhor o real impacto de outras variáveis durante a experimentação. Abaixo um exemplo:

Policy (implementação)Resultado
Recomendações aleatórias+10%
Policy #1 (A)+14% (Ajustado +4%)
Policy #2 (B)+12% (Ajustado +2%)

Ou seja, logo de começo eu tenho 10% de viés de disponibilidade não importa a recomendação que seja colocada em tela em um novo sistema. Eu vou tirar esses 10% de performance do meu resultado pois eles serão atingidos só pelo fato de estarem disponíveis.

Desta maneira, apenas com um baseline aleatório eu ja consigo ter parâmetros de comparação para saber o quanto do resultado é devido a disponibilidade.  

Considerações Finais

Ter um viés de disponibilidade em uma plataforma de recomendação não é problema nenhum e as vezes é até esperado em novos sistemas. O grande problema é quando confundem-se os efeitos de disponibilidade e toda a carga de incerteza que este viés pode carregar com efeitos da implementação dos algoritmos de forma propriamente dita. A consideração final que eu deixo aqui é que antes de qualquer implementação de sistemas de recomendação ter o entendimento a priori dos fatores de incerteza e contrafactuais que podem influenciar o resultado.

Frutas no corredor e viés de disponibilidade em Sistemas de Recomendação