Information Has Many Faces: Why Concept Tagging Is More Than an LLM Call

Language is what LLMs do. Trust is what knowledge graphs are for.
The graph gives the model something true to say; the model gives the graph a way to say it. 

There is a quiet shift happening in a lot of content pipelines. Concept tagging, the unglamorous but load-bearing work of figuring out what a document is actually about, is being handed to a large language model (LLM). In the best case the model is grounded in a taxonomy. Often it is just asked, in plain language, to “list the relevant topics.” It works in a demo. The tags look plausible. The temptation to retire the old machinery is real.

We think that’s worth a closer look, because the question is not whether an LLM can produce a tag. It can. The question is whether the tag is correct, whether it is the same tag tomorrow, whether you can explain why it was assigned, and whether anything downstream can reuse it. Those four properties are exactly where context, and a graph, start to matter.

Why a plausible tag is not the same as a useful one

A tag in isolation is cheap. A tag that is disambiguated, connected to everything else you know, reproducible, and traceable to its source is an asset. The gap between the two is the difference between a system that demos well and one you can put in real-life production systems.

This matters most in the domains where Graphwise tends to work: science, law, finance, regulated industry. In those settings, “plausible-sounding” is not a feature. In fact, it can often be a liability. A generative model interpolates over token distributions. Ask it the same question twice and you may get two answers, with no record of how either was reached. For a one-off summary, fine. For metadata that feeds search, analytics, compliance reporting, and downstream agents, drift and opacity are expensive.

The deeper issue is that meaning is contextual, and an LLM tagging a document in isolation has thrown most of the context away. It does not know that in your organization a “position” on the trading desk is not a “position” in HR, or that a “control” in your regulatory framework is a specific, defined obligation rather than a general English word. That knowledge is not in any foundation model’s training data, and it never will be, because it is yours.

What we mean by “advanced semantic analytics”

We use the broad term advanced semantic analytics on purpose, because information has many faces. The same fact can show up as an explicit mention, as an unstated implication, as a relationship between two entities, or as an event unfolding across several documents. Reading all of those faces takes a family of techniques (entity recognition, entity linking, classification, relation and event extraction), not a single prompt.

What ties the family together is the move underneath each task: every result gets anchored to a knowledge graph. That is what turns an extracted label into something contextualized. Once a concept is a node in your graph rather than a string in a list, it inherits everything the graph already knows: its broader and narrower terms, its relationships, its definition, its place in your domain model. And because the graph is connected, that context can be followed in a multi-hop way: not just “what is this,” but “what is this connected to, and what is that connected to.” A flat tag list cannot do that. A graph does it natively.

Tagging is often a classification problem, not a search problem

Here is the part that catches a lot of LLM-only tagging out. In complex domains, the right concept is frequently not in the text at all.

Take a corporate sustainability report that states the company “focuses on ethical and responsible working conditions” and “continual improvement… voluntary participation in ISO 14001.” A reader who knows the domain recognizes occupational safety risk and environmental risk being addressed, even though neither phrase appears. Naïve mention-matching finds nothing. A plain LLM might guess, inconsistently. What you actually want is to treat the passage as a classification task against a structured set of risk categories, and to let the graph’s inference engine resolve the specific tags from the general ones: from “non-financial risk” down to “occupational safety risk,” “regulatory risk,” “environmental risk.” The connectedness of the graph is what makes that inference principled and repeatable rather than a lucky guess.

Linking means disambiguation, not just recognition

Recognizing that a span of text is a named entity is the easy half. The hard half is deciding which entity it is, and ambiguity is often inherent to the domain rather than incidental.

This is the problem our in-house model CEEL (Common English Entity Linking) was built for. CEEL links English text mentioning People, Locations, and Organizations to their exact instances in Wikidata – a knowledge base of roughly 42 million concepts of these types (out of over 100 million entities overall). It’s not just the scale that’s the challenge – in addition to that Wikidata is gloriously ambiguous. For example, there are over 600 distinct concepts labelled “china” and a similar number labelled “japan.” A lookup, or a generic model, collapses under that. 

CEEL treats disambiguation as a first-class step: detect the mention, generate candidates through hybrid lexical-plus-vector retrieval, then score them with a transformer that weighs context, descriptions, and entity types. Trained on a small, focused corpus, it reaches around 88% F1 on the standard AIDA benchmark while linking against a knowledge base seven times larger and far noisier than the one most published results use. Just as deliberate, though, was a decision not to chase evaluation numbers for their own sake. We built CEEL for production rather than for the top of a leaderboard: it runs on commodity hardware, CPU included, and tags a standard piece of content in a few seconds. A model that scores a fraction higher but is too slow or too expensive to run at enterprise volume has solved the wrong problem. The point is not the leaderboard number; it is that getting linking right against real-world ambiguity, at a speed and cost you can actually deploy, is hard work that an off-the-shelf prompt does not do.

Relationships and events: where the graph earns its keep

The richest faces of information are the relational ones. “Which suppliers of our top-five customers are exposed to a sanctioned entity?” is not a similarity question. It is a question about connected facts. Extracting those facts (relations between entities, events that link several of them) is exactly where a dense, high-quality graph contributes the most, because the graph supplies the surrounding structure that tells you whether a candidate relation is plausible in the first place.

We see this across very different fields. In a drug-discovery knowledge graph built for NuMedii, the work was to annotate large volumes of scientific literature with genes, diseases, compounds, and drug concepts, and then mine the relations among them: the connections, not the mentions. In a financial-news setting, our relation and event detector turns raw articles into structured events for risk and opportunity assessment. In both cases the graph is what gives the extracted relationship meaning beyond the sentence it came from.

How the graph and the model fit together

None of this is an argument against LLMs. The honest framing is that “LLMs versus knowledge graphs” is a false choice, and the state of the art is hybrid, a view the wider market is converging on. Each side does what it is genuinely good at.

The graph supplies structured, trustworthy context to the model and provides the vocabulary, constraints, and relationships that ground a tagging or linking decision. In some cases, the model can accelerate the extraction itself, proposing candidates, reading messy prose, breaking ties on hard cases. The graph then closes the loop: validating, deduplicating, and providing the data to reason over what was extracted, so that each new document incrementally enriches your institutional memory rather than vanishing after a single prompt.

That loop is also why the economics differ. An LLM answer is ephemeral; a graph triple is an asset that search, analytics, recommenders, and agents can all reuse. Materializing knowledge once and querying it is cheaper and faster than asking a model the same question ten thousand times. And because every triple carries a source and can be validated against formal constraints, you get the lineage that regulators ask for, something a chat log cannot give you.

So by all means use an LLM in your tagging pipeline. Just don’t ask it to be the pipeline. Concept tagging, done well, is advanced semantic analytics: reading the many faces of information, anchoring each one in a graph, and leaving behind knowledge you own, rather than inference you rent.

Learn more about the interaction between concept tagging, taxonomies and AI!