推薦系統管線架構設計師 是做什麼的？
一個專為建構可組合推薦、排序和饋送管線的規範與框架生成技能。它實現了 六階段模式 — Source → Hydrator → Filter → Scorer → Selector → SideEffect — 此模式由 xAI 開源的 For You 演算法 (Apache 2.0) 推廣。本技能是此模式的獨立重新實作 (MIT)，未複製原始程式碼。
上游來源：https://github.com/mturac/recsys-pipeline-architect
何時使用
- 使用者想要建構任何能為「使用者/情境選出前 K 個項目」的系統
- 使用者詢問「我該如何對 X 進行排序」或描述一個饋送/個人化問題
- 使用者已有評分函數，需要圍繞它建立管線基礎設施
- 使用者想從單一相關性評分遷移至可調權重的多動作預測
- 使用者正在封裝一個 LLM/ML 評分器，並需要在其技術棧 (TypeScript / Go / Python) 中加入過濾器、資料充實、副作用以及可執行的框架
- 觸發關鍵字：「推薦系統」、「饋送演算法」、「排序管線」、「為你推薦」、「候選管線」、「內容推薦器」、「推薦系統的管線架構」、「RAG 檢索重排序器」
何時不該使用
- 模型架構工作 (Transformer 設計、雙塔檢索、Embedding 訓練) — 此技能是模型周圍的基礎設施，而非模型本身
- 純 ML 訓練管線 — 評分函數由使用者負責
- 營運已部署的管線 (監控、自動擴展) — 不在此技能範圍內
六階段框架
| # | 階段 | 任務 | 可並行？ |
|---|---|---|---|
| 1 | Source (來源) | 從一個或多個來源獲取候選項 | 是 — 多個來源可並行執行 |
| 2 | Hydrator (資料充實) | 為每個候選項充實過濾和評分所需的中繼資料 | 是 — 獨立的資料充實器可並行執行 |
| 3 | Filter (過濾) | 丟棄絕不應顯示的候選項 (被封鎖、已過期、重複、不符合資格) | 順序 — 每個過濾器看到的項目越來越少 |
| 4 | Scorer (評分) | 為每個存活的候選項分配一個或多個分數 | 順序 — 後續評分器會看到先前的分數 |
| 5 | Selector (選取) | 按最終分數排序，回傳前 K 個 | 單一操作 |
| 6 | SideEffect (副作用) | 快取已服務的 ID、記錄曝光、發送事件、更新計數器 | 非同步 — 絕不能阻塞回應 |
為何是這個順序
- 先有來源再有資料充實：先知道有哪些候選項，再考慮為充實它們付費
- 先有資料充實再有過濾：許多過濾器需要來源未提供的中繼資料
- 先有過濾再有評分：評分是昂貴的階段；先丟棄不合格的
- 評分器鏈 (非單一評分器)：實際系統會組合 ML 評分、多樣性重排序和業務規則
- 評分後才選取：保持評分的確定性與可快取性
- 副作用最後且非同步：副作用絕不能阻塞使用者的回應
被呼叫時的工作流程
引導使用者完成以下八個步驟：
- 釐清使用案例 (一輪，三個問題)：要排序的項目？輸入情境？語言/執行環境？
- 識別候選來源：通常是網路內 (追蹤/擁有/訂閱) + 網路外 (ML 檢索 / 熱門 / 相似於喜愛)
- 列出所需的資料充實：對於每個過濾器和評分器，它需要哪些來源未提供的資料？
- 列出過濾器：重複、自己、年齡、封鎖/靜音、先前服務過、資格。順序很重要 — 廉價的在前，昂貴的在後。
- 設計評分器鏈：主要 (ML) → 組合器 (多動作加權) → 多樣性 → 業務規則
- 選取器：按最終分數降序排序，取前 K 個 (或針對網路內/網路外進行分層混合)
- 副作用：快取已服務的 ID、發出曝光事件、更新計數器、記錄分析資料 — 全部 fire-and-forget
- 在使用者的技術棧中生成框架
須揭露的關鍵權衡 (不要默默地採用預設值)
1. 單一評分 vs 多動作預測
- 單一評分：訓練一個模型來預測相關性。要改變行為 → 重新訓練。
- 多動作預測：預測多個動作的
P(動作)(閱讀、按讚、分享、跳過、檢舉)，在服務時使用權重組合它們。要改變行為 → 改變權重。無需重新訓練。
X 的 For You 系統使用同時具有正負權重的多動作預測。當使用者預期會頻繁調整時，建議使用多動作預測。
2. 評分中的候選項隔離
- 獨立評分：每個候選項獨立評分。確定性，可快取。
- 聯合評分：候選項在評分時互相關注 (例如，對批次進行 Transformer 處理)。更具表達力，但在不同批次間非確定性。
預設使用獨立評分。只有在有特定原因時才使用聯合評分 (例如，明確的批次感知多樣性)。
3. 線上 vs 離線
- 請求時 (線上)：管線在每次請求時執行。延遲預算：100–300 毫秒。預設值。
- 預先計算 (離線批次)：管線定期執行，結果被快取。延遲更低，新鮮度更低。
- 混合式：離線檢索候選項，線上進行排序。
硬性規則
- 不要虛構基準測試數字。「快多少？」→「取決於工作負載，請自行執行測試。」
- 歸屬紀律。在提及此模式時，應歸因於「由 xAI 開源的 For You 演算法推廣」/
github.com/xai-org/x-algorithm(Apache 2.0)。 - 勿使用商標。不要將使用者的成品命名為「X-like」或使用「For You」品牌。模式是自由的；品牌則不是。建議命名：「候選管線」、「饋送管線」、「排序管線」、「推薦系統管線」。
- 揭露權衡。多動作 vs 單一、獨立 vs 聯合、線上 vs 離線 — 絕不能默默地採用預設值。
- 生成的框架必須可執行。不能以偽代碼濫竽充數。
- 過濾器順序很重要。廉價的在前，昂貴的後。通用的在個人化之前。
- 副作用絕不阻塞。使用 fire-and-forget 模式 (goroutines / 無 await 的 Promise / asyncio tasks) 來包裝。
反模式
- 在評分前才進行過濾 (浪費運算資源在最終會被丟棄的候選項上)
- 同步的副作用 (快取寫入 / 曝光發送阻塞了回應)
- 當產品需要為多個目標進行調整時，使用單一的「相關性」評分 (參與度 vs 安全性 vs 多樣性 vs 廣告)
- 將聯合評分設為預設值 (非確定性、難以快取、不與重排序階段組合)
- 生成「僅供說明」的偽代碼 — 框架必須真的能執行
上游內容
上游儲存庫位於 https://github.com/mturac/recsys-pipeline-architect，提供了：
- 完整的
SKILL.md，包含 8 步驟的完整工作流程 - 5 個按需載入的參考文件：4 種語言的介面 (TS/Go/Python/Rust)、多動作評分模式、候選項隔離、過濾器食譜 (12 種模式)、評分器食譜 (加權總和、MMR、多樣性懲罰、位置去偏)
- 3 個可執行的範例框架，每個在測試套件中都是全綠燈：
- Strapi v5 外掛 (TypeScript / Jest — 3/3 通過)
- Zentra 相容管線 (Go 搭配泛型 — 3/3 通過)
- PMAI 任務優先順序排序器 (Python / FastAPI / pytest — 3/3 通過)
- v0.1.0 版本已標記
- MIT 授權；模式歸屬於 xAI X For You 演算法 (Apache 2.0)
透過 skills.sh 安裝：npx skills add mturac/recsys-pipeline-architect