Design a Food Ordering Chatbot With Dietary Guardrails and Budget Fine-Tuning

In a round focused on post-training and evaluation of large language models, design a customer-facing chatbot that lets customers of a food-delivery app find and order food through conversation. After the overall design, the discussion went deep on three topics: guardrails when a customer mentions a dietary restriction, handling menu items that come with options (for example a build-your-own spicy hot-pot bowl in which the customer chooses every ingredient), and how to fine-tune the model if the budget only allows fine-tuning an open-source LLM. ### Clarifying Questions - Which actions may the bot take: search restaurants, read menus, build a cart, apply promotions, place the order? Does placing an order need an explicit confirmation? - What restaurant data is available: structured menus with ingredient and allergen fields, or only item names and free-text descriptions? - Which dietary restrictions are in scope: allergies, religious or ethical diets, preferences? What does the product promise about them? - What latency and cost per conversation turn are acceptable? - What compute and data are available for fine-tuning, and may existing chat or ordering logs be used? ### Part 1 — The ordering chatbot Describe the end-to-end design: how a conversation turns into a confirmed order, which components sit beside the language model, and how the bot stays grounded in real menus, prices and availability. ```hint What the model may decide Separate what the language model is allowed to decide on its own from what a deterministic system must decide or check. ``` #### What This Part Should Cover - Tool or API boundaries for search, menus, cart and checkout - Conversation and cart state, and where each is stored - Grounding of item names and prices, with an explicit confirmation before ordering ### Part 2 — Guardrails for dietary restrictions A customer mentions a dietary restriction, such as an allergy or a diet they follow. Explain how the bot detects it, remembers it, applies it to recommendations and to the cart, and talks about it without making promises it cannot keep. ```hint Allergy is not a preference Consider how the cost of a miss differs between a peanut allergy and a dislike of cilantro, and what the bot should do when ingredient data is incomplete. ``` #### What This Part Should Cover - Detection and a structured representation of restrictions, including severity - Enforcement outside the model's free-form text, with a check before checkout - Behaviour when menu data is missing or a request conflicts with the restriction - How the guardrail is evaluated ### Part 3 — Items with options Some items require choices: a size, a spice level, or a long list of ingredients the customer assembles. Explain how the bot collects these choices through conversation and turns them into a valid order line. ```hint Let the menu define the questions Think about what structure in the menu data tells the bot which choices are required, how many may be picked, and what each choice costs. ``` #### What This Part Should Cover - A data model for option groups and their rules - A dialogue strategy that asks only what is needed and handles free-form choices - Validation, pricing and dietary checks at the option level ### Part 4 — Fine-tuning an open-source LLM on a limited budget The budget only allows fine-tuning an open-source model. Explain whether and how you would fine-tune it for this bot, what data you would use, and how you would know it worked. ```hint Spend the budget where prompting fails Ask which behaviours a good prompt plus tools still gets wrong, and what the cheapest training method is that changes them. ``` #### What This Part Should Cover - The decision to fine-tune, the model size and a parameter-efficient method - Training data sources, curation and the safety cases that must be included - Offline and online evaluation, including safety regression checks ### What a Strong Answer Covers - A design in which the model converses and interprets intent while deterministic systems own menus, prices, the cart and safety checks - Dietary restrictions treated as hard constraints, with honest handling of unknown ingredient data - Option-rich items handled from structured option data rather than free text - A realistic budget fine-tuning plan with data, method and evaluation - Metrics for task success, safety and cost, and how they are monitored after launch ### Follow-up Questions - A customer says "I'm allergic to peanuts" in the first turn and later asks to reorder "the usual". How does the restriction persist and apply? - A restaurant's menu has no allergen information at all. What should the bot say, and what should it refuse to say? - How would you show that fine-tuning improved the bot without a regression on safety? - How would you detect and handle a prompt injection hidden in a menu item description?