How do you make a large language model keep two plus two equal to four?

How do you make a large language model keep two plus two equal to four?

You make the Large Language Model more deterministic. A business runs on decisions that have to come out the same way every time. Payroll, tax, a refund, a deadline under European Union (EU) law. Two plus two must be four. The path to that four, when the rule is a statute, is lawyers and a written process, not a confident paragraph.

A Large Language Model (LLM) is a probability engine. It selects the next token from a weighted list. Two plus two might come out four, because four is a very common neighbor of those words. That is not the same as addition. If you plug the model into a ticket or a mailbox and hope, you did not buy arithmetic. You bought a fluent maybe.

Why does a company need the same answer twice?

Because money and duty do not average. If the invoice is wrong on Tuesday and right on Wednesday, you do not have a creative writing problem. You have a ledger problem. The person who signs the books needs one number. The person who answers a regulator needs one path.

I have watched teams treat a chat box like a junior analyst who never sleeps. The sentences look finished. The voice is calm. Then someone pastes the output into a system that will pay a vendor or close a case. That is the moment the maybe becomes a fact, and nobody in the room agreed to that upgrade.

The trade-off is ugly and honest. You can have a model that talks like a person, or you can have a process that repeats. You can have both only if you split the jobs. Language on one side. Rules on the other.

Why is an EU rule not a vibe?

An EU regulation is written so a court can tell whether you followed it. The outcome is supposed to be deterministic. Did you process the request in time? Did you keep the record you said you would keep? Did you refuse the write you were not allowed to make? The path to that yes or no is counsel, a policy, and evidence. It is not a temperature slider.

Why do LLM rules follow the same path as early car laws? is the street version. Tools arrive first. Fines arrive after the fenders meet. The EU will not ask whether your chatbot sounded helpful. It will ask whether you can show what the system did.

I will not invent a fine amount here. The number is public when the authority publishes it. What I will say is simpler. If you cannot replay the decision, you do not have compliance. You have a transcript.

Why does the model only maybe get four?

Because it is not adding. It is choosing, token by token, from a cloud of likely next pieces. Weights. Vectors. A score for each candidate. Four wins often. Sometimes a joke wins. Sometimes a look-alike number wins. Parallel math on different chips can even wobble the same prompt.

People hear "artificial intelligence" and picture a mind that knows arithmetic the way a child learns it. That is the wrong picture. The model has seen a lot of homework. It has not sworn an oath to the integers.

If you need four, you write 2 + 2 in a language that only has one answer. You let the model read the messy email and fill a form. You do not let it keep the pencil when the form says "amount."

Is turning the randomness down enough?

No. Setting the sampler to pick the single most likely token, and locking a seed so the same input can replay, is a start. It cuts the long tail of creative nonsense. It does not turn the model into a court.

You still need a shape the fill must match. You still need code that refuses a field that is not a date, a yes or no, or a code from a closed list. You still need a person after a few failed tries. Zero temperature without those fences is a calmer guess.

The teams that rush a wrapper live, with the sampler still warm, and then call the first bad write an edge case, have the diagnosis backwards. The edge case is the architecture. The chat box was the shortcut.

How do you split language from the rule?

The model reads. Code decides. A messy customer message becomes a small JSON object: intent, amount, deadline, a flag for a human. Then a function you can test does the tax, the date math, the allow or deny. If the object is broken, you send a plain error back and try again, a few times, then you stop.

That is how you get closer to deterministic. Not by lecturing the model that it is probabilistic. Every competent engineer already knows. You get there by taking executive power away from the sampler.

Prism Signals is that split on a support bot. Score the turn. Mark the thin sentences. Keep a weak fill off the ticket. Counsel gets a trail: the state, the check, the retry, the fallback. The bot can still talk like a person. The record is a worker you can replay.

What should you ask to see before you trust the wrap?

Ask for the log, not the demo. Which step ran. Whether the shape passed. How many times it retried. Who took the turn when it failed. If the vendor can only show you a chat window, you bought a widget.

Then ask where the arithmetic lives. If the answer is "in the prompt," walk away. If the answer is "in a function we can unit test," stay and read it.

I write this from the same belief I have about voice. Probability is not wisdom. Humans read the room. Machines compute the next likely token. A company that forgets the difference will look modern until the first number is wrong in public.

If you want the support-bot version in the product, email [email protected]. Bring a workflow that cannot be maybe. We will talk about the wrap, not a pile of prompts.