When your task does not need an LLM — and what to use

TL;DR. A sizeable share of the work that arrives labelled "we need AI" is solved without a language model — faster, cheaper, and with a reproducible result. The signs: the answer comes from a closed list, the noise in the data is spelling-level rather than semantic, and the decision has to be explainable. A model adds no accuracy there, and it does add inference cost, latency, and variance between runs.

Three signs a language model is surplus

The answer comes from a closed list. Map a job title to a 56-entry reference list, sort tickets into five categories, derive a region from an address. The set of valid answers is finite and known in advance. A model capable of producing any text at all is solving a problem that never asked for that.

The noise is spelling-level, not semantic. Abbreviations, typos, and junk like a company name sitting in the job-title field. There's no ambiguity of meaning here — there's mess. That's fixed by normalization and fuzzy string matching, not by language understanding.

The result has to be explained. If someone will eventually ask "why did the system decide that," then "the model scored it" won't do. Especially where the decision touches money or a person.

Two out of three is enough to seriously price out the no-model option.

What solves it instead

Normalization plus fuzzy matching. On the job-title project, 300 input strings collapsed into 78 unique canonical forms after normalization — most of the work became exact matching before any comparison ran. The rest was matched against the reference list with a weighted string-similarity metric. The whole dataset processes in under 0.2 seconds on an ordinary CPU, with no GPU and not a single external call.

Rules and weights. Routing incoming tickets between agents needs no model: each agent has a competence weight per ticket source and a cap on concurrent load, and the pick is weighted-random among those available. The logic fits in a few dozen lines, the behaviour is predictable, and tuning it means editing a config file.

Deterministic structural diffing. Finding how an incoming contract differs from your template is a tree-comparison problem, not a language-understanding one. Handing it to a model means volunteering a chance of invention where an exact answer exists. We cover this in the AI contract review guide: code does the diffing, the model only interprets what the diff found.

What you give up by reaching for a model anyway

• Reproducibility. The same input yields different answers across runs. Invisible in a demo; in production it's reports that disagree with each other and trust that quietly drains away.
• Explainability. A rule can be read. A weight can be adjusted. A model's decision can only be accepted or rejected.
• Cost and latency. Inference costs money per call or needs a GPU of its own. Two tenths of a second on CPU versus a network round-trip to an external API is a difference users feel.
• Data perimeter. An external API means the data left the building. For HR exports and contracts that's a conversation you could have avoided having.
• Exact identifiers. Part numbers, model codes, error codes go badly with semantic search: VF-3YT and VF-3YR are near-indistinguishable to an embedding. Where an exact string match is what you need, lexical search and metadata filters beat dense vectors.

Where a language model genuinely earns its place

The other side, without which the list above would read as denial.

• An open set of answers. Explaining what specifically in a contract clause creates exposure — that answer can't be picked from a list, it has to be composed.
• Semantic ambiguity. "How is the spindle cooled" should find the paragraph about the cooling system even when the word "cooling" isn't in it. That's exactly what lexical matching can't do.
• Long unstructured text. Compressing an hour-long conversation into its substance, pulling intent out of an email, turning free-form description into structure.
• Flexibility over predictability. Work where rules would have to be rewritten weekly to keep up with new phrasings.

Almost always the right answer isn't "model or rules" but a division of labour: the model does what nothing else can, and everything computable stays in code. In our call-scoring system the language model marks observable facts with a quote from the conversation, while the arithmetic of the score and the escalation thresholds run in ordinary Python — because that score notifies a real sales manager, and it has no business depending on a coin flip.

A short test before you start

Four questions worth asking before picking a tool:

1. Can you enumerate every valid answer? If yes, you probably don't need a model.
2. What kind of noise is it — typos and abbreviations, or different ways of expressing one idea? The first is a normalization problem.
3. What happens if the system answers differently on the same input twice? If that's a problem, the arithmetic and the decisions belong in code.
4. What does one call cost at your real volume? Sometimes that answer settles it on its own.

Your labelled sample is an argument too. On the job-title project a trained classifier was rejected on arithmetic alone: 50 labelled rows against 56 classes would have almost certainly overfitted and lost the rare ones. That took one evening of counting and saved weeks of work in the wrong direction.

How we did it

• Job title classifier: 1C exports into a reference list — normalization, fuzzy matching, confidence calibration. 277 of 300 records accepted automatically, 23 routed to a human. No LLM, no embeddings, no external APIs. Open source.
• Ticket auto-routing: a mini-CRM for agents — competence weights and load caps instead of a model. Open source.
• AI contract analysis — division of labour in practice: deterministic template diffing, model-driven risk flagging.

If you're unsure whether your task needs a model — let's talk for 30 minutes. "It doesn't" is a legitimate outcome.