Machines Should Retrieve, Models Should Reason

Many search and matching workloads don't need an LLM or a vector database. Use the cheapest computational primitive capable of solving the problem.

Voice recorded by author.

Machines Should Retrieve, Models Should Reason

Many search, similarity, and retrieval workloads do not require large language models or high-dimensional embeddings.

In the rush to build “smart” applications, the default architectural reflex has become surprisingly simple: put raw text through an embedding model, store the resulting vectors, and let an LLM figure out the rest.

That can be an extraordinary amount of machinery for problems that are fundamentally simpler.

If the problem is deduplication, fuzzy lookup, finding related documents, or narrowing a large collection down to a handful of relevant candidates, there is little reason to make a language model do the work.

The goal of a well-engineered system is straightforward:

Use the least expensive computational primitive capable of solving the problem.

Not All Similarity Is the Same

“Similarity” is often treated as a single problem. It isn’t.

Different problems call for different levels of computational complexity:

Fingerprinting & hashing Useful for fuzzy matching, near-duplicate detection, structural overlap, and high-throughput filtering. These operations can run in microseconds with very little memory.

Embeddings Useful when similarity depends on meaning rather than shared structure—conceptual relationships, cross-lingual matching, and broad semantic clustering.

Generative models Useful when the system actually needs to reason, synthesize information, resolve ambiguity, or generate something new.

The relationship can be thought of simply:

Fingerprint → Filter → Embed → Relate → Model → Reason

The mistake isn’t using embeddings or LLMs. The mistake is using them when a simpler tool would have solved the problem.

Using an LLM as an expensive regex engine, or a vector database as a fuzzy string matcher, means paying for capabilities you never needed.

Privacy Should Be Architectural

The same principle applies to privacy.

A retrieval system does not necessarily need to store the content it searches.

Source documents can remain inside an application’s existing database or behind a client’s security perimeter, while the retrieval layer works entirely from derived representations of that content.

Instead of moving raw documents through search workers, indexing pipelines, and third-party services, the system can operate on compact mathematical representations such as token hashes and fingerprints.

This doesn’t eliminate every theoretical privacy risk, but it can dramatically reduce the amount of sensitive information exposed by the retrieval layer.

More importantly, the search system doesn’t have to become the system of record for the content it searches.

The Simple Idea Behind LSH

One of the useful techniques for this kind of retrieval is Locality-Sensitive Hashing, or LSH.

The basic idea is simple: instead of comparing a query against every document, organize fingerprints so that similar documents are likely to land in the same buckets.

A query can then look roughly like this:

Fingerprint → Find Similar Buckets → Retrieve Candidates → Rank → Return Results

A traditional linear search has to examine the entire collection for every query.

With LSH, most of the collection can be ignored entirely. The system first finds a small group of plausible candidates, then spends its more expensive comparison work only on those candidates.

The important idea isn’t the acronym.

It’s doing less work.

Measuring Work, Not Just Accuracy

Performance claims are easy to make. What matters in production is how much work the system actually performs to answer a query.

A lightweight fingerprinting system can operate with a fraction of the memory and infrastructure required by dense vector representations, making it practical for applications where latency, cost, or resource constraints matter.

That makes the approach particularly interesting at the edge, inside worker processes, or anywhere that spinning up another piece of specialized infrastructure isn’t justified by the problem.

The goal isn’t to win a benchmark by making one operation exceptionally fast.

The goal is to make the entire system do less work.

Where This Approach Fits

Algorithmic fingerprinting is particularly useful when the relationship you’re looking for is already present in the structure of the data.

That makes it well suited for:

  • Deduplication: Finding duplicate or near-duplicate content.
  • Version detection: Identifying documents that have changed without being completely different.
  • Candidate filtering: Reducing enormous collections to a small set before invoking more expensive models.
  • Privacy-sensitive retrieval: Searching derived representations without moving raw content through the retrieval infrastructure.
  • High-throughput matching: Performing large numbers of comparisons without requiring a large inference stack.

But there are limits.

Fingerprinting cannot reliably discover relationships that aren’t represented in the underlying data. Matching a French document to an English document, connecting unrelated terminology, or understanding an abstract conceptual relationship may require embeddings or another semantic model.

And once the system has found the relevant information, reasoning is still reasoning. Synthesizing conflicting sources, resolving ambiguity, and generating an answer are problems where generative models earn their complexity.

That’s not a weakness of simple algorithms. It’s exactly why the layers should remain separate.

The Principle of Less

Vector databases and generative models are remarkable engineering achievements. They have made problems that once required enormous amounts of specialized infrastructure accessible to ordinary applications.

But they aren’t universal hammers.

Before adding another model, vector index, or agentic loop to a system, ask a simpler question:

How much of this work can be eliminated before the model ever sees it?

Let machines retrieve with lightweight algorithms. Let models reason about the information that actually requires reasoning.

The best AI system may not be the one that uses the most intelligence.

It may be the one that knows when intelligence isn’t necessary.