How AI Shifts Recommendation Systems from Simply Pushing Items to Guiding User Choices

Why focus on game understanding and expression

Recommendation systems are good at answering "what to push", but users get stuck at "how to choose". The authors propose adding an "expression and decision" layer after ranking so that the system not only tells users which games are likely to be clicked, but also explains why a particular game fits the user’s needs.

Why a new label system is needed

Existing game tags (mechanics, genre, combat style, rhythm) describe "what a game is" but cannot answer "why a player would play it" or "why they would pay"—the information needed for decision making. For example, a fishing game’s old tags are simply "Fishing · PVE · Simulation · Light" which tells little about recommendation relevance.

To add value, the authors introduce two new layers:

Game motivation : why players play and pay (e.g., "爽感刺激", "解压逃避", "随机刺激").

Payment mechanism : how the game structures monetisation (e.g., "概率付费", "抽卡/转盘", "中等复杂度").

These dimensions turn a generic description like "a fishing game" into a richer statement such as "a fast‑paced, stress‑relieving game that drives payment through probabilistic loot boxes"—information that directly supports recommendation decisions.

Defining useful dimensions

After deciding to add motivation and payment layers, the team asked which dimensions are worth encoding. They let large models explore freely, generating many candidate attributes (player motivations, reward loops, growth systems). Human reviewers then filtered the output, keeping only dimensions that are simultaneously explainable, comparable, reusable, and have decision value. Examples kept include "growth drive", "treasure‑hunt excitement", and "social identity"; less useful ones like "art style" were discarded.

Workflow: Exploration → Convergence → Production

模型放开探索 → 撞出边界 → 验证哪些维度真有用 → 收敛成 schema → 规模化生产

The process is split clearly: models generate diverse insights, humans validate and codify them into a closed‑set schema, and the normalized schema becomes the stable API for downstream services.

AI’s boundaries

The model’s role is limited to understanding, summarising, and expressing; it never invents facts or replaces the ranking engine. The ranking component still decides "what to push"; the AI layer only explains "why it fits". This separation ensures traceability—if an explanation drifts, the structured schema reveals which layer introduced the error.

Reusable engineering experience

Use two faces of the model: free‑form exploration first, then constrained production.

Treat the raw LLM output as non‑API; wrap it with a schema and a normalisation layer to guarantee type safety and completeness.

The prompt’s structure defines the depth of understanding—more granular partitions yield deeper explanations.

Decouple "what to compare", "how to phrase", and "which dimension gets highlighted" into separate schema fields.

Make the LLM capability stateless and context‑agnostic so it can be reused across scenarios (recommendation explanation, similarity search, new‑game discovery).

Product perspective shift

AI does not simplify product design; it makes the system architecture itself a product feature. The new pipeline compresses multiple hand‑offs (understanding → expression → validation → front‑end rendering) into a single, verifiable path that product managers can prototype and iterate on alone.

Previously the workflow was: Business goal → Feature design → Engineering implementation. After AI integration it became: Business problem → Capability exploration → Structured design → Prototype validation → System collaboration.

Conclusion

The exploration shows that recommendation systems can move beyond "what to show" to "how to help users decide" by layering AI‑driven game understanding on top of existing ranking. The pipeline remains read‑only for ranking, adding a stable, explainable layer that can be reused across multiple product scenarios.