Concept-Vector Open Source: Turning Word Vectors into Readable Concept Lists

A Data Designer Who Went to Dismantle the Black Box of Word Vectors

In early June, a developer with the ID true-hum dropped their project, Concept-Vector—one they had been tinkering with for some time—into r/MachineLearning. The project's goal sounded a bit countercultural: while everyone else is stacking parameters and expanding context windows, what they want to do is take the black-box coordinates of word embeddings (those 300, 768, 4096 dimensions) and break them back down into human-readable conceptual dimensions.

In plain terms, it’s about labeling each dimension of a word vector: this dimension manages “whether it’s an animal,” that one manages “whether it’s past tense,” and the next may manage “whether it has high frequency of occurrence in the corpus.” Each dimension has a human-readable label that can be defined by humans.

The author is very candid—right up front, they say they come from a data design background, familiar with data transformation and data modeling, but with limited neural network experience. The project has not yet gone through full experiments on real models, and they don’t even have the funds for a proper test database. The post was mainly for gathering feedback and showcasing the idea—this is as far as they can push it for now.

Such candidness is actually rare in the ML community; most self-recommendation projects either hype themselves up massively or drown you in paper citations. Concept-Vector doesn’t have benchmarks, doesn’t claim SOTA; it’s just a design document plus a few scratch notebooks. But the problem it pinpoints is real: since Word2Vec came out in 2013, interpretability of word vectors has never been fully solved.

Why This Problem Hasn’t Been Cracked in Over a Decade

To understand what Concept-Vector wants to do, we must first go back to the fundamental problem of word vectors.

The generation of distributed representations like Word2Vec, GloVe, and FastText is based on the core idea that “words with similar contexts have similar vectors.” This approach works extremely well—“king - man + woman ≈ queen” became a classic example in beginner tutorials. But the trade-off is that each individual dimension has no fixed semantics. If you take a 300-dimensional vector for king, what does the 47th dimension represent? Nobody knows. In one training run it might capture “royalty,” but with a different random seed the 47th dimension becomes something else.

Subsequent research has tried many paths:

• Sparsification: Using L1 regularization or dictionary learning to make most dimensions zero, hoping that nonzero dimensions highlight some semantics. The result: sparsified, yes, but interpretability is still a matter of luck.
• Probing classifier: Training small classifiers to detect what information is encoded in the vector. This can tell you “syntactic information is in layer 6,” but not which dimension corresponds to the subject.
• Disentangled representation: Done in the VAE series, effective on images, but never mainstream in NLP.
• Dictionary learning + Sparse Autoencoder: A direction heavily pushed by Anthropic in recent years, using SAE to decompose model hidden layer activations into tens of thousands of interpretable features. Works well but is expensive to train, and the features are still grown by the model itself—humans only name them afterward.

Concept-Vector takes a different road—it’s not trying to interpret afterward, but to give dimensions meaning from the design stage.

Design Logic: Turning Dimensions into “Human-Defined Fields”

According to the readme and scratch notebooks released by the author, the core abstraction of Concept-Vector is roughly this:

• A concept-vector is a set of fields, each corresponding to a readable label.
• Field categories can cover semantics (animal, abstract noun), syntax (part of speech, tense, singular/plural), statistics (frequency, co-occurrence intensity), and theoretically any attribute you can define.
• Each field’s value method is decided by the designer—it can be binary (0/1), a continuous scalar, or discrete buckets.
• Multiple fields combined make a full concept-vector, which in principle maps to any downstream model’s embedding space.

This design method resembles more a database schema than a machine learning model. The author’s data design background shows: they treat each word as a row, each linguistic attribute as a column, and forcibly revert the vector space back to the world of relational models.

Advantages of this approach:

1. Controllable. You want the model to be sensitive to “tense”? Add a tense field. Want to distinguish proper nouns? Add a column. The meaning of each dimension is designed, not guessed.
2. Debuggable. If a word’s vector shows an abnormal value in one dimension, you can directly pinpoint which linguistic attribute is problematic, instead of staring blankly at a pile of floats.
3. Composable. Different languages and domains can share some fields (like part of speech) and extend others (like Chinese measure words, Japanese honorific levels).

But the costs are just as obvious.

The Problem: The Dilemma Between Annotation Cost and Expressiveness

Anyone who’s done some NLP will instantly ask: Where do these fields come from? Who annotates them?

A vocabulary can easily have hundreds of thousands of words, and each must be scored across dozens or even hundreds of fields. If done manually, this is the workload of old-school linguists building WordNet; if done with rules, coverage is incomplete; if inferred using existing models, you’re back to “using one black box to explain another.”

The author is aware of this, so the readme spends a lot of space discussing fields that can be hierarchical and inheritable—for example, under “animal” you can hang “mammal” and “bird” subfields, so annotating a higher-level concept propagates automatically to sub-concepts. This is a typical ontology approach, naturally aligning with the knowledge graph community.

Another concern is expressiveness. Word2Vec outperformed traditional one-hot and co-occurrence matrices mainly because it captured implicit semantics that aren’t exhaustively definable by human labels. You can define “royalty” and “gender” fields, but how do you define “this word feels sophisticated” or “this word leans negative in a financial context”? Language has too much fuzziness, continuity, and context sensitivity, forcing it into a schema will lose information.

Thus Concept-Vector will likely not replace distributed representations, but more likely serve as their interpretable index layer—original embeddings run underneath, with a concept-vector layer on top for debugging, filtering, and injecting rules.

Relationship to SAE and Knowledge Graphs

Placed on the current interpretability map, Concept-Vector occupies a subtle position.

Compared to Sparse Autoencoder: SAE is bottom-up, letting the model grow features itself, then humans name them afterward. Concept-Vector is top-down, humans define features first, then fit them. SAE’s advantage is discovering features humans wouldn’t think of; disadvantage is feature explosion, high naming cost, and some features defying explanation to this day. Concept-Vector’s advantage is readability from day one; disadvantage is expressiveness limited by the designer’s imagination.

Compared to Knowledge Graphs: Knowledge graphs also structure concepts, but they deal with relationships between entities (Beijing - capital - China), not internal semantic dimensions of words. Concept-Vector is more like pushing the field-based thinking of knowledge graphs down to the token level.

Compared to Probing: Probing is post-hoc diagnosis; Concept-Vector wants prior design. From an engineering angle, the former is more like APM monitoring, the latter more like writing typed code.

What It Could Be Used For

If this system can actually work (a big “if”), it could be interesting in these scenarios:

• Alignment and safety: You can directly see fields like “aggressiveness,” “sexual content,” “political sensitivity” in vectors, making filtering more transparent than training a classifier.
• Low-resource languages: Annotation cost is high, but once the schema is built, it can be reused across all downstream tasks in that language, eliminating repeated data loading.
• Domain specialization: Fields like medicine, law, and finance with strong ontology traditions already have existing term hierarchies; Concept-Vector can directly incorporate these priors.
• Debugging LLM embedding layers: If you suspect an LLM performs poorly in a certain semantic, Concept-Vector can be used as a probe to pinpoint which linguistic dimension is compressed or lost.

But to get there, the author still lacks many things. What’s missing most is not ideas, but compute and data—they state in the post they don’t have resources to build a test corpus. The project’s current state resembles an RFC, a design draft awaiting verification.

Some Frank Judgments

Some straight talk.

Concept-Vector at this stage isn’t usable. No trained weights, no benchmark data, no engineering scaffolding to interface with existing embedding models. The developer admits they’ve only pushed it to the design stage.

But as an idea, it’s worth attention from the NLP community, especially those focused on interpretability, for two reasons:

First, it represents a research paradigm neglected by the mainstream—starting from data modeling rather than from model architecture to tackle interpretability. In recent years SAE has flourished because in the era of large models, “bottom-up feature discovery” became feasible. But top-down design thinking has never been falsified; it’s just that nobody wants to spend time on tedious ontology work.

Second, it comes from someone outside the ML background. Honestly, ML’s competitive culture has a side effect: everyone is grinding micro-innovations within the same discourse system, and fewer people bring fresh perspectives from external disciplines. A data designer dismantling word vectors may not have the correct conclusions, but their viewpoint is different.

If you’re interested in interpretability or symbolic-neural hybrid representations, I recommend checking out the readme and scratch notebooks directly. This is the kind of project that will spark new questions in your mind after reading, more interesting than the 800th paper on RAG optimization.

By the way, doing such experimental research often requires comparing embeddings from different models—feeding the same text to GPT, Claude, Gemini, DeepSeek and seeing their respective semantic biases. OpenAI Hub aggregates these mainstream models under one key and one OpenAI-compatible interface, directly accessible domestically, making horizontal comparisons easier.

Final Notes

The field of word vectors has had its heat eclipsed by large models and attention mechanisms for years. But the question “What does a word actually mean” hasn’t been solved just because models grew bigger—it’s only been buried. Small projects like Concept-Vector bring it back to the surface, reminding us: interpretability doesn’t have to wait for SAE training completion; it can also start from a data schema.

Whether it can run depends on whether someone picks up the baton. But at least in this era—2026—when everyone is racing for trillion-parameter models, seeing someone quietly ponder how to make dimensions readable is rather comforting.

References

• Concept-Vector: A design framework for human-interpretable word embeddings - Reddit — Original post and the author’s self-description and discussion
• Understanding Word Vectors Word2Vec - Zhihu Column — Fundamental concepts of word vectors and Word2Vec principle review