推荐系统流水线架构师 是做什么的？
一个用于构建可组合推荐、排序和内容流管道的规范与脚手架技能。它编码了六阶段模式 — 来源→充实→过滤→评分→选择→副作用 — 该模式因 xAI 开源的 为你推荐算法（Apache 2.0）而广为人知。此技能是该模式的独立重新实现 (MIT) — 未从原始代码中复制任何代码。
上游仓库：https://github.com/mturac/recsys-pipeline-architect
使用时机
- 用户想要构建任何“为一个用户/上下文挑选前 K 个项目”的系统
- 用户询问“我该如何对 X 进行排名”或描述了一个 feed/个性化问题
- 用户有一个评分函数，并需要围绕它构建管道基础设施
- 用户希望从单一相关性评分迁移到可调权重的多动作预测
- 用户正在封装一个 LLM/ML 评分器，并需要在其技术栈（TypeScript / Go / Python）中添加过滤器、充实器、副作用以及可运行的脚手架
- 触发词：“推荐系统”、“feed 算法”、“排名管道”、“为你推荐 feed”、“候选管道”、“内容推荐器”、“推荐系统管道架构”、“RAG 检索重排序器”
何时不使用
- 模型架构工作（Transformer 设计、双塔检索、嵌入训练）— 此技能是围绕模型的管道基础设施，而非模型本身
- 纯 ML 训练管道 — 评分函数是用户的责任
- 操作已部署的管道（监控、自动缩放）— 不在范围内
六阶段框架
| # | 阶段 | 任务 | 可并行？ |
|---|---|---|---|
| 1 | 来源 | 从一个或多个源获取候选内容 | 是 — 多个来源并行运行 |
| 2 | 充实 | 为每个候选内容丰富过滤和评分所需的元数据 | 是 — 独立的充实器并行运行 |
| 3 | 过滤 | 丢弃绝不应展示的候选内容（被屏蔽、过期、重复、不符合条件） | 顺序 — 每个过滤器看到的项目减少 |
| 4 | 评分 | 为每个存活的候选内容分配一个或多个分数 | 顺序 — 后续评分器会看到之前的评分 |
| 5 | 选择 | 按最终分数排序，返回前 K 个 | 单一操作 |
| 6 | 副作用 | 缓存已提供内容的 ID、记录展示、发出事件、更新计数器 | 异步 — 绝不能阻塞响应 |
为什么是这个顺序
- 在充实之前先有来源：先知道有哪些候选者，再决定是否付出代价去丰富它们
- 在过滤之前先有充实：许多过滤器需要来源未提供的元数据
- 在评分之前先有过滤：评分是昂贵的阶段；先丢弃不符合条件的候选者
- 评分链（而非单一评分器）：真实系统会组合 ML 评分、多样性重排序和业务规则
- 在评分之后选择：保持评分确定性且可缓存
- 副作用最后且异步：副作用绝不能阻塞用户响应
调用时的工作流
引导用户完成以下八个步骤：
- 澄清用例（一轮对话，三个问题）：要排序的项目？输入上下文？语言/运行时？
- 识别候选来源：通常是网络内（关注/拥有/订阅的）+ 网络外（ML 检索/热门/与喜欢的相似）
- 列出所需的充实操作：对于每个过滤器和评分器，它需要哪些来源未提供的数据？
- 列出过滤器：重复、自身、年龄、屏蔽/静音、之前已提供、资格。顺序很重要 — 便宜的在前，昂贵的在后。
- 设计评分链：主评分（ML）→ 组合器（带权重的多动作）→ 多样性 → 业务规则
- 选择：按最终分数降序排序，取前 K 个（或网络内/网络外的分层混合）
- 副作用：缓存已提供内容的 ID、发出展示事件、更新计数器、记录分析 — 全部即发即忘
- 生成脚手架：在用户的技术栈中
需要体现的关键权衡（不要静默默认）
1. 单一评分 vs 多动作预测
- 单一评分：训练一个模型预测相关性。要改变行为 → 重新训练。
- 多动作：预测许多动作（阅读、点赞、分享、跳过、举报）的
P(动作)，在服务时用权重组合。要改变行为 → 更改权重。无需重训练。
X For You 系统使用同时包含正负权重的多动作。当用户预期会频繁调整时，推荐使用多动作。
2. 评分中的候选隔离
- 隔离：每个候选独立评分。确定性、可缓存。
- 联合：候选在评分时相互关注（例如，对整个 batch 使用 Transformer）。表达能力更强，但跨 batch 非确定性。
默认使用隔离。仅在有特定原因（例如，明确的 batch 感知多样性）时才使用联合。
3. 在线 vs 离线
- 请求时（在线）：管道在每个请求上运行。延迟预算：100–300 毫秒。默认。
- 预计算（离线批处理）：管道定期运行，结果被缓存。延迟更低，新鲜度更低。
- 混合：候选检索离线，排名在线。
硬性规则
- 不要编造基准数据。“快多少？” → “取决于工作负载，请自己运行。”
- 归属规范。 当引用该模式时，应注明“因 xAI 开源的为你推荐算法而广为人知” /
github.com/xai-org/x-algorithm(Apache 2.0)。 - 不使用商标。 不要将用户的产物命名为“X-like”或使用“为你推荐”品牌。模式是免费的；品牌不是。建议命名：“候选管道”、“feed 管道”、“排名管道”、“推荐系统管道”。
- 体现权衡。 多动作 vs 单一、隔离 vs 联合、在线 vs 离线 — 绝不能静默默认。
- 生成的脚手架必须可运行。 不允许用伪代码冒充代码。
- 过滤器顺序很重要。 便宜的在前，昂贵的在后。通用的在用户特定的之前。
- 副作用绝不阻塞。 使用即发即忘模式（goroutines / 无 await 的 Promises / asyncio 任务）。
反模式
- 在过滤之前评分（浪费计算资源在终将被丢弃的候选上）
- 同步副作用（缓存写入/展示发出阻塞响应）
- 当产品需要针对多个目标（参与度 vs 安全性 vs 多样性 vs 广告）进行调整时，仅使用单一的“相关性”评分
- 默认使用联合评分（非确定性，更难缓存，不能与重排序阶段组合）
- 生成“仅供说明”的伪代码 — 脚手架必须能实际运行
上游内容
上游仓库位于 https://github.com/mturac/recsys-pipeline-architect，包含：
- 完整的
SKILL.md，包含完整的八步工作流 - 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