Design an LLM-Based Conversational Assistant (Chatbot)
MetaMachine Learning Engineer · OnsiteLast updated
Design an end-to-end conversational AI assistant powered by large language models, covering post-training alignment, retrieval/tool orchestration, low-latency serving, and safety guardrails at consumer scale.
Scenario
Design a consumer-facing conversational AI assistant (similar to Meta AI) integrated across messaging platforms. The assistant must handle open-ended dialogues, provide factual and up-to-date answers via web search, invoke external tools (e.g., calendar, weather, reminders), and maintain strict safety and policy adherence.
Requirements
Functional Requirements
- Multi-turn dialogue: Maintain coherent context, track user intent, and resolve coreferences across turns.
- Factual grounding (RAG): Retrieve real-time information from external web indices or internal knowledge bases when questions require up-to-date or domain-specific facts.
- Tool use & API calling: Parse intent to execute external APIs structured as function calls and integrate results into natural language responses.
- Safety & Moderation: Detect and block toxic, harmful, or policy-violating queries and generations while minimizing false positive refusals.
Non-Functional Requirements
- Latency: Time-to-First-Token (TTFT) < 600 ms; Inter-Token Latency (ITL) < 35 ms per token (streaming response).
- Scale: 150 million daily active users (DAU), averaging 10 turns per user daily. Peak query traffic of ~40,000 requests per second (RPS).
- High Availability: 99.99% uptime globally across multiple data center regions.
Scale & Resource Assumptions
- Average input prompt: 800 tokens (including system prompt, retrieved context, and multi-turn history).
- Average generated response: 250 tokens.
- Target primary generation model: ~70B parameter dense model or a Mixture-of-Experts (MoE) equivalent.
Key Architectural Points to Cover
- Model Pipeline & Post-Training: Architecture choices (Dense vs. MoE), Supervised Fine-Tuning (SFT) data collection, Preference Optimization (RLHF / DPO / PPO), and Constitutional AI / Red-teaming loops.
- RAG & Tool Orchestration: Query rewriting, retrieval router (deciding when to search vs. answer directly), vector indexing vs. hybrid search, and prompt synthesis.
- Serving & Inference Optimization: Decoupling prefill and decode stages, KV-cache management (e.g., PagedAttention), continuous batching, quantization (e.g., FP8/INT4), and speculative decoding.
- Safety & Guardrails: Pre-inference moderation (input classifier), on-the-fly token checks, and post-generation safety verification.
- Evaluation & Monitoring: Online metrics (session length, user thumbs-up/down, tool success rate) and offline benchmarks (factuality, instruction following, safety refusal rates).
Hints
Hint 1
Differentiate parametric knowledge from non-parametric retrieval by using a lightweight intent classifier or routing model to avoid unnecessary search latency.
Hint 2
Decouple inference infrastructure into dedicated prefill (compute-bound) and decode (memory-bandwidth-bound) clusters to optimize both TTFT and ITL.
Hint 3
Layer safety checks into asynchronous input screening, aligned base model representations, and output streaming classifiers to minimize added overhead.
Follow-up questions
- How would you implement context compression or memory summarization when conversation history approaches the model's context limit?
- How do you design an automated offline evaluation pipeline to prevent safety or quality regressions after model fine-tuning?
- If p99 Time-to-First-Token spikes during peak hours due to large RAG contexts, what architectural changes would you make to mitigate it?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.