NLP vs LLM vs RAG, Routed by Task Shape and Cost

Most "add AI to this document workflow" requests never needed a generative model. Strip away the business wording and the ask is almost always one of five shapes, and four of them terminate in deterministic components that cost fractions of a cent to at most a few cents per page and structurally cannot hallucinate, because nothing in them generates text. That is the honest answer to NLP vs LLM vs RAG: the request's shape decides the branch before any pricing page is opened. Enterprise document-intelligence writing has largely converged on RAG as the centerpiece, including a whole series on building RAG brick by brick from minimal to corpus scale. Useful as those guides are, they start after a decision that belongs first. How large are the per-request cost gaps between branches? Which failure signature does each branch carry? Where does a frontier model genuinely earn its keep? The rest of this piece answers all three, in order.

Why Task Shape Comes Before Model Choice

When a stakeholder says "add AI," the reflex question is "which model?" That question is premature. The first question is "what shape is this task," because shape determines the cheapest reliable handle, the failure contract you sign, and the monitoring you owe the system in production.

Five shapes cover nearly every document and text request crossing a practitioner's desk: classify, match to a reference list, read a table, clean noise, synthesize. Only the last one produces novel text. Route the first four to deterministic components and you inherit three properties no prompting technique provides: marginal costs measured in fractions of a cent to a few cents per page, failures that announce themselves, and behavior you can unit test. Route everything to a frontier model instead and you pay generation prices for pattern matching, then pay again chasing stochastic bugs.

The stakes are not hypothetical. Under budget scrutiny, the difference between a pipeline costing pennies per thousand documents and one costing dollars per hundred becomes a line item someone will eventually question. And in document workflows a silently wrong answer is worse than an exception, because it flows downstream looking correct.

The Five Task Shapes and Their Cheapest Reliable Handle

Name the shape and the routing decision mostly makes itself.

Three one-line definitions so the table reads cleanly: classical NLP is statistical and rule-based text processing, deciding rather than generating; an LLM is a generative model that produces text; and RAG is retrieval over a corpus feeding that generator the passages it needs.

Task shape	Typical ask	Cheapest reliable handle	Cost per document
Classify	"Route these tickets"	Small supervised classifier (linear model over TF-IDF, or spaCy's TextCategorizer)	Fractions of a cent
Match to reference list	"Normalize vendor names against our master list"	Fuzzy string matching (RapidFuzz, edit distance scoring)	Effectively free
Read a table	"Extract line items from these invoices"	Layout-aware parser or OCR table extraction	Cents per page or less
Clean noise	"Fix OCR garbage before indexing"	Rule-based cleanup, domain dictionaries, regex passes	Effectively free
Synthesize	"Summarize the risk clauses in this contract"	LLM call, or RAG over a large changing corpus	Cents per call

Two of these deserve comment, because they are the ones teams over-engineer. Matching free text to a reference list is not a semantic understanding problem; "Acme Mfg Corp" against "Acme Manufacturing Corporation" is a distance computation, and libraries built for it settle millions of such comparisons on a laptop. Reading a table is not a reading comprehension problem; it is a geometry problem, and layout-aware parsers solve it by detecting cell boundaries rather than understanding language. Neither task rewards a generative model, and both punish one at volume.

OCR cleanup without an LLM is its own quiet win: confusable-character fixes, dictionary lookups against a domain lexicon, ligature and whitespace normalization. These passes are deterministic, inspectable, and free at the margin.

The Classical NLP Branch and Its Cost Math

The classical NLP techniques in this branch are old and unglamorous for a reason: they solved these problems. Three worked examples with the arithmetic shown.

Matching a vendor list. Suppose 1,000 invoices a day must reconcile against a 5,000-entry vendor master. That is 5 million comparisons, which CPU-bound fuzzy matching handles in seconds on commodity hardware. Per-document compute cost rounds to zero; the real costs are authoring the reference list and tuning thresholds. The dominant failure mode is a zero match, which is loud.

Classifying at scale. For text classification in production, a linear model over TF-IDF features or a small spaCy pipeline remains the default. Public sparse classifier benchmarks typically put such models in the milliseconds-per-document range on CPU, which prices classifying a million documents near the cost of running a small VM for a day. That puts a trained linear model among the cheapest reliable ways to classify documents at scale, orders of magnitude below generation prices. One caveat the pricing math hides: this handle assumes labeled training data already exists. The branch's real upfront cost is the label budget, and at cold start, labeling a few thousand documents can dominate everything else here. When no labeled set exists yet, the hybrid router below is the bootstrap path: the LLM boundary handler fields the early traffic, and its promotion loop harvests logged fallbacks as training rows.

Reading and cleaning documents. Cloud OCR bills per page, typically fractions of a cent for plain text and more for table or form parsing; figures move, so anchor to vendor pricing rather than to this article. Tesseract's accuracy documentation is candid that quality depends heavily on input quality, which is exactly why deterministic cleanup passes belong in the pipeline: they handle the head of the noise distribution and flag the rest rather than guessing at it. In template-heavy workloads, layout-aware table parsing plus rule-based cleanup can match or beat a general-purpose LLM at a small fraction of the per-document cost.

The RAG Branch, When Retrieval Is the Job

Adopting RAG means subscribing to a data pipeline, not calling a feature. Someone has to own ingest, chunking, and embedding on every corpus update; someone has to keep the index fresh when sources change daily; and every query still pays a generation tax on top. The decision worth making is whether the org will actually run that pipeline indefinitely, because a neglected RAG stack does not degrade gracefully. It keeps answering, fluently, from whatever the index happens to hold.

That framing turns when to use RAG into a concrete question with three conditions to check: the corpus is large, the questions are open-vocabulary (you cannot enumerate answers in advance), and the corpus changes. Question answering over a contracts archive, an internal wiki, or support history fits all three. When they align, a solid retrieval augmented generation primer covers the mechanics from there; routing precedes mechanics.

The not-RAG signals deserve equal billing, because they are where most requests actually land. A fixed answer set is your strongest signal for when not to use an LLM or a RAG stack at all; that is matcher or classifier territory. A single document is a direct LLM call, since retrieval over one document is just an LLM call with extra steps. And a small static corpus that fits a modern context window argues for long context on sheer simplicity: paste the corpus in, skip the pipeline. RAG wins that fight only at scale, when the corpus outgrows the window; at freshness, when answers must track a living source; and at per-query cost control, when re-feeding the whole corpus into the prompt on every call stops being defensible.

The cost stack surprises people who only price the embeddings. Ingest, chunking, and embedding recur with every corpus update; vector storage and retrieval bill per query; and the generation call on top costs the same as any direct LLM call. A RAG vs classifier cost comparison is therefore not close: the classifier answers for effectively nothing, while RAG pays retrieval scaffolding plus generation on every request. Its recurring bill is dominated by the generation riding on each query, not by the embedding tier.

The LLM Branch, What a Frontier Call Is For

A frontier call is for asks that genuinely produce novel text dependent on synthesis or judgment: drafting a memo, assessing whether a clause is risky, extracting fields from wildly varied free text no parser anticipates, or handling the strange document your deterministic layer punted on. These are generation problems, full stop.

LLM cost per request is a multiplication problem with public inputs. Take a ten-page contract, roughly 5,000 input tokens, and a 400-token structured answer. At mid-tier list prices in the range of a few dollars per million input tokens and roughly five times that for output, the call costs about two cents. Verify current figures on OpenAI's pricing page and Claude's pricing page; list prices move often. Two cents sounds harmless until multiplied: 100,000 documents a month lands in the low thousands of dollars, against a fuzzy-matching layer whose compute rounds to zero and a classifier paying VM prices. The per-request gap between the effectively-free matcher layer and a frontier call spans three to four orders of magnitude, and every figure in that math is checkable on public pricing pages. Defaulting every ask to the frontier model means paying generation prices for matching-shaped and classification-shaped work.

Failure Modes, Loud Versus Silent

Each branch has a failure signature, and the signature should drive how much of that branch you can safely afford.

Branch	Failure signature	What you monitor
Deterministic (rules, matchers, classifiers)	Loud and local: exceptions, zero-matches, flat confidence	Error rates per rule, threshold margins, unit tests
RAG	Quiet at retrieval: wrong or stale context, fluent wrong answer	Chunk recall, index freshness, not-found rate
Frontier LLM	Silent and stochastic: plausible wrong content, sampling variance	Scheduled eval sets, schema checks, human audits

Deterministic components fail loudly and locally. The matcher returns nothing above threshold, the classifier's probability mass goes flat, the parser throws. The failure has a stack trace, a unit test can reproduce it, and the blast radius is usually one document.

RAG fails quietly upstream of generation. The retriever misses the chunk holding the answer, or the index is stale relative to the source system, and the model then answers fluently from the wrong context. RAG failure-mode research keeps converging on retrieval quality as the first thing to measure, which tells you where evaluation effort belongs: chunk recall on known-answer questions, index freshness, and explicit not-found behavior.

LLMs fail silently and stochastically. The output is valid JSON with a wrong value; the summary invents a clause; the same input fails today and passes tomorrow. That changes the monitoring contract: you need held-out eval sets run on a schedule, schema validation that catches malformed but not wrong, and periodic human audits, because nothing in the pipeline volunteers that it erred.

The routing consequence: loud branches scale cheaply because their errors announce themselves. Silent branches need paid supervision forever.

The Hybrid Router With the LLM as Boundary Handler

The strongest production pattern is not a choice among the three branches but a cascade. The deterministic layer answers everything it can, with a confidence score attached. Anything below threshold, the tail of the distribution, routes to the LLM with a tight prompt and a constrained output format. This LLM fallback pattern lets the head of the distribution flow through pennies-per-thousand code.

Accuracy often improves alongside spend, for a structural reason. The deterministic layer handles the repetitive head where it is reliably right, and the LLM sees only genuinely ambiguous inputs, where its judgment is what you are paying for. You route low confidence cases to an LLM and let both halves of the distribution play to their strengths.

The promotion loop turns the fallback into a shrinking cost center. Log every LLM exit with input and output. When the same correction recurs, promote it: a vendor name the LLM fixes weekly becomes a canonical alias in the reference list, and a recurring low-confidence class becomes labeled training rows or a new rule. The deterministic layer absorbs what the LLM taught it, and the fallback rate falls.

def route(doc):
    score, result = deterministic_layer(doc)   # matcher, classifier, parser
    if score >= THRESHOLD:
        return result
    answer = llm_fallback(doc)                 # tight prompt, constrained output
    log_fallback(doc, answer)                  # feeds the promotion loop
    return answer

Treat the threshold as a product decision, not just an ML one. Start conservative, measure precision at each candidate threshold on a labeled sample, and remember the threshold literally sets how many documents per day you are willing to pay cents for.

An NLP vs LLM vs RAG Checklist You Can Ship

1. Name the shape. Classify, match, read, clean, synthesize. If you cannot name it, ask the requester what a correct output looks like; the answer usually names the shape for you.
2. Ask whether the output must be novel text. If not, a generative model is the wrong branch on both cost and failure grounds.
3. Ask whether the answer set is fixed. Fixed list or label set routes deterministic. Open vocabulary over a changing corpus routes to RAG. Judgment and drafting route to an LLM.
4. Do the volume math in public prices. Cost per document times monthly volume, per candidate branch, written down. The gap is usually the whole argument.
5. Write the failure contract. What does a bug look like in this branch, and who notices first?
6. Add the fallback before you need it. Confidence threshold, LLM boundary handler, logged outputs.
7. Instrument the promotion loop. Review recurring fallbacks monthly and convert winners into aliases, rules, and training rows.

The cost gaps are real and checkable, spanning orders of magnitude between fuzzy matching and frontier calls. The failure signatures differ in kind, loud versus silent, and therefore in what supervision each branch owes. And the LLM's correct role emerges from both: boundary handler for the ambiguous tail, teacher whose recurring answers get promoted back into the deterministic layer. Treat the NLP vs LLM vs RAG decision as a routing table keyed to task shape, and the model debate mostly dissolves into arithmetic.