DEV Community: Boris Orekhov

How We Mapped 96 Minority Languages of Russia on the Internet – A Web Scraping Journey

Boris Orekhov — Sat, 07 Nov 2026 07:04:00 +0000

The challenge: find 96 languages without a dictionary

Russia speaks dozens of minority languages – Tatar, Bashkir, Udmurt, even tiny ones like South Yukaghir. Some have no Wikipedia, no standard corpus, and almost no digital footprint. But they do exist online, scattered across forums, blogs, and VK communities.

We wanted to measure their online presence. As programmers, we quickly realised: no global corpus, no labelled dataset, and no simple way to ask a search engine “give me all pages in Chechen”.

So we built our own pipeline.

Step 1: Choose word markers – the hard way

You can’t download the whole internet (unless you’re Google). But search engines already crawled it. We used Yandex.XML – a limited API (10k requests/day) that returns search results page by page (each next page costs another request).

What do we search for? We need word markers:

Frequent in the target language
Unique – not appearing in Russian or other languages
Free of special characters (because real users don’t type them)

That last point is killer. Most minority languages use Cyrillic extensions: ҙ, ә, ö, ҷ. There’s no standard keyboard for them. People write “менан” instead of “менән”. If we query with the “correct” spelling, we lose 90% of real texts.

We call this “household spelling” – like medieval birch‑bark manuscripts, but with modern laziness.

Step 2: Kill the noise

Even good markers return junk:

Wikipedia duplicates (we can download those in one click, so exclude them)
Linguistic papers with example sentences (Russian text containing one line of Rutul)
Music sites with song titles but no lyrics
Typos – e.g. Russian “пазух” (bosom) mistyped as “пазох”, which is a valid Khakas word meaning “again”

To filter, we used multi‑marker verification. If one marker appears on a domain but others from the same language don’t, it’s probably a false positive. That means extra API calls – expensive when you only have 10k/day.

Step 3: Classify domains by depth

We asked Yandex to categorise each domain into three tiers:

Language‑first – most pages in the minority language
Mixed – several pages, but minority language is not dominant
Giant platforms – YouTube, stihi.ru, etc., where minority content exists but is buried

Also, we specifically queried VK.com communities because social networks post‑2012 ate most standalone language sites.

Step 4: Detect the language (without a training corpus)

We downloaded pages and needed to separate Russian from, say, Tuvan. Classic n‑gram language detection requires a pre‑labelled corpus – which we didn’t have.

But we did have Russian – plenty of it. So we built a binary classifier: Russian vs. everything else. If a paragraph isn’t Russian, it’s our target. Not perfect, but good enough to build the first ever web corpora for these languages.

What we learned (the data science part)

We compared online metrics (Wikipedia articles, VK communities, text volume) with offline metrics (speaker count, regional economy).

Correlation (Spearman) among online metrics: >0.7

Correlation between online and offline: near zero

That means: how many people speak a language does not predict how alive it is on the internet. What matters is a small, active, passionate community.

Example: Bashkir has fewer speakers than Chechen, but far more online communities. Why? Chechnya’s internet infrastructure recovered later (1990s‑2000s conflicts delayed digital adoption).

A few geeky findings

Post‑2012, almost all minority language activity moved to VK.com – Russian Facebook.
Typical user: 19‑31 years old, lives in the region’s capital (Ufa for Bashkir, Izhevsk for Udmurt).
Typical minority‑language post: ~5 words long. Most conversation is in Russian, but people sprinkle native words as identity markers.
The minority language web is highly interconnected – sites in different languages link to each other. A rare case of “peoples united” online.

Data

Downloadable corpora and domain lists: web-corpora.net

And yes, there’s a VK community with cute memes in minority languages – featuring cats.

Takeaway for devs:

Web scraping isn’t just about avoiding robots.txt. It’s about understanding human behaviour – typos, keyboard limitations, social network migration, and why a language with 50 speakers can thrive online if those 50 are determined enough.

Wikipedia as a Linguistic Dataset?

Boris Orekhov — Tue, 27 Oct 2026 09:56:00 +0000

If you’ve ever scraped Wikipedia for training data, you probably assumed the text is “natural” – written by humans, balanced across topics, ready for your shiny language model.

Think again.

We analyzed Russian, Tatar, Bashkir, Mari, Mordvin, and Komi Wikipedias using a dead‑simple method: word frequency lists. The results are eye‑opening for anyone who handles text corpora.

The litmus test for a “natural” corpus

In any balanced, human‑written text collection, the most frequent words are function words – prepositions, conjunctions, pronouns, auxiliary verbs.

Example from the Russian National Corpus:

#	Word	Part of speech	Frequency (ipm)
1	и (and)	conj	35801
2	в (in)	prep	31374
3	не (not)	part	18028

Content words (nouns, adjectives, full verbs) appear much lower in the list.

So if your corpus’s top 20 is full of words like “river”, “basin”, “water”, “orchid” – you have a problem.

Russian Wikipedia passes (mostly)

The Russian Wikipedia (1.06M articles) top word forms:

#	Word	Frequency
1	в (in)	10,859,129
2	и (and)	5,761,105
3	на (on)	3,214,393
4	с (with)	2,439,469

Apart from the verb “быть” (to be), it’s all prepositions/conjunctions. ✅ Good enough for linguistic research.

But Tatar and Bashkir Wikipedia? Disaster.

Tatar Wikipedia (~50k articles) top 10:

#	Word	Translation	Frequency
1	елга	river	132,567
2	бассейны	basin	75,706
3	су	water	54,689
4	буенча	by (postposition)	48,838
5	Русия	Russia	48,722

The only “function word” is буенча at #4. “River” is 3x more frequent than the conjunction “and”.

Bashkir Wikipedia is identical: йылга (river), бассейны, һыу (water), Рәсәй (Russia) dominate the top.

Why? Auto‑generated articles

Most articles weren’t written by humans. They were created automatically from a template, filled with data from Russia’s State Water Registry.

Thousands of articles about rivers – each repeating “river”, “basin”, “water”, “located”, “km” – completely distort the frequency distribution.

For a programmer: Imagine scraping this corpus for word embeddings or a language model. Your embeddings would be obsessed with hydrology.

Mordvin Wikipedias: the Orchid syndrome

Erzya and Moksha (Mordvin) Wikipedias have ~1,100–1,500 articles. Their top words include “category”, “see”, “day”, “year” – but also:

Erzya	Moksha
истэжо (also)	ди (and)
категория	и (and)
ван (see)	тыналста (from family)
чи (day)	касыкссь (plant)
ды (and)	панчф (flower)
ие (year)	орхидея (orchid)

The explanation: most articles are automatically generated about orchids (family Orchidaceae). Hundreds of plant stubs, each repeating “orchid”, “flower”, “species”, “genus”.

They call this the Orchid Phenomenon – a corpus hijacked by bot‑generated content about a single narrow topic.

Average article length: a quick sanity check

Wikipedia	Avg length (words)
Russian	184.5
Tatar	58.5
Bashkir	56.8
Komi‑Zyrian	29.6
Erzya	34.5
Moksha	34.9

Short stubs = high risk of template‑driven, repetitive content.

What this means for you (the developer)

Don’t trust Wikipedia dumps blindly – especially for low‑resource languages or small editions.
Frequency analysis is your cheap, powerful friend – a simple count of top word forms can reveal massive bias.
Auto‑generated content is everywhere – not just rivers and orchids, but also geographical coordinates, biological taxa, movie stubs.
If you build a language model on such data, expect weird behaviour: over‑representation of “river”, “water”, “orchid”, “species” in any context.

The takeaway

“Wikipedia is free, but not always natural.”

For major languages (English, Russian, German) the corpus is surprisingly balanced. For many minority languages, the Wikipedia you scrape may be more botanical than linguistic.

Always profile your data. A frequency list takes 5 minutes to generate and can save you months of debugging weird model predictions.

Further reading: Orekhov, Reshetnikov (2014). “Towards an evaluation of Wikipedia as a linguistic source: a comparative study.” In Modern Russian Language on the Internet, Moscow.

Liked this? Share with your fellow NLP engineers. They’ll never look at Wikipedia the same way again.

Teaching a Computer to Write Bashkir Haiku (And Why It Went Viral)

Boris Orekhov — Sat, 17 Oct 2026 09:49:00 +0000

Ever tried to teach a computer to write poetry in a language that has almost no digital linguistic resources? That’s exactly what we did.

I work at the Computational Philology Lab at Bashkir State University. While Russian and English have plenty of NLP tools, Bashkir – a Turkic language spoken in Russia – has close to none. So we decided to build something fun: a haiku generator.

The rules were simple

First line: 5 syllables
Second: 7 syllables
Third: 5 syllables
All output must be grammatically correct Bashkir

We built a dictionary of ~11,500 words and designed 90+ rhythm-grammar scenarios – templates that ensure syllable counts and grammatical agreement (cases, verb tenses, singular/plural). The algorithm randomly picks words and slots them into a scenario. Present tense appears more often than past, singular more than plural – just because it feels more natural for haiku.

What came out?

Mostly nonsense. But sometimes – pure accidental poetry.

Here’s one (translated):

Sovinformburo

takes from fire and buries. The word

fears the statue.

It reads like a surrealist miniature: war communiques, fire, burial, and a fearful “word” that brings to mind the Don Juan legend. A machine wrote this without any intent – yet it feels oddly coherent.

Another one:

Thousand cable workers

hang like leather. The ray, ah!

like tinder, does not obey.

You see contrast: dark, flexible cables vs. a straight, unbending ray of light. The computer accidentally discovered antithesis.

The unexpected part

We put the generator online as a joke. Then the media went wild. Radio, newspapers, TV – all wanted to talk about “computer haiku.” Nobody cared about our serious academic corpora or folklore databases. But a silly poetry bot? That got headlines.

Why this matters for programmers

Low-resource languages need creative first steps. You don’t need giant transformers to have fun and learn.
Randomness + constraints = emergent meaning. The human brain will find poetry even where none was intended.
Grammar-first generation is possible with modest dictionaries and smart templates. Our 90 scenarios keep everything grammatical.

We’re not claiming real AI poetry. But watching a Bashkir-speaking machine accidentally write about excavators, grenade launchers, and frozen cellars? That’s entertainment – and a tiny step toward putting my language on the computational map.

👉 Want to try it? It’s online (in Bashkir, sorry). Each refresh gives you a new, never-before-seen haiku. Some are garbage. Some – just weird enough to be beautiful.

P.S. One journalist wrote we “decided to amaze the world.” We didn’t. But we’re glad it made people smile.

🤖📜 The Electronic Lyre

Boris Orekhov — Wed, 07 Oct 2026 06:52:00 +0000

Why Every Dev Should Care About AI Poetry (And Not Just for the Memes)

TL;DR: Most programmers know AI can generate poems, but they rarely ask why it does it so badly—or so brilliantly. This book finally explains it, without drowning you in linear regression and backpropagation. It turns out, understanding AI poetry is less about math and more about understanding what poetry actually is. And the answer might surprise you.

Let's be real. When you hear "AI writes poetry," what's the first thing that comes to mind?

Probably something like this:

The hour is twice a cat on velvet rose
Who melts the moon until the willow sings

Beautiful nonsense, right? Just random words glued together by an overeager RNN.

For years, that's been the programmer's view of machine poetry: a neat party trick, a testbed for Markov chains, and a source of hilariously broken syntax.

But that view is stuck in 1997.

While we were busy declaring victory over Kasparov, something quietly happened in the humanities departments. A real revolution. And my new book, *"The Electronic Lyre: How and Why Artificial Intelligence Writes Poetry" ,* is the first serious attempt to explain what the hell is actually going on.

And no, this isn't a book about "the future of art." This is a book that finally bridges the chasm between how we build AI and how it learns to mean something.

Wait, Why Should a Dev Read This?

I know what you're thinking: "I don't care about literary theory. Just tell me how the transformer works."

But hold on. This book is deliberately, provocatively written for humanities scholars. Me, a computational linguist, swears he'll barely mention loss functions. Instead, he'll talk about hexameter, centos and collage.

If that doesn't send shivers down your spine, you're missing the point.

Me argue that we've been asking the wrong question. For 70 years, engineers have been asking: "Can we make a computer write a convincing poem?" And they've done it by basically brute-forcing the problem: combinatorial word shuffling → Markov chains → RNNs → Transformers.

But no one stopped to ask the real question: "What are we even trying to copy?"

The Two Ages of Machine Poetry (And Why Your Old Code is Obsolete)

The book brilliantly separates the history of machine poetry into two distinct eras. And knowing the difference will change how you look at your own generative models.

🕰️ Era 1: Combinatorics (1950s–2010s) — The "Shakespearean Monkey"
This is the era you know. The program had a dictionary, some grammar rules, and a random number generator. The goal was surprise. The computer was a roulette wheel for words. This approach was a direct descendant of Dadaism and Surrealism—artistic movements whose whole point was to break the chains of rational thought.

"Dada created a real element of global protest," Orekhov writes. The computer was the ultimate tool for irrationality.

Every program from the 60s to the 2000s—from Стихоплюй to Кибер-Пушкин—was just shuffling a deck of cards.

🚀 Era 2: Neural Networks (2010s–Now) — The "Statistical Mimic"
Then everything changed. RNNs, and later Transformers, didn't rely on randomness. They relied on prediction. They learned from massive datasets—millions of lines of real poetry. They stopped trying to break the rules and started trying to internalize them.

This is the crucial point. An RNN doesn't invent new words. It learns the distribution of letters. It learns that 'о' is common, that '-ние' is a suffix, that 'в лесах' is a phrase. It learns style.

I show this with brutal clarity. I trained an RNN on Pushkin. It didn't just rhyme. It learned to mimic Pushkin's specific syntactic inversions, his preferred vocabulary, even his thematic concerns.

But here's the magic—and the error.

The Hallucination of Meaning

The book's central, mind-bending argument is this: A computer's poem isn't a message. It's a statistically perfect forgery of a message.

And that might be the most interesting thing about it.

Think about it. When you read a human poem, you're engaged in an act of understanding. You're trying to reverse-engineer the author's intent. You're looking for the "why" behind the "what."

When you read a GPT-generated poem, there is no "why." There's just a statistically probable sequence of tokens.

But—and this is the killer—the human brain is a meaning-making machine. We cannot look at a text that looks like a poem and not try to find meaning in it.

So, we hallucinate it. We fill in the gaps. We find profound connections between words that the model placed there by pure mathematical accident.

The book calls this the "uncanny valley" of poetry. The closer the model gets to perfect mimicry, the more disturbed we become, because we sense the lack of a soul behind the words.

What's Actually in the Book (For the Curious)

If you want to sound smart at your next ML meetup, here are the three big takeaways from The Electronic Lyre:

The "Impossible" Vers Libre: For decades, Russian computer poems were strictly rhymed and metered. Why? Because the developers had a "school" view of poetry. In the West, where developers were influenced by Surrealism, free verse was the norm. The book argues that the cultural context of the programmer is encoded into the model's output more than any dataset.
The Stylistic Impersonator: I run an experiment. I take a short (4-line) poem generated by a model trained on Nekrasov. I ask literary scholars to identify which of four poets it most resembles. The experts, even on this tiny fragment, pick Nekrasov 80% of the time. The model isn't just generating text; it's capturing an authorial fingerprint that is statistically indistinguishable from the real thing.
Parody vs. Plagiarism: Is a neural poem a parody? A parody mimics style for humorous or critical effect. An AI poem mimics style for no reason at all. It's an empty simulacrum. And yet, it reveals more about the nature of style than any critical essay ever could.

One Last Thing: The "Turing Test" is a Trap

The book ends with a powerful plea: stop asking "can a machine fool a human?"

That's boring. That's the "counting cats in Zanzibar" of AI research.

Instead, ask: "What happens to our understanding of poetry when a machine can flawlessly produce its outward form?"

The answer, according to me, is that we finally have to confront the mystery of meaning itself. And that's a question worth sticking around for.

The Book: "The Electronic Lyre: How and Why Artificial Intelligence Writes Poetry" by Boris Orekhov.

👉 Get it from the publisher's site here (It's in Russian, but the ideas are universal).

What do you think? Have you ever tried to seriously interpret a GPT-generated poem, or do you dismiss it all as stochastic parroting? Drop a comment below—let's get a real debate going.

Vindolanda. A Free Font That Brings Ancient Roman Cursive into the Digital Age

Boris Orekhov — Sun, 27 Sep 2026 06:38:00 +0000

If you think ancient handwriting has no place in modern sans-serif typography, think again.

Meet Vindolanda — a free, open-source typeface that reproduces the letterforms found on wooden writing tablets from a Roman auxiliary fort near Hadrian’s Wall. These tablets, preserved for nearly 2,000 years by anaerobic soil conditions, contain one of the best examples of early Roman cursive.

The most famous is tablet 291 — a birthday invitation from Claudia Severa. Her elegant, slanted handwriting became the main inspiration for the font.

But here’s the twist: Vindolanda is not a historical reenactment. It’s a strict modern sans-serif that combines the raw, fractured energy of hand‑drawn Roman cursive with the clean regularity of contemporary typography.

No uppercase/lowercase distinction. Just pure, angular character.

Why This Matters for Type Designers

Authentic letterforms — every Latin character is based directly on Vindolanda tablets (where they could be found). Letters like B, C, D, and L keep their original uneven, almost runic structures.
Kerning done right — because these shapes are unusual, standard kerning pairs won’t work. The article includes a detailed list of pairs like E+O, F+V, R+Q, and more.
Cyrillic for fun — no historical basis (Slavs didn’t have writing for another 700 years), but the author fantasizes what Roman‑cursive Cyrillic might look like. Great for Easter eggs or secret‑club alphabets.

A Few Letter Highlights

A – sharp, almost triangular
B – very vertical with a detached element
C – drawn in two linear strokes, not a smooth curve
Q – so rare on the tablets that the designer had to adapt it to fit the font’s character
X, Y, Z – almost absent in the original documents (no scholarly Greek needed for Roman logistics)

Beyond the Font

The creator, me, didn’t just draw letters. I wrote a full academic-style paper (with DOI!) explaining the design decisions, showing side‑by‑side comparisons of tablet letters vs. font letters, and even discussing how the font can be used for:

Authentic book/web reproduction of Roman cursive texts
Teaching paleography
Secret kid clubs (Dead Poets Society style)

Download & License

100% free and open source (includes commercial use)
OTF + TTF files available
Source project in Glyphr Studio — you can modify it
License: Creative Commons (see article)

Download from GitHub:

Vindolanda-Regular.otf

Vindolanda-Regular.ttf

Original academic publication:

10.5281/zenodo.13293622

Final Thought

“Vindolanda returns clarity and precision of Greek writings to Roman cursive.”

If you’re a type designer looking for something between ancient runes and sci‑fi movie lettering — give this font a try. Your next project might just look like it was written by a Roman soldier with a steady hand and a very sharp stylus.

Lingua Latina in the font? Absolutely. Check the original article for a full Latin banner.

Train OCR on Pre-Revolution Russian Texts? I’ve Got a Dataset for You! 🧐📜

Boris Orekhov — Thu, 17 Sep 2026 06:25:00 +0000

The problem: Old Russian orthography is a different beast

If you’ve ever tried to OCR a book published in Russia before 1917, you quickly run into a wall. The alphabet had four extra letters (ѣ, і, ѳ, ѵ), plus spelling rules that disappeared after the orthographic reform. Modern OCR engines trained on contemporary Russian will choke on words like «съ», «онѣ», or «всѣхъ».

But digitizing historical texts is crucial for linguists, historians, and even NLP researchers who want to train models on original sources. So what do we do?

The solution: A clean, paired dataset

I published russian-old-orthography-ocr on Hugging Face. It contains source images and human‑extracted ground‑truth texts from 19th‑century Russian publications – all in original pre‑reform spelling.

Long texts (novels, stories) → PDF + TXT in books-pdf-plaintext/
Single‑page samples → PNG + TXT in pages-img-plaintext/

File pairs share the same base name, e.g.

afanasjev-chuzhbinskij_a_s.peterburgskie_igroki.pdf and .txt, or

300_page_image_009.png and 300_page_text_009.txt.

Why this dataset rocks for developers

✅ Ready to train – images + ground truth, no scraping or alignment headaches

✅ Covers real 19th‑century typography – including tricky pre‑reform letters

✅ Perfect for fine‑tuning Tesseract, TrOCR, or any CRNN model

✅ Also useful for NLP – language modelling, old‑to‑modern conversion, historical text analysis

Old orthography, demystified

Those four extinct letters have their own Unicode code points, but you also have to handle the old rules (e.g., hard sign at the end of words, и vs і). I wrote a Python package to convert between old and modern orthography: prereform2modern.

Here’s a taste:

from prereform2modern import convert

old_text = "Онъ былъ въ Петербургѣ и видѣлъ тамъ всѣхъ."
modern_text = convert(old_text)
print(modern_text)  # Он был в Петербурге и видел там всех.

You can use it to augment your OCR training pipeline, evaluate model output, or build a transliteration API.

A real example

(imagine an old Russian page here – typefaces, ѣ, і, the whole vibe)

Corresponding ground truth:

7

вамъ это происшествіе со всѣми должными приправами: съ непритворнымъ ужасомъ на лицѣ, въ глазахъ; съ содроганіемъ; съ восклицаніями и, наконецъ, съ поднятіемъ рукъ къ Небу!… Вы увидите какъ это послѣднее тѣлодвиженіе картинно въ немъ.»

Notice the ъ at the end of words, the ѣ in «небе», the `і» in «происшествіе». This is what your OCR model needs to learn.

What can you build?

Specialised OCR for historical Russian documents (archives, old newspapers, diaries)
Old‑to‑modern transliteration service (like prereform2modern on steroids)
Evaluation benchmark for any OCR engine claiming to support pre‑reform Russian
Synthetic data generator – convert the ground truth back to old orthography and render different fonts

Get started in 30 seconds

bash git clone https://huggingface.co/datasets/nevmenandr/russian-old-orthography-ocr cd russian-old-orthography-ocr ls books-pdf-plaintext/pdf # pick a PDF ls pages-img-plaintext # or a PNG+txt pair

Then pair each image with its text, train your model, and watch it learn to read like a 19th‑century typesetter.

Let’s talk

Have you worked with historical languages in OCR? Ever fought with pre‑reform Russian? Drop a comment below – I’d love to hear your stories, ideas, or questions. And if you find the dataset useful, share this post so others can discover it too.

👉 Dataset on Hugging Face

👉 prereform2modern on PyPI

Happy (old) reading! 📖👓

🧠 I Trained a Massive Word2Vec Model on 13 Billion Russian Fiction Words — Here’s What Happened

Boris Orekhov — Mon, 07 Sep 2026 06:14:00 +0000

TL;DR: I built a lemma‑based Word2Vec model (CBOW, 300d) on a huge corpus of Russian fiction (13B tokens → 7.3B after cleaning). You can load it with Gensim and explore semantic neighborhoods of words like слово, язык, речь. The model captures literary semantics without stop words or grammar tags. Check it out on Hugging Face.

Why another word2vec for Russian?

Most pre‑trained Russian word2vec models are trained on web crawls, news, or mixed corpora. That’s fine for general NLP, but fiction has its own semantic rules. Poetic metaphors, archaic vocabulary, and author‑specific styles shift vector spaces.

I wanted a model that:

Is trained exclusively on fiction (from classic to modern authors).
Uses lemmas (no inflection noise).
Is small enough to ship (197 MB for the main model, plus two 5.8 GB arrays).
Lets researchers and developers play with literary semantics.

So I built one. And I’m sharing it under the MIT license.

The Corpus by Numbers

Metric	Value
Raw words before preprocessing	13.98 B
After lemmatization & stop‑word removal	7.36 B
Sentences (after cleaning short ones)	1.36 B
Paragraphs processed	~539 M

Stop words: removed using this list.

Lemmatizer: Yandex Mystem.

Sentence splitter: razdel.sentenize.

All lemmas are lowercase, dictionary form, no part‑of‑speech tags (saves time & space).

Training Details

import gensim

data = gensim.models.word2vec.LineSentence('splitted_lemmed_lines.txt')
model = gensim.models.Word2Vec(
    data,
    vector_size=300,
    window=10,
    min_count=2,
    sg=0          # CBOW (faster, good for large corpora)
)
model.save('cbow_300_10.model')

CBOW, not skip‑gram – slightly better syntactic capture for fiction.
Window size 10 – balances local and long‑range dependencies.
Min count 2 – very rare words become noise; keep it clean.

The training script is plain Gensim – no weird dependencies. You can retrain or fine‑tune if you have more data.

What’s Inside the Download?

When you clone from Hugging Face, you get:

cbow_300_10.model (197 MB) – the main Gensim model object
cbow_300_10.model.syn1neg.npy (5.8 GB) – negative sampling weights
cbow_300_10.model.wv.vectors.npy (5.8 GB) – the actual word vectors
README.md, tst.py – docs and a test script

Yes, the two .npy files are large. But you can load the model without loading both if you only need similarities (Gensim does lazy loading). Or use model.wv directly.

Quick Start – Get Similar Words

import gensim

model = gensim.models.Word2Vec.load("cbow_300_10.model")

# Look at closest neighbours of "слово" (word)
for word, score in model.wv.most_similar("слово", topn=10):
    print(f"{word}: {score:.4f}")

Output:

фраза: 0.7941
словечко: 0.6602
слог: 0.6322
реплика: 0.6015
словосочетание: 0.5928
изречение: 0.5818
высказывание: 0.5800
глагол: 0.5735
эпитет: 0.5615
сентенция: 0.5556

Notice how epithet and verb pop up – the model clearly learned linguistic meta‑concepts from fiction.

Now try язык (language / tongue):

наречие (adverb) 0.6684
диалект 0.6095
латынь 0.5892
язычок (little tongue) 0.5698
алфавит 0.5039
грамматика 0.5027
суахили 0.4977
идиома 0.4952
иврит 0.4950
произношение 0.4927

And речь (speech):

монолог 0.6400
спич 0.5914
тирада 0.5900
фраза 0.5652
диалог 0.5477
проповедь 0.5334
слово 0.5217
разглагольствование 0.5193
филиппика 0.5184
декламация 0.5147

Cool Things You Can Do

Author style analysis – Compare vector spaces of Tolstoy vs. modern authors.
Semantic change over time – Not directly, but you can train separate models for 19th and 20th century subsets.
Genre classification – Fiction vs. non‑fiction (though this model is pure fiction, so it will be biased).
Creative writing tools – Find thematic associations, generate metaphor candidates.
Educational – Show how word geometry reflects literary concepts.

Known Limitations (Read Before You Complain)

No POS tags – All lemmas are ambiguous (e.g., стекло could be noun “glass” or past tense of “to flow”). That’s a conscious trade‑off for performance.
Only lemmas – No inflected forms. Want слова, слову, словом? You won’t find them; use the lemma слово.
Fiction bias – This model will perform poorly on legal documents, tweets, or technical manuals. But that’s the point.
Large memory footprint – The full model takes ~12 GB on disk. However, you can load just the vectors with KeyedVectors.load() to save RAM.

Comparison with Other Russian Word2Vec Models

Model	Corpus	Size	POS	Availability
This one	Fiction, 13B words	300d	No	MIT, HF
w2v-russian-tolstoy	Only Tolstoy	300d	No	MIT, HF
w2v-russian-19c-fiction-lemmas	19th century prose	300d	No	HF
RusVectores (web+news)	Mixed, ~20B	300d	Yes (tags)	CC BY‑SA

If you need a general‑purpose model with grammatical info, go for RusVectores. If you work with literary analysis, this one is your friend.

Why You Should Star / Share / Fork

📦 Ready to use – pip install gensim and model = gensim.models.Word2Vec.load(...)
🧪 Reproducible – Full preprocessing script included in the HF repo.
📚 Academically referenced – Several papers already used it (see README).
🚀 Lightweight core – The 197 MB model loads in seconds; the big .npy files are optional.

Get the Model

Hugging Face: nevmenandr/w2v-russian-fiction

License: MIT

Clone with git lfs or download via huggingface_hub:

from huggingface_hub import snapshot_download
snapshot_download(repo_id="nevmenandr/w2v-russian-fiction", local_dir="./w2v_model")

What I’d Love to See in the Comments

🧩 Use cases – Are you doing computational literary studies? Building a Russian story generator? Tell me!
🐛 Issues / improvements – Did you find a bug? A word that should be a lemma but isn’t?
📊 Benchmarks – How does it perform on your task compared to other models?
🧠 Funny analogies – Run model.most_similar(positive=['царь', 'женщина'], negative=['мужчина']) and share the result. (Hint: it’s not “царица” – fiction is weird.)

Final Code Snippet – Try It Yourself

import gensim

model = gensim.models.Word2Vec.load("cbow_300_10.model")

# Find words similar to "поэт" (poet)
print("Neighbors of поэт:")
for w, s in model.wv.most_similar("поэт", topn=5):
    print(f"  {w}: {s:.4f}")

# Analogy: Москва : Россия = Париж : ?
result = model.wv.most_similar(positive=["Франция", "Москва"], negative=["Россия"], topn=1)
print(f"\nМосква / Россия ≈ Париж / {result[0][0]} (score {result[0][1]:.4f})")

Run it. Play with it. Break it. Then tell me in the comments what you found.

Happy vector hunting! 🧙‍♂️

P.S. The model is called cbow_300_10.model – old‑school name, but it works like a charm.

How I Ended Up Publishing My Coding Journey – and Why CoderLegion Made It Worthwhile

Boris Orekhov — Tue, 01 Sep 2026 22:50:00 +0000

A few weeks ago, I received an unexpected message.

It came from the CoderLegion community team. They'd noticed my engagement on the site and asked if I'd be interested in sharing my programming journey as part of their "Developer Stories" series.

My first reaction? Skepticism, if I'm honest. I've been around long enough to know how these things usually go. Platforms reach out, they promise visibility, they ask for content, and then... crickets. Your carefully written piece gets buried under an avalanche of "10 JavaScript Tips You Won't Believe" and disappears into the void.

But something about their approach felt different. They were direct, genuine, and – most importantly – they'd actually read what I'd written before reaching out. That's rarer than you'd think.

"But I'm not a real developer"

I felt I should be upfront. I replied that I'm not a professional software engineer – I'm a researcher, a scientist, a humanities guy who learned to code out of necessity. My code has never been production-grade, I've cut more corners than I care to admit, and my early work still makes me wince in hindsight.

Would that kind of story still be of interest?

Their response was immediate and unequivocal: "Absolutely."

No gatekeeping. No "well, let's see if it fits our editorial direction." Just a straightforward recognition that a researcher's pragmatic, messy, real-world coding journey might actually be more relatable than another polished success story from a FAANG engineer.

That was the moment I decided to say yes.

From philology to Python – and everything in between

I wrote the piece over a couple of days. It wasn't difficult – the memories came flooding back. PHP without templates, Perl without use strict;, Python without a debugger, all held together with hope and echo statements. My "server" was shared hosting that ran CGI scripts, and my "database" was a handful of MySQL tables that today I'd replace with a JSON file.

The story wrote itself, really.

When I sent it over, I braced myself for edits, rewrites, or the dreaded "this is great, but could you make it more technical?" None of that happened.

Why CoderLegion stands out

Now that the piece is live, I want to share a few thoughts about the platform itself – because it genuinely deserves attention.

1. It's a small community, and that's a good thing

Platforms like DEV.to have become enormous. That's great for reach, but it also means your carefully crafted post competes with thousands of others. Unless you're writing about the latest JavaScript framework or AI trend, you're shouting into the void.

On CoderLegion, the community is smaller, but the engagement feels more genuine. My posts there get modest view counts – but they're still several times higher than on DEV.to. People actually read, reflect, and respond. It reminds me of the early internet, where community meant something.

2. They treat contributors like humans, not content factories

This is the big one. The person who reached out didn't just send a template email and move on. They read my work, understood its value, and engaged in a thoughtful, personal conversation throughout the entire process. The editorial support was light-touch but effective – they helped my story shine without making it theirs.

Too many platforms treat contributors as interchangeable content providers. CoderLegion doesn't.

3. They allow republishing

This might seem like a small thing, but it matters. CoderLegion permits authors to share content that's already appeared elsewhere. I haven't taken advantage of it yet, but knowing that I can – without being locked into exclusivity – lowers the barrier to participation significantly. It's a flexible, author-friendly policy that respects your time and effort.

What I'd tell other developers

If you're considering sharing your journey, here's my advice: don't overthink it.

You don't need to be a rockstar developer. You don't need to have built the next unicorn startup or contributed to major open-source projects. Your story – with all its false starts, bad habits, and lessons learned the hard way – is probably more valuable than you realise. Because somewhere out there, someone is making the same mistakes you did, and they'd benefit from hearing that it's okay.

Platforms like CoderLegion exist precisely to tell those stories.

Final thoughts

The piece went live recently, and I've already shared it with my Telegram audience. The response has been warm – several fellow researchers and self-taught coders reached out to say they saw themselves in the narrative.

That's the whole point, isn't it? To connect, to reassure, to remind each other that we're all figuring it out as we go.

So here's my public thank-you to the CoderLegion team. Thank you for reaching out, for trusting my story, for handling it with care, and for building a space where imperfect journeys are welcomed.

I'll be writing more about the experience on DEV.to soon – but for now, if you're curious, here's the piece itself:

https://coderlegion.com/25394/from-philology-to-python-how-i-fell-into-coding-and-why-my-code-still-makes-me-wince

And to anyone reading this: if you have a story to tell, tell it. You might be surprised who listens.

How to Actually Determine Authorship with a Computer (And Why Most People Get It Wrong)

Boris Orekhov — Thu, 27 Aug 2026 05:56:00 +0000

TL;DR: Most “computer‑based” author attribution you see on the internet is junk. Average word length? TF‑IDF + cosine similarity? Please. There’s a method that actually works – it’s called Delta, it’s 20 years old, and you can run it with a few clicks in R. Let me show you why the naive approaches fail and how real stylometry is done.

The problem with “obvious” methods

We’ve all seen it: someone grabs a few texts, computes average word distribution or most frequent words, draws a pretty line chart, and declares they can tell who wrote what.

Spoiler: they can’t.

A famous example – in 2018, a data scientist tried to identify the anonymous New York Times op‑ed “I Am Part of the Resistance Inside the Trump Administration”. He used TF‑IDF on Trump administration members’ tweets, computed cosine similarity, and concluded… the most likely author was Trump himself (or someone from State Department). Not very convicing.

That’s not science – that’s cargo‑cult data analysis.

Even worse, a 2023 book Python for Hackers dedicates a whole chapter to stylometry, yet it uses average word length and plots line charts copied from 19th‑century geophysicist Thomas Mendenhall. Yes, the same Mendenhall who thought word‑length distributions would work like spectral analysis of chemical elements.

Spoiler: they don’t. Grzybek (2007) already buried that idea.

So if those methods are garbage, what actually works?

Enter John Burrows and the Delta method (2002)

Burrows proposed a surprisingly simple distance measure between texts – Delta. It uses only the 100–500 most frequent words (mostly function words like “the”, “and”, “of” – not content words). That’s genius, because it ignores topic and focuses on style.

Here’s the intuition:

For each text, compute the relative frequency of each frequent word.
Convert to z‑scores (how many standard deviations above/below the corpus average).
Delta between two texts = mean absolute difference of their z‑scores across all words.

Small Delta → stylistically similar → probably same author.

No neural networks. No thousands of parameters. Just robust statistics.

And it works. On English, Russian, Arabic, Ancient Greek, even Chinese (yes, despite no clear word boundaries). Nobody knows exactly why – but it has been validated on hundreds of test cases.

How to run it without writing a single line of R

There’s an R package called stylo (Kestemont et al., 2016). It has a point‑and‑click GUI.

install.packages('stylo')
library(stylo)
stylo()   # GUI opens

You put your texts in a folder named corpus. Name files like author_title.txt – stylo automatically colors by author in the output.

It produces a dendrogram (cluster tree). If the method works, texts by the same author cluster together.

I tested 24 Russian prose texts (Lermontov, Chekhov, Leskov, Gogol). One unknown text (“???”) was supposed to be by Leskov. Result: 23 out of 24 correctly clustered. Only one early Chekhov story drifted to Lermontov – because Delta is sensitive to author’s evolution over time.

The unknown text landed right with Leskov.

Not perfect – but far better than random guessing.

Case studies that (sort of) worked

Rowling / Galbraith (2013)

When J.K. Rowling published The Cuckoo’s Calling as “Robert Galbraith”, stylometrists quickly identified her as the author. Rowling later confessed. A model case, right?

Well… stylo includes a galbraith dataset. I ran it. The data are hand‑picked: authors from different centuries and genres, making Rowling stand out artificially. A more honest test? Still works, but less dramatic. Always question your benchmark.

The Quiet Don (Sholokhov)

The famous Russian novel has been suspected to be plagiarised from Fyodor Kryukov. Delta analysis (using 100+ texts) shows:

It’s not Kryukov.
“Don Stories” (signed Sholokhov) and “The Quiet Don” cluster together → same author.

Politics aside, the data are clear.

Bitcoin white paper (Satoshi Nakamoto)

Here the method is abused. The white paper has only ~3700 words – well below the recommended 10k+ minimum. Still, curious minds ran it: the paper clustered with Craig Wright.

Should you trust that? Absolutely not. But it’s fun.

Where Delta breaks (and why you should care)

Different genres – comparing a play to a novel makes no sense. Remove the play.
Theological texts – for unknown reasons, Delta often fails on religious writings. Atheist algorithm?
Short texts (< 10,000 words) – too noisy. Don’t even try.
Authors who change style radically – early vs. late Chekhov can look like different people.

So it’s not magic. But when used correctly, it’s the best we have.

For the curious programmer

If you want to dig deeper:

Burrows, J. F. (2002). Delta: A Measure of Stylistic Difference.
stylo package: https://github.com/computationalstylistics/stylo
My colleague’s visualisation (better than dendrograms): distributions of intra‑author vs inter‑author distances.

And a fascinating book: Passwords: Philology, Security, Authentication by B. Lennon (2018) – it traces the common roots of cryptography and stylometry. The first US crypto‑analysis unit hired… English professors who argued over Shakespeare’s authorship.

Final verdict

Next time someone shows you a line chart of average word lengths to “prove” who wrote something, send them this post. Real authorship attribution is harder – but also more reliable when you use proper methods like Delta.

And remember: if the text is shorter than 10,000 words, just walk away. No method can save you.

Try it yourself:

Download a few texts by two different authors (>10k words each), name them author1_title.txt, run stylo(), and see if they separate. You’ll be surprised how well it works.

Chess plays as data for word2vec models

Boris Orekhov — Mon, 17 Aug 2026 05:42:00 +0000

♟️ You shall know a piece by the company it keeps

Chess plays as data for word2vec models

Programmers, have you ever looked at a PGN file and thought: this looks like a language?

What if we trained word2vec on 5.4 million chess games, treating each move as a word and each game as a sentence? Would the vectors capture anything about chess strategy? Or would it be nonsense?

I asked exactly that. And the results are surprisingly… meaningful.

🔗 Original preprint: arXiv:2407.19600

🧩 The core idea

Word2vec relies on the distributional hypothesis: a word’s meaning is defined by its context (neighbouring words).

Orekhov’s move: apply the same to chess moves.

He built 18 different models from a corpus of ~5.4M high‑level games (≈840M moves).

Two main approaches:

Type 1 – moves only (each move = a word, game = sentence)
Type 2 – moves + board state (each “sentence” = current position + the move)

Then: train word2vec (skip‑gram / CBOW), get dense vectors (300‑500 dims), and run the usual NLP tricks – nearest neighbours, odd‑one‑out, analogies, t‑SNE visualisations.

🔍 What the model learned (without ever seeing a board)

Test	Result
Quasi‑synonyms	Closest vectors to `Pe2e4` are `Pe2e3`, `Ng1f3`, `Pd2d4` – exactly what you’d expect.
Odd one out	`[Pe2e4, Ng1f3, Pd2d4, Bf1c4, Nb1c3, Pb4b5]` → `Pb4b5` is flagged (edge pawn move, rarely an opening).
Analogies	`king - man + woman ≈ queen` for words. For chess: `Pe2e4 - Pf2f4 + pe7e5` suggests `pe7e6` (French Defence). Works.
Castling detection	`Ke1g1` (short castling) → closest vectors include `Rh1f1` and `Ke1c1`. The model learned that king and rook move together.
Endgame clusters	t‑SNE shows extremely clean, piece‑separated clusters. Openings are messy (all similar).
Bishop colour	Light‑squared and dark‑squared bishops form different clusters – the model learned chess‑relevant semantics.
Captures as “POS tags”	Adding `_CAP` / `_N` made moves cluster by destination square instead of source piece. A new kind of “part of speech” for chess.

📊 Over 68% of moves have at least 3 of their 10 nearest neighbours being the same piece moving to the same square. That’s not random – it’s structural.

🤯 The most beautiful visualisation

The model trained on games without queens produced a perfectly symmetric t‑SNE plot – white moves on one side, black moves mirrored.

The algorithm had no concept of “colour” as a feature. Yet the distributional signal was so strong that the two colour spaces separated like antipodal points on a sphere.

⚠️ The honest conclusion (refreshing for a paper)

“I don't see how this representation can be used productively. It's unlikely to help engines or humans choose the best move. But in a purely academic sense, it captures something important about the nature of the game.”

No overhyped “this will revolutionise chess AI”. Just a clean, curious application of NLP to a symbolic system – and it works.

🧰 For the hacker’s toolbox

All models are public on HuggingFace: nevmenandr/w2v-chess
Code & data: PGN corpus of 5.4M games (freely available online)
Techniques used: word2vec, t‑SNE, cosine distance, analogies, “stemming” (removing source square), part‑of‑speech tags for captures

📚 Cite this work

APA

Orekhov, B. (2024). You shall know a piece by the company it keeps. Chess plays as a data for word2vec models. arXiv preprint. https://arxiv.org/abs/2407.19600

IEEE

B. Orekhov, “You shall know a piece by the company it keeps. Chess plays as a data for word2vec models,” 2024. [Online]. Available: arXiv:2407.19600

MLA

Orekhov, Boris. “You Shall Know a Piece by the Company It Keeps. Chess Plays as a Data for Word2vec Models.” arXiv, 2024, https://arxiv.org/abs/2407.19600.

BibTeX

@misc{orekhov2024shallknowpiececompany,
      title={You shall know a piece by the company it keeps. Chess plays as a data for word2vec models}, 
      author={Boris Orekhov},
      year={2024},
      eprint={2407.19600},
      archivePrefix={arXiv},
      primaryClass={cs.CL},
      url={https://arxiv.org/abs/2407.19600}, 
}

👉 Would you run word2vec on Go games? Poker hands? Protein folding sequences? The method is language‑agnostic – and that’s the real lesson.

Natural Languages vs. Programming Languages

Boris Orekhov — Fri, 07 Aug 2026 05:30:00 +0000

Natural Languages vs. Programming Languages: Same Word, Different Worlds

We call them both “languages” – but does a for loop have anything in common with a love poem? Turns out, yes and no. And the differences are way more interesting than you might think.

The Reason We Have Languages (Either Kind)

Languages exist to pass information around. Human languages gave us tribes, then kingdoms, then sci-fi novels about interstellar travel – written centuries before anyone ever left Earth. That’s flexibility.

Computers, on the other hand, speak machine code: raw numbers and arithmetic operations. BB 11 01 means something to a CPU, but to a human? It’s a headache. So in the late 1950s, we invented programming languages – a human-readable middle layer that gets translated into machine code. That’s why you can write if user.is_active: instead of pushing hex bytes around.

How Human Languages Lie (and Why Code Doesn’t)

Russian says “dождь идёт” – “the rain walks”. English says “it rains” – “it rain-verbs”. French says “il pleut”. None of them are true: there’s no walker, no “it”, just water falling from the sky. Human languages force reality into their own grammar.

Machine code has zero such illusions. It’s brutally literal: take this number, add that number, put the result there. No metaphors, no actors, no walking rain.

Low‑Level vs High‑Level – It’s Not a Class Thing

“Low‑level” languages (like assembly) stay close to the machine – you tell the CPU every tiny step. “High‑level” languages (Python, JavaScript) let you say “make it pretty, I don’t care how”. The naming reflects our narcissism: humans at the top, computers at the bottom.

The Real Killer Difference: Narration vs Commands

What do we do most with natural language? We tell stories.

I woke up dressed in an armchair,

In my own flat among familiar walls…

Now try to write that in C. All you get are assertions: I_am = dressed; I_am = awake; my_location = armchair; Clunky, right? Programming languages are built almost entirely for the imperative mood – do this, go there, set that. They’re instruction manuals, not novels.

Want to talk about the past? Good luck. Natural languages handle tense effortlessly. In code, the past doesn’t matter unless you explicitly store it. And concepts like “spiritual thirst” (Pushkin’s famous line) can’t be mapped to a variable – thirst = 0 is just an empty box, not a longing.

But People Still Write Poetry in Code

Yes, really. There are esoteric languages like Shakespeare, where the source code looks like a Renaissance play. And people have written poems in Python and JavaScript – some for everyone, some for the elite few. The results are awkward, fascinating, and beautifully absurd.

Bottom Line

Both language families have words and grammar. But natural grammars are universal – they can describe anything from a rainy street to a broken heart. Programming grammars are narrow, laser‑focused on giving commands. One tells stories, the other gives orders. And that’s why you can’t import a soul.

Chess & Computer Tech Today – A Programmer’s Take

Boris Orekhov — Mon, 27 Jul 2026 05:25:00 +0000

Chess & Computer Tech Today – A Programmer’s Take

Remember when beating a human at chess was the holy grail of AI? In 1972, it was literally the benchmark. Fast forward to today: a random office desktop crushes any grandmaster. Game over? Not even close.

Chess didn’t die – it went full cyberpunk. And as a programmer who barely knows a fork from a fianchetto (my Lichess rating is ~800), I’ve become obsessed with how code reshaped this ancient game. Here’s what every dev should care about.

1. Analysis engines – the real MVP

Every chess move today gets instantly judged by an engine. That little “thermometer” on stream? It’s a live eval bar. One blunder, and the score tanks from +2 to -3 – you feel the drama.

But here’s the fun part for us: I built vector models of chess games using word2vec. Treating moves like words in a sentence. Preprint here: arxiv.org/abs/2407.19600. Turns out, chess positions embed nicely into vector space. Who knew?

2. Cheating – from SMS to… sex toys?

Cheating in chess is not like doping. A single engine move at the right moment = game over. So offline tournaments scan players like airport security.

But the real WTF moment: during the 2022 Carlsen–Niemann scandal, Elon Musk suggested Niemann might have received moves via a remote-controlled vibrating sex toy hidden inside his body. Yes, seriously.

And how would you encode a chess move without Bluetooth? French team at 2010 Olympiad used SMS + captain standing near imaginary chessboard squares. Programmers, think about it: you could encode a move with just 2 vibrations (source square, target square). Someone even wrote Python demo for that.

3. Online chess – pre-moves, flag-hunting, and lag

Online blitz (3+0, 3+1) is a different beast. Premoves let you queue your next move while opponent thinks. Click, and it executes instantly when their move arrives. No physical clock button. No “oops I dropped the knight”.

But then you get flag-hunting – players in losing positions spam premoves hoping the winner runs out of time. Old-school champ Kramnik calls it unethical. New generation says “it’s in the rules”.

The ultimate test? A 2024 match between Kramnik (legend, hates flag-hunting) and Jospem (online phenom, suspected cheater). Half the games OTB, half online, same room back-to-back. Result: inconclusive. But the drama? Chef’s kiss. Also, organizers printed fresh laptops – Windows updates caused lag only for one player. Conspiracy? Probably just Windows.

Why it matters for devs

Chess is no longer about “intelligence”. It’s about psychology, emotion, and… code. We built machines that play perfect chess, then humans kept playing anyway. Now we’re debating: does a premove change the nature of the game? Is online chess “real” chess? Can we detect cheaters from move statistics?

These are our questions – systems design, anomaly detection, real-time constraints, UI/UX of time controls.

And the best part? No definitive answers. Just like software engineering.