Content Analysis v3: From the Semantic Web to the Entity Layer of AI
Fifteen years after IKS and Apache Stanbol, entity resolution is becoming core infrastructure for AI. Content Analysis v3 turns language into stable Wikidata identities across eight languages, and it abstains when the evidence is thin. On our evaluation sets it already scores higher than Google Cloud Natural Language in German, English and Spanish. Here is how it works, what we measured, and where it still fails.
Fifteen years after IKS and Apache Stanbol, entity resolution is becoming core infrastructure for AI.
Generative AI has made producing text remarkably easy. Understanding what that text is actually about remains much harder.
Take a simple sentence:
Apple opened a new store in Paris.
A language model reads it effortlessly. A system that wants to build reliable knowledge from it has to answer more precise questions. Is Apple the company, the fruit or the record label? Is Paris the French capital or the town in Texas? What types of things are they, and which identifiers represent them? And, most importantly: when should the system admit that it does not have enough evidence to decide?
These questions sound very current in the age of AI agents. For us they are not. We have been working on them for more than fifteen years. Content Analysis v3 is the latest chapter of a journey that began before WordLift existed as a company, with the European IKS project, Apache Stanbol, DBpedia and a group of brilliant people who taught us to see content not as strings of words but as a network of identifiable things.
What has changed is the scale of the problem. Entity resolution is no longer only about enriching a CMS or adding structured data to a page. It increasingly determines how AI systems reconstruct the world. Which brings us back to the oldest question in our field: what are we talking about?
It started with IKS
In 2009 the European Commission launched the Interactive Knowledge Stack (IKS), a four-year FP7 research project coordinated by Salzburg Research. Its goal sounds remarkably contemporary: give content management systems a layer of semantic intelligence, so that software could operate on knowledge and not only on documents.
From that work came Apache Stanbol, an open-source framework for semantic content management. Stanbol brought together what we would now call an AI enrichment pipeline: language detection, named entity recognition, entity linking, controlled vocabularies, semantic indexing, reasoning.
In 2012 Olivier Grisel and Rupert Westenthaler presented Automated Linking Data with Apache Stanbol at WWW2012. Rupert would later become my partner in Redlink; at the time, he and Olivier were among the people teaching us how to think rigorously about semantic content analysis. One phrase from that work has stayed with me ever since:
Get to know your content.
It sounds simple. It is not. The point was never to detect the word Paris. It was to determine that the text referred to Paris, France, attach a stable identifier to it, understand what kind of thing it was, and connect it to a wider graph of knowledge. That shift, from strings to things, changed the way we thought about content.
From Stanbol to WordLift
We were not watching from the outside. By 2012 some of the early technology that would become WordLift was already being contributed back to Apache Stanbol: language processing with FreeLing, entity recognition against Freebase, enrichment with DBpedia, and a refactoring layer that translated extracted knowledge toward Schema.org.
The technologies have changed almost completely since then. The architectural idea has not: content analysis should produce reusable knowledge, not annotations trapped inside an NLP service. An entity needs an identity. That identity must be resolvable and reconcilable with other knowledge, and publishers and organizations should be able to build their own knowledge on top of it.
This is why we still support the DBpedia project today. Open knowledge infrastructure and shared identifiers remain fundamental to an interoperable web. This is not nostalgia for the Semantic Web. It has become more relevant in the age of AI.
The world has come back to entities
For several years the dominant AI narrative moved in the opposite direction. Embeddings could encode meaning, vector databases could retrieve similar passages, LLMs could extract facts directly from text. Perhaps explicit entities and identifiers were no longer necessary.
Then we started looking inside modern AI systems, and the entities were there.
In our research on ChatGPT’s web interface, we observed OpenAI carrying structured entity objects alongside conversational responses: people, organizations, events, products. More recently, studying local search inside ChatGPT, we found something even more concrete. ChatGPT resolves local businesses into structured objects with an internal entity_lookup_id (of the form lbe1_...), carrying name, coordinates, address, category, website, ratings and reviews. We were able to connect these objects with externally verifiable Google place identities. And we saw the resolved entity being carried forward into the experience:
query → entity resolution → entity panel → follow-up retrieval
These are observations of the current ChatGPT web experience, not a public OpenAI API contract. But the architectural direction is clear. The question for an AI system is no longer only which document should I retrieve? It is increasingly which real-world entity does this document refer to? Once that identity is established, it becomes part of the interface and part of the context for whatever happens next.
What Rupert and Olivier were solving inside a semantic CMS in 2012 is now happening inside one of the world’s most advanced AI interfaces. The scale is different and the models are vastly better, but the problem is familiar: language has to be reconciled with identity.
Enter Content Analysis v3
Content Analysis v3 is our newest implementation of that idea, and one of the foundations of WordLift’s Context Engine: a semantic-resolution layer that turns unstructured language into entities with stable identities, types and evidence, ready to enter a Knowledge Graph or an AI workflow.
The production system works across eight languages (English, Italian, French, German, Spanish, Portuguese, Japanese and Chinese) against a Knowledge Base of approximately 13.67 million Wikidata entities, 34 million surface forms and 13.67 million semantic vectors, plus almost 11 million DBpedia abstracts covering more than 5 million entities.
It still starts from a fundamental distinction: finding an entity is not the same as knowing what it is. Named Entity Recognition tells us that Apple is an Organization and Paris is a Location. Useful, but insufficient for a graph. A graph needs identity, and that is the job of Named Entity Disambiguation: Apple is Wikidata Q312, Paris is Q90. A label tells us that something looks like an organization. An identifier tells us which organization.
That stable identity is what lets knowledge discovered on one page connect with data found elsewhere: reconciled across languages, joined with proprietary data, linked to DBpedia, mapped into Schema.org, used by retrieval, or preserved as context for an agent.
So Content Analysis v3 treats recognition and disambiguation as a single system:
content → language detection → entity recognition → candidate retrieval → reranking → abstention → entity identity
The output is not a list of keywords. It is grounded context.
How it resolves identity
Recognition starts with GLiNER on a multilingual DeBERTa architecture. The harder stage comes afterward: for each mention, the system has to find possible identities among millions of entities and decide which candidate, if any, the author actually meant.
Candidate retrieval combines two kinds of evidence. Lexical: a search across millions of labels and aliases for exact and approximate matches. Semantic: BGE-M3 embeddings provide vector retrieval over the entity collection, so we can find candidates even when the text and the canonical label do not match.
The candidates are then evaluated by a multilingual BGE reranker cross-encoder. Unlike a vector similarity score, the cross-encoder reads the mention in its surrounding context jointly with the candidate’s label, description and encyclopedic information. In production we deliberately keep a large candidate pool, because at this scale eliminating the right candidate too early is often impossible to repair later.
Finally, the system combines that semantic evidence with lexical priors, entity typing and other signals before deciding what to return. And one possible answer is, deliberately, nothing.
A false edge is worse than no edge
This is probably the most important principle in Content Analysis v3: the system is allowed to abstain.
A missing relationship can be enriched tomorrow. A wrong one quietly contaminates everything built on top of it: retrieval, recommendations, analytics, generation, agent reasoning.
This led us to separate evidence from confidence. A model can produce a high numerical score and still be wrong. Worse, apparent confidence can shift simply because the candidate set changed. So Content Analysis asks two distinct questions: which candidate should rank first? and do we have enough evidence to accept it? Signals that are useful for ranking do not automatically count as evidence for accepting an identity.
That may look conservative for an NLP application. For a Context Engine it is essential.
The Knowledge Base is part of the model
It is tempting to imagine that the model does the intelligence and the Knowledge Base is just data attached to it. Entity linking shows why that is wrong.
We saw it clearly with Portuguese. Recognition performed well, but our entity layer lacked Portuguese labels, aliases and Wikipedia mappings. The system knew a phrase was an entity; it did not have the local-language knowledge to say which one. After rebuilding the Knowledge Base with the right Portuguese data, performance changed dramatically.
Japanese and Chinese made the lesson stronger, and produced some of our most useful failures. Performance was initially very poor, and it would have been easy to blame the multilingual model. The real culprit was tokenization: our default strategy assumed word boundaries that do not exist in Japanese and Chinese the way they do in European languages. With proper segmentation, exact-span recall in our tests went from roughly 5% to above 80% in Japanese, and from roughly 3% to almost 80% in Chinese. We added Unicode normalization, traditional-to-simplified folding for Chinese and CJK-specific type logic, then rebuilt the Knowledge Base with Japanese and Chinese labels and aliases. End-to-end linking improved dramatically too.
Chinese is still where the system is weakest, and that is useful information. Entity linking cannot be reduced to choosing a better foundation model. Labels, aliases, descriptions, Wikipedia mappings, normalization, tokenization and evaluation data all have to be multilingual. One of the principles now written into the Content Analysis repository says it well:
Adding a language is a knowledge-base job, not a code switch.
Quality is a system property.
More knowledge creates more ambiguity
Scaling the Knowledge Base taught us something counterintuitive: more knowledge can make entity linking harder.
With a small dictionary, an exact string match looks almost definitive. Expand to tens of millions of labels and aliases, and the same string can point to a company, a football club, a political organization, a place, a product, a person or a creative work. Coverage improves, and ambiguity grows with it.
Shortcuts that worked with a smaller collection became unsafe. Exact matching could no longer be equated with identity. Retrieval had to become broader, reranking more important, abstention critical.
This is why I consider the current architecture state of the art. Not because we added one new model, but because of how the pieces work together: multilingual NER, a 13.7M-entity lexical layer, dense semantic retrieval, cross-encoder reranking, semantic typing, evidence-aware abstention and evaluation on the live system. The intelligence is in the system.
How state of the art are we?
We wanted an external reference point, so we built a harness to compare Content Analysis v3 with Google Cloud Natural Language’s entity-linking service, using the same mention-matching rules and the same eight evaluation sets for both: 666 entity mentions in total.
| Language | Content Analysis v3 F1 | Google Cloud NL F1 |
|---|---|---|
| German | 94.1 | 92.6 |
| English | 88.9 | 88.0 |
| Spanish | 90.7 | 86.5 |
| Italian | 87.8 | 89.2 |
| French | 85.3 | 87.4 |
| Japanese | 77.2 | 80.0 |
| Portuguese | 91.6 | 97.6 |
| Chinese | 66.2 | 74.8 |
| All languages | 85.8 | 87.3 |
We do not universally “beat Google”, and that is not the interesting conclusion. The interesting one is more specific. Content Analysis v3 achieves higher F1 on our German, English and Spanish sets, and higher recall in German, English, Spanish, Italian and French. Across all eight languages recall is essentially tied (82.9% versus 82.0%). Google’s advantage is precision, 93.3% against our 89.0%, which gives it the stronger aggregate F1.
Some caveats. These are small, deliberately difficult evaluation sets, not a universal benchmark. Our own data construction may introduce some home-field advantage. And Google’s API exposes a single operating point, while Content Analysis can move along the precision/recall trade-off through its abstention threshold: at the 0.7 acceptance threshold we currently use, it reaches 91.0% precision and 86.1 F1 overall.
So this is how I would put it: the system we actually operate, not a research prototype, is in the same performance territory as a mature commercial entity-linking API, with measurable wins in three languages and clear areas where Google is stronger. I find that more interesting than declaring victory, because we can see what to improve next.
Owning the improvement loop
When Content Analysis makes a mistake, we can ask why. Was the entity absent from the Knowledge Base? Was the right alias missing? Did NER pick the wrong span? Was the correct entity never retrieved as a candidate? Did the cross-encoder choose the wrong reading? Did typing distort the result? Or should the system simply have abstained?
Being able to decompose failure is one of the most valuable properties of this architecture. Our evaluation framework lets us replay candidate sets and inspect every changed entity decision before we release a modification. The question is not just did F1 improve? but which entities changed?
A recent example: SAP, in German. NER correctly identified it as a company, but a vocabulary rule was inadvertently lending support to the Swedish Social Democratic Party, because party appeared in organization-related type evidence. We fixed the rule. Across twenty evaluation ledgers (gold and live entity types, multiple datasets) exactly one production decision changed: SAP moved from the wrong political entity to abstention. No correct links were lost, German precision went up, and we shipped it.
Other apparently clever changes were rejected. One reranking adjustment improved results dramatically against perfect gold entity types. Tested with the types actually produced by the live GLiNER pipeline, it increased the number of confidently wrong links. It did not ship.
That is now another core principle: evaluate the system your users actually run.
From entity extraction to the Context Engine
Content Analysis v3 analyzes text and URLs and preserves the relationship between entities and the source HTML. Once a mention becomes a stable identity, it can be reused across pages, languages and datasets: in a Knowledge Graph, in Schema.org markup, for search and recommendations, for GraphRAG, for an agent’s context.
content → entity resolution → Knowledge Graph → retrieval and reasoning → content and actions
I increasingly think of Content Analysis as a semantic compiler. Human language is the source language. Entities, types, identifiers and evidence are the intermediate representation. The Knowledge Graph is the durable, machine-readable context that comes out of it.
In 2009 we called this Semantic Content Management. Today we talk about Context Engines, GraphRAG and AI agents, and identity has become much more than an SEO concern. It is AI infrastructure. An Entity Graph can represent what an organization knows. A Lexical Graph can preserve the language and distinctions it recognizes. An Action Graph can describe what agents are allowed to do. All of these layers depend on something more primitive. Before an agent can reason about your company, product, store, destination, molecule, paper or customer, it has to answer a simpler question: which one?
That is the problem Content Analysis v3 is designed to solve.
Help us break it
Benchmarks are necessary. Your content is harder.
So take something from your website. Try an obscure company, a local business, a product with an ambiguous name, a football club that shares its name with its city, a person known only by their surname, a sentence that requires domain knowledge. Try it in any of the eight languages. Then don’t just look at the highlighted words: inspect the entity. Did we find the right identity? Did we abstain when we should have? Where did we get it wrong?
Try Content Analysis v3 on the WordLift Entity Extraction page.
That is the feedback we want.
More than fifteen years have passed since IKS, and since Rupert, Olivier and the Apache Stanbol community taught us to think in terms of entities, reconciliation and open knowledge. Models have become vastly more powerful, but the Semantic Web did not disappear. Some of its most important ideas moved deeper into the stack, and they are resurfacing inside search engines, Knowledge Graphs, multimodal models and AI agents.
The fundamental question has barely changed: what are we talking about? Getting that identity right is where reliable AI context begins.