recsys-pipeline-architect
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chineserecsys-pipeline-architect
recsys-pipeline-architect
A spec-and-scaffold skill for building composable recommendation, ranking, and feed pipelines. It encodes the six-stage pattern — Source → Hydrator → Filter → Scorer → Selector → SideEffect — popularized by xAI's open-sourced For You algorithm (Apache 2.0). This skill is an independent reimplementation of the pattern (MIT) — no code copied from the original.
一款用于构建可组合推荐、排序和信息流管道的规范与脚手架技能。它实现了由xAI开源的For You算法(Apache 2.0协议)推广的六阶段模式——Source → Hydrator → Filter → Scorer → Selector → SideEffect。本技能是该模式的独立重实现(MIT协议)——未复制原项目的任何代码。
When to Use
适用场景
- User wants to build any system that picks "the top K items for a user/context"
- User asks "how should I rank X" or describes a feed/personalization problem
- User has a scoring function and needs the pipeline plumbing around it
- User wants to migrate from a single relevance score to multi-action prediction with tunable weights
- User is wrapping an LLM/ML scorer and needs filters, hydrators, side-effects, and a runnable scaffold in their stack (TypeScript / Go / Python)
- Triggers: "recommendation system", "feed algorithm", "ranking pipeline", "for you feed", "candidate pipeline", "content recommender", "pipeline architecture for recsys", "RAG retrieval reranker"
- 用户希望构建任何需为“用户/上下文选择前K个项目”的系统
- 用户询问“我该如何对X进行排序”或描述了信息流/个性化相关问题
- 用户已有评分函数,需要围绕它搭建管道架构
- 用户希望从单一相关性评分迁移至带可调权重的多动作预测
- 用户正在封装LLM/ML评分器,需要在其技术栈(TypeScript / Go / Python)中添加过滤器、数据增强器、副作用处理及可运行的脚手架
- 触发关键词:"recommendation system"、"feed algorithm"、"ranking pipeline"、"for you feed"、"candidate pipeline"、"content recommender"、"pipeline architecture for recsys"、"RAG retrieval reranker"
When NOT to Use
不适用场景
- Model architecture work (transformer design, two-tower retrieval, embedding training) — this skill is plumbing around the model, not the model itself
- Pure ML training pipelines — the scoring function is the user's responsibility
- Operating a deployed pipeline (monitoring, autoscaling) — out of scope
- 模型架构工作(Transformer设计、双塔检索、嵌入训练)——本技能负责模型周边的架构搭建,而非模型本身
- 纯ML训练管道——评分函数由用户自行负责
- 已部署管道的运维(监控、自动扩缩容)——不在本技能范围内
The six-stage framework
六阶段框架
| # | Stage | Job | Parallel? |
|---|---|---|---|
| 1 | Source | Fetch candidates from one or more origins | Yes — multiple sources run in parallel |
| 2 | Hydrator | Enrich each candidate with metadata needed for filtering and scoring | Yes — independent hydrators run in parallel |
| 3 | Filter | Drop candidates that should never be shown (blocked, expired, duplicate, ineligible) | Sequential — each filter sees fewer items |
| 4 | Scorer | Assign each surviving candidate one or more scores | Sequential — later scorers see earlier scores |
| 5 | Selector | Sort by final score, return top K | Single op |
| 6 | SideEffect | Cache served IDs, log impressions, emit events, update counters | Async — must never block the response |
| 序号 | 阶段 | 职责 | 是否可并行? |
|---|---|---|---|
| 1 | Source | 从一个或多个来源获取候选项目 | 是——多来源可并行运行 |
| 2 | Hydrator | 为每个候选项目添加过滤和评分所需的元数据 | 是——独立的数据增强器可并行运行 |
| 3 | Filter | 剔除不应展示的候选项目(已屏蔽、过期、重复、不符合资格) | 串行——每个过滤器处理的项目数量逐渐减少 |
| 4 | Scorer | 为每个留存的候选项目分配一个或多个评分 | 串行——后续评分器可获取前期评分结果 |
| 5 | Selector | 根据最终评分排序,返回前K个项目 | 单一操作 |
| 6 | SideEffect | 缓存已展示的ID、记录曝光数据、触发事件、更新计数器 | 异步——绝不能阻塞响应 |
Why this exact order
为何采用此顺序
- Sources before hydration: know what candidates exist before paying to enrich them
- Hydration before filtering: many filters need metadata the source did not provide
- Filtering before scoring: scoring is the expensive stage; drop the ineligible first
- Scorer chain (not single scorer): real systems compose ML scoring + diversity reranking + business rules
- Selector after scoring: keeps scoring deterministic and cacheable
- SideEffects last and async: side effects must never block the user response
- 先获取来源再做数据增强:先明确候选项目范围,再为其添加元数据,避免资源浪费
- 先数据增强再过滤:许多过滤器需要来源未提供的元数据
- 先过滤再评分:评分是高成本阶段,先剔除不符合资格的项目
- 评分链(而非单一评分器):实际系统需结合ML评分、多样性重排序、业务规则
- 评分后再选择:保证评分的确定性和可缓存性
- 最后异步处理副作用:副作用绝不能阻塞用户响应
Workflow when invoked
调用后的工作流程
Walk the user through these eight steps:
- Clarify the use case (one round, three questions): items being ranked? input context? language/runtime?
- Identify the candidate sources: usually in-network (followed/owned/subscribed) + out-of-network (ML retrieval / trending / similar-to-liked)
- List required hydrations: for each filter and scorer, what data does it need that the source did not provide?
- List the filters: duplicate, self, age, block/mute, previously-served, eligibility. Order matters — cheap before expensive.
- Design the scorer chain: primary (ML) → combiner (multi-action with weights) → diversity → business rules
- Selector: sort descending by final score, take top K (or stratified mix for in-network/out-of-network)
- SideEffects: cache served IDs, emit impression events, update counters, log analytics — all fire-and-forget
- Generate the scaffold in the user's stack
引导用户完成以下八个步骤:
- 明确使用场景(一轮沟通,三个问题):待排序的项目类型?输入上下文?使用的语言/运行时?
- 确定候选项目来源:通常包括网络内(已关注/拥有/订阅的内容)+ 网络外(ML检索/热门/相似内容)
- 列出所需的数据增强项:针对每个过滤器和评分器,来源未提供但必需的数据是什么?
- 列出过滤器:重复项、自身内容、时效、屏蔽/静音、已展示过的内容、资格验证。顺序很重要——低成本过滤器优先于高成本过滤器。
- 设计评分链:主评分(ML)→ 组合器(带权重的多动作)→ 多样性调整 → 业务规则
- 选择器:按最终评分降序排序,取前K个(或按网络内/外分层混合)
- 副作用处理:缓存已展示ID、触发曝光事件、更新计数器、记录分析数据——全部采用“触发即遗忘”模式
- 生成用户技术栈对应的脚手架
Key trade-offs to surface (don't default silently)
需要明确的关键权衡(不可默认选择)
1. Single score vs multi-action prediction
1. 单一评分 vs 多动作预测
- Single score: train one model to predict relevance. To change behavior → retrain.
- Multi-action: predict for many actions (read, like, share, skip, report), combine with weights at serving time. To change behavior → change weights. No retraining.
P(action)
The X For You system uses multi-action with both positive and negative weights. Recommend multi-action when the user expects to tune frequently.
- 单一评分:训练一个模型预测相关性。如需调整行为→重新训练模型。
- 多动作预测:预测多个动作的(阅读、点赞、分享、跳过、举报),在服务阶段结合权重计算。如需调整行为→修改权重。无需重新训练。
P(action)
X的For You系统采用带正负权重的多动作预测。当用户需要频繁调优时,推荐使用多动作预测。
2. Candidate isolation in scoring
2. 评分时的候选项目隔离
- Isolated: each candidate scored independently. Deterministic, cacheable.
- Joint: candidates attend to each other during scoring (e.g., transformer over batch). More expressive but non-deterministic across batches.
Default to isolation. Joint only when there's a specific reason (e.g., explicit batch-aware diversity).
- 隔离式:每个候选项目独立评分。具有确定性、可缓存性。
- 联合式:评分时候选项目相互影响(如对批次使用Transformer)。表达能力更强,但批次间结果非确定性。
默认选择隔离式。仅当有特定需求时(如明确的批次感知多样性调整)才使用联合式。
3. Online vs offline
3. 在线 vs 离线
- Request-time (online): pipeline runs on each request. Latency budget: 100–300ms. Default.
- Pre-computed (offline batch): pipeline runs periodically, results cached. Lower latency, lower freshness.
- Hybrid: candidate retrieval offline, ranking online.
- 请求时(在线):管道在每次请求时运行。延迟预算:100–300ms。默认选择。
- 预计算(离线批次):管道定期运行,结果缓存。延迟更低,但新鲜度不足。
- 混合式:候选项目检索离线完成,排序在线进行。
Hard rules
硬性规则
- Do not invent benchmark numbers. "How much faster?" → "depends on workload, run it yourself."
- Attribution discipline. When the pattern is referenced, attribute as "popularized by xAI's open-sourced For You algorithm" / (Apache 2.0).
github.com/xai-org/x-algorithm - No trademark use. Do not name the user's artifact "X-like" or use "For You" branding. Pattern is free; brand is not. Suggested naming: "candidate pipeline", "feed pipeline", "ranking pipeline", "recsys pipeline".
- Surface trade-offs. Multi-action vs single, isolation vs joint, online vs offline — never default silently.
- The generated scaffold must run. No pseudocode passing as code.
- Filter order matters. Cheap before expensive. Universal before user-specific.
- Side effects never block. Wrap in fire-and-forget patterns (goroutines / promises without await / asyncio tasks).
- 不得编造基准数据。若被问“速度提升多少?”→回答“取决于工作负载,请自行测试。”
- 规范归属标注。当引用该模式时,标注为“由xAI开源的For You算法推广” / (Apache 2.0协议)。
github.com/xai-org/x-algorithm - 不得使用商标。不得将用户的产物命名为“类X”或使用“For You”品牌。模式可免费使用;品牌不可。建议命名:“候选项目管道”、“信息流管道”、“排序管道”、“推荐系统管道”。
- 明确权衡选项。多动作vs单一、隔离vs联合、在线vs离线——绝不能默认选择而不告知用户。
- 生成的脚手架必须可运行。不得用伪代码替代可执行代码。
- 过滤器顺序至关重要。低成本过滤器优先于高成本过滤器。通用过滤器优先于用户特定过滤器。
- 副作用绝不能阻塞。采用“触发即遗忘”模式(goroutines / 无需await的promise / asyncio任务)。
Anti-Patterns
反模式
- Scoring before filtering (wastes compute on candidates that will be dropped anyway)
- Synchronous side effects (cache writes / impression emits blocking the response)
- A single "relevance" score when the product needs to tune for multiple objectives (engagement vs safety vs diversity vs ads)
- Joint scoring as default (non-deterministic, harder to cache, doesn't compose with reranking stages)
- Generating pseudocode "for illustration" — the scaffold must actually run
- 先评分再过滤(浪费计算资源在最终会被剔除的候选项目上)
- 同步处理副作用(缓存写入/曝光事件触发阻塞响应)
- 当产品需要针对多目标调优(参与度vs安全性vs多样性vs广告)时,仅使用单一“相关性”评分
- 默认使用联合评分(非确定性、难以缓存、无法与重排序阶段组合)
- 生成“用于演示”的伪代码——脚手架必须实际可运行
Upstream contents
上游仓库内容
The upstream repository at https://github.com/mturac/recsys-pipeline-architect ships:
- Full with the complete 8-step workflow
SKILL.md - 5 load-on-demand reference docs: interfaces in 4 languages (TS/Go/Python/Rust), multi-action scoring pattern, candidate isolation, filter cookbook (12 patterns), scorer cookbook (weighted sum, MMR, diversity penalty, position debiasing)
- 3 runnable example scaffolds, every one green on its test suite:
- Strapi v5 plugin (TypeScript / Jest — 3/3 pass)
- Zentra-compatible pipeline (Go with generics — 3/3 pass)
- PMAI task prioritizer (Python / FastAPI / pytest — 3/3 pass)
- v0.1.0 release tagged
- MIT license; pattern attributed to xAI X For You algorithm (Apache 2.0)
Install via skills.sh:
npx skills add mturac/recsys-pipeline-architect- 完整的,包含全部8步工作流程
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