The easiest way to misunderstand Large Quantitative Models is to see them as the next thing that replaces large language models. They are not. SandboxAQ CEO Jack Hidary has framed the relationship as complementary: use LLMs for what they are good at, then bring in LQMs for what they are good at (VentureBeat). The interesting engineering is in how the two meet.
Different questions, different machines
An LLM answers the question: given everything humans have written, what is the most plausible continuation? That is an astonishingly useful question for explanation, drafting, code and interface. An LQM answers a different question: given what we know about how this system behaves, what will this quantity be — and how sure are we?
The first is evaluated by humans reading the output. The second is evaluated by reality — a lab measurement, a failed part, a realised loss. That single difference drives almost every other design choice.
Side by side
| Large Language Model | Large Quantitative Model | |
|---|---|---|
| Native input | Text, code, images | Numbers, structures, signals, fields |
| Training data | Internet-scale human text | First-principles simulation + proprietary measurements |
| Objective | Plausible next token | A target property or prediction |
| Typical architecture | Transformer | Modular hybrid: surrogates, graphs, physics constraints |
| Ground truth | Human judgement | Measurement |
| Failure mode | Hallucinated facts | Confident numbers built on bad assumptions |
| Best at | Interface, synthesis, reasoning in language | Screening, prediction, simulation |
The seam is where the value is
The integration point between the two models is deceptively hard. An LLM must turn an ambiguous request — "find me a cheaper catalyst for this reaction" — into a well-posed quantitative job with explicit constraints. The LQM must return not just a number but its uncertainty and the assumptions it rests on. And the LLM must then explain that result without rounding off the caveats.
When the seam is designed well, the user gets the best of both: a conversational interface with answers that hold up in the lab. When it is designed badly, the user gets the worst of both: fluent prose wrapped around a number nobody can trace.
Fluent prose wrapped around a number nobody can trace is the worst of both worlds.
Three integration patterns
Pattern A — LQM as a tool
The LLM is the orchestrator and calls the LQM through a tool interface, the same way it might call a search engine. This is the pattern behind SandboxAQ's marketplace delivery, where models are reachable from conversational assistants. It is the fastest route to adoption.
Pattern B — LLM as an extractor
The language model turns unstructured inputs — emails, reports, lab notebooks — into structured numerical features, and the LQM does the analysis. Aviso's revenue-forecasting design follows this shape.
Pattern C — closed-loop design
The LQM proposes candidates, a lab or simulator measures them, results flow back into training, and the LLM handles planning and reporting. This is the most powerful pattern and the hardest to build, because it requires data pipelines into the physical world.
Pitfalls
- Precision theatre. Six significant figures do not make a prediction accurate. Always demand calibrated uncertainty.
- Out-of-distribution queries. Surrogates trained on one region of chemical or design space can fail silently outside it.
- Assumption drift. Quantitative results are only as good as the assumptions underneath; those assumptions must travel with the number.
- The LLM summarising away the caveat. The last mile — explanation — is where error bars most often disappear.