# Design a Retrieval-Grounded Local Sports News Recommender Design a system that recommends local sports news and uses a large language model to produce grounded, useful responses or summaries from retrieved reporting. Focus on the production architecture and on the decisions required to make retrieval-augmented generation reliable. Your design should explain the content-ingestion and indexing path, personalized retrieval, prompt construction, model serving, response validation, and feedback loop. Compare a managed vector-search service with a self-hosted vector database, and explain when prompt engineering is preferable to fine-tuning. Address latency reductions such as quantization or distillation without assuming that either technique is automatically appropriate. Hallucination control is a central requirement: users should be able to distinguish supported facts from unsupported model output. ### Constraints & Assumptions - No traffic volume, latency target, or content-publishing rate is supplied. State the assumptions that drive your capacity plan instead of inventing fixed requirements. - News changes quickly, so freshness and source provenance must be represented throughout ingestion, retrieval, and generation. - Personalization must not override relevance, freshness, or access controls on source content. - The design should degrade safely when retrieval or generation is unavailable. ### Clarifying Questions to Ask - Is the generated experience a ranked feed, a question-answering surface, a summary, or a combination of these? - Which locations, leagues, teams, and content providers define “local,” and how is a user's locality determined? - How fresh must breaking-news updates be, and can older reports be corrected or retracted? - Which response claims require citations, and what should happen when the retrieved evidence is weak or contradictory? - What user signals may be used for personalization, and what privacy or retention limits apply? ```hint Separate retrieval from generation Define the contract between the ranker that selects evidence and the model that turns that evidence into a response. ``` ```hint Make unsupported output observable Consider a validation stage that can abstain, attach provenance, and record why a response was blocked or downgraded. ``` ### What a Strong Answer Covers - A closed ingestion pipeline that normalizes articles, preserves publication and update times, deduplicates versions, creates embeddings, and updates both lexical and vector indexes. - Candidate generation using location, team, league, freshness, and user-interest signals, followed by a ranker that can combine semantic and keyword relevance. - A clear managed-search versus self-hosted-vector-store decision based on operational burden, scale, filtering support, cost, and portability rather than brand preference. - Grounded prompt construction with retrieved passages, source identifiers, freshness metadata, and an explicit abstention path when evidence is insufficient. - Hallucination defenses at multiple layers: retrieval-quality thresholds, claim-to-source checks, output validation, red-team tests, and monitoring of unsupported-claim rates. - A reasoned prompt-engineering versus fine-tuning choice and a measured approach to quantization, distillation, caching, batching, or smaller-model routing. - Evaluation that separates retrieval quality, recommendation quality, groundedness, latency, and user outcomes. ### Follow-up Questions 1. How would you prevent a stale but highly similar article from outranking a breaking update? 2. What signals would tell you that poor answers come from retrieval rather than generation? 3. How would you handle two credible sources that disagree about the same event? 4. Where could quantization or distillation damage quality, and how would you detect that regression? 5. How would you red-team the system for fabricated scores, players, injuries, or quotations?