Catalog Matching With LLMs: Why Changing Knowledge Should Stay Outside the Model

Product catalog matching looks simple until real-world data enters the picture. The same product may appear under different names, abbreviations, languages, units, brand conventions, or category structures. A human can usually recognize these variations, but an automated system has to formalize them.

One obvious approach is to train a local model on historical matches, deploy it on dedicated infrastructure, and periodically fine-tune it as new errors appear. This is attractive because, once the infrastructure is in place, inference can be relatively inexpensive.

The harder question is not whether such a model can perform catalog matching. It can. The question is how the system should absorb new naming conventions, supplier-specific terminology, and matching rules over time.
If every new pattern has to be incorporated through another training cycle, model adaptation quickly becomes an ongoing ML maintenance process. For this type of problem, we found it more useful to ask a different architectural question: should changing domain knowledge live inside the model weights at all?

Why One Training Cycle Is Not Enough

The same entity can be represented very differently across catalogs. Differences may include:

• abbreviations;
• transliteration;
• mixed languages;
• different brand naming conventions;
• different units of measurement;
• different product classification systems;
• new attributes;
• missing attributes;
• supplier-specific terminology.

Some of these inconsistencies can be handled during data normalization. Over time, however, new cases still appear that were not present in the original training data. If every new variation is supposed to become part of the model itself, maintaining the system quickly turns into a full ML lifecycle.

Incorrect cases have to be collected and labeled. A new training dataset has to be prepared. The model has to be fine-tuned, evaluated against both new and existing cases, and then deployed as a new version.

There is nothing unusual about this process. It is standard practice for many ML systems. The more important question is whether it is really necessary to update model weights every time a new abbreviation, transliteration pattern, or business rule appears.

An Alternative: Change the Context, Not the Model

An alternative approach is to keep the underlying model stable and change the context it receives when making a decision.
Suppose the system encounters a new pair of products and cannot determine with sufficient confidence whether they match. That case is sent for human review. The reviewer confirms or rejects the match, and the validated example is stored in a database of previous decisions.
When a similar case appears later, the system retrieves relevant validated examples and provides them to the LLM together with the new product pair. The model no longer evaluates the case in isolation. It can also see how similar situations were handled before.
A simplified version of the flow looks like this: new product pair → retrieve similar validated cases → new pair + retrieved examples → LLM → result

If the result is still ambiguous, it can be sent back for human review. Once validated, that case becomes another example that can be retrieved in the future.

It is important to distinguish this from model training. No fine-tuning happens here. The weights of the LLM remain unchanged. What evolves is the external knowledge layer available at inference time.

For that reason, it is more accurate to describe this as retrieval-based system adaptation rather than model retraining.

Why This Adapts Faster to New Data

The difference becomes especially clear when a new pattern appears.
Imagine that a known brand suddenly appears under a spelling that was not present in the original dataset. In a traditional fine-tuning workflow, that case can be saved as a new training example and included in the next model update.

But one new example rarely justifies an immediate fine-tuning run. More data usually needs to be collected. A new dataset has to be prepared, the model retrained, and the new version evaluated.

With retrieval, the validated example can be used almost immediately. Once a human confirms the relationship, it becomes available to future requests.

This is particularly useful when the new information is really a piece of knowledge or a business rule rather than a new capability that the model needs to learn.

There is little reason to modify model weights just to teach the system that EVOO means Extra Virgin Olive Oil. The same applies to supplier-specific knowledge, such as a retailer using JD as a shorthand for Jack Daniel's. These facts can be stored externally and inserted into the context only when they are relevant.

Architecturally, this separates two different responsibilities. The LLM handles language understanding and reasoning over the provided information. Current knowledge about a specific catalog and its matching rules remains outside the model in the retrieval layer.

Corrections Are Easier to Control

There is another advantage that is less obvious at first: a retrieval-based system is generally easier to debug.
After a fine-tuning run, the behavior of a model may change not only on the examples that motivated the update. The new version has to be evaluated again, regression cases need to be checked, and engineers may need to understand which changes in the dataset affected the output.
With RAG, the connection between newly added knowledge and a particular decision is usually easier to trace. It is possible to inspect which validated cases were retrieved and passed to the model. If one of those examples turns out to be incorrect, it can be edited or removed. If a business rule changes, the rule can be updated without releasing a new model version.

This does not make the final LLM decision fully explainable. The model remains probabilistic. But the layer containing accumulated domain knowledge becomes much easier to manage.

That distinction matters in business systems because the definition of a correct match can change for reasons that have nothing to do with the underlying data. Two products may be considered equivalent today, while a stricter policy may be introduced tomorrow. In such cases, updating a rule or a set of validated examples is usually easier than trying to determine how the new policy should be encoded in model weights.

What We Mean by an LLM-Based Approach

This does not mean sending two product names to GPT and asking whether they represent the same item. The LLM is only one component of the system, and the final result is based on several independent signals.

First, catalog data goes through preprocessing. Units, spelling variations, abbreviations, and other standard elements are normalized. The system then extracts relevant product attributes such as brand, product type, volume, flavor, color, or alcohol content. The attributes that matter depend on the category.

The system then searches for possible matches by combining lexical similarity, semantic similarity from embeddings, and overlap in relevant product attributes. The LLM is used where simple comparisons are not enough, for example when dealing with non-standard abbreviations, ambiguous terminology, or context-dependent interpretation.

These signals are combined into a final matching score. High-confidence matches can be accepted automatically, while borderline cases are sent for human review. The outcome of that review then becomes additional context that the retrieval layer can use for similar cases in the future.

What About Token Costs?

The most obvious argument against using a cloud LLM is recurring cost. The more requests the system makes and the more context it sends, the more it spends on inference.

A local model looks attractive from that perspective. Once the hardware has been purchased, the company no longer pays an LLM provider for every request. At sufficiently high and stable inference volumes, this can be a significant advantage.

However, comparing token costs with nearly free local inference is too simplistic.

A local model has its own lifecycle costs. These include GPU infrastructure, dataset preparation, training experiments, fine-tuning, evaluation, deployment, versioning, monitoring, retraining, and engineering time.

Fine-tuning also requires labeled data and compute resources. Every new model version has to be evaluated because an improvement on new cases does not guarantee that the model will behave equally well on existing ones.
The relevant comparison is therefore not API pricing versus a model that has already been deployed. It is the total cost of ownership of both systems.

For a local setup, that includes infrastructure, training, maintenance, and engineering work. For a cloud LLM with RAG, the main variable costs are inference and maintenance of the retrieval layer.

At moderate processing volumes, the second option can be less expensive.
If catalogs are processed only a few times per month, dedicated GPU infrastructure may remain idle for much of the time. It still has to be purchased or rented, configured, and maintained. A cloud model follows a different cost structure: when there is no inference workload, there is little or no model usage cost.

Retraining introduces another cost component. If the model has to be updated regularly because new data formats and naming conventions keep appearing, the savings from local inference may be smaller than they initially seem.

When a Local Model Still Makes More Sense

None of this means that LLM + RAG is always the better option.
A local model may be significantly more economical at very high inference volumes. The same applies when latency requirements are strict or when data cannot be sent to external cloud services.

Fine-tuning is also more attractive when the domain is stable, matching rules change infrequently, and the organization already has a large, high-quality labeled dataset and the infrastructure needed to support an ML lifecycle.

In that situation, a trained model may perform the same task for a long time with predictable costs.

Catalog matching often falls into a different category. Many of the changes are related to terminology, new ways of representing existing entities, and changing interpretation rules. That information does not necessarily need to be encoded in model weights every time it changes.

Conclusion: Where Should New Knowledge Live?

In practice, the choice between fine-tuning and RAG comes down to a simple architectural question: what should change as the system accumulates experience?

With a fine-tuned local model, human corrections gradually become part of a new training dataset, and the knowledge is eventually encoded in a new version of the model.

With an LLM + RAG approach, corrections remain explicit validated examples. They can be retrieved and used when the system encounters a similar situation.

These approaches reflect two different architectural ideas. The first assumes that the model itself should become increasingly specialized over time. The second keeps a strong general-purpose model relatively stable and builds specialization around it through context and accumulated decisions.

For catalog matching, the second approach is often more practical. It can adapt faster to new variations in the data, makes accumulated knowledge easier to control, and avoids starting a new training cycle every time the domain changes.

There is still a recurring cost for LLM inference, and at sufficient scale that cost may become significant. But recurring token costs do not automatically mean that the overall architecture is more expensive.
Sometimes it is cheaper to pay for context that can be updated today than to keep retraining a model so that it remembers something that may change again tomorrow.

Struggling With Product Matching Across Catalogs and ERP Systems?

At Businessware Technologies, we build AI-powered matching pipelines that connect supplier catalogs, customer RFQs, and internal product databases — even when product names, attributes, and formats don't align.

Our solutions combine LLMs, semantic search, business rules, and human validation to automate matching while continuously incorporating verified corrections.

Have a product matching challenge? Let's discuss your use case and explore how to automate it without building a costly model retraining pipeline.

Let's discuss your use case →