Skip to main content

Discriminative AI: Decision Models, Examples, and Uses

· 10 min read
Felo Search Tips Buddy
Committed to answers at your fingertips

Learn how discriminative AI and decision models classify, route, and score inputs, how they differ from generative AI, and where developers can use them.

A support request arrives: “I was charged twice and need a refund.” Your application does not necessarily need a paragraph from an AI model. It may first need a decision: should this ticket go to billing, technical support, or sales?

Discriminative AI is designed around predicting a label, score, or other target from an input. A newer group of decision models brings this idea to developer APIs: give a model context and a defined question, and it returns a structured decision or probabilities that software can use. This guide explains how these models work, where they fit beside generative AI, and how to evaluate them.

Discriminative AI decision model classifying and scoring inputs

What is discriminative AI?​

Discriminative AI predicts something about an input. A spam filter predicts whether an email is spam; a classifier assigns a support ticket to a team; a risk model estimates the likelihood of a specified outcome.

In machine learning, discriminative models commonly learn a mapping from input x to a target y, or estimate the conditional probability P(y | x). The target might be a class, a numerical value, or another structured output. Logistic regression, support vector machines, and many neural classifiers are examples of discriminative approaches. Not every discriminative model returns a probability, and not every numerical score is well calibrated.

The underlying idea predates today's AI assistants. What is newer is the availability of general-purpose decision APIs that accept task descriptions and answer choices in natural language, so developers can apply the same interface to many classification or scoring tasks.

What is an AI decision model?​

In the current API landscape, a decision model generally refers to a model or service designed to answer bounded questions about a supplied input. Instead of composing a free-form response, it returns a typed result such as:

  • Yes/no probability: How likely is this message to contain a refund request?
  • Choice: Which department should receive this ticket?
  • Score: Where does this answer fall on a defined quality rubric?

For example, a decision model might return a billing label and probability estimates for each department. Your application can use those results to route the ticket, ask for more information, or send it to a human reviewer.

TypeSafe calls its Jev family “System One” models. Liquid AI describes its d1 decision model as accepting text and images and returning probabilities without generating output tokens. The Google Codelab on discriminative models demonstrates how a decision model can be used alongside a generative model in an application.

The terms are related, but not interchangeable. Discriminative modeling is a broad machine-learning concept; a decision model is a product or interface for bounded decisions. A generative model can also classify text when prompted, even though its underlying generation process and response format differ.

Discriminative AI vs. generative AI​

Discriminative AIGenerative AI
Typical question“Which category fits this input?”“What response or content should be produced?”
Common outputLabel, prediction, score, or probabilityText, code, image, audio, or other generated content
Example taskRoute a customer ticketDraft a response to the customer
Strength to investigateConsistent bounded decisions and usable scoresFlexible synthesis, explanations, and creation
Main evaluation concernClassification errors, calibration, and thresholdsAccuracy, instruction following, safety, and usefulness

The boundary is not a rule that one model can perform only one task. An LLM can return JSON labels, and a decision system can use a generative model inside a larger workflow. The practical distinction is what each component is optimized and exposed to do. A structured API response alone does not prove that its probabilities are calibrated or that its underlying model is discriminative.

Consider the refund ticket. A decision model could identify the issue as billing and estimate urgency. A generative model could then draft an empathetic reply using the relevant refund policy. The application should still check policy, permissions, and any required human approval before taking action.

How decision models work in an application​

The exact schema differs by provider, but a typical decision request contains three pieces:

  1. State: The information to assess, such as the text of a ticket or an image.
  2. Question and criteria: The decision to make and descriptions of the allowed answers or score levels.
  3. Typed response: A label, score, or probability distribution returned for the application to interpret.

For example:

State: "I was charged twice for my subscription."
Question: Which team should handle this request?
Options: billing, technical support, sales
Illustrative result: billing

This is a conceptual example, not an actual API response. The model may also provide confidence or probabilities, depending on the endpoint. Follow the documentation for the specific model and API rather than assuming all providers use the same request format or support the same modalities.

What do probability scores mean?​

A predicted probability is useful only if you understand its reliability. If a system assigns 0.8 to many similar predictions, a well-calibrated system should be correct roughly 80% of the time across that group. A single 0.8 score does not guarantee an individual decision is correct.

Check calibration on your own data, especially after changing models, labels, languages, or input sources. You can use thresholds to direct low-confidence cases to review, but choose those thresholds against the costs of false positives and false negatives. A fraud-review queue and a harmless content recommendation require different rules.

Discriminative AI examples and use cases​

Support ticket classification and routing​

A decision model can assign incoming messages to billing, technical support, or account management. Add an “other” or “needs review” path for ambiguous requests, and test messages containing multiple issues. Evaluate the error rate by category, not just overall accuracy: a model that misses urgent billing complaints can look good on a dataset dominated by routine questions.

Content moderation​

A moderation workflow can ask whether content falls into a defined policy category. Give the model clear criteria and examples, evaluate edge cases, and route uncertain or consequential cases to trained reviewers. A decision score is an input to your policy process, not proof that content violates a rule.

LLM and agent routing​

Before calling an LLM, an application can classify the request by topic, complexity, or required modality. A routing component can then choose a workflow or request additional information. Test routing together with the downstream system: a cheap first step is not useful if it consistently sends difficult requests down the wrong path.

Document and image triage​

A multimodal decision model may classify whether an image or document belongs to a predefined category, such as an invoice, receipt, or support screenshot. Verify that the exact endpoint supports the input format and image handling you need. Classification is distinct from extracting every field in a document; check whether the chosen model and API support both tasks.

Rubric scoring​

A model can place a response on an ordered scale using descriptions such as “missing key evidence,” “partially supported,” and “fully supported.” Test whether reviewers agree with the labels and whether the model treats similar answers consistently. Avoid presenting rubric scores as objective measurements without validation.

Decision models available in the Felo model catalog​

The Felo model catalog includes a Decisions output filter. As listed on November 2, 2026, examples include:

Catalog listingDescribed useInputs shown in catalog
TypeSafe Jev 1.14Routing, classification, and moderationText and image; the listing describes image support as experimental
LiquidAI d1.1Yes/no, choice, and score decisionsText and image
Baseten Joey 1Classification and routingText and image
Perplexity Decider Flash V1.2Classification, routing, and scoringText and image

These descriptions reflect the catalog, not independent performance tests or a recommendation that one model is best. Availability, feature support, context limits, and pricing can change. Check the current listing and endpoint documentation before building, especially for experimental or multimodal features. A model's listing does not by itself establish that every provider's native API feature is exposed through every platform.

How to evaluate an AI decision model​

Start with a narrow decision and a set of representative examples with trusted labels. Include difficult cases, minority categories, missing context, and examples where a human should take over. Then compare the model against a simple baseline, an existing classifier, or an LLM with structured output.

Measure more than accuracy:

  • Precision and recall: Which errors matter, and how often do they occur for each class?
  • Calibration: Do predicted probabilities match observed outcomes over groups of cases?
  • Coverage: What fraction of requests can be handled automatically at your chosen threshold?
  • Latency and reliability: Does the complete API call meet your production requirements?
  • Cost: What is the cost per useful decision, including retries, multiple questions, image processing, and human review?
  • Robustness: Does performance hold across languages, formats, unfamiliar examples, and changing traffic?

Use a held-out test set after tuning labels and thresholds. In production, log outcomes where appropriate, review disagreements, and re-evaluate when the model version, policy, or input distribution changes. For consequential decisions, design meaningful human oversight and verify applicable requirements.

Frequently asked questions​

Is discriminative AI the same as a decision model?​

Not exactly. Discriminative AI describes a broad approach to predicting a target from an input. Decision models are a newer product category focused on bounded outputs such as choices, scores, and probabilities. Some decision models use discriminative techniques, but the terms do not describe identical things.

Can an LLM classify or make decisions?​

Yes. A generative LLM can be prompted to classify content or return structured outputs. Whether a dedicated decision model performs better, faster, or more cheaply depends on the task, model, provider, and evaluation method. Test both on your own examples.

Are decision model probabilities always accurate?​

No. A model can produce probabilities that are poorly calibrated on a particular dataset or subgroup. Measure calibration and the consequences of mistakes before using thresholds to automate a workflow.

When should I use generative AI instead?​

Use a generative model when the task requires drafting, explaining, synthesizing, or producing open-ended content. For many applications, a decision model and a generative model work together: one routes or classifies, while the other creates the response.

Discriminative AI gives developers a way to put explicit, measurable decisions into a workflow. Start with one bounded task, test the errors that matter, and decide how much automation the evidence supports.

Explore decision models in the Felo catalog →


This post is also available in 简体中文, 日本語, 한국어, 繁體中文, हिन्दी, Français, العربية, Русский, اردو, Bahasa Indonesia, Deutsch, Tiếng Việt, Türkçe, Italiano, ไทย, Español, বাংলা and Português.