Spaces:
Sleeping
Sleeping
Update README.md
Browse files
README.md
CHANGED
|
@@ -1,499 +1,509 @@
|
|
| 1 |
-
|
| 2 |
-
|
| 3 |
-
|
| 4 |
-
|
| 5 |
-
|
| 6 |
-
|
| 7 |
-
|
| 8 |
-
|
| 9 |
-
|
| 10 |
-
|
| 11 |
-
|
| 12 |
-
|
| 13 |
-
|
| 14 |
-
|
| 15 |
-
|
| 16 |
-
|
| 17 |
-
|
| 18 |
-
|
| 19 |
-
|
| 20 |
-
|
| 21 |
-
|
| 22 |
-
|
| 23 |
-
|
| 24 |
-
|
| 25 |
-
|
| 26 |
-
|
| 27 |
-
|
| 28 |
-
|
| 29 |
-
|
| 30 |
-
|
| 31 |
-
|
| 32 |
-
|
| 33 |
-
|
| 34 |
-
|
| 35 |
-
|
| 36 |
-
|
| 37 |
-
|
| 38 |
-
|
| 39 |
-
|
| 40 |
-
|
| 41 |
-
|
| 42 |
-
|
| 43 |
-
|
| 44 |
-
|
| 45 |
-
|
| 46 |
-
|
| 47 |
-
|
| 48 |
-
|
| 49 |
-
|
| 50 |
-
|
| 51 |
-
|
| 52 |
-
```
|
| 53 |
-
|
| 54 |
-
|
| 55 |
-
|
| 56 |
-
|
| 57 |
-
|
| 58 |
-
|
| 59 |
-
|
| 60 |
-
|
| 61 |
-
|
| 62 |
-
|
| 63 |
-
|
| 64 |
-
|
| 65 |
-
|
| 66 |
-
|
| 67 |
-
|
| 68 |
-
|
| 69 |
-
|
| 70 |
-
|
| 71 |
-
|
| 72 |
-
|
| 73 |
-
|
| 74 |
-
|
| 75 |
-
|
| 76 |
-
|
| 77 |
-
|
| 78 |
-
|
| 79 |
-
|
| 80 |
-
|
| 81 |
-
|
| 82 |
-
|
| 83 |
-
|
| 84 |
-
|
| 85 |
-
|
| 86 |
-
|
| 87 |
-
|
| 88 |
-
|
| 89 |
-
|
| 90 |
-
|
| 91 |
-
|
| 92 |
-
|
| 93 |
-
|
| 94 |
-
|
| 95 |
-
|
| 96 |
-
|
| 97 |
-
- **
|
| 98 |
-
|
| 99 |
-
|
| 100 |
-
|
| 101 |
-
|
| 102 |
-
|
| 103 |
-
|
| 104 |
-
|
| 105 |
-
|
| 106 |
-
|
| 107 |
-
|
| 108 |
-
|
| 109 |
-
|
| 110 |
-
|
| 111 |
-
|
| 112 |
-
|
| 113 |
-
|
| 114 |
-
|
| 115 |
-
|
| 116 |
-
|
| 117 |
-
|
| 118 |
-
|
| 119 |
-
|
| 120 |
-
|
| 121 |
-
|
| 122 |
-
|
| 123 |
-
|
| 124 |
-
|
| 125 |
-
|
| 126 |
-
|
| 127 |
-
|
| 128 |
-
|
| 129 |
-
|
| 130 |
-
|
| 131 |
-
|
| 132 |
-
|
| 133 |
-
|
| 134 |
-
|
| 135 |
-
|
| 136 |
-
|
| 137 |
-
|
| 138 |
-
|
| 139 |
-
|
| 140 |
-
|
| 141 |
-
|
| 142 |
-
|
| 143 |
-
|
| 144 |
-
###
|
| 145 |
-
.
|
| 50 |
+
Create an account (if you haven’t already), generate your key, and set it as an environment variable:
|
| 51 |
+
|
| 52 |
+
```bash
|
| 53 |
+
export GROQ_API_KEY=your_api_key_here
|
| 54 |
+
```
|
| 55 |
+
|
| 56 |
+
Or, add it to a `.env` file and load it using your preferred method.
|
| 57 |
+
|
| 58 |
+
### 🔗 Running the App
|
| 59 |
+
|
| 60 |
+
```bash
|
| 61 |
+
streamlit run app.py
|
| 62 |
+
```
|
| 63 |
+
|
| 64 |
+
Ensure the `restaurant_reservation.db` is in the `/db` folder inside the root directory. This contains all restaurant, table, slot, and reservation data.
|
| 65 |
+
|
| 66 |
+
|
| 67 |
+
|
| 68 |
+
---
|
| 69 |
+
|
| 70 |
+
## 🧠 Language Model & Retrieval Architecture
|
| 71 |
+
|
| 72 |
+
This project leverages **Meta’s LLaMA 3 8B** language model (`llama3-8b-8192`), accessed via **Groq’s OpenAI-compatible API**. Groq’s unique **LPU (Language Processing Unit)** hardware delivers ultra-fast inference speeds—up to 876 tokens per second for LLaMA 3 8B—enabling near-instantaneous responses even for complex, multi-step conversations. The model’s 8192-token context window allows it to efficiently process extended dialogues, rich database results, and prompt histories.
|
| 73 |
+
|
| 74 |
+
The system is built around a **Retrieval-Augmented Generation (RAG)** architecture. Here’s how it works:
|
| 75 |
+
|
| 76 |
+
- **Semantic Search & Retrieval:**
|
| 77 |
+
- **ChromaDB** is used as the vector database to store embeddings of restaurant, table, and slot data.
|
| 78 |
+
- User queries and database content are converted to embeddings using the **all-MiniLM-L6-v2** sentence transformer model from Hugging Face’s Sentence Transformers library.
|
| 79 |
+
- This enables the system to quickly find semantically similar information, such as restaurants matching a cuisine or tables with specific features.
|
| 80 |
+
- **Grounding in Real-Time Data:**
|
| 81 |
+
- The LLM is provided with both the results of semantic search and, when needed, structured data retrieved from the SQLite database.
|
| 82 |
+
- This ensures responses are always up-to-date and contextually accurate.
|
| 83 |
+
- **Modular, Multi-Step Processing:**
|
| 84 |
+
- The LLM is used in a modular fashion, with specialized prompts for each stage of the conversation:
|
| 85 |
+
|
| 86 |
+
### **Key Processing Steps**
|
| 87 |
+
|
| 88 |
+
1. **Intent Detection**
|
| 89 |
+
Determines the user’s goal—booking a table, checking availability, asking general questions, or handling edge cases and non-sequiturs.
|
| 90 |
+
|
| 91 |
+
2. **Information Extraction**
|
| 92 |
+
Extracts structured fields (restaurant name, user name, contact info, party size, reservation time) from free-form user input.
|
| 93 |
+
|
| 94 |
+
3. **Extracting information from database**
|
| 95 |
+
- **Semantic Search:** For natural language queries (e.g., “Italian restaurants with outdoor seating”), the LLM triggers a semantic search in ChromaDB, powered by `all-MiniLM-L6-v2` embeddings.
|
| 96 |
+
### Cases where semantic search approach fails:
|
| 97 |
+
- **SQL Query Generation:** For precise data requests (e.g., “Show all tables available at 7pm”), the LLM generates SQL queries to fetch data from the SQLite database.
|
| 98 |
+
|
| 99 |
+
4. **Result Interpretation**
|
| 100 |
+
Converts raw SQL or semantic search results into clear, conversational summaries for the user.
|
| 101 |
+
|
| 102 |
+
5. **Multi-Turn Dialogue Management**
|
| 103 |
+
Maintains context across messages, using previous inputs and system memory to build coherent, helpful conversations with the user.
|
| 104 |
+
|
| 105 |
+
### **Security & Control**
|
| 106 |
+
|
| 107 |
+
- **No Direct Booking by LLM:**
|
| 108 |
+
For security, the LLM is not permitted to perform direct database modifications. Final reservations are handled by a dedicated, safeguarded logic module.
|
| 109 |
+
- **Prompt Engineering:**
|
| 110 |
+
Each task (intent, extraction, query, summarization) is managed by a specialized prompt, improving reliability and modularity.
|
| 111 |
+
|
| 112 |
+
---
|
| 113 |
+
|
| 114 |
+
## **In summary:**
|
| 115 |
+
This architecture combines the speed and intelligence of LLaMA 3 via Groq with robust retrieval from ChromaDB (using `all-MiniLM-L6-v2` embeddings) and SQLite, ensuring fast, accurate, and context-aware responses for every user query.
|
| 116 |
+
|
| 117 |
+
|
| 118 |
+
## 💬 Example User Journeys with Application Walkthrough
|
| 119 |
+
|
| 120 |
+
|
| 121 |
+
Below are screenshots showing the end-to-end flow of the restaurant reservation assistant in action:
|
| 122 |
+
|
| 123 |
+
---
|
| 124 |
+
|
| 125 |
+
### 🟢 Image 1: Landing Page
|
| 126 |
+
|
| 127 |
+
|
| 128 |
+
The landing page welcomes users and prompts:
|
| 129 |
+
**"Ask something about restaurants or reservations..."**
|
| 130 |
+
|
| 131 |
+
|
| 132 |
+
This initiates a free-form, conversational interface for users to interact naturally.
|
| 133 |
+
Here, also names of restaurants, cuisines, special features can be seen, which also stays along with the conversation thread which is scrollable.
|
| 134 |
+
|
| 135 |
+
---
|
| 136 |
+
|
| 137 |
+
### 💬 Image 2: General Conversation
|
| 138 |
+
|
| 139 |
+
|
| 140 |
+
The assistant engages in friendly conversation, understanding user intent like greetings, small talk, or queries about restaurants.
|
| 141 |
+
|
| 142 |
+
---
|
| 143 |
+
|
| 144 |
+
### 🔍 Image 3: Database Query + Interpretation
|
| 145 |
+
|
| 146 |
+
|
| 147 |
+
The assistant first uses ChromaDB with semantic search to quickly retrieve relevant answers from a knowledge base. If no confident result is found, it dynamically generates an appropriate SQL SELECT query, executes it on the structured database, interprets the result, and returns a natural, conversational response.
|
| 148 |
+
|
| 149 |
+
---
|
| 150 |
+
|
| 151 |
+
### 🤝 Image 4 to 6: Information Gathering + Suggestions
|
| 152 |
+
|
| 153 |
+
|
| 154 |
+
### Handling random text
|
| 155 |
+
|
| 156 |
+
|
| 157 |
+
Through ongoing conversation, the assistant extracts necessary reservation information:
|
| 158 |
+
- 🏨 Restaurant name
|
| 159 |
+
- 🙋 User name
|
| 160 |
+
- 📱 Contact
|
| 161 |
+
- 👥 Party size
|
| 162 |
+
- ⏰ Time
|
| 163 |
+
|
| 164 |
+
It continues to help the user by checking availability and making suggestions.
|
| 165 |
+
|
| 166 |
+
---
|
| 167 |
+
|
| 168 |
+
### ✅ Image 7: Ready for Booking Confirmation
|
| 169 |
+
|
| 170 |
+
|
| 171 |
+
Once all required information is gathered, the assistant summarizes the reservation details and asks for user confirmation with a simple **`book`** command.
|
| 172 |
+
|
| 173 |
+
---
|
| 174 |
+
|
| 175 |
+
### 🧾 Image 8: Booking Confirmation
|
| 176 |
+
|
| 177 |
+
|
| 178 |
+
Booking is processed successfully!
|
| 179 |
+
|
| 180 |
+
- Restaurant: **Pasta Republic**
|
| 181 |
+
- Time: **20 on 2025-05-12**
|
| 182 |
+
- Party size: **15**
|
| 183 |
+
- Tables booked: **4** (4 tables are needed to accomodate 15 people as one table has 4 seating capacity)
|
| 184 |
+
- Reservation ID: **#10**
|
| 185 |
+
The system calculates the number of tables needed using `ceil(party_size / 4)`, verifies table availability, reserves the required slots, and finalizes the booking.
|
| 186 |
+
|
| 187 |
+
The assistant informs the user:
|
| 188 |
+
|
| 189 |
+
|
| 190 |
+
👉 Please mention this Reservation ID at the restaurant reception when you arrive.
|
| 191 |
+
|
| 192 |
+
This flow demonstrates a complete, intelligent reservation assistant that uses natural language processing, database querying, and interactive UX logic to help users make hassle-free bookings.
|
| 193 |
+
|
| 194 |
+
|
| 195 |
+
---
|
| 196 |
+
## Some other results:
|
| 197 |
+
|
| 198 |
+
|
| 199 |
+
|
| 200 |
+
---
|
| 201 |
+
### If user enters random text:
|
| 202 |
+
|
| 203 |
+
|
| 204 |
+
|
| 205 |
+
|
| 206 |
+
|
| 207 |
+
# Database explanation
|
| 208 |
+
* **`restaurant_reservation.db`**:
|
| 209 |
+
|
| 210 |
+
* This SQLite database contains the following tables:
|
| 211 |
+
|
| 212 |
+
* **`restaurants`**:
|
| 213 |
+
|
| 214 |
+
* Stores information about each restaurant, such as its **name**, **cuisine**, **location**, **seating capacity**, **rating**, **address**, **contact details**, **price range**, and **special features**.
|
| 215 |
+
* The **`id`** field serves as a unique identifier for each restaurant.
|
| 216 |
+
* **Important Note**: The **`id`** is used internally in the database and should not be exposed to the user.
|
| 217 |
+
|
| 218 |
+
* **`tables`**:
|
| 219 |
+
|
| 220 |
+
* Stores information about tables at each restaurant.
|
| 221 |
+
* Each table is associated with a **`restaurant_id`**, linking it to a specific restaurant.
|
| 222 |
+
* Each table has a **capacity** (default is 4), which indicates how many guests it can accommodate.
|
| 223 |
+
* The **`id`** field uniquely identifies each table and should not be shared with the user.
|
| 224 |
+
|
| 225 |
+
* **`slots`**:
|
| 226 |
+
|
| 227 |
+
* Stores information about the availability of each table.
|
| 228 |
+
* Each slot corresponds to a **1-hour** time block for a specific table on a particular day (e.g., a table might have slots available from **9AM to 9PM**).
|
| 229 |
+
* **`is_reserved`** indicates whether the slot is booked (**1**) or available (**0**).
|
| 230 |
+
* **`date`** is hardcoded to **2025-05-12**, and the **`hour`** field defines the start time for the reservation (ranging from **9** to **20**, representing 9AM to 8PM).
|
| 231 |
+
* The **`slot.id`** and **`table_id`** are used to uniquely identify the slots and link them to the relevant tables.
|
| 232 |
+
|
| 233 |
+
* **`reservations`**:
|
| 234 |
+
|
| 235 |
+
* Stores reservation details made by the user, including:
|
| 236 |
+
|
| 237 |
+
* **`restaurant_id`**: Links the reservation to a specific restaurant.
|
| 238 |
+
* **`user_name`**: The name of the user who made the reservation.
|
| 239 |
+
* **`contact`**: The contact details (e.g., phone number) of the user.
|
| 240 |
+
* **`date`**: Hardcoded to **2025-05-12**, representing the reservation date.
|
| 241 |
+
* **`time`**: The starting hour of the reservation, which matches a slot's **hour** field.
|
| 242 |
+
* **`party_size`**: The number of people for whom the reservation is made.
|
| 243 |
+
* The **`id`** is used to uniquely identify each reservation, but it is not exposed to the user.
|
| 244 |
+
|
| 245 |
+
* **`reservation_tables`**:
|
| 246 |
+
|
| 247 |
+
* A junction table that links reservations to tables.
|
| 248 |
+
* Contains:
|
| 249 |
+
|
| 250 |
+
* **`reservation_id`**: Links the reservation to the **`reservations`** table.
|
| 251 |
+
* **`table_id`**: Links the reservation to the relevant **`tables`**.
|
| 252 |
+
* This table helps associate a reservation with the actual tables that are booked for that reservation.
|
| 253 |
+
|
| 254 |
+
|
| 255 |
+
## 📄 Prompt Engineering Strategy
|
| 256 |
+
|
| 257 |
+
### ✨ Design Principles
|
| 258 |
+
|
| 259 |
+
1. **🔁 Separation of Concerns**
|
| 260 |
+
For different purposes, I have engineered different prompts that are modular, making the assistant easier to debug, maintain, and enhance:
|
| 261 |
+
|
| 262 |
+
* **Intent classification** (`determine_intent.txt`)
|
| 263 |
+
* **Information extraction** (`store_user_info.txt`)
|
| 264 |
+
* **SQL query generation** (`schema_prompt.txt`)
|
| 265 |
+
* **SQL result interpretation** (`interpret_sql_result.txt`)
|
| 266 |
+
* **Natural reply generation** (`generate_reservation_conversation.txt`)
|
| 267 |
+
|
| 268 |
+
2. **🧠 Context-Aware Memory Management**
|
| 269 |
+
|
| 270 |
+
* Maintains `chat_history`, `user_data`, and `last_reply` using Streamlit session state.
|
| 271 |
+
* Tracks conversation context across turns to avoid repetition, keep interactions natural, and gracefully handle incomplete data.
|
| 272 |
+
|
| 273 |
+
3. **✅ Controlled Confirmation Flow**
|
| 274 |
+
|
| 275 |
+
* Prompts ensure that **only when all required fields (restaurant name, name, contact, party size, and time)** are filled, the assistant proceeds to ask for booking confirmation.
|
| 276 |
+
* Prevents accidental bookings and ensures user consent before writing to the database.
|
| 277 |
+
|
| 278 |
+
4. **🛡️ Safe Query Execution**
|
| 279 |
+
|
| 280 |
+
* Only **SELECT statements** generated by the LLM are allowed to be executed directly.
|
| 281 |
+
* INSERT/UPDATE operations (like booking a reservation) are handled by a **separate, controlled module**, protecting the database from unintended writes or corruption.
|
| 282 |
+
|
| 283 |
+
5. **📦 Iterative Prompt Optimization**
|
| 284 |
+
|
| 285 |
+
* Prompts have been fine-tuned through iterative experimentation and real conversation testing.
|
| 286 |
+
* Incorporated **few-shot examples** where relevant to guide the LLM.
|
| 287 |
+
* Prompts are designed to gracefully handle edge cases, e.g., when users give partial or ambiguous information.
|
| 288 |
+
|
| 289 |
+
6. **📏 Robust Format Enforcement & Cleaning**
|
| 290 |
+
|
| 291 |
+
* JSON outputs (e.g., for `store_user_info`) include explicit instructions on quoting keys/values to prevent parsing issues.
|
| 292 |
+
* Pre/post-processing logic strips any unexpected or extra text surrounding JSON responses from the LLM.
|
| 293 |
+
* Regular expressions and cleaning checks are used to sanitize LLM responses before using them in downstream logic.
|
| 294 |
+
|
| 295 |
+
7. **🌐 User-Centric Design**
|
| 296 |
+
|
| 297 |
+
* Prompts use natural, polite tone and context-aware replies, improving user trust and UX.
|
| 298 |
+
* Conversational flow shifts fluidly between transactional (booking) and informational (restaurant FAQs) based on detected intent, also handling **multiple-intent** cases.
|
| 299 |
+
|
| 300 |
+
---
|
| 301 |
+
|
| 302 |
+
|
| 303 |
+
### ⚠️ Error Handling & Edge Cases
|
| 304 |
+
|
| 305 |
+
This assistant is designed to offer a smooth and reliable user experience, even in unexpected scenarios. The following mechanisms are implemented to handle errors and edge cases effectively:
|
| 306 |
+
|
| 307 |
+
#### ✅ Error Handling
|
| 308 |
+
|
| 309 |
+
* **LLM Output Sanitization**:
|
| 310 |
+
When the LLM occasionally adds extra text before or after the expected response (e.g., in SQL queries), the output is parsed and cleaned using regex or string manipulation to extract only the required format. This ensures that unexpected formatting does not break the application.
|
| 311 |
+
|
| 312 |
+
* **Safe Execution with Try-Catch Blocks**:
|
| 313 |
+
All critical operations — especially SQL queries and bookings — are wrapped in `try-except` blocks. This prevents the UI from crashing and allows the assistant to gracefully inform the user about what went wrong.
|
| 314 |
+
|
| 315 |
+
* **Pre-Booking Availability Recheck**:
|
| 316 |
+
Just before finalizing a reservation, the system re-checks for table and slot availability. This is to prevent race conditions where multiple users might try to book the same slot at the same time — ensuring consistency and avoiding double bookings.
|
| 317 |
+
|
| 318 |
+
* **Preventive measures for malicious data injection/Database modification by prompt**:
|
| 319 |
+
The LLM does not directly execute SQL INSERT statements. Instead, it only interprets user intent, and can perform certain select queries to gather information. There is a dedicated backend module securely handles data injection for reservations , reducing the risk of malicious injection or malformed queries.
|
| 320 |
+
|
| 321 |
+
---
|
| 322 |
+
|
| 323 |
+
#### 🔍 Edge Cases
|
| 324 |
+
|
| 325 |
+
* **Random or Nonsensical User Input**:
|
| 326 |
+
If a user inputs irrelevant or nonsensical text (e.g., "asdf123", emojis, or spam), the assistant classifies it as an invalid intent (tagged as `RUBBISH`) and politely asks the user to rephrase or clarify their request.
|
| 327 |
+
|
| 328 |
+
* **Partial Reservation Information**:
|
| 329 |
+
When users provide only some details (e.g., name but not time), the assistant remembers the known information and continues the conversation by asking only for the missing fields, without repeating previously collected data.
|
| 330 |
+
|
| 331 |
+
* **Privacy Protection**:
|
| 332 |
+
Users cannot ask about bookings made by others. The SQL data access layer enforces this by exposing only the current user’s booking context. There is no direct query access to personal or third-party reservation data.
|
| 333 |
+
|
| 334 |
+
* **Restaurant Not Found**:
|
| 335 |
+
If the user provides a restaurant name that does not exist in the database, the assistant notifies them and may offer to show a list of available restaurants.
|
| 336 |
+
|
| 337 |
+
* **Unavailable Timeslots**:
|
| 338 |
+
If the requested time has no available tables (due to existing reservations), the assistant explains this clearly and suggests choosing a different time.
|
| 339 |
+
|
| 340 |
+
---
|
| 341 |
+
|
| 342 |
+
By handling these cases gracefully, the assistant ensures that users have a seamless experience even when unexpected situations arise.
|
| 343 |
+
|
| 344 |
+
|
| 345 |
+
|
| 346 |
+
|
| 347 |
+
|
| 348 |
+
|
| 349 |
+
|
| 350 |
+
|
| 351 |
+
## 🧭 Assumptions, Limitations & Enhancements
|
| 352 |
+
|
| 353 |
+
### Assumptions:
|
| 354 |
+
* There is a hardcoded 4-person table capacity, so the system itself selects multiple tables that are available at that time.
|
| 355 |
+
* Reservation slots are fixed to **2025-05-12**, and all reservations are for this date.
|
| 356 |
+
---
|
| 357 |
+
### ⚠️ Limitations:
|
| 358 |
+
|
| 359 |
+
* The system currently supports reservations only for a fixed date (2025-05-12). This could be extended to multi-day support by adding appropriate entries to the database.
|
| 360 |
+
* Since the system relies on Large Language Models (LLMs), there's **no absolute guarantee of perfect behavior**—LLMs can occasionally misinterpret queries, miss context, or produce inaccurate outputs.
|
| 361 |
+
* **Table preferences cannot be specified** by the user. The system auto-assigns tables based on availability, so users cannot choose specific table locations (e.g., window-side, outdoor, etc.).
|
| 362 |
+
* Only **select queries** are executed directly by the LLM to ensure **data safety**. For insert/update operations (e.g., booking), a separate transaction module is used.
|
| 363 |
+
|
| 364 |
+
|
| 365 |
+
---
|
| 366 |
+
### Future Enhancements:
|
| 367 |
+
|
| 368 |
+
* Expand the system to allow for multi-day reservations.
|
| 369 |
+
* Also add table preferences to choose(eg. beside window,private space).
|
| 370 |
+
* Add features like user authentication, personalized recommendations, and more sophisticated handling of party sizes and table combinations.
|
| 371 |
+
|
| 372 |
+
### 🔮 Future Enhancements in deployment
|
| 373 |
+
|
| 374 |
+
* ✅ Date picker and calendar integration
|
| 375 |
+
* 📲 SMS/WhatsApp confirmation with reservation ID
|
| 376 |
+
* 🧾 Admin dashboard to manage reservations & analytics
|
| 377 |
+
* 🌐 Multilingual support for non-English customers
|
| 378 |
+
* 🔌 API-first backend to support mobile and kiosk interfaces
|
| 379 |
+
|
| 380 |
+
---
|
| 381 |
+
|
| 382 |
+
|
| 383 |
+
|
| 384 |
+
## 📎 File Structure
|
| 385 |
+
|
| 386 |
+
```
|
| 387 |
+
├── app.py
|
| 388 |
+
├── tools.py
|
| 389 |
+
├── var.py
|
| 390 |
+
├── requirements.txt
|
| 391 |
+
├── Business Strategy Presentation/
|
| 392 |
+
│ ├── app.js
|
| 393 |
+
│ ├── index.html
|
| 394 |
+
│ ├── style.js
|
| 395 |
+
├── prompts/
|
| 396 |
+
│ ├── determine_intent.txt
|
| 397 |
+
│ ├── generate_reservation_conversation.txt
|
| 398 |
+
│ ├── interpret_sql_result.txt
|
| 399 |
+
│ ├── schema_prompt.txt
|
| 400 |
+
│ └── store_user_info.txt
|
| 401 |
+
├── db/
|
| 402 |
+
│ └── restaurant_reservation.db
|
| 403 |
+
└── README.md
|
| 404 |
+
```
|
| 405 |
+
|
| 406 |
+
### Explanation of Each File
|
| 407 |
+
|
| 408 |
+
#### 1. **`app.py`**
|
| 409 |
+
|
| 410 |
+
* The main application file that drives the restaurant reservation system.
|
| 411 |
+
* Handles user input, coordinates prompt usage, calls functional tools, executes SQL queries, and returns conversational responses.
|
| 412 |
+
* Acts as the central orchestrator between all components.
|
| 413 |
+
|
| 414 |
+
#### 2. **`tools.py`**
|
| 415 |
+
|
| 416 |
+
* Contains core utility functions used throughout the system.
|
| 417 |
+
* Includes logic for:
|
| 418 |
+
|
| 419 |
+
* Determining user intent
|
| 420 |
+
* Storing and updating user information
|
| 421 |
+
* Generating reservation-related conversations
|
| 422 |
+
* Creating and interpreting SQL queries
|
| 423 |
+
* Serves as the modular backend logic layer for reusable operations.
|
| 424 |
+
|
| 425 |
+
#### 3. **`var.py`**
|
| 426 |
+
|
| 427 |
+
* Defines classes and configuration variables.
|
| 428 |
+
* Includes:
|
| 429 |
+
|
| 430 |
+
* `SchemaVectorDB`: for handling schema-related semantic search
|
| 431 |
+
* `FullVectorDB`: for broader retrieval tasks using vector similarity
|
| 432 |
+
* Facilitates integration of ChromaDB and semantic retrieval workflows.
|
| 433 |
+
|
| 434 |
+
#### 4. **`prompts/` Folder**
|
| 435 |
+
|
| 436 |
+
Stores prompt templates that guide the behavior of the language model (LLM):
|
| 437 |
+
|
| 438 |
+
* **`determine_intent.txt`**:
|
| 439 |
+
Prompt for classifying user messages into intents like `greet`, `select`, `book`, or irrelevant.
|
| 440 |
+
|
| 441 |
+
* **`generate_reservation_conversation.txt`**:
|
| 442 |
+
Handles multi-turn interactions to collect user details and guide reservations.
|
| 443 |
+
|
| 444 |
+
* **`interpret_sql_result.txt`**:
|
| 445 |
+
Formats raw SQL query results into natural-sounding responses.
|
| 446 |
+
|
| 447 |
+
* **`schema_prompt.txt`**:
|
| 448 |
+
Describes the SQLite database schema and provides rules for query generation.
|
| 449 |
+
|
| 450 |
+
* **`store_user_info.txt`**:
|
| 451 |
+
Extracts and stores user details like name, contact info, party size, and reservation time.
|
| 452 |
+
|
| 453 |
+
#### 5. **`db/` Folder**
|
| 454 |
+
|
| 455 |
+
* Contains the SQLite database (`restaurant_reservation.db`) with all restaurant, table, and reservation information.
|
| 456 |
+
* Used to run SQL queries for booking and retrieving restaurant details.
|
| 457 |
+
|
| 458 |
+
---
|
| 459 |
+
|
| 460 |
+
|
| 461 |
+
|
| 462 |
+
## 📊 Vertical Expansion
|
| 463 |
+
|
| 464 |
+
This solution can be adapted for:
|
| 465 |
+
|
| 466 |
+
* ✈️ Airlines (seat booking assistants)
|
| 467 |
+
* 🏥 Clinics & Hospitals (appointment schedulers)
|
| 468 |
+
* 🎟️ Event Ticketing Systems (concerts, sports, etc.)
|
| 469 |
+
* 🏨 Hotels (room booking, amenities)
|
| 470 |
+
|
| 471 |
+
---
|
| 472 |
+
|
| 473 |
+
## 🥇 Competitive Advantages
|
| 474 |
+
|
| 475 |
+
1. 🔁 Multi-turn conversation memory (session-state-based and intent based)
|
| 476 |
+
2. 🧠 Contextual intent handling with seamless switching between FAQ and transactional flows
|
| 477 |
+
3. 📦 Modular LLM prompt architecture for future scaling
|
| 478 |
+
4. 🔒 Secure and Controlled SQL Access
|
| 479 |
+
Only read-only SQL (SELECT) statements are generated and executed via the LLM to prevent any risk of data corruption.
|
| 480 |
+
Reservation actions like INSERT or UPDATE are handled securely in a separate logic module, ensuring strict control over data modification.
|
| 481 |
+
|
| 482 |
+
---
|
| 483 |
+
|
| 484 |
+
## 📅 Implementation Timeline
|
| 485 |
+
|
| 486 |
+
| Phase | Description | Duration |
|
| 487 |
+
| ------- | -------------------------------------- | -------- |
|
| 488 |
+
| Phase 1 | Database creation+LLM sql query creation and interpretation | 1st day |
|
| 489 |
+
| Phase 2 | Intent detection+conversational flow | 1st day |
|
| 490 |
+
| Phase 3 | Booking and edge-case handling | 2nd day |
|
| 491 |
+
| Phase 4 | Presentation & packaging | 2nd day |
|
| 492 |
+
|
| 493 |
+
---
|
| 494 |
+
|
| 495 |
+
## 👥 Key Stakeholders
|
| 496 |
+
|
| 497 |
+
* Restaurant Manager / Owner
|
| 498 |
+
* Frontdesk / Host
|
| 499 |
+
* Customer Service Ops
|
| 500 |
+
* Technical Dev Team
|
| 501 |
+
|
| 502 |
+
---
|
| 503 |
+
|
| 504 |
+
|
| 505 |
+
|
| 506 |
+
|
| 507 |
+
|
| 508 |
+
|
| 509 |
+
|