PCA vs raw embeddings for feeding a risk scoring model

If you've gotten as far as having an embedding vector per site, the next question lands on your desk fast: do you feed that vector straight into your scoring model, or run it through PCA first and pass along a handful of compressed components instead. There's no universal answer here, but there is a right way to think about it for a treaty-level book.

What you're actually deciding

An embedding is just a long row of numbers, maybe a few hundred dimensions, that encode whatever the imagery model learned to encode: roof geometry, vegetation density, site layout, whatever patterns it picked up without being told what to look for. Your scoring model, whether it's a GLM, a gradient boosted tree, or something in between, has to ingest that row alongside your existing book of features: TIV, construction class, distance to coast, prior loss history.

Raw embeddings go in as-is. PCA (or another reduction, UMAP, autoencoders, whatever your team favors) collapses those hundreds of dimensions down to the 10 or 20 that explain most of the variance, and you feed those components instead. What your model and your validation process can tolerate matters more here than accuracy in the abstract.

The case for raw embeddings

Tree-based models (XGBoost, LightGBM, random forest) don't care much about collinearity between input features. They split on whatever dimension reduces loss at that node, and 300 correlated columns aren't fundamentally harder for a tree ensemble than 20 uncorrelated ones. If that's your architecture, feeding the full vector is often the simpler path: no reduction step to validate, no variance-explained threshold to pick, no retraining your PCA loadings every time the embedding model gets updated.

The cost is interpretability. When underwriting asks why a site scored the way it did, "dimension 147 of the embedding was elevated" isn't an answer anyone can act on. If your governance process needs a feature attribution story that a non-modeler can follow, raw embeddings make that harder, not the model's predictive power.

The case for PCA

Linear models are a different story. A GLM with 300 correlated embedding dimensions next to your existing features is an invitation to unstable coefficients and a validation team asking hard questions about multicollinearity. Compressing to a smaller set of orthogonal components fixes that cleanly, and it also shrinks your feature count enough that you're not drowning your existing, well-understood variables in a few hundred new ones that outweigh them by sheer count during regularization.

PCA also gives you a cheaper retraining story. If the embedding file refreshes annually and the underlying imagery model changes under the hood, a stable set of principal components built once and reused is less brittle to recompute than hoping 300 raw dimensions stay semantically consistent year over year. The tradeoff is you lose some signal, however much variance sits in the components you drop, and picking that cutoff (85%? 95%?) is itself a judgment call you'll need to document for your own model validation file.

A middle path worth testing

You don't have to pick one approach for the whole book. Run both: feed the raw vector into a candidate gradient boosted model, and feed PCA components into your existing GLM, then compare lift on a holdout set your validation team already trusts. Most risk quants we'd expect to read this already have a feature-testing harness for exactly this kind of question, since it's the same workflow you'd use to test any new candidate variable, whether that's a new peril score, a new third-party dataset, or an internal change to exposure data.

The one thing worth flagging before you start that test: an embedding vector delivered per site is meant to slot into whichever pipeline you already run, raw or reduced, not to dictate the architecture. If your team hasn't built the PCA step yet, that's a smaller lift than building a feature-extraction pipeline from scratch, which is the alternative most quants are weighing this against.

Where this leaves you

If your scoring layer is tree-based and your validation process can live without a clean attribution story, start with raw. If it's linear, or your governance process wants a small, documented set of inputs, reduce first and keep the variance-explained threshold in your model doc. Either way, the embedding itself doesn't change: what changes is the step between the file you receive and the model that reads it.

Pull the CSV, test both, and see which one your existing model actually rewards.