Engineering3 min read
ReID embeddings and vector databases
Store, index and query normalized person-appearance embeddings without losing model compatibility, privacy boundaries or review context.
A ReID embedding becomes useful when it can be searched safely and reproducibly. The vector database is only one part of that system: compatibility metadata, project isolation, thresholds and review context matter just as much as the index algorithm.
The PolyReID embedding API returns 768 float32 values normalized to L2 norm 1. A raw vector therefore occupies 3,072 bytes.
Similarity for normalized vectors
For vectors (x) and (y) with unit L2 norm, cosine similarity equals their inner product:
cosine(x, y) = (x · y) / (||x|| ||y||) = x · y
Higher similarity means the model considers the crops closer in its learned appearance space. It is not a calibrated probability that the people are the same.
Metadata you must keep
Store at least:
modeland immutablemodel_revision;preprocess_version;- your project and source-object identifiers;
- creation and expiry timestamps;
- the lawful-purpose and access boundary needed by your application.
Never mix vectors from incompatible model or preprocessing revisions in one search space. A silent model update can invalidate thresholds and rankings, which is why PolyReID does not retarget polyreid-person-reid-v1.
Exact or approximate search
Exact search compares the query with every vector. It is straightforward and often sufficient for small galleries. Approximate nearest-neighbour indexes trade a controlled amount of recall for lower latency and memory at larger scale.
Benchmark with realistic collection sizes and query patterns before choosing HNSW, IVF or another structure. Index parameters influence retrieval recall; they do not improve the underlying model. The FAISS project is one established library for dense-vector similarity search, while managed vector databases provide operational features around similar index families.
Partition by purpose
Use a separate logical collection or enforced tenant filter for each customer, project or event. A search intended for one authorised gallery must not silently expand into every vector the organisation has ever created.
Apply the same isolation to backups, analytics and deletion jobs. Store no source filename or image bytes in usage logs. If the application needs a preview, resolve it through the customer’s authorised object ID after retrieval.
Thresholds need local validation
Nearest-neighbour search always returns something when a gallery is non-empty. A “top result” can still be a bad match. Build a representative validation set, then choose review bands around the observed false-match and missed-match trade-off.
A useful interface exposes:
- the ranked candidate list, not only the first result;
- source context for a reviewer;
- an explicit reject action;
- a way to correct a merge or split;
- model and threshold versions for audit.
Revalidate after meaningful changes to cameras, crops, lighting, clothing or population. Domain drift can matter even when the API model has not changed.
Retention and deletion
Vector deletion must propagate to the primary index, replicas and any application cache. Treat expiry as an access-control rule first: deny access at the deadline, then let a retryable purge perform physical cleanup.
The API integration guide covers PolyReID’s 24-hour idempotency cache and optional 30-day vector retention. The complete Person ReID guide places the index inside the wider human-reviewed system.