Cosine similarity vs Euclidean distance for site risk embeddings
When you start feeding embedding vectors into a portfolio risk model, the first implementation question usually isn't which model architecture produced them. It's which distance metric you use to compare one site's vector against another. Cosine similarity and Euclidean distance will often rank the same sites differently, and if you've plugged an off-the-shelf nearest-neighbor function into your pipeline without thinking about this, you may be scoring site similarity on the wrong basis.
What the two metrics actually measure
Euclidean distance measures the straight-line distance between two points in the vector space, accounting for both the direction the vectors point and their magnitude. Cosine similarity measures only the angle between two vectors and ignores magnitude entirely. Two sites can sit in very different parts of the embedding space but point in nearly the same direction. Cosine similarity will call them close. Euclidean distance will call them far apart.
For site risk embeddings this isn't academic. If your embedding model encodes something like building density or structural footprint into the length of the vector, and many image encoders do, magnitude is carrying signal. Switch to cosine similarity and you discard part of what the imagery told you, without necessarily realizing it.
When cosine similarity earns its keep
Cosine similarity tends to work better once you've normalized your embeddings to unit length before comparison, or when you expect vector scale to vary for reasons unrelated to risk: a slight shift in how two imagery passes were processed, say, rather than anything about the site itself. It's also the more forgiving choice for clustering a large book into risk archetypes, where you care that a site looks like "coastal low-density industrial" and don't particularly care that its raw vector happens to be longer than its neighbors'.
When Euclidean distance is the better fit
Euclidean distance keeps the full geometry of the embedding space intact, which matters when you're running nearest-neighbor lookups to find the closest comparable sites for a specific location, pulling the five nearest analogues to a new submission to sanity-check an attachment point, for instance. If your embedding provider doesn't normalize vectors before delivery, and you should ask whether they do, magnitude differences between sites are real information, not noise to average away.
One shortcut worth knowing: cosine similarity is mathematically equivalent to Euclidean distance computed on L2-normalized vectors, up to a monotonic transform. So you don't have to rewrite your nearest-neighbor function to switch metrics. Normalize the embeddings once at ingestion, then run ordinary Euclidean distance on top.
Testing the metric against your own book
The honest answer to which metric is "right" depends on what your vectors encode and what the comparison is for: flagging likely duplicate submissions, clustering for concentration risk, or feeding nearest-neighbor distance into a loss model as a feature in its own right. Before you lock one metric into the whole pipeline, run both against a sample of sites you already know and see which one's "closest sites" line up with what your underwriters would call similar. If cosine similarity keeps grouping a beachfront warehouse with an inland one because they share a rough footprint shape, that's a sign magnitude mattered more than you assumed.
None of this changes depending on whether you built the embeddings in-house or sourced them: the vector is the input either way, and what you do with the distance metric is your model's business, not the vendor's. The deliverable here is a per-site vector you can drop straight into an existing scoring model, not a packaged similarity score you can't inspect.
If nearest-neighbor distance between sites is a feature you're still testing rather than one you've committed to, an annual batch of embeddings is a cheap way to find out whether it earns a permanent place in the model.