Why an embedding search cannot find a CUSIP
Identifiers are strings without meaning. What a vector index does with them, and the two-line fix.
Ask a vector-only index to retrieve documents about 037833100 and it will return passages containing numbers that look similar, about entirely different companies. The index is not broken. It is doing exactly what it was built to do, and that is the problem.
Meaning versus identity
An embedding places text near other text with similar meaning. An identifier has no meaning to place. 037833100 is Apple, but the model has never learned that; to it the string is nine digits with no neighbours. So it reaches for surface similarity and returns noise.
Identifiers are the one thing in finance that must match exactly and never approximately. A near-miss on a CUSIP is not a slightly worse answer. It is a different company.
The two-line fix: hybrid retrieval
Run two indexes. A keyword index handles exact terms and identifiers, where a match is a match. A vector index handles meaning, where "similar to" is the whole point. A fusion step combines the two rankings so a query can filter on the CUSIP and still rank by relevance.
Most real questions need both at once: filter in the keyword index, rank in the vector index, join on the identifier.
The test
Search fifty identifiers you know are in the corpus. Count the misses. On a vector-only system the number will surprise you. On a hybrid one it should be zero.