Base deps: QWEN 3.6, Elasticsearch over our catalogue, and Milvus holding feature embeddings of reference images. I architected the system that turns them into a card ID.
99.98%identification accuracy on Pokémon
4.1/squeries
40KPokémon SKUs to match
The pipeline
Front and back images arrive already cropped and oriented.
A generic prompt pulls the key values off the card: name, card number, and so on.
Those filter the top K out of Elasticsearch, which queries the 40M-row catalogue my scrapers built.
The Elasticsearch score picks the top group. Everything tied at the highest score is an equally good match, so something else has to break the tie.
VariantIQ
VariantIQ is a conditional prompting system. It stores custom prompts, crop regions, reference images, and context, keyed by SKU, so a group of cards that look the same can carry its own rules for telling them apart.
Rules live in the PostgreSQL catalogue, with a schema for rule types, crop regions stored as lists of boxes, and priority.
At inference, an endpoint checks whether a SKU has a rule attached.
A rule can crop the card to a region, ask something specific like “decide if this card has this emblem or not”, and give an example or two for reference: “here is the emblem.”
Each rule resolves to a column in the catalogue that tightens the search query. Rules run highest priority first, whittling the group down until one result remains.
The card evaluation workflow.A real rule: read the copyright line, answer two checks in order.
Self-audit
SKUs marked always-audit in the catalogue go straight to audit.
If there is still a tie after all the rules run, we audit.
If the catalogue has a reference image, I compare it with DINOv2 cosine similarity. Below 0.7 and we audit.
Audit ends up being about 5% of cards, human-reviewed offshore through our audit site. Under the consignment model it was 100%. With this in place we can give the website fast, accurate Pokémon pricing and IDs for pack creation.
