Service interaction method, method for realizing travel route planning and corresponding device

Abstract

The embodiment of the invention discloses a service interaction method, a method for realizing itinerary planning and a corresponding device. The service interaction method comprises the following steps: acquiring travel route planning description input by a user through a session interface; displaying state information of a plurality of stage tasks in the process of generating the itinerary planning document on the session interface, the plurality of stage tasks at least comprise a first stage task for analyzing the itinerary planning description to obtain constraint conditions of multiple dimensions; searching based on the constraint condition to obtain a second-stage task of service data corresponding to a plurality of itinerary elements, and generating a third-stage task of itinerary planning documents meeting the constraint condition based on the service data; and obtaining and displaying the itinerary planning document on the session interface. The itinerary planning document can be automatically generated based on the itinerary planning description input by the user, and the transparency and experience of the user interaction process are improved.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and information service technology, and in particular to a service interaction method, a method for implementing itinerary planning, and a corresponding apparatus. Background Technology

[0002] With the rapid development of artificial intelligence and information service technologies, intelligent assistant services are evolving from simple information retrieval to in-depth life services. Users may have itinerary planning needs in various scenarios such as travel, event organization, and business trips, requiring them to switch between multiple platforms to browse information and manually plan their trips. For example, checking attraction locations and routes on map apps, comparing prices on ticketing apps, finding restaurants on food apps, and finding and comparing accommodations on accommodation apps, etc. This is clearly inefficient and results in a poor user experience. Summary of the Invention

[0003] In view of this, this application provides a service interaction method, a method for implementing itinerary planning, and a corresponding device to improve user efficiency and user experience.

[0004] This application provides the following solution: A first aspect of this application provides a service interaction method, including: Obtain the trip planning description entered by the user through the chat interface; The session interface displays the status information of multiple stages of tasks during the generation of the itinerary planning document. These multiple stages include at least the following: the first stage task, which parses the itinerary planning description to obtain constraints in multiple dimensions; the second stage task, which searches for service data corresponding to multiple itinerary elements based on the constraints; and the third stage task, which generates an itinerary planning document that meets the constraints based on the service data. Retrieve and display the itinerary planning document in the chat interface.

[0005] In some embodiments, the status information of multiple stages of tasks during the generation of the itinerary planning document is displayed in the session interface, including: Obtain the execution status of each stage of the task and the execution status of the subtasks contained in each stage of the task; In response to obtaining information about the currently executing stage task and its subtasks, visual elements indicating the execution of the stage task are displayed for the node corresponding to the currently executing stage task, and an extended area is displayed at the node corresponding to the currently executing stage task, where information about the currently executing subtasks is displayed. In response to the completion of the currently executing phase task, the display area is hidden and the visual element is updated to indicate that the phase task has been completed.

[0006] In some embodiments, the execution progress information of the corresponding stage task is displayed in the display area corresponding to each node, including: Obtain the execution status of each stage of the task and the execution status of the subtasks contained in each stage of the task; In response to obtaining information about the currently executing stage task and its subtasks, an extended area is displayed at the node corresponding to the currently executing stage task, and information about the currently executing subtasks is displayed in the extended area.

[0007] In some embodiments, information about the currently executing subtask is displayed in the extended area, including: In response to an update of the currently executing subtask, the updated currently executing subtask is displayed at a preset position in the extended area, and the completed subtask is scrolled away from the preset position.

[0008] In some embodiments, the method further includes: For each completed stage task, the corresponding first component is displayed. In response to the operation that triggers the first component, an extended area is displayed at the node corresponding to the triggered first component. The extended area includes information about the subtasks contained in the corresponding stage task. In response to the action of triggering the first component again, hide the extended area.

[0009] In some embodiments, the information of the subtasks displayed in the extended area includes at least one of the following: The subtask description information, the information on calling external service system interfaces, and the second component, which is used to trigger the display of the execution result data of the corresponding subtask; The execution result data of the subtasks in the second phase of the task includes: service data corresponding to multiple process elements obtained by calling the external service system interface; The execution result data of the subtasks in the third phase task includes at least one of the following: The code used to integrate service data; A trip planning and analysis report based on service data; HTML code for a trip planning document generated from a trip planning analysis report.

[0010] In some embodiments, displaying a trip planning document in the session interface includes: The session interface displays a trip summary and a trip card, with the trip card including a third component; In response to the operation that triggers the third component, the user is redirected to the trip planning page, which includes: trip description information, a visual map area showing the routes of each time unit in the trip, a list of trip elements for each time unit in the trip, service acquisition components corresponding to the trip elements in the list of trip elements, and trip budget information. The service acquisition component is used to trigger the display of the service acquisition page for the corresponding trip element.

[0011] A second aspect of this application provides a method for implementing itinerary planning, including: In response to the trip planning description sent by the user, the large model is invoked to execute multiple stage tasks and synchronize the status information of each task stage to the user; these multiple stage tasks include: The itinerary planning description is analyzed to obtain constraints in multiple dimensions; Based on the constraints, service data corresponding to multiple trip elements can be obtained through search. Based on the service data corresponding to multiple trip elements, a trip planning document that meets the constraints is generated.

[0012] In some embodiments, a trip planning document that meets constraints is generated based on service data corresponding to multiple trip elements, including: Based on constraints, call the interface of an external service system to search for reference itineraries in order to generate a planning schedule; Based on service data and planning schedules corresponding to multiple trip elements, a trip planning analysis report is generated. HTML code for generating a travel planning document based on the travel planning analysis report.

[0013] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application, after obtaining the user-input itinerary planning description, automatically executes multiple stages of tasks, including parsing multidimensional constraints, searching service data for multiple itinerary elements, and generating a planning document, and displays the status information of each stage of the task to the user in real time. Therefore, this application can automatically generate personalized itinerary planning documents that conform to multidimensional constraints based on the user-input itinerary planning description, effectively improving the feasibility and generation efficiency of itinerary planning, and enhancing the transparency and experience of the user interaction process.

[0014] Of course, any product implementing this application does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a system architecture diagram applicable to the embodiments of this application.

[0017] Figure 2 A flowchart illustrating the service interaction method provided in this application embodiment.

[0018] Figure 3 This is a schematic diagram of a session interface for displaying an authorization request from an external service system, provided as an embodiment of this application.

[0019] Figure 4 This is a schematic diagram of a session interface for displaying clarification statements, provided as an embodiment of this application.

[0020] Figure 5 This is a schematic diagram of a session interface that displays task status information at each stage via a progress axis, as provided in an embodiment of this application.

[0021] Figure 6 This is a schematic diagram of a session interface for an extended area corresponding to a display node provided in an embodiment of this application.

[0022] Figure 7 This is a schematic diagram of another session interface for the extended area corresponding to the display node provided in the embodiments of this application.

[0023] Figure 8 This is a schematic diagram of another session interface for the extended area corresponding to the display node provided in the embodiments of this application.

[0024] Figure 9 This is a schematic diagram of a session interface for displaying a summary view of a trip planning document, provided as an embodiment of this application.

[0025] Figure 10 This is a schematic diagram of a trip planning page provided in an embodiment of this application.

[0026] Figure 11 This is a flowchart illustrating a method for implementing trip planning provided in an embodiment of this application.

[0027] Figure 12 A schematic block diagram of a service interaction device provided in an embodiment of this application.

[0028] Figure 13 A schematic block diagram of an apparatus for implementing trip planning provided in an embodiment of this application.

[0029] Figure 14 A schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0031] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0032] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0033] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0034] To facilitate understanding of this application, the system architecture on which this application is based will be described first. Figure 1 An exemplary system architecture that can be applied to embodiments of this application is shown, such as Figure 1 As shown, the system architecture may include: a client and a server.

[0035] The client and server are the two main components of an application service. The server side uses a server as its primary hardware infrastructure and may include one or more software service modules. The server and client form a collaborative front-end and back-end. The client can be a client application running on a user's terminal, a mini-program, or a web application running through a browser.

[0036] The user terminal can include, but is not limited to, smart mobile terminals, wearable devices, and PCs (Personal Computers). Smart mobile devices can include mobile phones, tablets, PDAs (Personal Digital Assistants), and connected car terminals. Wearable devices can include smartwatches, smart glasses, smart bracelets, VR (Virtual Reality) devices, AR (Augmented Reality) devices, and mixed reality devices (devices that support both virtual and augmented reality), etc.

[0037] The server can be a standalone server, a server cluster, or a cloud server. A cloud server, also known as a cloud computing server or cloud host, is a hosting product within the cloud computing service system, designed to address the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) services, such as high management difficulty and weak service scalability.

[0038] One possible approach is to provide a user-facing interface where the user inputs a travel itinerary description. After receiving the description, the user-facing client uses the service interaction method provided in this embodiment to interact with the user and ultimately display the travel itinerary document. The server uses the travel itinerary planning method provided in this embodiment to generate a travel itinerary document based on the description and sends it to the user-facing client for display. The server-side process of generating the travel itinerary involves calls to external service system interfaces and large-scale models.

[0039] Large Language Models (LLMs) are deep learning models trained on massive amounts of text data, capable of generating natural language text or understanding the meaning of language text. They are characterized by their enormous scale and massive number of parameters (typically exceeding tens of billions), and are usually based on deep learning architectures such as the Transformer architecture. The difference between LLMs and ordinary pre-trained language models lies in the scale of their parameters. When the parameter scale exceeds a certain level, the model achieves significant performance improvements and exhibits capabilities that smaller models lack, such as in-context learning capabilities, the ability to learn complex patterns in language, and the performance of a wide range of tasks. Therefore, to distinguish them from traditional pre-trained language models, models with a parameter scale exceeding a certain level are called LLMs. In general, language models with a parameter scale exceeding tens of billions implemented based on deep learning architectures can be considered large language models.

[0040] It should be understood that Figure 1 The number of client-side, server-side, external service systems, and large models shown is merely illustrative. Depending on implementation needs, there can be any number of client-side, server-side, external service systems, and large models.

[0041] Figure 2 This is a flowchart of a service interaction method provided in an embodiment of this application. This method can be... Figure 1 The user-side execution in the system shown is as follows. Figure 2 As shown, the method may include the following steps: Step 201: Obtain the itinerary planning description entered by the user through the session interface.

[0042] Step 203: Display the status information of multiple stages of tasks in the process of generating the itinerary planning document on the session interface. The multiple stages of tasks include at least the following: the first stage task of parsing the itinerary planning description to obtain constraints in multiple dimensions; the second stage task of calling the external service system interface based on the constraints to search for service data corresponding to multiple itinerary elements; and the third stage task of calling the large model based on the service data to generate an itinerary planning document that meets the constraints.

[0043] Step 205: Obtain and display the itinerary planning document in the chat interface.

[0044] As can be seen from the above process, this application can automatically generate personalized itinerary planning documents that meet multi-dimensional constraints based on the user's input itinerary planning description, which effectively improves the feasibility and generation efficiency of itinerary planning. Furthermore, by displaying the status information of multiple stages in the process of generating itinerary planning documents in the session interface, the user interaction feedback of the background task has been improved, realizing a clear, real-time and predictable interaction effect in the itinerary planning document generation scenario, thereby improving the transparency and experience of the user interaction process.

[0045] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments. It should be noted that the terms "first" and "second" involved in this disclosure do not have limitations in terms of size, order, or quantity, but are only used to distinguish them in name. For example, "first dialogue voice" and "second dialogue voice" are used to distinguish two voices.

[0046] First, the above step 201, namely "obtaining the itinerary planning description input by the user through the session interface", will be described in detail with reference to the embodiments.

[0047] In this application, "conversational interface" refers to any graphical user interface that enables multi-round information interaction between a user and a server-side intelligent system. Examples include, but are not limited to, chat windows in instant messaging applications, visual feedback panels in voice assistants, or intelligent customer service dialog boxes in web pages.

[0048] Users can express their needs by inputting natural language descriptions through the chat interface. The server identifies the needs based on the natural language descriptions input by the user. If it identifies a need for itinerary planning, it confirms that the natural language description is an itinerary planning description.

[0049] After obtaining the itinerary description input by the user through the chat interface, the system can further display authorization requests for external service systems within the chat interface. These external service systems refer to the systems invoked during the generation of the itinerary planning document, providing various underlying data and service capabilities for the itinerary planning. These include, but are not limited to: map service systems providing geographic information, points of interest data, route planning, and navigation capabilities; ticketing and booking service systems providing information and interfaces for transportation tickets, attraction tickets, hotel and restaurant bookings; local lifestyle service systems providing richer information on local merchants, activities, and user reviews; and social media service systems providing abundant UGC (User Generated Content) data, such as travel guides, itineraries, travelogues, and hand-drawn route maps. The server can obtain real-time and accurate service data by calling the application programming interfaces (APIs) of these external service systems.

[0050] For example Figure 3 As shown, when a user inputs "A 4-day travel plan for city A in February, including one weekend, with a budget of 10,000 yuan, I like historical sites, food, and want to visit trendy shopping districts," the system recognizes that this natural language description indicates a travel planning need and displays authorization requests for map service system B and ticketing and booking service system C in the form of a card component. This card component can include authorization description information and interactive elements to trigger authorization.

[0051] Furthermore, the user-input itinerary planning description may contain vague information or missing information dimensions. Therefore, in this embodiment, the user-input itinerary planning description can be parsed to obtain planning requirement information, and then further clarified based on the user-input planning requirement information. One possible approach is to pre-set multiple requirement types with different information dimensions. The server matches the obtained planning requirement information with the pre-set requirement types and determines whether to generate a clarification statement based on the matching requirement types. A matching requirement means that the planning requirement information belongs to a specific requirement type and the requirement is clear. If the matching requirement types do not meet preset requirements, such as the number of matching requirement types being less than a preset threshold, a clarification statement can be generated using the unmatched requirement types. The server sends the clarification statement to the user, who then displays it on the session interface. Then, in response to the user's input of supplementary requirement descriptions for the clarification statement, the supplementary requirement descriptions are parsed to obtain supplementary requirement information, and the planning requirement information is updated using this supplementary requirement information.

[0052] The aforementioned clarification statements can be one or more, and can be presented to the user in one round of dialogue or through multiple rounds of dialogue. Preset demand types may include, for example: departure city, budget plan, accommodation preferences, interest preferences, itinerary pace, indoor / outdoor preferences, and taboos.

[0053] like Figure 4 As shown, based on the user's input of the itinerary description, a clarifying statement can be generated: "Received! I will help you check. To generate a plan that better suits your needs, I would like to confirm the following details beforehand: 1. What are the specific travel dates? Are they fixed? 2. What is your hotel budget? 3. What is your priority among historical sites: Site 1, Classic Site 2, Site 3, Site 4...? 4. What are your food preferences? Do you have any allergies? 5. Do you prefer a relaxed, spontaneous trip or a tightly packed itinerary? Do you enjoy taking photos and checking in on social media?" Users can further input supplementary descriptions of their needs, such as "Not fixed, just comfortable, around 500 yuan. I'm open to everything except Site 3. I want to eat Peking duck and Zha Jiang Mian (noodles with soybean paste), but I don't eat pork. I prefer a more compact itinerary, preferably with some photo spots."

[0054] The following describes step 203, namely "displaying the status information of multiple stages of tasks in the process of generating the itinerary planning document in the session interface", in detail with reference to the embodiments.

[0055] In this application, the server can generate a trip planning document by executing multiple phased tasks. These multiple phased tasks include at least: a task to parse the trip planning description to obtain constraints in multiple dimensions, referred to as the first phase task; a task to call an external service system interface based on the constraints to search for service data corresponding to multiple trip elements, referred to as the second phase task; and a task to call a large model based on the service data to generate a trip planning document that meets the constraints, referred to as the third phase task.

[0056] The tasks described above can be further divided into coarser or finer-grained stages. For example, the third stage can be broken down into tasks such as generating a planning schedule based on constraints and service data, generating an itinerary planning analysis report based on service data and the planning schedule, and generating HTML code for an itinerary planning document based on the itinerary planning analysis report. The specific processing for each stage will be detailed in subsequent server-side embodiments.

[0057] Since generating itinerary planning documents is a time-consuming process, if users are in a state of waiting without feedback during this time, they cannot know which stage the task is at or what each stage is doing, which can easily lead to anxiety or a desire to give up, severely impacting the user experience and service reliability. Therefore, this step breaks down the continuous, user-invisible backend processing flow into multiple logically continuous and predefined stage tasks, and proactively and structurally pushes the execution status information of each stage task to the frontend conversation interface for display.

[0058] When displaying the status information of multiple stages of tasks in the process of generating a travel planning document in the conversation interface, one possible approach is to obtain the description information and execution progress information of multiple stages of tasks in the process of generating a travel planning document; display a progress axis containing multiple nodes in the conversation interface, with each node corresponding to a stage of task; display the execution progress information of the corresponding stage of task in the display area corresponding to each node; and display the description information of the corresponding stage of task for each node.

[0059] A progress axis is an intuitive visual representation that combines a linear time concept with a logical sequence of stages (i.e., a sequence of multiple stage tasks). Each node represents a stage task, and the order of the nodes reflects the logical sequence of execution of each stage task. By displaying stage task descriptions next to or within nodes, users can immediately understand the purpose of each stage. Displaying execution progress information dynamically reflects the completion status of the stage task.

[0060] like Figure 5As shown, a card component can be displayed, containing a progress axis with three nodes, each corresponding to a stage task. The execution status of the stage task can be indicated by the visual elements corresponding to the nodes, such as... Figure 5 As shown, the nodes corresponding to the unexecuted phase task 3 are represented by numbers, the nodes corresponding to the currently executed phase task 2 are represented by a progress ring, and the nodes corresponding to the completed phase task 1 are represented by checkmarks.

[0061] This approach allows information to be organized in a highly structured, time-sequential visual format, giving users a clear overview of the overall process and current progress, significantly reducing cognitive load.

[0062] The methods for displaying the status information of multiple stages of a task are not limited to a progress axis. For example, they may include, but are not limited to: displaying each stage in a side-by-side list of cards, with the status updated within each card; displaying it as a step bar; or dynamically updating the status of each task in a list format within a separate floating panel. All of these solutions can achieve the function of mapping the status of multiple stages of tasks in the background to the front-end interface for display.

[0063] To further refine the granularity of status display and allow users to understand the more specific work being done within the current stage, one possible approach is to obtain the execution status of tasks in each stage and the execution status of subtasks contained within each stage task. In response to obtaining information about the currently executing stage task and its subtasks, an extended area is displayed at the node corresponding to the currently executing stage task, and information about the currently executing subtasks is displayed in the extended area.

[0064] This approach allows status feedback to delve into the internal execution details of each stage of the task. For example... Figure 6 As shown, when the second-stage task is in progress, its description information, "Search service data," can be displayed at the corresponding node. Furthermore, information about the currently executing subtasks can be displayed through the expanded area at the node. If a subtask involves calling an external service system interface, this can be indicated using the external service system's icon or text, such as "Using map service system B to search for popular attractions in city A," "Using reservation service system C to search for popular restaurants in city A," "Using ticketing service system D to search for transportation information," and so on. Simultaneously, visual elements can be used to display the subtask's execution progress at the node of the currently executing stage task, for example... Figure 6 The node corresponding to the intermediate stage task 2 can be displayed using visual elements to show that the third of the five subtasks has been executed.

[0065] In this way, users can not only know that a task is in progress at a certain stage, but also see the specific sub-tasks being executed through an expanded area. This provides greater transparency, allowing users to perceive the specific content of the system's work and further enhancing the user experience.

[0066] When displaying subtask information in the extended area, the subtask information may be dynamically updated. In order to present this dynamic update process clearly and orderly, and to avoid visual confusion caused by the stacking of old and new information, as a preferred implementation, in response to the update of the currently executing subtask, the updated currently executing subtask can be displayed at a preset position in the extended area, and the completed subtask can be scrolled away from the preset position.

[0067] For example Figure 7 As shown, when the currently executing subtask is updated, all currently executing subtasks will be displayed in the extended area. Figure 7 In (a), the area outlined by the dashed line is the bottom of the extended area corresponding to the node of stage task 2. If the currently executing subtask is "Searching for popular restaurants in city A using the reservation service system C", the displayed session interface will look like this. Figure 7 As shown in (a). After a period of time, the currently executing subtask is updated to "Searching for transportation information using ticketing service system D". The information of this subtask is then inserted into a preset position, and the already executed subtasks scroll up. Among them, due to the limitation of the expanded area size, the information "Searching for popular attractions in city A using map service system B" scrolls out of the display area and is hidden.

[0068] This approach consistently guides the user's visual focus to the latest dynamic information (i.e., information about the currently executing subtask), while retaining temporary historical records for future reference. The interface update logic is clear and dynamic.

[0069] When a task at a certain stage is completed, its status representation on the interface needs to be explicitly updated, and the extended area generated to display dynamic details needs to be cleaned up. Therefore, as a further implementation, in response to the completion of the currently executing task at a certain stage, the display area can be hidden, and the visual element on the progress axis indicating the corresponding node can be updated to the visual element indicating that the task at that stage has been completed.

[0070] The system retrieves the execution status of a stage task and triggers two UI update operations upon completion. First, it hides the extended area corresponding to that stage task, as all dynamic subtasks within it have finished, making continued display unnecessary and potentially disruptive to the interface and resource-intensive. Second, it updates the visual appearance of the corresponding node on the progress axis, for example, changing the node's color from blue for "in progress" to green for "completed," or changing the icon from a rotating progress ring to a checkmark.

[0071] This approach provides users with clear and unambiguous signals of stage completion, while minimizing unnecessary information display that interferes with the session interface and consumes resources, thus allowing users to easily follow the progress of stage tasks.

[0072] Since the extended area corresponding to a node is collapsed after the phase task is completed, but considering that users may want to review the specific execution details of the completed phase task, this application embodiment also provides a further interaction mechanism. For the node corresponding to the completed phase task, its corresponding first component is displayed; in response to the operation of triggering the first component, an extended area is displayed at the node corresponding to the triggered first component, the extended area including information about the subtasks contained in the corresponding phase task; in response to the operation of triggering the first component again, the extended area is hidden.

[0073] The first component can be a clickable icon, button, or text link that corresponds to a node, for example... Figure 8 The component shown in (a) is used to trigger the display of subtask details for the corresponding task stage. By default, the expanded area for completed tasks is hidden, maintaining a clean interface. When a user wants to view the subtask details for a specific task stage, they can trigger the first component of the corresponding node to reopen the expanded area for that task stage and view the recorded historical subtask execution information. Triggering it again will collapse the expanded area. If the user clicks... Figure 8 Following the first component shown in (a), as Figure 8 As shown in (b), expand the extended area to display the historical subtasks executed under this stage of the task.

[0074] This approach provides users with a mechanism to trace historical subtasks, enabling the on-demand display and hiding of extended areas, balancing information traceability with interface cleanliness, and further improving the user experience.

[0075] Whether during or after the execution of a phase task, the subtask information displayed in the extended area can contain rich content to provide more insights and value. As one possible approach, the subtask information displayed in the extended area can include at least one of the following: a description of the subtask, information about calls to external service system interfaces, and a second component used to trigger the display of the corresponding subtask's execution result data.

[0076] The description information of a subtask can be such as "searching for popular restaurants in city A", "searching for transportation information", "generating a travel itinerary", "executing Python code", etc.

[0077] Information about calling external service system interfaces can be displayed in text format, such as "Using Reservation Service System C" or "Using Ticketing Service System D". It can also be displayed using icons of the external service systems, or in other formats.

[0078] The second component can take many forms, such as buttons, icons, and text links. For example... Figure 8 As shown in (b), a text box containing a text link can be used. When the user triggers the second component, the execution result data of the corresponding subtask can be displayed.

[0079] The execution result data of the subtasks in the second phase of the task may include, for example, service data corresponding to multiple process elements obtained by calling external service system interfaces. Figure 7 As shown in (b), if a user clicks "Using the reservation service system C to search for popular restaurants in city A", a list of popular restaurants obtained from the search will be displayed.

[0080] The execution result data of the subtasks in the third phase of the task may include at least one of the following: the code used to integrate service data; the itinerary planning analysis report based on the service data; and the HTML code of the itinerary planning document generated based on the itinerary planning analysis report.

[0081] For example Figure 8 As shown in (b), if the user clicks "Generating Travel Itinerary," the generated travel itinerary will be displayed. If the user clicks "Executing Python Code," the Python code used to integrate service data will be displayed. If the user clicks "Generating Trip Analysis Report," the trip planning analysis report obtained based on the service data will be displayed. If the user clicks "Generating HTML Four-Day Travel Plan for City A," the corresponding HTML code for that travel plan will be displayed.

[0082] As can be seen, the extended area not only shows users what the system is doing, but also how it's doing it and what has been accomplished. This provides users with detailed execution result data, helping them understand the specific basis for generating the itinerary planning document, thereby enhancing interpretability and user trust, and improving the user experience.

[0083] The following describes step 205, namely "obtaining and displaying the itinerary planning document in the session interface", in detail with reference to the embodiments.

[0084] Once all phases of the task have been completed, the server generates the final itinerary planning document and sends it to the user's client. The user then displays this document in the session interface. This is the final output of the entire service interaction.

[0085] Trip planning documents can be presented in one or more formats, such as text, tables, and images, or any combination thereof. They can go beyond simply presenting text; they can provide a fully functional and interactive action guide.

[0086] One possible approach is to display a trip summary and trip cards in the session interface. The trip cards include a third component. In response to triggering the third component, the user is redirected to a trip planning page. The trip planning page includes: trip description information, a visual map area displaying the routes for each time unit of the trip, a list of trip elements for each time unit of the trip, service acquisition components corresponding to the trip elements in the list of trip elements, and trip budget information. The service acquisition components are used to trigger the display of the service acquisition page for the corresponding trip element.

[0087] like Figure 9 As shown, after generating the itinerary planning document, an itinerary summary and itinerary cards can be displayed on the conversation interface, forming a concise overview view. The itinerary card can display the title of the itinerary planning document, cover image, and a third component. If the user wants to view the details of the itinerary planning document, they can jump to the specific itinerary planning page through the third component. This two-level display method takes into account both overview and details, which is more in line with the lightweight interaction habits of the conversation interface.

[0088] The itinerary planning page itself is a structured document, and its HTML code can be generated by calling a large model. The itinerary planning page includes itinerary description information, such as... Figure 10 As shown in (a).

[0089] The process of generating the itinerary planning document involves several steps. First, based on constraints, an external service system interface is invoked to search for reference itineraries to generate a planned schedule. Then, based on service data corresponding to multiple itinerary elements and the planned schedule, a large-scale model is invoked to generate an itinerary planning analysis report. Finally, based on the itinerary planning analysis report, the large-scale model is invoked to generate the HTML code for the itinerary planning document. The planned schedule is essentially a structured schedule divided into time units based on the reference itinerary, containing a list of itinerary elements and their service data for each time unit. The itinerary planning analysis report is a structured analysis report generated based on the planned schedule and the service data of the itinerary elements, considering factors such as rationality, cost, and user preferences. Finally, the large-scale model is invoked to generate the HTML code for the itinerary planning document.

[0090] The HTML code reserves a map container to display a visualized map area. The routes displayed in this visualized map area are generated based on route information for each time unit. Furthermore, interactive controls can be provided within the visualized map area, allowing users to select the route for the target time unit to be displayed. At this point, the service system interface can be called to retrieve the map data corresponding to that route, and the data can be rendered and displayed in real time within the visualized map area.

[0091] Furthermore, when calling the HTML code to generate the itinerary planning document from the large model, the itinerary elements can be presented as card components in the HTML code based on the list of itinerary elements for each time unit and the service data of the itinerary elements. In addition to descriptions and images of the itinerary elements, each card also includes a service retrieval component (in the form of an interactive control). The itinerary element cards are organized and arranged by time unit. The service retrieval component embeds an external service system interface. When the itinerary planning page is displayed, if an event triggering the service retrieval component is detected, the external service system interface is called to retrieve service pages provided by the external service system, such as ticket purchase pages or accommodation reservation pages.

[0092] If a user triggers the display of the itinerary planning page (i.e., a page-based itinerary planning document), the HTML code is parsed, and dynamic rendering is performed based on the parsing results. In response to obtaining a map container from the HTML code, a visual map area is displayed within the map container. This visual map area includes interactive controls corresponding to each time unit. These interactive controls, when triggered, call external service system interfaces to retrieve map data for the corresponding time unit's route, and then render and display this map data within the visual map area. In response to obtaining a itinerary element card from the HTML code, the itinerary element card is rendered. This itinerary element card may include a service retrieval component. When triggered, this service retrieval component calls external service system interfaces to retrieve corresponding service page data, and then renders and displays the service page based on this service page data.

[0093] Because the HTML code contains a map container and cards representing various itinerary elements organized by time unit, the HTML code can be parsed and dynamically rendered in real time based on the screen size. The length of the itinerary planning page may exceed the screen size; users can trigger rendering sequentially according to the scrolling direction by scrolling the page. For example, assuming the current rendering is of a visual map area, the visual map area will be displayed in the map container. If the user selects a route for a target time unit using interactive controls provided in the visual map area, the service system interface will be called to retrieve the map data corresponding to that route, and it will be rendered and displayed in real time in the visual map area. As another example, assuming the current rendering is of a card representing an itinerary element, the card and its included text, images, or service retrieval components will be rendered and displayed. If the user clicks on the service retrieval component corresponding to that itinerary element, such as clicking the ticket purchase component for attraction B, the ticketing service system interface will be called to retrieve the ticket purchase page for attraction B provided by the ticketing service system. The entire display and usage process is just like using a web application.

[0094] The itinerary includes a visual map area showing the route for each time unit. This can be displayed on the itinerary planning page, showing the route for each day and the attractions along the way. Figure 10 As shown in (a), the visualized map area includes a canvas on which map data and planned routes are rendered. The map data can be obtained by calling a map application service interface. Users can switch the routes displayed in the visualized map area for the corresponding time unit by clicking different route icons (different colored line segments represent different route icons in the figure).

[0095] The itinerary element list can be organized by time unit, for example, it could be a list of itinerary elements for each day of the itinerary (i.e., one day as a time unit), such as... Figure 10As shown in (a). Users can trigger the display of more content on the page by swiping up or other gestures, for example... Figure 10 As shown in (b), the itinerary element list can contain a variety of itinerary elements, such as transportation information, attraction information, accommodation information, dining information, ticketing information, etc.

[0096] When displaying information such as attractions, the attraction information can include multiple points of interest (POIs), which are displayed sequentially. Further information such as the distance between the points of interest can also be displayed.

[0097] In addition, for each trip element, a corresponding service acquisition component can be displayed. When the service acquisition component is triggered, the service acquisition page for the corresponding trip element will be displayed.

[0098] For example, in the case of transportation information, the service acquisition component is the component that triggers the display of the transportation ticketing page, where users can purchase transportation tickets such as train tickets and plane tickets.

[0099] For example, attraction information mainly includes attraction-type Points of Interest (POIs), and the corresponding service acquisition components may include: components that trigger the display of the ticketing page (e.g., Figure 10 (b) shows the "Ticket Purchase" component for attractions 1 and 2, and the component that triggers navigation to that POI (e.g.) Figure 10 (b) shows the "Navigation" component for attractions 1 and 2 and the component that triggers the display of the POI details page (e.g., Figure 10 At least one of the “Details” components for attractions 1 and 2 shown in (b).

[0100] For example, restaurant information mainly includes restaurant-related Points of Interest (POIs), and the corresponding service acquisition components may include at least one of the following: a component that triggers the display of a booking page, a component that triggers navigation to the POI, and a component that triggers the display of the POI's details page.

[0101] For example, accommodation information mainly includes accommodation-related Points of Interest (POIs), and the corresponding service acquisition components may include: components that trigger the display of the booking page (e.g., Figure 10 The “Reservation” component for XX Hotel shown in (b) triggers at least one of the components that navigate to the POI and trigger the display of the POI details page.

[0102] In addition, the trip planning page can also include information such as trip budget, weather, transportation guide, and precautions.

[0103] In this way, users can not only clearly and comprehensively obtain planning and recommendations for various itinerary elements on the itinerary planning page, but also conveniently and quickly access the service acquisition page through its corresponding service acquisition component, and then carry out processing such as service booking, ticket purchase, and navigation. This makes the itinerary planning page a web application, eliminating the need for users to search for the corresponding platform themselves, and greatly improving the feasibility of itinerary plans and user experience.

[0104] Figure 11 This is a flowchart illustrating a method for implementing trip planning provided in an embodiment of this application. This method can be implemented by... Figure 1 The server-side execution in the system shown. For example... Figure 11 As shown, the method may include the following steps 1102-1104: Step 1101: In response to the itinerary planning description sent by the user terminal, execute multiple stage tasks and synchronize the status information of multiple task stages to the user terminal. The multiple stage tasks may include: Step 1102: Analyze the itinerary planning description to obtain constraints in multiple dimensions.

[0105] In this embodiment, the user-input itinerary planning description can be parsed to obtain planning requirement information, which is then further clarified. One possible approach is to pre-set multiple requirement types across various information dimensions. The server matches the obtained planning requirement information against these pre-set types and determines whether to generate a clarification statement based on the number of matching requirement types. A matching requirement means that the planning requirement information belongs to a specific requirement type and the requirement is clear. If the number of matching requirement types does not meet preset requirements (e.g., the number of matching requirement types is less than a preset threshold), a clarification statement can be generated using the unmatched requirement types. The server sends the clarification statement to the user, who then displays it on the session interface. Then, in response to the user's input of supplementary requirement descriptions for the clarification statement, the supplementary requirement descriptions are parsed to obtain supplementary requirement information, which is then used to update the planning requirement information. This parsing and clarification can be implemented using a large model.

[0106] Based on planning needs information, constraints can be derived in multiple dimensions. These constraints may include, but are not limited to: time constraints (such as travel dates and number of days), spatial constraints (such as departure point, destination, and preferred regions), budget constraints (total budget and individual itemized budgets), interest and preference constraints (such as history, nature, and cuisine), accommodation preference constraints (such as ratings, location, and room type), pace preference constraints (such as relaxed or busy), and prohibition constraints. Transforming these vague needs into a clear set of constraints is a prerequisite for accurate planning.

[0107] Step 1103: Based on the above constraints, call the external service system interface to search for service data corresponding to multiple process elements.

[0108] In this step, a search strategy can be planned based on the constraints obtained from the task analysis in the previous stage, and calls to multiple external service system interfaces can be initiated. For example, based on time, space, and budget constraints, a ticketing service system interface can be called to search for flight or train ticket information; based on interest preferences, space, and budget constraints, a map service system interface can be called to search for attraction information; based on interest preferences, space, and budget constraints, a local life service system interface can be called to search for restaurant information; and based on accommodation preferences, space, and budget constraints, a hotel booking service system interface can be called to search for accommodation information. The search results are raw, discrete service data items, each corresponding to a trip element (such as a flight number, a hotel option, or an attraction). The server can further perform preliminary filtering, sorting, or formatting of this data.

[0109] Step 1104: Based on the service data corresponding to multiple trip elements, call the large model to generate a trip planning document that meets the constraints.

[0110] In this step, the service data corresponding to the multiple trip elements obtained from the previous stage task, as well as the constraints obtained from the first stage task, can be provided to the large model. The large model acts as an intelligent planner, arranging the trip elements in time and space while satisfying the constraints, and then performing a rationality assessment to form a trip planning document.

[0111] One feasible approach is to first search for reference itineraries by calling an external service system interface based on constraints to generate a planning schedule. For example, one could search for itineraries already published by other users as reference content, and then call a large model to generate a planning schedule based on this reference content, constraints, and service data. Next, based on the service data corresponding to multiple itinerary elements and the planning schedule, the large model generates an itinerary planning analysis report, which may include comparisons of multiple options and reasons for selection. Finally, based on the itinerary planning analysis report, the large model generates the HTML code for the itinerary planning document. Thus, when a user requests the itinerary planning document, the itinerary planning page can be rendered based on the HTML code.

[0112] In this embodiment, not only can the external service system interface be called to search for service data of itinerary elements, but the external service system interface can also be called to search for reference itineraries, etc., making full use of the existing capabilities and data of the external service system to better provide reference knowledge for generating itinerary planning documents for large models.

[0113] Because large models may have issues such as knowledge cutoff (i.e., the model's knowledge base is a static snapshot, not updated in real time), fictitious information, spatiotemporal logic errors, and detachment from real data, a planning schedule is generated by calling external service system interfaces to search for reference itineraries. This uses the real-world experience of users as a reference, making the final itinerary planning document more closely aligned with real travel scenarios and constraints. Furthermore, an itinerary planning analysis report is generated based on the service data corresponding to the itinerary elements and the planning schedule. The itinerary planning document is then generated based on the itinerary planning analysis report, ensuring that the itinerary planning is based on real data and allows for comparative decision-making, thereby guaranteeing the authenticity, feasibility, and interpretability of the itinerary planning.

[0114] One possible implementation is that the itinerary planning document can be an itinerary planning page. This page includes itinerary description information, a visual map area displaying the routes for each time unit within the itinerary, a list of itinerary elements for each time unit, service acquisition components corresponding to the itinerary elements in the list, and itinerary budget information. The service acquisition components are used to trigger the display of the service acquisition page for the corresponding itinerary element. For details regarding the specific content of the itinerary planning page, please refer to the relevant descriptions in the previous embodiments; they will not be repeated here.

[0115] In addition to page format, other forms of itinerary planning documents can also be used.

[0116] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0117] According to another embodiment, a service interaction device is provided. Figure 12 This is a schematic block diagram of a service interaction device provided in an embodiment of this application. The device is disposed in... Figure 1 The user end in the illustrated architecture. For example... Figure 12 As shown, the device 1200 includes: a description acquisition unit 1201, an interface display unit 1202, and a service-side interaction unit 1203. The main functions of each component are as follows: Description acquisition unit 1201 is configured to acquire the trip planning description input by the user through the session interface.

[0118] The interface display unit 1202 is configured to display the status information of multiple stages of tasks in the process of generating the itinerary planning document on the session interface. The multiple stages of tasks include at least the following: the first stage task of parsing the itinerary planning description to obtain constraints in multiple dimensions; the second stage task of calling the external service system interface based on the constraints to search for service data corresponding to multiple itinerary elements; and the third stage task of calling the large model based on the service data to generate an itinerary planning document that meets the constraints.

[0119] The service-side interaction unit 1203 is configured to retrieve and display the itinerary planning document in the session interface.

[0120] As one possible approach, the service-side interaction unit 1203 is also configured to obtain description information and execution progress information of multiple stages of tasks during the generation of the itinerary planning document.

[0121] The interface display unit 1202 can be specifically configured to: display a progress axis containing multiple nodes in the session interface, with each node corresponding to a different stage task; display the execution progress information of the corresponding stage task in the display area corresponding to each node; and display the description information of the corresponding stage task for each node.

[0122] As one possible implementation method, when the interface display unit 1202 displays the execution progress information of the corresponding stage task in the display area corresponding to each node, it can be specifically configured to: obtain the execution status of each stage task and the execution status of the subtasks contained in each stage task; in response to obtaining the information of the currently executing stage task and its subtasks, display an extended area at the node corresponding to the currently executing stage task, and display the information of the currently executing subtasks in the extended area.

[0123] As one possible implementation method, when the interface display unit 1202 displays the information of the currently executing subtask in the extended area, it can be specifically configured to: in response to the update of the currently executing subtask, display the updated currently executing subtask at a preset position in the extended area, and scroll the completed subtask from the preset position away from the preset position.

[0124] Furthermore, the interface display unit 1202 is also configured to: in response to the completion of the currently executing stage task, hide the display area and update the visual element on the progress axis that indicates the corresponding node to a visual element that indicates the completion of the stage task.

[0125] Furthermore, the interface display unit 1202 is also configured to: display the corresponding first component for the node corresponding to the completed stage task; in response to the operation of triggering the first component, display an extended area at the node corresponding to the triggered first component, the extended area including information of the sub-tasks contained in the corresponding stage task; and in response to the operation of triggering the first component again, hide the extended area.

[0126] The information of the subtasks displayed in the extended area includes at least one of the following: description information of the subtask, information on calling external service system interfaces, and a second component, which is used to trigger the display of the execution result data of the corresponding subtask.

[0127] The execution result data of the subtasks in the second phase of the task includes: service data corresponding to multiple process elements obtained by calling the external service system interface.

[0128] The execution result data of the subtasks in the third phase of the task includes at least one of the following: the code used to integrate service data; the itinerary planning analysis report based on the service data; and the HTML code of the itinerary planning document generated based on the itinerary planning analysis report.

[0129] As one possible implementation method, when the interface display unit 1202 displays the itinerary planning document in the session interface, it can be specifically configured to: display an itinerary summary and itinerary cards in the session interface, the itinerary cards including a third component; in response to the operation of triggering the third component, jump to the itinerary planning page, the itinerary planning page including: itinerary description information, a visual map area displaying the routes of each time unit included in the itinerary, a list of itinerary elements for each time unit included in the itinerary, a service acquisition component corresponding to the itinerary element in the itinerary element list, and itinerary budget information, the service acquisition component being used to trigger the display of the service acquisition page for the corresponding itinerary element.

[0130] The service acquisition component corresponding to the itinerary element may include: The component that triggers the display of the transportation ticketing page corresponding to the transportation information; The component that triggers the display of the ticketing page, the component that triggers navigation to the POI, and the component that triggers the display of the POI's details page for the attraction-type POI; The component that triggers the display of the reservation page for a food and beverage POI, the component that triggers navigation to the POI, and the component that triggers the display of the POI's details page are all included. The component that triggers the display of the booking page for the accommodation-type POI, the component that triggers navigation to the POI, and the component that triggers the display of the POI details page are at least one of the following:

[0131] As one possible implementation method, when displaying the itinerary planning page, the interface display unit 1202 can be specifically configured to: obtain and parse HTML code; In response to obtaining a map container from the HTML code, a visual map area is displayed in the map container. The visual map area includes interactive controls corresponding to each time unit. The interactive controls are used to call an external service system interface to obtain map data corresponding to the route of the corresponding time unit after being triggered, and to render and display the map data in the visual map area based on the map data. In response to parsing the trip element card from the HTML code, the trip element card is rendered. The trip element card includes a service acquisition component. The service acquisition component is used to call an external service system interface to obtain the corresponding service page data after being triggered, and to render and display the service page based on the service page data. The itinerary element cards in the HTML code are organized and sorted according to time units.

[0132] According to another embodiment, an apparatus for implementing trip planning is provided. Figure 13 This is a schematic block diagram of a device for implementing trip planning provided in an embodiment of this application. The device is disposed in... Figure 13 The server side in the illustrated architecture. For example... Figure 13 As shown, the device 1300 includes a user-side interaction unit 1301 and a task processing unit 1302. The main functions of each component are as follows: User-side interaction unit 1301 is configured to obtain the trip planning description sent by the user.

[0133] The task processing unit 1302 is configured to respond to the itinerary planning description, execute multiple stage tasks respectively, and synchronize the status information of multiple task stages to the user terminal through the user-side interaction unit 1301. The multiple stage tasks include: parsing the itinerary planning description to obtain constraints in multiple dimensions; calling the external service system interface based on the constraints to search for service data corresponding to multiple itinerary elements; and calling the large model to generate an itinerary planning document that meets the constraints based on the service data corresponding to multiple itinerary elements.

[0134] As one possible implementation method, when the task processing unit 1302 calls the large model to generate a trip planning document that meets the constraints based on the service data corresponding to multiple trip elements, it can be specifically configured to: call the external service system interface to search for reference trips based on the constraints to generate a planning schedule; call the large model to generate a trip planning analysis report based on the service data corresponding to multiple trip elements and the planning schedule; and call the large model to generate the HTML code of the trip planning document based on the trip planning analysis report.

[0135] The itinerary planning document is the itinerary planning page, which includes itinerary description information, a visual map area showing the routes of each time unit in the itinerary, a list of itinerary elements for each time unit in the itinerary, service acquisition components corresponding to the itinerary elements in the itinerary element list, and itinerary budget information. The service acquisition component is used to trigger the display of the service acquisition page for the corresponding itinerary element.

[0136] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or device embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the description of the method embodiments. The system and device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0137] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0138] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0139] And an electronic device, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any of the foregoing method embodiments.

[0140] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0141] in, Figure 14 An exemplary architecture of an electronic device is shown, which may include a processor 1410, a video display adapter 1411, a disk drive 1412, an input / output interface 1413, a network interface 1414, and a memory 1420. The processor 1410, video display adapter 1411, disk drive 1412, input / output interface 1413, network interface 1414, and memory 1420 can communicate with each other via a communication bus 1430.

[0142] The processor 1410 can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs and implement the technical solution provided in this application.

[0143] The memory 1420 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1420 can store the operating system 1421 for controlling the operation of the electronic device 1400, and the basic input / output system (BIOS) 1422 for controlling the low-level operations of the electronic device 1400. Additionally, it can store a web browser 1423, a data storage management system 1424, a service interaction device 1200, and a trip planning device 1300, etc. The aforementioned service interaction device 1200 and trip planning device 1300 can be application programs that specifically implement the aforementioned steps in this embodiment. In summary, when implementing the technical solution provided in this application through software or firmware, the relevant program code is stored in the memory 1420 and executed by the processor 1410.

[0144] Input / output interface 1413 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, etc.

[0145] Network interface 1414 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0146] Bus 1430 includes a pathway for transmitting information between various components of the device, such as processor 1410, video display adapter 1411, disk drive 1412, input / output interface 1413, network interface 1414, and memory 1420.

[0147] It should be noted that although the above-described device only shows the processor 1410, video display adapter 1411, disk drive 1412, input / output interface 1413, network interface 1414, memory 1420, bus 1430, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the solution of this application, and does not necessarily need to include all the components shown in the figures.

[0148] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer program product. This computer program product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0149] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A service interaction method, characterized in that, The method includes: Obtain the trip planning description entered by the user through the chat interface; The session interface displays the status information of multiple stages of tasks during the generation of the itinerary planning document. The multiple stages of tasks include at least: a first stage task of parsing the itinerary planning description to obtain constraints in multiple dimensions; a second stage task of calling an external service system interface based on the constraints to search for service data corresponding to multiple itinerary elements; and a third stage task of calling a large model based on the service data to generate an itinerary planning document that meets the constraints. The itinerary planning document is retrieved and displayed in the session interface.

2. The method according to claim 1, characterized in that, The status information of multiple stages of tasks during the process of generating the itinerary planning document is displayed on the session interface, including: Obtain description information and execution progress information of multiple stages of tasks during the generation of the itinerary planning document; The session interface displays a progress axis containing multiple nodes, each corresponding to a different stage task. The execution progress information of the corresponding stage task is displayed in the display area corresponding to each node, and a description of the corresponding stage task is displayed for each node.

3. The method according to claim 2, characterized in that, The display of the execution progress information of the corresponding stage task in the display area corresponding to each node includes: Obtain the execution status of each stage of the task and the execution status of the subtasks contained in each stage of the task; In response to obtaining information about the currently executing stage task and its subtasks, visual elements indicating the execution of the stage task are displayed for the node corresponding to the currently executing stage task, and an extended area is displayed at the node corresponding to the currently executing stage task, where information about the currently executing subtasks is displayed. In response to the completion of the currently executing phase task, the display area is hidden and the visual element is updated to indicate that the phase task has been completed.

4. The method according to claim 3, characterized in that, The information displayed in the extended area regarding the currently executing subtasks includes: In response to an update to the currently executing subtask, the updated currently executing subtask is displayed at a preset position in the extended area, and the completed subtask is scrolled away from the preset position.

5. The method according to claim 1, characterized in that, The method further includes: For each completed stage task, the corresponding first component is displayed. In response to the operation that triggers the first component, an extended area is displayed at the node corresponding to the triggered first component, the extended area including information about the subtasks contained in the corresponding stage task; In response to the re-triggering of the operation of the first component, the extended area is hidden.

6. The method according to any one of claims 3 to 5, characterized in that, The information on the subtasks displayed in the extended area includes at least one of the following: The subtask description information, the information on calling external service system interfaces, and the second component, the second component being used to trigger the display of the execution result data of the corresponding subtask; The execution result data of the subtasks in the second phase task includes: service data corresponding to multiple process elements obtained by calling the external service system interface; The execution result data of the subtasks in the third phase task includes at least one of the following: The code used to integrate the service data; A trip planning analysis report based on the service data; The HTML code of the itinerary planning document generated based on the itinerary planning analysis report.

7. The method according to any one of claims 1 to 5, characterized in that, The process of displaying the itinerary planning document on the session interface includes: The session interface displays a trip summary and a trip card, the trip card including a third component; In response to the operation of triggering the third component, the user is redirected to the trip planning page, which includes: trip description information, a visual map area displaying the routes of each time unit in the trip, a list of trip elements for each time unit in the trip, a service acquisition component corresponding to the trip element in the list of trip elements, and trip budget information. The service acquisition component is used to trigger the display of the service acquisition page for the corresponding trip element.

8. The method according to claim 7, characterized in that, The itinerary planning page includes: Get and parse HTML code; In response to obtaining a map container from the HTML code, a visual map area is displayed in the map container. The visual map area includes interactive controls corresponding to each time unit. The interactive controls are used to call an external service system interface to obtain map data corresponding to the route of the corresponding time unit after being triggered, and to render and display the map data in the visual map area based on the map data. In response to parsing the trip element card from the HTML code, the trip element card is rendered. The trip element card includes a service acquisition component. The service acquisition component is used to call an external service system interface to obtain the corresponding service page data after being triggered, and to render and display the service page based on the service page data. The itinerary element cards in the HTML code are organized and sorted according to time units.

9. A method for implementing itinerary planning, characterized in that, The method includes: In response to the itinerary planning description sent by the user, multiple stage tasks are executed respectively, and the status information of the multiple task stages is synchronized to the user; wherein, the multiple stage tasks include: The itinerary planning description is parsed to obtain constraints in multiple dimensions; Based on the aforementioned constraints, the external service system interface is invoked to search and obtain service data corresponding to multiple itinerary elements; Based on the service data corresponding to the multiple trip elements, a large model is invoked to generate a trip planning document that meets the constraints.

10. The method according to claim 9, characterized in that, The step of generating a trip planning document that meets the constraints by calling a large model based on the service data corresponding to the multiple trip elements includes: Based on the aforementioned constraints, an external service system interface is invoked to search for reference itineraries in order to generate a planned schedule. Based on the service data corresponding to the multiple itinerary elements and the planning schedule, a large model is invoked to generate an itinerary planning analysis report. Based on the aforementioned itinerary planning analysis report, the HTML code for generating the itinerary planning document is called from the large model.

11. A service interaction device, characterized in that, The device includes: The description acquisition unit is configured to acquire the trip planning description input by the user through the session interface; The interface display unit is configured to display the status information of multiple stages of tasks in the process of generating a trip planning document in the session interface. The multiple stages of tasks include at least: a first stage task of parsing the trip planning description to obtain multiple dimensions of constraints; a second stage task of calling an external service system interface based on the constraints to search for service data corresponding to multiple trip elements; and a third stage task of calling a large model based on the service data to generate a trip planning document that meets the constraints. The service-side interaction unit is configured to retrieve and display the itinerary planning document on the session interface.

12. An apparatus for implementing trip planning, characterized in that, The device includes: The user-side interaction unit is configured to obtain the trip planning description sent by the user. A task processing unit is configured to, in response to the itinerary planning description, execute multiple stage tasks and synchronize the status information of the multiple task stages to the user terminal through the user-side interaction unit; wherein, the multiple stage tasks include: The itinerary planning description is parsed to obtain constraints in multiple dimensions; Based on the aforementioned constraints, the external service system interface is invoked to search and obtain service data corresponding to multiple itinerary elements; Based on the service data corresponding to the multiple trip elements, a large model is invoked to generate a trip planning document that meets the constraints.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 10.

14. An electronic device, characterized in that, include: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 1 to 10.

15. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 10.

Images