### Prompt Design a system that detects and handles inappropriate text in seller-uploaded product descriptions for a marketplace containing billions of product listings. Your design should cover the machine-learning approach and the production system around it, from upload-time decisions through human review, appeals, monitoring, and model improvement. Do not assume that “inappropriate” is one universal binary label. Explain how policy categories, severity, confidence, language, and context affect the action taken. ### Constraints & Assumptions - New and edited descriptions should receive an upload-time decision quickly enough not to make listing creation unusable. - The corpus is multilingual and includes slang, obfuscation, quoted text, and legitimate terms that can be ambiguous out of context. - Some violations are severe enough to block immediately; uncertain or lower-severity cases may be queued for review or checked asynchronously. - A seller must receive a reason category and have an appeal path where policy permits it. - Models, policy rules, and thresholds change over time, so every decision must be reproducible and auditable. - Images and other listing fields may exist, but the required scope is the product-description text. Treat richer context as an optional extension. ### Clarifying Questions to Ask - Which policy categories and jurisdictions are in scope, and what action corresponds to each category? - What are the tolerable false-positive and false-negative costs by severity? - What upload latency, peak traffic, availability, and review-capacity targets apply? - Is existing labeled moderation and appeal data available, and how biased is it toward previously reviewed traffic? - Should existing listings be rescanned when policy or models change? - What seller context may legally and ethically be used? ### Part 1: Frame the ML Problem Define labels, training data, model families, metrics, and thresholding. Explain how you would handle multilingual text, class imbalance, ambiguous context, adversarial spelling, and changing policy. #### Hints Optimize decisions, not one global model score. A severe category with costly misses may need a different threshold and review path from a contextual category with costly false blocks. #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 2: Design the Online and Offline System Describe the upload request path, asynchronous processing, feature and model versioning, human-review queues, appeals, rescans, and failure behavior. Explain how the design scales to billions of stored descriptions without scanning all of them on every change. #### Hints Separate the low-latency decision path from expensive enrichment and historical rescans. Store enough decision metadata to explain and replay outcomes. #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 3: Evaluate and Operate the System Explain offline evaluation, a safe launch, online monitoring, feedback loops, abuse resistance, and rollback. Address the fact that appealed and reviewed content is not a random sample of all uploads. #### Hints Observed reviewer outcomes are selected by the current system. Include random sampling or another strategy that can estimate blind spots. #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions 1. How would you estimate recall when most allowed descriptions are never manually reviewed? 2. How would you prevent an attacker from learning thresholds through repeated edits? 3. When should an edit be blocked synchronously versus published pending asynchronous review? 4. How would a policy-label split or merge affect historical training data and rescans? 5. How would you test that one language is not receiving a disproportionate false-block rate?