System One Models

011. Decisions, not text

The name

The psychologist Daniel Kahneman described two modes of human thinking. System 1 is fast, automatic and intuitive: recognising a face, sensing that a sentence is rude. System 2 is slow, deliberate and effortful: working out a tax return. Reasoning models, which part 2 of the language models module described writing out long deliberations before answering, are the field’s System 2. TypeSafe’s name claims the other mode: a model for snap judgements.

The analogy is loose. Kahneman’s point about System 1 was that it is quick and error-prone in systematic ways, and the company argues its model is the more reliable tool for the jobs it fits. Take the name as a label for “fast judgement, no deliberation” and do not lean on it further.

How much of AI in software is deciding

Look at the uses this course has recommended for models inside systems. Classification, routing and triage, in part 1 of this module. Guardrail checks and grading outputs, in part 9 of the practical AI module. Choosing whether a retrieved passage is relevant. Deciding whether an agent’s step succeeded. Each has a known set of possible answers, is made again and again, and feeds straight into an if statement.

Using a general language model for these has four costs.

• Speed and price. Part 3 of the language models module showed that output is generated one token at a time and is the expensive part. A model asked for one word still carries the machinery for writing essays.
• Parsing. The answer comes as text. Part 7 of the practical AI module showed how structured output forces the shape, and the content inside the shape is still generated text.
• Invented options. Asked to choose among five teams, a text generator can name a sixth. Constrained decoding prevents that, and not every system uses it.
• No usable confidence. This is the important one. Ask a chat model how sure it is and it will write “90%”, because that is a plausible thing to write. The number is more text. It was not measured, and studies have repeatedly found such stated confidence to be poorly matched to accuracy. So the program cannot tell a safe decision from a coin toss, and every decision must be treated alike.

022. How Jev works, as described

What goes in and what comes out

The input is a state, meaning the data to judge, which can include free text, and a set of typed questions, each with instructions in plain language. The output is one typed value for each question, with probabilities attached.

A request, as an independent write-up shows it, looks like this.

{
  "state": { "message": "My card was charged twice for the same order." },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which department handles this?",
      "criteria": {
        "billing": "Charges, refunds and invoices",
        "technical": "Faults in the product",
        "account": "Sign-in and personal details"
      }
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "Does the customer need an answer today?"
    }
  }
}

The reply would give billing with a probability for each of the three departments, and a probability for is_urgent. The field names are illustrative, since the interface is in early access and may change.

What is different inside

The vendor has published little about the architecture, and no size. It says three things.

• No text generation. The model has no ability to produce strings. Its only outputs are the typed values. The company’s phrase is that giving up strings buys everything else.
• All answers in one pass. Where a language model generates token after token, Jev produces every answer to every question together. Adding questions to a request adds little time. The company quotes 70 to 500 milliseconds end to end, and the independent write-up found most requests near 100.
• Trained for calibration. The company names its method Reinforcement Learning for Calibrated Decisions. The aim is that the probabilities mean what they say, which section 3 explains.

On price, the vendor charges for input at about four US cents a million tokens and nothing for output. Its headline comparison with large language models, roughly two hundred times faster and four hundred times cheaper, comes from its own workflow tests, and it says itself that those are at the high end of what users will see.

The “zero hallucination” claim

The company reports a hallucination rate of 0% and is open about what it means by that: the figure is not measured. It follows from the design, since the model can only return a value of the declared type, from the declared options. It can never invent a sixth department.

That is a real property and a narrower one than the phrase suggests. The model can still choose the wrong department. A wrong answer in a valid shape is still a wrong answer. What the design removes is one class of error, the malformed or invented output, and what it adds is a probability that lets you catch some of the rest.

033. Calibration

Why it is the point

A decision with a trustworthy probability can be handled by policy.

Without the probability, all three are “spam” or “not spam”, and the system is either too cautious everywhere or too bold everywhere. With it, automation can be confined to the cases where the model is sure, and part 9 of the practical AI module argued that this is how people get out of the loop safely: not by trusting the model more, but by knowing when to.

What it does not mean

Calibration is a property of many predictions taken together. Of all the answers given at 90%, about nine in ten are right. Which one in ten is wrong, it cannot say. A single confident answer can be wrong, and in a large enough volume some will be, every day. Thresholds must therefore be set by the cost of a mistake. An action that cannot be undone may deserve a threshold that almost nothing passes.

Calibration also belongs to a model on a kind of data. A model calibrated on its makers’ test sets may be overconfident on your tickets, your jargon, your language. Nothing in a vendor’s claim can settle that. Your own labelled cases can.

Why chat models are poor at it

A language model straight out of pretraining is, perhaps surprisingly, quite well calibrated about its next token: when it gives a token 80%, it is right about 80% of the time, because that is exactly what its training optimised. The post-training that part 2 of the language models module described, which makes the model helpful and agreeable, damages this. The model learns to sound confident, because people rate confident answers highly. Some APIs expose the underlying token probabilities, and they can be used as a confidence signal with care, and they are not what the model says when you ask it how sure it is.

044. What came before

The honest comparison

For a stable, high-volume decision on which you have labelled data, a trained classifier is still hard to beat. It is fast, cheap, runs anywhere, and its calibration can be measured and corrected. Its weakness is the cost of a new question: every new category or policy means new labels and a new training run.

A language model’s strength is exactly that a new question costs a sentence. Much classification moved to LLMs for that reason alone, and teams accepted the speed, cost and confidence problems as the price.

The system one proposal is a classifier that takes its task in words. If the claims hold up, it removes the classifier’s main weakness and the LLM’s main three. Whether they hold on data unlike the vendor’s is what early users will find out. The idea does not depend on this vendor. The tiny models of part 1 reach the same place from the other side, and nothing stops a general model vendor exposing a decision-only mode with calibrated outputs.

055. Where it fits

The three conditions

The vendor’s own guidance is a good test for any tool of this kind. Reach for it when three things are true at once.

1. You know the set of possible answers. Departments, categories, levels of severity, yes or no.
2. You make the decision repeatedly. The cost of each decision matters, and there will be enough cases to measure.
3. You can act on a confidence. There is somewhere for uncertain cases to go.

Good fits

• routing and triage of messages, tickets and documents
• the guardrail checks of part 9 of the practical AI module: is this input an injection attempt, is this output on topic, does this action need approval
• grading in evals, where part 6 warned about the biases of chat models as judges, and a calibrated score is worth more than an eloquent one
• filtering and labelling very large sets of records, where cost for each record decides whether the job is possible
• decisions in the middle of an interaction, where a second’s wait is too long
• the small decisions inside an agent’s loop: did that step work, which tool family is relevant, is the task finished

Poor fits

The independent write-up lists where Jev did badly, and the list would hold for any model that answers without deliberating: arithmetic, comparing dates, questions needing several steps of reasoning, and a relevant detail buried in a large irrelevant state. Add anything that needs a written answer, anything where the options cannot be listed in advance, and extracting an arbitrary value from text, where the advice is to choose from a deck of cards you supply and not to ask for a free value.

Fast and slow together

Kahneman’s two systems work as a pair, and so should these. The fast model takes every case. Those it is sure of are acted on. Those it is not go to a reasoning model, or to a person, with the fast model’s probabilities attached as a starting point. If nine cases in ten clear the threshold, the expensive model’s bill falls by about 90% and the typical response time falls further, while the hard cases get the same attention as before.

This is the first-pass pattern that part 1 of this module recommended for small models, with one improvement: the hand-over is decided by a measured probability and not by a guess.

Adopting one

Treat it like any new instrument, and the house advice of this course applies in full.

• Run it in shadow. Let it decide alongside the current process, without acting, and record both.
• Label the outcomes, and check accuracy and calibration on your own data as the deep dive describes.
• Set thresholds from your costs, not from a default.
• Automate the low-risk, high-confidence paths first, and widen from there.
• Keep measuring. Your data will drift, and a vendor in early access will change its model.
• Mind the dependency. A hosted model from a young company, with no open weights, is a risk to plan for. Keep the old path working.

The whiteboard version

Most AI calls inside software are decisions: yes or no, pick one, rate it. A text generator makes them slowly and cannot say honestly how sure it is. A decision model returns only a typed answer and a probability. If that probability is calibrated, which you check on your own data, software can act alone on the sure cases and pass the rest up. The product is days old and its numbers are its maker’s. The pattern is worth adopting with whatever tool earns it.