All guides

Foundations3 min read

Person Re-Identification: a practical guide for production systems

Understand person ReID inputs, embeddings, evaluation, retrieval, failure modes and the human controls required beyond a model benchmark.

Person re-identification, or Person ReID, is the task of retrieving images of the same person across a collection using visual similarity. In production it is best understood as ranked retrieval, not as a declaration of civil identity.

PolyReID’s Person Re-Identification API accepts one person crop and returns an appearance embedding. Detection, tracking, names and automated decisions sit outside that contract.

From a crop to a ranked list

A typical offline workflow has four distinct stages:

  1. a separate process creates one-person crops;
  2. the ReID model maps each crop into a fixed-dimensional vector;
  3. a vector index returns the nearest candidates;
  4. a human or a carefully validated downstream rule reviews those candidates.

Keeping these stages separate makes errors traceable. A bad crop is a detection or input-quality problem; a poor neighbour ranking is a representation or domain-shift problem; an incorrect final decision can be an oversight and product-design problem.

What an embedding represents

An appearance embedding compresses visual cues that were useful during training. It does not contain a human-readable identity field. Two close vectors suggest that two crops look similar under the model, within the same model revision.

This distinction matters. Similar costumes, body shape, occlusion and motion blur can create false neighbours. A costume change can push images of the same person far apart. Learn more in ReID embeddings and vector databases.

Evaluation without overclaiming

Academic ReID often reports Rank-k and mean Average Precision (mAP). Rank-1 asks whether a correct candidate appeared first. mAP also considers the ordering of multiple relevant results. Both depend on the evaluation protocol, gallery composition and dataset.

A number measured on one ballroom dataset is not a universal accuracy promise. Before deployment, build a representative validation set for the intended cameras, venues, clothing and population. Measure false matches, missed matches and reviewer workload at the threshold you intend to use.

For polyreid-person-reid-v1, internal ballroom metrics remain unpublished as API performance until the evaluated checkpoint hash is proven to match the immutable serving revision.

Known production failure modes

  • Similar appearance: two people may wear near-identical clothing.
  • Motion blur: the crop can lose the texture and structure used for retrieval.
  • Occlusion: a partial or head-only crop falls outside the intended input.
  • Wardrobe change: an appearance model has no inherent continuity across a major costume change.
  • Domain shift: results can change with cameras, viewpoints, culture, clothing and lighting.
  • No temporal reasoning: a standalone image endpoint does not know what occurred before or after the frame.

These are system-design inputs, not footnotes. Preserve source context, allow rejection, and make ambiguous results easy to inspect.

Privacy and governance

An embedding can remain personal or biometric data when it is used to single out or identify a person. Pseudonymisation reduces risk but is not automatic anonymisation. Define the purpose, legal basis, access boundaries, retention, deletion and human oversight before generating vectors.

The EU AI Act classification of a complete deployment depends on intended purpose and use. The public responsible-use summary explains PolyReID’s current assessment status without claiming that every customer integration shares one classification.

A sound starting architecture

Use a project-scoped vector collection, store the model and preprocessing revision with every vector, require idempotency for generation, and retain only the data your purpose needs. Monitor result quality after camera or workflow changes. Version thresholds and reviewer rules alongside the model.

The final quality of a ReID product comes from this full loop—input validation, versioned inference, retrieval, calibrated thresholds, human review and data governance—not from the embedding endpoint alone.