Design a Food-Ordering Chatbot with Dietary Guardrails
Design a customer-facing chatbot that builds a valid food order through conversation, respects stated dietary restrictions, handles customizable items, and is fine-tuned and evaluated on a limited budget.
Problem statement
Design a customer-facing chatbot that helps a customer order food through conversation.
Three areas matter most: guardrails when a customer mentions a dietary restriction such as an allergy or a vegetarian diet, items that are built from many options (for example a bowl where the customer picks a base, several toppings and a sauce), and how you would fine-tune an open-source language model when the budget rules out larger hosted models.
For this exercise, assume the customer has already chosen one restaurant and chats inside the app. The chatbot can answer questions about that restaurant's menu, suggest items, ask about required choices and build a cart.
The restaurant's menu service is the source of truth for items, option groups and their selection rules, prices, availability, and the dietary and allergen tags the restaurant supplies; some items have no tag information.
The chatbot proposes cart changes; nothing is added to the customer's cart until the customer confirms the change, and checkout and payment use the existing flow.
When a customer states a restriction, the chatbot must not suggest an item that the menu data marks as conflicting with it, must say when the data is missing rather than guess, and must never promise that an item is safe beyond what the restaurant states.
For this exercise, assume the team can only fine-tune and self-host an open-source model of up to about 8 billion parameters. Design the conversation and cart flow, the guardrails, the model's training and evaluation, and serving. Restaurant search, delivery, payments and voice ordering are outside scope.
All counts and targets below are practice assumptions.
What to build
- A customer can ask about the chosen restaurant's menu and build an order in conversation; each proposed cart change names exact items and options, uses current menu prices and availability, and is applied only after the customer confirms it.
- A restriction the customer states is remembered for the session and applied to every later suggestion: conflicting items are not suggested, missing tag data is disclosed, and an explicit request for a conflicting item gets a warning and needs a separate confirmation.
- Items made of option groups are configured through conversation: the chatbot asks for required choices, enforces each group's minimum and maximum selections, and shows the resulting price before confirmation.
- Operators fine-tune a version of the open-source model, evaluate it on task success and guardrail behavior before release, and roll it out or back with every conversation tied to the model version that served it.
At scale
- For this exercise, assume 2 million chat sessions a day with peaks of 1,000 customer messages per second; a typical session has 6 to 10 turns.
- For this exercise, assume a reply should start streaming within 1.5 seconds and finish within 4 seconds at the 95th percentile.
- For this exercise, assume a menu has up to 300 items and an item up to 10 option groups, and a sold-out item or price change must be reflected in new replies within 1 minute.
- For this exercise, assume a fine-tuning run must fit on one node of 8 GPUs and finish within a day, and a release is blocked if the evaluation finds any suggestion that conflicts with a stated restriction on the guardrail test set.