How LLMs Extract Implicit User Preferences: From Click Logs to Structured Profiles

TL;DR.

• Implicit preference extraction is the problem of inferring what a user wants from behavioral signals — clicks, dwell, skips, scroll depth — without asking them.
• Traditional collaborative filtering and embedding-based models compress behavior into a latent vector that is fast but semantically opaque — they capture that a user engaged, not why.
• LLMs close the semantic gap by reasoning over behavior sequences in context, producing structured preference profiles that link actions to content attributes.
• In 2026, the architecture has shifted: LLMs run offline as batch extractors against interaction logs, outputting typed preference schemas that power real-time serving layers — not in the hot path.
• If you only remember one thing: a click log is evidence, not preference — LLMs are the inference step that turns evidence into structured belief.

Every recommender system has the same foundational problem: users reveal preferences indirectly. A user who watches 40% of a documentary, skips the next three suggestions, then seeks out a specific director's catalog has expressed something — but a matrix factorization model encodes that entire narrative as a sparse row of interaction weights. What was expressed is gone. What remains is a signal residue that collaborative filtering can exploit statistically but cannot interpret.

LLMs change this. Not because they are better recommenders — they often are not, at inference time — but because they are competent readers of behavioral sequences. Given a structured log of what a user did, an LLM can reason about what that behavior implies about preferences along semantic axes: genre, tone, complexity, recency bias, format preference, domain depth. That capability, applied correctly, produces a structured preference profile that a downstream serving layer can actually use.

This post is about the extraction step: the architecture, the signal taxonomy, where LLMs add genuine leverage, and what to avoid.

What Is Implicit Preference Extraction?

Implicit preference extraction is the task of inferring a user's structured preferences from behavioral evidence rather than self-reported data. It sits upstream of recommendation — the output of extraction feeds a user model, which feeds a retrieval or ranking layer.

The classic formulation treats it as a learning problem: train a model on (user, item, interaction-weight) triples to produce a user embedding and item embedding whose dot product predicts affinity. Matrix factorization (Wikipedia), ALS, BPR, and their neural descendants (NCF, LightGCN) all work this way. The preference is implicit in the embedding geometry — not explicitly represented anywhere.

The LLM formulation treats it as a reading-comprehension problem: given a behavior sequence with content metadata attached, what can we infer about this user's preferences along named axes? The output is not a dense vector but a typed structure — something like {genres: ["documentary", "political-history"], depth: "long-form", session_pattern: "evening-binge", recency_bias: 0.3}.

These are different epistemic positions. The embedding approach produces latent representations that are predictively powerful but inspectable only through probing. The LLM approach produces representations that are readable, auditable, and composable with structured knowledge. Both have a place. The question is where each belongs in your stack.

Why Click Matrices Lose the Signal

The problem with treating behavior as a matrix of interaction weights is that the representation destroys context. A "1" for a 45-second video view and a "1" for a 45-minute podcast completion carry the same weight until you engineer dwell-time features by hand. Relative engagement — the user who watched 80% of one item and 20% of the next — requires explicit normalization. The sequence in which items were consumed is collapsed into co-occurrence statistics that approximate but don't capture narrative.

Embedding-based models recover some of this through attention mechanisms (SASRec, BERT4Rec, and their successors encode item order) but they still operate over item IDs, not item semantics. A user who switches from thriller films to thriller novels to thriller podcasts is expressing a consistent preference for narrative tension — but if those three item types live in separate ID spaces, the model sees three unrelated sessions, not one coherent signal.

The deeper issue is the semantic gap: between what a user actually engaged with (content with attributes) and the representation the model holds (a compressed vector or ID sequence). Bridging that gap has historically required manual feature engineering — tagging items with attributes, building content embeddings, cross-joining item metadata into the interaction pipeline. This works but is brittle: it requires the content taxonomy to exist before training, every new content type must be re-enumerated, and the bridge between signals and semantics is hard-coded at featurization time.

LLMs close this gap at inference time, without a fixed taxonomy, by reading the content descriptions attached to interaction logs and reasoning about what they have in common.

How LLMs Reason Over Behavior Sequences

Given a prompt like: "Here are 12 items this user interacted with over the last 7 days, with interaction weights and content descriptions. What do these interactions suggest about this user's preferences?" — a capable LLM produces a structured hypothesis about preferences that a human reader would recognize as plausible.

This is not magic. It is in-context reasoning over co-occurrence patterns that the LLM can interpret because it was trained on text that names and describes content. It knows that "The Wire" and "Narcos" share attributes like "crime procedural" and "systemic critique" in a way that a pure CF model trained only on interaction matrices does not.

The 2023 paper TALLRec (arXiv:2305.00447) demonstrated that instruction-tuned LLMs, given only a user's interaction history as text, could match or exceed state-of-the-art CF baselines on cold-start and sparse-data segments — not because they memorized item statistics, but because they could generalize from content semantics. The leverage is largest where CF is weakest: new users, new items, cross-domain transfer.

The practical architecture in 2026 is not "run an LLM at query time to pick items." That is too slow and too expensive. It is: run an LLM offline, periodically, against interaction logs, to produce a structured preference profile stored in a user graph node. Then serve from the graph.

The extraction prompt structure

A well-structured extraction prompt has three components:

Behavior log with metadata. Not raw event IDs — resolved item titles, descriptions, and attributes attached to each interaction event. Dwell time and completion rate as numeric fields. Timestamps bucketed by recency tier (last 24h, last 7d, last 30d).

Extraction schema. A JSON schema or function-calling spec that defines the preference dimensions you care about. Do not ask the LLM to invent dimensions; constrain the output to typed fields your downstream system can consume. Examples: content_depth (shallow/standard/deep), format_affinity (video/audio/text), topic_clusters (array of labeled themes), recency_sensitivity (0–1 float).

Uncertainty instructions. Tell the model to express low confidence as absence or a confidence flag, not confabulation. "If there is insufficient signal to infer a preference on a dimension, omit that field or set it to null."

The PALR paper (arXiv:2305.07622) used a similar approach — user-history-as-natural-language prompt — and showed that retrieval-augmented LLM ranking outperformed CF baselines when the LLM had access to item descriptions, not just IDs. The signal is in the content semantics, not the interaction matrix alone.

Architectures for LLM-Based Preference Extraction

There are three viable patterns in 2026, each with a different latency and cost profile.

1. Offline batch extraction

Run an LLM (GPT-4o, Claude Sonnet, or a domain-fine-tuned 7–13B open-weight model) as a batch job against accumulated interaction logs. Input: last N interactions with resolved metadata. Output: a typed preference profile written to a user-graph node or user-profile store. Cadence: hourly or daily, triggered by interaction volume thresholds.

This is the correct default for most applications. Latency is irrelevant — you're writing to a store that gets read at query time. Cost is manageable because you run extraction only when a user's behavior has materially changed. The preference profile is fresh enough for recommendation purposes because behavioral preferences are not millisecond-volatile.

2. Session-level extraction

At the end of a session — or at natural pause points within one — extract a session-level preference delta and merge it into the persistent profile. Useful for apps with long, content-dense sessions (video streaming, e-learning) where a single session meaningfully shifts the preference distribution.

The merge step matters: you want recency-weighted update, not replacement. A user who watched two horror films tonight after a month of sci-fi is probably mood-surfing, not converting. Bayesian update semantics — shift the prior proportionally to session evidence — outperform hard overwrite.

3. LLM-assisted cold-start bootstrapping

For users with no interaction history — day-zero personalization — run extraction against auxiliary signals: onboarding answers, search queries, referred content, device and locale metadata. The LLM's job here is to make weakly structured signals inferentially useful. A user who found the app through a search for "beginner guitar tabs" provides more information than a pure cold-start system can leverage. The LLM can translate that signal into a structured preference hypothesis that seeds the initial user model.

This is the pattern we use in ×marble's synthetic clone architecture: the clone is initialized from LLM-extracted signals before any user-specific interactions exist.

Signal Taxonomy: What Translates and What Doesn't

Not all behavioral signals are equally interpretable by an LLM. Understanding the taxonomy prevents you from feeding noise into the extraction pipeline.

High-signal inputs for LLM extraction:

• Completion rate with content description (80% completion of a 45-min deep-dive → strong depth affinity signal)
• Sequential consumption patterns (binge sequences, genre pivots, director/author follow-through)
• Search queries resolved to content (user searched "Byzantine history" → topic signal with specificity)
• Explicit content relationships (saved to playlist, shared, revisited)
• Skip timing (skipped at intro vs. skipped at 80% tells you different things)

Low-signal / noise inputs:

• Autoplay completions without further engagement (user left the room)
• Thumbnail impressions without click (negative preference signal only if paired with visible impression time)
• Background audio play (engagement without attention)
• Raw dwell time without normalization for content length

Inputs LLMs handle worse than traditional models:

• High-frequency micro-interaction streams (hover events, scroll velocity) — too granular for text-based reasoning, better handled by statistical models
• Pure frequency patterns without semantic content — CF is better at "users who do X 10 times in a row tend to do Y"
• Real-time session state — LLMs are not the right tool for sub-second preference inference

The key heuristic: if you could hand the interaction log to a thoughtful human analyst and they could derive a preference inference from it, the LLM probably can too. If the signal requires statistical aggregation across millions of similar users to be meaningful, use a collaborative model.

Integrating Extracted Preferences into a Knowledge Graph

A preference profile stored as a JSON blob in a relational database is only marginally better than a latent vector — it is explicit but isolated. The upgrade is to store preference claims as nodes and edges in a knowledge graph where they can participate in multi-hop reasoning.

The graph structure that works:

• User node ← PREFERS → Concept node (e.g., "long-form documentary", "political analysis")
• Concept node ← IS_A → Category node (e.g., "non-fiction video")
• Concept node ← RELATED_TO → Concept node (e.g., "political analysis" ↔ "investigative journalism")

When a recommendation query arrives, graph traversal from the user node can reach related concepts that the LLM extraction step may not have named explicitly — bridging through the ontology. This is how you get "user who prefers long-form documentary" to surface investigative journalism podcasts: not because the LLM extracted a podcast preference, but because the graph knows that documentary and investigative journalism share ontological ancestors.

The paper P5 (arXiv:2203.13366) showed that unifying recommendation tasks under a single language model backbone enabled cross-task transfer — but the architecture is expensive. The knowledge-graph alternative achieves similar cross-domain transfer more cheaply by externalizing the relational reasoning into graph structure, letting the LLM do extraction and letting the graph do traversal.

In 2026, the combination of LLM-extracted preference profiles loaded into a graph traversal layer — with p50 < 30 ms serving latency — is the architecture that gives you both semantic richness and production-grade inference speed.

Explainability as a First-Class Output

One undervalued property of LLM-extracted preferences over latent embeddings: they are natively explainable. When the preference representation is "user shows strong affinity for content with themes of systemic critique and long-form narrative" — you can generate a surface explanation: "Because you watched The Wire and Why We Sleep" without post-hoc saliency approximation.

This matters for right-to-explain compliance — GDPR Article 22, and increasingly under CCPA enforcement in California — where users can request an explanation of automated decisions. It matters for product trust: users who understand why a recommendation appeared engage with it differently than users who receive an opaque suggestion. And it matters for debugging: when your recommender goes wrong, a preference profile you can read is a preference profile you can interrogate.

The extraction prompt should be designed with explanation as a byproduct, not an afterthought. Ask the LLM to produce not just the preference claims but the evidence chains: which interactions support which claims, with what confidence. Store both. Surface the summary; keep the evidence for audit.

Recent work on LLM-based recommendation explanation, surveyed in a 2024 ACM Computing Surveys piece (ACM), confirms that natural-language preference explanations improve user trust and click-through in A/B tests — though the magnitude varies significantly by domain and user demographics.

Where to Start

If you are building preference extraction today, this is the sequencing that avoids the common failure modes.

Step 1: Resolve your item IDs to text. You cannot extract semantic preferences from opaque IDs. Build an item metadata store that maps every interacted item to a short description — title, category, topic tags, format, and a 1-2 sentence summary. This is the prerequisite. Everything else depends on it.

Step 2: Define your preference schema first. Do not ask the LLM to invent a preference taxonomy. Define the 5-8 dimensions that matter for your downstream ranking model — the dimensions a retrieval query will actually filter or weight on — and constrain the LLM output to those dimensions via structured output / function calling. Starting with a fixed schema means your preference store has a consistent shape from day one.

Step 3: Run batch extraction on a sample of users. Before you instrument a pipeline, run the extraction prompt against 100 real interaction logs manually. Read the outputs. Are the inferences plausible? Where does the LLM confabulate? What signal inputs produce noise? This calibration step is worth more than any ablation study.

Step 4: Build the merge, not just the extraction. The extraction prompt is 20% of the work. The other 80% is the update logic: how new extractions merge into existing profiles, how you decay stale signal, how you handle conflicting inferences from different sessions. A Bayesian update model with session-specific recency weights is a reasonable starting point.

Step 5: Wire preferences into the knowledge graph before you wire them into ranking. Preference nodes in a graph let you run multi-hop inference — finding items related to expressed preferences via ontological paths — before you add the complexity of LLM-in-the-loop re-ranking. Graph traversal is deterministic, fast, and auditable. Use it as your first serving layer. Add LLM re-ranking on top if you need it.

The extractive capability of LLMs is not the bottleneck. The bottleneck is always the infrastructure around extraction: the item metadata quality, the schema discipline, the update semantics, and the serving integration. Get those right and the preference signals an LLM produces are genuinely differentiated from anything a pure CF system can offer — especially at cold start, across domains, and anywhere explainability is a requirement.