Subscription task processing method and device, equipment and storage medium

Abstract

The invention discloses a subscription task processing method and device, equipment and a storage medium, and relates to the technical field of computers. The method comprises the steps that according to query information of a subscription task, a query result of the subscription task is obtained, and the subscription task is used for periodically obtaining information of a subscription object; determining the state of the subscription object according to the query result of the subscription task; and under the condition that the query information of the subscription task is not matched with the state of the subscription object, reconstructing the query information of the subscription task to obtain updated query information of the subscription task. The self-adaptive reconstruction mechanism in the application endows the subscription task with the perception ability for the life cycle, realizes the stage evolution of the life cycle of the subscription task, and improves the effectiveness and accuracy of the query result of the subscription task.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a processing method and device for a subscription task, an equipment and a storage medium. BACKGROUND

[0002] The traditional subscription system has been relatively maturely applied in Internet services, and its technical evolution has experienced a development process from a simple protocol to intelligent analysis.

[0003] In the related art, some subscription systems introduce a text similarity algorithm to improve the change detection capability, trigger a subscription task based on a database, and obtain a historical query result and a current query result of the subscription task. A TF-IDF (Term Frequency-Inverse Document Frequency), cosine similarity, or edit distance statistical method can be used to calculate the similarity between the current query result and the historical query result. When the similarity is lower than a set threshold, it is determined that the subscription task has changed significantly and a push is triggered. When the similarity is higher than a preset threshold, it is determined that the subscription task has not changed significantly, and only the current query result is saved to the database.

[0004] However, the above-mentioned text similarity algorithm cannot understand the deep semantics of the content, resulting in limited information obtained by the query. SUMMARY

[0005] Embodiments of the present application provide a processing method and device for a subscription task, an equipment and a storage medium. The technical solutions provided by the embodiments of the present application are as follows: According to an aspect of the embodiments of the present application, a processing method for a subscription task is provided, and the method comprises: obtaining a query result of the subscription task according to query information of the subscription task, the subscription task being used to periodically obtain information of a subscription object; determining a state of the subscription object according to the query result of the subscription task; reconfiguring the query information of the subscription task to obtain updated query information of the subscription task in a case where the query information of the subscription task does not match the state of the subscription object.

[0006] According to an aspect of the embodiments of the present application, a processing device for a subscription task is provided, and the device comprises: a result obtaining module configured to obtain a query result of the subscription task according to query information of the subscription task, the subscription task being used to periodically obtain information of a subscription object; a state determining module configured to determine a state of the subscription object according to the query result of the subscription task; The information reconstruction module is used to reconstruct the query information of the subscription task when the query information of the subscription task does not match the state of the subscription object, so as to obtain the updated query information of the subscription task.

[0007] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described method for processing subscription tasks.

[0008] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, the computer program being loaded and executed by a processor to implement the above-described method for processing subscription tasks.

[0009] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being loaded and executed by a processor to implement the above-described method for processing subscription tasks.

[0010] The technical solution provided in this application can bring the following beneficial effects: By determining the status of the subscribed object based on the query results of the subscription task and judging whether the query information of the subscription task matches the status of the subscribed object, it is determined whether the query information of the subscription task needs to be reconstructed. This allows for accurate identification of changes in the status of the subscription task. When the life stage indicated by the status of the subscription task has ended, the query information of the subscription task is automatically reconstructed, and the query dimensions of the subscription task are adjusted to realize the stage evolution of the subscription task's life cycle. This allows the subscription account to obtain query results that accurately reflect the status of the subscribed object, improving the effectiveness and accuracy of the query results of the subscription task. The adaptive reconstruction mechanism in the technical solution provided in this application gives the subscription task the ability to perceive its life cycle, which can prevent the subscription task from always querying information on the same dimension, thus avoiding a large number of invalid subscription tasks occupying the query resources of the subscription system. This reduces the call cost and computing resource consumption of the search engine, and optimizes the resource utilization efficiency of the subscription system. Attached Figure Description

[0011] Figure 1 This is a schematic diagram illustrating the processing flow of a keyword-based subscription system provided by related technologies; Figure 2 This is a schematic diagram of a computer system provided in one embodiment of this application; Figure 3 This is a flowchart of a subscription task processing method provided in one embodiment of this application; Figure 4This is a flowchart illustrating the implementation of an adaptive refactoring mechanism for subscription tasks provided in one embodiment of this application; Figure 5 This is a flowchart illustrating the implementation of a semantic similarity comparison algorithm for subscription tasks provided in one embodiment of this application. Figure 6 This is a schematic diagram of the push process of the query results of a subscription task provided in one embodiment of this application; Figure 7 This is a schematic diagram of the core scheduling process of an intelligent agent provided in one embodiment of this application; Figure 8 This is a flowchart of a multi-agent cooperation mechanism provided in one embodiment of this application; Figure 9 This is a schematic diagram of the overall architecture of a subscription system provided in one embodiment of this application; Figure 10 This is a block diagram of a subscription task processing apparatus provided in one embodiment of this application; Figure 11 This is a structural block diagram of a computer device provided in one embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0013] Figure 1 The diagram illustrates the processing flow of a keyword-based subscription system provided by related technologies. After triggering a subscription task, the system performs a query to obtain the current query result and retrieves historical query results from the database. Then, methods such as keyword matching, MD5 or SHA256 hash value comparison, TF-IDF vector cosine similarity calculation, or timestamp comparison can be used to detect whether the content has changed. For example, statistical methods such as TF-IDF, cosine similarity, or edit distance can be used to calculate the similarity between the current query result and historical query results to determine whether the subscription task's query result has changed. When the similarity is below a set threshold, the subscription task is considered to have changed significantly, and a push notification is triggered. When the similarity is above the preset threshold, the subscription task is considered not to have changed significantly, and only the current query result is saved to the database.

[0014] However, traditional subscription systems, once query conditions are set, continuously execute the same query logic, failing to automatically adjust to changes in the external environment or content status. Specifically, if a user subscribes to a product's release information, and the subscription system continues to query the same content after the product's release, the system will continuously push duplicate "released" information to the subscription account. Similarly, if a user subscribes to a company's financing progress, it cannot automatically switch to subscribing to "Company's Subsequent Development" or "Fund Usage" after the financing is completed; or if subscribing to "Technical Standard Development Progress," it cannot automatically switch to "Standard Implementation" or "Technical Application Cases" after the standard is released. This results in the query logic being hard-coded into the subscription system, lacking the ability to understand the semantic content and status of the subscription task, and failing to recognize the phased changes in the lifecycle of the subscribed object.

[0015] Furthermore, traditional subscription systems rely on keyword matching, hash value comparison, or simple text similarity algorithms, failing to understand the deep semantics of content, leading to serious false positives and false negatives. Specifically: False Positives: When the wording of a subscription task changes but the semantics remain the same, the subscription system misjudges this as a change in the subscription task. For example, "expected to be released next month" changes to "planned to launch in 30 days," the semantics remain the same but the wording changes, triggering a push notification. False Negatives: When the semantics of a subscription task undergo a significant change but the wording remains similar, the subscription system fails to detect it. For example, "product release postponed to next year" changes to "product release postponed to the year after next," the postponement time increases significantly but the semantic similarity is high, failing to identify the synonym. Subscription systems cannot recognize synonyms such as "price reduction," "price reduction promotion," and "special offers," leading to duplicate push notifications or omissions of key information. They also lack contextual understanding, failing to grasp the impact of time on the semantics of content; for example, "the product will be released in three months" has different semantic value at different points in time. The traditional text similarity algorithms based on word frequency statistics and character matching lack semantic understanding capabilities and cannot capture the deep meaning and contextual relationships of the text.

[0016] Furthermore, traditional subscription systems cannot learn from historical query results or automatically optimize subscription strategies based on user feedback or content change patterns. Specifically: the push frequency is fixed and cannot be automatically adjusted according to content update frequency (e.g., the query frequency is not increased when content updates accelerate); it cannot identify the types of changes users are truly interested in, continuously pushing information users are not interested in; the similarity threshold is fixed, preventing adaptive adjustments based on specific content types; subscription rules require manual modification and maintenance by users, and the system cannot proactively suggest optimization directions. Subscription systems lack reflection mechanisms and self-learning capabilities, cannot analyze historical execution data, and cannot establish a correlation model between content change patterns and user interests.

[0017] Furthermore, traditional subscription systems typically push content in plain text or simple web pages, lacking multimodal information such as charts and images, making it difficult for users to quickly understand changing content. Specifically: data-based subscriptions (such as stock prices and sales figures) only push numbers, lacking trend charts; product subscriptions only push text descriptions, lacking product images or comparison charts; complex changes can only be described with long paragraphs of text, resulting in high comprehension costs for users. Subscription systems lack multimodal content generation capabilities, and the push module only supports text format.

[0018] Furthermore, traditional systems employ simple timed task mechanisms, resulting in numerous subscription tasks being executed serially or inefficiently concurrently, leading to low resource utilization. Specifically, this manifests as: concentrated task execution times causing system load spikes; a lack of collaboration mechanisms between tasks, resulting in repeated queries of the same or similar content; and unreasonable resource allocation, treating important tasks and general tasks equally. Subscription systems lack intelligent task scheduling and multi-agent collaboration mechanisms.

[0019] Furthermore, as subscription tasks run for extended periods, the volume of historical data grows rapidly, leading to a decline in query and management efficiency. Specifically: excessively large single-table data volumes result in decreased query performance; historical data lacks an effective sharding mechanism; and simplistic data cleaning strategies fail to balance storage costs and data value.

[0020] Please refer to Figure 2 This illustration shows a schematic diagram of a computer system provided in one embodiment of this application. The computer system may include: a terminal device 10 and a server 20.

[0021] There may be one or more terminal devices 10. Terminal devices 10 may be electronic devices such as mobile phones, tablets, laptops, desktop computers, game consoles, e-book readers, multimedia playback devices, wearable devices, smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc.

[0022] The terminal device 10 may have a client application for the target application installed. The target application has the function of subscribing to tasks to periodically obtain information from subscribed objects. Optionally, the target application may be an application that needs to be downloaded and installed, or it may be an application that can be used immediately upon clicking. This application does not limit this.

[0023] Server 20 provides background services for clients of the target application installed and running on terminal device 10. For example, server 20 can be a background server for the aforementioned target application. Server 20 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, but is not limited to these. Optionally, server 20 can simultaneously provide background services for target applications on multiple terminal devices 10. Terminal devices 10 and server 20 can communicate with each other via a network.

[0024] The data storage system can store the data that server 20 needs to process. The data storage system can be integrated onto server 20 or placed in the cloud or on other servers. Terminal device 10 responds to the subscription task by sending the query information of the subscription task to server 20. Server 20 obtains the query results of the subscription task based on the agent and the query information of the subscription task. Based on the query results of the subscription task and historical query results, it determines whether to push the query results of the subscription task to the subscribing account. It also determines the status of the subscribed object based on the query results of the subscription task; if the query information of the subscription task does not match the status of the subscribed object, it reconstructs the query information of the subscription task to obtain the updated query information; and then, based on the updated query information, it re-obtains the query results of the subscription task.

[0025] Please refer to Figure 3 This document illustrates a flowchart of a subscription task processing method provided in one embodiment of this application. The execution entity for each step of this method can be a computer device. The method may include at least one of the following steps 310-330: Step 310: Obtain the query results of the subscription task based on the query information of the subscription task. The subscription task is used to periodically obtain information about the subscribed object.

[0026] A subscription task is a task created by a subscription account to periodically retrieve information about a subscribed object within a specified query dimension. A subscription account is the user account that creates the subscription task. The query information for a subscription task is generated according to the subscription rules and is used to obtain the query results. The subscription rules specify the subscribed object and the corresponding query dimension for the subscription task. The query information for the subscription task specifies the subscribed object and a query dimension of the subscribed object to be queried. Typically, the query information for a subscription task is text-based. After receiving the query information, the subscription system retrieves the query results based on that information. The query results indicate the information about the subscribed object within the query dimension indicated by the query information.

[0027] The subscription targets for subscription tasks include, but are not limited to, products, companies, and technical standards. Products can be tangible goods such as mobile phones, clothing, home appliances, and food, or virtual products such as game currency, online courses, and movie memberships. The query dimensions for subscription tasks are related to the subscription target. For example, if the subscription target is a product, the query dimensions include, but are not limited to, product releases, price changes, promotions, inventory alerts, and user reviews. If the subscription target is a company, the query dimensions include, but are not limited to, the company's financing progress, IPO progress, and stock price fluctuations. If the subscription target is a technical standard, the query dimensions include, but are not limited to, the progress of the technical standard's development, implementation, and modifications.

[0028] Each query dimension corresponding to a subscription task indicates a lifecycle stage of the subscription task, and different query dimensions corresponding to a subscription task indicate different lifecycle stages of the subscription task. A subscription task can have one or more query dimensions.

[0029] If a subscription task corresponds to a single query dimension, then the query dimension indicated by the subscription task's query information is that single query dimension, and the query result of the subscription task is the information about the subscribed object on that single query dimension. For example, if the subscription object corresponding to the subscription task is a product, then the query dimension corresponding to the subscription task is the product release dimension, and the query result of the subscription task is information about whether the product has been released. If a subscription task corresponds to multiple query dimensions, then the query dimension indicated by the subscription task's query information is the query dimension with the earliest lifecycle stage among these multiple query dimensions, and the query result of the subscription task is the information about the query dimension with the earliest lifecycle stage among these multiple query dimensions. For example, if the subscription object corresponding to the subscription task is a product, then the query dimensions corresponding to the subscription task include the product release dimension and the price change dimension, and the lifecycle stage corresponding to product release is earlier than the lifecycle stage corresponding to price change, and the query result of the subscription task is information about whether the product has been released.

[0030] However, if the subscription task consistently only queries information based on the earliest query dimension of the subscription's lifecycle, changes in the subscription object's lifecycle will prevent the task from adjusting the query dimensions accordingly. This results in query results limited to the earliest query dimension of the lifecycle, failing to reflect the phased changes in the subscription object's lifecycle and leading to inaccurate results. Therefore, the technical solution provided in this application updates the query dimensions indicated in the subscription task's query information when the subscription object's lifecycle changes. This adjusts the query dimensions to match the latest state of the subscription object, ensuring that the subscription task's query results accurately reflect the latest information of the subscription object.

[0031] Step 320: Determine the status of the subscription object based on the query results of the subscription task.

[0032] The query results of a subscription task indicate the information about the subscribed object within the query dimension indicated by the query information of the subscription task. This information reflects whether the lifecycle of the subscribed object has ended within that query dimension, thus allowing the determination of the subscribed object's status based on whether its lifecycle has ended within that query dimension. The status of a subscribed object indicates whether its lifecycle within the query dimension indicated by the query information of the subscription task has ended.

[0033] For example, if the query result of a subscription task is information about whether a product has been published, then the query result of the subscription task is used to indicate whether the product's lifecycle has ended. If the query result of a subscription task is that the product has been published, then the status of the subscription task is used to indicate that the product's lifecycle has ended. If the query result of a subscription task is that the product has not yet been published, then the status of the subscription task is used to indicate that the product's lifecycle has not yet ended.

[0034] In some embodiments, it is detected whether the query results of the subscription task contain predefined status keywords, which are keywords related to the status changes of the subscription object; based on the status keywords contained in the query results of the subscription task, the status of the subscription object is determined.

[0035] For example, the query results of the subscription task are analyzed using LLM (Large Language Model) to determine whether the query results of the subscription task contain predefined status keywords, and the analysis results are obtained. Based on the status keywords contained in the query results of the subscription task indicated by the analysis results, the status of the subscription object is determined.

[0036] Predefined status keywords are used to indicate whether the lifecycle of a subscribed object has ended in the query dimension indicated by the query information of the subscription task. These can include, but are not limited to, predefined status keywords such as "Published," "Completed," "Listed," "Published Completed," "Officially Launched," "Sales Begin," "Funding Completed," "Standard Released," "Event Ended," and "Discontinued." Specifically, the predefined status keywords "Published," "Completed," "Listed," "Published Completed," "Funding Completed," "Standard Released," "Event Ended," and "Discontinued" indicate that the lifecycle in the query dimension indicated by the query information of the subscription task has ended, while the predefined status keywords "Officially Launched" and "Sales Begin" indicate that the lifecycle in the query dimension indicated by the query information of the subscription task has not yet ended.

[0037] By analyzing the semantic meaning of status keywords in the query results of subscription tasks, the status of the subscription object can be determined, ensuring the standardization and rationality of the subscription task processing flow and improving the accuracy of the subscription object's status.

[0038] Step 330: If the query information of the subscription task does not match the state of the subscription object, reconstruct the query information of the subscription task to obtain the updated query information of the subscription task.

[0039] The query information of a subscription task is used to indicate a query dimension of the subscription object to be queried by the subscription task, and the status of the subscription object is used to indicate whether the life stage of the subscription object on the query dimension indicated by the query information of the subscription task has ended.

[0040] A mismatch between the query information of a subscription task and the status of the subscribed object means that the lifecycle stage of the subscribed object has ended according to the query dimension indicated by the subscription task's query information. The query information cannot find any new information about the subscribed object at that query dimension. Therefore, it is necessary to reconstruct the subscription task's query information, update the query dimension indicated by the subscription task's query information, and change the lifecycle stage of the subscribed object that the subscription task's query information is seeking to query, resulting in updated query information. This allows the subscription system to query information for the next lifecycle stage of the subscribed object based on the updated query information, ensuring the timeliness and accuracy of the retrieved information.

[0041] Matching the query information of the subscription task with the status of the subscription object means that the life stage of the subscription object in the query dimension indicated by the query information of the subscription task has not yet ended. The query information of the subscription task can still query new information of the subscription object in the query dimension. Therefore, there is no need to reconstruct the query information of the subscription task. The subscription system still queries the information of the current life stage of the subscription object according to the query information of the subscription task until the current life stage of the subscription object has ended.

[0042] The query dimension indicated by the updated query information of a subscription task differs from the query dimension of the subscription task's query information. Typically, the query dimension indicated by the updated query information is the query dimension corresponding to the next lifecycle stage of the subscribed object's lifecycle, i.e., the query dimension following the query dimension in the subscription task's query information. In some embodiments, the query dimension indicated by the updated query information is the next query dimension among the query dimensions corresponding to the subscription task.

[0043] In some embodiments, the query information of the subscription task is reconstructed based on the state of the subscription object to obtain the updated query information of the subscription task.

[0044] Based on the end of the subscription object's lifecycle indicated by its status, the next lifecycle stage of the subscription object is determined. Thus, the query information of the subscription task can be reconstructed based on the query dimensions corresponding to the next lifecycle stage of the subscription object, and the updated query information of the subscription task can be obtained.

[0045] The next life stage of a subscription object's lifecycle is the life stage that the current life stage of the subscription object can evolve to. This means that the next life stage of a subscription object's lifecycle is not the only possible life stage. For example, the next life stage after a product launch could be the price change stage, the promotional stage, the inventory alert stage, the user review stage, and so on.

[0046] Therefore, based on the status of the subscribed object and the query dimensions corresponding to the subscription task, the query dimensions corresponding to the next lifecycle stage within the query dimensions of the subscription task can be determined. Based on these query dimensions, the query information of the subscription task can be reconstructed to obtain the updated query information. For example, if the query dimensions corresponding to the subscription task include product release, price change, and promotional offers, the query information can be reconstructed based on either the price change dimension or the promotional offers dimension.

[0047] For example, in a restructuring scenario where the subscription object is a product, if the subscription object's status is "product has been released," the updated query information for the subscription task can be adjusted to periodically retrieve information on product price changes, or periodically retrieve information on product user reviews, and so on. If the subscription object's status is "product price has decreased," the updated query information for the subscription task can be adjusted to periodically retrieve information on product promotions, or periodically retrieve information on product inventory alerts, and so on. In a restructuring scenario where the subscription object is a company, if the subscription object's status is "company financing completed," the updated query information for the subscription task can be adjusted to periodically retrieve information on the company's fund usage. In a restructuring scenario where the subscription object is a technology standard, if the subscription object's status is "technology standard development completed," the updated query information for the subscription task can be adjusted to periodically retrieve information on the technology standard's implementation progress.

[0048] By reconstructing the query information of the subscription task based on the status of the subscribed object, the updated query information of the subscription task can obtain information about the next life stage of the subscribed object. This makes the transition of the query dimensions indicated by the updated query information of the subscription task smoother and more natural, meeting the user's expectations for the subscription task.

[0049] In some embodiments, if the status of the subscription task indicates that the life phase of the subscription object on the query dimension corresponding to the subscription task has ended, the step of reconstructing the query information of the subscription task and obtaining the updated query information of the subscription task is not performed.

[0050] A subscription task can have one or more query dimensions. When a subscription task has only one query dimension, if the task's status indicates that the subscription object's lifecycle stage for that query dimension has ended, it's impossible to switch from a pre-defined query dimension to one not defined by the subscription rules. Therefore, the subscription task's query information loses its value for reconstruction, and the step of reconstructing the subscription task's query information is not executed. For example, if the subscription task's query dimension only includes the product release dimension, then after the product release is complete, the subscription task lacks a basis for dimension updates, and the step of reconstructing the subscription task's query information is not executed.

[0051] When there are multiple query dimensions corresponding to a subscription task, if the status of the subscription task indicates that the lifecycle stage of the subscribed object in the corresponding query dimension has not yet ended, then there is a basis for dimension updates in the corresponding query dimension, and the query information of the subscription task has not lost its value for reconstruction. Based on other query dimensions included in the corresponding query dimension, the query dimension corresponding to the next lifecycle stage of the subscribed object can be determined, and the query information of the subscription task can be reconstructed. Alternatively, if the subscription system determines, based on the updated query information of the subscription task, that the update status of the subscription task indicates that the lifecycle stage in the corresponding query dimension has ended, then the step of reconstructing the query information of the subscription task will not be executed. If the update status of the subscription task indicates that the lifecycle stage in the corresponding query dimension has not yet ended, then the step of reconstructing the query information of the subscription task can still be executed.

[0052] For example, if the query dimensions corresponding to a subscription task include the product release dimension and the inventory reminder dimension, then after the product has been released, the updated query information of the subscription task is used to periodically obtain information about the product in the inventory reminder dimension. If the product is sold out, the query information of the subscription task will not be reconstructed.

[0053] By determining whether the query information of the subscription task should be reconstructed based on whether the life stage of the subscribed object has ended in the query dimension corresponding to the subscription task, a basis for reconstructing the query information of the subscription task is provided. This avoids querying in query dimensions not defined in the subscription rules, which would disrupt the execution basis of the subscription task and ensure the execution standardization of the subscription task.

[0054] The technical solution provided in this application determines the status of the subscription object based on the query results of the subscription task and judges whether the query information of the subscription task matches the status of the subscription object to determine whether the query information of the subscription task needs to be reconstructed. This allows for accurate identification of changes in the status of the subscription task. When the life stage indicated by the status of the subscription task has ended, the query information of the subscription task is automatically reconstructed, the query dimensions of the subscription task are adjusted, and the life cycle of the subscription task is realized. This allows the subscription account to obtain query results that accurately reflect the status of the subscription object, improving the effectiveness and accuracy of the query results of the subscription task. The adaptive reconstruction mechanism in the technical solution provided in this application gives the subscription task the ability to perceive its life cycle, which can prevent the subscription task from always querying information on the same dimension, thus avoiding a large number of invalid subscription tasks occupying the query resources of the subscription system. This reduces the call cost and computing resource consumption of the search engine and optimizes the resource utilization efficiency of the subscription system.

[0055] The following describes the process of reconstructing the query information for the subscription task, including at least one of steps S11 to S12.

[0056] Step S11: Generate reconstruction prompts for the Large Language Model (LLM). These prompts guide the LLM to adjust the query information of subscription tasks based on changes in the state of the subscribed objects.

[0057] In some embodiments, the reconstruction prompt information includes at least one of the following: first role definition information, first input information, first task requirement information, and first output format information.

[0058] The first role definition information instructs the LLM to act as an optimization assistant for subscription tasks, adjusting the query information of subscription tasks based on changes in the state of the subscription objects. This first role definition information indicates the LLM's role in the refactoring process, namely, determining whether to adjust the query information of subscription tasks based on changes in the state of the subscription objects, and how to adjust the query information.

[0059] The first input information is used to indicate the state changes of the subscribed object.

[0060] In some embodiments, the first input information includes at least one of the following: query information of the subscription task, query results of the subscription task, a summary of changes to the subscription task, and status keywords of the subscription task.

[0061] A change summary for a subscription task is used to summarize the state changes of the subscribed object. Specifically, the change summary describes whether the state of the subscribed object has changed, and if so, what kind of state change occurred. For example, the change summary can be generated after the query results of the subscription task are generated, during the process of determining whether the subscription account should push the query results of the subscription task through LLM. See the following embodiment for details.

[0062] It is important to note that the step of detecting whether the query results of the subscription task contain predefined status keywords can be implemented by detecting whether the change summary of the subscription task contains predefined status keywords. Therefore, the status keywords of the subscription task included in the first input information are status keywords extracted from the change summary of the subscription task, such as "published" or "completed."

[0063] By constructing the first input information according to the above method, the LLM can determine whether the state of the subscribed object has changed and how it has changed based on the first input information, ensuring the comprehensiveness of the first input information construction and helping to improve the accuracy of the LLM's reconstruction results of the query information.

[0064] The first task requires information indicating the adjustment requirements for the query information of the subscription task. Specifically, the adjustment requirements for the query information of the subscription task include: determining whether the query information of the subscription task has reconstruction value in the latest state of the subscription object, i.e., determining whether the query information of the subscription task needs to be reconstructed; if the query information of the subscription task has reconstruction value in the latest state of the subscription object, adjusting the query dimension of the subscription task, i.e., determining the query dimension that the query information of the subscription task can be transformed into in the corresponding query dimension of the subscription task; and generating the updated query information of the subscription task based on the adjusted query dimension of the subscription task.

[0065] The first output format information is used to indicate the information format of the refactoring result. For example, the first output format information is used to indicate that the refactoring result is output information in JSON format, which may include the first indication information, the updated query information of the subscribed task, and the reason for refactoring.

[0066] By constructing refactoring prompts using the method described above, the LLM can obtain more comprehensive refactoring instructions, which facilitates the LLM in accurately adjusting the query information of the subscription task based on the refactoring prompts, thereby improving the accuracy of the LLM's refactoring results for the query information.

[0067] Step S12: Generate a reconstruction result using LLM based on the reconstruction prompt information; wherein, the reconstruction result includes first indication information, which indicates whether to reconstruct the query information of the subscription task, and if the first indication information indicates that the query information of the subscription task should be reconstructed, the reconstruction result also includes the updated query information of the subscription task.

[0068] Based on the LLM refactoring results, the updated query information for the subscription tasks is obtained.

[0069] By reconstructing the query information of subscription tasks using the above methods, subscription tasks can automatically adapt to the lifecycle evolution of the subscription object, avoid invalid subscription tasks occupying the query resources of the subscription system, improve the user experience, and ensure that users can always obtain the most valuable dynamic information.

[0070] In some embodiments, the similarity between the query results of the subscription task and the historical query results of the subscription task is determined. If the subscription task meets the reconstruction conditions, the step of reconstructing the query information of the subscription task to obtain the updated query information of the subscription task is performed; wherein, the reconstruction conditions include: the similarity is less than or equal to a third threshold; the query information of the subscription task does not match the state of the subscription object.

[0071] The similarity between the query results of a subscription task and the historical query results of the subscription task can be generated after the query results of the subscription task are generated, by using LLM to determine whether the subscription account pushed the query results of the subscription task. For details, please refer to the following example.

[0072] If the similarity is less than or equal to the third threshold, and the query information of the subscription task does not match the state of the subscription object, then the step of reconstructing the query information of the subscription task to obtain the updated query information of the subscription task is performed. It can be seen that whether the similarity between the query result of the subscription task and the historical query result of the subscription task is less than or equal to the third threshold is a non-essential condition for information reconstruction, while the mismatch between the query information of the subscription task and the state of the subscription object is a necessary condition for information reconstruction.

[0073] When the similarity between the query results of a subscription task and the historical query results of the subscription task is less than or equal to the third threshold, it can be considered that the state of the subscription object has changed drastically, requiring information reconstruction to obtain the latest state of the subscription object. When the similarity between the query results of a subscription task and the historical query results of the subscription task is greater than the third threshold, it can be considered that the state change of the subscription object is minor, and information reconstruction is not required; the query results of the subscription task can be used to indicate the latest state of the subscription object.

[0074] Optionally, if the similarity is less than or equal to the third threshold, it can be further determined whether the query information of the subscription task matches the state of the subscription object. If the query information of the subscription task does not match the state of the subscription object, the step of reconstructing the query information of the subscription task to obtain the updated query information of the subscription task can be performed. If the similarity is greater than the third threshold, it is not necessary to determine whether the query information of the subscription task matches the state of the subscription object, nor is it necessary to perform the step of reconstructing the query information of the subscription task to obtain the updated query information of the subscription task.

[0075] For example, when the subscription target is a product, if the query dimension indicated by the query information of the subscription task is the dimension of product publication, then it is not necessary to use a similarity less than or equal to the third threshold as a reconstruction condition. If the query dimension indicated by the query information of the subscription task is a dimension such as price alerts or promotional offers, then it is necessary to use a similarity less than or equal to the third threshold as a reconstruction condition.

[0076] This application does not limit the third threshold mentioned above. For example, the third threshold can be 0.3.

[0077] The dual-condition judgment mechanism ensures both the sensitivity of the reconstruction mechanism when it is triggered and avoids frequent reconstructions caused by misjudgments, thus guaranteeing the accuracy of reconstruction decisions and improving the accuracy of query information after the subscription task is updated.

[0078] In some embodiments, a confidence level of the reconstruction result is obtained, which indicates the degree of credibility of the reconstruction result. If the confidence level is greater than or equal to a first threshold, the query information of the subscription task is updated to the updated query information of the subscription task. If the confidence level is less than the first threshold but greater than a second threshold, based on the reconstruction selection of the subscription account (the user account that created the subscription task), it is determined whether to update the query information of the subscription task to the updated query information of the subscription task. If the confidence level is less than or equal to the second threshold, updating the query information of the subscription task is cancelled.

[0079] The confidence level of the LLM during the process of generating refactoring results based on refactoring prompts is obtained, and this confidence level measures the reliability of the refactoring results. When the confidence level is greater than or equal to a first threshold, the refactoring result is considered highly reliable, and the subscription system can directly determine that it is a refactoring without user consent, thus updating the query information of the subscribed task and improving the efficiency of information updates. When the confidence level is less than or equal to a second threshold, the refactoring result is considered less reliable, and the subscription system can directly determine that it is not a refactoring without user consent, thus avoiding invalid updates to the query information of the subscribed task.

[0080] When the confidence level is less than the first threshold but greater than the second threshold, the reliability of the reconstruction result can be considered to be at a moderate level. The subscription system cannot make a direct choice and needs to push a prompt message to the subscription account, allowing the user to choose whether to reconstruct. The user can choose to agree to the reconstruction, refuse the reconstruction, or allow the subscription system to determine whether to reconstruct. Based on the subscription account's reconstruction choice, it is determined whether to update the query information of the subscription task to the updated query information. The default judgment of the subscription system when the confidence level is less than the first threshold but greater than the second threshold can be either default to reconstruction or default not to reconstruction; this application does not limit this.

[0081] Through the confidence mechanism and user confirmation process provided above, a balance is achieved between automating the reconstruction mechanism and balancing the reconstruction opinions selected by users. This avoids both relying solely on the subscription system to determine whether to reconstruct and ignoring user decision-making opinions, and also avoids letting users make decisions alone, which could affect the efficiency of information reconstruction. This ensures that while respecting the user's final decision-making right, intelligent optimization suggestions are also provided, thus guaranteeing the practicality and reliability of the reconstruction mechanism.

[0082] It is important to note that the subscription system maintains a complete reconstruction history chain. For each reconstruction action, the reconstruction history of the subscription task is recorded, including the identification information of the reconstruction task, the identification information of the subscription rule, the query information of the subscription task, the query information after the update of the subscription task, the reconstruction time of the subscription task, the reason for the reconstruction of the subscription task, and the reconstruction selection of the subscription account, forming a traceable evolution trajectory of the life stage.

[0083] Figure 4The flowchart illustrates the implementation of the adaptive refactoring mechanism for subscription tasks. First, a preliminary judgment is made based on similarity results using quantitative indicators. If the similarity meets the quantitative indicators, state keywords in the change summary of the subscription task in the semantic analysis results are identified to determine whether the state keyword signifies that the subscription object has moved from one lifecycle stage to the next. If the dual refactoring conditions are met, refactoring prompts are constructed. These prompts are analyzed using LLM to identify the latest state of the subscription object (e.g., whether it has changed from an unpublished state to a published state). Based on the latest state of the subscription object, the focus is adjusted (e.g., from publishing time prediction to price / performance evaluation query dimensions), maintaining the user's core focus intent, and generating natural and fluent updated query information. Then, the relevant fields of the subscription task's query information in the subscription rules are updated, and the refactoring history is recorded. During this process, users can selectively receive refactoring notifications. The subscription system explains the reasons for the adjustments and the new query dimensions in a user-friendly manner, enhancing users' understanding and trust in the system's intelligent behavior. This transparent design ensures both the convenience of automation and preserves the user's right to know and control.

[0084] The technical solution provided in this application has the ability to learn and optimize autonomously. It can analyze historical execution data, establish a correlation model between content change patterns and user attention dimensions, identify changes in the demand for subscription tasks, and automatically adjust subscription parameters and task structure, thereby realizing continuous optimization and personalized evolution of subscription tasks.

[0085] The following describes the process of whether to push the query results of the subscription task to the subscription account, including at least one of steps S21 to S23.

[0086] Step S21: Obtain the historical query results and historical query time of the subscribed task.

[0087] The historical query results and historical query times of the subscription task are obtained from the data storage system. The historical query results of the subscription task are obtained based on the historical query information of the subscription task, and the historical query time of the subscription task refers to the time when the subscription system generates the historical query results of the subscription task.

[0088] Step S22: Based on the query information of the subscription task, the historical query results and historical query time of the subscription task, and the query results and query time of the subscription task, perform semantic analysis on the subscription task to obtain the semantic analysis result of the subscription task. The semantic analysis result includes second indication information, which is used to indicate whether to push the query results of the subscription task to the subscription account.

[0089] Semantic analysis is used to analyze the deep semantics of the query information of subscription tasks and the impact of time on subscription tasks. It determines whether the information of the subscribed object has changed, thus determining whether to push the query results of the subscription task to the subscription account. If the information of the subscribed object has changed significantly, the query results of the subscription task can be considered to have substantial meaning to the subscription account, and the query results of the subscription task need to be pushed to the subscription account. If the information of the subscribed object has changed little, or has not changed, the query results of the subscription task can be considered to have no substantial meaning to the subscription account, and the query results of the subscription task do not need to be pushed to the subscription account.

[0090] Step S23: If the second instruction information is used to instruct the subscription account to push the query results of the subscription task to the subscription account, the query results of the subscription task are pushed to the subscription account.

[0091] By performing semantic-level comparisons of the query information for subscription tasks, the subscription system can fully understand the deeper meaning of the query information, identify synonyms and distinguishing expressions in the text, determine whether the information of the subscription object has undergone substantial changes, and introduce time context for time-aware analysis during the semantic comparison process to determine the changes that time has brought to the subscription task, thereby improving the accuracy of semantic detection and thus improving the accuracy of push decision logic. This results in a fundamental improvement in the relevance of push content and user satisfaction.

[0092] In some embodiments, step S22 includes at least one of the sub-steps S221 to S222.

[0093] Sub-step S221 generates analysis prompts for the LLM, which guide the LLM to analyze changes in the information of the subscribed objects based on the query results of the subscription tasks.

[0094] In some embodiments, the analysis prompt information includes at least one of the following: second role definition information, second input information, second task requirement information, and second output format information.

[0095] The second role definition information instructs the LLM to act as an optimization assistant for subscription tasks, determining whether to push the query results of the subscription task to the subscription account. This second role definition information also indicates the LLM's role in the semantic analysis process: performing semantic analysis on the subscription task, determining whether it's necessary to push the query results to the subscription account, and, if necessary, summarizing the changes to the subscription task.

[0096] The second input information is used to indicate changes in the information of the subscribed object. The second input information includes: the query information of the subscription task, the historical query results of the subscription task, the historical query time of the subscription task, the query results of the subscription task, and the query time of the subscription task.

[0097] The second task requires information to determine whether changes in the subscriber's information meet the push notification requirements. Different subscription tasks correspond to different push notification requirements. For example, if a subscription task is used to periodically obtain information on whether a product has been released, then if the subscriber's information indicates that the product has been released, it is determined whether the changes in the subscriber's information meet the push notification requirements. If a subscription task is used to periodically obtain information on product price reductions, then if the subscriber's information indicates that the price reduction is greater than a first percentage or a first value, it is determined whether the changes in the subscriber's information meet the push notification requirements. If a subscription task is used to periodically obtain information on whether a product is sold out, then if the subscriber's information indicates that the product is sold out, it is determined whether the changes in the subscriber's information meet the push notification requirements.

[0098] If the changes in the information provided by a subscriber do not meet the push notification requirements, then it can be considered unnecessary to push that subscriber's information to the subscriber's account, as such information has no practical value to the user. For example, if the subscriber's information consistently indicates that a product has not yet been released, then the notification of the product's non-release is meaningless to the user; only the notification of the product's release is meaningful. Similarly, if the price reduction indicated by the subscriber's information is small, such as a price reduction of 10 yuan or 1%, then the price reduction notification is also meaningless to the user. It is only necessary to push price reduction information to the user if the product's price reduction meets the requirements and offers a significant discount.

[0099] The second output format information is used to indicate the information format of the semantic analysis result. For example, the second output format information is used to indicate that the semantic analysis result is output information in JSON format, which may include the second indication information, the reason for the push, and a summary of the changes to the subscription task.

[0100] By constructing analysis prompts using the above method, the LLM can obtain more comprehensive semantic analysis instructions, which makes it easier for the LLM to accurately determine whether to push the query results of the subscription task to the subscription account based on the analysis prompts, thus improving the accuracy of the LLM's push logic judgment.

[0101] Sub-step S222: Based on the analysis prompts, LLM generates semantic analysis results for the subscription task. The semantic analysis results also include a change summary of the subscription task, which is used to summarize the state changes of the subscription object.

[0102] It is important to note that during the process of generating semantic analysis results for subscription tasks in LLM, the similarity between the query results of the subscription task and the historical query results of the subscription task will also be output midway.

[0103] By employing LLM (Limited Language Management) for semantic analysis of subscription tasks, compared to traditional text similarity algorithms, LLM's semantic analysis method achieves a leap from surface matching to deep semantic understanding. It can accurately distinguish between semantic phrasing changes and substantive changes, effectively filtering out surface textual differences caused by website redesigns, wording adjustments, etc., avoiding false positives and reducing the false positive rate of the subscription system. Furthermore, LLM can identify the semantic impact of synonyms and the passage of time, accurately judging the timeliness value of time factors and reducing the false negative rate of the subscription system. Moreover, through time-aware engineering and the design of subscription-specific rules, the subscription system achieves precise adaptation to different scenarios. In the price reduction notification subscription scenario, the system can determine whether price fluctuations are substantial; in the new product release subscription scenario, the system can distinguish between the deterministic release time and subsequent detailed updates; in the promotional notification subscription scenario, the system can identify the differences between new offers and description tweaks, effectively solving the core pain points of traditional subscription systems such as high noise and low relevance.

[0104] In some embodiments, the semantic analysis dimensions of LLM include at least one of the following: fact change dimension, timeliness impact dimension, information expression dimension, and new information dimension.

[0105] The fact change dimension is used to analyze whether key information in the query results of a subscription task has changed. LLM can extract key information from the query results of a subscription task and compare it with key information from historical query results to determine whether the key information has changed. For example, if the subscription object is a product, the key information in the query results may include at least one of the following: product price, product release time, product inventory status, product user ratings, etc. Determining whether the key information has changed means determining whether the product price has increased or decreased, whether the product release time has been updated, whether the product inventory status has decreased, and whether the product user ratings have increased or decreased.

[0106] The timeliness impact dimension is used to analyze whether the information of the subscribed object changes over time. For example, if the information of the subscribed object is "expected to be released in Q4", then querying the subscription task in Q3 will yield the predicted result, i.e., "expected to be released in Q4". However, querying the subscription task in Q4 may yield the result "soon to be released" or "already released". Therefore, querying the subscription task at different points in time will yield different information about the subscribed object.

[0107] The information description dimension is used to analyze whether changes in the description of information from a subscriber result in semantic changes. For example, website redesigns or wording adjustments may cause surface textual changes in the information from a subscriber. For instance, if the subscriber's historical information was described as "priced at 7999 yuan," and the current information is described as "7999 yuan," then the description of the information has changed, but this change in description has not resulted in a semantic change.

[0108] The new information dimension is used to analyze whether new information has appeared in the news information of the subscribed object. For example, if the subscribed object is a product, it can analyze whether information such as new free gifts, new promotional activities, or new product introductions has appeared in the news information of the subscribed object. If the product price has not changed, the addition of "free wireless headphones" to the product information also constitutes a substantial change in the news information of the subscribed object.

[0109] By conducting multi-dimensional semantic analysis from the dimensions of factual changes, timeliness impact, information expression, and new information, LLM can fully identify the substantial changes in subscription tasks across different dimensions. By combining the results of multi-dimensional analysis, the accuracy of the final semantic analysis output can be improved, avoiding false positives and false negatives.

[0110] Figure 5 The flowchart illustrates the implementation of the semantic similarity comparison algorithm for subscription tasks. It constructs LLM's analysis prompts, including the original query information, historical query results, current query results, and temporal context (historical query time and current query time). Based on these prompts, LLM performs semantic analysis on the subscription task from the dimensions of factual change, timeliness impact, information description, and new information, obtaining semantic analysis results. These results include push decision (i.e., whether to push the query results of the subscription task to the subscription account), a change summary, and similarity.

[0111] The following describes the process of generating query information for subscription tasks, including at least one of steps S31 to S33.

[0112] Step S31: Obtain the metadata of the subscription rule corresponding to the subscription task based on the subscription rule corresponding to the subscription task. The metadata of the subscription rule is used to indicate the execution status of the subscription task.

[0113] Subscription rules are rules used to indicate the execution status of subscription tasks, and the metadata of subscription rules is a concrete representation of the subscription rules. Based on the subscription task, the corresponding subscription rule is loaded, and the metadata of the subscription rule corresponding to the subscription task is parsed.

[0114] In some embodiments, the metadata of a subscription rule includes at least one of the following: the identification information of the subscription rule; the account information of at least one subscription account corresponding to the subscription rule; the subscription object corresponding to the subscription rule; the query dimension corresponding to the subscription rule; the query information corresponding to the subscription rule; the query frequency corresponding to the subscription rule; the creation time corresponding to the subscription rule; and the update time corresponding to the subscription rule.

[0115] At least one subscription account corresponding to a subscription rule refers to the subscription account that created the subscription task corresponding to the subscription rule. The metadata of the subscription rule records the account information of all subscription accounts that created the same subscription task. For example, the metadata of a subscription rule can be represented as: rule_id (identifier of the subscription rule), uin (UserIdentification Number), products (subscription objects corresponding to the subscription rule), dimensions (query dimensions corresponding to the subscription rule), query (query information corresponding to the subscription rule), frequency (query frequency corresponding to the subscription rule), status (lifecycle stage of the subscription object), created_at (creation time of the subscription rule), updated_at (update time of the subscription rule), and dedup_key (deduplication key of the subscription rule). The deduplication key corresponding to the subscription rule is used to indicate the account information of at least one subscription account corresponding to the subscription rule.

[0116] By setting the metadata of the subscription rules using the above method, query information for the subscription task can be generated based on the metadata of the subscription rules. The information of the subscription object in the query dimension can be queried according to the query frequency included in the metadata, and the query results can be pushed to at least one subscription account. This constructs all the data required to execute the subscription task and ensures the normal execution of the subscription task.

[0117] Step S32: Obtain the grouping information of the subscription task. The grouping information of the subscription task includes the account information of at least one subscription account that created the subscription task.

[0118] Based on the deduplication key corresponding to the subscription rules, the grouping information of the subscription tasks is obtained. The grouping information of the subscription tasks includes the account information of all subscription accounts that created the same subscription task. Here, "same subscription task" means that the corresponding query frequency, query dimension, and query object are all the same. "Different subscription tasks" means that the corresponding subscription tasks have one or more differences in query frequency, query dimension, and query object.

[0119] In some embodiments, a subscription task list is obtained, which includes multiple subscription tasks. Each subscription task is created by a subscription account and is used to periodically retrieve information about the subscribed object in a query dimension. The subscription task list is deduplicated based on the subscription object and query dimension corresponding to each subscription task, resulting in a deduplicated subscription task list. Grouping information for the subscription tasks is obtained based on the subscription account corresponding to each subscription task in the deduplicated subscription task list.

[0120] The subscription task list includes subscription tasks created by each subscription account. Each subscription account can create one or multiple subscription tasks, and different subscription accounts can create the same or different subscription tasks. Based on the subscription object, query dimension, and query frequency corresponding to the subscription task, the subscription task list is deduplicated, retaining only the identical subscription tasks. This deduplicated subscription task list allows you to group the subscription accounts corresponding to each subscription task in the deduplicated subscription task list, thus obtaining the subscription task grouping information.

[0121] Based on the deduplicated subscription tasks in the deduplicated subscription task list, a deduplication key is generated for each subscription task. This key is used to identify identical subscription tasks and their grouping information. For example, the deduplication key can be an MD5 (Message-Digest Algorithm 5) hash value.

[0122] By integrating the same subscription tasks, the subscription system only needs to execute the subscription task once to distribute the query results of the subscription task to all subscription accounts indicated by the grouping information, thereby reducing the resource consumption of the subscription system and improving its performance.

[0123] Step S33: For at least one subscription account, generate query information for the subscription task based on the metadata of the subscription rules.

[0124] Based on the grouping information of the subscription task, query information for the subscription task is generated for at least one subscription account indicated by the grouping information. This query information is used as the common query information for the subscription task of at least one subscription account, which avoids performing a large number of repetitive query operations on the same subscription task, reduces the total execution time of the subscription system, improves the efficiency of query operations, and greatly reduces the resource consumption of the subscription task.

[0125] It is important to note that the subscription system employs a worker pool model for concurrency control. By configuring the number of worker threads to limit the number of concurrent tasks, the system prevents resource exhaustion and overload crashes, ensuring stability under high load scenarios. By creating a fixed number of worker threads and using a task queue for scheduling, the system avoids the impact of excessive concurrency on the LLM and search services, while achieving natural load balancing. This application does not limit the threshold for the number of concurrent tasks per worker thread; for example, a maximum of 10 worker threads can be created in the worker pool model.

[0126] Furthermore, the subscription system supports a priority-based task scheduling algorithm, where high-priority subscription tasks are given priority access to the subscription system's task execution resources, while low-priority subscription tasks are given priority access, thereby ensuring the timeliness of important subscription tasks.

[0127] Figure 6 This diagram illustrates the process of pushing query results for a subscription task. After the subscription system starts executing the subscription task, it parses the subscription rules, executes the search task based on the query information contained in the subscription rules, and generates the query results. It then checks if historical query results for the subscription task exist in the data storage system. If not, it indicates that this is the first time the subscription task has executed a search task, and the query results are saved to the Redis cache database and the push message for the query results are saved to the Elasticsearch message repository. The message push service then pushes the query results to the subscription accounts. If historical query results for the subscription task exist in the data storage system, an LLM (Local Management Model) is used to perform a semantic comparison between the subscription task's query results and the historical query results to determine their similarity, obtaining a semantic analysis result. If the semantic analysis result indicates that the subscription task's query results are similar to historical query results, only the subscription system's search records are saved; if the semantic analysis result indicates that the subscription task's query results are not similar to historical query results, the Redis cache database and the Elasticsearch message repository are updated, and the message push service then pushes the query results to the subscription accounts.

[0128] The following describes the process of generating the query results for the subscription task, including at least one of steps S41 to S42.

[0129] Step S41: Based on the query information of the subscribed task, retrieve the query data corresponding to at least one query node in sequence according to the priority order of at least one query node.

[0130] The priority order of at least one query node is a predefined order, used to indicate the order in which the subscription system accesses the query nodes. Following the priority order of at least one query node, the subscription system sequentially retrieves the query data required for the subscription task from each query node. The query data corresponding to each query node is used to indicate the information available to the subscription object at that query node.

[0131] For example, at least one query node includes, but is not limited to, query nodes such as Session memory, priority Agent node, root task Answer field, and Markdown resource extraction.

[0132] In some embodiments, if the query process of a subscription task meets the retry conditions, the step of retrieving query data is re-executed from the previous query node preceding the current query node, according to an exponential backoff strategy. The exponential backoff strategy indicates the threshold number of times the query step is re-executed and the time interval between each re-execution.

[0133] The retry condition is used to indicate that the query data retrieval for the current query node failed. Data query failure can have various causes, such as network fluctuations, temporary unavailability of the query node, or temporary unavailability of the agent in the subscription system. If the retry condition is met during the subscription task's query process, the corresponding query data needs to be retrieved again from the current query node. This can be achieved by reverting to the previous query node and re-executing the data retrieval steps from that node; that is, first retrieve the query data corresponding to the previous query node, and then re-retrieve the query data corresponding to the current query node.

[0134] The exponential backoff strategy indicates a threshold for the number of times a query step can be re-executed. This threshold represents the maximum number of times the subscription system allows a query step to be re-executed within the overall query process of the subscription task. This means that query steps can be re-executed for the same query node or for different query nodes. If the subscription task fails to generate a query result after reaching the threshold for re-execution, the subscription task is considered a query failure. For example, if the threshold for re-execution is 3, the subscription system will execute the query step a maximum of 3 times. If the query result is still not generated after 3 retries, the query step will be stopped, and the subscription task is considered a query failure.

[0135] The exponential backoff strategy is also used to indicate the time interval between each re-execution of the query step. Optionally, the time interval between each re-execution of the query step can be the same or different. For example, if the threshold for the number of re-executions of the query step is 3, then the time intervals for the 3 re-executions of the query step are 1 second, 2 seconds, and 4 seconds, respectively. That is, after the first query failure, the query step is re-executed after an interval of 1 second; after the second query failure, the query step is re-executed after an interval of 2 seconds; and after the third query failure, the query step is re-executed after an interval of 4 seconds.

[0136] By re-executing the query steps according to the exponential backoff strategy when the query process of the subscription task meets the retry conditions, the success rate of data retrieval is guaranteed. At the same time, the number of times threshold is used to avoid endless re-executing of the retrieval steps, ensuring the rational allocation of query resources and avoiding resource waste, thereby improving the success rate of subscription task execution and the overall robustness of the system.

[0137] In some embodiments, the retry conditions include at least one of the following: the current query node is not accessed during a first time period; the query data corresponding to the current query node is not found from the current query node during a second time period; and the LLM is not accessed during a third time period.

[0138] During the query process of a subscription task, at least one query node and an LLM need to be invoked to obtain query data from at least one query node and generate the query results of the subscription task through the LLM.

[0139] If the current query node is not connected within the first time period, it can be considered that the current query node connection has timed out. It needs to reconnect to the previous query node to obtain the query data before reconnecting to the current query node. This application does not limit the first time period; for example, the first time period can be 20 seconds.

[0140] If no query data corresponding to the current query node is found within the second time period, the query task of the current query node can be considered frozen. It is necessary to revert to the previous query node to retrieve the query data again, and then retrieve the query data corresponding to the current query node from the current query node. This application does not limit the second time period; for example, the second time period can be 30 seconds.

[0141] If LLM is not accessed during the third time period, the LLM call can be considered to have timed out. It is necessary to revert to the last query node to retrieve the last query data, then reconnect to LLM, and generate the query results for the subscription task based on the query data corresponding to at least one query node. This application does not limit the third time period; for example, the third time period can be 60 seconds.

[0142] By setting up timeout and failure tolerance mechanisms, subscription tasks have the opportunity to be re-executed, which improves the success rate of subscription tasks in the subscription system and enhances the response efficiency of subscription tasks, effectively ensuring the stability of subscription task responses.

[0143] Furthermore, if no query results for the subscription task are obtained within the fifth time period, and the subscription task query is determined to have failed, a timeout protection mechanism is activated. Timeout-exceeding subscription tasks are automatically marked as query failures, and the query resources of the subscription system are released to prevent prolonged suspension and occupation of system resources. This application does not limit the fifth time period; for example, the fifth time period can be 30 minutes.

[0144] Step S42: Based on the query data corresponding to at least one query node, the LLM generates the query results of the subscription task. The query results of the subscription task include at least one of the following modalities: text, image, chart, table, voice, and video.

[0145] The query results of subscription tasks are multimodal query reports. LLM extracts key information from the query data corresponding to at least one query node and integrates and summarizes it, so that the key information in the query data can be presented in the most appropriate form. This ensures that the query results of subscription tasks are not only textual descriptions, but also have information display in other modalities, avoiding the limitations of single-modal output. Users can intuitively understand the information changes of the subscribed object through information in different modalities, which improves the display effect of the query results of subscription tasks and enhances the user's query experience for subscription tasks.

[0146] In some embodiments, if the semantic analysis result of the subscription task is not obtained within the fourth time period, it is determined that the semantic analysis of the subscription task has failed; the hash value of the query result of the subscription task and the historical hash value of the historical query result of the subscription task are obtained; if the semantic analysis of the subscription task fails and the hash value and the historical hash value are different, the query result of the subscription task is pushed to the subscription account.

[0147] The subscription system has a fallback mechanism for determining whether a subscription task will fail semantically. If the semantic analysis of the subscription task fails, the semantic analysis is downgraded to a simple hash value comparison. If the hash value of the subscription task's query result differs from the historical hash value of the subscription task's historical query results, the query result of the subscription task can be considered changed, and the subscription account can then push the query result of the subscription task. This application does not limit the fourth time period.

[0148] By setting up a fallback mechanism for the push decision-making mechanism, if semantic analysis fails, the system will push a notification to the subscription account only if the query results of the subscription task change. This ensures the stability of the subscription system's handling of subscription tasks and avoids push failures that could affect the operation of the subscription system.

[0149] In some embodiments, the processing of subscription tasks is implemented by an intelligent agent; the intelligent agent obtains the query results of the subscription task by calling a first intelligent agent; the intelligent agent performs semantic analysis on the subscription task and reconstructs the query information of the subscription task by calling a second intelligent agent; the intelligent agent pushes the query results of the subscription task to the subscription account by calling a third intelligent agent.

[0150] The SubscribeAgent is the core scheduling engine of the subscription system. As a central scheduler, it manages the entire lifecycle of the subscription task and coordinates the different processing flows of each agent. The first agent retrieves query data corresponding to at least one query node and generates the query results for the subscription task using LLM (Local Management Model). The second agent performs semantic analysis on the subscription task, obtaining the semantic analysis results and reconstructing the query information to obtain the updated query information. The third agent implements the message push service, pushing the query results of the subscription task to the subscribing accounts.

[0151] Figure 7This diagram illustrates the core scheduling process of the intelligent agent, employing a modular design to achieve complete task lifecycle management. Its scheduling logic follows a strict state machine pattern, comprising multiple key steps forming a complete processing pipeline: parsing subscription rules, initializing the context based on the metadata of the subscription rules, and generating query information for subscription tasks. A strategy combining asynchronous calls and polling is used to execute the DeepSearchAgent task, generating query results for the subscription tasks and avoiding prolonged blocking of the main process. Internally, this method implements an intelligent polling mechanism, checking the task status every minute, waiting a maximum of 30 minutes, and using a heartbeat timeout mechanism to promptly detect dead tasks and prevent system stagnation. A multi-level priority strategy is employed, sequentially retrieving query data from each query node, and then generating multimodal query results based on the query data corresponding to multiple query nodes. Historical data queries implement a hybrid query strategy using Redis and Elasticsearch, prioritizing millisecond-level responses from Redis, and automatically degrading to Elasticsearch for deep queries in case of failure, ensuring high availability of data retrieval. Semantic similarity comparison is the core innovation of the subscription system. It employs time-aware prompt word engineering technology, fusing multi-dimensional contextual information such as historical query time, current query time, and query details into the LLM (Local Language Module) to achieve deep semantic understanding rather than simple text matching. Finally, based on the semantic analysis results, the Redis cache database and Elasticsearch message repository are updated, triggering a push decision. The entire process utilizes lightweight Goroutines in Go for concurrent processing and employs a Channel mechanism for state synchronization, ensuring the stability and responsiveness of the subscription system under high concurrency scenarios.

[0152] Figure 8 The flowchart of the multi-agent collaboration mechanism is shown. The subscription system follows a master-slave collaboration mode. The SubscribeAgent, as the master controller, is located at the center of the architecture and is responsible for global scheduling and process orchestration. It coordinates multiple specialized agents through a message passing mechanism to form an efficient task processing pipeline.

[0153] The Agent-based layered collaboration system is functionally divided into three collaboration layers: The first layer is the task search layer, where the DeepSearch Agent, as the core node for information acquisition, is responsible for multi-source information search and content aggregation. Internally, it further coordinates fine-grained sub-agents such as the WebSearch Agent (web crawling), DataAnalysis Agent (data analysis), and ChartGenerationAgent (chart generation) to achieve integrated processing of search, analysis, and visualization. The second layer is the intelligent analysis layer, where the LLM Service, as the "brain" of the subscription system, provides advanced intelligent services such as semantic similarity comparison, adaptive task reconstruction, and change summary generation. All tasks requiring deep understanding and reasoning are handled by this layer. The third layer is the message push layer, where the Notification Service is responsible for multi-channel message distribution, supporting various notification methods such as in-site messages, emails, and mobile push notifications, and integrating automatic poster generation and message persistence management functions.

[0154] Meanwhile, the Subscribe Agent allows for concurrency control and fault tolerance strategies. The system employs a worker pool model for concurrency control, limiting the number of concurrent tasks by configuring the number of worker threads to prevent system resource exhaustion and overload crashes. Each subscription task has a timeout protection mechanism; timed-out tasks are automatically marked as failed and resources are released, avoiding prolonged suspension and resource occupation. The system supports a priority-based task scheduling algorithm, with high-priority subscription tasks receiving execution resources first, ensuring the timeliness of important subscriptions. For temporary failures (such as network fluctuations or temporary service unavailability), the system implements an exponential backoff retry mechanism to improve task execution success rate and overall system robustness.

[0155] Agents communicate using an asynchronous message passing mechanism. The Subscribe Agent initiates task requests by calling the standardized interface of its sub-agents, which then return the processing results via callback functions. The system implements a unified data exchange format (based on JSON) to ensure interoperability between different agents. For long-running tasks (such as DeepSearch Agents), a polling model is used to obtain execution status, preventing main process blockage. The system also implements agent-level logging, collecting metrics such as the number of calls, success rate, and average response time for each agent, providing data support for system optimization and problem diagnosis.

[0156] From an architectural perspective, the Subscribe Agent, acting as the central scheduler, implements a complete 10-stage state machine management system, modularizing and streamlining complex logic such as task scheduling, semantic comparison, refactoring evaluation, and push decisions. Each stage has an independent fault tolerance mechanism, including timeout control, failure retry, and fallback solutions, ensuring that the failure of a single stage does not lead to the failure of the entire task. The DeepSearch Agent, as a specialized search module, focuses on multi-source information integration and structured report generation, with clear responsibilities and loose coupling. This architectural design not only improves the system's stability and maintainability but also provides a flexible technical foundation for subsequent functional expansion (such as adding subscription dimensions and switching LLM models), improving the overall system execution efficiency and resource utilization.

[0157] The complete state machine of the Subscribe Agent includes: 1. Initialization Phase: Loading subscription rules and parsing metadata such as query information, query dimensions, and query frequency of subscription tasks. 2. Deduplication and Grouping Phase: Generating MD5 deduplication keys based on the query information, query dimensions, and query frequency of subscription tasks, and grouping identical subscription tasks. 3. Task Execution Phase: Calling the DeepSearch Agent to execute queries and obtain structured query results. 4. Historical Query Phase: Retrieving historical query data (LastAnswer, LastExecutedAt) from the Redis cache database or MySQL cache database. 5. Semantic Comparison Phase: Calling LLM to perform semantic similarity analysis to determine whether there are substantial changes in the information of the subscribed objects. 6. Restructuring Evaluation Phase: If a lifecycle phase transition is detected, calling LLM to make a restructuring decision. 7. Push Decision Phase: If there are substantial changes, calling LLM to generate a push summary. 8. Push Execution Phase: Calling the push service to send notifications to the subscription accounts and saving the messages to the Elasticsearch message box. 9. State Update Phase: Updating the LastAnswer and LastExecutedAt fields of the subscription rules and writing them to the Redis cache database. 10. Archiving stage: Write the task execution records (Fields such as TaskID, Answer, lastexecutedatCostTime, etc.) into the MySQL history table.

[0158] DeepSearch Agent's professional search capabilities include: 1. Multi-source information integration: Integrating information from multiple data sources such as search engine APIs (Application Programming Interfaces), e-commerce platform APIs, and web crawlers. 2. Structured report generation: Generating query results in multiple modalities, including text summaries, data tables, and trend charts, through LLM analysis. 3. Quality assessment mechanism: Scoring the quality of query data at each query node (information completeness, timeliness, credibility, etc.) and filtering low-quality data. 4. Caching optimization: Cacheing high-frequency queries (such as popular products) with a cache validity period of 5-10 minutes to reduce duplicate queries.

[0159] Figure 9 The diagram illustrates the overall architecture of the subscription system. The system employs a layered and decoupled design, with clear responsibilities across the four layers of scheduling, execution, service, and storage, facilitating independent expansion and optimization. For agent collaboration, the Subscribe Agent acts as the central scheduler, while the DeepSearch Agent serves as the specialized search module, with clearly defined responsibilities. Specifically, the SubscribeAgent, as the main controller, is responsible for the entire subscription task lifecycle management, coordinating specialized agents such as the DeepSearchAgent, LLM service, and notification service to complete complex subscription processing flows. The service layer modularizes LLM, search, push, and caching services, supporting the replacement of different implementations (such as switching LLM models). Finally, storage is layered: Redis caches frequently accessed data, MySQL stores structured data, and Elasticsearch stores unstructured messages, supporting both efficient semantic search and convenient data lifecycle management.

[0160] This application adopts a three-tier architecture of Redis caching, MySQL structured storage, and Elasticsearch unstructured storage, and designs differentiated storage strategies for different data characteristics, achieving an optimal balance between query performance and storage cost.

[0161] For hot data access, the Redis cache database stores subscription rule metadata, historical execution results, and deduplicated grouping information, with a TTL (Time to Live) set to 90 days or 24 hours. Since subscription tasks are typically queried once a day, a 90-day cache window covers the vast majority of query scenarios, maintaining a high cache hit rate. The introduction of caching reduces the response time for rule loading and historical data queries from tens of milliseconds for database queries to milliseconds for cache reads, improving response speed by an order of magnitude.

[0162] For example, the metadata of a subscription rule can be represented as: rule_id (identification information of the subscription rule), uin (User Identification Number), products (subscription objects corresponding to the subscription rule), dimensions (query dimensions corresponding to the subscription rule), query (query information corresponding to the subscription rule), frequency (query frequency corresponding to the subscription rule), status (lifetime stage of the subscription object), created_at (creation time corresponding to the subscription rule), updated_at (update time corresponding to the subscription rule), and dedup_key (deduplication key corresponding to the subscription rule). The historical execution result cache is: Key="last_answer:{rule_id}", Value=LastAnswer (historical query result of the subscription task) + LastExecutedAt (historical query time of the subscription task), TTL=90 days, accelerating semantic comparison. The deduplicated group information cache is: Key="dedup_group:{dedup_key}", Value=list of rule IDs (including account information of at least one subscription account within the group information), TTL=24 hours, accelerating group queries. After each subscription task is executed, the Redis cache database is updated asynchronously to ensure eventual consistency between the cache and the database.

[0163] For structured data, the MySQL cache database serves as persistent storage for subscription rules, task execution records, and reconstruction history. Through well-designed indexing strategies (such as a composite index on `uin` and `status`, and a composite index on `rule_id` and `executed_at`), the system can efficiently support core operations such as user subscription queries and historical record queries. More importantly, the task execution record table employs a data lifecycle management strategy, retaining only records from the most recent 90 days, archiving expired data to cold storage or deleting it. This strategy prevents the MySQL table from growing indefinitely (otherwise, tens of millions of records would severely impact query performance) while simultaneously reducing the cost of high-performance storage.

[0164] For example, the subscription rule cache is: Key="subrule:{rule_id}", Value=rule JSON, TTL=90 days, to speed up rule loading. The task execution record (stores detailed records of each execution) is cached as: task_id (identifier of the subscription task), rule_id (identifier of the subscription rule), query (query information of the subscription task), answer (query result of the subscription task), lastexecuted_at (query time of the subscription task), cost_time (query time spent by the subscription task), and is_pushed (indicator information on whether the subscription task was successfully executed). The reconstruction history table (stores the reconstruction history of subscription tasks) is cached as: record_id (identifier of the reconstruction record), rule_id (identifier of the subscription rule), old_query (query information of the subscription task), new_query (query information after the update of the subscription task), reason (reason for reconstruction), reconstructed_at (reconstruction time), and user_confirmed (user's reconstruction choice). Task execution records are retained for 90 days; records older than 90 days are archived to cold storage. Reconstructed history is permanently retained for algorithm optimization and analysis.

[0165] For unstructured message data, Elasticsearch's monthly sharding indexing strategy offers flexible scalability and lifecycle management capabilities. New indexes are created automatically each month, and indexes older than 12 months are automatically deleted, ensuring that storage capacity grows linearly over time rather than exponentially. Furthermore, Elasticsearch's full-text search capabilities allow users to search messages by product name, offering a significant performance advantage over MySQL's LIKE fuzzy search, with query response times consistently in the hundreds of milliseconds.

[0166] For example, a monthly sharded index is used, with the index naming convention being "subscribe_inbox_YYYYMM" (e.g., "subscribe_inbox_202501"). A new index is automatically created monthly. The document structure is as follows: msg_id (index identifier), uin (account information of the subscribing account), rule_id (identifier of the subscription rule), task_id (identifier of the subscription task), title (title of the push message), description (text description of the push message), answer (query result of the subscription task), reason (reason for the push), created_at (creation time of the push message), and is_read (whether the user read the push message). A composite index is created using uin and created_at to support efficient user message list queries and time range filtering. Lifecycle management: Indexes from the most recent 12 months are retained; indexes older than 12 months are automatically deleted, saving storage costs.

[0167] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0168] Please refer to Figure 10 This diagram illustrates a block diagram of a subscription task processing apparatus according to an embodiment of this application. The apparatus has the function of implementing the above-described subscription task processing method; this function can be implemented in hardware or by hardware executing corresponding software. The apparatus can be the computer device described above, or it can be installed within a computer device. Figure 10 As shown, the device 1000 may include: a result acquisition module 1010, a status determination module 1020, and an information reconstruction module 1030.

[0169] The result acquisition module 1010 is used to acquire the query result of the subscription task based on the query information of the subscription task, wherein the subscription task is used to periodically acquire information information of the subscription object.

[0170] The status determination module 1020 is used to determine the status of the subscription object based on the query results of the subscription task.

[0171] The information reconstruction module 1030 is used to reconstruct the query information of the subscription task when the query information of the subscription task does not match the state of the subscription object, so as to obtain the updated query information of the subscription task.

[0172] In some embodiments, the state determination module 1020 is configured to: The query results of the subscription task are checked to see if they contain predefined status keywords, which are keywords related to the status changes of the subscription object. The status of the subscription object is determined based on the status keywords contained in the query results of the subscription task.

[0173] In some embodiments, the information reconstruction module 1030 is configured to: Based on the state of the subscribed object, the query information of the subscription task is reconstructed to obtain the updated query information of the subscription task.

[0174] In some embodiments, the information reconstruction module 1030 is configured to: Refactoring suggestions are generated for a large language model (LLM), which guide the LLM to adjust the query information of the subscription task according to the state changes of the subscription object. The LLM generates a reconstruction result based on the reconstruction prompt information; wherein the reconstruction result includes first indication information, which indicates whether to reconstruct the query information of the subscription task, and when the first indication information indicates that the query information of the subscription task should be reconstructed, the reconstruction result also includes the updated query information of the subscription task.

[0175] In some embodiments, the reconstruction prompt information includes at least one of the following: The first role definition information is used to instruct the LLM to act as an optimization assistant for the subscription task and adjust the query information of the subscription task according to the status changes of the subscription object; The first input information is used to indicate the state change of the subscribed object; The first task requirement information is used to indicate the adjustment requirements for the query information of the subscribed task; The first output format information is used to indicate the information format of the reconstruction result.

[0176] In some embodiments, the first input information includes at least one of the following: The query information for the subscription task; The query results of the subscription task; The change summary of the subscription task is used to summarize the state changes of the subscription object; The status keywords for the subscription task.

[0177] In some embodiments, the device 1000 further includes an information update module, the information update module being configured to: Obtain the confidence level of the reconstruction result, which is used to indicate the credibility of the reconstruction result; If the confidence level is greater than or equal to the first threshold, the query information of the subscription task is updated to the updated query information of the subscription task. If the confidence level is less than the first threshold and greater than the second threshold, it is determined whether to update the query information of the subscription task to the updated query information of the subscription task based on the reconstruction selection of the subscription account. The subscription account is the user account that created the subscription task. If the confidence level is less than or equal to the second threshold, the update of the query information for the subscription task is cancelled.

[0178] In some embodiments, the information reconstruction module 1030 is configured to: If the status of the subscription task indicates that the life phase of the subscription object on the query dimension corresponding to the subscription task has ended, the step of reconstructing the query information of the subscription task and obtaining the updated query information of the subscription task is not executed.

[0179] In some embodiments, the information reconstruction module 1030 is configured to: Determine the similarity between the query results of the subscription task and the historical query results of the subscription task; If the subscription task meets the reconstruction conditions, the step of reconstructing the query information of the subscription task to obtain the updated query information of the subscription task is performed; wherein, the reconstruction conditions include: the similarity is less than or equal to a third threshold; the query information of the subscription task does not match the state of the subscription object.

[0180] In some embodiments, the device 1000 further includes a result push module, the result push module being configured to: Obtain the historical query results and historical query time of the subscribed task; Based on the query information of the subscription task, the historical query results and historical query time of the subscription task, and the query results and query time of the subscription task, semantic analysis is performed on the subscription task to obtain the semantic analysis result of the subscription task. The semantic analysis result includes second indication information, which is used to indicate whether to push the query results of the subscription task to the subscription account. When the second instruction information is used to instruct the subscription account to push the query results of the subscription task to the subscription account, the query results of the subscription task are pushed to the subscription account.

[0181] In some embodiments, the result push module is configured to: The LLM generates analysis prompts, which guide the LLM to analyze changes in the information of the subscribed object based on the query results of the subscription task. The LLM generates a semantic analysis result for the subscription task based on the analysis prompts. The semantic analysis result also includes a change summary of the subscription task, which is used to summarize the state changes of the subscription object.

[0182] In some embodiments, the analysis prompt information includes at least one of the following: The second role definition information is used to instruct the LLM to act as an optimization assistant for the subscription task and to determine whether to push the query results of the subscription task to the subscription account; The second input information is used to indicate changes in the information of the subscribed object; The second task requires information to determine whether changes in the information of the subscribed object meet the push requirements. The second output format information is used to indicate the information format of the semantic analysis result.

[0183] In some embodiments, the semantic analysis dimension of the LLM includes at least one of the following: The fact change dimension is used to analyze whether key information in the query results of the subscription task has changed; The timeliness impact dimension is used to analyze whether the information of the subscribed object changes over time. The information description dimension is used to analyze whether changes in the description of the information of the subscribed object result in semantic changes. The new information dimension is used to analyze whether new information appears in the information of the subscribed object.

[0184] In some embodiments, the device 1000 further includes an information generation module, the information generation module being configured to: Based on the subscription rule corresponding to the subscription task, the metadata of the subscription rule corresponding to the subscription task is obtained, and the metadata of the subscription rule is used to indicate the execution status of the subscription task; Obtain the grouping information of the subscription task, which includes account information of at least one subscription account that created the subscription task; For the at least one subscription account, query information for the subscription task is generated based on the metadata of the subscription rules.

[0185] In some embodiments, the information generation module is configured to: Get the subscription task list, which includes multiple subscription tasks. Each subscription task is created by a subscription account and is used to periodically obtain information about the subscribed object in the query dimension. Based on the subscription object and query dimension corresponding to the subscription task, the subscription task list is deduplicated to obtain a deduplicated subscription task list; Based on the subscription accounts corresponding to each subscription task in the deduplicated subscription task list, the grouping information of the subscription tasks is obtained.

[0186] In some embodiments, the metadata of the subscription rule includes at least one of the following: The identification information of the subscription rule; The account information of at least one subscription account corresponding to the subscription rule; The subscription object corresponding to the subscription rule; The query dimensions corresponding to the subscription rules; The query information corresponding to the subscription rules; The query frequency corresponding to the subscription rule; The creation time corresponding to the subscription rule; The update time corresponding to the subscription rule.

[0187] In some embodiments, the result acquisition module 1010 is configured to: Based on the query information of the subscription task, the query data corresponding to the at least one query node is obtained sequentially from the at least one query node according to the priority order of the at least one query node; The LLM generates query results for the subscription task based on the query data corresponding to each of the at least one query node. The query results for the subscription task include at least one of the following modalities: text, image, chart, table, audio, and video.

[0188] In some embodiments, the result acquisition module 1010 is configured to: If the query process of the subscription task meets the retry conditions, the step of obtaining query data is re-executed from the previous query node before the current query node, according to the exponential backoff strategy. The exponential backoff strategy is used to indicate the threshold number of times the query step is re-executed and the time interval between each re-execution of the query step.

[0189] In some embodiments, the retry conditions include at least one of the following: The currently queried node was not connected during the first time period; No query data corresponding to the current query node was found from the current query node during the second time period; The LLM was not accessed during the third time period.

[0190] In some embodiments, the result push module is configured to: If the semantic analysis result of the subscription task is not obtained within the fourth time period, it is determined that the semantic analysis of the subscription task has failed. Obtain the hash value of the query result of the subscription task, and the historical hash value of the historical query result of the subscription task; If the semantic analysis of the subscription task fails and the hash value is different from the historical hash value, the query result of the subscription task will be pushed to the subscription account.

[0191] In some embodiments, the processing of the subscription task is implemented by an intelligent agent; The intelligent agent obtains the query results of the subscribed task by invoking the first intelligent agent; The intelligent agent performs semantic analysis on the subscription task and reconstructs the query information of the subscription task by invoking the second intelligent agent; The intelligent agent pushes the query results of the subscription task to the subscription account by invoking a third intelligent agent.

[0192] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the content structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0193] Please refer to Figure 11 This diagram illustrates a structural block diagram of a computer device 1100 provided in one embodiment of this application. The computer device 1100 can be any electronic device capable of data computation, processing, and storage. The computer device 1100 can be used to implement the subscription task processing method provided in the above embodiments.

[0194] Typically, computer device 1100 includes a processor 1101 and a memory 1102.

[0195] Processor 1101 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1101 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1101 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1101 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1101 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0196] The memory 1102 may include one or more computer-readable storage media, which may be non-transitory. The memory 1102 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1102 are used to store a computer program configured to be executed by one or more processors to implement the above-described method for processing the subscription task.

[0197] Those skilled in the art will understand that Figure 11 The structure shown does not constitute a limitation on the computer device 1100 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0198] In an illustrative embodiment, a computer-readable storage medium is also provided, wherein a computer program is stored in the storage medium, and the computer program, when executed by a processor of a computer device, implements the above-described method for processing the subscription task. Optionally, the above-described computer-readable storage medium may be ROM (Read-Only Memory), RAM (Random Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage device, etc.

[0199] In an exemplary embodiment, a computer program product is also provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the aforementioned subscription task processing method.

[0200] It should be noted that this application may display prompt interfaces, pop-ups, or output voice prompts before and during the collection of user data. These prompt interfaces, pop-ups, or voice prompts are used to inform users that their data is being collected. This ensures that the application only begins the steps for collecting user data after receiving confirmation from the user regarding the prompt interface or pop-up; otherwise (i.e., without user confirmation), the steps for collecting user data end, meaning no user data is collected. In other words, all user data collected by this application is processed strictly in accordance with the requirements of relevant national laws and regulations. The informed consent or separate consent of the data subject is obtained only with the user's consent and authorization. Subsequent data use and processing are conducted within the scope of laws, regulations, and the data subject's authorization, and the collection, use, and processing of relevant user data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0201] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0202] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for processing subscription tasks, characterized in that, The method includes: Based on the query information of the subscription task, the query result of the subscription task is obtained. The subscription task is used to periodically obtain information about the subscription object. Based on the query results of the subscription task, determine the status of the subscription object; If the query information of the subscription task does not match the state of the subscription object, the query information of the subscription task is reconstructed to obtain the updated query information of the subscription task.

2. The method according to claim 1, characterized in that, Determining the status of the subscription object based on the query results of the subscription task includes: The query results of the subscription task are checked to see if they contain predefined status keywords, which are keywords related to the status changes of the subscription object. The status of the subscription object is determined based on the status keywords contained in the query results of the subscription task.

3. The method according to claim 1 or 2, characterized in that, The process of reconstructing the query information of the subscription task to obtain the updated query information of the subscription task includes: Based on the state of the subscribed object, the query information of the subscription task is reconstructed to obtain the updated query information of the subscription task.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Refactoring suggestions are generated for a large language model (LLM), which guide the LLM to adjust the query information of the subscription task according to the state changes of the subscription object. The LLM generates a reconstruction result based on the reconstruction prompt information; wherein the reconstruction result includes first indication information, which indicates whether to reconstruct the query information of the subscription task, and when the first indication information indicates that the query information of the subscription task should be reconstructed, the reconstruction result also includes the updated query information of the subscription task.

5. The method according to claim 4, characterized in that, The reconstruction prompt information includes at least one of the following: The first role definition information is used to instruct the LLM to act as an optimization assistant for the subscription task and adjust the query information of the subscription task according to the status changes of the subscription object; The first input information is used to indicate the state change of the subscribed object; The first task requirement information is used to indicate the adjustment requirements for the query information of the subscribed task; The first output format information is used to indicate the information format of the reconstruction result.

6. The method according to claim 5, characterized in that, The first input information includes at least one of the following: The query information for the subscription task; The query results of the subscription task; The change summary of the subscription task is used to summarize the state changes of the subscription object; The status keywords for the subscription task.

7. The method according to any one of claims 4 to 6, characterized in that, After generating the reconstruction result through the LLM based on the reconstruction prompt information, the process further includes: Obtain the confidence level of the reconstruction result, which is used to indicate the credibility of the reconstruction result; If the confidence level is greater than or equal to the first threshold, the query information of the subscription task is updated to the updated query information of the subscription task. If the confidence level is less than the first threshold and greater than the second threshold, it is determined whether to update the query information of the subscription task to the updated query information of the subscription task based on the reconstruction selection of the subscription account. The subscription account is the user account that created the subscription task. If the confidence level is less than or equal to the second threshold, the update of the query information for the subscription task is cancelled.

8. The method according to any one of claims 1 to 6, characterized in that, The method further includes: If the status of the subscription task indicates that the life phase of the subscription object on the query dimension corresponding to the subscription task has ended, the step of reconstructing the query information of the subscription task and obtaining the updated query information of the subscription task is not executed.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: Determine the similarity between the query results of the subscription task and the historical query results of the subscription task; If the subscription task meets the reconstruction conditions, the step of reconstructing the query information of the subscription task to obtain the updated query information of the subscription task is performed; wherein, the reconstruction conditions include: the similarity is less than or equal to a third threshold; the query information of the subscription task does not match the state of the subscription object.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: Obtain the historical query results and historical query time of the subscribed task; Based on the query information of the subscription task, the historical query results and historical query time of the subscription task, and the query results and query time of the subscription task, semantic analysis is performed on the subscription task to obtain the semantic analysis result of the subscription task. The semantic analysis result includes second indication information, which is used to indicate whether to push the query results of the subscription task to the subscription account. When the second instruction information is used to instruct the subscription account to push the query results of the subscription task to the subscription account, the query results of the subscription task are pushed to the subscription account.

11. The method according to claim 10, characterized in that, The step of performing semantic analysis on the subscription task based on the query information of the subscription task, the historical query results and historical query time of the subscription task, and the query results and query time of the subscription task, to obtain the semantic analysis result of the subscription task, includes: The LLM generates analysis prompts, which guide the LLM to analyze changes in the information of the subscribed object based on the query results of the subscription task. The LLM generates a semantic analysis result for the subscription task based on the analysis prompts. The semantic analysis result also includes a change summary of the subscription task, which is used to summarize the state changes of the subscription object.

12. The method according to claim 11, characterized in that, The analysis prompt information includes at least one of the following: The second role definition information is used to instruct the LLM to act as an optimization assistant for the subscription task and to determine whether to push the query results of the subscription task to the subscription account; The second input information is used to indicate changes in the information of the subscribed object; The second task requires information to determine whether changes in the information of the subscribed object meet the push requirements. The second output format information is used to indicate the information format of the semantic analysis result.

13. The method according to claim 11 or 12, characterized in that, The semantic analysis dimensions of the LLM include at least one of the following: The fact change dimension is used to analyze whether key information in the query results of the subscription task has changed; The timeliness impact dimension is used to analyze whether the information of the subscribed object changes over time. The information description dimension is used to analyze whether changes in the description of the information of the subscribed object result in semantic changes. The new information dimension is used to analyze whether new information appears in the information of the subscribed object.

14. The method according to any one of claims 1 to 13, characterized in that, Before obtaining the query results of the subscription task based on the query information of the subscription task, the method further includes: Based on the subscription rule corresponding to the subscription task, the metadata of the subscription rule corresponding to the subscription task is obtained, and the metadata of the subscription rule is used to indicate the execution status of the subscription task; Obtain the grouping information of the subscription task, which includes account information of at least one subscription account that created the subscription task; For the at least one subscription account, query information for the subscription task is generated based on the metadata of the subscription rules.

15. The method according to claim 14, characterized in that, The step of obtaining the grouping information of the subscription task includes: Get the subscription task list, which includes multiple subscription tasks. Each subscription task is created by a subscription account and is used to periodically obtain information about the subscribed object in the query dimension. Based on the subscription object and query dimension corresponding to the subscription task, the subscription task list is deduplicated to obtain a deduplicated subscription task list; Based on the subscription accounts corresponding to each subscription task in the deduplicated subscription task list, the grouping information of the subscription tasks is obtained.

16. The method according to claim 14 or 15, characterized in that, The metadata of the subscription rule includes at least one of the following: The identification information of the subscription rule; The account information of at least one subscription account corresponding to the subscription rule; The subscription object corresponding to the subscription rule; The query dimensions corresponding to the subscription rules; The query information corresponding to the subscription rules; The query frequency corresponding to the subscription rule; The creation time corresponding to the subscription rule; The update time corresponding to the subscription rule.

17. The method according to any one of claims 1 to 16, characterized in that, The step of obtaining the query results of the subscription task based on the query information of the subscription task includes: Based on the query information of the subscription task, the query data corresponding to the at least one query node is obtained sequentially from the at least one query node according to the priority order of the at least one query node; The LLM generates query results for the subscription task based on the query data corresponding to each of the at least one query node. The query results for the subscription task include at least one of the following modalities: text, image, chart, table, audio, and video.

18. The method according to claim 17, characterized in that, The method further includes: If the query process of the subscription task meets the retry conditions, the step of obtaining query data is re-executed from the previous query node before the current query node, according to the exponential backoff strategy. The exponential backoff strategy is used to indicate the threshold number of times the query step is re-executed and the time interval between each re-execution of the query step.

19. The method according to claim 18, characterized in that, The retry conditions include at least one of the following: The currently queried node was not connected during the first time period; No query data corresponding to the current query node was found from the current query node during the second time period; The LLM was not accessed during the third time period.

20. The method according to any one of claims 10 to 13, characterized in that, The method further includes: If the semantic analysis result of the subscription task is not obtained within the fourth time period, it is determined that the semantic analysis of the subscription task has failed. Obtain the hash value of the query result of the subscription task, and the historical hash value of the historical query result of the subscription task; If the semantic analysis of the subscription task fails and the hash value is different from the historical hash value, the query result of the subscription task will be pushed to the subscription account.

21. The method according to any one of claims 1 to 20, characterized in that, The processing of the subscription task is implemented by an intelligent agent; The intelligent agent obtains the query results of the subscribed task by invoking the first intelligent agent; The intelligent agent performs semantic analysis on the subscription task and reconstructs the query information of the subscription task by invoking the second intelligent agent; The intelligent agent pushes the query results of the subscription task to the subscription account by invoking a third intelligent agent.

22. A processing apparatus for subscription tasks, characterized in that, The device includes: The result acquisition module is used to acquire the query results of the subscription task based on the query information of the subscription task, wherein the subscription task is used to periodically acquire information information of the subscription object; The status determination module is used to determine the status of the subscription object based on the query results of the subscription task; The information reconstruction module is used to reconstruct the query information of the subscription task when the query information of the subscription task does not match the state of the subscription object, so as to obtain the updated query information of the subscription task.

23. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the subscription task processing method as described in any one of claims 1 to 21.

24. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the method for processing subscription tasks as described in any one of claims 1 to 21.

25. A computer program product, characterized in that, The computer program product includes a computer program that is loaded and executed by a processor to implement the method for processing subscription tasks as described in any one of claims 1 to 21.

Images