Thessaloniki Travel Guide (RASA chatbot)

This chatbot was created as part of the course 'Special Topics in Language Technology: Multimodal and Dialogue Systems and Voice Assistants' as part of the MSc Language Technology.

When someone visits a new city for some purpose, they may not want to spend a lot of time browsing through Google, TripAdvisor etc. for things to do there; they might just want a quick, personalized but also reliable recommendation of something they will definitely enjoy. This chatbot solves this issue by getting some basic information from the user such as why they're traveling, who they're traveling with, their interests etc. and quickly giving them a few personalized options for what they can do in Thessaloniki, to choose from. It is task-oriented, as it is a recommendation chatbot, and belongs to the domain of travel and tourism.

Implemented Scenarios

Scenario 1: The user asks for a recommendation for a later date

• The chatbot greets the user and begins running the form to collect the following slots: trip type, visit date, group type, interests.
• Once these are collected, it submits the form, then runs action_resolve_visiting_time to determine if the visit is close (within 1 week) or at a later date, and sets the visit season.
• It then runs action_confirm_trip_details, repeating the user's details back to them for confirmation. If there has been a mistake, the form restarts.
• After that, it runs action_filter_candidates to filter the candidate activities of the mockup excel database based on the user's constraints (mainly interests, group type and visit season) and returns the matching ones.
• Lastly, it runs action_generate_response, randomly picking 3 of the matching activities and presenting them to the user.

Scenario 2: The user asks for a recommendation for a closer date (within 1 week)

• In this scenario, after the user's details are confirmed through action_confirm_trip_details, the chatbot runs action_get_weather, requesting the weather in Thessaloniki through the OpenMeteo daily forecast API for the particular day the user is visiting, retrieved from the offset days slot (for example, if the user said 'I'm visiting in 3 days', the offset days will be 3).
• The only value we care about here is 'rainy' or 'not_rainy', which will later further constraint the activities in action_filter_candidates.

Scenario 3: The user has a follow-up question about the recommendations

• After a recommendation has been given via action_generate_response, the user may have follow-up questions, such as "What is the address of these places?" or "How are these places rated?".
• In this case, the chatbot answers by returning the additional information (again through action_generate_response).

Integrated Data Sources

This chatbot integrates two main data sources:

• Curated activity database (excel mock dataset): This is a manually curated Excel file used as the primary knowledge base of activities in Thessaloniki. Each entry includes structured attributes such as activity name, description, group type, trip type, seasonality, weather constraints, interests, Google rating and address. By using a structured, local dataset in this stage of the project, we can have deterministic filtering based on user constraints, which ensures reliability and transparency in returned recommendations. It is furthermore easy to replace or to extend with a real database in the future.

• OpenMeteo daily forecast API (short-term forecast): A weather API is used to retrieve current or near-future weather conditions, when the user’s visit is imminent (e.g., 'now', 'this weekend', 'in 2 days'). The weather is abstracted into simple labels (rainy / not rainy) and used as an additional constraint during candidate filtering. The rationale behind this is that some activities in the database (e.g. Cine Ellinis) are suited for clear weather. Incorporating real-time weather thus enables more context-aware recommendations without overcomplicating the system.

Challenges faced during implementation and how they were addressed

• Reliability and controllability of LLM-based NLG: Initially, action_generate_response was implemented using a Microsoft Azure-hosted LLM. In practice, this approach proved unreliable: the same configuration could work on one day and fail on another due to backend changes or model-specific limitations. Moreover, safety mechanisms prevented the model from answering follow-up questions with factual details (e.g., addresses of venues), even when this information was explicitly provided in the input data. Therefore, the NLG component was redesigned so that the recommendation logic and factual responses are handled deterministically using a structured, rule-based approach grounded in the activity database.

• Ambiguity between confirmation and follow-up intents (affirm / deny): A key dialogue-management challenge arose from the dual meaning of affirm and deny: they can indicate either (a) confirmation or correction of form-collected user constraints, or (b) agreement or disagreement in the context of follow-up questions after recommendations have been presented. This ambiguity was resolved by introducing a boolean slot (has_recommendation) that tracks whether a recommendation has already been given. When has_recommendation is false, affirm and deny are interpreted as confirmation or correction of the collected form slots. Once a recommendation has been issued (has_recommendation = true), the same intents are interpreted in the context of follow-up questions, thus ensuring coherent dialogue flow.

Example Use