A product-image index is not an asset you build once. It is a loop you run, and the loop has a monthly price: catalogue churn drives re-embedding, re-embedding drives GPU hours, and the staleness window in between is what a shopper actually experiences. Index freshness is measurable, which means it can be budgeted before launch rather than discovered as unexplained conversion drift six months in.
Most visual-search budgets we see are built around the initial build β embed the catalogue, stand up the vector index, ship the storefront surface β with the refresh loop left as an implicit assumption. That assumption survives exactly as long as the catalogue stands still. New SKUs arrive, imagery gets re-shot for a seasonal template change, variants are consolidated, and the index quietly stops describing the products on sale.
This piece is about the operating line item: how to measure churn, how to convert churn into a cadence, and what that cadence costs in compute, storage and human attention. The broader ownership model β per-query inference, vector-store residency, fallback handling β is priced separately in our visual search cost model at catalogue scale.
What does keeping a product-image index fresh actually mean?
Freshness is not a binary state. It is a latency: the number of hours between a SKU or image change in the product information system and that change becoming searchable in the vector index. We call that catalogue-freshness latency, and it is the single number that most usefully anchors the budget conversation.
Four sub-costs sit under it:
- Detection β knowing that an image or SKU changed at all. Cheap if your PIM emits change events with image hashes; expensive if you have to diff the catalogue on a schedule.
- Re-embedding β running the changed images through the embedding model. This is the GPU line.
- Index write β an incremental upsert into the vector store, or a full rebuild when the embedding model or index parameters change.
- Fallback handling β what the storefront does for items that are stale, unmatched, or mid-refresh.
The first and fourth are usually underestimated. In our experience, detection gaps are the most common cause of a freshness loop that looks healthy in dashboards while a specific product family is months out of date β the re-embedding job ran perfectly on the wrong list of images.
Measuring churn before you size the loop
Churn is measurable directly from the catalogue history, and it decomposes into three rates that behave very differently:
- SKU add/retire rate β new products entering, discontinued products leaving. Drives incremental work.
- Re-image rate β existing SKUs whose primary or secondary imagery was replaced. This is the rate teams forget, and it is the one that degrades match quality without changing any SKU count.
- Structural change rate β variant regrouping, pack-size consolidation, image-template redesigns. Drives bulk work in bursts, not a steady trickle.
Pull twelve months of catalogue history and compute each rate weekly. The distribution matters more than the mean: a fashion retailer with a 3% weekly average and a 25% pre-season spike needs a loop sized for the spike and a budget sized for the average. A grocery or hardware catalogue with steady sub-1% weekly churn can run a far cheaper cadence.
Cadence follows from the rate and the acceptable latency, not from convenience. If 4% of the catalogue changes weekly and you accept a 24-hour freshness latency, you need a daily incremental cycle covering roughly 0.6% of the catalogue β a small, predictable job. If you run the same catalogue on a monthly cycle, roughly one SKU in six is misrepresented in the index at any given moment, and match quality decays in a way that looks like model degradation but is not.
Incremental upsert versus full re-embed
These are different cost classes and should be budgeted separately.
| Trigger | Correct operation | Scope | Typical cost class |
|---|---|---|---|
| New SKU, image replaced, variant added | Incremental embed + vector upsert | Changed items only | Small, daily, predictable |
| Image template / crop convention changed catalogue-wide | Full re-embed | Entire affected category or catalogue | Large, bursty, planned |
| Embedding model version change | Full re-embed + index rebuild | Entire catalogue | Largest; requires dual-index cutover |
| Vector index parameter change (metric, quantisation, graph params) | Index rebuild from stored vectors | No re-embedding needed | Medium; compute-bound not GPU-bound |
| Match quality regression with no catalogue change | Diagnose first β do not re-embed | n/a | Investigation, not compute |
The last row earns its place. Re-embedding is the reflex response to a quality complaint and it is frequently the wrong one: near-duplicate SKUs, angle and lighting mismatch in shopper photos, and out-of-catalogue queries all present as βbad matchesβ and none of them are fixed by a fresher index. Those structural failure modes are enumerated in where CV product-matching fails in retail visual search.
Note also that storing raw embeddings β not just the built index β converts a whole class of would-be full re-embeds into cheap index rebuilds. Keeping float32 vectors alongside a quantised serving index costs storage, but storage is the cheapest line in this budget by a wide margin.
Sizing the compute footprint
The honest way to budget GPU hours is to measure your own throughput rather than borrow a number. The measurement is straightforward: run a representative sample of your catalogue images through the actual pipeline β decode, resize, normalise, forward pass, write β on the hardware you intend to use, and record images per second end to end.
Two things routinely surprise teams doing this for the first time. First, the embedding forward pass is often not the bottleneck; image decode and network fetch from object storage frequently dominate, which means the fix is dataloader and I/O work rather than a larger GPU. Second, batch size and precision choices move throughput more than model choice does within a family of similar encoders. A pipeline built on PyTorch with a TensorRT or ONNX Runtime export path for the encoder typically leaves substantial headroom on the table until someone profiles it deliberately.
Once you have images-per-second on your stack, the arithmetic closes:
- GPU hours per refresh cycle = (images changed per cycle) Γ· (measured images per second) Γ· 3600
- Monthly compute cost = GPU hours per cycle Γ cycles per month Γ instance hourly rate
- Storage = (vectors Γ dimensions Γ bytes per element) for the serving index, plus the same again if you retain full-precision vectors, plus the source image bucket
Keep those three lines visible next to the initial build cost. The build is a one-off; the loop is forever, and it is the loop that gets cut in the second budget cycle by someone who never saw it itemised.
What the storefront does while an item is stale
A freshness loop without a defined stale-state behaviour just relocates the failure to the shopper. Three decisions belong in the design, not in an incident review:
- Fallback path. When an image query returns no result above the confidence threshold, or returns a match to a retired SKU, the surface should degrade to category browse or text search with the visual attributes pre-applied β not to an empty state. Text search remains the primary discovery mode for identifier-shaped intent, which is why visual search sits alongside it rather than in front of it.
- Logging. Every fallback event should record the query, the top candidate scores, and the index age for the matched category. Without index age in the log you cannot later separate a freshness problem from a model problem.
- Suppression. Retired SKUs should be removable from the serving index faster than new SKUs are added to it. Asymmetric urgency is correct here: showing a shopper a product you cannot sell is worse than not yet showing one you can.
Tying spend back to outcomes
The reason to instrument all of this is to make the freshness budget arguable in commercial terms. Track image-search-to-cart rate segmented by the index age of the matched catalogue cohort, and track fallback rate over the same segments. If cart rate is flat across index-age buckets, your cadence is faster than it needs to be and there is money to reclaim. If it drops measurably in the older buckets, you have the number that justifies the compute β and it is a number, not a complaint about degradation.
That segmentation is a measurement design problem in its own right, and it is easy to get wrong: the same seasonality and traffic-mix noise that corrupts a naive before/after conversion read will corrupt an index-age read too. We work through the retail side of discovery instrumentation more fully in our retail AI practice, and the embedding and vector-index mechanics underneath it are general computer vision pipeline engineering applied to a catalogue.
The uncertainty worth naming: churn rates are stable enough to budget from, but merchandising decisions can change them overnight β a supplier switch or a photography-standard revision can turn a quiet quarter into a full re-embed. Size the steady-state loop from measurement, and hold a contingency for the burst you did not schedule.
Frequently Asked Questions
What does keeping a product-image index fresh mean in practice, and what does it actually cost?
Maintaining an up-to-date product image index requires balancing storage expenses, compute cycles for re-indexing, and API call frequency. In real use, it means running a loop with a target latency: detect a catalogue or image change, re-embed the affected items, upsert them into the vector index, and handle anything stale in between. The cost is four lines β change detection, GPU hours for re-embedding, index write or rebuild, and fallback handling β of which GPU hours are the most visible and detection gaps the most commonly missed.
How do we measure our catalogue churn rate, and how does it set the re-embedding cadence?
Pull twelve months of catalogue history and compute three weekly rates separately: SKU add/retire, re-image, and structural change. Cadence then falls out of the rate and your accepted freshness latency β a 4% weekly churn with a 24-hour latency target implies a daily incremental cycle over roughly 0.6% of the catalogue. Size the loop for the seasonal spike, budget from the average.
When is incremental re-indexing enough, and when is a full re-embed unavoidable?
Incremental upsert handles new SKUs, replaced images and variant additions β the steady trickle. A full re-embed is unavoidable only when the embedding model version changes or when a catalogue-wide imagery convention changes, such as a new crop or template standard. Index parameter changes need a rebuild but no re-embedding, provided you retained the vectors.
What GPU and storage footprint should we budget per million catalogue images?
Measure rather than borrow: run a representative image sample through your actual decode-resize-forward-write pipeline on your intended hardware and record end-to-end images per second, then divide. Storage is the sum of the serving index vectors, optionally retained full-precision vectors, and the source image bucket β and it is usually the cheapest line, which is why keeping raw embeddings is good economics.
What staleness latency is acceptable before shoppers see wrong or missing matches?
There is no universal threshold; the acceptable window is whatever keeps your image-search-to-cart rate flat across index-age cohorts. Set a target latency, instrument cart rate and fallback rate by index age, and adjust the cadence in whichever direction the data points β faster if older cohorts convert worse, slower if they do not.
How should the system behave β fallback path and logging β while an item is stale or unmatched?
Degrade to category browse or text search with visual attributes pre-applied, never to an empty state, and remove retired SKUs from the serving index faster than you add new ones. Log every fallback with the query, top candidate scores, and the index age of the matched category β without index age you cannot later distinguish a freshness problem from a model problem.
How do we tie index-freshness spend back to image-search-to-cart and fallback-rate metrics?
Segment both metrics by the index age of the matched catalogue cohort rather than reading them globally. A flat cart rate across age buckets says the cadence is over-provisioned; a measurable decline in older buckets gives you the per-month value that the refresh compute protects, which is the form the finance conversation actually needs.
Budget for the refresh cycle, not the launch
Monthly image updates cost 40β60% of the initial indexing budget, yet most procurement teams allocate nothing beyond year one. Revisit it when your workload shifts.
