Information automatic generation method and device, storage medium and electronic equipment

Abstract

This application discloses an automatic information generation method, apparatus, storage medium, and electronic device. The automatic information generation method includes: responding to an information generation task request, generating a unique task identifier for the task request, and encapsulating the task request as a task object and storing it in an asynchronous task queue; scheduling the task object from the asynchronous task queue and determining multiple processing stages to be executed; executing information generation operations sequentially or in parallel based on the multiple processing stages to be executed, generating corresponding intermediate information in each processing stage and storing it in the metadata of the task object; receiving a re-execution request for a specified processing stage of a completed task, re-executing the specified processing stage, and updating the metadata using the regenerated information; and pushing the status information of the task object to the client in real time through server push events, thereby achieving flexible control, observability, and convenient integration of the information generation process, significantly improving the efficiency, quality, and throughput of automatic information generation.

Description

Technical Field

[0001] This application relates to the field of information processing technology, specifically to an automatic information generation method, apparatus, storage medium, and electronic device. Background Technology

[0002] With the rapid development of artificial intelligence technology, especially the widespread application of Large Language Models (LLMs), it has become possible to use AI technology to assist or replace human content creation. In fields such as news writing, marketing copy generation, and industry report writing, the demands for the quantity, timeliness, and diversity of content production are increasing. Traditional manual editing methods are insufficient to meet the needs of large-scale, high-frequency content creation; therefore, automated information generation systems have emerged.

[0003] Currently, the field of automated information generation mainly consists of three types of technical solutions: general workflow engines (such as Celery and Apache Airflow), CMS systems with integrated AI writing plugins (such as WordPress + AI plugin), and independent AI writing platforms or API services.

[0004] However, current solutions generally suffer from technical defects such as rigid processes (black box mode, unable to intervene in the intermediate process), unknown status (users cannot know the progress in real time), difficult integration (lack of standardized APIs and callback mechanisms), and limited processing capacity (difficult to support high-concurrency scenarios). Summary of the Invention

[0005] This application provides an automatic information generation method, apparatus, storage medium, and electronic device, which can solve the problems of rigid processes, unknown states, difficult integration, and limited processing capabilities in the prior art.

[0006] In a first aspect, embodiments of this application provide an automatic information generation method, including: In response to a task request generated by information generation, a unique task identifier is generated for the task request, and the task request is encapsulated as a task object and stored in an asynchronous task queue; The task object is scheduled from the asynchronous task queue, and multiple processing stages to be executed are determined based on the configuration information of the task object; Information generation operations are performed sequentially or in parallel based on multiple processing stages to be executed. Intermediate information is generated in each processing stage and stored in the metadata of the task object. Receive a re-execution request for a specified processing stage of a completed task, re-execute only the specified processing stage according to the re-execution request, and update the metadata using the regenerated information; The server pushes the status information of the task object to the client in real time through push events.

[0007] In the information automatic generation method provided in this application embodiment, the step of determining multiple processing stages to be executed based on the configuration information of the task object includes: Parse the mode parameters in the configuration information of the task object, and obtain the list of processing stage identifiers corresponding to the mode parameters and their dependencies from the predefined process template library; By using each processing stage in the processing stage identifier list as a node and the dependency relationship as a directed edge, a directed acyclic graph is constructed, and the multiple processing stages to be executed and their execution order are represented by the directed acyclic graph.

[0008] In the information automatic generation method provided in this application embodiment, the step of performing information generation operations sequentially or in parallel based on multiple processing stages to be executed includes: The directed acyclic graph is parsed to identify root processing stages that have no dependencies and execute them first. Once any processing stage is completed, the execution of subsequent processing stages that have satisfied all dependent conditions is triggered based on the directed edges in the directed acyclic graph, thereby achieving parallel processing of the processing stages.

[0009] In the information automatic generation method provided in this application embodiment, the step of re-executing only the specified processing stage according to the re-execution request and updating the metadata using the regenerated information includes: In response to the re-execution request, locate the target node corresponding to the specified processing stage in the directed acyclic graph; Perform forward reachability analysis on the target node, traverse the directed acyclic graph to identify the downstream processing stages corresponding to all downstream nodes that directly or indirectly depend on the output of the target node; Based on the linkage strategy in the configuration information, determine whether to re-execute the identified downstream processing stage and the specified processing stage together; The metadata is updated based on the judgment result.

[0010] In the information automatic generation method provided in this application embodiment, updating the metadata based on the judgment result includes: If it is determined that all processes must be re-executed, then the downstream processing stages will be re-executed sequentially according to the topological order of the downstream nodes in the directed acyclic graph, and the regenerated stage information will be updated to the metadata. If it is determined that the downstream processing stage will not be re-executed, then only the specified processing stage will be re-executed, and the regenerated information will overwrite the corresponding old information in the metadata.

[0011] In the information automatic generation method provided in this application embodiment, the step of pushing the status information of the task object to the client in real time through server push events includes: In response to a server push event connection request initiated by the client, a long connection is established with the client, and the connection protocol is upgraded to the server push event protocol; The server maintains an event sending queue for pushing events, and uses a sliding window rate limiting algorithm to control the event pushing frequency. The sliding window rate limiting algorithm dynamically adjusts the timing of the current event push based on the number of events already pushed within the time window. When the rate at which the status information of the task object is generated exceeds a preset threshold, multiple processing stage update events are merged into one aggregate event, and only the aggregate event containing complete details of the task object is pushed to the client. The system periodically sends heartbeat events to the client to maintain the long connection, and determines whether the long connection is alive by monitoring the client's transmission control protocol. When the long connection is detected to be disconnected, the system resources occupied by the server push event connection are released.

[0012] The information automatic generation method provided in this application embodiment also includes: When responding to a task request for information generation, receive callback configuration information; When the task object finishes execution, a callback request is initiated to the specified Uniform Resource Locator according to the callback configuration information, and the execution result of the task object is passed as a parameter.

[0013] Secondly, embodiments of this application provide an automatic information generation device, comprising: An encapsulation unit is used to respond to a task request generated by information generation, generate a unique task identifier for the task request, and encapsulate the task request into a task object and store it in an asynchronous task queue. The scheduling unit is used to schedule the task object from the asynchronous task queue and determine multiple processing stages to be executed based on the configuration information of the task object; An execution unit is used to perform information generation operations sequentially or in parallel based on multiple processing stages to be executed, generating corresponding intermediate information in each processing stage and storing it in the metadata of the task object; An update unit is configured to receive a re-execution request for a specified processing stage of a completed task, re-execute only the specified processing stage according to the re-execution request, and update the metadata using the regenerated information; The push unit is used to push the status information of the task object to the client in real time through server push events.

[0014] Thirdly, this application provides a storage medium storing a plurality of instructions adapted for loading by a processor to execute the information automatic generation method described in any of the preceding claims.

[0015] Fourthly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the information automatic generation method described in any of the preceding claims.

[0016] In summary, the automatic information generation method provided in this application includes: responding to a task request for information generation, generating a unique task identifier for the task request, and encapsulating the task request into a task object and storing it in an asynchronous task queue; scheduling the task object from the asynchronous task queue, and determining multiple processing stages to be executed based on the configuration information of the task object; executing information generation operations sequentially or in parallel based on the multiple processing stages to be executed, generating corresponding intermediate information in each processing stage and storing it in the metadata of the task object; receiving a re-execution request for a specified processing stage of a completed task, re-executing only the specified processing stage according to the re-execution request, and updating the metadata using the regenerated information; and pushing the status information of the task object to the client in real time through a server push event. This application embodiment decouples the information generation task by using an asynchronous task queue, decomposing the complex information generation process into multiple independently executable modular processing stages, and introducing a stage replay mechanism to achieve local fine-tuning of the generation results. At the same time, it provides real-time task status monitoring by combining server push events, thereby achieving flexible control of the information generation process, full transparency and observability of the process, and convenient integration with external systems, significantly improving the efficiency, quality and throughput of automatic information generation. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram illustrating an application scenario of the information automatic generation method provided in the embodiments of this application.

[0019] Figure 2 This is a flowchart illustrating the information automatic generation method provided in the embodiments of this application.

[0020] Figure 3This is a schematic diagram of the structure of the information automatic generation device provided in the embodiments of this application.

[0021] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0022] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0023] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0024] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0025] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0026] In the description of this application, it should be noted that the terms "upper," "lower," "left," "right," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. In addition, terms such as "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0027] Current automated information generation solutions generally suffer from technical defects such as rigid processes (black box mode, unable to intervene in intermediate processes), unknown status (users cannot know the progress in real time), difficulty in integration (lack of standardized APIs and callback mechanisms), and limited processing capacity (difficult to support high-concurrency scenarios).

[0028] Based on this, embodiments of this application provide an automatic information generation method, apparatus, storage medium, and electronic device. Specifically, the automatic information generation apparatus can be integrated into an electronic device, which can be a server or a terminal, etc. The terminal can include mobile phones, wearable smart devices, tablets, laptops, and personal computers (PCs) and other computers and auxiliary devices. The server can be a single server or a server cluster composed of multiple servers, and can be a physical server or a virtual server.

[0029] For example, such as Figure 1 As shown, the electronic device can respond to a task request for information generation by generating a unique task identifier for the task request and encapsulating the task request into a task object and storing it in an asynchronous task queue; scheduling the task object from the asynchronous task queue and determining multiple processing stages to be executed based on the configuration information of the task object; executing the information generation operation sequentially or in parallel based on the multiple processing stages to be executed, generating corresponding intermediate information in each processing stage and storing it in the metadata of the task object; receiving a re-execution request for a specified processing stage of a completed task, re-executing only the specified processing stage according to the re-execution request, and updating the metadata using the regenerated information; and pushing the status information of the task object to the client in real time through server push events.

[0030] The technical solutions shown in this application will be described in detail below through specific embodiments. It should be noted that the order of description of the following embodiments is not intended to limit the priority of the embodiments.

[0031] Please see Figure 2 , Figure 2 This is a flowchart illustrating the information automatic generation method provided in an embodiment of this application. The specific flow of this information automatic generation method can be as follows: 101. In response to the task request generated by the information, generate a unique task identifier for the task request and encapsulate the task request as a task object and store it in the asynchronous task queue.

[0032] In this embodiment, when a user or external electronic device needs to generate content (i.e., information), it first initiates an information generation task request to the electronic device provided in this application embodiment. This task request can be submitted through the application programming interface (API) provided by the electronic device, for example, through a POST request using the Hypertext Transfer Protocol (HTTP).

[0033] Specifically, the task request carries all the raw materials and instructions needed to generate content, including but not limited to: original text, reference materials, and configuration parameters. The configuration parameters may include a mode parameter (mode) to specify the task's processing flow type, such as fully automated publishing mode (slimwrite) or manual review mode (phainowrite); a large language model parameter (llm_model) to specify which AI model to use for content generation; and callback configuration information to specify the notification address upon task completion.

[0034] Upon receiving a task request, the electronic device generates a globally unique task identifier. This task identifier can be in the form of a Universally Unique Identifier (UUID) to ensure that it is not repeated throughout the entire electronic device. Subsequently, the electronic device encapsulates the task request into a task object, which contains information such as the task identifier, input data, configuration parameters, creation time, and current status (initialized to "pending processing"). After encapsulation, the electronic device stores the task object in an asynchronous task queue, awaiting subsequent scheduling and processing.

[0035] Asynchronous task queues can be implemented using message queue middleware, such as RabbitMQ, Apache Kafka, or Redis. After storing a task object in the asynchronous task queue, the electronic device immediately returns a storage success response to the client, which includes the generated task identifier. In this way, the client does not need to block and wait for the actual processing result of the task, achieving decoupling between task request submission and task execution, and effectively handling high-concurrency scenarios.

[0036] In some embodiments, to prevent duplicate task requests, the electronic device can also perform deduplication verification on the task requests. Specifically, the electronic device generates a hash value (e.g., using the SHA-256 algorithm) based on the input content of the task request and generates a deduplication key in combination with configuration parameters. A Bloom filter is used to quickly predict the deduplication key. If a stored task object with the same deduplication key exists within a preset time window, the task identifier of the stored task object is directly returned, and the task is not created again.

[0037] 102. Schedule task objects from the asynchronous task queue and determine multiple processing stages to be executed based on the configuration information of the task objects.

[0038] When electronic device resources are idle, the scheduler retrieves task objects from the asynchronous task queue and begins the actual content generation process. In some embodiments, the mode parameters in the configuration information of the task object can be parsed, and a list of processing stage identifiers corresponding to the mode parameters and their dependencies can be obtained from a predefined process template library. Each processing stage in the list of processing stage identifiers is used as a node, and the dependencies are used as directed edges to construct a directed acyclic graph, which represents multiple processing stages to be executed and their execution order.

[0039] Specifically, the electronic device can parse the configuration information of the task object and extract the mode parameter. This mode parameter indicates which preset process template should be used for this task. The electronic device retrieves a list of processing stage identifiers corresponding to this mode parameter and their dependencies from a predefined process template library. The process template library stores preset combinations of processing stages for different business scenarios, such as the combination of "body text generation - title generation - tag generation - abstract generation - cover image generation", as well as the sequential dependencies between each stage.

[0040] After obtaining the list of processing stage identifiers and their dependencies, the electronic device constructs a Directed Acyclic Graph (DAG) by treating each processing stage in the list as a node and the dependencies as directed edges. This DAG represents multiple processing stages to be executed and their execution order. In the DAG, each node represents an independent processing stage, such as the news content generation stage (news_content), the news title generation stage (news_title), the tag extraction stage (tag_name), the summary generation stage (intro), and the cover image generation stage (cover). Directed edges represent the dependencies between stages; for example, the news title generation stage depends on the output of the news content generation stage, so it points from the news_content node to the news_title node.

[0041] By constructing a directed acyclic graph, electronic devices can clearly identify the dependencies between processing stages, providing a foundation for subsequent parallel execution and stage replay.

[0042] 103. Based on multiple pending processing stages, information generation operations are executed sequentially or in parallel, generating corresponding intermediate information in each processing stage and storing it in the metadata of the task object.

[0043] After identifying the multiple processing stages to be executed and their dependencies, the electronic device begins to perform the information generation operation.

[0044] Specifically, first, the directed acyclic graph is parsed to identify root processing stages that have no dependencies and execute them first. These root processing stages are those without predecessor nodes, meaning they can be executed without relying on any other processing stages. The electronic device will prioritize executing these root processing stages.

[0045] For example, in a directed acyclic graph, the "text generation" stage typically does not depend on other processing stages and is considered the root processing stage. The electronic device invokes the text generation module, which reads the input data from the task object and uses a pre-defined large-scale language model to generate the text content. The generated text content is stored as intermediate information in the task object's metadata.

[0046] Then, once any processing stage has been completed, the subsequent processing stages that have satisfied all dependent conditions are triggered based on the directed edges in the directed acyclic graph, so as to achieve parallel processing of the processing stages.

[0047] Specifically, after any processing stage is completed, the electronic device checks all subsequent processing stages based on the directed edges in the directed acyclic graph. For a given subsequent processing stage, if all its dependent preceding processing stages have been completed, then all its dependency conditions are met, and the electronic device immediately triggers the execution of that subsequent processing stage. This process continues, executing all processing stages step by step until all processing stages are completed.

[0048] By using this dependency-driven approach, electronic devices can automatically identify and execute all processing stages where dependencies are met, enabling parallel processing of processing stages. For example, after the main text is generated, both "title generation" and "abstract generation" may depend on the main text, but there is no mutual dependency between them. In this case, the electronic device can execute these two processing stages in parallel, thereby improving processing efficiency.

[0049] During execution, intermediate information generated at each processing stage (such as generated title text, tag list, summary text, etc.) is recorded in the task object's metadata. Simultaneously, the electronic device updates the overall schedule and status of the task object, for example, updating the progress from 0% to 25%, 50%, etc., so that subsequent server-pushed events can provide real-time feedback to the client.

[0050] In some embodiments, the electronic device also dynamically adjusts the estimated execution time of each processing stage based on historical execution data of that stage using an Exponentially Weighted Moving Average (EWMA) algorithm. When the actual execution time exceeds a preset multiple threshold of the estimated execution time, the electronic device triggers a timeout interrupt operation to prevent a single processing stage from blocking the execution of the entire task.

[0051] 104. Receive a re-execution request for a specified processing stage of a completed task, re-execute only the specified processing stage according to the re-execution request, and update the metadata with the regenerated information.

[0052] In practical applications, users may be dissatisfied with the results generated at a certain processing stage, for example, believing that the generated title is not appropriate and wanting to regenerate it. The traditional approach is to re-execute the entire task, wasting time and computing resources. The stage replay mechanism provided in this embodiment allows users to re-execute only a specified processing stage. Specifically, it can be as follows: First, in response to the re-execution request, locate the target node in the directed acyclic graph corresponding to the specified processing stage.

[0053] Specifically, users can initiate a re-execution request by calling the stage replay interface provided by the electronic device (e.g., POST / replay / {task_id}). This re-execution request carries the task identifier and the identifier of the specified processing stage to be re-executed, such as specifying the re-execution of the "news title generation" stage. Upon receiving the re-execution request, the electronic device first locates the corresponding task object based on the task identifier and obtains the directed acyclic graph (DAG) of that task object. Then, the electronic device locates the target node corresponding to the specified processing stage within the DAG.

[0054] Next, the electronic device performs forward reachability analysis on the target node, traversing the directed acyclic graph to identify the downstream processing stages corresponding to all downstream nodes that directly or indirectly depend on the output of the target node.

[0055] Forward reachability analysis refers to traversing the directed acyclic graph (DAG) from the target node along the directed edges to identify all downstream nodes that directly or indirectly depend on the output of the target node. The processing stages corresponding to these downstream nodes are called downstream processing stages. For example, if the user specifies to re-execute the "body text generation" stage, then stages such as "title generation," "abstract generation," and "tag generation," which depend on the body text, will all be identified as downstream processing stages.

[0056] Then, the electronic device determines, based on the linkage strategy in the configuration information, whether to re-execute the identified downstream processing stage along with the specified processing stage.

[0057] It should be noted that the linkage strategy can be preset or specified by the user in the re-execution request. Common linkage strategies include: re-execute only the specified processing stage (no linkage), re-execute the specified processing stage and all its downstream processing stages (full linkage), and re-execute the specified processing stage and its direct downstream processing stages (first-level linkage), etc.

[0058] Finally, the metadata is updated based on the judgment results.

[0059] Specifically, if it is determined that all processes should be re-executed, the downstream processing stages will be re-executed sequentially according to the topological order of the downstream nodes in the directed acyclic graph, and the regenerated stage information will be updated to the metadata. The topological order ensures that the predecessor processing stage that each processing stage depends on has been completed when it is executed.

[0060] If it is determined that downstream processing stages will not be re-executed, only the specified processing stage will be re-executed, and the newly generated information will overwrite the corresponding old information in the metadata. At this time, since the results of the downstream processing stages may depend on the overwritten old data, the electronic device will mark the status of the task object as "data inconsistency" or "requires review," reminding the user that the results of the downstream processing stages may not match the new data.

[0061] Through the aforementioned stage replay mechanism, users can make partial and refined adjustments and optimizations to the content generation results without having to rerun the entire task, significantly improving the flexibility and efficiency of content production.

[0062] In some embodiments, to prevent data corruption caused by concurrent replay, the electronic device employs an optimistic locking mechanism. Specifically, each task object's metadata includes a version number. The re-execution request carries the current version number of the task object's metadata. The electronic device only performs a re-execution operation and updates the version number if the current version number matches the version number stored in the database. If the version numbers do not match, it indicates that the task object has been modified by other operations during this period; the electronic device rejects the re-execution request and prompts the user to refresh and try again.

[0063] 105. Push the status information of the task object to the client in real time through server push events.

[0064] To enable users to understand the processing progress and status changes of task objects in real time, this embodiment uses Server-Sent Events (SSE) technology to push status information to the client in real time.

[0065] Specifically, a client can subscribe to the status updates of a specified task object by initiating a server push event connection request (e.g., GET / look / {task_id}). In response to the client's server push event connection request, the electronic device establishes a persistent connection with the client and upgrades the connection protocol to the server push event protocol.

[0066] Among them, the server push event protocol is a one-way push protocol based on the Hypertext Transfer Protocol, which allows the server to actively send data to the client.

[0067] After a long connection is established, the electronic device maintains the event sending queue for the server push event connection and uses a sliding window rate limiting algorithm to control the event push frequency. The sliding window rate limiting algorithm dynamically adjusts the push timing of the current event based on the number of events pushed within the time window to prevent client overload or network congestion caused by high-frequency push.

[0068] Throughout the lifecycle of a task object, the electronic device generates corresponding events based on changes in the task object's state, including but not limited to: wait events (indicating the task is in the queue), start events (indicating the task has started processing), update events (indicating the completion of a certain processing stage, carrying the latest complete details of the task object), finish events (indicating the task is fully completed), and cancel events (indicating the task has been canceled).

[0069] When the rate at which the status information of a task object is generated exceeds a preset threshold (for example, when multiple processing stages are completed consecutively in a short period of time), the electronic device merges the update events of multiple processing stages into an aggregate event and pushes only the aggregate event containing complete details of the task object to the client, thereby reducing the number of network transmissions and improving push efficiency.

[0070] In addition, electronic devices can periodically send heartbeat events to clients to maintain persistent connections. A heartbeat event is an empty event without business data, used to detect whether a persistent connection is alive. Electronic devices determine connection viability by monitoring the client's Transmission Control Protocol (TCP) status. When a persistent connection is detected to be broken, the electronic device proactively releases the resources occupied by the server-side push event connection, avoiding resource waste.

[0071] Through the aforementioned server push event mechanism, the client can receive real-time status updates of task objects, achieving a "live broadcast"-style content generation experience. Users can accurately grasp every step of the task's dynamics and promptly identify and respond to problems.

[0072] In this embodiment of the application, a callback mechanism is also provided to facilitate the integration of electronic devices with external applications.

[0073] Specifically, in step 101, in response to the task request for information generation, the electronic device simultaneously receives callback configuration information. This callback configuration information includes a callback Uniform Resource Locator (URL) and the field parameters to be returned.

[0074] When a task finishes execution, regardless of whether the task status is success, failure, or cancellation, the electronic device initiates a callback request to the specified Uniform Resource Locator (URL) based on the callback configuration information. The callback request can use the Hypertext Transfer Protocol (HTTP) GET or POST method, passing the task execution result as a parameter. For example, the electronic device can assemble the generated article content, task identifier, execution status, and other information into request parameters and send them to the receiving address configured for downstream electronic devices.

[0075] After receiving the callback request, downstream electronic devices can automatically trigger subsequent operations based on the transmitted results, such as automatically publishing the generated article to the website, storing it in the database, or sending a notification, thereby achieving a fully automated closed loop from content generation to content publishing.

[0076] In some embodiments, to improve callback reliability, the electronic device employs at-least-once delivery semantics. Specifically, the electronic device writes the callback task into a retry queue and uses an exponential backoff algorithm for retrying on failure. For example, after the first failure, it waits 1 second to retry, after the second failure, it waits 2 seconds to retry, after the third failure, it waits 4 seconds to retry, and so on, up to a maximum of 5 retries. Simultaneously, the electronic device adds a unique callback identifier to the Hypertext Transfer Protocol header of the callback request for idempotent processing by downstream electronic devices, preventing duplicate processing due to repeated callbacks. The electronic device records the response status of each retry; if the callback still fails after reaching the maximum number of retries, it writes the callback failure event to a dead-letter queue and triggers an alarm so that maintenance personnel can intervene promptly.

[0077] In some embodiments, the above-described automatic information generation method can also support batch task processing. Specifically, in response to a batch task request, the electronic device generates a unique task identifier for each subtask in the batch task request and encapsulates each subtask as a subtask object and stores it in an asynchronous task queue. For batch tasks, the electronic device can aggregate the execution results of each subtask object and send callback notifications uniformly or in batches according to a user-specified aggregation strategy. For example, the user can choose to send a unified callback after all subtasks are completed, or they can choose to send a callback once after each subtask is completed.

[0078] In summary, the automatic information generation method provided in this application includes: responding to a task request for information generation, generating a unique task identifier for the task request, and encapsulating the task request into a task object and storing it in an asynchronous task queue; scheduling the task object from the asynchronous task queue, and determining multiple processing stages to be executed based on the configuration information of the task object; executing information generation operations sequentially or in parallel based on the multiple processing stages to be executed, generating corresponding intermediate information in each processing stage and storing it in the metadata of the task object; receiving a re-execution request for a specified processing stage of a completed task, re-executing only the specified processing stage according to the re-execution request, and updating the metadata using the regenerated information; and pushing the status information of the task object to the client in real time through a server push event. This application decouples the information generation task by using an asynchronous task queue, decomposing the complex information generation process into multiple independently executable modular processing stages, and introducing a stage replay mechanism to achieve local fine-tuning of the generation results. Simultaneously, it provides real-time task status monitoring in conjunction with server push events, thereby achieving flexible control of the information generation process, full-process transparency and observability, and convenient integration with external systems, significantly improving the efficiency, quality, and throughput of automatic information generation.

[0079] To facilitate better implementation of the information automatic generation method provided in the embodiments of this application, the embodiments of this application also provide an information automatic generation apparatus. The meanings of the terms used are the same as in the above-described information automatic generation method, and specific implementation details can be found in the descriptions in the method embodiments.

[0080] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of the information automatic generation device provided in an embodiment of this application. The information automatic generation device may include an encapsulation unit 201, a scheduling unit 202, an execution unit 203, an update unit 204, and a push unit 205. Encapsulation unit 201 is used to respond to the task request generated by information generation, generate a unique task identifier for the task request, and encapsulate the task request as a task object and store it in the asynchronous task queue. The scheduling unit 202 is used to schedule task objects from the asynchronous task queue and determine multiple processing stages to be executed based on the configuration information of the task objects; The execution unit 203 is used to execute information generation operations sequentially or in parallel based on multiple processing stages to be executed, and to generate corresponding intermediate information in each processing stage and store it in the metadata of the task object. The update unit 204 is used to receive a re-execution request for a specified processing stage of a completed task, re-execute only the specified processing stage according to the re-execution request, and update the metadata using the regenerated information. The push unit 205 is used to push the status information of the task object to the client in real time through server push events.

[0081] For specific implementation methods of each of the above units, please refer to the embodiments of the above-mentioned automatic information generation method, which will not be repeated here.

[0082] In summary, the information automatic generation device provided in this application embodiment can, in response to the information generation task request, generate a unique task identifier for the task request through the encapsulation unit 201, and encapsulate the task request into a task object and store it in the asynchronous task queue; the scheduling unit 202 schedules the task object from the asynchronous task queue and determines multiple processing stages to be executed based on the configuration information of the task object; the execution unit 203 executes the information generation operation sequentially or in parallel based on the multiple processing stages to be executed, generates corresponding intermediate information in each processing stage and stores it in the metadata of the task object; the update unit 204 receives a re-execution request for a specified processing stage of a completed task, re-executes only the specified processing stage according to the re-execution request, and updates the metadata using the regenerated information; and the push unit 205 pushes the status information of the task object to the client in real time through server push events. This application embodiment decouples the information generation task by using an asynchronous task queue, decomposing the complex information generation process into multiple independently executable modular processing stages, and introducing a stage replay mechanism to achieve local fine-tuning of the generation results. At the same time, it provides real-time task status monitoring by combining server push events, thereby achieving flexible control of the information generation process, full transparency and observability of the process, and convenient integration with external systems, significantly improving the efficiency, quality and throughput of automatic information generation.

[0083] This application also provides an electronic device that may integrate the information automatic generation device of this application, such as... Figure 4 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 301 with one or more processing cores and a memory 302 with one or more computer-readable storage media. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 301 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs stored in the memory 302 and / or the information automatic generation method of this application, and by calling data stored in the memory 302, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Optionally, the processor 301 may include one or more processing cores; preferably, the processor 301 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operation of the storage medium, user interface, and application programs, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 301.

[0084] The memory 302 can be used to store software programs and the automatic information generation method of this application. The processor 301 executes various functional applications and data processing by running the software programs stored in the memory 302 and the automatic information generation method of this application. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store applications required for operating the storage medium and at least one function; the data storage area may store data created according to the use of the electronic device. In addition, the memory 302 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 302 may also include a memory controller to provide the processor 301 with access to the memory 302.

[0085] Although not shown, the electronic device may also include a display unit, an input unit, and a power supply, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 301 in the electronic device loads the executable files corresponding to the processes of one or more application programs into the memory 302 according to the following instructions, and the processor 301 runs the application programs stored in the memory 302 to realize various functions, as follows: In response to the task request generated by the information, a unique task identifier is generated for the task request, and the task request is encapsulated as a task object and stored in the asynchronous task queue; Schedule task objects from the asynchronous task queue and determine multiple processing stages to be executed based on the configuration information of the task objects; Information generation operations are performed sequentially or in parallel based on multiple processing stages to be executed. Intermediate information is generated in each processing stage and stored in the metadata of the task object. Receive a re-execution request for a specified processing stage of a completed task, re-execute only the specified processing stage according to the re-execution request, and update the metadata with the regenerated information; The server pushes event information to the client in real time, providing status information of the task object.

[0086] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0087] Therefore, embodiments of this application provide a storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the methods provided in embodiments of this application. For example, the instructions can execute the following steps: In response to the task request generated by the information, a unique task identifier is generated for the task request, and the task request is encapsulated as a task object and stored in the asynchronous task queue; Schedule task objects from the asynchronous task queue and determine multiple processing stages to be executed based on the configuration information of the task objects; Information generation operations are performed sequentially or in parallel based on multiple processing stages to be executed. Intermediate information is generated in each processing stage and stored in the metadata of the task object. Receive a re-execution request for a specified processing stage of a completed task, re-execute only the specified processing stage according to the re-execution request, and update the metadata with the regenerated information; The server pushes event information to the client in real time, providing status information of the task object.

[0088] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0089] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0090] Since the instructions stored in the storage medium can execute the steps of any method provided in the embodiments of this application, the beneficial effects that any method provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0091] The above provides a detailed description of the information automatic generation method, apparatus, storage medium, and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for automatically generating information, characterized in that, include: In response to a task request generated by information generation, a unique task identifier is generated for the task request, and the task request is encapsulated as a task object and stored in an asynchronous task queue; The task object is scheduled from the asynchronous task queue, and multiple processing stages to be executed are determined based on the configuration information of the task object; Information generation operations are performed sequentially or in parallel based on multiple processing stages to be executed. Intermediate information is generated in each processing stage and stored in the metadata of the task object. Receive a re-execution request for a specified processing stage of a completed task, re-execute only the specified processing stage according to the re-execution request, and update the metadata using the regenerated information; The server pushes the status information of the task object to the client in real time through push events.

2. The information automatic generation method as described in claim 1, characterized in that, The step of determining multiple processing stages to be executed based on the configuration information of the task object includes: Parse the mode parameters in the configuration information of the task object, and obtain the list of processing stage identifiers corresponding to the mode parameters and their dependencies from the predefined process template library; By using each processing stage in the processing stage identifier list as a node and the dependency relationship as a directed edge, a directed acyclic graph is constructed, and the multiple processing stages to be executed and their execution order are represented by the directed acyclic graph.

3. The information automatic generation method as described in claim 2, characterized in that, The information generation operation, which is executed sequentially or in parallel based on multiple pending processing stages, includes: The directed acyclic graph is parsed to identify root processing stages that have no dependencies and execute them first. Once any processing stage is completed, the execution of subsequent processing stages that have satisfied all dependent conditions is triggered based on the directed edges in the directed acyclic graph, thereby achieving parallel processing of the processing stages.

4. The information automatic generation method as described in claim 2, characterized in that, The step of re-executing only the specified processing stage according to the re-execution request and updating the metadata using the regenerated information includes: In response to the re-execution request, locate the target node corresponding to the specified processing stage in the directed acyclic graph; Perform forward reachability analysis on the target node, traverse the directed acyclic graph to identify the downstream processing stages corresponding to all downstream nodes that directly or indirectly depend on the output of the target node; Based on the linkage strategy in the configuration information, determine whether to re-execute the identified downstream processing stage and the specified processing stage together; The metadata is updated based on the judgment result.

5. The information automatic generation method as described in claim 4, characterized in that, The step of updating the metadata based on the judgment result includes: If it is determined that all processes must be re-executed, then the downstream processing stages will be re-executed sequentially according to the topological order of the downstream nodes in the directed acyclic graph, and the regenerated stage information will be updated to the metadata. If it is determined that the downstream processing stage will not be re-executed, then only the specified processing stage will be re-executed, and the regenerated information will overwrite the corresponding old information in the metadata.

6. The information automatic generation method as described in claim 1, characterized in that, The step of pushing the status information of the task object to the client in real time via server push events includes: In response to a server push event connection request initiated by the client, a long connection is established with the client, and the connection protocol is upgraded to the server push event protocol; The server maintains an event sending queue for pushing events, and uses a sliding window rate limiting algorithm to control the event pushing frequency. The sliding window rate limiting algorithm dynamically adjusts the timing of the current event push based on the number of events already pushed within the time window. When the rate at which the status information of the task object is generated exceeds a preset threshold, multiple processing stage update events are merged into one aggregate event, and only the aggregate event containing complete details of the task object is pushed to the client. The system periodically sends heartbeat events to the client to maintain the long connection, and determines whether the long connection is alive by monitoring the client's transmission control protocol. When the long connection is detected to be disconnected, the system resources occupied by the server push event connection are released.

7. The information automatic generation method as described in claim 1, characterized in that, Also includes: When responding to a task request for information generation, receive callback configuration information; When the task object finishes execution, a callback request is initiated to the specified Uniform Resource Locator according to the callback configuration information, and the execution result of the task object is passed as a parameter.

8. An automatic information generation device, characterized in that, include: An encapsulation unit is used to respond to a task request generated by information generation, generate a unique task identifier for the task request, and encapsulate the task request into a task object and store it in an asynchronous task queue. The scheduling unit is used to schedule the task object from the asynchronous task queue and determine multiple processing stages to be executed based on the configuration information of the task object; An execution unit is used to perform information generation operations sequentially or in parallel based on multiple processing stages to be executed, generating corresponding intermediate information in each processing stage and storing it in the metadata of the task object; An update unit is configured to receive a re-execution request for a specified processing stage of a completed task, re-execute only the specified processing stage according to the re-execution request, and update the metadata using the regenerated information; The push unit is used to push the status information of the task object to the client in real time through server push events.

9. A storage medium, characterized in that, The storage medium stores multiple instructions, which are adapted for loading by a processor to execute the information automatic generation method according to any one of claims 1-7.

10. An electronic device, characterized in that, The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the automatic information generation method as described in any one of claims 1-7.

Images