21 domain LLMs turn generic AI into specialists

I turn InfoWorld’s domain LLM roundup into a practical playbook you can copy.

I've been using general-purpose LLMs for a while now, and the weird part is how often they feel almost right. They can draft the email, summarize the doc, and fake confidence in a meeting note. Then you ask for something domain-specific and they go slippery. Legal wording gets mushy. Medical language gets hand-wavy. Security analysis starts sounding like a blog comment with better grammar. That’s the frustration: the model is fluent, but it is not actually useful where accuracy matters.

That’s why Peter Wayner’s InfoWorld roundup hit a nerve for me. It’s not selling a shiny new chatbot. It’s showing the opposite move: take the broad model and force it to learn one job, one corpus, one kind of answer. I’ve seen teams waste months trying to make a generic model behave like an expert. Wayner’s list is basically the antidote to that habit. He walks through models aimed at medicine, law, finance, climate, cybersecurity, and materials science, and the pattern is obvious once you see it: specialization is the product, not a side quest.

Stop asking one model to know everything

“The best teams are building specialized models for niches—one for the doctors, one for the lawyers, one for the bankers, and so on.”

What this actually means is that the old “one model for every task” fantasy is getting expensive and sloppy. A general model can sound smart across many domains, but once the cost of being wrong gets real, that broadness becomes a liability. In medicine, law, finance, and security, a slightly wrong answer is not a cute hallucination. It’s a bug with consequences.

I’ve run into this in product work more than once. A team wants a single assistant for support, internal docs, compliance, and analytics. It looks efficient in the planning doc. In practice, the prompts get longer, the guardrails get uglier, and the model still misses the stuff that matters most. The minute I split the problem into domain-specific tasks, the quality jumps because the model no longer has to guess what “good” means.

Wayner’s article makes that tradeoff explicit. The smartest teams are not trying to make a supertanker do city driving. They’re building smaller vehicles for narrower roads.

How to apply it: start by listing the top three domains where wrong answers are most expensive. If your assistant touches legal review, clinical support, or threat intel, do not let it share the same model path as your generic content tool. Separate the use cases first, then decide whether each one needs its own fine-tune, retrieval layer, or both.

• Use a general model for drafting and routing.
• Use a domain model for final answers, extraction, or classification.
• Keep the “expert” path narrow enough that you can evaluate it properly.

Smaller models win because they cost less to be wrong

Wayner points out that specialization is driven by quality, but also by efficiency. Smaller focused models are cheaper to run. That matters more than people admit in architecture reviews. Everyone likes to pretend inference cost is someone else’s problem until the bill lands.

He also notes that some of the biggest models are really mixtures of smaller experts under the hood. That’s the part I wish more teams understood before they start worshipping parameter counts. Bigger is not the same thing as better. Sometimes it just means you’re paying a lot to activate knowledge you don’t need.

I’ve seen this show up in production when teams deploy a giant model for a narrow workflow like contract clause extraction or medical note summarization. It works, sure. Then usage grows, latency starts creeping up, and suddenly the “smart” choice becomes the budget disaster. A smaller expert model, or a mixture-of-experts setup, often gets you the same result with less drama.

How to apply it: treat model size like scope control. If the task is bounded, keep the model bounded too. If you need breadth, consider routing or MoE-style designs before you jump to a giant monolith. And if you’re quantizing for edge or local use, test the quality hit against the actual task, not a generic benchmark.

• Benchmark latency and cost against one real workflow.
• Quantize only after you know the acceptable accuracy floor.
• Prefer smaller specialized models when the domain is stable.

Your training corpus is the real product

Wayner says the hard part is creating the training corpus, and that’s exactly right. The model is the visible thing, but the corpus is the part that decides whether the output is useful or just confidently formatted nonsense. In several of the examples he cites, teams hired subject-matter experts to build ontologies and verify answers. That’s not optional busywork. That is the work.

This is where most “we’ll just fine-tune it” plans fall apart. If the data is sloppy, the model learns sloppy. If the labels are inconsistent, the model learns inconsistency with better punctuation. And if the references aren’t trustworthy, you get a domain model that sounds authoritative while quietly drifting off target.

I’ve been in that mess. A team wanted a legal assistant trained on internal contract history. The first pass looked amazing in demos because the examples were cherry-picked. Then we widened the corpus and found a swamp of contradictory clause language, outdated templates, and half-finished redlines. The model didn’t fail because the architecture was wrong. It failed because the knowledge base was junk.

How to apply it: spend more time on corpus design than on model selection. Build a source policy, define what counts as ground truth, and get domain experts to review edge cases. If you can’t explain why a document belongs in the training set, it probably doesn’t.

• Curate documents by source quality, not just volume.
• Track provenance for every record you use.
• Have experts review ambiguous labels before training.

Specialized models need verification, not vibes

Wayner is blunt about hallucinations: users with serious questions won’t tolerate them. That’s the whole reason specialized models exist in the first place. A model for legal or medical work cannot just be “pretty good.” It has to be inspectable, traceable, and boring in the right ways.

This is why so many of the examples in the article pair the model with human review or constrained workflows. EvenUp, for example, drafts personal injury letters but also offers human review. That’s not a weakness. That’s the product being honest about risk.

I think a lot of teams still want the magic trick version of AI: press button, get answer, ship it. Domain systems don’t work like that. They need guardrails, citation checks, escalation paths, and a way to say “I don’t know.” If the system can’t do that, it’s not an expert system. It’s a liability generator with autocomplete.

How to apply it: build verification into the workflow from day one. Don’t bolt it on after the first incident. Require citations for factual claims, confidence thresholds for auto-actions, and human review for high-risk outputs. If you’re in a regulated domain, make the review path part of the product, not an exception.

Some useful patterns are simple:

• RAG for grounding.
• Structured extraction for repeatable outputs.
• Human approval for anything that changes money, health, or legal position.

Look at the corpus before you look at the brand name

Wayner’s examples are a mixed bag of proprietary systems, open-weight models, and research projects. That mix matters. BioGPT, Meditron-70B, MedGemma, FinGPT, ClimateBERT, CyLens, and Sec-PaLM 2 all come from different teams with different goals, but the pattern is the same: the corpus and task definition matter more than the logo.

That’s the part I’d tell any team shopping for a domain model. Don’t start with “Which model is hottest?” Start with “What did it read, who checked it, and what job was it trained to do?” A model trained on PubMed abstracts is not the same thing as a model trained on clinical guidelines. A finance model trained on decades of curated documents is not the same thing as a generic chatbot with a finance prompt.

I’ve seen teams pick a model because it had a nice demo and a confident sales deck. Then they discovered the model was tuned for a neighboring problem, not their actual one. That gap always shows up later, and it always costs more to fix later.

How to apply it: create a procurement checklist that starts with data lineage and ends with evaluation. Ask three questions before you buy or build: what corpus was used, who validated it, and what failure modes were measured? If the vendor can’t answer those cleanly, keep walking.

• Ask for corpus provenance.
• Ask for domain-expert review.
• Ask for task-specific evals, not generic benchmark theater.

Pick the right kind of specialization

One thing I like about Wayner’s roundup is that it does not pretend all specialization is the same. Some models are built for classification, some for generation, some for reasoning, some for retrieval, and some for simulation. That distinction matters because a team can waste a lot of time forcing one tool to do another tool’s job.

For example, ClimateBERT is used to locate and classify climate-related text. That is not the same thing as generating a policy memo. GNoME is not really an LLM at all, but a graph neural network for materials discovery. Earth-2 is about climate simulation and forecasting. These are all “specialized AI,” but they are not interchangeable.

I keep seeing teams blur those lines. They want one model to summarize, classify, reason, and automate. That’s how you end up with a bloated system that is mediocre at everything. The cleaner move is to let each model do the kind of thinking it is actually good at.

How to apply it: map the task before you map the model. If the job is extraction, use a model or pipeline optimized for extraction. If the job is reasoning, test reasoning models. If the job is simulation, stop trying to solve it with a chat interface. The interface is not the capability.

Here’s the practical split I use:

• Classification and detection: smaller domain-tuned models.
• Drafting and explanation: generative models with grounding.
• Simulation and prediction: specialized scientific or statistical models.

The template you can copy

# Domain LLM selection template

## 1) Define the job
- Primary task:
- Secondary task:
- What counts as a wrong answer:
- What the model is allowed to do:
- What the model must never do:

## 2) Choose the specialization type
- [ ] Classification / extraction
- [ ] Drafting / generation
- [ ] Reasoning / planning
- [ ] Retrieval / search
- [ ] Simulation / forecasting

## 3) Build the corpus
- Source systems:
- Trusted references:
- Excluded sources:
- Expert reviewers:
- Labeling rules:
- Provenance tracking:

## 4) Pick the model path
- Base model:
- Fine-tune method:
- Retrieval layer:
- Quantization target:
- Hosting target:
- Human review step:

## 5) Evaluate on real cases
- Gold set size:
- Acceptance threshold:
- Hallucination checks:
- Citation checks:
- Latency target:
- Cost per request target:

## 6) Ship with guardrails
- Confidence threshold:
- Escalation rules:
- Audit logging:
- Fallback behavior:
- Human approval required for:

## 7) Prompt skeleton
You are a domain assistant for [domain].
Use only approved sources: [sources].
If evidence is missing, say so.
Cite the source for every factual claim.
Prefer concise answers.
Flag uncertain or risky outputs.

## 8) Review checklist
- Did the answer stay inside the domain?
- Did it cite approved sources?
- Did it avoid unsupported claims?
- Would a domain expert sign off on it?
- Would I ship this in production?

That’s the version I’d hand to a team before they start fine-tuning anything. It forces the boring questions first, which is exactly where these projects usually go wrong. If you can’t define the job, you don’t need a better model. You need a better spec.

And if you want to go deeper into the source material, the original roundup is Peter Wayner’s InfoWorld article, 21 LLMs tuned for special domains. For model and repo context, I’d also look at Hugging Face, GitHub, and the model families mentioned in the article like Mistral, Microsoft, and Google Cloud. My breakdown here is derivative of Wayner’s list, but the template and implementation advice are mine.