Ask HN: Getting into NLP in 2018?
For someone with a reasonable background in software development, what new skills might need to be acquired to move specifically into NLP (natural language processing)?
Does doing NLP essentially mean having to learn ML at this point?
Also, how to showcase skills to potential employers?
33 comments
[ 11.1 ms ] story [ 1330 ms ] threadDon't watch 2012, rather the latest available from 2017. It has changed completely. Start learning from word2vec and finish with transfer learning using BERT/ULMFit/ELMo and you'll be state-of-art as of end of 2018 (though BERT needs >20GB VRAM on your GPU, so get a Titan RTX or V100).
There are another recent NLP lectures such as these from Oxford:
https://github.com/oxford-cs-deepnlp-2017/lectures
Yes. Everything in NLP nowadays involve ML. Most NLP problems have some structure (e.g., generating a sequence from another sequence like in Machine Translation, or predicting a tag for each word in a sequence like in part of speech tagging). Once you have good ML fundamentals it's not that difficult to get into NLP.
Also, even though different tasks in NLP share structure and characteristics, it's a large field with different areas of expertise. You don't need to know everything. Focus on the problems that interest you first.
Some really nice projects do NLP without using ML at all, for instance Duckling [1] (a library made by facebook to find entities in a text) works a 100% with parsing rules, and is surprisingly efficient.
I agree with your point though, most of the time there is ML at some point in your pipeline so you can't really avoid learning it !
[1] https://github.com/facebook/duckling
Aside from that, yes. Lots, but not all, of NLP these days involves ML in some form. Most things I've seen are done in Python, what with all the NLP-specific and general ML libraries available.
In terms of textbooks, Speech & Language Processing by Jurafsky & Martin is great. Might not be the best way of diving in, but it's a good resource to go deeper into things. The draft third edition, while only partially complete, is online for free [4].
[1] http://web.stanford.edu/class/cs224n/
[2] https://www.youtube.com/playlist?list=PL3FW7Lu3i5Jsnh1rnUwq_...
[3] https://www.cl.cam.ac.uk/teaching/1819/NLP/
[4] https://web.stanford.edu/~jurafsky/slp3/
NLP projects fail a lot. If you line up a job as a company's first NLP person, you'll probably be setting yourself up for failure. You'll get handed an idea that can't work, you won't know enough about how to push back to change it into something that might, etc. After the project fails, you might get a chance to fail at a second one, but maybe not a third. This isn't a great way to move into any new field.
I think a cunning plan would be to angle to be the person who "productionises" models. Tonnes of data scientists these days are surprisingly light on programming skills, and they expect to hand off a notebook to someone who'll "make it work". I think that sort of role would position you well to take over the actual modelling as well.
As a bit of background, I'm the lead author of spaCy, a popular NLP library. I'd like to stress that spaCy's definitely just one part of a solution --- nothing is a "make NLP go now" button. I do think you'll need to know machine learning to have really successful NLP projects. Another thing you might want to check out is our annotation tool Prodigy: https://prodi.gy . This is especially good for experimenting, as you really need to annotate data to get anything done.
Has having seen a lot of NLP projects given you any insight into prerequisites for success?
The biggest problem I see people having is they don't realise that defining a consistent annotation scheme takes a lot of work. If you don't define your problem well, you won't be able to collect consistent annotations, and your model will always perform poorly. You need an annotation scheme that "carves reality at the joints". There will always be boundary cases, but some ways of dividing things up are just bad.
For instance, if you want to collect opinions about bands you like on social media, you don't want to have an NER category "BANDS_I_LIKE". That's just dumb: detect bands to handle ambiguities, run the classifier over lots of text, get a frequency list, and then mark the ones you like.
Another example. Let's say you were looking for suspicious activity in some dataset like the Panama papers. You might have a bunch of indicators for suspicious activity, like companies that change name a lot, or the same director on companies from very different industries. A lot of people have gotten the message that they should make their models as direct and end-to-end as possible, so they might try to label emails as "INDICATES_SUSPICIOUS_ACTIVITY". This label is unlikely to be the easiest way to do things. For one thing, it's bad to have one category that applies to a bunch of disjunct sets. If you've got a single label for "A or B", you won't have a linear decision boundary. Linearly separable problems are much easier to learn. Another problem here is that the decision you're trying to make rests on tonnes of world knowledge. The business goals would be much better met by learning some simple text annotations like NER, a few simple text categories etc, and using a rule-based approach to stitch things together.
Basically, don't just work on having more powerful solutions. Make sure you've tried hard to have easier problems as well --- that part tends to be higher leverage.
If you lack skills in one area, develop it & become an expert, don't be the guy who only does Python/R/matlab etc.
People with full spectrum skill set tend to be in more influential (and better paid) positions.
It turned NLP for me from "voodoo" into something I'm kinda interested in tackling for fun, and it was a pretty short/easy read to begin with. Probably the biggest thing I picked up out of it though was that advancement in NLP probably requires far more understanding of the English language than particularly talented coding.
In our own product, I have a backlog wishlist story to parse a repository of docs and flag the ones containing locations, people, places, etc... then let a linear regression determine if there are correlations.
But I'd probably hire an ETL or Data Engineer to accomplish that task.
~12 months after we started that we got a request for an event detection model using data that only existed in our text database, so I was able to put the infrastructure we set up to use.
Setting up that infrastructure with good text parsing defaults was a good intro to NLP although I have been intentionally avoiding getting too deep into the NLP-specific methods (e.g. linguistics) for this project. The event detection model gave me a nice focused project to work on which was very helpful for learning more NLP.
FWIW I actually chose not to use ML for this project (aside from parsing with the NLP software) despite that being the easier route since we lacked sufficient training data to train a good model. But in general one would probably need to know how to use ML for this sort of thing.
Hopefully this will be a useful anecdote though it's probably not compatible with your situation.
When it comes to DL stuff, I think the most useful thing in production projects will be "embeddings", and all the relatively simple stuff you can do once you have the word -> vector mapping. It's simple stuff, pick up the new O'reilly book 'Deep Learning Cookbook' [1] the first 4 chapters already cover this [2]. Popular libraries have this baked in [3], I think soon this will be like making SQL calls in Django projects...
[1] https://www.amazon.com/Deep-Learning-Cookbook-Practical-Reci...
[2] https://github.com/DOsinga/deep_learning_cookbook/blob/maste...
[3] https://pytorch.org/tutorials/beginner/nlp/word_embeddings_t...
What problem are you trying to solve?
Detail: deliveries in the Middle East. There's no zip codes, street names are iffy, people don't know their address, there's multiple names for everything (at least english and arabic), there's no "database" for lookups (Gmaps/OSM does not have good enough coverage/accuracy). So delivery companies, when they accept a package for delivery, get the (customer_name, customer_phone, customer_address) tuple (and the physical package), where everything is totally freetext, sometimes the address is like "I live in the X laborcamp, near the gate, call me when you get here". So by default there's a large call center which calls the recipient, and the CC agent tries to figure out where the driver should go based on the conversation. The outcome of the phonecall is a (lat, lon) that the CC agent drops on Gmaps. Then, the next day, packages are assigned to drivers based on the (lat, lon), each driver has a zone (cities are broken into zone polygons).
Challenge: given the historic delivery data, can you (how well can you?) automate the (customer_name, customer_phone, customer_address) -> (lat, lon) prediction?
Answer: as I wrote above, it's doable for 40-80% of orders, depending on what accuracy we're willing to accept, with fairly simple ML.
https://github.com/keon/awesome-nlp