How to pick a vector dimensionality for a portfolio risk embedding
Most of the time this question doesn't start as a math problem. It starts because someone handed you a CSV with 256 columns of embedding and asked whether that's going to blow up your XGBoost run or just sit there doing nothing. Dimensionality isn't a property of the imagery. It's a property of how that vector interacts with the rest of your feature matrix and the number of rows you have to validate against.
Size it against your book, not against the imagery
Start by sizing the vector against your own row count, then check whether the provider's default width even fits inside that budget. If your book has 40,000 scored sites and you're already carrying 30 to 50 hand-built features (construction class, TIV, distance to coast, elevation, whatever your cat model already uses), bolting on a 512-dimension vector means your model now has more columns than most analysts would feel comfortable fitting without heavy regularization. A rough guardrail a lot of risk teams use: keep the ratio of rows to total features somewhere in the double digits per dimension, not single digits. Below that, a gradient-boosted tree starts finding splits that are really just noise in disguise, and your out-of-time validation will tell you so, usually the hard way, a year later.
This is also why "how many dimensions does a site embedding need" doesn't have one answer. A regional book of 5,000 commercial properties and a national book of 300,000 residential sites can't use the same vector length and expect the same stability. Size the input to the sample, not the other way around.
Test dimensionality the way you'd test any other feature
Three checks are worth running before a vector goes anywhere near production scoring:
Explained variance curve. Run PCA on the delivered embedding and plot cumulative variance against component count. If 90% of the variance sits in the first 40 components out of 256, you've effectively been given a 40-dimensional signal padded with 216 columns of diminishing returns. That tells you where to truncate, or whether truncating even matters once your tree model handles the correlation on its own.
Redundancy against what you already have. Correlate the embedding's top components against existing cat model variables, flood zone, wind zone, construction age, roof type proxies. A vector that just re-derives what your peril model already knows isn't adding lift, it's adding columns. The dimensions worth keeping are the ones that move your loss ratio residuals in a way your current variable set doesn't explain.
Ablation on your actual validation split. Drop the embedding entirely, record your model's AUC or Gini on held-out losses, add it back at 32, 64, 128, and 256 dimensions, and compare. If performance flattens past a certain width, that's your number. It's a one-afternoon test and it ends the argument faster than any rule of thumb.
Sizing for a cat model specifically
If this vector is feeding peril scoring rather than a general portfolio risk model, the same logic applies but the ceiling is usually lower. Cat models get re-run across scenario sets and stress tests constantly, so every extra dimension is extra compute multiplied across every simulation path. A property pricing model that runs once a quarter can absorb a wider vector than a cat engine that runs thousands of event sets overnight. Ask your modeling team what their runtime budget actually tolerates before you ask what's statistically ideal.
None of this requires building a bespoke feature-extraction pipeline to find out. Imagery Embeddings delivers a vector per site, keyed to your existing site list and refreshed annually, so the sizing question becomes something you test against your own validation sample rather than something you have to spec out before a single site gets imaged.
If you're weighing whether an embedding belongs in next year's scoring run, that's exactly the kind of test worth doing against a live file rather than a demo.