Skip to content
Contact

Algorithms · Language models · Hybrid systems

Algorithm or language model? Both, each in its place.

An algorithm gives the same result for the same input, every time. A language model computes a distribution over possible continuations, and its answer is drawn from it. elsyQ builds systems in which the model reads and a deterministic part checks and computes.

Colour code on this page

  • Deterministic Algorithm or rule: same input, same result.
  • Probabilistic Output of a language model or another learned model: a proposal.
Discuss a project Try the experiment

Same input, five runs

Input Quotation with 12 line items, asking for the total

Show the line items
  1. €1,249.00
  2. €386.50
  3. €72.90
  4. €918.00
  5. €45.60
  6. €212.40
  7. €1,030.00
  8. €64.80
  9. €157.20
  10. €289.00
  11. €118.60
  12. €268.40
Algorithm Sum of the line items, computed in cents
Run Result
1 €4,812.40 b2f4a58f
2 €4,812.40 b2f4a58f
3 €4,812.40 b2f4a58f
4 €4,812.40 b2f4a58f
5 €4,812.40 b2f4a58f
Language model Total continued as text, T = 1.0
Run Result
1 €4,812.40 same b2f4a58f
2 €4,812.04 same 4baa7475
3 €4,812.40 same b2f4a58f
4 €4,812.00 same 2a64497a
5 €4,812.40 same b2f4a58f

Same result as the algorithm: 3 of 5 runs

Under each total sits a fingerprint: the first eight hex digits of SHA-256 over the result, written in the form “4812.40 EUR”.

An illustration, not a measurement. The language model values are drawn from the same distribution that the temperature experiment below shows.

The difference

From the outside they look alike: text or numbers go in, a result comes out. Inside they work in completely different ways. An algorithm runs through fixed computation steps. A language model scores possible continuations, and one of them is drawn. That decides what you can test and recompute.

deterministic

Algorithm

An algorithm is a fixed sequence of computation steps. Each step depends only on the input and on the steps before it, and chance plays no part. Sorting and summing work this way, and so do a Newton iteration and a circuit solver.

y=f⁡(x)

The result y is a function of the input x. It depends on nothing else.

x1=x2⇒f⁡(x1)=f⁡(x2)

Same inputs, same outputs. Tests rely on that, and so does recomputing a result or passing an audit.

  • Reproducible
  • Testable against a spec
  • Every step traceable
probabilistic

Language model

The network computes a score, the logit, for every possible next token. That computation is deterministic up to floating-point effects. Randomness only comes in when a token is drawn from those scores.

P(y|x)=∏t=1mP(yt|y<t,x)

An answer of m tokens is produced one token at a time. Its probability is the product of the conditional probabilities of all the steps.

pi=ezi/T∑jezj/T

Softmax turns the logits into a distribution whose values add up to one. The temperature T changes its shape: T > 1 flattens it, T < 1 sharpens it.

yt=argmaxi⁡pi

Greedy decoding takes the most probable token at every step. It is the limit T → 0.

  • Handles free-form text
  • Can vary from run to run
  • Accuracy is measured, not proven

Temperature experiment

The model is meant to continue the total from above, and only the cents are missing. Five candidates are in the running. Move the temperature and draw some tokens.

Input Total: 4,812.

Candidates for the next token

  1. 40 63.81% Logit 3.2 correct
  2. 04 17.39% Logit 1.9
  3. 00 10.55% Logit 1.4
  4. 14 4.74% Logit 0.6
  5. 41 3.51% Logit 0.3

At T = 1.0, “40” gets 63.81% of the probability. The rest goes to wrong cent amounts.

At T = 0.1 nearly all of it sits on the most probable token. Greedy decoding (argmax) is the limit T → 0 and only as right as that token. Here it is right because the example was built that way.

The logits were chosen for this example, not measured on a model. The arithmetic behind them is real: softmax with temperature, then a weighted draw.

Errors compound

At 95% per step, 10 steps are all correct in only about 60% of cases.

A process rarely consists of just one step. If an error anywhere in the chain goes unnoticed, the end result is wrong. Without a check, the success rates multiply. With a deterministic check after every step, an error only slips through when the model and the check both get it wrong.

Without a check

Rn=∏k=1npk=pn

The chain is right only if all n steps are right. With independent steps and the same success rate p, that is the product p to the power n.

R10=0.9510≈0.599

With p = 0.95 and n = 10, about 60% of runs stay free of errors. The rest contain an error somewhere, and nobody noticed it.

With a deterministic check

q=(1−p)⁢(1−d)

A step goes wrong unnoticed with probability q: it is wrong, and the check misses it. Of all wrong results, the check catches the share d.

Sn=1−(1−q)n

From that follows the probability that at least one error slips through unnoticed in n steps.

S10=1−0.999510≈0.0050

With p = 0.95 and d = 0.99, q = 0.0005. Over 10 steps an error slips through unnoticed in 0.50% of runs, and in 99.50% it does not. Caught errors go back to the model or to a person.

Assumptions: independent steps, one checked attempt per step. Every further attempt carries the risk q again, including one that an overly strict check has triggered. In real systems, p and d are measured on a test set.

A chain of n steps

Each line is the probability that no error goes through unnoticed. Without a check (d = 0) that is exactly p to the power n. The line with a check counts caught errors as retried or escalated, not as failures.

No check, p = 0.99
n Chain correct
1 99.00%
5 95.10%
10 90.44%
20 81.79%
30 73.97%
No check, p = 0.95
n Chain correct
1 95.00%
5 77.38%
10 59.87%
20 35.85%
30 21.46%
No check, p = 0.90
n Chain correct
1 90.00%
5 59.05%
10 34.87%
20 12.16%
30 4.24%
With check, p = 0.95, d = 0.99
n No silent error
1 99.95%
5 99.75%
10 99.50%
20 99.00%
30 98.51%

The hybrid architecture

The model reads. The algorithm checks and computes.

The pattern fits any process that can be described clearly and still takes a lot of manual work, in any industry. Our example is checking a quotation. A language model reads it, because free-form text is what it handles well. Everything after that is ordinary code that can be tested.

How a quotation gets checked

  1. Inbox

    An e-mail with a quotation as a PDF.

  2. Language model

    Reads line items and prices into a fixed schema. Local or hosted.

  3. Check

    Checks the output against fixed rules, such as totals and units.

    Errors go back to the model with a reason. At most 3 attempts.

    After 3 failed attempts, a person decides.

  4. Computation

    Computes price, discount and tax by fixed rules.

  5. Result

    A checked quotation with a log of every step.

The core in pseudocode

fn quote(mut input: Input) -> Result<Price, Escalation> {for attempt in 1..=3 {let draft = llm.extract(&input, &SCHEMA)?;match rules.check(&draft) {Ok(valid) => return Ok(price(&valid)),Err(errors) => input.feedback(attempt, errors),}}Err(escalate(input))}
Only the call to llm.extract asks the model (P). Everything else is ordinary, testable code (D). Pseudocode in the style of Rust.

Log of one run

  1. E-mail with a PDF quotation: 12 line items, total stated in the document €4,812.40
  2. First attempt: the model fills the schema with 12 line items.
  3. Schema and unit check passed.
  4. Sum check rejected: the line items add up to €4,803.40 instead of €4,812.40, a difference of €9.00.
  5. Feedback to the model: the line items miss the stated total by €9.00. Please read again.
  6. Second attempt: the first line item is now €1,249.00 instead of €1,240.00.
  7. Sum check passed: the line items add up to €4,812.40.
  8. Computation: €4,812.40 plus 19% VAT gives €5,726.76.
  9. Quotation released. Input, output and model version are logged.
A staged run for illustration, not a client project. The numbers are the same as above.

The same principle in a circuit simulator: Circuit Forge

Making it reproducible

Temperature 0 alone is not enough.

At temperature 0 the model takes the most probable token at every step. That is greedy decoding, and in exact arithmetic it is deterministic: same input, same answer. It makes the answer repeatable, not correct. And a computer does not do exact arithmetic.

Hosted models run on GPU servers that group requests into batches. How large a batch is and what it contains depends on the load on the server, and many kernels then add floating-point numbers in a different order. The logits can shift in the last digits. If two tokens are nearly tied, the choice can flip, and the text continues differently from there.

On top of that, providers update their models. An alias such as “latest” eventually points to a different model, and even pinned versions are retired after a notice period. Reproducing a result later takes more than one parameter.

(0.1 + 0.2) + 0.3
0.6000000000000001
0.1 + (0.2 + 0.3)
0.6

IEEE 754: floating-point addition is not associative. Both lines add the same three numbers. That is why the algorithm at the top adds whole cents.

What we do about it

  • Pin the version or run locally

    With a hosted model we pin the version. Locally, a run can be made repeatable as long as weights, software, hardware and batch size stay the same. The switch between local and OpenAI, Anthropic or Mistral stays open.

  • Greedy decoding where possible

    Where the model and its interface allow it, we decode greedily at temperature 0. That narrows the spread between runs. It guarantees nothing, as described above.

  • Structured output

    The model answers against a fixed JSON schema. That guarantees the form of the answer, meaning its fields and types. It does not guarantee that the values in it are correct.

  • Deterministic validation

    Rules check every output: totals, units, value ranges, a match against master data. Whatever fails goes back to the model with a reason, or to a person.

  • A complete audit trail

    For every run we store the input, the output, the model version, the prompt version and the parameters. Any decision can be traced later, even long after the model has been replaced.

  • A fixed evaluation set

    Before any change of model or prompt, a fixed set of test cases runs as a regression test. Each case runs several times, because a hosted model can answer differently.

We do not promise that a hosted model writes the same thing twice. We make sure that nothing reaches your system unchecked.

What goes where

The table shows how we weigh it up. Often an algorithm is the better choice, and sometimes the answer is simply “no model”. If we cannot make a process better, we say so before it turns into a project.

Algorithm

Same input, same output
Yes, by construction
Unstructured text as input
Only in fixed formats such as CSV or XML
Testable against a specification
Yes, case by case
Explainable to an auditor
Every step can be shown
Cost per call
Compute time on your own hardware
Typical tasks
Billing, control loops, simulation, solvers

Language model

Same input, same output
Not guaranteed, not even at temperature 0
Unstructured text as input
Yes, that is its strength
Testable against a specification
Only statistically, on an evaluation set
Explainable to an auditor
Hardly: weights are not a justification
Cost per call
Token price or your own GPU
Typical tasks
Reading, sorting and summarising text

Hybrid

Same input, same output
Check and computation yes, the model output is logged
Unstructured text as input
Yes, the model reads and the rules check
Testable against a specification
Rules and computation yes, the model statistically
Explainable to an auditor
Approval and computation follow rules you can show
Cost per call
Model cost for reading plus compute time
Typical tasks
Checking quotations, orders and datasheets

Three patterns

Patterns from typical enquiries, not client projects.

  • Purchasing

    Pre-checking quotations from e-mails

    Quotations arrive as PDFs by e-mail, every supplier with its own layout. Today someone types the line items into the ERP and recomputes them. The system does the groundwork and only shows a person the discrepancies.

    Model
    A language model reads line items, quantities and prices from the PDF.
    Deterministic
    Totals, units and delivery dates are checked and matched against master data.
  • Master data

    Digitising datasheets

    Component parameters sit in datasheets, and every manufacturer lays them out differently. They are needed as clean records, for component selection, for the bill of materials or for simulation.

    Model
    A language model reads the tables and running text of the datasheet.
    Deterministic
    Units are converted, min ≤ typ ≤ max must hold, every value within the range of its component class.
  • Simulation

    Speeding up circuit simulation

    Large parameter sweeps on a circuit simulator take time. A surrogate model can screen variants or propose starting values so that the solver converges sooner. The computing is still done by the solver.

    Model
    A trained surrogate model, not a language model, proposes starting values.
    Deterministic
    The solver stays deterministic. Convergence and tolerance decide, and the result always comes from the solver.

Frequently asked questions

What is the difference between a deterministic algorithm and a language model?

elsyQ tells deterministic algorithms and language models apart by where a result comes from: an algorithm computes it in fixed steps, while a language model’s result is drawn from a probability distribution. With an algorithm the same input therefore always leads to the same result. A language model computes a score, the logit, for every possible next token, and that part is also deterministic up to floating-point effects. Randomness only comes in when a token is drawn from those scores. That is why the same question can get different answers.

Does a language model always give the same answer at temperature 0?

A hosted language model can answer differently even at temperature 0, so elsyQ never relies on getting the same answer twice. Temperature 0 means greedy decoding, which is deterministic only in exact arithmetic. The server groups requests into batches whose size depends on the load, and many GPU kernels then sum in a different order. The logits can shift in the last digits, and when two tokens are nearly tied the choice can flip. Locally, a run can be made repeatable as long as weights, software, hardware and batch size stay the same. That costs some throughput.

When does elsyQ use a language model, and when an algorithm?

elsyQ uses deterministic algorithms wherever the result has to be reproducible, and a model only where it demonstrably does better. Prices and taxes are therefore always computed by an algorithm. A language model comes in when the input is free-form text that no fixed rule can read reliably, such as a quotation as a PDF or an informal e-mail. Whether the model wins is shown by a comparison on a test set, not by the impression a demo leaves.

What is a hybrid system of language model and algorithm?

A hybrid system as elsyQ builds it splits the work: the language model reads unstructured input and proposes a structured result, and deterministic code checks it and does the computing. The model fills a fixed schema, for example with the line items of a quotation. Rules check things such as totals and units. If a result fails, it goes back to the model with a reason, and after a fixed number of attempts a person decides. Amounts and taxes are always computed by the algorithm at the end, and every step is logged.

How does elsyQ measure whether a model is good enough?

elsyQ measures whether a model is fit for the task on a fixed evaluation set of real or realistic cases from your process, before it goes live. Each case runs several times, because a hosted model can answer differently, and we count how often the result is right and how often the check catches errors. Among the models that are good enough, protection requirements, latency and cost decide whether the chosen one runs locally on your hardware or through OpenAI, Anthropic or Mistral. The architecture keeps that switch open. Before any change to the model or the prompt, the set runs again.

Let’s talk

A process where a model reads and an algorithm checks?

Describe in a few sentences what is done by hand today and how you recognise a correct result. Within two working days you get a technical assessment, even if it comes down to “no model”.

Discuss a project [email protected]