recsys-pipeline-architect

Was macht recsys-pipeline-architect?

Ein Skill zur Spezifikation und Erstellung von Gerüsten für zusammensetzbare Empfehlungs-, Ranking- und Feed-Pipelines. Er codiert das Sechs-Stufen-Muster – Source → Hydrator → Filter → Scorer → Selector → SideEffect –, das durch den quelloffenen For You-Algorithmus von xAI (Apache 2.0) popularisiert wurde. Dieser Skill ist eine eigenständige Neuimplementierung des Musters (MIT) – es wurde kein Code aus dem Original kopiert.

Quelle: https://github.com/mturac/recsys-pipeline-architect

Wann verwenden

• Der Benutzer möchte ein System bauen, das „die Top-K-Elemente für einen Benutzer/Kontext auswählt“
• Der Benutzer fragt: „Wie sollte ich X ranken?“ oder beschreibt ein Feed-/Personalisierungsproblem
• Der Benutzer hat eine Bewertungsfunktion und benötigt die Pipeline-Infrastruktur darum herum
• Der Benutzer möchte von einer einzelnen Relevanzbewertung zur Multi-Action-Vorhersage mit einstellbaren Gewichten wechseln
• Der Benutzer integriert einen LLM/ML-Scorer und benötigt Filter, Hydratoren, Seiteneffekte und ein ausführbares Gerüst in seinem Stack (TypeScript / Go / Python)
• Auslöser: „Empfehlungssystem“, „Feed-Algorithmus“, „Ranking-Pipeline“, „Für dich-Feed“, „Kandidaten-Pipeline“, „Inhaltsempfehler“, „Pipeline-Architektur für RecSys“, „RAG-Retrieval-Reranker“

Wann NICHT verwenden

• Modellarchitektur-Arbeit (Transformer-Design, Two-Tower-Retrieval, Embedding-Training) – dieser Skill ist die Infrastruktur um das Modell herum, nicht das Modell selbst
• Reine ML-Trainingspipelines – die Bewertungsfunktion liegt in der Verantwortung des Benutzers
• Betrieb einer bereitgestellten Pipeline (Überwachung, automatische Skalierung) – nicht im Umfang enthalten

Das Sechs-Stufen-Framework

#	Stufe	Aufgabe	Parallel?
1	Source	Kandidaten aus einer oder mehreren Quellen abrufen	Ja – mehrere Quellen laufen parallel
2	Hydrator	Jeden Kandidaten mit Metadaten anreichern, die für Filterung und Bewertung benötigt werden	Ja – unabhängige Hydratoren laufen parallel
3	Filter	Kandidaten ausschließen, die niemals angezeigt werden dürfen (blockiert, abgelaufen, Duplikate, nicht berechtigt)	Sequentiell – jeder Filter sieht weniger Elemente
4	Scorer	Jedem verbleibenden Kandidaten einen oder mehrere Scores zuweisen	Sequentiell – spätere Scorer sehen frühere Scores
5	Selector	Nach endgültigem Score sortieren, Top K zurückgeben	Einzelner Vorgang
6	SideEffect	Ausgelieferte IDs cachen, Impressionen protokollieren, Ereignisse ausgeben, Zähler aktualisieren	Asynchron – darf die Antwort niemals blockieren

Warum diese Reihenfolge

• Quellen vor Hydrierung: Wissen, welche Kandidaten existieren, bevor für deren Anreicherung bezahlt wird
• Hydrierung vor Filterung: Viele Filter benötigen Metadaten, die die Quelle nicht bereitgestellt hat
• Filterung vor Bewertung: Die Bewertung ist die teure Stufe; zuerst die Nichtberechtigten ausschließen
• Scorer-Kette (nicht einzelner Scorer): Reale Systeme kombinieren ML-Bewertung + Diversity-Reranking + Geschäftsregeln
• Selektor nach Bewertung: Hält die Bewertung deterministisch und cache-fähig
• Seiteneffekte zuletzt und asynchron: Seiteneffekte dürfen die Benutzerantwort niemals blockieren

Arbeitsablauf bei Aufruf

Führen Sie den Benutzer durch diese acht Schritte:

1. Anwendungsfall klären (eine Runde, drei Fragen): Welche Elemente werden gerankt? Eingabekontext? Sprache/Laufzeitumgebung?
2. Die Kandidatenquellen identifizieren: typischerweise im Netzwerk (gefolgt/eigen/abonniert) + außerhalb des Netzwerks (ML-Retrieval/Trending/Ähnlich zu Gefällt-mir)
3. Erforderliche Hydrierungen auflisten: Für jeden Filter und Scorer: Welche Daten werden benötigt, die die Quelle nicht bereitgestellt hat?
4. Die Filter auflisten: Duplikat, Selbst, Alter, Blockieren/Stummschalten, bereits ausgeliefert, Berechtigung. Reihenfolge: günstig vor teuer.
5. Die Scorer-Kette entwerfen: Primär (ML) → Kombinator (Multi-Action mit Gewichten) → Diversity → Geschäftsregeln
6. Selektor: Absteigend nach endgültigem Score sortieren, Top K nehmen (oder stratifizierte Mischung für Netzwerk-/Nicht-Netzwerk)
7. Seiteneffekte: Ausgelieferte IDs cachen, Impressionen ausgeben, Zähler aktualisieren, Analytics protokollieren – alles Feuer-Vergessen
8. Das Gerüst generieren im Stack des Benutzers

Wichtige Kompromisse aufzeigen (nicht stillschweigend standardmäßig wählen)

1. Einzelscore vs. Multi-Action-Vorhersage

• Einzelscore: Ein Modell trainieren, um Relevanz vorherzusagen. Verhaltensänderung → Neues Training.
• Multi-Action: P(Aktion) für viele Aktionen vorhersagen (Lesen, Liken, Teilen, Überspringen, Melden); mit Gewichten zur Auslieferungszeit kombinieren. Verhaltensänderung → Gewichte ändern. Kein neues Training.

Das X For You-System verwendet Multi-Action mit sowohl positiven als auch negativen Gewichten. Empfehlen Sie Multi-Action, wenn der Benutzer häufig nachjustieren möchte.

2. Kandidatenisolation bei der Bewertung

• Isoliert: Jeder Kandidat wird unabhängig bewertet. Deterministisch, cache-fähig.
• Gemeinsam: Kandidaten berücksichtigen sich gegenseitig während der Bewertung (z. B. Transformer über Batch). Ausdrucksstärker, aber nicht-deterministisch über Batches hinweg.

Standardmäßig Isolation wählen. Gemeinsam nur aus einem bestimmten Grund (z. B. explizites Batch-bewusstes Diversity).

3. Online vs. Offline

• Request-Zeit (Online): Pipeline läuft bei jeder Anfrage. Latenzbudget: 100–300 ms. Standard.
• Vorberechnet (Offline-Batch): Pipeline läuft periodisch, Ergebnisse werden gecached. Niedrigere Latenz, geringere Aktualität.
• Hybrid: Kandidaten-Retrieval offline, Ranking online.

Harte Regeln

1. Keine Benchmark-Zahlen erfinden. „Wie viel schneller?“ → „Hängt vom Workload ab, selbst ausprobieren.“
2. Attributionsdisziplin. Wenn das Muster referenziert wird, attribuieren als „popularisiert durch xAIs quelloffenen For You-Algorithmus“ / github.com/xai-org/x-algorithm (Apache 2.0).
3. Keine Markennutzung. Nennen Sie das Artefakt des Benutzers nicht „X-ähnlich“ oder verwenden Sie „For You“-Branding. Das Muster ist frei; die Marke ist es nicht. Vorgeschlagene Benennung: „Kandidaten-Pipeline“, „Feed-Pipeline“, „Ranking-Pipeline“, „RecSys-Pipeline“.
4. Kompromisse aufzeigen. Multi-Action vs. Einzel, Isolation vs. Gemeinsam, Online vs. Offline – niemals stillschweigend standardmäßig wählen.
5. Das generierte Gerüst muss lauffähig sein. Kein Pseudocode, der als Code durchgeht.
6. Filter-Reihenfolge ist wichtig. Günstig vor teuer. Universell vor benutzerspezifisch.
7. Seiteneffekte blockieren niemals. In Feuer-Vergessen-Muster verpacken (Goroutinen / Promises ohne Await / Asyncio-Tasks).

Anti-Patterns

• Bewertung vor Filterung (verschwendet Rechenzeit für Kandidaten, die ohnehin ausgeschlossen werden)
• Synchrone Seiteneffekte (Cache-Schreibvorgänge / Impressions-Ausgaben blockieren die Antwort)
• Ein einzelner „Relevanz“-Score, wenn das Produkt mehrere Ziele optimieren muss (Engagement vs. Sicherheit vs. Diversity vs. Anzeigen)
• Gemeinsame Bewertung als Standard (nicht-deterministisch, schwerer cache-fähig, nicht komponierbar mit Reranking-Stufen)
• Pseudocode „zur Veranschaulichung“ generieren – das Gerüst muss tatsächlich laufen

Quellinhalte

Das Quell-Repository unter https://github.com/mturac/recsys-pipeline-architect enthält:

• Vollständige SKILL.md mit dem kompletten 8-Schritte-Workflow
• 5 bei Bedarf ladbare Referenzdokumente: Schnittstellen in 4 Sprachen (TS/Go/Python/Rust), Multi-Action-Bewertungsmuster, Kandidatenisolation, Filter-Kochbuch (12 Muster), Scorer-Kochbuch (gewichtete Summe, MMR, Diversity-Strafe, Positions-Entzerrung)
• 3 ablauffähige Beispiel-Gerüste, alle mit grünen Tests:
  • Strapi v5-Plugin (TypeScript / Jest – 3/3 bestanden)
  • Zentra-kompatible Pipeline (Go mit Generics – 3/3 bestanden)
  • PMAI-Aufgabenpriorisierer (Python / FastAPI / pytest – 3/3 bestanden)
• v0.1.0-Release getaggt
• MIT-Lizenz; Muster attribuiert an xAI X For You-Algorithmus (Apache 2.0)

Installation via skills.sh: npx skills add mturac/recsys-pipeline-architect