Method and electronic device for vertical search

Abstract

The application provides a method and an electronic device for vertical search, the method comprising: configuring different search templates for different scenes in advance, that is, configuring search rules for different scenes in advance, so that when a search word is received, a pre-configured search template matching the scene of the search word can be found, and a DSL statement is packaged based on the matching version and a search engine associated with the search engine is called to search. The scheme can meet different search requirements of different scenes in the whole search process, and the pre-configured search template is more conducive to subsequent updating and maintenance, and compared with a traditional scheme, the development time is shortened and the development cost is saved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electronic devices, and in particular to a vertical search method and an electronic device. BACKGROUND

[0002] The application of vertical field search, also known as vertical search, is becoming more and more widespread. In different vertical fields, it is impossible to avoid providing relevant search services when providing services to users, so it is necessary to quickly build search capabilities corresponding to different vertical data based on different vertical data.

[0003] In the traditional scheme, if a vertical search service is set on an electronic device, a specific search system must be built for each specific vertical field. This requires programmers to start from writing tedious code to complete the entire search system building process, which has a long development cycle and high personnel demand, resulting in high cost and long update cycle. Moreover, due to the continuous updating and upgrading of electronic devices, new search requirements may arise, and search requirements in different application scenarios may also differ in search focus. In the traditional scheme, these situations can only repeat the above development process to build new search systems, otherwise they cannot be searched.

[0004] Therefore, how to provide a better vertical search scheme that is easier to update and maintain is a technical problem to be solved. SUMMARY

[0005] The present application provides a vertical search method and an electronic device, which can be more conveniently updated and maintained, and adapt to different search requirements in different scenarios.

[0006] In a first aspect, a vertical search method is provided. The method includes receiving a search term from a second electronic device, the search term being input by a user in a search bar of an application running on the second electronic device; determining a scenario of the search term, the scenario of the search term including an application source and a scenario identifier; determining a target template matching the scenario of the search term from at least one preconfigured search template of at least one defined scenario, each defined scenario corresponding to at least one preconfigured search template; encapsulating the search term into a domain-specific language (DSL) statement according to an indication of the target template to obtain a target DSL statement; sending the target DSL statement to a search engine matching the target DSL statement to obtain a search result; and sending the search result to the second electronic device.

[0007] In the technical solution of the present application, different versions are configured in advance for different scenarios, that is, the retrieval rules of different scenarios are configured in advance, and then when the retrieval word is received, the pre-configured retrieval template matching the scenario of the retrieval word can be found, and a DSL statement is encapsulated based on the matching version and the associated search engine is called for retrieval, so that the entire retrieval process can meet the different retrieval requirements of different scenarios at the same time, and such a pre-configured retrieval template is more conducive to subsequent updating and maintenance, compared with the traditional scheme, the development time is shortened, and the development cost is saved.

[0008] In combination with the first aspect, in some implementations of the first aspect, when determining the target template matching the scenario of the retrieval word from at least one pre-configured retrieval template of at least one defined scenario, the method can include: when the target template is included in at least one pre-configured retrieval template cached in the cache space of the first electronic device, reading the target template from the cache space; or when the target template is not in the cache space of the first electronic device, reading the target template from the database. In this implementation, the target template is first searched in the local cache space of the first electronic device, and if the target template can be found in the local cache space, the target template is read from the local cache space first, and if the local cache space does not have the target template, the target template is searched and read from the database.

[0009] In one example, when the target template is not in the cache space of the first electronic device, the step of reading the target template from the database can include: when the target template is included in the database, reading the target template from the database; or when the target template is not in the database, generating exception indication information and sending the exception indication information to the second electronic device. When the target template is read from the database, if the database has the target template, the target template can be read, and if the database does not have the corresponding version, the retrieval needs to be ended and the second electronic device needs to be informed of the exception.

[0010] In combination with the first aspect, in some implementations of the first aspect, the method further includes: after the first template is read from the database for the first time, storing the first template in the cache space of the first electronic device, the first template being any one version of all pre-configured retrieval templates in the database. In this implementation, the target template can be found more quickly by storing the first template in the local cache space after the first template is read from the database for the first time.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: when the number of times the second template is read from the database within a preset time period is greater than or equal to a preset threshold, storing the second template in the cache space of the first electronic device. In this implementation, a threshold is set for the version cached locally; only frequently used versions are stored in the local cache space. This reduces the occupation of local cache space while ensuring a certain degree of convenience in finding the target template more quickly later.

[0012] In conjunction with the first aspect, some implementations of the first aspect may include the following when sending the target DSL statement to a matching search engine for retrieval: performing template parameter validation on the target DSL statement; if the parameter validation is successful, sending the target DSL statement to the matching search engine for retrieval; or, if the parameter validation fails, generating an exception indication message and sending it to a second electronic device. This implementation adds validation of the encapsulated DSL statement to prevent retrieval failure due to errors in the encapsulated data. If the validation fails, the retrieval is terminated and the second electronic device is notified of the exception.

[0013] In conjunction with the first aspect, in some implementations of the first aspect, before determining the target template, the method further includes: defining at least one scenario, and for each scenario, creating at least one pre-configured retrieval template for that scenario; and sending the defined scenario and the created pre-configured retrieval template corresponding to that scenario to a database for storage. In this implementation, scenarios and pre-configured retrieval templates need to be pre-defined and created, and then stored in the database so that this data can be retrieved from the database later. The database plays a centralized management role, increases version storage capacity, and effectively reduces storage pressure in local storage scenarios.

[0014] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: when no target template is found from either the cache space of the first electronic device or from the database, displaying a prompt message on the screen of the first electronic device. This prompt message instructs the operator to add a definition for the scenario corresponding to the search term and to create a search template for that scenario. In this implementation, if no target template can be found at all, a prompt may also appear indicating that a new search template needs to be created for that scenario.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, each pre-configured search template includes a scene identifier and a DSL statement format. The scene identifier includes a scene code and / or a scene name, and the DSL statement format includes keywords and a type. The scene code and scene name can be seen as examples of different scene identifiers, and the two can also be used together. The DSL statement format is mainly used to guide what content to encapsulate and how to encapsulate it.

[0016] In one example, each pre-configured search template also includes at least one of the following: a version identifier, an associated index, and an application source identifier. The associated index includes the index library corresponding to the pre-configured search template. The version identifier can be understood as distinguishing different versions within the same scenario. However, it should be understood that although a scenario can have multiple versions, only one version of a scenario can be online at any given time; otherwise, it would be impossible to determine which target template to use. The index can be understood as a pre-created directory or link to an index library. Each pre-configured search template will have an associated index used to determine the index library corresponding to that pre-configured search template.

[0017] In conjunction with the first aspect, in some implementations of the first aspect, the above method further includes: version control for each pre-configured search template in both sandbox and online environments; version control in the sandbox environment includes at least one of the following: creating new versions, deploying created versions online, editing existing versions, and deleting existing versions; version control in the online environment includes taking deployed versions offline. Controlling version creation and maintenance in the sandbox effectively prevents impact on ongoing search operations (existing operations), ensuring that versions are only deployed online after being created or modified in the sandbox.

[0018] Version control in an online environment can also include deleting versions that have been taken offline.

[0019] In one example, version control also includes control based on the version status of each pre-configured search template, including: Editing, Live, Not Live, and Offline. Editing could occur during creation or after creation. Not Live means the template has been created or modified but not yet live. Offline means the template has been live and has been taken offline.

[0020] In one example, editing and deleting an existing version is performed when the version is offline or offline. If the version is still online, modifying or deleting it will inevitably make the search service unusable. Therefore, editing or deletion can only be performed when the version is offline or offline, and this must be done in a sandbox environment.

[0021] In a second aspect, an apparatus for performing vertical category retrieval is provided, the apparatus comprising units consisting of software and / or hardware for performing any of the methods of the first aspect.

[0022] Thirdly, an electronic device is provided, including a memory, one or more processors, and a computer program stored in the memory and executable on the processor, wherein when the one or more processors execute the computer program, the electronic device is enabled to implement any of the methods of the first aspect.

[0023] Fourthly, a chip is provided, including a processor for reading and executing a computer program stored in a memory, such that when the computer program is executed by the processor, the electronic device in which the chip resides is able to implement any of the methods of the first aspect.

[0024] Optionally, the chip also includes a memory electrically connected to the processor.

[0025] Optionally, the chip may also include a communication interface.

[0026] Fifthly, a computer-readable storage medium is provided that stores a computer program, which, when executed by an electronic device, can implement any of the methods of the first aspect.

[0027] In a sixth aspect, a computer program product is provided, comprising a computer program that, when executed by an electronic device, can implement any of the methods of the first aspect. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of a vertical category retrieval system according to an embodiment of this application.

[0029] Figure 2 This is a schematic flowchart illustrating a vertical category retrieval method according to an embodiment of this application.

[0030] Figure 3 This is an interactive diagram illustrating a defined retrieval scenario according to an embodiment of this application.

[0031] Figure 4 This is a schematic diagram of the interface interaction for version control in a sandbox environment according to an embodiment of this application.

[0032] Figure 5 This is a schematic diagram of the interface interaction for version control in an online environment according to an embodiment of this application.

[0033] Figure 6 This is a schematic diagram of a version state transition logic according to an embodiment of this application.

[0034] Figure 7 This is a schematic flowchart illustrating another vertical category retrieval method according to an embodiment of this application.

[0035] Figure 8 This is a schematic diagram of a vertical category retrieval system according to an embodiment of this application.

[0036] Figure 9 This is a schematic diagram of a vertical category retrieval device according to an embodiment of this application.

[0037] Figure 10 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0038] The embodiments of this application will now be described in conjunction with the accompanying drawings.

[0039] Figure 1 This is a schematic diagram of a vertical category retrieval system according to an embodiment of this application. For example... Figure 1 As shown, electronic device A can be a server or a computer, used to execute the steps performed by the first electronic device in the embodiments of this application, and can be regarded as an example of the first electronic device below. Electronic device B can be a terminal device such as a mobile phone, tablet computer, or laptop computer, and can be regarded as an example of the second electronic device below.

[0040] For ease of understanding, we will use electronic device A as a cloud server and electronic device B as a mobile phone as an example. Electronic device A can store or retrieve data from a database (DB), and can also call a search engine to perform searches and receive search results.

[0041] An application, C, runs on the phone. When the user enters a search term in the search bar of application C, the search term is sent to the cloud server, along with the application and context from which the search term originates. After receiving the search term, the cloud server finds a matching search template based on the context, and then encapsulates the domain-specific language (DSL) statement according to the instructions of the search template. After encapsulation, it can call the corresponding search engine to perform the search, and then send the search results back to the phone. At this point, the search is complete.

[0042] A search template can be understood as a workflow (work instructions) for the search process, a guide for the search process, a search rule, or a search format.

[0043] However, if you switch to another application and enter new search terms, the process remains the same, only the matching versions found will be different, which may lead to a different search engine and thus different search results. Similarly, if you enter new search terms in another scenario (corresponding to a different interface) within application C, the process is identical, but the matching versions found will be different, leading to a different search engine and different search results.

[0044] This application's embodiments primarily address the problem that traditional solutions can only adapt to the retrieval needs of one scenario per retrieval system, leading to inconvenience in updating and maintaining, as well as high development or maintenance costs and long development times. By pre-configuring suitable search versions for different scenarios, it is possible to adapt to the retrieval needs of different scenarios simultaneously, and updates and maintenance are more convenient and less costly.

[0045] Figure 2 This is a schematic flowchart illustrating a vertical category retrieval method according to an embodiment of this application. The following is a description of... Figure 2 The steps shown are described below. This method is applied to a first electronic device, which can be a cloud server or other electronic device capable of scene definition and version control, as well as capable of calling a search engine.

[0046] S201. Receive a search term from a second electronic device, which is entered by a user in the search bar of an application running on the second electronic device.

[0047] The second electronic device can be, for example, a mobile phone, a tablet, etc., as long as it can provide a vertical category search service. As for the application running, there are no restrictions as long as it can provide a vertical category search service. For example, it could be a sports and health application or a smart space application, etc., as listed below.

[0048] Once the user enters the search terms, the search terms can be sent to the first electronic device through the communication interface of the second electronic device.

[0049] S202. Determine the scenario of the search term. The scenario of the search term includes the application source and scenario identifier of the search term.

[0050] A scenario can be understood as corresponding to a business, or a specific business within an application. For example, different sections (businesses) within an audio-visual application, such as songs, short videos, and web browsing, can all be considered a business. When a user enters the same search term in different sections, they can still find different resources. Another example is a health application, which might include sections like weight loss and body shaping. If a user searches for "running" in the weight loss section, they might find results on how to lose weight through running. In the body shaping section, searching for "running" might yield results on how to build muscle through running. In this example, running in the weight loss section might involve fast running or alternating fast and slow running, while in the body shaping section, it might focus more on fast running or weighted running. When searching, the search term and keywords (titles) need to be compared. The search results may be divided into multiple result groups, or understood as types or categories. Grouping can be based on data carrier type, such as video, audio, and text; or on content category, such as a health application grouping content into courses, sharing, and check-in categories. Other cases will not be listed individually.

[0051] As the examples above demonstrate, retrieval needs differ across scenarios, which can be understood as requiring different knowledge bases. Therefore, matching scenarios with vertical categories is more suitable for the retrieval needs of different businesses within various applications on electronic devices. Other cases will not be listed individually.

[0052] The application source can be understood as which application reported the search terms. The scenario identifier can be understood as the type of scenario, which can be a business name or a custom text or character identifier, as long as it can distinguish different search scenarios.

[0053] S203. From at least one pre-configured search template of at least one defined scenario, determine the target template that matches the scenario of the search term, wherein each defined scenario corresponds to at least one pre-configured search template.

[0054] By pre-creating pre-configured search templates corresponding to different scenarios, once the scenario of the received search terms is determined, a matching version, or target template, can be found from these pre-configured search templates. One scenario can correspond to one or more pre-configured search templates.

[0055] These pre-configured search templates can be centrally stored in a database for easy centralized management and use, and retrieved from the database when needed. Alternatively, one or more potentially used versions can be stored locally on the first electronic device for easy access later, eliminating the need to retrieve data from the database each time.

[0056] For an explanation of the version, please refer to [link / reference].Figure 1 The relevant content will not be repeated.

[0057] In one implementation, step S203 may include: when at least one pre-configured retrieval template cached in the cache space of the first electronic device contains a target template, reading the target template from the cache space; or, when the cache space of the first electronic device does not contain a target template, reading the target template from the database (DB). In this implementation, the target template is first searched for in the local cache space of the first electronic device. If the target template can be found in the local cache space, it is preferentially read from the local cache space; otherwise, it is searched and read from the database.

[0058] In one example, when the target template is not in the cache of the first electronic device, the step of reading the target template from the database may include: if the database contains the target template, reading it from the database; or, if the database does not contain the target template, generating an exception indication message and sending it to the second electronic device. When retrieving the target template from the database, if it exists in the database, it can be read; if the database does not contain the corresponding version, the retrieval needs to be terminated and the second electronic device needs to be notified of an exception.

[0059] In one implementation, the method further includes: after the first template is read from the database for the first time, storing the first template in the cache space of the first electronic device. The first template is any version among all pre-configured retrieval templates in the database. This implementation allows for faster retrieval of the target template by storing it in the local cache space immediately after the first read from the database.

[0060] In another implementation, the method further includes storing the second template in the cache space of the first electronic device when the number of times the second template is read from the database within a preset time period is greater than or equal to a preset threshold. This implementation sets a threshold for locally cached versions; only frequently used versions are stored in the local cache space. This reduces the amount of local cache space occupied while ensuring faster retrieval of the target template later.

[0061] In one implementation, before determining the target template, the method further includes: defining at least one scenario, and for each scenario, creating at least one pre-configured retrieval template; and sending the defined scenarios and the created pre-configured retrieval templates corresponding to those scenarios to a database for storage. In this implementation, scenarios and pre-configured retrieval templates need to be pre-defined and stored in the database before these data can be retrieved. The database provides centralized management, increases version storage capacity, and effectively reduces storage pressure in local storage scenarios.

[0062] In another implementation, the method further includes: when no target template is found from either the cache space of the first electronic device or the database, displaying a prompt message on the screen of the first electronic device. This prompt message instructs staff to add a definition for the scenario corresponding to the search term and to create a search template for that scenario. In this implementation, if no target template can be found at all, a prompt can also be displayed indicating that a new search template needs to be created for that scenario.

[0063] S204. According to the instructions of the target template, the search terms are encapsulated into DSL statements to obtain the target DSL statements.

[0064] The target template can include the encapsulation format of DSL statements, which can then be used for encapsulation.

[0065] In one implementation, each pre-configured search template includes a scene identifier and a DSL statement format. The scene identifier includes a scene code and / or scene name, while the DSL statement format includes keywords and a type. The scene code and scene name can be seen as examples of different scene identifiers, and they can be used together. The DSL statement format primarily guides on what content to encapsulate and how to encapsulate it.

[0066] In one example, each pre-configured search template also includes at least one of the following: a version identifier, an associated index, and an application source identifier. The associated index includes the index library corresponding to the pre-configured search template. The version identifier can be understood as distinguishing different versions within the same scenario. However, it should be understood that although a scenario can have multiple versions, only one version of a scenario can be online at any given time; otherwise, it would be impossible to determine which target template to use. The index can be understood as a pre-created directory or link to an index library. Each pre-configured search template will have an associated index used to determine the index library corresponding to that pre-configured search template.

[0067] In one example, the definition of the retrieval scenario can be as follows: Figure 3 As shown. In Figure 3As shown in (a), taking a scenario from a sports and health application as an example, it can be seen that the application identifier (ID) of a sports and health application is represented by app_sport_xxx. Adding an application ID in addition to the existing application name effectively distinguishes similar applications. Moreover, when the electronic device processes data in the background, it needs to use the application ID to recognize the application, rather than relying on the application's Chinese name. Figure 3 Both scene codes and scene names are present. For example, scene codes are 123, and scene names are scene1. It can be seen that scenes do not necessarily have to be named according to their corresponding business functions. However, in practice, to improve readability, scene names and scene codes can be prioritized based on business functions. The related index exists in the form of a doc document. The DSL statement format provides keywords (i.e., title) and types (i.e., category type) (the type can be understood as corresponding to the title type mentioned above; for example, in "running video," "running" is the keyword, and "video" is the type). Here, we take the example where the keyword can be a default field, for example... Figure 3 In this context, "$title" and "$type" represent the default keyword and default type, respectively. Figure 3 The DSL statement format shown in (a) also defines the result field ""_source":["name","age"]", which means that the DSL statement format can include other elements besides keywords and types according to the actual situation.

[0068] Figure 3 As shown in (b), a schematic diagram of the results can be shown after the search scenario is defined. During the debugging process, you can enter the title and type and then click search to test. Here, we take "Health Course" as the title and "1" as the type as the example.

[0069] In short, different search requirements can be matched by modifying the DSL statement format. For example, for applications with a single business function, only the title, i.e., only the keywords, can be specified in the DSL statement format. For applications with multiple business functions, elements can be added to further refine the search requirements for different scenarios.

[0070] In the solution of this application embodiment, even if new scenarios are added or existing scenarios have new search requirements, the new search requirements can be adapted by recreating the search template for the scenario or modifying the parameters in the created search template, so as to achieve more convenient maintenance and adaptation to new requirements and save development time and development costs.

[0071] S205. Send the target DSL statement to the matching search engine for retrieval and obtain the retrieval results.

[0072] After encapsulating the DSL statement, you can call the corresponding search engine to perform a retrieval. This can be done by using associated indexes or by using the encapsulated DSL statement itself.

[0073] In one implementation, step S205 may include: performing template parameter verification on the target DSL statement; if the parameter verification is successful, sending the target DSL statement to a matching search engine for retrieval; or, if the parameter verification fails, generating an error indication message and sending it to a second electronic device. This implementation adds verification of the encapsulated DSL statement to prevent retrieval failure due to errors in the encapsulated data. If the verification fails, the retrieval ends and the second electronic device is notified of the error.

[0074] S206. Send the search results to the second electronic device.

[0075] The search results can be sent to a second electronic device via a communication interface.

[0076] To better manage different versions, different management environments can be set up, such as sandbox and online environments. Versions can be created, maintained, and deployed in the sandbox environment, while versions can be taken offline in the online environment.

[0077] In one implementation, the method further includes: version control for each pre-configured search template in both sandbox and online environments; version control in the sandbox environment includes at least one of the following: creating new versions, deploying created versions online, editing existing versions, and deleting existing versions; version control in the online environment includes taking deployed versions offline. Controlling version creation and maintenance within the sandbox effectively prevents impact on ongoing search operations (existing business), ensuring that versions are only deployed online after being created or modified within the sandbox.

[0078] Version control in an online environment can also include deleting versions that have been taken offline.

[0079] In one example, version control also includes control based on the version status of each pre-configured search template, including: Editing, Live, Not Live, and Offline. Editing could occur during creation or after creation. Not Live means the template has been created or modified but not yet live. Offline means the template has been live and has been taken offline.

[0080] In one example, editing and deleting an existing version is performed when the version is offline or offline. If the version is still online, modifying or deleting it will inevitably make the search service unusable. Therefore, editing or deletion can only be performed when the version is offline or offline, and this must be done in a sandbox environment.

[0081] exist Figure 2 The proposed solution primarily involves pre-configuring different templates for different scenarios, i.e., pre-configuring search rules for different scenarios. When a search term is received, the solution can find the pre-configured search template that matches the scenario, encapsulate the DSL statement based on the matching version, and call the associated search engine to perform the search. This allows the entire search process to simultaneously meet the different search needs of different scenarios. Furthermore, this pre-configured search template approach is more conducive to subsequent updates and maintenance, shortening development time and saving development costs compared to traditional solutions.

[0082] Figure 4 This is a schematic diagram of the interface interaction for version control in a sandbox environment according to an embodiment of this application. For example... Figure 4 As shown, the sandbox environment for this scenario management includes various information such as the application name, scenario code, and scenario name. The status column provides examples of draft (not yet online), online, under modification (editing), and offline.

[0083] Version control can also be performed by clicking on these controls: edit, upload, and delete. It can also be seen that... Figure 4 The system only has edit and delete controls for the draft and offline states; it does not have edit and delete controls for the online and modified states.

[0084] Figure 5 This is a schematic diagram of the interface interaction for version control in an online environment according to an embodiment of this application. For example... Figure 5 As shown, the online environment for this scenario management includes various information such as the application name, scenario code, and scenario name. The status column provides examples of applications that are online and those that are offline.

[0085] Version control can also be performed by clicking on these controls: view, log off, refresh, and delete. It can also be seen that... Figure 5 The delete control is only available for scenarios that are offline; it is not available for scenarios that are online. Offline scenarios will appear in the sandbox environment, while the delete control can be used in the online environment.

[0086] Figure 6 This is a schematic diagram illustrating a version state transition logic according to an embodiment of this application. For example... Figure 6As shown, the "Draft" status changes to "Online" after being brought online. The "Online" status changes to "Editing" while being edited, and "Editing" changes back to "Online" after being brought online. The "Editing" status can also change to "Offline" after being taken offline, and the "Online" status changes to "Offline" after being taken offline. The "Draft" status can change to "Deleted" after being deleted, and the "Offline" status can change back to "Draft" while being edited. The "Offline" status can also change to "Deleted" after being deleted. It should also be understood that the "Deleted" status can continue to be displayed on the interface, with a cleanup control to indicate deletion to the user and prevent them from wanting to restore it. However, more commonly, the "Deleted" status simply disappears and is no longer displayed on the interface.

[0087] Figure 7 This is a schematic flowchart illustrating another vertical category retrieval method according to an embodiment of this application. Figure 7 It can be seen as Figure 2 An example of the method shown. Below is an example of... Figure 7 Each step will be explained.

[0088] S701. Perform business verification of the search terms. If the verification passes, proceed to step S702. If the verification fails, proceed to step S711.

[0089] S702. Read the application identifier (appid) and scene identifier (sceneid) used to query the scene configuration.

[0090] Scene configuration refers to pre-configured search templates.

[0091] S703. Determine whether the corresponding scenario configuration exists in the local cache. If the determination result is yes, proceed to step S704. If the determination result is no, proceed to step S705.

[0092] The corresponding scenario configuration is the target template mentioned above.

[0093] S704: Read the corresponding scenario configuration from the local cache.

[0094] S705. Determine whether the corresponding scenario configuration exists in the database (DB). If the determination result is yes, proceed to step S706. If the determination result is no, proceed to step S711.

[0095] S706. Read the corresponding scene configuration from the database.

[0096] S707, Perform DSL encapsulation to obtain DSL statements.

[0097] S708. Perform template parameter validation. If the validation passes, proceed to step S709. If the validation fails, proceed to step S711.

[0098] S709. Send the DSL statement to the corresponding search engine for retrieval.

[0099] S710. Encapsulate the search results and return them.

[0100] A return can be understood as sending the search terms back to the electronic device that sent them.

[0101] S711. Encapsulate the exception information and return it.

[0102] Figure 8 This is a schematic diagram of a vertical category retrieval system according to an embodiment of this application. Figure 8 The system shown can be used to implement the solutions of the embodiments of this application. Figure 8 The system shown can be considered as Figure 1 A concrete example is that the search side can be viewed as electronic device B, and the operations side as electronic device A. The search side sends vertical category data to the operations side, which then executes subsequent steps. However, it should be understood that... Figure 8 The search engine and database within the system can be used by the operations team, not the operations team. For example... Figure 8 As shown, scenario definitions and version control are performed on the operations-side server, and the scenario definitions and each created version are sent to the DB database. These scenario definitions and version information can also be synchronized to the local cache space.

[0103] When a search-side device sends a vertical category of data, it can distribute the data based on that vertical category, which means determining the scene information. Then, it can retrieve the scene configuration from the local cache or database, generate a DSL statement based on the scene configuration, and send the generated DSL statement to the corresponding search engine for retrieval, so that different scenes can be retrieved using the associated search engine.

[0104] The methods of the embodiments of this application have been described above with reference to the accompanying drawings. It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially, these steps are not necessarily executed in the order shown in the figures. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the steps or stages of other steps. The apparatus of the embodiments of this application will now be described with reference to the accompanying drawings.

[0105] Figure 9 This is a schematic diagram of a vertical category retrieval device according to an embodiment of this application. For example... Figure 9 As shown, the device 2000 includes a transceiver unit 2001 and a processing unit 2002. The device 2000 can be integrated into electronic devices such as computers, servers, and cloud devices.

[0106] The device 2000 can be used to execute any of the vertical category retrieval methods described above. For example, the transceiver unit 2001 can be used to execute steps S201 and S206, and the processing unit 2002 can be used to execute steps S202-S205. As another example, the device 2000 can also be used to execute... Figure 7 The steps are shown. The device 2000 can also be used to perform... Figure 8 The steps performed by the operation-side equipment during the process are shown.

[0107] In one implementation, the device 2000 may further include a storage unit for storing relevant data. This storage unit may be integrated into any of the aforementioned units, or it may be a unit independent of all of the aforementioned units.

[0108] Figure 10 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Figure 10 As shown, the electronic device 3000 includes: at least one processor 3001 ( Figure 10 (Only one is shown) a processor, a memory 3002, and a computer program 3003 stored in the memory 3002 and executable on the at least one processor 3001, wherein the processor 3001 executes the computer program 3003 to implement the steps of any of the above methods.

[0109] Those skilled in the art will understand that Figure 10This is merely an example of an electronic device and does not constitute a limitation on electronic devices. In practice, electronic devices may include more or fewer components than those shown in the illustration, or combinations of certain components, or different components. For example, they may also include input / output devices, network access devices, etc.

[0110] Processor 3001 can be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0111] In some embodiments, memory 3002 may be an internal storage unit of electronic device 3000, such as a hard disk or memory of electronic device 3000. In other embodiments, memory 3002 may be an external storage device of electronic device 3000, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on electronic device 3000. Optionally, memory 3002 may include both internal and external storage units of electronic device 3000. Memory 3002 is used to store operating system, application programs, bootloaders, data, and other programs, such as program code of computer programs. Memory 3002 may also be used to temporarily store data that has been output or will be output.

[0112] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0113] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0114] This application also provides an electronic device comprising: one or more processors, a memory, and a computer program stored in the memory and executable on the one or more processors. When the one or more processors execute the computer program, the electronic device can perform the steps in any of the methods described above. This application also provides a computer-readable storage medium storing a computer program, which, when executed by an electronic device, can perform the steps in the various method embodiments described above.

[0115] The computer-readable medium may include at least: any entity or device capable of carrying computer program code to a photographic / electronic device, recording media, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical discs. In some jurisdictions, according to legislation and patent practice, computer-readable media may not be electrical carrier signals or telecommunication signals.

[0116] This application provides a computer program product, which includes a computer program that, when executed by an electronic device, can implement the steps described in the various method embodiments above. The computer program includes computer program code, which may be in the form of source code, object code, executable file, or some intermediate form.

[0117] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0118] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0119] In the embodiments provided in this application, it should be understood that the disclosed apparatus / devices and methods can be implemented in other ways. For example, the apparatus / device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0120] 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0121] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0122] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0123] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0124] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0125] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for vertical category retrieval, characterized in that, include: The second electronic device acquires the search terms entered by the user through the search bar in the first business module of the first application on the second electronic device, wherein the first application includes at least one business module; The second electronic device sends the search terms to the first electronic device; The first electronic device receives the search terms; The scenario in which the first electronic device determines the first business segment as the search term based on the search term originating from the first business segment; The first electronic device determines a target template that matches the first business segment from at least one pre-configured search template that is online and corresponds to at least one defined scenario. Each scenario corresponds to one business segment, each scenario corresponds to at least one pre-configured search template, and each scenario corresponds to one online pre-configured search template. Each pre-configured search template includes a scenario identifier, a version identifier under the same scenario, an associated index, and an application source identifier. The associated index includes the index library corresponding to the pre-configured search template. The first electronic device encapsulates the search terms into a domain-specific language (DSL) statement according to the instructions of the target template to obtain the target DSL statement; The first electronic device sends the target DSL statement to a matching search engine for retrieval and obtains the retrieval results; The first electronic device sends the search results to the second electronic device; The first electronic device manages at least one pre-configured search template corresponding to each scenario by performing at least one of the following steps: In the scene management interface, in response to the user's operation on the management environment control, the management environment is set to a sandbox environment or a production environment. In a sandbox environment, in response to user actions on the corresponding controls, at least one of the following version control operations should be performed: create a new version, deploy the created version online, edit an existing version, or delete an existing version. In an online environment, in response to user actions on the corresponding controls, version control is implemented to remove the online version from the online version.

2. The method according to claim 1, characterized in that, The first electronic device determines a target template matching the first business segment from at least one pre-configured search template that corresponds to at least one defined scenario and is already online, including: When the first electronic device contains at least one pre-configured retrieval template cached in its cache space, the first electronic device reads the target template from the cache space; or, When the target template is not in the cache space of the first electronic device, the first electronic device reads the target template from the database DB.

3. The method according to claim 2, characterized in that, When the target template is not present in the cache space of the first electronic device, the first electronic device reads the target template from the database, including: When the database contains the target template, the first electronic device reads the target template from the database; or... When the target template is not found in the database, the first electronic device generates an error indication message and sends it to the second electronic device.

4. The method according to claim 2, characterized in that, The method further includes: After the first electronic device reads the first template from the database for the first time, it stores the first template in the cache space of the first electronic device. The first template is any version of all the pre-configured retrieval templates in the database.

5. The method according to claim 2, characterized in that, The method further includes: When the number of times the second template is read from the database within a preset time period is greater than or equal to a preset threshold, the first electronic device stores the second template in the cache space of the first electronic device.

6. The method according to claim 2, characterized in that, The method further includes: When no target template is found in the cache space or database of the first electronic device, the first electronic device displays a prompt message on the screen. The prompt message is used to instruct the staff to add a definition for the scenario corresponding to the search term and to create a search template for that scenario.

7. The method according to any one of claims 1 to 6, characterized in that, The first electronic device sends the target DSL statement to a matching search engine for retrieval, and obtains the retrieval results, including: Perform template parameter validation on the target DSL statement; If the parameter validation is successful, the target DSL statement is sent to a matching search engine for retrieval; or, When parameter verification fails, an error indication message is generated and sent to the second electronic device.

8. The method according to any one of claims 1 to 6, characterized in that, Before determining the target template, the method further includes: In the scene management interface on the first electronic device, at least one scene is defined, and for each of the at least one scene, at least one pre-configured retrieval template for that scene is created; The defined scenarios and the pre-configured search templates corresponding to those scenarios are sent to the database for storage.

9. The method according to any one of claims 1 to 6, characterized in that, The scene identifier includes a scene code and / or a scene name, and the statement format of the DSL includes keywords and types.

10. The method according to claim 1, characterized in that, The management of at least one pre-configured search template corresponding to each scenario by the first electronic device also includes: controlling the version status of each pre-configured search template, wherein the version status includes: editing, online, offline, and offline.

11. The method according to claim 10, characterized in that, Editing a created version and / or deleting an existing version is done when the version status is offline or offline.

12. An electronic device comprising a memory, one or more processors, and a computer program stored in the memory and executable on the processor, characterized in that, When the one or more processors execute the computer program, the electronic device causes the electronic device to perform the method as described in any one of claims 1 to 11.

13. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by an electronic device, it implements the method as described in any one of claims 1 to 11.

Images