algo-rec-hybrid
結合多種推薦策略的混合式推薦系統設計
中文翻譯
---
name: "algo-rec-hybrid"
description: "設計結合多種策略的混合式推薦系統，提升準確度。當使用者需要克服單一方法的限制、結合協同過濾與內容式過濾、或建立正式環境的推薦 pipeline 時使用，即使他們說的是「結合多種推薦做法」、「最佳推薦架構」或「冷啟動加上個人化」也一樣。"
metadata:
category: "WP-36 推薦系統"
tags: ["recommendation", "hybrid", "ensemble", "system-design"]
---
# 混合式推薦系統（Hybrid Recommendation System）
## 概述
混合式推薦結合多種策略（CF、內容式、知識式），克服個別方法的限制。常見架構：加權式、切換式、串接式、特徵擴充式和 meta-level。複雜度依架構而異。
## 何時使用
**觸發條件：**
- 要建立正式環境的推薦系統，必須同時處理冷啟動「和」個人化
- 單一方法在你的使用情境有已知的弱點
- 需要在準確度、多樣性和覆蓋率之間取得平衡
**何時不要用：**
- 只有一個乾淨的資料來源時（先從對應的單一方法開始）
- 系統簡單比邊際的準確度提升更重要時
## 演算法
```
鐵律：混合式只有在「優勢互補」時才有價值
把兩個有「相同」弱點的系統結合起來，只會放大那個弱點。
CF 在冷啟動失敗 + 內容式在冷啟動失敗 = 混合式
「仍然」在冷啟動失敗。要選能互補彼此缺口的元件。
```
### 階段 1：輸入驗證
找出可用的資料：互動歷史（給 CF）、項目特徵（給內容式）、情境訊號（時間、裝置、位置）。把資料對應到各方法的能力。
**關卡：** 至少有兩個互補的資料來源。
### 階段 2：核心演算法
**加權式混合：** Score = α × CF_score + β × CB_score。用交叉驗證調整權重。
**切換式混合：** 資料充足時用 CF；遇到冷啟動的項目／使用者就切換成內容式。
**串接式混合：** 第一階段先過濾（例如內容式），第二階段在過濾後的集合內排名（例如 CF）。
**特徵擴充：** 把一個方法的輸出當成另一個方法的輸入特徵（例如把 CF 的 embedding 當成內容特徵）。
### 階段 3：驗證
把混合式和個別元件做 A/B 測試。衡量：準確度（NDCG、precision@K）、覆蓋率（被推薦到的目錄比例 %）、多樣性（清單內多樣性）。
**關卡：** 混合式在主要指標上勝過最好的單一元件。
### 階段 4：輸出
回傳推薦，並附上來源歸屬以便解釋。
## 輸出格式
```json
{
"recommendations": [{"item_id": "789", "score": 0.91, "sources": {"cf": 0.85, "content": 0.95}, "method": "weighted"}],
"metadata": {"architecture": "weighted", "weights": {"cf": 0.6, "content": 0.4}, "coverage": 0.78}
}
```
## 範例
### 輸入輸出範例
**輸入：** 新使用者只有 2 次互動 + 豐富的項目特徵目錄
**預期：** 切換式混合：先用內容式推薦（CF 資料不足），隨著互動累積再轉移到 CF
### 邊界情況
| 輸入 | 預期 | 原因 |
|-------|----------|-----|
| 全新的使用者 + 全新的項目 | 退回熱門度 | 兩種方法都沒有資料 |
| 兩種方法差異很大 | 取決於架構 | 加權式取加權平均；串接式交給第二階段決定 |
| 其中一個元件回傳空的 | 由另一個元件接手 | 優雅降級 |
## 常見陷阱
- **複雜度成本**：每多一個元件，延遲、維護和除錯的難度都會增加。從簡單開始，有指標佐證才增加複雜度。
- **權重調整**：靜態權重會隨時間退化。要定期重新調整，或用學習出來的權重（例如用 meta 模型預測每種情境下哪個元件表現最好）。
- **評估更困難**：你必須同時評估混合式「和」每個個別元件，才能了解各自的貢獻並偵測退步。
- **特徵洩漏**：在特徵擴充中，要確保擴充用的模型的預測，在訓練時沒有洩漏測試集的資訊。
- **邊際效益遞減**：從一個方法加到兩個，提升最大。加第三個很少值得多出來的複雜度。
## 參考資料
- 架構選擇的決策指南，見 `references/architecture-selection.md`
- 推薦系統的 A/B 測試，見 `references/ab-testing-recs.md`英文原文
---
name: "algo-rec-hybrid"
description: "Design hybrid recommendation systems combining multiple strategies for improved accuracy. Use this skill when the user needs to overcome single-method limitations, combine collaborative and content-based filtering, or build a production recommendation pipeline — even if they say 'combine recommendation approaches', 'best recommendation architecture', or 'cold start plus personalization'."
metadata:
category: "WP-36 推薦系統"
tags: ["recommendation", "hybrid", "ensemble", "system-design"]
---
# Hybrid Recommendation System
## Overview
Hybrid recommendation combines multiple strategies (CF, content-based, knowledge-based) to overcome individual method limitations. Common architectures: weighted, switching, cascade, feature augmentation, and meta-level. Complexity varies by architecture.
## When to Use
**Trigger conditions:**
- Building a production recommendation system that must handle cold start AND personalization
- Single methods have known weaknesses for your use case
- Need to balance accuracy, diversity, and coverage
**When NOT to use:**
- When you have a single clean data source (start with the matching single method first)
- When system simplicity is more important than marginal accuracy gains
## Algorithm
```
IRON LAW: Hybrid Adds Value ONLY With Complementary Strengths
Combining two systems with the SAME weakness amplifies the weakness.
CF fails on cold start + content-based fails on cold start = hybrid
STILL fails on cold start. Choose components that cover each other's gaps.
```
### Phase 1: Input Validation
Identify available data: interaction history (for CF), item features (for content-based), contextual signals (time, device, location). Map data to method capabilities.
**Gate:** At least two complementary data sources available.
### Phase 2: Core Algorithm
**Weighted hybrid:** Score = α × CF_score + β × CB_score. Tune weights via cross-validation.
**Switching hybrid:** Use CF when sufficient data exists; switch to content-based for cold start items/users.
**Cascade hybrid:** First stage filters (e.g., content-based), second stage ranks (e.g., CF) within filtered set.
**Feature augmentation:** Use one method's output as input features for another (e.g., CF embeddings as content features).
### Phase 3: Verification
A/B test hybrid vs individual components. Measure: accuracy (NDCG, precision@K), coverage (% of catalog recommended), diversity (intra-list diversity).
**Gate:** Hybrid outperforms best individual component on primary metric.
### Phase 4: Output
Return recommendations with source attribution for explainability.
## Output Format
```json
{
"recommendations": [{"item_id": "789", "score": 0.91, "sources": {"cf": 0.85, "content": 0.95}, "method": "weighted"}],
"metadata": {"architecture": "weighted", "weights": {"cf": 0.6, "content": 0.4}, "coverage": 0.78}
}
```
## Examples
### Sample I/O
**Input:** New user with 2 interactions + rich item feature catalog
**Expected:** Switching hybrid: content-based recommendations (insufficient CF data), transitioning to CF as interactions accumulate
### Edge Cases
| Input | Expected | Why |
|-------|----------|-----|
| Completely new user + new item | Fall back to popularity | No data for either method |
| Methods disagree strongly | Depends on architecture | Weighted averages; cascade defers to second stage |
| One component returns empty | Other component takes over | Graceful degradation |
## Gotchas
- **Complexity cost**: Each added component increases latency, maintenance, and debugging difficulty. Start simple, add complexity only when justified by metrics.
- **Weight tuning**: Static weights degrade over time. Retune periodically or use learned weights (e.g., a meta-model that predicts which component performs best per context).
- **Evaluation is harder**: You must evaluate the hybrid AND each component individually to understand contribution and detect regressions.
- **Feature leakage**: In feature augmentation, ensure the augmenting model's predictions don't leak test-set information during training.
- **Diminishing returns**: Going from one method to two gives the biggest lift. Adding a third rarely justifies the complexity.
## References
- For architecture selection decision guide, see `references/architecture-selection.md`
- For A/B testing recommendation systems, see `references/ab-testing-recs.md`