algo-rec-content
比對項目特徵和使用者偏好檔案的內容式推薦
中文翻譯
---
name: "algo-rec-content"
description: "實作內容式推薦，把項目特徵和使用者偏好檔案做比對。當使用者需要依屬性推薦項目、解決新項目的冷啟動問題、或在沒有協同資料的情況下建立推薦時使用，即使他們說的是「推薦類似的產品」、「像這樣的項目」或「依特徵配對」也一樣。"
metadata:
category: "WP-36 推薦系統"
tags: ["recommendation", "content-based", "feature-matching"]
---
# 內容式推薦（Content-Based Recommendation）
## 概述
內容式過濾會推薦特徵符合使用者偏好檔案的項目，偏好檔案是從使用者的互動歷史建出來的。每位使用者的計算是 O(I × F)，其中 I=項目數、F=特徵數。它能解決新項目的冷啟動，因為項目只需要特徵，不需要互動歷史。
## 何時使用
**觸發條件：**
- 要依項目屬性（類型、類別、關鍵字、價格帶）做推薦
- 新項目冷啟動：項目有特徵，但還沒有互動資料
- 使用者隱私要求不能跨使用者共用資料時
**何時不要用：**
- 在意意外驚喜時（內容式會造成同溫層）
- 項目特徵拿不到，或沒有資訊量時（改用 CF）
## 演算法
```
鐵律：內容式只能推薦「相似」的項目
它發現不了意料之外的興趣（同溫層問題）。
只看動作片的使用者，就只會拿到動作片的推薦，
就算他其實會很愛紀錄片。
```
### 階段 1：輸入驗證
擷取項目的特徵向量（文字用 TF-IDF、類別用 one-hot、屬性用數值）。用互動過的項目的加權特徵建出使用者檔案。
**關卡：** 項目特徵已擷取、使用者檔案向量已建好。
### 階段 2：核心演算法
1. 把每個項目表示成特徵向量
2. 建立使用者檔案：互動過的項目向量的加權質心（依新近度、評分或參與度加權）
3. 計算使用者檔案和所有候選項目之間的相似度（餘弦相似度）
4. 依相似度分數排名，排除已經互動過的項目
### 階段 3：驗證
評估：推薦清單有沒有反映使用者已展現出來的偏好？檢查多樣性指標。
**關卡：** 推薦內容在主題上和使用者歷史一致。
### 階段 4：輸出
回傳排好名的推薦，並附上特徵層級的解釋。
## 輸出格式
```json
{
"recommendations": [{"item_id": "456", "score": 0.87, "matching_features": ["genre:thriller", "director:Nolan"]}],
"metadata": {"method": "content-based", "features_used": 15, "profile_items": 30}
}
```
## 範例
### 輸入輸出範例
**輸入：** 使用者看過 5 部科幻片、2 部紀錄片。候選項目：一部新的科幻片。
**預期：** 高分（約 0.8 以上），因為類型符合主要偏好。
### 邊界情況
| 輸入 | 預期 | 原因 |
|-------|----------|-----|
| 新使用者，沒有歷史 | 無法建立檔案 | 新使用者冷啟動，改用熱門度 |
| 所有項目特徵相同 | 分數一樣 | 無法區分 |
| 歷史很多元的使用者 | 所有項目都是中等分數 | 檔案的平均會稀釋訊號 |
## 常見陷阱
- **特徵品質就是一切**：垃圾特徵 → 垃圾推薦。要投資在特徵工程上。
- **同溫層**：使用者拿到的推薦會越來越窄。要混入探索型的項目來注入多樣性。
- **檔案漂移**：使用者偏好會隨時間改變。要對較舊的互動做時間衰減。
- **特徵稀疏**：特徵很少的項目，算出來的相似度不可靠。要設最低特徵數的門檻。
- **過度專門化**：只對一張爵士專輯打高分的使用者，不該拿到「全部」都是爵士。要依互動次數加權，不能只看評分。
## 參考資料
- 結合內容式與 CF 的混合做法，見 `references/hybrid-strategies.md`
- 以文字為基礎的特徵擷取技巧，見 `references/feature-extraction.md`英文原文
---
name: "algo-rec-content"
description: "Implement content-based recommendation by matching item features to user preference profiles. Use this skill when the user needs to recommend items based on attributes, solve the cold start problem for new items, or build recommendations without collaborative data — even if they say 'recommend similar products', 'items like this', or 'feature-based matching'."
metadata:
category: "WP-36 推薦系統"
tags: ["recommendation", "content-based", "feature-matching"]
---
# Content-Based Recommendation
## Overview
Content-based filtering recommends items whose features match the user's preference profile, built from their interaction history. Computes in O(I × F) per user where I=items, F=features. Solves new-item cold start since items only need features, not interaction history.
## When to Use
**Trigger conditions:**
- Recommending based on item attributes (genre, category, keywords, price range)
- New item cold start: items have features but no interaction data yet
- When user privacy requires no cross-user data sharing
**When NOT to use:**
- When serendipity matters (content-based creates filter bubbles)
- When item features are unavailable or uninformative (use CF instead)
## Algorithm
```
IRON LAW: Content-Based Can Only Recommend SIMILAR Items
It cannot discover unexpected interests (filter bubble problem).
Users who only interact with action movies will only get action
movie recommendations — even if they'd love a documentary.
```
### Phase 1: Input Validation
Extract item feature vectors (TF-IDF for text, one-hot for categories, numerical for attributes). Build user profile from weighted item features of interacted items.
**Gate:** Item features extracted, user profile vector built.
### Phase 2: Core Algorithm
1. Represent each item as a feature vector
2. Build user profile: weighted centroid of interacted item vectors (weight by recency, rating, or engagement)
3. Compute similarity between user profile and all candidate items (cosine similarity)
4. Rank by similarity score, exclude already-interacted items
### Phase 3: Verification
Evaluate: does the recommendation list reflect the user's demonstrated preferences? Check diversity metrics.
**Gate:** Recommendations are topically aligned with user history.
### Phase 4: Output
Return ranked recommendations with feature-level explanations.
## Output Format
```json
{
"recommendations": [{"item_id": "456", "score": 0.87, "matching_features": ["genre:thriller", "director:Nolan"]}],
"metadata": {"method": "content-based", "features_used": 15, "profile_items": 30}
}
```
## Examples
### Sample I/O
**Input:** User watched 5 sci-fi movies, 2 documentaries. Candidate: new sci-fi movie.
**Expected:** High score (~0.8+) due to genre match with dominant preference.
### Edge Cases
| Input | Expected | Why |
|-------|----------|-----|
| New user, no history | Cannot build profile | New-user cold start — use popularity |
| All items same features | Equal scores | No differentiation possible |
| User with diverse history | Moderate scores for all | Profile averages dilute signal |
## Gotchas
- **Feature quality is everything**: Garbage features → garbage recommendations. Invest in feature engineering.
- **Filter bubble**: Users get increasingly narrow recommendations. Inject diversity by mixing in exploration items.
- **Profile drift**: User preferences change over time. Apply temporal decay to older interactions.
- **Feature sparsity**: Items with few features produce unreliable similarity. Set a minimum feature count threshold.
- **Over-specialization**: A user who rated one jazz album highly shouldn't get ALL jazz. Weight by interaction count, not just rating.
## References
- For hybrid approaches combining content and CF, see `references/hybrid-strategies.md`
- For text-based feature extraction techniques, see `references/feature-extraction.md`