Vision models for product-image analysis: preprocessing before the vision model
A bigger model won't fix it. What you uploaded isn't what the model reasons over, not once resize, crop, tiling, and token budget get between the two.
Start with the boring baseline, not the model
A fluent answer can be grounded, half grounded, or built on a detail that vanished before inference started; from outside, those look identical. Narrow the job first. For product images that's describing attributes, comparing items, catching a bounded defect, or retrieving similar ones, using controlled views, catalog metadata, and allowed attribute values. Run embeddings and catalog filters first, escalating only where that hits layout, ambiguity, or packaging language rules can't handle cheaply. Preprocessing stays narrow: strip irrelevant variation without erasing evidence or changing its meaning.
What actually belongs in the eval log
Version the pipeline like code, and score raw, normalized, cropped, and OCR-augmented inputs separately. Log the model, runtime, prompt version, every transform, image order, OCR beside the pixels, token counts, latency, and the outcome: grounded, unsupported, abstain, or repair. Gemini CLI surfaces most of that for free; local setups behind Ollama won't, so log the projector, quantization, and preprocessing code, since a mismatched projector fails quietly while the server keeps talking. Score unsupported claims apart from missing information: an omission earns a second look, an invented serial number drives a wrong action unwatched. Reward abstention on unanswerable ones.
The enhancement trick that fools reviewers too
The failure I see most is the model inferring material, authenticity, or condition the pixels can't establish. Aggressive sharpening that clarifies text for a human eye can also invent characters never printed, or smooth a defect out of visibility; both survive casual review because they match what's expected. Require a region, frame, or label behind every conclusion, and show it to the reviewer, not a log. Separate observation from association from inference from action: red indicator is observation, network panel is association, connection failure is inference, restart the gateway is action, each needing its own evidence and authority. Multiple images add identity risk: label each, state same object or time period, drop duplicates, test a shuffled control when order matters.
The part that has to live in code, not the prompt
Keep the original retrievable and every transform reproducible in code, not prompt prose someone edits later. Store model and pipeline version with each result so an upgrade replays against the same images. Crop out rooms, faces, and reflections, with separate retention for originals, thumbnails, and debug captures; local models keep bytes off the wire but not an unencrypted disk. Track upload time for hosted models, cold-load and heat for local ones, and compare the full path at p50 and p95, not tokens per second alone. Stop once the gate passes at acceptable latency, cost, and abstention: a bigger model with more pixels just answers further past the evidence.
What I'd check next: pull the last ten unsupported-claim failures, rerun them with the exact crop and resolution the model saw, and see how many a person looking at that same image would still have believed.