LLM, NLI, ML or a Decision Model: Which One Should You Use?

The situation: a customer writes in: "I was charged twice for order 4471 and I want my money back today." Four different things need to happen. Someone has to decide where the ticket goes and how urgent it is. Someone has to guess whether it will escalate. Someone has to write the reply. And someone has to make sure the reply doesn't promise something the refund policy doesn't allow.

The default today is to prompt an LLM for all four. It will produce something for each. But three of the four jobs aren't writing jobs, and a smaller, purpose-built model does them better, faster and more consistently.

We build SynapCores. The guidance on this page applies to any stack. The SQL ran on SynapCores 2.4.7-ce, and the decision-model call uses the /v1/systemone endpoint in 2.5.0-ce.

The one question that picks the model

Ask what shape the output has, and what the model has to learn from.

If you remember one thing: LLMs write, NLI checks, ML learns your history, decision models judge.

                         What do you need back?
                                  │
        ┌──────────────┬──────────┴─────────┬──────────────────────┐
     free text   support/contradict    number or label        probability over
        │         between two texts   from columns            answers you name
        │              │                   │                 about one text
        ▼              ▼                   ▼                      ▼
       LLM            NLI        Have labelled outcomes?      Decision model
                                    yes → train ML              (no labels needed)
                                    no  → decision model,
                                          collect labels,
                                          train ML later

1. LLM: when the output is language

An LLM generates text one token at a time. That makes it the right tool whenever the answer is open-ended: a customer reply, a summary of a long thread, an explanation of a query result, a draft that a person will edit.

Pick an LLM when nobody can list the possible answers in advance.

Don't pick it when the answer is a label, a score or a yes/no. You pay for every generated token, you have to parse the text back into a value, and you get one sampled answer instead of a probability for each option.

In SynapCores the LLM is a SQL function, so the draft is written next to the ticket:

SELECT GENERATE(
  'Write a two-sentence, friendly reply to this customer message. '
  || 'Message: I was charged twice for order 4471 and I want my money back today.',
  json_object('max_tokens', 120, 'temperature', 0.2, 'seed', 42)
) AS reply;

I'm sorry to hear that you were charged twice for your recent order, Order #4471.
Our team is looking into it right away and will make the necessary adjustments
to ensure you are not overcharged. Thank you for bringing this to our attention
so we can resolve it quickly!

A low temperature and a fixed seed make the draft repeatable. The reply sounds fine, but nothing in it has been checked against the policy yet. That's the next model's job.

2. NLI: when you need to know if one text backs up another

An NLI (natural language inference) model reads a premise and a claim and returns three scores that add up to 1: entailment (the premise supports the claim), contradiction (it says the opposite) and neutral (it doesn't settle it). It's small, it runs on a CPU, and it returns the same scores every time.

Pick NLI when you have a source of truth and a piece of text that must agree with it: an AI answer against your policy, a new memory against old ones, a call transcript against a script.

Don't pick it when the question isn't about two texts. NLI doesn't route tickets or rate urgency, and it only knows what's in the premise you give it.

Here the refund policy is the source of truth, and each sentence an agent (human or AI) might send is checked against it with NLI_VERIFY:

SELECT NLI_VERIFY('nli-default',
         'You are not eligible for a refund of the duplicate charge.',
         JSON_ARRAY(
           'If a customer is charged twice for the same order, the duplicate charge is refunded.',
           'Refunds go back to the card that was charged.')
       ) AS check_result;

The same check, run on four candidate sentences:

Every LIE names the exact policy line it breaks, so the reply can be fixed or sent to a person before the customer sees it. For the full method (similarity floor, numbers and dates, sentence-by-sentence checks), see How to check if an AI answer is actually backed by your documents.

3. Trained ML: when your history knows the answer

A trained model (logistic regression, gradient boosting, a random forest) learns from rows where you already know the outcome. It turns structured columns into a number or a category: churn risk, fraud score, delivery time, escalation risk.

Pick ML when you have labelled outcomes and the signal is in your columns. Nothing beats it on cost and speed per row, and it learns patterns that are specific to your business, which no pre-trained model can know.

Don't pick it when you have no labels yet, or the input is mostly free text. You also need to retrain and monitor it as your data changes.

Say we have 600 past tickets with an escalated column. Training is one statement:

CREATE EXPERIMENT escalation_model AS
  SELECT tenure_months, prior_tickets_90d, order_value, hours_waiting,
         escalated AS target
  FROM ticket_history
WITH (
  task_type = 'binary_classification', target_column = 'target',
  algorithms = ['logistic_regression', 'xgboost'], max_trials = 6,
  validation_strategy = 'holdout', validation_split = 0.2,
  optimization_metric = 'roc_auc', random_seed = 42
);
-- best_score 0.873 (ROC AUC on the 20% holdout), trained in under a second

Scoring the open tickets is a function call in a normal query:

SELECT id, customer, tenure_months, prior_tickets_90d, order_value, hours_waiting,
       AUTOML.PREDICT('escalation_model',
                      tenure_months, prior_tickets_90d, order_value, hours_waiting) AS escalation_risk
FROM open_tickets
ORDER BY escalation_risk DESC;

Dana is a new customer with four recent tickets, a large order and a 30-hour wait. The model has seen that pattern escalate before. Notice that it never read Dana's message: the history in the columns was enough.

4. Decision model (d1): when you want a calibrated judgment about text, with no training

A decision model sits between an LLM and a classifier. Like an LLM, it reads text and understands questions written in plain English. Like a classifier, it returns a probability for each answer instead of writing anything.

d1, from Liquid AI, is built for exactly this. You give it a state (the ticket, a JSON record, a log line) and one or more typed questions. For each question it renders the options, runs one forward pass and reads the model's probability for each option directly. It generates zero output tokens, so there's no text to parse.

There are three question types:

Pick a decision model when the answers are a fixed set you can describe in words, the input is text or a record, and you either have no labels yet or your categories change often. Routing, triage, urgency, sentiment, policy category, "does this need a human?" are all good examples.

Don't pick it when you need text back (use an LLM), when you're checking text against a source (NLI is built for that), or when you have labelled history and numeric features (a trained model learns your patterns).

Pull the model once, then ask all three questions about the ticket in one request:

synapcores pull d1:latest

curl -s http://localhost:8080/v1/systemone \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{
    "model": "d1:latest",
    "state": "Customer message: I was charged twice for order 4471 and I want my money back today.",
    "questions": {
      "route":   { "type": "choice", "instructions": "Which team should handle this?",
                   "criteria": { "billing": "payments, charges and refunds",
                                 "shipping": "delivery and tracking",
                                 "technical": "bugs and login problems" } },
      "angry":   { "type": "noul",  "instructions": "Is the customer angry?" },
      "urgency": { "type": "score", "instructions": "How urgent is this?",
                   "criteria": ["can wait", "this week", "today", "right now"] }
    }
  }'

{
  "model": "d1:latest",
  "answers": {
    "route":   { "type": "choice", "choice": "billing",
                 "probabilities": { "billing": 0.90, "shipping": 0.03, "technical": 0.07 },
                 "confidence": 0.86 },
    "angry":   { "type": "noul", "noul": 0.82 },
    "urgency": { "type": "score", "score": 2.28,
                 "legend": { "0": "can wait", "1": "this week", "2": "today", "3": "right now" },
                 "probabilities": { "0": 0.04, "1": 0.19, "2": 0.22, "3": 0.55 },
                 "confidence": 0.28 }
  },
  "usage": { "input_tokens": 130, "output_tokens": 0 }
}

Three things make this different from asking an LLM:

1. You get the whole distribution. billing 0.90 vs technical 0.07 tells you how sure the model is. Route automatically above a threshold, and send the rest to a person.
2. The score type keeps the shape of the scale. An urgency of 2.28 means "between today and right now, leaning today", which is more useful than a single label when you sort a queue.
3. Changing the question is a text edit. Add a fraud team or a new urgency level and the next request uses it. There's nothing to retrain.

Side by side

How they work together

On a real support queue the four run in sequence, each doing the one thing it's best at:

1. Decision model routes the ticket (billing), flags the tone (angry 0.82) and rates urgency (2.28).
2. Trained ML adds the escalation risk from the account history (0.986).
3. LLM drafts the reply, with the route and risk in its prompt.
4. NLI checks every sentence of the draft against the refund policy. TRUTH goes out; LIE goes back for a rewrite or to a person.

We walk through that whole pipeline on one ticket, start to finish, in the blog post One support ticket, four AI models: LLM, NLI, AutoML and a decision model in one database.

Common mistakes

• Using an LLM as a classifier. It works in a demo. In production you parse text, handle the off-format answers, pay for output tokens and still don't know how sure it was. Use a decision model, or a trained classifier if you have labels.
• Training a model before you have labels. Start with a decision model, log its scores next to the outcomes people record, and train a classifier on that history when you have enough of it.
• Asking a decision model to check facts against a document. It judges the state you give it. To check a claim against a source, NLI is the purpose-built tool.
• Treating any single score as the whole system. Each model answers one question. The value comes from chaining them, with a threshold and a human for the cases in between.

Try it

Every example on this page runs on the free SynapCores Community Edition, on your own machine. Want to try SQL first without installing anything? Open the playground.