Multi-stage rec serving
Multi-stage rec serving
One-line summary: Online recommenders retrieve a candidate subset, then score/rank, then optionally re-rank or run test-time knowledge-graph reasoning — including when the preference store is structured knowledge.
The insight
A “rec API over a KG” in the fetched record is still retrieve → rank, not a single graph walk that replaces serving. Grokipedia’s primer states the three online stages. KGERA adds a lightweight KG-Reason score at inference so the graph can change without retraining. K-RagRec retrieves item-KG subgraphs, re-ranks them, then feeds an LLM. Knowledge-based systems use explicit constraints or graph-shaped user models but still generate then order items. From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app.
The chain
Online serving is retrieve then rank (optional test-time KG reason). For YouTube, cheap candidates are playlistItems of named channels; cloning browse is out.
Canonical: user-owned-graph-to-quota-aware-youtube-serving.
Evidence
- From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: “candidate generation first retrieves a subset of potential items (e.g., hundreds from millions) … Scoring then ranks these candidates … Final re-ranking incorporates additional factors like diversity, freshness, or business constraints.”
- From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: KGERA “performs lightweight, interpretable reasoning exclusively at inference time” and “adapt dynamically to evolving user preference signals without retraining.”
- From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: KGERA reports “approximately 10ms per-user inference time” for the reasoning module; the graph they score over is a mined MovieLens item KG, not a user-drawn map.
- From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: K-RagRec “indexes item-KG subgraphs into a vector store, applies a popularity-selective retrieval policy, re-ranks retrieved subgraphs, then projects them into an LLM.”
- From 2026-08-21-autoresearch-best-architecture-for-a-rec-system-web-app: Official YouTube candidate path for a known channel is
channels.list→ uploads playlist →playlistItems.list(1 unit/page), notsearch.list(100 calls/day).
Contradictions / tensions
- Every fetched KG-rec serving paper uses a mined or item-side graph. A hand-authored interest graph is closer to knowledge-based-recommender user models; those pages do not test YouTube.
- Recreating YouTube browse as the “candidate generation UI” is policy-barred; independent value has to sit in the graph/ranker, not a clone of homepage/Up Next. See youtube-data-access-constraints.