---

name: recsys-pipeline-architect description: 使用 xAI 开源 For You 算法推广的六阶段 Source→Hydrator→Filter→Scorer→Selector→SideEffect 框架，设计可组合的推荐、排序和信息流管道。当用户构建任何为"(用户, 上下文)选择 top K 项目"的系统时使用此技能——社交信息流、内容 CMS、RAG 重排器、任务优先级排序、通知分流、搜索重排、广告排序。 origin: community

recsys-pipeline-architect

用于构建可组合推荐、排序和信息流管道的规范与脚手架技能。它编码了六阶段模式 — Source → Hydrator → Filter → Scorer → Selector → SideEffect — 由 xAI 开源的 For You 算法（Apache 2.0）推广。此技能是该模式的独立重新实现（MIT）——未从原始代码复制。

上游：https://github.com/mturac/recsys-pipeline-architect

何时使用

• 用户想构建任何为"用户/上下文选择 top K 项目"的系统
• 用户问"我应该如何排序 X"或描述信息流/个性化问题
• 用户有评分函数，需要围绕它的管道基础设施
• 用户想从单一相关性分数迁移到带可调权重的多动作预测
• 用户正在包装 LLM/ML 评分器，需要过滤器、水合器、副作用和其技术栈（TypeScript / Go / Python）中的可运行脚手架
• 触发词："推荐系统"、"信息流算法"、"排序管道"、"为你推荐"、"候选管道"、"内容推荐器"、"推荐系统管道架构"、"RAG 检索重排器"

何时不使用

• 模型架构工作（transformer 设计、双塔检索、embedding 训练）——此技能是模型周围的管道，而非模型本身
• 纯 ML 训练管道——评分函数是用户的责任
• 运维已部署的管道（监控、自动扩缩）——超出范围

六阶段框架

| # | 阶段 | 职责 | 并行？ | |---|---|---|---| | 1 | Source | 从一个或多个来源获取候选项 | 是——多个来源并行运行 | | 2 | Hydrator | 用过滤和评分所需的元数据丰富每个候选项 | 是——独立水合器并行运行 | | 3 | Filter | 丢弃永远不应展示的候选项（被屏蔽、过期、重复、不合格） | 顺序——每个过滤器看到更少的项目 | | 4 | Scorer | 为每个存活的候选项分配一个或多个分数 | 顺序——后续评分器看到先前的分数 | | 5 | Selector | 按最终分数排序，返回 top K | 单一操作 | | 6 | SideEffect | 缓存已服务 ID、记录曝光、发出事件、更新计数器 | 异步——绝不能阻塞响应 |

为什么是这个确切顺序

• Source 在水合之前：在付费丰富之前先知道有哪些候选项
• 水合在过滤之前：许多过滤器需要来源未提供的元数据
• 过滤在评分之前：评分是昂贵的阶段；先丢弃不合格的
• 评分器链（非单一评分器）：真实系统组合 ML 评分 + 多样性重排 + 业务规则
• Selector 在评分之后：保持评分确定性和可缓存
• SideEffect 最后且异步：副作用绝不能阻塞用户响应

调用时的工作流

引导用户完成以下八个步骤：

1. 澄清用例（一轮，三个问题）：正在排序的项目？输入上下文？语言/技术栈？
2. 定义候选来源：列出所有候选项来源（数据库查询、API、缓存）
3. 设计水合器：确定评分和过滤需要哪些额外数据
4. 指定过滤器：硬性排除规则（屏蔽、过期、重复、资格）
5. 设计评分器链：ML 分数 → 多样性重排 → 业务规则提升
6. 配置选择器：top-K 选择、分页、去重
7. 规划副作用：曝光日志、缓存更新、事件发出
8. 生成脚手架代码：用户选择的语言中的可运行管道