What Is a Classifier? Definition and Examples

What is a classifier? It’s a model or system that assigns an input to a predefined category.

Give it a support ticket and it might label it “billing,” “bug,” or “feature request.” Give it an image and it might label it “invoice,” “receipt,” or “other.” Give it a job posting and it might sort the role into a function, seniority tier, or skill category.

The input can be text, an image, audio, a transaction, or a row in a spreadsheet. The output is a label you decided matters.

Classification turns a pile of messy information into something a product, analyst, or workflow can act on. That sounds simple because the basic job is simple. Defining categories that people can apply consistently is where the work starts.

TLDR

A classifier maps an input to a defined label, such as routing a ticket or sorting an image. Traditional models suit labeled, stable work at scale. Prompted LLMs fit changing categories and lower volume, while precision, recall, and F1 expose mistakes accuracy can hide.

Key Takeaways

• A classifier assigns an input to a predefined category.
• Clear labels matter as much as model choice.
• Traditional models, fine-tuned transformers, and prompted LLMs fit different operating constraints.
• Accuracy can hide failure when one class overwhelms the data.
• Production decisions should account for volume, latency, label availability, and the cost of mistakes.

What Is a Classifier

A classifier assigns inputs to predefined categories based on patterns it learned or instructions it received. Those categories are called classes.

A spam filter is a classifier. It receives an email and assigns a label such as “spam” or “inbox.” A request-routing system does the same thing with customer messages. A document-processing product may classify an uploaded file before deciding where it belongs.

The label set is fixed before the system starts sorting. That is the defining feature. A classifier does not begin by inventing its own organizational system. It maps each input to one of the categories you provide.

That makes classifiers useful whenever a team has recurring decisions that look alike. Which messages need a human reply? Which documents should enter a review queue? Which job postings belong to a particular function? Which transactions deserve fraud review?

The model can be sophisticated. The operating idea is still plain: input in, label out.

Classification can involve two categories or many. A fraud system may decide whether a transaction deserves review. A content moderation system may choose among several policy categories. A sales operation may classify inbound requests by account type, product interest, or urgency.

The hard part is often the label definition, not the algorithm.

“Enterprise lead” sounds like a category until people start applying it. Does company size decide it? Revenue? Buying intent? A named-account list? If sales, marketing, and the person preparing training examples each use a different definition, the classifier will learn a moving target.

Good labels describe a real decision. They should be mutually understandable, stable enough to matter, and tied to an action. If a label does not change what anyone does next, it may be clutter rather than a useful class.

Classifier Examples in AI Products

Support teams use classifiers to route incoming requests. A message about an account charge can go to billing. A report of broken behavior can go to technical support. A question about availability can go to sales. The label creates a path through the business.

Document products use classifiers before extraction or review. A system can identify whether a file is an invoice, a receipt, a contract, or something else. That choice determines the fields to extract and the workflow to run next.

Recruiting and labor-market products classify job postings by function, skill, seniority tier, location, or work arrangement. PE Collective publishes weekly data from 22,000+ job postings, the sort of feed where consistent categories become the product rather than a background implementation detail.

Image classification works much the same way. A quality-control tool might label a photo as acceptable, damaged, or unclear. A retail workflow can identify a product type. A medical imaging workflow may classify an image for further review, though high-stakes applications need domain-specific validation and human oversight.

Moderation is another familiar example. A platform can classify text, images, or user reports into policy categories. The label may trigger removal, escalation, reduced distribution, or a human review queue. Each action has a different cost when the classifier is wrong.

A classifier can also sit quietly inside a product feature. It may identify the topic of a meeting transcript, assign a document to a folder, or decide which saved response an agent should see. Users may never call it machine learning. They simply notice that the product puts things in the right place more often than it used to.

The category definition determines whether that experience feels useful or irritating. A classifier that creates labels nobody trusts has automated the argument, which is not much of an upgrade.

Traditional Models, Fine-Tuning, and LLM Prompts

There are several ways to build a classifier. The right choice depends on the data you have, how often categories change, the volume you expect, and how quickly the system must respond.

Traditional classifiers include logistic regression, random forests, and support vector machines. They train on labeled examples. You show the model inputs and the correct category, then it learns patterns that separate one class from another.

These models are often a good fit for stable tasks with enough labeled data. They can be fast and inexpensive to run once trained. They also make a lot of sense when a product needs to process a large stream of similar inputs.

Fine-tuned transformer models use a language model as the starting point, then train it further on examples from a specific classification problem. This approach can work well when meaning depends on context, phrasing, and domain language that simpler text features struggle to capture.

A fine-tuned model needs labeled examples and an evaluation process. It also asks more from the team running it: data preparation, training infrastructure, model versioning, monitoring, and retraining when the input distribution changes. That overhead is worth it when the task is important and persistent.

Prompted LLM classification takes a different route. Instead of training a dedicated classifier, you provide category definitions and examples in a prompt, then ask the model to choose a label.

That can be useful when categories are new, change often, or lack labeled training data. It gives a team room to test a taxonomy before committing to a training pipeline. The page frames prompted classification as suitable for fewer than 1,000 classifications per day.

Prompting has tradeoffs. Each classification carries model cost. Response time can be slower than a small dedicated model. Outputs need guardrails because a general-purpose model may return an explanation, an unexpected label, or formatting that breaks a downstream workflow.

The page contrasts prompted classification with production volumes of millions of items. At that scale, per-request cost and latency stop being implementation details. They become part of the business model.

Approach	Best fit	Label requirement	Cost at high volume	Latency
Traditional model	Stable categories and repeated inputs	Labeled examples	Low	Low
Fine-tuned transformer	Context-heavy domain text	Labeled examples	Moderate	Moderate
Prompted LLM	New or changing categories	Natural-language definitions can work	High	Moderate to high

A practical pattern uses prompted classification to create an initial set of labels, then trains a smaller specialized classifier once the taxonomy settles. The LLM helps bootstrap the work. The dedicated model handles the repetitive production job.

That pattern is appealing because it matches the stage of the problem. Early on, the team is still figuring out what the categories mean. Later, the category system has enough history to support training and needs cheaper, faster execution.

Model choice is not a purity test. You do not get points for using the most fashionable option. You get a classifier that works when the categories, data, and operating constraints line up.

Choosing a Classifier for Production

Start with the decision you need the classifier to make. A category should connect to a clear action: route, approve, review, prioritize, personalize, or measure.

If the action is vague, the labels will be vague. If the labels are vague, the evaluation will be vague. Teams often discover this after spending time debating model architecture when they should have been debating the category definitions.

Next, look at label availability. Do you already have examples of past inputs and the correct outcomes? Support teams may have historical queues. Finance teams may have reviewed transactions. Operations teams may have manually categorized documents for years.

That history can be training data if the past decisions are consistent enough to trust. If they are not, a classifier will scale the inconsistency with impressive efficiency.

When labeled examples are scarce, prompting can be the quickest way to test whether the category system works. Write category definitions in the language a competent reviewer would use. Add examples that clarify the boundary cases. Require a constrained output format that downstream systems can parse.

Then inspect the failures. Do the mistakes come from unclear inputs, overlapping labels, missing context, or a label set that does not match how the business operates? Fixing the taxonomy may improve results more than changing models.

Volume changes the decision. A low-volume workflow can tolerate more expensive inference and occasional human review. A high-volume workflow usually needs predictable cost and speed. Small per-item inefficiencies have a way of becoming a very large bill.

Latency matters too. A classifier that operates overnight has different constraints from one that sits inside a live customer conversation. If a user is waiting for a response, slow classification can make the whole product feel slow.

The cost of each error should shape the design. Misrouting a routine support request may be annoying but recoverable. Sending a risky transaction through without review has a different downside. High-cost errors may justify confidence thresholds, human escalation, or a narrower set of automated decisions.

You should also plan for change. Categories drift as products, customers, and internal teams change. New offerings create new intents. A policy update changes moderation labels. A reorganization turns yesterday’s routing logic into a museum piece.

Monitor the inputs and the labels after launch. Sudden changes in class distribution can indicate a product shift, an upstream data problem, or a classifier that is losing the plot. The inference glossary pairs naturally with this operating question: the model is only useful if its production predictions remain usable as real inputs change.

Evaluate More Than Accuracy

Accuracy is the share of predictions a classifier gets right. It is useful, but it can be a trap.

Imagine a review queue where almost every item belongs to the common class. A classifier can label every input as the common class and look excellent on accuracy while failing at the rare cases the queue exists to catch.

The page uses 99% accuracy as an imbalance caution example. That result can still be worthless if the classifier misses the small class that carries the business risk.

Precision asks: when the classifier predicts a class, how often is it correct? High precision means fewer false alarms for that class.

Recall asks: of the inputs that belong to a class, how many did the classifier find? High recall means fewer misses.

F1 combines precision and recall into one measure. It is helpful when you need to balance false positives and false negatives, though the right balance still depends on the workflow. A fraud-review queue may accept more false alarms to catch more risky items. A manual-review team with limited capacity may need higher precision.

Evaluate these measures for each class. A blended score can conceal a weak category, especially when one class has far more examples than the others.

Use a test set that reflects the production environment. If the training data contains clean, complete examples but live inputs are terse, misspelled, multilingual, or missing context, the test result is flattering the model.

Look at actual mistakes. A confusion matrix can show which labels get mixed up. That often tells you whether the problem is ambiguous categories, missing information, weak training data, or a model that needs more work.

Overfitting is another concern. A model can memorize the patterns in its training examples and then struggle with new inputs. The overfitting glossary is useful here because a strong training result is not evidence that the classifier will hold up outside the dataset it already knows.

The loss-function glossary also helps explain why training behavior and business outcomes can diverge. Models optimize the objective they are given. If the objective does not reflect the costly errors in the real workflow, a technically successful training run can produce a bad operating result.

A classifier earns trust through the decisions it improves. The model, prompt, and metric are all in service of that job.

Sources

• PE Collective classifier page: fewer than 1,000 classifications per day
• PE Collective classifier page: 99% accuracy
• PE Collective classifier page: 22,000+ job postings
• PE Collective classifier page: 2,700+ subscribers