Cut LLM Misclassification with Hierarchical Classification

When AI classifies abstract concepts directly, its judgments are inconsistent and misclassification increases. Instead, let AI judge concrete categories and let code deterministically handle the mapping to abstract parent concepts, and you can cut misclassification sharply. This design principle applies not only to classifying search intent in a GEO content pipeline but to any task where you need AI to classify something.

Content strategy starts with understanding search intent accurately. Wrong classification leads to the wrong content and halves the value of keyword research. The problem is that an instruction that looks intuitive, like "classify this keyword as awareness, exploration, decision, or action," is actually very hard for AI.

Why direct classification fails

Hand a framework like funnel stages straight to AI and you get inconsistent judgments.

Why does this happen? Funnel stages are an abstract framework that marketers made up. Exactly where the "exploration stage" starts and ends is interpreted differently by different people, and by different models.

Here's the key insight. Models are good at judging things that are concrete and observable, and bad at judging things that are abstract and need interpretation.

• "Does this keyword contain a price-related word?" → observable, so easy
• "Which stage of the buying journey is this keyword in?" → needs interpretation, so hard

The two-stage structure of hierarchical classification

The way to solve this is to split the judgment into two stages. Prompt engineering research has repeatedly confirmed that decomposing complex tasks into modules raises accuracy^[1].

Step 1: The model judges (concrete categories)

  "price" → qualify    "vs" → compare    "how to" → action
  "what is" → concept  "recommend" → recommend  "error" → solve

  → The model only needs to judge observable signals

              (deterministic code)

Step 2: Code maps (abstract parent concepts)

  concept   → Awareness
  recommend → Exploration
  compare   → Exploration
  qualify   → Decision
  action    → Action
  solve     → Action

The point is this: the model gets only the easy job (judging concrete categories), and code handles the hard job (abstract mapping).

Four design principles

Principle 1: Mutually exclusive top-level categories

Boundaries between categories must be clear. "recommend" and "compare" are conceptually similar, but they can be told apart by signals: phrasing like "recommend me" versus phrasing like "vs."

Principle 2: Make errors harmless with many-to-one mapping

This is the core of the pattern.

Suppose the model confuses recommend and compare:

  "Recommend X" → model: compare (misclassified)
                    ↓
               code mapping: Exploration  ← same result anyway

  "Recommend X" → model: recommend (correct)
                    ↓
               code mapping: Exploration  ← identical result

Because recommend and compare both map to the "exploration" stage, the final result is the same even if the model confuses them. You can't prevent every misclassification, but by mapping similar categories to the same parent group, you can build a structure where a misclassification doesn't affect the final result.

Principle 3: Confidence-based fallback

Add a safeguard so that when the model's confidence in a category is low, it falls back to a default value. Rather than forcing ambiguous cases into one category, marking low confidence and handling them with a safe default makes the whole system more stable.

Principle 4: Code mapping must always be deterministic

Code mapping must always give the same output for the same input. The essence of this pattern is a structure that offsets the model's nondeterminism with the determinism of code.

In practice: before and after

Before (classifying abstract concepts directly)

After (concrete category → code mapping)

Uses beyond search intent classification

Hierarchical classification isn't a pattern just for search intent. You can apply the same structure to most tasks where AI needs to categorize something.

Content topic tagging: if you ask directly "what is this post's main topic?", judgments easily split from model to model. Instead, have the model first judge observable features like "does this post mention pricing?", "does it have a comparison table?", or "does it have a step-by-step procedure?", and let code decide the topic from that combination. It's far more stable.

Inquiry and ticket classification: if you classify customer inquiries straight into abstract priorities like "urgent/normal/low," the criteria wobble. Classifying concrete signals first, like "is there a mention of a refund?" or "is there a mention of a service outage?", and letting code decide priority from the combination of signals is far more consistent.

Competitor content classification: rather than classifying competitor content by abstract tone like "aggressive/defensive," catching concrete signals first, like "does it mention price directly?" or "does it mention our brand name?", and mapping the higher-level tone in code makes results more reproducible.

The pattern is the same in all three cases. Instead of handing the model an abstract judgment that even people find ambiguous, break that judgment into the observable pieces that make it up, and let code handle the combination.

The GEO angle: balancing funnel coverage

If classification skews toward one category (usually concept explainers), you overproduce awareness-stage content and miss chances to be cited by AI for exploration, decision, and action questions^[3]. When hierarchical classification splits categories precisely, you can see in the data which stages are short on content and fill them in a balanced way. This also connects to the principle that content must match search intent exactly^[2].

When do you need three or more stages?

In most cases, two stages (concrete category → abstract parent concept) are enough, but when there are very many categories or the domain is complex, you can consider a three-stage structure. For example, inserting one more stage, as in "concrete signal judgment → intermediate category → final funnel stage."

There are cautions when going to three or more stages, though. When the mapping tables grow to two, the management burden grows with them, and the risk that errors at each stage accumulate into the next stage rises too. Decomposing complex reasoning into simpler subproblems is effective in itself^[1], but you need to account for the fact that the more decomposition stages you add, the higher the cost of managing each stage's accuracy separately.

So before considering three or more stages, first check "which misclassifications actually remain when we handle this in two stages?" If the remaining misclassifications are concentrated in a few specific categories, it's often more efficient to subdivide just that one category than to extend everything to three stages.

Practical tips for reducing misclassification

1. Around six categories is the sweet spot. Too few and distinctions blur together; too many and the model starts confusing the boundaries.
2. Don't give the model hard judgments, only easy ones. "Which stage of the buying journey is this?" is an abstract judgment even experts disagree on. Ask only for observable judgments like "does it contain a price-related word?"
3. Many-to-one mapping doesn't drive errors to zero; it makes them harmless. Mapping similar categories to the same parent group creates a structure where a misclassification doesn't affect the final result.
4. Manage the mapping table in only one place. When mapping logic is scattered across many places, inconsistencies creep in.
5. Manage test data systematically. Build a ground-truth set from real keywords and measure accuracy every time something changes. Classification sits upstream in the content pipeline, so accuracy here determines overall quality.

In the end, hierarchical classification is a design sense for "precisely separating what the model is good at from what it isn't." Resist the temptation to hand every judgment to AI, give it only the easy ones, handle the rest with deterministic code, and you can build a much more stable system.

You can continue with llms.txt is a signpost for AI agents, not a ranking button, Getting products recommended by AI shopping agents: a guide to structuring product information, and Design principles for a GEO data AI agent: structured tool calls and blocking irreversible actions.