Written by: Kacper Osiewalski, Lead Backend Engineer, Digital Colliers
The first question after any AI procurement demo is which model got fine-tuned. For catalogue data, that's usually the wrong question. Fine-tuning bakes your data into model weights at training time. If your parts list changes tomorrow, your model doesn't know. You're answering queries from a snapshot that's already stale.
Fine-tuning optimizes for the wrong problem
Fine-tuning works when you need domain-specific reasoning or tone, not when you need up-to-date facts. A model fine-tuned on your January parts catalogue will confidently hallucinate about products you discontinued in February. It can't tell the difference between what it learned during training and what's true right now.
The retraining cycle is the other trap. You commit to fine-tuning, then discover you need to retrain every time a supplier changes a SKU or a price shifts. Most teams estimate a monthly cadence. Reality imposes weekly or daily updates. The compute cost compounds. The deployment lag grows. The pattern I keep seeing is teams who ship a fine-tuned proof-of-concept, then spend six months in retraining hell before they ever reach production scale. 88% of AI proof-of-concepts never reach widescale deployment. The fine-tuning default is a large part of why.
Grounded retrieval fits catalogue data shape
Grounded retrieval (also called RAG, retrieval-augmented generation) pulls current facts from a live database at inference time. The model gets your query, fetches the relevant catalogue rows, and answers using what it just read. When you update a part price at 9am, the next query at 9:01 sees the new number. No retraining. No stale weights.
The retrieval step is where the work lives. You need vector embeddings that surface the right products for ambiguous queries. You need structured filters so the model can narrow by category, supplier, or availability. You need the system to handle partial matches and typos without returning garbage. But once that retrieval layer works, your data stays fresh. The architecture follows the shape of your problem.
What winning operators build
The operators shipping catalogue systems in 2026 tend to run grounded retrieval with three layers. First, a vector store that indexes product descriptions and specs. This catches semantic queries like "something that mounts on a DIN rail" even when your catalogue uses different terminology. Second, a metadata layer that enforces structured filters. The model can narrow by in-stock status, price range, supplier, or compatibility without guessing. Third, a citation mechanism that shows the user which catalogue rows the model consulted.
That last piece matters more than most teams expect. When the model says a part costs £47, the citation shows the source row. The user sees the timestamp, the supplier, the stock level. If something looks wrong, they can verify. That transparency keeps the system trustworthy even when the model makes mistakes. More than 80% of AI projects fail. The subset that survives tends to include systems the user can verify and correct.
The implementation pattern is consistent. You version your catalogue in a proper database. You keep embeddings in sync with catalogue updates using a lightweight pipeline. You log every retrieval so you can debug when the wrong products surface. You instrument the citation step so product managers can see which parts the model references most often. The system becomes a lens on your catalogue, not a black box.
The left-behind risk
Fine-tuning for catalogue data leaves you with a system that gets worse every day. The model confidently cites discontinued products. It quotes last quarter's prices. It recommends parts you no longer stock. Users ask why the AI is wrong, your team explains it needs retraining, and the credibility drops. After a few cycles, users stop trusting it. Then they stop using it. 95% of enterprise GenAI pilots deliver zero measurable P&L impact. This is one of the paths that gets you there.
Grounded retrieval keeps pace with your data. You update the catalogue, the system updates. You add a new supplier, queries start surfacing those parts immediately. You discontinue a product line, the model stops recommending it within seconds. The architecture fits the problem. That was the point.