Under the hood · Entity extraction
How Korely builds your knowledge graph, on your machine
Korely runs a small open weights entity extraction model on every note you save: people, projects, places, concepts. The model in the slot today is GLiNER, one of a wider family we compare further down. Notes that share entities become connected on their own, with no manual wikilinks and no tagging discipline.
Concept
What entity extraction is
Think of a kid reading a history textbook with three colored highlighters. People get highlighted in pink, places in green, dates in yellow. Entity extraction is the same idea, only the highlighting happens automatically as you write.
When you write "Met with John Smith from the customer about the Q3 launch", a model reads that sentence and returns three entities: John Smith (person), the customer (organisation), Q3 launch (project). Then the same model reads the next note, and the next, and pretty soon you have a list of every person, project, place, and concept that recurs across your vault.
In Obsidian-style apps you can do this by hand: you type
[[John Smith]]
and the link is preserved. Korely runs the extraction
automatically. You write naturally, the connections appear
on their own.
The model today
The model in the slot today
Korely today runs GLiNER, an open source named entity recognition model under Apache 2.0. It ships inside the Korely desktop bundle and is downloaded once on first run.
- Architecture: zero shot transformer based NER. The model accepts the labels you care about at inference time, so it can extract any entity type without retraining.
- Default labels: Person, Project, Place, Organisation, Concept. You can add custom ones in Settings.
- Quantization: int8, runs on CPU.
- Disk: around 150 MB for the weights, plus a few KB per note for the extracted entities and mentions.
- Languages: English, Italian, French, Spanish, German, and a long tail of other languages. Entities extracted from notes in different languages still merge if they refer to the same thing.
That "zero shot" bit is what makes GLiNER feel different from most NER models. Think of it as a friend who can spot anything you point at, with no preparation. "Find the people" and they do. "Find the brand names" and they do that too. You don't have to train them for each new request, you just tell them what you're looking for.
How the graph builds itself
How the graph builds itself
Think of the knowledge graph like a detective's pin board on the wall. Every important name, place, project, or concept becomes a pin. Threads run between pins when they show up in the same note. After a few months of writing, you can stand back and see what's actually connected in your work, without ever having drawn a single arrow yourself.
The flow runs every time you save or edit a note:
- Korely runs GLiNER on the text and gets back a list of entities with their types.
- For each entity, Korely either creates a new row in the graph table or links to an existing one. "John Smith" mentioned in note A and "John Smith" mentioned in note B point to the same entity, with two mentions.
- Two notes that share at least one entity become related. The relatedness score grows with the number of shared entities, weighted by how rare each one is across the vault.
-
The graph table is what powers
korely_get_related, the knowledge graph view in the app, and the GraphRAG retrieval that AI tools use through MCP.
If you mention a customer in a meeting note in March and again in a follow up in May, the May note surfaces in the March note's sidebar without any explicit linking. If you write a research note about a concept in English and a brainstorm note about the same concept in Italian, both connect to the same entity.
In the same family
Other entity extraction tools in the same family
Picture three readers sitting at a long table, each with their own way of underlining the proper nouns in a book. One was trained in a classroom on a thousand grammar rules. One was sent to school by a research team. One can spot anything you point at without preparation. GLiNER is the third type, but the other two are equally real and equally useful for different jobs. Here is the rest of the shelf.
- spaCy (Explosion AI, MIT). The veteran of the shelf. Not a single model, more like a library of pre-trained NER pipelines for over twenty languages, used in production for years. Picture the librarian who learned every language in school and never forgot any of them.
- Stanza (Stanford NLP, Apache 2.0). The academic option. Built by Stanford's NLP group, comes paired with full linguistic analysis (parts of speech, parsing) on top of entity extraction. Picture the linguistics PhD who marks up every sentence with grammar arrows before answering your question.
- NuNER v2.0 (NuMind, MIT). A foundation model designed to be the starting point for your own fine-tuning, rather than an off the shelf tool. Picture the apprentice who picks up a custom vocabulary fast once you sit down to train them.
- GLiNER (the model Korely runs today, Apache 2.0). The zero-shot friend who can spot anything you point at, no training required, just tell them what to look for and they do.
Korely chose GLiNER because the zero-shot behaviour fits the use case: a user's vault has unpredictable labels ("our suppliers", "our funding rounds", "the books I am reading") and asking the user to train a model first would be a non-starter. The other family members would shine in other contexts: spaCy when you have a fixed schema and want production reliability, Stanza when you also want grammar analysis, NuNER when you want to invest in a custom-trained model.
We tested supervised pipelines and zero-shot transformers side by side before settling on this one. Zero-shot won for one practical reason: every vault has a different vocabulary. One has "suppliers" and "funding rounds", another has "patients" and "medications", a third has "sources" and "case files". A model that has to be trained first would die at the first install. GLiNER reads the labels at inference time, so the same model on everyone's machine handles every vault out of the box.
On your CPU
Everything runs on your CPU
GLiNER runs on the CPU every time you save or edit a note. The latency is in the tens of milliseconds for short notes, up to about a second for very long ones. Extraction happens in the background, so the editor never blocks.
The entity graph is a small SQLite table next to your vault. A vault of 10,000 notes typically has a few thousand unique entities and tens of thousands of mentions. Disk overhead is in the single digit megabytes.
In Free mode with cloud sync off, the model and the graph both stay on the device. The text of your notes never touches a network.
Frequently asked
What is entity extraction? +
Entity extraction is the task of pulling the named things out of a piece of text: people, projects, places, organisations, concepts. A model reads the note and returns a list of entities along with the type of each one.
Which entity extraction model does Korely use? +
GLiNER, an open source zero shot named entity recognition model under Apache 2.0. It runs on CPU, supports custom entity labels, and works across multiple languages.
How does the knowledge graph get built? +
Every time you save a note, GLiNER pulls out entities. Korely stores each entity once in the database along with every note that mentions it. Two notes that mention the same entity become related automatically.
Will my graph sync if I turn on Pro cloud sync? +
Yes. The entity graph is part of the synced vault, so all your devices see the same connections. The GLiNER model itself stays on every device. The extraction runs locally.
Can I see and edit the graph? +
Yes. Korely has a graph view that shows your notes as nodes and their entity based connections as edges. You can also rename, merge, or remove extracted entities directly on each note.
See your graph build itself
Free forever for the local vault. The model downloads once, then your notes connect themselves for the rest of their life.