Retrieval method, retrieval system and related equipment

Abstract

The embodiment of the invention discloses a retrieval method, a retrieval system and related equipment. In the method, electronic equipment can upload a search word to a server after receiving the search word input by a user. In addition, the electronic device can also upload the user memory data to the server. Then, the server can accurately judge the retrieval intention of the user based on the retrieval word input by the user and the user memory data, the necessary retrieval parameters are obtained by utilizing the retrieval intention, and the value of the necessary retrieval parameters is determined by combining the retrieval input of the user and the user memory data; the necessary retrieval parameters are used for modifying the retrieval word input by the user, and the retrieval result is returned to the electronic equipment on the basis of the modified retrieval word, so that efficient, accurate and personalized retrieval experience is provided for the user.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a retrieval method, retrieval system and related equipment. Background Technology

[0002] With the development of terminal technology, electronic devices are able to push increasingly rich information and services to users. Building on this, electronic devices not only provide search functions so that users can quickly locate the content they need, but also offer personalized search results.

[0003] Electronic devices can identify tags corresponding to user-input search terms, then use these tags to determine the user's search intent, and finally return relevant search results based on that intent, thus achieving personalized service. However, the above method cannot fully tailor search results to each user's specific circumstances, and therefore cannot truly provide personalized search results. Summary of the Invention

[0004] This application provides a retrieval method, retrieval system, and related equipment. In this method, after receiving search terms input by a user, the electronic device can upload the search terms to a server. In addition, the electronic device can also upload user-remembered data to the server. Subsequently, the server can accurately determine the user's search intent based on the user-input search terms and the user-remembered data, use this search intent to obtain necessary search parameters, combine the user's search input and user-remembered data to determine the values ​​of these necessary search parameters, and then use these necessary search parameters to modify the user-input search terms. Based on the modified search terms, the server returns search results to the electronic device to provide the user with an efficient, accurate, and personalized search experience.

[0005] In a first aspect, this application provides a retrieval method applied to a first electronic device in a first communication system, the first communication system further including a server, the method comprising: the first electronic device receiving a first retrieval input; the first electronic device displaying a first retrieval result; detecting the activation of a first authorization, the first authorization being used to upload first user data on the first electronic device to the server; the first electronic device receiving a second retrieval input, the second retrieval input containing the same search terms as the first retrieval input; the first electronic device displaying a second retrieval result, the second retrieval result being different from the first retrieval result, and the second retrieval result having a higher relevance to the first user data compared to the first retrieval result.

[0006] Implementing the method provided in the first aspect, before enabling the first authorization, the first electronic device (i.e., the terminal-side electronic device) can display first search results based on the search terms entered in the first search. After enabling the first authorization, the first electronic device can display second search results based on the search terms entered in the second search. The search terms are the same for both searches, but the second search result is more relevant to the first user data (i.e., the various user data subscribed to by the first electronic device).

[0007] Compared to solutions that use clustering techniques to provide personalized search results to users, the method described in the above embodiments can provide users with more accurate personalized search results, thereby improving the user's search experience.

[0008] In conjunction with the method provided in the first aspect, in some embodiments, the first user data comes from one or more of the following: the user's input in the first application in the most recent first time period, the user's schedule in the most recent first time period, the user's call content in the most recent first time period, the user's chat history in the most recent first time period, the user profile, and the dialogue between the user and the intelligent voice assistant.

[0009] In conjunction with the method provided in the first aspect, in some embodiments, after detecting that the first authorization has been enabled, the method further includes: the first electronic device sending the first user data to the server.

[0010] By implementing the method provided in the above embodiments, the first electronic device (i.e., the end-side electronic device) can upload the first user data to the server, thereby utilizing the server's computing power to perform calculations such as intent judgment, thus making the final returned personalized search results more accurate.

[0011] In conjunction with the method provided in the first aspect, in some embodiments, the first electronic device sends the first user data to the server, specifically including: the first electronic device determining relevant user memory data from the first user data based on the second retrieval input; and the first electronic device sending the relevant user memory data to the server.

[0012] By implementing the method provided in the above embodiments, the terminal electronic device can filter the data uploaded to the server and upload only the user memory data (i.e., relevant user memory data) that is related to the search terms entered by the user to the server, thereby reducing the occupation of server resources and reducing the time required for server queries, thereby improving the efficiency of retrieval.

[0013] In conjunction with the method provided in the first aspect, in some embodiments, before the first electronic device displays the second search result, the method further includes: receiving the second search result returned by the server.

[0014] In conjunction with the method provided in the first aspect, in some embodiments, the second search result is the search result for the second search term, which is obtained by modifying the first search term based on the first user data, and the first search term is the search term input for the second search.

[0015] By implementing the method provided in the above embodiments, the second search result received by the terminal electronic device is not obtained directly based on the search terms entered by the user, but is obtained by using search terms modified based on the user's memory data. This makes the returned personalized search results more accurate and more in line with the user's actual needs, providing the user with a better search experience.

[0016] Secondly, this application provides a retrieval method applied to a server in a first communication system, the first communication system further including a first electronic device, the method comprising: receiving first user data and a first search term sent by the first electronic device, the first user data and the first search term being sent by the first electronic device when it obtains a first authorization; modifying the first search term based on the first user data to obtain a second search term; and returning a second search result to the first electronic device based on the second search term.

[0017] By implementing the method provided in the second aspect, the server can modify the first search term (i.e., the original query received after obtaining the first authorization) based on the first user data sent by the terminal electronic device, thereby retrieving the second search result based on the modified query and returning it to the terminal electronic device. Thus, the server can use its higher computing power to provide users with more accurate and personalized search results.

[0018] In conjunction with the method provided in the second aspect, in some embodiments, the method further includes: receiving a third search term, which is the same as the first search term, and the third search term is sent by the first electronic device when it has not obtained the first authorization; returning a first search result to the first electronic device based on the third search term; and the second search result having a higher relevance to the first user data compared to the first search result.

[0019] In conjunction with the method provided in the second aspect, in some embodiments, modifying the first search term based on the first user data to obtain the second search term specifically includes: identifying a first intent based on the first user data and the first search term, the first intent being used to determine the first search parameters; modifying the first search term according to the first search parameters associated with the first intent to obtain the second search term, the second search term including the value of the first search parameters, and the first search term lacking the value of the first search parameters.

[0020] By implementing the method provided in the above embodiments, the server can first use the user's user data (including user memory data) to accurately determine the user's search intent when inputting the first search term. This search intent is strongly correlated with the necessary search parameters (i.e., the first search parameters). The server can then use the user's search intent to modify the search term, thereby ensuring that the modified search term can include the values ​​of the necessary search parameters, making the search term closer to the user's true search intent, and thus making the search results more personalized.

[0021] In conjunction with the method provided in the second aspect, in some embodiments, modifying the first search term according to the first search parameter associated with the first intent specifically includes: determining the value of the missing first search parameter in the first search term based on the name of the first search parameter; determining the value of the first search parameter from the first user data; and adding the value of the first search parameter to the first search term to obtain the second search term.

[0022] By implementing the method provided in the above embodiments, the server can determine whether the user-input query (i.e., the first search term) is missing any necessary search parameter (i.e., the first search parameter). Subsequently, the server can find the value of the necessary search parameter from the user's user data (including user memory data) to complete the user-input query. The completed query is the second search term. Thus, by using user data to supplement the necessary search parameters in the query, the completed query can retrieve results that better meet the user's personalized needs.

[0023] In conjunction with the method provided in the second aspect, in some embodiments, identifying the first intent based on the first user data and the first search term specifically includes: obtaining a candidate intent list based on the first search term, wherein the candidate intent list has the highest relevance to the first search term;

[0024] The first intent is determined from the candidate intent list based on the first user data. The first intent is the intent in the candidate intent list that has the highest relevance to the first user data.

[0025] By implementing the method provided in the above embodiments, the server can first determine a candidate intent list based on the query transmitted from the terminal electronic device, and then determine the user's real search intent (i.e., the first intent) from the candidate intent list based on user data. This allows for personalized determination of the user intent corresponding to the query, making the server's judgment of the user intent more accurate.

[0026] In conjunction with the method provided in the second aspect, in some embodiments, the method further includes: modifying the first search term based on the first user data and the private domain data set to obtain a fourth search term; and returning a third search result to the first electronic device based on the fourth search term.

[0027] By implementing the method provided in the above embodiments, the server can retrieve a private domain database using the user-input query and modify the user-input query to generate an expanded query. Subsequently, the server can refine this expanded query using user data. This refined expanded query is then used by the server to retrieve expanded service items (i.e., the third search result) and return them to the terminal electronic device. The generation of the expanded query ensures that the service items returned to the terminal electronic device are both relevant to the user's search content and enrich the search results.

[0028] In conjunction with the method provided in the second aspect, in some embodiments, the method further includes: modifying the first search term based on the private domain data set to obtain a fifth search term; returning a fourth search result to the first electronic device based on the fifth search term; and the third search result having a higher relevance to the first user data compared to the fourth search result.

[0029] By implementing the method provided in the above embodiments, the server can retrieve a private domain database using the query input by the user and modify the query input by the user to generate an extended query. Instead of parsing the query using the ReAct method, the server can directly use this extended query for retrieval.

[0030] In conjunction with the method provided in the second aspect, in some embodiments, the first search term is modified based on the first user data and the private domain data set to obtain the fourth search term. Specifically, this includes: identifying a second intent based on the private domain data set and the first search term, the second intent being used to determine the second search parameters; modifying the first search term according to the second search parameters associated with the second intent to obtain the fourth search term, the fourth search term including the values ​​of the second search parameters, while the first search term lacks the values ​​of the second search parameters.

[0031] Implementing the method provided in the above embodiments, the server retrieves a private domain database (i.e., a private domain data set) based on the user's input query to identify the user's possible extended intent (i.e., a second intent). Then, it modifies the first search term according to the necessary search parameters of the extended intent (i.e., the second search parameters) to obtain the fourth search term. This ensures that the modified extended query can include the values ​​of the necessary search parameters, making the search term closer to the user's true search intent, thereby making the search results more personalized.

[0032] Thirdly, this application provides a retrieval method applied to a first system, the first system including a first electronic device and a server. The method includes: the first electronic device receiving a first retrieval input; the server receiving a search term from the first electronic device based on the first search term; the server sending a first retrieval result to the first electronic device based on the first search term; the first electronic device displaying the first retrieval result; detecting the activation of a first authorization, the first authorization being used to upload first user data on the first electronic device to the server; the first electronic device receiving a second retrieval input, the second retrieval input containing the same search term as the first search term; the server receiving the first search term and the first user data from the first electronic device, the first search term being the search term of the second retrieval input; the server modifying the first search term based on the first user data to obtain a second search term; the server returning a second retrieval result to the first electronic device based on the second search term; and the first electronic device displaying the second retrieval result, the second retrieval result being different from the first retrieval result, and having a higher relevance to the first user data compared to the first retrieval result.

[0033] Implementing the method provided in the third aspect, before enabling the first authorization, the first electronic device (i.e., the terminal electronic device) can request and display the first search results from the server based on the search terms entered in the first search. After enabling the first authorization, the first electronic device can request and display the second search results from the server based on the search terms entered in the second search. The search terms are the same for both searches, but regarding the returned results, because user data can be sent to the server and participate in the server's search process after enabling the first authorization, the second search results returned by the server to the terminal electronic device are more relevant to the first user data (i.e., the various user data subscribed to by the terminal electronic device).

[0034] Fourthly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the method described in the first aspect and any possible implementation thereof, or the method described in the second aspect and any possible implementation thereof.

[0035] Fifthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect and any possible implementation thereof, or the method described in the second aspect and any possible implementation thereof.

[0036] Sixthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect and any possible implementation thereof, or the method described in the second aspect and any possible implementation thereof.

[0037] Understandably, the electronic device provided in the fourth aspect, the computer storage medium provided in the fifth aspect, and the computer program product provided in the sixth aspect are all used to execute the method provided in this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0038] Figure 1 This is a flowchart illustrating a method for identifying application search intent provided in an embodiment of this application;

[0039] Figure 2 This is a schematic diagram of a service direct access interface provided in an embodiment of this application;

[0040] Figure 3 This is a schematic diagram of the system architecture of a retrieval system provided in an embodiment of this application;

[0041] Figure 4 This is a schematic flowchart illustrating intent understanding provided in an embodiment of this application;

[0042] Figure 5 This is a schematic diagram of an intent recognition service provided in an embodiment of this application;

[0043] Figure 6 This is a schematic diagram of a scenario-based analysis architecture provided in an embodiment of this application;

[0044] Figure 7 This is a schematic diagram of a scenario-based analysis process provided in an embodiment of this application;

[0045] Figure 8 This is a schematic diagram of the hardware structure of an end-side electronic device provided in an embodiment of this application;

[0046] Figure 9 This is a schematic diagram of the hardware structure of a cloud-side server provided in an embodiment of this application. Detailed Implementation

[0047] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be a limitation of this application.

[0048] With the development of terminal technology, electronic devices are able to push increasingly rich information and services to users. Based on this, electronic devices provide users with search functions so that they can quickly locate the content they need.

[0049] Building on this foundation, and leveraging advancements in machine learning and natural language processing technologies, the aforementioned search function further provides personalized search results. This allows for the filtering and recommendation of content that users need most, resulting in a more accurate and personalized search experience.

[0050] In one implementation, electronic devices can use clustering techniques to provide personalized search results to users. This clustering technique involves grouping similar data within a dataset into groups, making data within the same group as similar as possible, and data between different groups as different as possible. In search, this clustering technique can be applied to electronic devices recognizing the tags corresponding to the user's input search terms (i.e., search input), then using these tags to determine the user's search intent, and finally returning relevant search results based on that intent, thereby achieving personalized service.

[0051] Taking service retrieval as an example, Figure 1 This is a flowchart illustrating a method for identifying application retrieval intent provided in an embodiment of this application.

[0052] Specifically, such as Figure 1 As shown, electronic devices can obtain search terms from the query session logs of the application search engine and mine a tag system for each search term based on the search terms and preset strategies. Then, when a user enters a search term, the electronic device can identify the corresponding tag from the aforementioned tag system based on the user's input, thereby identifying the user's application search intent when entering the search term, and then returning application search results to the user based on that search intent. It is understandable that the above process of mining a tag system based on search terms is a clustering process. For example, the electronic device can construct and mine the corresponding tag "food" based on search terms such as "fried chicken" and "Japanese food" in the logs. Subsequently, when a user searches for "fried chicken," the electronic device can determine the corresponding tag as "food" based on this search term, thereby identifying the user's application search intent of "dining," and then pushing a food ordering application to the user based on that application search intent.

[0053] However, the aforementioned approach of constructing a tagging system based on search terms from various query sessions in the logs to determine user search intent does not truly incorporate personalized user information. Understandably, a user's search intent is determined based on the correspondence between search terms and the tagging system. However, this correspondence is not built on individual user data but on data from a large number of users. Therefore, the search intent determined by this process only represents the application search intent of most people when they enter that search term, and cannot specifically reflect the application search intent of that particular user. In other words, for user A and user B, entering the same search term may mean completely different search intents. For example, user A is a news enthusiast, and user B is a travel enthusiast. When they both search for location A, user A wants to receive the latest news about location A, while user B wants to receive travel guides for location A. Therefore, constructing a tagging system from query session logs to obtain the user's application search intent is not accurate enough in intent identification, which will lead to deviations when returning search results based on search intent, resulting in a mismatch between the search results and the user's true search intent.

[0054] In addition to providing personalized search results, the current service retrieval system also offers a convenient feature—direct service access. This feature allows users to instantly access and use the services they need while obtaining personalized search results. By simplifying the operation process, it reduces the waiting and switching between searching, selecting, and actually using the service, achieving seamless integration from information acquisition to service use.

[0055] Figure 2 This is a schematic diagram of a service direct access interface provided in an embodiment of this application. It is understood that traditional service retrieval only returned relevant applications to the user. Taking the search for "Beijing hotels" as an example, traditional service retrieval functions would only return applications used for booking hotels, such as... Figure 2 For example, searching for "XX Travel" requires users to click through the application and then search for "Beijing Hotel A," resulting in multiple searches and a poor user experience. The aforementioned direct service access function, however, returns service items directly to the user after their service search. These service items are the specific content of the service, such as... Figure 2 The example shown directly returns two service items, "Beijing Hotel A" and "Beijing Hotel B", to the user as search results.

[0056] However, due to incomplete or ambiguous search terms entered by users, the user's true intent may not be effectively identified, thus failing to return the service the user needs. For example, when a user searches for location A, the electronic device cannot accurately distinguish whether the user intends to navigate to location A or wants to view recent information about location A. The aforementioned incomplete search terms refer to the lack of necessary parameters for retrieving the corresponding service; these parameters are also called necessary search parameters. Understandably, to achieve the aforementioned direct service access effect, the electronic device needs to obtain the necessary parameters for retrieving the service from the user's search terms. For example, for ride-hailing services, the electronic device needs to parse the three necessary parameters—departure point, destination, and vehicle type—from the user's search terms before it can directly return the search results for the ride-hailing service. That is, after the user clicks on the returned search results, the device should directly display the ride route and the corresponding prices for each vehicle type. Continuing with the example above, if the user enters the search term "take a taxi home", the electronic device can obtain the user's current location as the departure point, but it cannot parse the destination and vehicle type from the search term. Therefore, when the user only enters "take a taxi home", the electronic device cannot actually return one or more service items of the taxi service to the user.

[0057] In view of this, this application proposes a retrieval method. When a user performs a retrieval, this method can accurately determine the user's retrieval intent based on the user's retrieval input and user memory data, use the retrieval intent to obtain necessary retrieval parameters, combine the user's retrieval input and user memory data to determine the values ​​of the necessary retrieval parameters, and then use the necessary retrieval parameters to recall and rank the retrieval results, so as to provide the user with an efficient, accurate and personalized retrieval experience. Here, the aforementioned recall refers to filtering out data related to the retrieval from a large amount of data (i.e., the aforementioned retrieval results).

[0058] The search methods described above are not limited to searching for service items; they can also be applied to other search services that require personalized recommendations, including but not limited to information retrieval. The specific fields in which the search methods described in this application are applied are not specifically limited. The following explanation will continue to use service retrieval as an example to illustrate the search methods provided in this application.

[0059] Figure 3 This is a schematic diagram of the system architecture of a retrieval system provided in an embodiment of this application. The above-described retrieval system can be used to execute the above-described retrieval method. The above-described retrieval system is also referred to as a first communication system.

[0060] The aforementioned retrieval system can be divided into two parts: the terminal side and the cloud side. The terminal side functions can be carried on electronic devices with display capabilities, while the cloud side functions can be carried on a server. The aforementioned electronic devices, also referred to as the first electronic device, may include mobile phones, tablets, desktop computers, laptop computers, handheld computers, laptops, augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, wearable devices, in-vehicle devices, smart home devices, etc. This application embodiment does not impose any special restrictions on the specific type of electronic device.

[0061] The aforementioned edge-side electronic devices can be used to collect user data from various applications, and the collected user data can be used to generate user memory data. This collected user data is also referred to as first user data. Optionally, the collected user data can be used by the electronic devices to generate short-term user memory data. Optionally, the collected user data can also be sent by the electronic devices to a cloud-side server after obtaining user authorization, and then used by the cloud-side server to generate long-term user memory data. The generation of short-term or long-term user memory data based on the collected user data can be understood as filtering short-term or long-term user memory data from various types of user data. Both short-term and long-term user memory data belong to user memory data. Specifically, short-term user memory data refers to user behavior data or interaction data collected by the electronic devices within a recent period (i.e., the first time period); for example, the short-term user memory data can come from one or more of the following: user input in applications within the most recent first time period, the most recent first time period's schedule, the most recent first time period's call content, and the most recent first time period's chat history. The aforementioned long-term user memory data refers to data stored in the retrieval system that reflects a user's long-term behavioral patterns and preferences. For example, this long-term user memory data can originate from user profiles or dialogues between users and intelligent voice assistants. The user profiles are typically constructed based on information such as user behavior, preferences, and attributes. This information can be obtained by the server from data subscribed to by the aforementioned electronic devices. Understandably, the retention time of the aforementioned short-term user memory data is relatively short, facilitating rapid access and updates; the retention time of the aforementioned long-term user memory data is relatively long, enabling the construction and reflection of stable user behavioral patterns and preferences.

[0062] In addition, the electronic device can also be used to receive user search input (i.e., a query). Preferably, the electronic device can retrieve short-term user memory data stored on the device side based on the query to obtain short-term user memory data related to the query. The electronic device can also be used to send the query and short-term user memory data to a cloud-side server. Optionally, the electronic device may not be used to retrieve short-term user memory data related to the query, but instead send all short-term user memory data to the cloud-side server.

[0063] Specifically, the above functions can be implemented by the query analysis module and knowledge recall engine in electronic devices.

[0064] The query analysis module described above can be used to receive user-input queries and request short-term user memory data related to those queries from the knowledge recall engine. This module also uploads the user-input query, or the user-input query and the requested short-term user memory data, to the cloud. The short-term user memory data related to the query is also referred to as the first short-term user memory data.

[0065] Specifically, the query analysis module mentioned above can include four sub-modules: a query rewriting module, a scene recognition module, a parameter analysis module, and a request generation module. The query rewriting module receives user-input queries and rewrites them. This means transforming the user-input query into a more specific request, facilitating the request of relevant short-term user memory data from the knowledge recall engine. Therefore, the user-input query can also be called the original query. The scene recognition module identifies the scene of the original query, allowing the obtained scene to be analyzed and identified, reflecting the user's search intent. Optionally, the scene recognition module can utilize a large language model (LLM) to implement scene recognition; this LLM can also be referred to as LLM-A. The input of LLM-A is the original query, and the output is the identified service scene requested by that original query. Understandably, all LLMs mentioned in this article, including LLM-A here, can be pre-trained by developers based on a general LLM and pre-stored in the aforementioned electronic devices. The parameter analysis module can be used to determine the necessary retrieval parameters for different scenarios and output these necessary retrieval parameters to the request generation module. The request generation module can be used to generate a request based on the rewritten query and the necessary retrieval parameters, denoted as the first request. This first request is used to request short-term user memory data related to the query from the knowledge recall engine. The necessary retrieval parameters are also referred to as the first retrieval parameters.

[0066] The aforementioned knowledge recall engine module can generate short-term user memory data and provide corresponding data retrieval functions. Specifically, the knowledge recall engine can include four sub-modules: a data subscription module, a data summarization module, a request processing module, and a data retrieval module. The data subscription module collects user data from various applications on the electronic device. The data summarization module summarizes the subscribed user data to obtain short-term user memory data. Optionally, the electronic device can summarize the collected user data using a Large Language Model (LLM-B) to extract short-term user memory data. The request processing module performs preliminary processing on the first request sent by the query analysis module. The data retrieval module retrieves the previously summarized short-term user memory data based on the first request and returns the retrieved results to the query analysis module.

[0067] Various data from the client side can be uploaded to the cloud server through a unified entry point, which is also called the aggregated cloud module.

[0068] The aforementioned cloud-side server can be used to summarize and generate long-term user memory data based on user data sent by edge electronic devices. The server can also receive queries and short-term user memory data sent by electronic devices, then use the user memory data in the server to modify the original query, and continue recalling and sorting service items based on the modified query.

[0069] Specifically, in addition to the aggregation cloud-side module, the aforementioned cloud-side server may also include a Natural Language Understanding (NLU) intent interface and a meta-service retrieval agent. The NLU intent interface can be used to generate a corresponding intent list based on the query. The functions implemented by the aforementioned cloud-side server are mainly undertaken by the meta-service retrieval agent within the server. Specifically, the meta-service retrieval agent includes, but is not limited to, the following functional modules: intent understanding module, query parsing module, recall module, ranking module, large language model (LLM), and tool module.

[0070] The aforementioned tool modules may include a long-term user memory data retrieval module and a short-term user memory data retrieval module. The long-term user memory data retrieval module, when invoked, can retrieve long-term user memory data stored in the cloud and return the retrieval results. The short-term user memory data retrieval module, when invoked, can retrieve short-term user memory data stored in the cloud and return the retrieval results. Optionally, the aforementioned tool modules may also include a retrieval augmented generation (RAG) module. The RAG module can retrieve query-related information from a private domain database and return the retrieval results. This private domain database can be pre-built by developers through methods such as crawling comments and stored in the cloud.

[0071] The intent understanding module described above is used to determine the true intent of the query, also known as the first intent. Specifically, this intent understanding module may include several sub-modules such as a candidate intent list acquisition module, a first query module, and a personalized intent decision module. Specifically, the candidate intent list acquisition module can receive queries sent to the cloud side, call the NLU intent interface to obtain the candidate intent list corresponding to the query, and output the candidate intent list to the first query module. The first query module can call the long-term user memory data retrieval module and the short-term user memory data retrieval module in the tool module to retrieve user memory data related to the query, and output the query results to the personalized intent decision module. The personalized intent decision module can combine the retrieved user memory data, call the LLM to finally determine the true intent (i.e., user intent) of the user input query from the candidate intent list, and output the user intent and query together to the query parsing module. The LLM called here can be denoted as LLM-C, which takes user memory data and the candidate intent list as input and the user intent as output.

[0072] The query parsing module described above can determine necessary retrieval parameters based on user intent. Specifically, the query parsing module may include several sub-modules such as a contextual parameter recognition module, a second query module, and a personalized parameter value extraction module. The contextual parameter recognition module receives user intent and query from the intent understanding module and determines whether the query contains necessary retrieval parameters and whether the values ​​of those parameters are available. It is understood that necessary retrieval parameters in a query are not necessarily available. For example, in the query "take a taxi to Beijing," the destination is one of the necessary retrieval parameters, and the query contains the value "Beijing," but this is not actually a specific destination; therefore, the value of this necessary retrieval parameter is unavailable. Optionally, the contextual parameter recognition module can call LLM (denoted as LLM-D) to perform the above judgment. The second query module can call the long-term user memory data retrieval module and the short-term user memory data retrieval module in the tool module to query personalized information to obtain user memory data containing the necessary parameter values ​​for the retrieval service items. The personalized parameter value extraction module can extract the values ​​of necessary search parameters from the results queried by the second query module using LLM (denoted as LLM-E), and then the server can modify the query based on the necessary search parameters.

[0073] The aforementioned recall module can be used to retrieve the service items needed by the user from a massive service database based on the modified query. The aforementioned sorting module can be used to sort the multiple service items output by the recall module.

[0074] It is understood that in the above retrieval system, the LLM-A to LLM-E called by the module can be independently trained LLMs, or they can be integrated into one or more comprehensive LLMs. This application does not impose any special restrictions on the specific form, structure, or integration of all LLMs mentioned herein.

[0075] The following section, using the system architecture described above, details the process from receiving a user's query input to returning a service item on the electronic device interface:

[0076] Understandably, before receiving the aforementioned query input, the knowledge recall engine in the device can collect user data from various applications through a data subscription module. Optionally, the knowledge recall engine in the device can directly perform intelligent summarization based on the subscribed user data to obtain short-term user memory data. In addition, after obtaining the user's initial authorization, the device can also send the user data to a cloud-based server and summarize long-term user memory data based on the aforementioned user data.

[0077] At this point, the device on the edge stores a set of short-term user memory data, while the server on the cloud stores a set of long-term user memory data. For example, the knowledge recall engine can extract the following information from subscribed user data as short-term user memory data based on LLM: "I'm going to travel to location A next week" from call logs, "[XX Takeout] Your takeout order is being delivered" from SMS messages, "15:00-17:00 Airport A Terminal 3 - Airport B Terminal 1" from daily reports, and "My son attends Middle School A" from WeChat chat logs. For example, the server can store the following long-term user memory data: the user is a travel enthusiast; the user prefers to travel by high-speed train; the user works at company A.

[0078] When an electronic device on the endpoint receives a user's query, it can retrieve relevant short-term user memory (STM) data based on the query and send the query and related STM data to the cloud-side server. Specifically, after the user inputs a query, it is sent to a query analysis module for query rewriting and scene recognition. After scene recognition, the query analysis module performs parameter analysis based on the results to determine necessary retrieval parameters. Subsequently, the query analysis module generates the first request based on the rewritten query and the necessary retrieval parameters and sends it to the knowledge recall engine. Upon receiving the first request, the knowledge recall engine retrieves the STM data related to the query from the STM data set and returns the retrieved STM data to the query analysis module. After receiving the STM data returned by the knowledge recall engine, the query analysis module aggregates the user-input query and related STM data and uploads it to the cloud-side server via an aggregation cloud-side module. Understandably, the query analysis module can obtain results from multiple scenario recognitions, and the knowledge recall engine can retrieve short-term user memories related to the query in each scenario. Ultimately, these short-term user memories will be sent to the cloud server along with the query.

[0079] For example, a user can input the query "Ice and Snow World". After receiving the query, the query analysis module can rewrite it as "Please retrieve short-term user memory data related to Ice and Snow World", identifying the scenario as "information learning" or "travel". The parameter analysis module can then output the necessary retrieval parameters for each scenario to the request generation module. For example, in the "information learning" scenario, the necessary retrieval parameters output by the parameter analysis module to the request generation module could be "location and date". Subsequently, the request generation module can generate the following first request: "Request to retrieve short-term user memory data related to 'Ice and Snow World', especially involving location and date information". Upon receiving the first request, the knowledge recall engine can retrieve and return the relevant short-term user memory data, such as the user's chat history today: "Need to organize the visitor flow data of Ice and Snow World on January 1st to support the paper". Then, the query analysis module can send the query "Ice and Snow World" and the retrieved short-term user memory data "Need to organize the visitor flow data of Ice and Snow World on January 1st" to the cloud server.

[0080] Understandably, for some scenarios where it is difficult to directly determine the necessary search parameters, such as "travel", it can be further subdivided into sub-scenarios such as "travel-travel ticket booking", "travel-ticket booking", and "travel-hotel reservation". After determining the "travel" scenario, the query analysis module can break it down into multiple sub-scenarios and determine the necessary search parameters for each sub-scenarios based on each sub-scenarios.

[0081] After obtaining the query and related short-term user memory data from the aggregation cloud module, the server can modify the query based on the user memory data on the server, and then recall service items based on the modified query. Understandably, the modified query better reflects the user's true intent when entering the query.

[0082] Specifically, upon receiving a query, the server can input the query into the intent understanding module. This module can then call the NLU intent interface to obtain a list of candidate intents corresponding to the query. Furthermore, the intent understanding module can retrieve user memory data related to the query by searching the long-term and short-term user memory data stored on the server. Subsequently, the intent understanding module can use LLM (Local Level Management) to combine the query-related user memory data with the determined user intent from the candidate intent list. Finally, the intent understanding module can compare the query with the determined user intent... Figure 1 And output it to the query parsing module.

[0083] Figure 4 This is a schematic diagram illustrating an intent-based understanding process provided in an embodiment of this application. For example... Figure 4 As shown, continuing the example above, if the original query sent by the electronic device to the cloud server is "Ice and Snow World", then the intent understanding module can first obtain the candidate intent list "tourism, information" corresponding to "Ice and Snow World" based on the intent recognition service on the server. (Understandable, optional) Figure 4 The intent recognition service shown can be provided solely by Figure 3 The NLU intent interface is provided in [the framework / platform]. It is not limited to, for example... Figure 3 The NLU intent interface shown is as follows: Figure 5 As shown, the aforementioned intent recognition service can also be provided by an offline LLM intent caching module. Specifically, as... Figure 5The offline LLM intent caching module described above can perform offline LLM intent determination using cached query data and pre-caches the correspondence between cached queries and the determined intents in the server. Subsequently, upon receiving a user-input query, the offline LLM intent caching module compares the user-input query with the cached query data. If there is a matching query in the cached query data (i.e., the input query matches the cached query data), the module can directly retrieve that query data to pre-determine the candidate intent list. It is understandable that the offline LLM intent caching module implements intent determination based on LLM, thus making the generated candidate intent list more accurate than the candidate intent list returned by the NLU intent interface. Therefore, when the intent recognition service includes both the offline LLM intent caching module and the NLU intent interface, if the input query matches the cached query data, the intent recognition service returns the candidate intent list output by the offline LLM intent caching module; if the input query does not match the cached query data, the intent recognition service calls the NLU intent interface to return the candidate intent list. Understandably, regardless of whether the aforementioned intent recognition service is provided by the offline LLM intent caching module or by the NLU intent interface, the list of candidate intents returned by the intent recognition service is unrelated to the user's user memory data.

[0084] Upon receiving the aforementioned query, the intent recognition module can also invoke the long-term user memory data retrieval module and the short-term user memory data retrieval module within the tool module to retrieve user memory data. For example, the intent recognition module can determine the user's profile as a travel enthusiast based on the retrieval of long-term user memory data, and can determine the user's recent search behavior for travel guides based on the retrieval of short-term user memory data. Subsequently, the intent recognition module can utilize LLM to determine the user's true search intent as "travel" from the aforementioned candidate intent list based on the retrieved user profile and the user's travel guide search behavior.

[0085] Understandably, the search intent identified by the intent recognition module through the above process can be recorded as the primary intent, and the aforementioned intent graph is used to indicate the most direct search intent when the user inputs a query. Optionally, after obtaining the intent graph, the server can also perform private domain data retrieval (i.e., retrieval of the private domain database) based on RAG technology to obtain extended intents and extended queries. These extended intents are also called secondary intents. Specifically, such as... Figure 4As shown, after determining the main idea to be "tourism," the intent recognition module can retrieve query-related information from the private domain database based on the user's original query. For example, it can retrieve the comment "It's too cold in Northeast China, I need a 300g down jacket" from the private domain database. This private domain database is also called the private domain dataset. At this point, the intent recognition module can generate the corresponding extended intent "shopping" and the extended query "300g down jacket" based on the retrieved comment. The result of modifying the extended query after the query parsing step is called the fourth search term, and the search results returned by the server based on the fourth search term are called the third search results. The extended query generated before modification is called the fifth search term, and the search results returned by the server based on the fifth search term are also called the fourth search results. Compared to the fourth search results, the third search results have a higher relevance to the user's memory data. The relevance discussed in this paper can be determined by a large language model. Optionally, the above generation process can be implemented using a pre-trained LLM (e.g., LLM-F). After the extended intent and extended query are generated, they will be input into the query parsing module by the intent recognition module. Subsequent processing of the extended intent and extended query is the same as processing of the main graph and the original query. It can be understood that the process of generating the extended query is actually modifying the user-input query based on the necessary search parameters associated with the second intent (also called the second search parameters) to obtain the fourth search term. The fourth search term includes the values ​​of the second search parameters, while the first search term lacks the values ​​of the second search parameters.

[0086] Figure 7 This is a schematic diagram of an architecture for contextualized query parsing provided in an embodiment of this application. It can be understood that the purpose of the query parsing module performing the contextualized query parsing step is to obtain the values ​​of necessary retrieval parameters, so that the server can modify the query to serve subsequent retrieval steps.

[0087] like Figure 6 As shown, the query parsing module in the server can determine the necessary search parameters for the given scenario based on the user's search intent obtained from the intent recognition module. Then, it uses ReAct to accurately identify whether the query contains necessary search parameters and whether the values ​​of those parameters are available. If a necessary search parameter's value is unavailable, it calls upon the user's memory data to fill in the missing value, thus achieving precise parsing of the necessary search parameter values ​​from the query. The server can then modify the query based on these necessary search parameter values ​​obtained from the query parsing module. This is understandable. Figure 6 The part within the dashed box is Figure 3 The contextual parameter recognition module in query parsing is responsible for this. Figure 6 The task execution (i.e., calling this tool module to query and obtain action results) is handled by... Figure 3 The second query module in the process is executed from... Figure 6 The values ​​of the necessary retrieval parameters obtained from the action results are determined by... Figure 3 The personalized parameter extraction module is executed.

[0088] Specifically, the query parsing module takes the query and the user's search intent as input, and the server can determine the necessary search parameters for that scenario based on the user's search intent. Understandably, the necessary search parameters corresponding to different search intents can be predetermined by the developers and pre-stored in the server. Optionally, a mapping table can be used to store the user's search intent and the aforementioned necessary search parameters in the server.

[0089] After confirming the necessary search parameters, the query parsing module can determine their values ​​using the ReAct method. Specifically, the ReAct method can be divided into three sub-steps: observation, thought, and action. The observation step can use Natural Language Processing (NLP) techniques (such as LLM) to determine whether the user-input query contains the values ​​of the necessary search parameters and whether those values ​​can be used to retrieve service items. Understandably, if the user-input query does not contain the necessary search parameters, their values ​​can be set to null; a null value can be considered a special case where the obtained necessary search parameter value cannot be used to retrieve service items. If, in the observation step, the query parsing module determines that the user-input query contains a necessary search parameter value that can be used to retrieve service items, then in the thought step, the query parsing module can generate a first instruction, which instructs the direct output of the necessary search parameter value. If, during the observation step, the query parsing module determines that the user-input query does not contain the necessary search parameter values ​​for retrieving service items, then during the thinking step, the query parsing module can generate a second instruction. This second instruction instructs the calling of a function in the tool module to further parse and obtain the values ​​of the aforementioned necessary search parameters. For example, this second instruction could instruct the calling of the long-term user memory data retrieval module and the short-term user memory data retrieval module of the tool module to supplement the necessary search parameters. This is not limited to the long-term user memory data retrieval module and the short-term user memory data retrieval module; other modules capable of providing the values ​​of the aforementioned necessary search parameters, such as... Figure 6 The point of interest agent (POIAgent) can also be invoked by the query parsing module. Subsequently, query parsing can act based on the results of the thinking process (i.e., the first instruction or the second instruction).

[0090] Continuing with the example above, the intent recognition module can output the query "Ice and Snow World" and the user's search intent "Tourism" to the query parsing module. It's understandable that when a user's search intent is "Tourism," this intent can include multiple sub-intents, which can then be used to return multiple service search items to the user. For example, the sub-intents of "Tourism" include, but are not limited to, travel ticket booking and hotel reservation. The user's search intent can be understood as scene recognition performed by the server; therefore, the sub-intents can also be understood as the aforementioned subdivided scenes. It's understandable that both the client-side and cloud-side can perform scene recognition or intent understanding, but because the computing power of the cloud side is far greater than that of the client side, the results obtained by the cloud-side server when performing intent understanding and scene parameter recognition will be more refined and accurate.

[0091] The following explanation will use travel ticket booking as an example.

[0092] The query parsing module can determine the necessary search parameters for the sub-intent "travel booking" as "departure location, destination, mode of transport, and travel date". Subsequently, the query parsing module can determine the values ​​of these necessary search parameters one by one using the ReAct method described above. The following example of determining the necessary search parameter "mode of transport" illustrates how the ReAct method is used to determine its value. The process for determining the values ​​of other search parameters is similar and will not be repeated here.

[0093] Specifically, the query parsing module can determine, through observation, that the query "travel mode" does not exist in the original query "Ice and Snow World," meaning the parameter value for "travel mode" is empty. Based on this observation, the query parsing module can then deduce the second instruction, which can be used to instruct the query parsing module to call one or more sub-modules within the tool module. Understandably, the query parsing module may include multiple sub-modules within the tool module in the process of generating the second instruction. Optionally, the query parsing module can call these sub-modules one by one until the necessary search parameter value is retrieved or all sub-modules have been called.

[0094] The following uses Figure 7 This will further explain the specific process by which the query parsing module obtains the necessary search parameter values ​​through the tool module.

[0095] like Figure 7As shown, the query parsing module in the metaservice retrieval agent can convert a user's query into the following code instruction: "Ice and Snow World. Please complete all the information required for this service in the 'Tourism - Travel Ticketing' scenario." Subsequently, the metaservice retrieval agent can go through the following thought process: it needs to know the travel mode, infers that the <Short-Term User Memory Data Retrieval Module> and <Long-Term User Memory Data Retrieval Module> can retrieve this information, and generates the current search prompt.

[0096] Subsequently, the metaservice retrieval agent can proceed to the action steps. For example, the metaservice retrieval agent can generate and execute two tasks. Specifically, the metaservice retrieval agent can first generate the following instructions to invoke the short-term user memory data retrieval module: It needs to know the travel method, infers that <short-term user memory data retrieval> can retrieve this information, and generates a retrieval prompt for <short-term user memory data retrieval>. For example... Figure 6 As shown, if there is no short-term user memory data related to "travel mode" in the short-term user memory data, the short-term user memory data retrieval module can return "No relevant data found". At this time, the meta-service retrieval agent can generate the following instructions to call the long-term user memory data retrieval module: It needs to know the travel mode; the short-term user memory data retrieval module cannot retrieve this information, so it is speculated that the long-term user memory data retrieval module may store this information; if it still cannot find it, then the information is defaulted; generate a retrieval prompt for the long-term user memory data retrieval module. The aforementioned long-term user memory data retrieval module can return that the user's commonly used travel mode is high-speed rail, based on the long-term user memory data stored on the cloud side.

[0097] The metaservice retrieval agent can summarize the retrieved information (i.e., the action result) and determine whether the above process can be fully executed. Specifically, it re-executes the observation, thinking, and action steps based on the travel mode returned by the long-term user memory data retrieval module. Understandably, the travel mode of high-speed rail can already be used to retrieve the service item; that is, the value of the travel mode parameter can be used to supplement the original query. Therefore, after re-executing the above thinking steps, the metaservice retrieval agent directly outputs the value of the necessary retrieval parameter: "Travel Mode: High-Speed ​​Rail".

[0098] Understandably, in the query parsing process described above, the LLM used by the query parsing module is not general-purpose, but rather fine-tuned from a general-purpose LLM. Optionally, the LLM used by the query parsing module can be obtained through supervised fine-tuning (SFT) of a general-purpose LLM. Specifically, the aforementioned LLM can be obtained through supervised training based on a general-purpose LLM using fine-tuning data prepared in advance by the developers.

[0099] After determining the values ​​of the necessary retrieval parameters using the ReAct method described above, the server can recall and sort service items based on these necessary retrieval parameters.

[0100] The aforementioned recall refers to the server filtering out service items relevant to the user's query from a massive number of service items. For example... Figure 3 As shown, optionally, the server can match the modified query text content with the service item description, recalling service items based on keywords, phrases, or semantic similarity. Optionally, the server can use a vector-based method to convert the query and candidate service items into vector representations, recalling service items by calculating the similarity between vectors. Not limited to the above methods, this application embodiment does not specifically limit the specific method by which the meta-service retrieval proxy in the server implements recall. For example... Figure 3 As shown, the server can sort the retrieved results. Optionally, the sorting module can sort the service items based on semantic relevance or textual relevance. Optionally, the sorting module can perform personalized sorting of the service items based on a knowledge graph. Subsequently, the server can return the sorted service item results to the terminal electronic device, and the electronic device can display the results on the interface.

[0101] In the above methods, the sorting step can also be performed by the edge electronic device instead of the cloud-side server. Specifically, after the recall step, the server can return the entire set of recalled service items to the edge electronic device, which can then sort the received service item set. Similarly, the electronic device can sort the service items based on relevance or based on a knowledge graph. Understandably, some user data that is highly sensitive to user privacy is difficult to upload to the cloud server with user authorization. Therefore, this user data cannot participate in the cloud server's sorting of the service items. If the edge electronic device performs the sorting step, the electronic device can utilize this highly sensitive user data to sort the service items, resulting in a final sorting result that is more relevant to the user's personalized data, meaning the sorting result better meets the user's needs.

[0102] Of the above methods, optionally, the user can choose to... Figure 2 Enter your query in the search box on the negative one screen or other interfaces. Optionally, you can also enter your query via voice input. For example, you can perform the above search by voice while conversing with a smart voice assistant, allowing the electronic device to display services related to the voice content.

[0103] The above method is predicated on the electronic device receiving user authorization (also known as first authorization). This authorization allows the electronic device to upload subscribed user data to the cloud, thereby leveraging the computing power of the cloud server to more accurately determine the user's search intent and modify the query, resulting in more personalized search results. Therefore, it is understandable that before the first authorization is activated, the electronic device can display the first search result upon receiving the first search input. After the first authorization is activated, the electronic device can receive the second search input and display the second search result. Even if the search terms in the second search input are the same as those in the first search input, the second search result may differ from the first search result. Furthermore, compared to the first search result, the second search result has a higher relevance to the user's memory data (or personalized user data), meaning the search results obtained after executing the search method provided in this application are more closely matched to the individual user. The search terms in the second search input are also called the first search terms, i.e., the query received by the electronic device after the first authorization is activated. The search terms in the first search input are also called the third search terms.

[0104] Furthermore, the server can modify the query by combining user memory data from the user data uploaded from the client side, that is, modify the first search term to obtain a second search term. Finally, the server can return the second search result based on the second search term. Therefore, not only can the electronic device obtain different search results based on the same search term before and after authorization, but also, the search results obtained after obtaining the first authorization using a simplified search term can be the same as the search results obtained before obtaining authorization using the complete search term. For example, taking hotel booking as an example, without the aforementioned first authorization, the electronic device can display hotels in city A (the user's city) based on the search term "hotel," and can display hotels in city B based on the search term "hotel in city B." If the electronic device has a schedule of "going on a business trip to city B next week," then after obtaining the aforementioned first authorization, the electronic device can return hotels in city B based on the search term "hotel," which is consistent with the search results when the search term was "hotel in city B" without authorization. This demonstrates that, after authorization, the user's search term was modified from "hotel" to "city B hotel," indicating that this method can improve the relevance of search results to the user's personalized data by modifying the user's search term.

[0105] Understandable. Figure 3 This is merely a schematic diagram of an exemplary retrieval system architecture, and is not limited to... Figure 3The system architecture shown can further include a module in the terminal electronic device for summarizing and retrieving long-term user memory data. This allows the terminal electronic device to retrieve relevant long-term user memory data upon receiving a query and upload it to the cloud server. The aforementioned query-related long-term user memory data and query-related short-term user memory data (i.e., the aforementioned first short-term user memory data) can also be collectively referred to as relevant user memory data. In other words, the terminal electronic device can determine relevant user memory data from the aforementioned first user data based on the query and send this relevant user memory data to the cloud server.

[0106] Understandably, the reason for uploading the aforementioned user memory data to the cloud server is that the cloud server can provide stronger computing power, making the user's search intent and supplementary necessary search parameters determined during the execution of the above methods more accurate. In other words, with the continuous improvement of electronic devices, when the electronic device itself can provide sufficient computing power to implement the above steps, the electronic device can independently perform the following steps: receiving user input queries, intent recognition, query parsing, recall, sorting, and display.

[0107] Figure 8 This is a schematic diagram of the hardware structure of an end-side electronic device provided in an embodiment of this application.

[0108] like Figure 8 As shown, the electronic device may include components such as a processor 211, a memory 212, a wireless communication processing module 213, a power switch 214, a display screen 215, an audio module 216, and a speaker 217. The components in the electronic device are connected to each other via a bus and communicate based on the bus.

[0109] Processor 211 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.

[0110] Memory 212 is coupled to processor 211 and is used to store various software programs and / or multiple sets of instructions. Memory 212 can be used to store computer executable program code, which includes instructions. Processor 211 executes various functional applications and data processing of the electronic device by running the instructions stored in memory 212. Memory may also be provided in processor 211 for storing instructions and data.

[0111] The memory 212 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM). The RAM can be directly read and written by the processor 211. The RAM can be used to store executable programs (e.g., machine instructions) of the operating system or other running programs, as well as user and application data. The NVM can also store executable programs and user and application data. Executable programs, i.e., user data, stored in the NVM can be pre-loaded into the RAM for direct reading and writing by the processor 211.

[0112] The executable program code and user data used to implement the retrieval method provided in the embodiments of this application can be stored in non-volatile memory. During the implementation of the above retrieval method, the electronic device can load the non-volatile memory executable program code and user data into random access memory to provide users with an efficient, accurate, and personalized retrieval experience.

[0113] The wireless communication processing module 213 can provide wireless communication solutions including WLAN (such as Wi-Fi), Bluetooth communication, ZigBee communication, NFC communication, infrared communication, and UWB communication. In this embodiment, the electronic device can send various data to the server based on the wireless communication functions provided by the wireless communication processing module 213, including but not limited to user-input queries, short-term user memory data, and user data. The electronic device can also receive service items returned from the server based on the wireless communication processing module 213.

[0114] The power switch 214 can be used to control the power supply to electronic devices, thereby supplying power to the processor 211, memory 212, wireless communication processing module 213, display screen 215, audio module 216, speaker 217, etc.

[0115] A display screen 215 is used for display. The display screen 215 includes a display panel. A touch sensor can be installed in the display screen 215. The touch sensor is used to detect touch operations applied to or near it. The touch sensor can transmit the detected touch operation to an application processor to determine the type of touch event. Furthermore, the electronic device can provide visual output related to the touch operation through the display screen 215. The electronic device can implement display functions through a GPU, display screen 215, touch sensor, and application processor. In this embodiment, the electronic device can display a user interface for a search service through the display functions provided by the GPU, display screen 215, touch sensor, and application processor, allowing users to perform operations such as search input, reading search results, and querying search results.

[0116] Audio module 216 can be used to convert digital audio signals into analog audio signals for output, and can also be used to convert analog audio input into digital audio signals. Speaker 217 can be used to convert the audio signals transmitted by audio module 216 into sound signals. Electronic devices can implement audio playback functions through audio module 216, speaker 217, etc. In some embodiments, audio module 216 may also include a microphone for converting sound signals into electrical signals. In this embodiment, electronic devices can use the microphone to collect ambient sound signals, generate voice packets, and then use the voice packets to retrieve input.

[0117] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. Components may be implemented in hardware, software, or a combination of software and hardware.

[0118] Figure 9 This is a schematic diagram of the hardware structure of a cloud-side server provided in an embodiment of this application. Compared to edge-side electronic devices, cloud-side servers can include fewer components.

[0119] like Figure 9 As shown, the cloud-side server may include a processor 311, a memory 312, a wireless communication processing module 313, and a power switch 314, etc.

[0120] The memory 312 is coupled to the processor 311 and is used to store various software programs and / or multiple sets of instructions. The processor 311 executes various functional applications and data processing of the server by running the instructions stored in the memory 312, such as intent recognition, query parsing, recall, and sorting.

[0121] Corresponding to wireless communication processing module 313 Figure 8The wireless communication processing module 213 is shown. The wireless communication processing module 313 can provide communication services equivalent to the wireless communication processing module 213. In this embodiment, the server can receive various data from the terminal electronic device based on the aforementioned wireless communication processing module 313, and can also return search results to the terminal electronic device based on the aforementioned wireless communication processing module 313.

[0122] The power switch 314 can be used to control the power supply to electronic devices, thereby supplying power to the processor 311, memory 312, wireless communication processing module 313, etc.

[0123] Similarly, Figure 9 The schematic diagram shown is only an example and should not be construed as a specific limitation on the server.

[0124] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer. Embodiments of this application also provide a computer program product, including a computer program that, when run on a processor, implements the steps in the various method embodiments described above.

[0125] The above detailed embodiments further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A retrieval method, characterized in that, A first electronic device applied in a first communication system, the first communication system further comprising a server, the method comprising: The first electronic device receives the first search input; The first electronic device displays the first search result; The activation of the first authorization is detected. The first authorization is used to upload the first user data on the first electronic device to the server. The first electronic device receives a second search input, wherein the search terms in the second search input are the same as those in the first search input. The first electronic device displays a second search result, which is different from the first search result. Compared with the first search result, the second search result is more relevant to the first user data.

2. The method according to claim 1, characterized in that, The first user data comes from one or more of the following: the user's input in the first application in the most recent first time period, the user's schedule in the most recent first time period, the user's call content in the most recent first time period, the user's chat history in the most recent first time period, user profile, and dialogue between the user and the intelligent voice assistant.

3. The method according to claim 2, characterized in that, After detecting that the first authorization has been enabled, the method further includes: The first electronic device sends the first user data to the server.

4. The method according to claim 3, characterized in that, The first electronic device sends the first user data to the server, specifically including: The first electronic device determines relevant user memory data from the first user data based on the second retrieval input; The first electronic device sends the relevant user memory data to the server.

5. The method according to any one of claims 1-4, characterized in that, Before the first electronic device displays the second search result, the method further includes: The second search result returned by the server is received.

6. The method according to any one of claims 1-5, characterized in that, The second search result is the search result for the second search term, which is obtained by modifying the first search term based on the first user data. The first search term is the search term input for the second search.

7. A retrieval method, characterized in that, The method is applied to a server in a first communication system, the first communication system further comprising a first electronic device, the method comprising: Receive first user data and first search terms sent by the first electronic device, wherein the first user data and first search terms are sent by the first electronic device when it obtains the first authorization; Based on the first user data, the first search term is modified to obtain the second search term; The second search result is returned to the first electronic device based on the second search term.

8. The method according to claim 7, characterized in that, The method further includes: Receive a third search term, which is the same as the first search term, and the third search term was sent by the first electronic device when it did not obtain the first authorization; The first search result is returned to the first electronic device based on the third search term; Compared to the first search result, the second search result is more relevant to the first user data.

9. The method according to claim 7 or 8, characterized in that, The step of modifying the first search term based on the first user data to obtain the second search term specifically includes: Based on the first user data and the first search term, a first intent is identified, and the first intent is used to determine the first search parameters; The first search term is modified according to the first search parameter associated with the first intent to obtain a second search term. The second search term includes the value of the first search parameter, while the first search term lacks the value of the first search parameter.

10. The method according to claim 9, characterized in that, Modifying the first search term according to the first search parameters associated with the first intent specifically includes: Determine the missing value of the first search parameter in the first search term based on the name of the first search parameter; The value of the first retrieval parameter is determined from the first user data; The second search term is obtained by adding the value of the first search parameter to the first search term.

11. The method according to claim 9 or 10, characterized in that, The step of identifying the first intent based on the first user data and the first search term specifically includes: A candidate intent list is obtained based on the first search term, wherein the candidate intent list has the highest relevance to the first search term; The first intent is determined from the candidate intent list based on the first user data, and the first intent is the intent in the candidate intent list that has the highest relevance to the first user data.

12. The method according to any one of claims 7-11, characterized in that, The method further includes: Based on the first user data and the private domain data set, the first search term is modified to obtain the fourth search term; The third search result is returned to the first electronic device based on the fourth search term.

13. The method according to claim 12, characterized in that, The method further includes: Based on the aforementioned private domain data set, the first search term is modified to obtain the fifth search term; The fourth search result is returned to the first electronic device based on the fifth search term; Compared to the fourth search result, the third search result is more relevant to the first user data.

14. The method according to claim 13, characterized in that, The step of modifying the first search term based on the first user data and the private domain data set to obtain the fourth search term specifically includes: A second intent is identified based on the private domain data set and the first search term, and the second intent is used to determine the second search parameters; The first search term is modified according to the second search parameter associated with the second intent to obtain the fourth search term, which includes the value of the second search parameter, while the first search term lacks the value of the second search parameter.

15. A retrieval method, characterized in that, Applied to a first system, the first system including a first electronic device and a server, the method includes: The first electronic device receives the first search input; The server receives the search terms input by the first electronic device. The server sends the first search result to the first electronic device based on the search terms entered in the first search. The first electronic device displays the first search result; The activation of the first authorization is detected. The first authorization is used to upload the first user data on the first electronic device to the server. The first electronic device receives a second search input, wherein the search terms in the second search input are the same as those in the first search input. The server receives the first search term and the first user data sent by the first electronic device, wherein the first search term is the search term input by the second search. The server modifies the first search term based on the first user data to obtain the second search term; The server returns a second search result to the first electronic device based on the second search term; The first electronic device displays the second search result, which is different from the first search result. Compared with the first search result, the second search result is more relevant to the first user data.

16. An electronic device, characterized in that, The method includes one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, the computer program code including computer instructions, which, when executed by the one or more processors, cause the method as described in any one of claims 1-7 or 8-15 to be performed.

17. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run on an electronic device, it causes the method as described in any one of claims 1-6 or 7-14 to be performed.

18. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-6 or 7-14.

Images