An embedding model turns an input into a vector so that useful relationships can be measured numerically. The difficult part is not producing vectors. It is teaching the geometry of the vector space: which inputs should be close, which should be far apart, and what “similar” should mean for the application.

Contrastive learning provides a practical answer. Instead of training only from a class label such as billing or technical support, it trains from relationships between examples. A positive pair contains examples that should have similar representations. A negative pair contains examples that should not.

This article builds that mental model from a small example, explains a common contrastive objective, and shows why pair construction, negative selection, batch size, and temperature often matter as much as the loss function itself.

Start with the geometry you want

Imagine an application that embeds support messages for semantic search. Consider three messages:

A: "I was charged twice for my subscription"
B: "My subscription payment appears two times"
C: "The mobile app crashes when I open settings"

For this application, A and B describe the same underlying problem, so they form a useful positive pair. A and C describe different problems, so they can form a negative pair.

The training goal is not to memorize these sentences. It is to adjust the encoder so that the resulting vectors have useful relative positions:

embedding(A)  <---- close ---->  embedding(B)

embedding(A)  <----------- far from ----------->  embedding(C)

“Close” and “far” require a similarity or distance function. For text embeddings, cosine similarity is common:

cosine_similarity(a, b) = (a dot b) / (||a|| * ||b||)

It measures the angle between two non-zero vectors. Values near 1 indicate similar directions, 0 indicates orthogonal directions, and -1 indicates opposite directions. Whether those numerical values correspond to useful semantic relationships depends on how the model was trained.

The important idea is that contrastive learning supervises relationships in representation space.

From one pair to a ranking problem

A single positive pair is not enough to define a useful space. If training only says that A and B should be close, a degenerate solution could map every input to the same vector. Then every positive pair is close, but the representation cannot distinguish unrelated inputs.

Negatives provide the missing pressure.

Suppose A is the anchor, B is its positive, and the batch contains three unrelated candidates:

anchor:   A
positive: B
negative: C
negative: D
negative: E

A useful objective asks the model to assign the positive a higher similarity to the anchor than the negatives. One widely used form converts similarities into a softmax distribution:

loss = -log(
    exp(sim(A, B) / T)
    /
    sum(exp(sim(A, candidate) / T) for candidate in [B, C, D, E])
)

T is the temperature, a positive scaling value. The exact objective varies across contrastive methods, but this form captures a reusable idea: the model must identify the positive among competing candidates.

If the positive already has much higher similarity than every negative, its probability under the softmax is high and the loss is low. If a negative is as similar as, or more similar than, the positive, the loss increases and training receives a stronger signal to change the representation.

Temperature changes how strongly similarity differences matter

Temperature does not change which candidate has the highest raw similarity. It changes how sharply the softmax reacts to similarity differences.

Consider one positive and two negatives with cosine similarities:

positive: 0.8
negative: 0.6
negative: 0.2

With a smaller positive temperature, dividing by T spreads the logits farther apart before the softmax. The resulting distribution becomes sharper. With a larger temperature, the logits are closer together and the distribution becomes flatter.

This affects gradients during training, so temperature is not merely a presentation setting. A value that is too small for a particular setup can make the softmax extremely sharp; a value that is too large can weaken distinctions among candidates. Appropriate values depend on the objective, similarity function, model, and data, so temperature should be treated as a training hyperparameter rather than copied without validation.

In-batch negatives make each batch do more work

Explicitly storing many negative examples for every anchor can be expensive. A common alternative is to use other examples in the same batch as negatives.

Suppose a batch contains four matched query-document pairs:

(q1, d1)
(q2, d2)
(q3, d3)
(q4, d4)

For q1, d1 is the positive. If the data construction guarantees that the other documents are not valid matches, d2, d3, and d4 can act as negatives. The same pattern applies to each query.

Conceptually, training scores a similarity matrix:

       d1    d2    d3    d4
q1     +     -     -     -
q2     -     +     -     -
q3     -     -     +     -
q4     -     -     -     +

The diagonal contains intended positives. Other cells become candidate negatives.

This makes larger batches attractive because each anchor can see more competing examples. But the benefit is conditional. More negatives help only when they are meaningful and correctly labeled. Larger batches also require more memory and computation, and distributed training may require gathering representations across devices if examples on other devices are meant to participate in the loss.

Batch size is therefore part of the learning setup, not just a throughput knob.

False negatives can teach the wrong geometry

In-batch negatives rely on an assumption: examples not marked as positives are actually negative for the task. Real datasets often violate it.

Imagine this batch:

q1: "charged twice for subscription"
d1: "duplicate subscription charge"       <- labeled positive

d2: "subscription payment duplicated"     <- treated as negative

d2 is semantically another valid answer for q1. If the objective treats it as a negative, training pushes apart examples that the application wants close together. This is a false negative.

False negatives become more likely when many examples share topics, multiple answers are valid, labels are incomplete, or batches are assembled without considering semantic relationships.

Possible responses depend on the data. You can record multiple positives, avoid placing known equivalent examples against each other, use metadata to filter impossible negatives, or use an objective that supports multiple positives. The important step is to inspect what “negative” actually means before increasing the number of negatives.

Easy and hard negatives teach different things

Not every valid negative is equally informative.

For the billing query, a message about an unrelated weather forecast is an easy negative. The model may separate it correctly very early. A message such as “my subscription renewal was declined” is harder: it shares vocabulary and domain context but represents a different support intent.

Hard negatives can teach fine distinctions that random negatives miss. They are especially useful when retrieval failures happen among superficially similar candidates.

But “hard” must not mean “possibly positive.” Mining the nearest current embeddings can surface both useful hard negatives and mislabeled positives. Aggressive hard-negative mining without label checks can reinforce dataset errors.

A practical progression is:

  1. Begin with trustworthy positives and reasonably clear negatives.
  2. Evaluate which wrong candidates the model ranks highly.
  3. Add verified hard negatives that represent those confusions.
  4. Re-evaluate instead of assuming harder negatives must improve the model.

This keeps negative mining tied to observed failure modes.

Positive pairs define the invariances you teach

Positive-pair construction deserves equal attention. When two examples are declared positive, training is encouraged to make their representations similar. That implicitly tells the model which differences should matter less.

For example, pairing two paraphrases teaches that wording can change while meaning remains similar. Pairing an image with a valid caption teaches a relationship across modalities. Pairing two augmented views of the same image can teach invariance to the selected augmentations.

This creates a boundary condition: an augmentation is useful only if it preserves the information the downstream task needs. If color distinguishes classes in the target application, an augmentation that removes color may teach the representation to ignore a feature that should remain important.

The loss function cannot recover task information that pair construction systematically tells it to discard.

Separate embedding training from downstream evaluation

A low contrastive training loss does not prove that an embedding model is useful in production. The loss measures performance on the relationships and negatives supplied during training.

Evaluate the representation using the operation the application will actually perform. For retrieval, useful measurements may include whether relevant items appear in the first k results and how rankings behave on difficult queries. For nearest-neighbor classification, evaluate classification behavior on held-out examples. If embeddings feed another model, measure the downstream task rather than only vector-space statistics.

Also keep the evaluation set independent of pair construction. If near-duplicate examples appear across training and evaluation, retrieval metrics can look strong because the model sees almost the same content during training.

A useful debugging habit is to inspect individual neighborhoods:

query
  -> nearest result 1
  -> nearest result 2
  -> nearest result 3

Metrics show how often the system works. Neighborhood inspection helps reveal why it fails: false negatives, overly broad positives, lexical shortcuts, duplicate data, or missing domain distinctions.

Know when contrastive learning is unnecessary

Contrastive learning is a strong fit when the product needs reusable representations for similarity, retrieval, clustering, matching, or transfer to another task. It is also useful when supervision naturally arrives as pairs or groups rather than as one label per example.

It adds complexity when the real requirement is simply a fixed-label prediction and a conventional supervised classifier already solves the problem. Contrastive training introduces choices about pair generation, negative sampling, similarity functions, temperature, and embedding evaluation. Those choices are worthwhile when representation geometry is part of the product requirement, not merely because embeddings are fashionable.

Likewise, if a strong pretrained embedding model already performs well on representative evaluation data, training a new contrastive model may add cost without enough benefit. Establish that baseline before building a custom training pipeline.

Conclusion

Contrastive learning is easiest to understand as supervised geometry. Positive relationships pull representations toward useful similarity; negatives provide competing alternatives that prevent the space from collapsing into an indiscriminate representation.

The practical challenge is deciding which relationships deserve that pressure. Reliable positive pairs define what should be preserved, trustworthy negatives define what should be separated, and temperature and batch construction determine how those comparisons influence optimization. Evaluate the resulting embeddings on the downstream behavior you actually need. A sophisticated loss cannot compensate for pairs that teach the wrong notion of similarity.