A used-record shop wants albums that mean something like a liner-note blurb, not albums that merely share three keywords. The shop is not asking for the model's working-memory size and is not asking for raw word pieces. Which representation should they use?

When a used-record shop wants albums that mean something like a liner-note blurb rather than albums that merely share three keywords, the right representation is embeddings: numeric vectors that encode semantic meaning. Nearby embeddings can relate paraphrase-style descriptions even when lexical overlap is low, which is exactly the meaning-over-keywords goal. The shop is not asking for working-memory size and not asking for raw word pieces as the similarity signal.

Relying on raw tokens only because shared keywords equal meaning collapses semantics into exact-word overlap. Token identity helps exact match search; it fails when two blurbs describe the same vibe with different vocabulary, which is the failure mode the shop wants to avoid.

Storing the context-window size as the album's meaning confuses a model capacity limit with a content representation. Window size is how much text fits in one call; it is not a per-album meaning vector you can search against.

A regression forecast of next week's vinyl price is a classical numeric prediction task. It does not represent liner-note meaning or retrieve semantically similar albums.

Exam caveat: embeddings enable semantic similarity but do not guarantee business relevance—poor embedding models or mismatched domains can still rank wrong pressings near a jazz blurb.

Operational check: embed a held-out set of liner notes and known similar pressings, measure whether true semantic neighbors rank above keyword-only decoys, and only then wire the shop's search to vector nearest-neighbor lookup.