natasha/natasha: a Python API for Russian NLP pipelines

The problem natasha solves for Russian text

Most NLP tooling assumes English. Russian brings free word order, a rich case system and a high rate of homonymy, so a tokenizer tuned for English will split and normalize Russian poorly. Natasha is a single Python package that wraps five lower-level Natasha project libraries: Razdel for token and sentence segmentation, Navec for compact Russian embeddings, Slovnet for morphology, syntax and NER models, Yargy for rule-based fact extraction, and Ipymarkup for NER and syntax visualization. The README describes the goal plainly: solve basic Russian NLP tasks under one convenient API, with quality on news articles similar to or better than current SOTAs for Russian. The intended user is an engineer who needs a working Russian pipeline, not a research result. The README states the underlying technologies are built for production, with attention to model size, RAM usage and performance, and that models run on CPU using Numpy for inference. That CPU-only stance matters if you have no GPU budget. It also caps what you can expect: this is not a transformer stack you can fine-tune on your own corpus.

How the Doc object drives segmentation, tagging and extraction

The architecture is a pipeline over one mutable object. You build a Doc from raw text, then call methods on it in order, and each step annotates the object further. Segmentation defines the tokens and sents properties. Morphology tagging depends on segmentation and defines pos and feats on each token. Lemmatization depends on morphology and defines a lemma property. Syntax parsing and NER tagging likewise consume the embeddings-backed models. Extraction sits on top: the README's example builds a NamesExtractor from the MorphVocab and uses it to pull structured facts out of the tagged document. The dependency order is not decorative. If you call tag_morph before segment, there are no tokens to tag. The README also notes that morph.print() visualizes morphology markup and that Ipymarkup provides NER and syntax visualizations, which is useful when you need to check a model's output by eye rather than trust a metric. The README carries an explicit warning that the API may change and that for real-world tasks you should consider using the low-level libraries from the Natasha project directly. Treat the top-level package as a convenience layer, not a stable contract.

Installing natasha and building your first Doc

Natasha supports Python 3.7+ and PyPy3. The README gives a single install command:

$ pip install natasha

That pulls the pinned dependencies declared in setup.py: pymorphy2, razdel>=0.5.0, navec>=0.9.0, slovnet>=0.6.0, yargy>=0.16.0 and ipymarkup>=0.8.0. The package ships its data files (dictionaries, embeddings and models) inside the wheel, so the first import does not trigger a separate model download step in the documented flow.

Next, import the components and build a Doc. This is the README's own initialization pattern, with the text shortened:

from natasha import (
    Segmenter,
    MorphVocab,
    NewsEmbedding,
    NewsMorphTagger,
    NewsSyntaxParser,
    NewsNERTagger,
    Doc
)

segmenter = Segmenter()
morph_vocab = MorphVocab()
emb = NewsEmbedding()
morph_tagger = NewsMorphTagger(emb)

doc = Doc('Посол Израиля на Украине Йоэль Лион признался, что пришел в шок.')
doc.segment(segmenter)
print(doc.tokens[:5])

After segment, doc.tokens holds DocToken objects with start, stop and text fields, and doc.sents holds DocSent objects. The README's example output shows DocToken(stop=5, text='Посол') as the first token, so expect character offsets rather than a bare string list.

To go further, tag morphology and then lemmatize each token. The README's example prints pos and feats on the tokens and calls morph.print() for a readable table:

doc.tag_morph(morph_tagger)
for token in doc.tokens:
    token.lemmatize(morph_vocab)
print(doc.tokens[:5])

The lemmatization step uses Pymorphy internally and depends on the morphology step having run first. The README's sample output shows 'Посол' resolving to lemma 'посол' with pos='NOUN' and feats=<Anim,Nom,Masc,Sing>. If you need NER, add NewsNERTagger(emb) and the PER constant alongside a NamesExtractor built from morph_vocab, following the import list in the README.

Where natasha is the wrong tool

The README is unusually direct about this. Models are optimized for news articles, and quality on other domains may be lower. That is not a hedge you can ignore. If you are processing support tickets, forum threads, product reviews or clinical notes, the morphology, syntax and NER models were not trained for your register and the README offers no domain-adaptation path. There is a second, harder boundary: the API may change, and the README tells you to consider the low-level libraries for real-world tasks. A production system that imports the top-level natasha package is accepting churn risk that the same author warns about. Third, the models are CPU and Numpy based by design. That is a feature for deployment cost, but it means there is no fine-tuning story in the README: you get the shipped model, not a base you can retrain on your labeled data. Finally, older extraction classes have moved. The README states that to use the old NamesExtractor and AddressExtractor you must downgrade with pip install natasha<1 yargy<0.13. If your codebase was written against those classes, the current version is not a drop-in replacement.

natasha against spaCy and Stanza for Russian

The obvious alternatives are spaCy and Stanza, both of which ship Russian pipelines. The difference is in what each project treats as the unit of work. SpaCy and Stanza are general multilingual frameworks: one pipeline object, many languages, a training configuration system, and a model registry. Natasha is the opposite shape. It is Russian-only, it is assembled from five separate Natasha project libraries, and it exposes a Doc object whose methods you call in a fixed order rather than a configurable pipeline. If you need one codebase for twelve languages, natasha is the wrong choice and spaCy or Stanza is the right one. If you need Russian news text processed with a small CPU footprint and you want fact extraction from rules as well as statistical NER, natasha is the more direct fit. The Yargy layer is the part with no real equivalent in the other two: rule-based fact extraction similar to Tomita parser, per the README, which lets you express patterns over morphology tags instead of training a model for each new field. That is a genuine architectural difference, not a feature checklist item.

Maintenance, version pinning and the MIT licence

The repository is not archived, and the last push was on 2026-04-13. Setup.py declares version 1.6.0. No releases were retrieved, so version history has to be read from setup.py and the dependency floors rather than a changelog. Those floors matter for upgrades: razdel>=0.5.0, navec>=0.9.0, slovnet>=0.6.0, yargy>=0.16.0 and ipymarkup>=0.8.0 are minimums, not pins, so a fresh install months later can resolve to different library versions than the ones the README examples were written against. If you need reproducibility, pin the full dependency set yourself rather than relying on these ranges. The Makefile shows the project's own check: make test runs flake8 over natasha and tests, then pytest -vv tests. There is also an exec-docs target that executes docs.ipynb through nbconvert, which means the notebook examples are executed as part of the project's own workflow. The package is MIT licensed, declared in both setup.py and the LICENSE file at the repository root. MIT is permissive and imposes no source-disclosure obligation on your application; the bundled model and embedding data files are distributed under the same repository licence, but if you redistribute them in a product, read the LICENSE file yourself rather than relying on this summary.

Editorial conclusion

Adopt natasha if you process Russian news text and want segmentation, morphology, syntax and NER behind one Doc object without assembling four libraries yourself. Do not adopt it if your corpus is chat messages, product reviews or clinical notes: the README states the models are optimized for news articles and that quality on other domains may be lower. Before committing, run the pinned versions from setup.py (razdel>=0.5.0, navec>=0.9.0, slovnet>=0.6.0, yargy>=0.16.0, ipymarkup>=0.8.0) against a sample of your own documents, and check whether the NamesExtractor output matches the fields you actually need.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. natasha/natasha on GitHub
4. README