Choosing an embedding model for financial documents, and what goes wrong when you do not
Six failures, from a model that thinks delta is an airline to a vendor that retires the model your whole index depends on.
In this note
Most teams pick the embedding model the way they pick a database driver: whatever came with the platform, chosen once, never revisited. On financial documents that decision quietly sets a ceiling on every answer the system will ever give.
The model was trained on the wrong language
A general model learns that "we reduced our delta exposure" sits near airline content, because that is where the word lives on the open web. It places a side letter's most-favoured-nation clause near marketing copy about favourites. The vectors are confident and wrong, and nothing in the pipeline tells you.
Start from a strong general model and adapt it on financial text and on question-passage pairs your analysts wrote. Prefer a model you can run yourself, so the day it is retired is your decision, not a vendor's.
Silent truncation
Every embedding model has a token limit. Feed it a long clause and it does not error. It embeds the first part and drops the rest, so the qualifying footnote that reverses the sentence is never in the vector at all. The match looks reasonable because the topic is right. The answer is wrong because the qualifier is gone.
Retirement is a re-index
Vectors from two different models cannot be compared. When a hosted model is deprecated, the entire corpus has to be re-embedded before anything works again. If you did not record the model version on every vector, you cannot even tell which ones need it.
The test you can run this week
Search twenty terms that mean one thing in finance and another thing everywhere else: delta, exposure, vintage, waterfall, carry. Count how many top-five results are about the other thing. If more than a couple are, the model does not speak your language yet.