This blog article focuses on three questions:

1. Why is intent classification needed?
2. What should an intent represent?
3. What classification approaches are available?

The aim is not to provide a complete machine-learning survey. It is to explain the main design choices and how they support semantic query.

1. Why Intent Classification Is Needed

Intent classification identifies what the user is trying to achieve before the system searches the semantic layer.

Consider the questions

What is InterestRatePayout?
Where does floatingRateIndex map?
What does MapSwapPayout do?
Compare InterestRatePayout between CDM 5 and CDM 6.

These questions require different kinds of knowledge and different operations:

• model definition retrieval;
• mapping lookup;
• function explanation;
• version comparison.

Without intent classification, the system may search across unrelated knowledge sources and retrieve many plausible but irrelevant results.

Intent classification helps determine:

• which knowledge providers should be searched;
• which entity types are expected;
• which semantic operations are relevant;
• which query-plan structure may be required.

Its purpose is therefore straightforward:

Identify the user’s objective and constrain downstream semantic processing.

2. What Should an Intent Represent?

An intent should represent the user’s broad objective.

Examples include:

REFERENCE_MODEL_QUESTION
MAPPING_QUESTION
VERSION_COMPARISON
FUNCTION_QUESTION
CODE_GENERATION
DATA_ONBOARDING

An intent should not represent every detailed action.

For example:

GET_DEFINITION
GET_ATTRIBUTES
GET_PARENT
GET_CHILDREN

are better represented as semantic operations under a broader intent:

intent: REFERENCE_MODEL_QUESTION
requested_operations:
  - GET_ATTRIBUTES
  - GET_PARENT

The distinction is:

Intent describes the user’s goal.
Semantic operations describe the actions needed to fulfil it.

This keeps the intent catalogue smaller, clearer, and more stable.

3. Rule-Based Classification

Rule-based classification uses explicit phrases, patterns, and structural signals.

Examples include:

"what is"          → REFERENCE_MODEL_QUESTION
"map to"           → MAPPING_QUESTION
"what does ... do" → FUNCTION_QUESTION
"CDM 5 and CDM 6"  → VERSION_COMPARISON

A simple implementation may use phrase matching:

if "map to" in normalized_query:
    return "MAPPING_QUESTION"

A more structured implementation can combine several conditions:

rule:
  id: version-comparison-rule
  conditions:
    all:
      - contains_two_version_references
      - contains_any:
          - compare
          - difference
          - changed
          - added
          - removed
  predicted_intent: VERSION_COMPARISON
  confidence: 0.98

How It Works

The classifier checks the normalized query for known signals.

These may include:

• keywords;
• multi-word phrases;
• regular-expression patterns;
• version references;
• technical identifiers;
• question structures;
• combinations of several conditions.

Each matched rule can produce:

• a candidate intent;
• a confidence score;
• evidence showing why the rule matched.

For example:

matched_signals:
  - phrase: map to
    candidate_intent: MAPPING_QUESTION
    confidence: 0.97
  - identifier_style: camelCase
    value: floatingRateIndex

Strengths

Rule-based classification is:

• deterministic;
• easy to explain;
• inexpensive;
• fast;
• useful when technical phrases strongly indicate intent.

It works particularly well for expressions such as:

mapped from
attributes of
callers of
difference between
removed in version
generate mapping

Limitations

Rules struggle when the user expresses the same objective indirectly.

For example:

How does floatingRateIndex reach CDM?

This is likely a mapping question, but it does not contain the word map.

Rules can also conflict:

Compare how floatingRateIndex maps in CDM 5 and CDM 6.

This query contains both mapping and version-comparison signals.

A rule-based implementation therefore needs:

• scoring;
• rule priority;
• conflict resolution;
• ambiguity handling;
• an out-of-scope fallback.

Where It Is Used in Practice

Rules are commonly used for:

• high-confidence technical phrases;
• compliance-sensitive routing;
• unsupported-query detection;
• mandatory conditions;
• deterministic overrides;
• capturing obvious version or operation expressions.

They are usually most effective as one component of a broader classifier rather than as the complete solution.

4. Classical Machine-Learning Classification

Classical machine-learning methods learn intent patterns from labelled examples.

Common algorithms include:

• Logistic Regression;
• Support Vector Machines;
• Naive Bayes;
• Random Forests;
• Gradient Boosting.

How It Works

The query is converted into numerical features. Common features include:

• word TF-IDF;
• character TF-IDF;
• word n-grams;
• character n-grams;
• query length;
• technical-identifier presence;
• version-reference presence;
• domain-specific keywords.

For example:

Where does floatingRateIndex map?

may produce:

features:
  word_terms:
    - where
    - floatingRateIndex
    - map
  word_bigrams:
    - where does
  character_ngrams:
    - rate
    - index
    - mapp
  has_camel_case_identifier: true

The classifier calculates a score for each intent:

intent_scores:
  MAPPING_QUESTION: 0.88
  REFERENCE_MODEL_QUESTION: 0.08
  VERSION_COMPARISON: 0.04

Strengths

Classical models are:

• fast;
• inexpensive to run;
• straightforward to evaluate;
• stable after training;
• suitable for high-volume classification.

Character n-grams are particularly useful for technical queries because they can handle:

• unfamiliar identifiers;
• spelling mistakes;
• naming-style variations;
• partial lexical similarity.

Limitations

These models depend heavily on the labelled training data.

They may struggle with:

• indirect expressions;
• new terminology;
• unseen intents;
• long conversational context;
• complex compound questions.

Adding or changing intents normally requires:

• new labelled examples;
• retraining;
• reevaluation;
• redeployment.

Where It Is Used in Practice

Classical classifiers are useful when:

• the intent catalogue is stable;
• a large reviewed query log exists;
• latency must be very low;
• most queries are short and repetitive;
• the task is mainly driven by lexical patterns.

They are often used as a strong baseline or as a production classifier for mature, narrow domains.

5. Fine-Tuned Transformer Classification

A fine-tuned transformer classifier starts with a pretrained language model, such as BERT or RoBERTa, and then trains it on labelled examples from the organisation’s own intent catalogue.

The pretrained model already understands general language patterns. Fine-tuning teaches it how those patterns should be interpreted within a specific enterprise domain.

The process is typically:

Pretrained language model
        ↓
Labelled enterprise queries
        ↓
Fine-tuning
        ↓
Domain-specific intent classifier

For example, the training data may include:

- query: What is InterestRatePayout?
  intent: REFERENCE_MODEL_QUESTION
- query: Show the attributes of InterestRatePayout.
  intent: REFERENCE_MODEL_QUESTION
- query: Where does floatingRateIndex map?
  intent: MAPPING_QUESTION
- query: How is floatingRateIndex transformed into CDM?
  intent: MAPPING_QUESTION

During fine-tuning, the model learns which contextual language patterns are associated with each governed intent.

How It Works

The query is first converted into tokens and passed through the transformer encoder.

The encoder produces a contextual representation of the whole query. A classification layer then converts that representation into a score for each supported intent.

Query
   ↓
Tokenisation
   ↓
Transformer encoder
   ↓
Contextual query representation
   ↓
Classification layer
   ↓
Intent scores

Unlike simple keyword or TF-IDF methods, the model considers how words are used together.

For example:

Where does this field map?

and:

Show me a map of the model.

both contain the word map, but the surrounding context is different.

A fine-tuned transformer can learn that the first query is about semantic mapping, while the second may not be.

It can also recognise paraphrases such as:

Where does this field map?
Which target does this field populate?
How does this value reach CDM?

These queries use different wording but may express the same broad intent.

Strengths

Fine-tuned transformers can:

• recognise paraphrases;
• interpret words in context;
• distinguish closely related expressions;
• perform well on domain-specific language;
• provide fast inference after deployment;
• produce consistent results for a stable intent catalogue.

Limitations

Fine-tuning requires:

• a sufficiently large and representative labelled dataset;
• clear and stable intent definitions;
• training and deployment infrastructure;
• retraining when the intent catalogue changes;
• monitoring for changes in user language.

The model can also learn problems in the training data.

For example, if most mapping questions contain the word map, the model may become overly dependent on that word and perform poorly on indirect expressions such as:

How does this value reach CDM?

It is also normally a closed-set classifier. This means it tends to select one of the known intents even when the query is unsupported.

Out-of-scope and ambiguity detection therefore need additional controls.

Where It Is Used in Practice

Fine-tuned transformer classification is most useful when:

• the intent catalogue is reasonably stable;
• a reviewed query history is available;
• the organisation has enough labelled examples;
• query volume justifies a dedicated model;
• low-latency classification is important.

A common pattern is to begin with rules, embeddings, and LLM-assisted classification, then use the reviewed production queries to train a dedicated transformer classifier later.

The trained model can handle routine, high-volume queries, while ambiguous or low-confidence cases are passed to an LLM or another fallback process.generated enough production data.

6. Embedding-Based Classification

Embedding-based classification represents both the query and the intent definitions as vectors.

The process is:

Query
   ↓
Embedding model
   ↓
Query vector
   ↓
Similarity against intent representations
   ↓
Ranked intent candidates

How It Works

Each intent can be represented using:

• a description;
• representative examples;
• an average prototype vector;
• a collection of labelled example vectors.

For example:

intent: MAPPING_QUESTION
description: >
  Questions about where a source field or semantic element maps,
  which target it populates, or how a mapping is represented.
examples:
  - Where does floatingRateIndex map?
  - Which target field does this populate?
  - What is the CDM destination for this field?

The query is compared with these representations.

Common Variants

Description Matching

The query is compared with one governed description for each intent.

This is simple, but the quality depends heavily on how clearly each intent is described.

Example Matching

The query is compared with representative examples.

This often works better because the examples reflect real user phrasing.

Prototype Matching

The vectors for several examples are averaged into one prototype per intent.

The query is classified according to the closest prototype.

k-Nearest-Neighbour Matching

The system retrieves the closest labelled examples and uses their labels as evidence.

For example:

nearest_examples:
  - query: Which CDM field does this populate?
    intent: MAPPING_QUESTION
    similarity: 0.91
  - query: Explain how this value reaches CDM.
    intent: MAPPING_QUESTION
    similarity: 0.86

Strengths

Embedding classification:

• requires little or no model training;
• handles paraphrases;
• supports rapid addition of new intents;
• produces ranked intent candidates;
• works well when the taxonomy is evolving.

Limitations

Closely related intents may have very similar embeddings.

For example:

MAPPING_LOOKUP
MAPPING_EXPLANATION
MAPPING_CODE_GENERATION

may all occupy nearby semantic space.

Similarity scores are also not calibrated probabilities. A similarity of 0.86 does not mean there is an 86% probability that the intent is correct.

Results also depend on:

• example quality;
• embedding-model choice;
• prototype construction;
• similarity thresholds.

Where It Is Used in Practice

Embeddings are often used for:

• Top-K intent candidate retrieval;
• matching new queries with historical examples;
• supporting rapidly changing catalogues;
• reducing the number of intents considered by a later classifier;
• identifying potentially out-of-scope queries.

They are usually better at candidate generation than final classification.

7. LLM-Based Classification

An LLM can classify the query using a governed intent catalogue supplied in the prompt or structured context.

The model may receive:

• the original query;
• the normalized query;
• allowed intent identifiers;
• intent descriptions;
• examples and counterexamples;
• active business context;
• known semantic operations;
• available capabilities.

Example input:

query: How does floatingRateIndex reach CDM?
allowed_intents:
  - REFERENCE_MODEL_QUESTION
  - MAPPING_QUESTION
  - VERSION_COMPARISON
  - FUNCTION_QUESTION

Example output:

primary_intent:
  id: MAPPING_QUESTION
  confidence: 0.89
requested_operations:
  - FIND_MAPPING
  - EXPLAIN_TRANSFORMATION
status: CLASSIFIED

Zero-Shot Classification

The model receives the intent names and descriptions without labelled examples.

This is useful when:

• the taxonomy is new;
• labelled data is unavailable;
• the intent definitions are clear.

Few-Shot Classification

The model also receives representative examples.

For example:

MAPPING_QUESTION:
  - Where does floatingRateIndex map?
  - How does this source value reach CDM?
VERSION_COMPARISON:
  - What changed between CDM 5 and CDM 6?
  - Was this attribute removed in version 6?

Examples help distinguish closely related intents and show the model how the taxonomy should be interpreted.

Constrained Structured Output

The LLM should not be allowed to invent intent names.

Its output should be controlled through:

• a predefined enum;
• a JSON schema;
• required output fields;
• validation against the active intent catalogue.

Invalid labels should be rejected.

Strengths

LLMs can:

• interpret indirect language;
• use conversational context;
• handle complex questions;
• adapt quickly when the taxonomy changes;
• work with relatively little labelled data;
• reason about the requested operations as well as the broad intent.

Limitations

LLM-based classification introduces:

• higher latency;
• higher cost;
• output variability;
• prompt sensitivity;
• weak confidence calibration;
• possible unsupported explanations;
• dependence on model availability.

The model’s confidence value should not be treated as a reliable statistical probability.

Where It Is Used in Practice

LLMs are useful when:

• the intent taxonomy is still evolving;
• queries are complex or conversational;
• labelled data is limited;
• business context affects interpretation;
• structured reasoning is needed.

They should normally operate within a governed catalogue and return a validated interpretation rather than directly selecting an unrestricted execution path.

8. Hybrid Classification

In real enterprise systems, the methods are often combined.

A practical flow is:

Query
    ↓
Deterministic signal detection
    ↓
Embedding-based candidate retrieval
    ↓
Contextual classification
    ↓
Catalogue and consistency validation
    ↓
Classification outcome

Stage 1 — Detect Strong Signals

Rules identify highly reliable expressions:

signals:
  - phrase: map to
    candidate_intent: MAPPING_QUESTION
    confidence: 0.97
  - versions:
      - CDM_5
      - CDM_6
    candidate_intent: VERSION_COMPARISON
    confidence: 0.91

Stage 2 — Retrieve Candidate Intents

Embeddings retrieve the most relevant intent descriptions or historical examples:

candidate_intents:
  - MAPPING_QUESTION
  - VERSION_COMPARISON
  - REFERENCE_MODEL_QUESTION

This prevents a later classifier from considering the entire catalogue.

Stage 3 — Apply Contextual Classification

An LLM or trained transformer evaluates the shortlisted intents using:

• the complete query;
• matched rules;
• similar examples;
• conversation context;
• expected operations;
• business-domain context.

Stage 4 — Validate the Result

The result is checked against:

• the active intent catalogue;
• allowed semantic operations;
• required query elements;
• expected entity types;
• available system capabilities.

Stage 5 — Return an Explicit Outcome

The result should not always be a single intent.

Possible outcomes include:

CLASSIFIED
AMBIGUOUS
OUT_OF_SCOPE
INVALID

For example:

intent_hypotheses:
  - intent: MAPPING_QUESTION
    score: 0.82
  - intent: VERSION_COMPARISON
    score: 0.79
status: AMBIGUOUS

The system preserves the uncertainty rather than forcing a decision.

Conclusion

Intent classification is not simply about attaching a label to a question. Its purpose is to identify the user’s objective and constrain the semantic processing that follows.

The main methods play different roles:

In real enterprise settings, these methods are usually used together and evolve as the capability matures. The best design is therefore not to choose one universal classifier, but to assign each method the role for which it is most effective.

• *AI-Native Financial Data Foundation