Quant Memo
Core

LLM-Generated Features for Trading Signals

Large language models can turn unstructured text — filings, transcripts, news — into structured numbers a traditional model can use, but those numbers inherit the LLM's own blind spots and need the same validation as any other feature.

Prerequisites: Designing a Cross-Sectional Feature Set, Putting an NLP Signal Into Production

A traditional quant feature is a number computed by a formula: 20-day momentum, book-to-price, short interest ratio. An earnings call transcript has no such number sitting inside it — extracting one used to require a team of analysts reading transcripts by hand, or a narrow NLP model trained for one specific task like sentiment scoring.

A large language model can instead read the raw transcript and directly output a structured feature: "management tone on guidance, scored 1 to 5," or "count of hedging phrases like 'headwinds' and 'uncertain,'" turning free text into a column a standard cross-sectional model can sit next to book-to-price and momentum.

An LLM-generated feature converts unstructured text into a number a normal model can consume, but the LLM's judgment becomes part of the feature — its errors, biases, and inconsistencies are now baked into the data the same way a mis-specified formula would be.

How it differs from a hand-coded feature

A hand-coded feature like "count of the word 'headwind' in the transcript" is deterministic and fully auditable — the same transcript always produces the same count. An LLM asked "on a scale of 1-5, how confident does management sound about guidance" is making a judgment call, and that judgment can shift between model versions, prompt wording, or even random sampling if temperature isn't set to zero. The feature is richer — it can capture tone and nuance a keyword count misses — but it is also noisier and less reproducible.

richness of signal reproducibility keyword count LLM tone score
LLM-generated features trade deterministic reproducibility for richer, more nuanced signal — both matter, and neither is free.

Worked example

A researcher feeds 400 earnings call transcripts to an LLM with the prompt "rate management's confidence about next-quarter guidance from 1 (very hedged) to 5 (very confident)." Backtesting the score against next-quarter earnings surprises shows stocks scored 4-5 beat estimates 58% of the time versus 44% for stocks scored 1-2 — a real, usable signal. But running the same 400 transcripts through the same prompt a second time, a month later after the vendor silently updated the underlying model, produces scores that agree with the first run only 81% of the time on which stocks land in the top tercile. That instability — not the original signal — is what needs to be flagged and monitored before the feature goes live.

What this means in practice

Treat an LLM-generated feature exactly like any other feature: check its distribution over time, check how stable it is under small prompt changes, and check whether it is actually adding information beyond features you already have (a "confident tone" score can just be re-deriving stock momentum you already capture elsewhere). Pin the model version and prompt used to generate historical training data, because an unannounced model upgrade from the vendor can shift the whole feature's distribution overnight, which looks identical to a real regime change if nobody is watching for it.

The biggest risk is silent respecification: a vendor or in-house team upgrades the underlying LLM, the feature's scale or meaning shifts slightly, and a model trained on the old distribution keeps running as if nothing changed. Because the feature still looks like a normal number in the pipeline, this failure mode is much harder to notice than a broken data feed.

Related concepts

Practice in interviews

Further reading

  • Lopez de Prado, Advances in Financial Machine Learning (ch. 2)
ShareTwitterLinkedIn