spaCy is a new library for text processing in Python and Cython. I wrote it because I think small companies are terrible at natural language processing (NLP). Or rather: small companies are using terrible NLP technology.
To do great NLP, you have to know a little about linguistics, a lot about machine learning, and almost everything about the latest research. The people who fit this description seldom join small companies. Most are broke — they’ve just finished grad school. If they don’t want to stay in academia, they join Google, IBM, etc.
The net result is that outside of the tech giants, commercial NLP has changed little in the last ten years. In academia, it’s changed entirely. Amazing improvements in quality. Orders of magnitude faster. But the academic code is always GPL, undocumented, unuseable, or all three. You could implement the ideas yourself, but the papers are hard to read, and training data is exorbitantly expensive. So what are you left with? A common answer is NLTK, which was written primarily as an educational resource. Nothing past the tokenizer is suitable for production use.
I used to think that the NLP community just needed to do more to communicate its findings to software engineers. So I wrote two blog posts, explaining how to write a part-of-speech tagger and parser. Both were well received, and there’s been a bit of interest in my research software — even though it’s entirely undocumented, and mostly unuseable to anyone but me.
So six months ago I quit my post-doc, and I’ve been working day and night on spaCy since. I’m now pleased to announce an alpha release.
If you’re a small company doing NLP, I think spaCy will seem like a minor miracle. It’s by far the fastest NLP software ever released. The full processing pipeline completes in 20ms per document, including accurate tagging and parsing. All strings are mapped to integer IDs, tokens are linked to embedded word representations, and a range of useful features are pre-calculated and cached.
If none of that made any sense to you, here’s the gist of it. Computers don’t understand text. This is unfortunate, because that’s what the web almost entirely consists of. We want to recommend people text based on other text they liked. We want to shorten text to display it on a mobile screen. We want to aggregate it, link it, filter it, categorise it, generate it and correct it.
spaCy provides a library of utility functions that help programmers build such products. It’s commercial open source software: you can either use it under the AGPL, or you can buy a commercial license under generous terms.
Let’s say you’re developing a proofreading tool, or possibly an IDE for writers. You’re convinced by Stephen King’s advice that adverbs are not your friend so you want to highlight all adverbs. We’ll use one of the examples he finds particularly egregious:
Easy enough — but the problem is that we’ve also highlighted “back”. While “back” is undoubtedly an adverb, we probably don’t want to highlight it. If what we’re trying to do is flag dubious stylistic choices, we’ll need to refine our logic. It turns out only a certain type of adverb is of interest to us.
There are lots of ways we might do this, depending on just what words we want to flag. The simplest way to exclude adverbs like “back” and “not” is by word frequency: these words are much more common than the prototypical manner adverbs that the style guides are worried about.
Token.prob attribute gives a log probability estimate of
(The probability estimate is based on counts from a 3 billion word corpus,
smoothed using the
Simple Good-Turing_ method.)
So we can easily exclude the N most frequent words in English from our adverb marker. Let’s try N=1000 for now:
There are lots of other ways we could refine the logic, depending on just what
words we want to flag. Let’s say we wanted to only flag adverbs that modified
words similar to “pleaded”. This is easy to do, as spaCy loads a vector-space
representation for every word (by default, the vectors produced by
Levy and Goldberg (2014)_). Naturally, the vector is provided as a numpy
We want to sort the words in our vocabulary by their similarity to “pleaded”. There are lots of ways to measure the similarity of two vectors. We’ll use the cosine metric:
As you can see, the similarity model that these vectors give us is excellent — we’re still getting meaningful results at 1000 words, off a single prototype! The only problem is that the list really contains two clusters of words: one associated with the legal meaning of “pleaded”, and one for the more general sense. Sorting out these clusters is an area of active research.
A simple work-around is to average the vectors of several words, and use that as our target:
These definitely look like words that King might scold a writer for attaching adverbs to. Recall that our original adverb highlighting function looked like this:
We wanted to refine the logic so that only adverbs modifying evocative verbs of communication, like “pleaded”, were highlighted. We’ve now built a vector that represents that type of word, so now we can highlight adverbs based on subtle logic, honing in on adverbs that seem the most stylistically problematic, given our starting assumptions:
This example was somewhat contrived — and, truth be told, I’ve never really bought the idea that adverbs were a grave stylistic sin. But hopefully it got the message across: the state-of-the-art NLP technologies are very powerful. spaCy gives you easy and efficient access to them, which lets you build all sorts of useful products and features that were previously impossible.
Independent evaluation by Yahoo! Labs and Emory University, to appear at ACL 2015. Higher is better.
Joel Tetreault and Amanda Stent (Yahoo! Labs) and Jin-ho Choi (Emory) performed a detailed comparison of the best parsers available. All numbers above are taken from the pre-print they kindly made available to me, except for spaCy v0.86.
I’m particularly grateful to the authors for discussion of their results, which led to the improvement in accuracy between v0.84 and v0.86. A tip from Jin-ho (developer of ClearNLP) was particularly useful.
Per-document processing times. Lower is better.
|Absolute (ms per doc)||Relative (to spaCy)|
Set up: 100,000 plain-text documents were streamed from an SQLite3 database, and processed with an NLP library, to one of three levels of detail — tokenization, tagging, or parsing. The tasks are additive: to parse the text you have to tokenize and tag it. The pre-processing was not subtracted from the times — I report the time required for the pipeline to complete. I report mean times per document, in milliseconds. Hardware: Intel i7-3770 (2012)
Efficiency is a major concern for NLP applications. It is very common to hear people say that they cannot afford more detailed processing, because their datasets are too large. This is a bad position to be in. If you can’t apply detailed processing, you generally have to cobble together various heuristics. This normally takes a few iterations, and what you come up with will usually be brittle and difficult to reason about.
spaCy’s parser is faster than most taggers, and its tokenizer is fast enough for any workload. And the tokenizer doesn’t just give you a list of strings. A spaCy token is a pointer to a Lexeme struct, from which you can access a wide range of pre-computed features, including embedded word representations.