I've explained transformers to analysts more times than I can count, and the explanation that actually lands is never the academic one. It's the one built from things a trading desk already understands: order books, factor exposure, correlation clusters. If you've ever looked at a depth-of-market screen, you already have the intuition for how attention works. Here's the version I actually use.
Attention is a weighting scheme, not magic
When a transformer processes a sentence, it asks, for every word, which other words in that sentence matter most for understanding this one right now. That's attention. It's not fundamentally different from how you read a depth-of-market screen: you don't weight every price level equally, you weight the levels near the touch far more heavily than the ones ten ticks away, because that's where the information that matters right now actually lives.
Concretely: in the sentence "the company missed on revenue but beat on margin," a model trying to understand "beat" needs to weight "margin" heavily, and weight "missed" and "revenue" as relevant context, not noise. Attention is the mechanism that computes those weights, for every word against every other word, simultaneously. That's also why transformers handle long, structurally messy documents, like an earnings call transcript with an unstructured Q&A section, better than older architectures that processed text strictly in order: attention doesn't care about distance, it cares about relevance, the same way you don't care that a relevant price level sits a few ticks further from the touch, you care whether it's actually going to move the print.
Embeddings are coordinates, and similar things cluster
The other piece that clicks quickly for anyone who's built a factor model: embeddings are just coordinates in a high-dimensional space, and things that mean similar things end up near each other, the same way correlated names cluster together when you plot factor exposures. "Revenue miss" and "top-line disappointment" don't share a single word, but they end up close together in embedding space because they mean the same thing in context.
That's the entire trick that makes retrieval work. When StockLens searches a filing for the passage relevant to your question, it's not doing keyword matching, it's finding the passages whose coordinates sit closest to the coordinates of your question, which is why it can find "the company lowered full-year guidance" even if you asked about "cut its outlook" and those exact words never appear together.
Where the analogy breaks, and why that matters
Here's the part that matters more than the clean explanation: a depth-of-market screen shows you real, verified orders. A transformer's attention weights show you what the model found statistically relevant, not what's true. This is the single most important caveat I give every team I work with, and it's the reason nothing in StockLens generates a number that feeds a decision without a citation attached.
A model can attend heavily to a passage and still misread it. It can find the closest embedding and still retrieve the wrong document if two filings use eerily similar language to describe very different situations, which happens more often in earnings language than you'd expect, every management team reaches for the same handful of hedging phrases. The model's confidence and its correctness are two separate things that happen to correlate most of the time, and "most of the time" is not a standard you can build a research process on when real capital is downstream.
What this means for how you should actually use these tools
Understanding attention and embeddings isn't academic if you're the one deciding how much to trust an AI research tool. It tells you exactly where to look for failure: attention can be fooled by surface-level similarity, so always check the cited source, not just the generated answer. Embeddings can retrieve the wrong document when two situations are described in similar language, so a good system needs to show you what it retrieved, not just what it concluded.
That's the actual design implication I've carried into everything I've built: the model's job is to find and weigh information quickly, across more documents than any analyst could read in the same time. The verification, the part where a human checks that the weighting and retrieval actually got it right, doesn't go away because the model got better. It just moves to a different, faster point in the workflow. Understanding what's actually happening under the hood is what tells you where that check needs to happen.