Recommendation System Logic AI Prompts for ML Engineers

Static recommendation models are showing their age. A collaborative filter trained on last month’s behavior cannot capture this week’s context. A content-based model trained on product descriptions cannot understand that a customer just changed jobs or moved cities.

The modern recommendation system needs to be dynamic. It needs to incorporate user intent signals, contextual factors, and real-time behavior. It needs to reason about recommendations the way a good sales associate would: by understanding what the customer needs right now.

This is where LLMs and recommendation systems converge. LLMs can reason about user needs in natural language. They can incorporate context that structured models cannot handle. They can explain recommendations in ways that improve user trust.

But they also have limitations. Latency, cost, consistency. The question is not whether to use LLMs in recommendations, but how to combine them with traditional approaches for systems that are both intelligent and practical.

AI Unpacker provides prompts designed to help ML engineers build hybrid recommendation systems that leverage LLMs where they add value.

TL;DR

• LLMs excel at understanding intent and context in natural language.
• Hybrid systems combine LLM reasoning with traditional retrieval.
• Latency and cost are practical constraints that cannot be ignored.
• Explanations improve user trust and recommendation quality.
• Personalization requires balance between exploration and exploitation.
• Evaluation metrics must match business outcomes.

Introduction

Recommendation systems have been around for decades. Collaborative filtering, content-based filtering, matrix factorization. These techniques work. They are efficient, interpretable, and well-understood.

The problem is not that these techniques fail. It is that they plateau. After you have captured the obvious patterns, incremental improvement becomes harder. The long tail remains uncovered. Contextual nuances go unexplained.

LLMs offer a different approach. They can understand natural language queries, reason about user needs, and generate personalized responses. But they are slow, expensive, and inconsistent in ways that traditional models are not.

The practical solution is hybrid systems. Use traditional models for the heavy lifting: retrieval, scoring, ranking at scale. Use LLMs for the reasoning that requires understanding context and intent.

1. Hybrid Architecture Design

Hybrid recommendation systems need to combine multiple components. Each component has specific strengths. The architecture must balance capability with practicality.

Prompt for Hybrid Recommendation Architecture

Design hybrid recommendation architecture for e-commerce platform.

Current system:
- Collaborative filtering (item-item similarity)
- Content-based filtering (product attributes)
- Trending/popular items module
- All run nightly, updated in batch

User context available:
- Current session behavior (views, carts, purchases)
- Search queries (current and historical)
- User profile (demographics, stated preferences)
- Real-time context (time of day, device, location)

Business requirements:
- Recommendations must respond to current session context
- Latency: <100ms for real-time slots, <500ms for browse pages
- Scale: 50M users, 10M products
- Cost: Inference cost must be predictable and controllable

What we want to add with LLM:
- Natural language preference understanding ("I am looking for a gift for my brother")
- Contextual reasoning ("My old one broke, I need a replacement not an upgrade")
- Explanation generation ("Recommended because...")
- Cold start for new users with sparse history

Architecture options:

Option 1: LLM-first retrieval
- LLM generates candidate IDs from user query
- Traditional model reranks candidates
- Pros: Leverages LLM reasoning fully
- Cons: Expensive, slow, hallucination risk

Option 2: Traditional retrieval + LLM reranking
- Traditional model generates candidate list
- LLM reranks and annotates with explanations
- Pros: Scalable, leverages existing system
- Cons: LLM reasoning limited to candidates

Option 3: LLM as scoring feature
- Traditional retrieval
- LLM generates features for scoring model
- Final ranking by ML model
- Pros: Combines strengths, more control
- Cons: Complex pipeline, harder to debug

Key decisions:
1. Which recommendation surfaces use LLM?
2. How to handle LLM latency requirements?
3. How to control cost?
4. How to detect and handle LLM failures gracefully?

Tasks:
1. Define system architecture for hybrid approach
2. Specify data flow between components
3. Design fallback mechanisms
4. Create monitoring approach for LLM outputs
5. Define cost and latency budgets

Generate hybrid architecture design with component specifications.

2. Candidate Retrieval Strategy

Retrieval is the bottleneck in modern recommendation systems. The quality of your candidates determines the ceiling of your recommendation quality.

Prompt for Candidate Retrieval Design

Design candidate retrieval strategy for hybrid recommendation system.

Use case: Product recommendations on PDP (product detail page)
Context: User viewing a specific product

Available signals:
1. Current product being viewed
2. User's recent browsing history
3. User's purchase history
4. User's cart contents
5. Current session search queries
6. User's stated preferences
7. Seasonal and trending signals

Retrieval requirements:
- Return top 100 candidates
- Latency: <50ms
- Diversity: avoid showing same brand/category repeatedly
- Personalization: must incorporate user-specific signals

Current retrieval approach:
- Item-item similarity (based on co-purchase matrix)
- Limited to products in same category
- No personalization beyond collaborative filtering

What LLM can contribute:
- Semantic understanding of "products similar to X but for Y use case"
- Reasoning about complementary vs substitute products
- Understanding implicit preferences from behavior

Retrieval strategy options:

Two-tower retrieval:
- User embedding tower
- Item embedding tower
- Dot product for retrieval
- Pros: Fast, scalable
- Cons: Requires training, less flexible

Hybrid semantic + collaborative:
- Traditional item-item similarity for base candidates
- LLM filters and expands based on semantic understanding
- Pros: Combines signals, robust
- Cons: Multiple steps, potential bottlenecks

LLM-guided retrieval:
- LLM analyzes user context
- LLM generates query理解和expand
- Vector search for candidates
- Pros: Most flexible, intelligent
- Cons: Slow, expensive

Tasks:
1. Design retrieval strategy for PDP recommendations
2. Specify how multiple signals are combined
3. Define candidate diversity requirements
4. Create approach for LLM integration point
5. Establish fallback strategy for LLM failures

Generate candidate retrieval strategy with implementation approach.

3. Personalization Logic

Personalization is the difference between recommendations that feel generic and recommendations that feel helpful. Getting it right requires understanding what to personalize and when.

Prompt for Personalization Strategy

Design personalization logic for recommendation system.

Goal: Personalized product recommendations that feel helpful, not creepy

Personalization signals to consider:
1. Explicit preferences (stated likes/dislikes, saved filters)
2. Implicit preferences (browsing patterns, dwell time, scroll depth)
3. Contextual factors (time of day, device, location, season)
4. Social proof (what similar users purchased)
5. Intent signals (current search queries, recent views)

What users expect:
- Recommendations that remember their tastes
- Recommendations that are relevant to their current need
- Surprise with genuinely new suggestions, not just obvious items
- Transparency about why something was recommended

What users do not want:
- Feeling watched or surveilled
- Same items repeated endlessly
- Recommendations that are too obvious
- Recommendations that feel manipulative

Personalization strategies:

Rule-based:
- If user viewed X, show related products
- Pros: Transparent, controllable
- Cons: Brittle, does not generalize

ML-based:
- Learn preferences from behavior
- Predict what user will engage with
- Pros: Scalable, handles complexity
- Cons: Opacity, bias amplification

LLM-based:
- User context expressed as natural language
- LLM reasons about what would be helpful
- Pros: Flexible, contextual, explainable
- Cons: Expensive, inconsistent

Hybrid:
- ML generates candidate list
- LLM filters and personalizes
- Pros: Best of both
- Cons: Complex pipeline

What to personalize:
1. Which attributes to personalize on (category, price, brand)?
2. How to balance personalization with discovery?
3. How to handle new users (cold start)?
4. How to handle users who change preferences?

Tasks:
1. Define personalization scope and depth
2. Create approach for cold start users
3. Design diversity/exploration mechanism
4. Develop privacy-respecting personalization
5. Define metrics for personalization quality

Generate personalization strategy with implementation approach.

4. Explanation Generation

Recommendations without explanations feel arbitrary. Explanations build trust. Trust improves engagement. Engagement improves recommendations over time.

Prompt for Explanation Generation

Design explanation generation for recommendation system.

Use case: E-commerce product recommendations
User: Viewing personalized recommendations on homepage

Recommendation examples:
1. "Inspired by your recent browsing"
2. "Most popular in [Category]"
3. "Customers who bought this also bought..."
4. "Because you liked [Product]"
5. "Recommended based on your style preferences"

Explanation requirements:
1. Truthful (must accurately reflect why item was recommended)
2. Relevant (must be meaningful to user)
3. Actionable (must help user decide)
4. Concise (must be readable at a glance)

LLM opportunity:
- Generate natural language explanations
- Adapt tone and detail to user context
- Handle edge cases where templates do not fit
- Update explanations based on recent signals

Explanation types:

Source-based (from retrieval):
- "Based on your recent views of X"
- "Popular in your network"
- Pros: Accurate, traceable
- Cons: Limited to available signals

Attribute-based:
- "Matches your preference for minimalist design"
- "Similar to products you saved"
- Pros: Personalized, interesting
- Cons: May not be verifiable

Collaborative-based:
- "Customers like you also bought"
- Pros: Socially validated
- Cons: Privacy concerns if too specific

Contextual:
- "Perfect for spring"
- "Popular for gift-giving"
- Pros: Timely, relevant
- Cons: Generic without user context

What makes explanations feel manipulative vs helpful:
- Manipulative: Omits important caveats
- Helpful: Sets appropriate expectations
- Manipulative: Creates false urgency
- Helpful: Focuses on fit, not scarcity

Tasks:
1. Define explanation taxonomy
2. Create template library for common cases
3. Design LLM integration for dynamic explanations
4. Develop approach for explaining cold-start recommendations
5. Create A/B test framework for explanation quality

Generate explanation generation system with templates and LLM integration.

FAQ

When should I use LLM vs traditional model for recommendations?

Use LLM when you need to understand intent expressed in natural language, reason about complex context, or generate explanations. Use traditional models when you need speed, scalability, consistency, or cost control. The decision is use-case specific. Homepage recommendations can use hybrid approaches. Real-time recommendations in checkout flow should use traditional models.

How do I handle LLM latency in recommendation systems?

Latency is the hard constraint. Options: pre-compute LLM outputs where possible, use faster LLM variants for simple cases, use LLM as a filter rather than a generator, cascade from fast to slow models (traditional retrieval first, LLM only for borderline cases). If latency is consistently over 100ms for real-time slots, your architecture needs redesign.

How do I prevent LLM hallucinations in recommendations?

Hallucinations are a real risk. Mitigations: constrain LLM to recommend only from a pre-approved candidate set, verify LLM outputs against product database before showing to users, use retrieval-augmented generation to ground responses in actual data. Never let LLM invent products or recommend items that do not exist in your catalog.

How do I evaluate recommendation quality beyond CTR?

CTR is a proxy, not an outcome. Business outcomes that matter: conversion rate, repeat purchase rate, customer satisfaction, discovery rate (are users finding new products they would not have found otherwise?), catalog coverage (are you using your full catalog or just popular items?). Build metrics that match your business model.

Conclusion

The future of recommendation systems is hybrid. Traditional models provide the foundation: scalable retrieval, efficient scoring, consistent performance. LLMs provide the intelligence layer: intent understanding, contextual reasoning, natural explanations.

AI Unpacker gives you prompts to design hybrid systems that leverage both approaches. But the engineering judgment about trade-offs, the architectural decisions about where to use each technology, and the monitoring to catch failures — those come from you.

The goal is not the most sophisticated system. The goal is recommendations that help users find what they need.