7 min left
Back to Series

Under the Hood > Article 5 | Intermediate | 7 min read

Article 5Intermediate7 min read

Making Claude a chemist — how a general-purpose LLM gets a specialised brain

Anthropic's chemistry work shows the pattern teams use to take a general-purpose model and make it reliable on a specialist domain. The lesson generalises far beyond chemistry.


A general-purpose language model being adapted with chemistry-specific tools and data sources

Anthropic published a research note this week titled Making Claude a Chemist. On the surface, it is a paper about giving a chat model better answers on questions involving molecules, reactions, and lab procedures. Underneath, it is one of the cleaner public descriptions we have of how a general-purpose large language model (LLM) gets turned into something that is actually reliable in a specialist domain.

The reason that matters beyond chemistry is simple. Almost every team building production AI features eventually runs into the same wall: the base model is fluent everywhere but trustworthy nowhere in particular. Closing that gap — fluency to trust — is the work nobody talks about in the launch announcements, and it follows a pattern.

This article walks through the four pieces of that pattern as they show up in the Claude chemistry work, why each piece is necessary, and what it looks like when you apply it to a domain that has nothing to do with molecules.


The gap between fluent and trustworthy

A base model trained on the open web can talk about chemistry. It can name reagents, sketch out a synthesis, and explain why a reaction proceeds. Most of what it says will sound right. A meaningful slice of what it says will be wrong in a way that is invisible without expertise.

Chemistry is unforgiving about this. A wrong stoichiometric coefficient is not a stylistic choice. A misremembered melting point is not a rounding error. The cost of a confidently wrong answer in a lab context is high — sometimes safety-critical, often experiment-killing.

The same gap exists in every specialist domain a team might want to deploy an LLM into. Medicine, law, financial compliance, embedded systems debugging, pharmaceutical regulation. The model sounds competent everywhere. It is reliable in the narrow places it has been deliberately made reliable. Those are different things.

Fluency comes from pre-training. Trustworthiness comes from everything you do after pre-training.

Anthropic's chemistry work is a worked example of the everything-after.


Piece one — a domain-honest evaluation set

The starting point is not training. It is measurement. Before you can improve a model in a specialist domain, you need to know how badly it does today, on questions that match the actual work you want it to do.

Generic chemistry benchmarks — exam-style multiple choice, textbook trivia — are not enough. They tend to be too easy for a modern frontier model, and they reward memorisation rather than reasoning over real lab artefacts. The Anthropic work emphasises evaluations built from the kind of problems an actual chemist hits during a workday: reaction planning, structural elucidation, literature reasoning, instrument output interpretation.

The shape is general. A domain-honest eval set has three properties:

  • Drawn from real work, not from the textbook that trained the model.
  • Graded by people who actually do the work, not by string-matching against a key.
  • Hard enough that the base model fails on a meaningful fraction, so improvement is measurable.

If your eval set is too easy, every change looks like an improvement. If it is too synthetic, the improvements do not transfer to real use. If it is graded by automation alone, you are optimising the metric rather than the underlying capability.

For chemistry, this looks like multi-step synthesis problems verified by trained chemists. For medical coding, it looks like real ambulatory notes graded by clinical coders. For legal drafting, it looks like contracts marked up by practising lawyers. The instrument changes; the principle does not.


Piece two — domain knowledge the model could not have absorbed

Even with perfect evaluation, the base model is missing things. Some of it is recent — papers published after the training cutoff. Some of it is closed — internal SOPs, proprietary datasets, company lab notebooks. Some of it is structured in formats the model never saw enough of — SMILES strings, reaction templates, IR spectra, mass-spec output.

There are two well-established paths to close this gap, and the chemistry work uses both.

Retrieval-augmented generation (RAG) keeps the model's weights frozen and gives it access to a search index over the domain corpus at inference time. For chemistry that index covers literature, reaction databases, and structured chemical data. The model looks things up the way a competent practitioner would, except faster.

Targeted fine-tuning updates the model's weights using carefully selected examples from the domain. This is where the model learns the formats and idioms that are too dense in domain text to pick up from general pre-training. Reading SMILES strings. Reasoning over reaction arrows. Following the conventions of a lab notebook entry.

The split is not arbitrary. The rule of thumb that holds up in practice:

What changes oftenWhat changes rarelyWhere it goes
Recent papersRetrieval
Internal SOPsRetrieval
Structured outputsRetrieval
Domain notationFine-tuning
Reasoning patternsFine-tuning
Refusal behaviourFine-tuning

Facts that change live in the index. Skills that the model needs to internalise live in the weights. Mixing the two — putting yesterday's paper in the weights, or asking retrieval to teach reasoning — is how teams end up with systems that are both expensive to update and weak at the actual task.


Piece three — tools the model can call when language is not enough

The third piece is the one most teams under-invest in. A language model is a text-in, text-out machine. Chemistry is full of operations that no language model should be doing in its head: drawing molecules, computing molecular weights, looking up boiling points, simulating reactions, validating that a proposed synthesis is balanced.

The right pattern is tools — deterministic functions the model can call with structured arguments and get structured results back. Anthropic's chemistry work surfaces this clearly. The model is given access to chemistry-specific tools, and the system is designed so that the model uses them rather than guessing.

Think of it the way a senior practitioner uses reference materials. A skilled chemist does not memorise every molecular weight in the periodic table — they look it up because looking it up is faster and more reliable than remembering. The LLM equivalent is a tool call. The model's job is to know when to reach for the tool, format the call correctly, and integrate the result back into its reasoning. The tool's job is to be right.

The same pattern recurs in every domain. Medical: a drug-interaction checker is a tool, not a memorisation target. Legal: case-law search is a tool. Finance: a present-value calculator is a tool. The general rule:

Anything that has a correct answer should be a tool call. The model is for judgement; the tool is for facts.

This split protects the system from the model's two characteristic failure modes — confident hallucination on lookup questions, and sloppy arithmetic on quantitative ones — without requiring the model itself to be perfect.


Piece four — domain-appropriate refusal

The fourth piece is where chemistry diverges sharply from, say, legal drafting. Some chemistry questions are dual-use — the same knowledge that helps a medicinal chemist design a better drug helps an attacker design a worse one. A specialised chemistry model has to refuse the second category without becoming useless on the first.

The Anthropic work treats this as an engineering problem rather than a content-moderation afterthought. The model learns, through fine-tuning and instruction, which categories of request to engage with fully, which to engage with cautiously, and which to refuse outright. The thresholds are calibrated against domain-expert judgement, not against keyword lists.

Domain-appropriate refusal is the piece that distinguishes a serious specialist deployment from a wrapper around a generic model. The wrapper either refuses too much (and frustrates legitimate users) or refuses too little (and creates real harm). The calibrated version learns the actual contour of the domain's risk surface.

For chemistry that surface is well-studied — there are decades of literature on dual-use research. For newer domains, the surface has to be mapped first, then encoded into the training. This is real work, and it is the kind of work that does not get cheaper as the base model gets better. Refusal calibration is its own discipline.


The loop that makes the pattern work

The four pieces only become an actual system when they are connected in a feedback loop. The chemistry work makes this loop explicit:

StepAction
1Run the current model against the evaluation set.
2Identify failure categories — what kinds of questions does it miss?
3Diagnose: missing knowledge, missing tool, or miscalibrated refusal?
4Apply the right fix — retrieval entry, tool, or fine-tuning sample.
5Re-evaluate. If the failure category closes without opening new ones.
6If new failures appeared, roll back and rediagnose.

This loop is unglamorous and slow. Each cycle measurably improves the model in a narrow direction without making it worse elsewhere. A specialist deployment is the product of many cycles, not a single training run.

The reason the loop matters more than any individual piece is that domain knowledge drifts. New papers appear. SOPs change. Tools get better. The system that was state-of-the-art six months ago is now slightly stale on every axis. Without the loop, the system decays. With the loop, it tracks the domain.


What this means for builders

The chemistry case study is interesting on its own merits, but the value for engineers outside chemistry is the template. Four points carry over directly.

Start with the eval set, not the model choice. The temptation is to pick a frontier model and start prompting. The mistake is that without a domain-honest eval set, you cannot tell whether the model is getting better or you are just getting better at writing prompts that survive the cases you happened to test.

Split your domain knowledge along change frequency. Things that change weekly or monthly belong in retrieval. Things that are stable for years belong in fine-tuning. Reversing that split is the most common architectural mistake in production LLM systems — it makes updates painful and makes the model dumber at its actual job.

Treat tool design as part of model design. A model with the right tools available is dramatically more reliable than a stronger model without them. Invest in well-typed, deterministic, fast tools for everything in your domain that has a correct answer. Reserve the model itself for the parts that require judgement.

Calibrate refusal against domain expertise, not generic safety lists. Generic refusal heuristics are tuned for general-purpose assistants. Specialist domains have specialist risk surfaces. If your refusal policy was not designed with someone who understands the domain's actual harms, it is either over-refusing or under-refusing — usually both, on different categories.


Conclusion

Making a frontier model usable in a specialist domain is not a one-step process. It is a domain-honest eval set, a clean split between retrieval and fine-tuning, a real investment in tools, and refusal behaviour calibrated by people who understand the domain's failure modes — connected by a slow, measured feedback loop.

That pattern is what Anthropic is publicly describing for chemistry. It is also, with different content in each box, what serious teams are doing in medicine, law, security, and finance. The headline is "Claude is now a chemist." The lesson is that the path from fluent generalist to trustworthy specialist is now well-trodden enough to be borrowed wholesale.


LLMAnthropicClaudedomain adaptationfine-tuningevaluationAI infrastructure

Up next in the series

Article 6Live

Find the Hot Path Before You Add a Message Queue

Most performance problems live on a small slice of code. Profile first, optimize that route, and only then add caches, replicas, or microservices.

system designperformancehot pathprofiling