Timing security report generation method and apparatus, device, and storage medium

Abstract

The application relates to the technical field of security analysis, and discloses a time sequence security report generation method, device, equipment and storage medium, which comprises the following steps: in response to a report request input by a user, determining a report date and a business statistical window based on the user input question and the original report date of the report request; determining a corresponding tool family according to a template identifier in the report request, and calling a parameter injection isolation directory for each tool in the tool family to obtain tool parameters; backfilling a date placeholder of historical successful call experience according to the report date to obtain template historical experience after the report date; determining a prompt context according to the template historical experience, the user input question, the report date, the business statistical window and the tool parameters; inputting the prompt context into a large language model as a message queue to output a main report. By avoiding replacing all security analysis logic with a large language model, the stability and reproducibility of report generation are improved.

Description

Technical Field

[0001] This application relates to the field of security analysis technology, and in particular to a method, apparatus, device and storage medium for generating time-series security reports. Background Technology

[0002] Existing large language models, when assisting in the generation of time-series security reports (such as daily and weekly security reports), often rely on fixed template scripts or free tool calls. On the one hand, statistical windows for different templates and dates are easily confused, making it difficult to unify time standards; on the other hand, the model lacks reference to historical successful paths during multiple rounds of tool calls, which can easily lead to call drift or duplicate errors, and caching and results between different templates may interfere with each other. These problems result in poor report generation stability and low reproducibility, making it difficult to meet the stringent requirements of production environments for security reports that are "time-consistent, template-isolated, and process-controllable." Summary of the Invention

[0003] The main objective of this application is to provide a method, apparatus, device, and storage medium for generating time-series security reports. The aim is to solve the technical problem of how to achieve unified determination of time caliber, explicit isolation of template boundaries, and effective transfer of historical successful experience in the process of generating time-series security reports from large language models, thereby improving the stability and controllability of report generation.

[0004] To achieve the above objectives, this application proposes a method for generating a timing security report, the method comprising: In response to a user-inputted report request, the report date and business statistics window are determined based on the user-inputted question and the original report date. The corresponding tool family is determined based on the template identifier in the report request, and an isolation directory is injected into the tool call parameters of each tool family to obtain the tool parameters; Based on the report date, the date placeholders for the historical successfully invoked experience are filled in to obtain the template historical experience after the current report date; The prompt context is determined based on the template's historical experience, the user's input question, the report date, the business statistics window, and the tool parameters; The prompt context is input into the large language model as a message queue, and the main report is output.

[0005] Optionally, the step of inputting the prompt context as a message queue into the large language model and outputting a main report includes: The message queue for the current round is determined based on the context of the prompt, and the message queue is input into the large language model to obtain the model output for the current round. The model output includes natural language content and a set of tool calls. When the number of tools in the tool call set is not empty, the execution result is determined based on the consecutive repeated call count of the current round; The execution result is injected into the message queue of the next round, and the step of inputting the message queue into the large language model is returned until the number of tools in the tool call set is empty, and the natural language content is used as the main report corresponding to the report request.

[0006] Optionally, determining the execution result based on the consecutive repeated call count of the current round includes: The tool call set is normalized to generate the call fingerprint for the current round; The call fingerprint of the current round is compared with the call fingerprint of the previous round, and the consecutive repeated call count is updated according to the comparison result; If the consecutive repeated call count is less than or equal to a preset threshold, then the tool in the tool call set is executed to obtain the execution result; If the number of consecutive repeated calls exceeds the preset threshold, a strong constraint hint is generated and used as the execution result of the current round. The strong constraint hint is used to prompt the large language model to stop repeated calls.

[0007] Optionally, after inputting the prompt context as a message queue into the large language model and outputting the main report, the method further includes: Based on the main filtering rules, a set of key objects is selected from the business statistics window; Generate an object-level summary for each object in the set of key objects, and output the key object summary text corresponding to the object-level summary based on the summary generation module; The summary text of the key objects is rendered based on the key analysis template, and the rendering result is added to the main report to obtain a complete time-series security report.

[0008] Optionally, the step of filtering the set of key objects from the business statistics window based on the main filtering rules includes: The first set of key objects is selected from the business statistics window based on the main filtering rules; If the number of objects in the first set of key objects is less than the preset upper limit, a backup query is triggered to obtain the second set of key objects. A set of key objects is generated based on the first set of key objects and the second set of key objects.

[0009] Optionally, after rendering the summary text of the key objects based on the key analysis template and adding the rendering result to the main report to obtain a complete time-series security report, the process further includes: Determine whether the complete timing security report contains a mandatory save flag; If the forced save flag does not exist, then determine whether the current system date is later than the report date, or whether the system date is equal to the report date and the system time has reached the business cutoff point; When the current system date is later than the report date, or when the system date is equal to the report date and the system time reaches the business deadline, the log information corresponding to the complete time-series security report is recorded, and the historical successful call experience is updated according to the tool call sequence corresponding to the complete time-series security report.

[0010] Optionally, determining the report date and business statistics window based on the user input question and the original report date of the report request includes: The report date is determined based on the user input question and the original report date in the report request. A business statistics window is constructed based on the business cutoff time of the report request and the report date. The business statistics window is a left-closed and right-open interval from the business cutoff time of the day before the report date to the business cutoff time of the report date.

[0011] Furthermore, to achieve the above objectives, this application also proposes a timing security report generation apparatus, which includes: The date determination module is used to respond to a user-inputted report request and determine the report date and business statistics window based on the user-inputted question and the original report date in the report request; The tool determination module is used to determine the corresponding tool family based on the template identifier in the report request, and inject an isolation directory into the tool call parameters of each tool family to obtain the tool parameters; The date backfilling module is used to backfill the date placeholders of historical successfully called experiences according to the report date, so as to obtain the template historical experience after the current report date; The context determination module is used to determine the prompt context based on the template's historical experience, the user's input question, the report date, the business statistics window, and the tool parameters; The model output module is used to input the prompt context as a message queue into the large language model and output the main report.

[0012] In addition, to achieve the above objectives, this application also proposes a timing security report generation device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the timing security report generation method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the timing security report generation method described above.

[0014] This application can automatically determine a unified report date and business statistics window based on the report request, and inject an isolated directory for tool calls of different templates. At the same time, it backfills the date based on the current report date and the experience of successful calls in the past, and constructs a prompt context that includes the historical experience of the template, the time caliber and the execution boundary. This effectively avoids the unstable report generation problem caused by replacing all security analysis logic with a large language model, and improves the stability and reproducibility of time-series security report generation.

[0015] Specifically, this application first ensures that all subsequent tool calls and data statistics are executed within the same business time boundary by explicitly constructing a statistical window aligned with the business deadline. Second, by instantiating an independent isolated directory for each template and injecting tool call parameters, it blocks cache crosstalk and erroneous result reuse between different templates at the parameter level. Third, by backfilling date placeholders for historical successful call experiences, it migrates the verified and feasible call skeleton to the current request, reducing the risk of model call path drift. Ultimately, this makes the generation process of the time-series security report possess closed-loop stability characteristics of unified time caliber, clear template boundaries, controllable call paths, and auditable and reproducible results, enabling stable delivery of production-grade security reports while meeting business time constraints. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0018] Figure 1 This is a flowchart illustrating the first embodiment of the timing security report generation method of this application; Figure 2 This is a flowchart illustrating the second embodiment of the timing security report generation method of this application; Figure 3 This is a sub-flowchart of the repetition suppression method in this application; Figure 4 This is a flowchart illustrating the third embodiment of the timing security report generation method of this application; Figure 5 A simplified flowchart illustrating a method for generating time-series security reports; Figure 6 This is a schematic diagram of the module structure of the timing security report generation device according to an embodiment of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the timing security report generation method in this application embodiment.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

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

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] While existing research covers partial capabilities such as "template generation," "rule orchestration," "tool invocation," and "agent execution," it still lacks a stable control chain specifically for time-series safety reports. This chain should not only focus on whether the final text is generated, but also simultaneously control time-specific consistency, template execution boundaries, tool invocation convergence, zero-value scenario tolerance, key object completion, and the timing of formal report saving. This application proposes an improvement to fill this gap. Its focus is not on making the model write more like a report, but on how to achieve stable convergence of the model-tool closed loop under strongly constrained scenarios and ensure auditable reproducibility.

[0023] Furthermore, the purpose of this application is not to replace all security analysis logic with a large language model, but to use the large language model as the core of the "semantic-to-execution structure" mapping, making it responsible for understanding intent, supplementing steps, and associating context, while delegating the final execution to a constrained agent or tool. This can both utilize the semantic understanding and generalization capabilities of the large language model and avoid the illusion and instability problems that may arise when it directly generates the final conclusion.

[0024] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a computer, or an electronic device capable of performing the above functions. The following description uses a time-series security report generation system as an example to illustrate this embodiment and the subsequent embodiments.

[0025] Based on this, embodiments of this application provide a method for generating a timing security report, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the timing security report generation method of this application.

[0026] In this embodiment, the time-series security report generation method includes: Step S10: In response to the user's input report request, determine the report date and business statistics window based on the user's input question and the original report date in the report request.

[0027] It should be noted that a report request refers to an instruction submitted by a user to the time-series security report generation system to trigger a report generation task. It typically includes key information such as the user-input question, the original report date, the report type, and a template identifier. The user-input question can be a security analysis requirement described in natural language, such as "generate yesterday's daily security report" or "statistics on this week's alerts." The original report date is an optional parameter; if not provided by the user, it must be extracted from the question or identified through a model. In this embodiment, the time-series security report generation system can be deployed on a server in the security operations center or a cloud-based analysis platform, receiving report requests from security analyst terminals or automated scheduling modules.

[0028] It should be noted that in this embodiment, the model can refer to a large language model with structured output capabilities; the tool call set refers to all the tool requests to be executed generated by the model in a certain round; the key objects can be key IPs, key events, key assets, or other objects that need to be analyzed separately in the report.

[0029] Understandably, the system receives request parameters. Then, it first undergoes standardization processing. Among these processes, Enter the question for the user; This parameter represents the original report date carried in the request; it can be empty. For report type; This is a template identifier. If... If the template identifier is empty, the default value "daily" is set; if the template identifier is empty, the default template is set; if the template identifier is not in the template mapping table, execution is refused and a template error message is returned; after passing the above checks, the system generates the request_id corresponding to this request, which is used to guide subsequent log entries.

[0030] It should be understood that the technical significance of this stage is not merely to perform parameter validity checks, but more importantly, to explicitly establish template boundaries at the starting point of the execution chain. Unlike ordinary natural language question answering, the timing safety report's subsequent call paths, cache boundaries, key analysis logic, and even disk write paths are all strongly correlated with the template. If the template is not explicitly determined at the outset, ambiguity from upstream will propagate to subsequent stages, ultimately leading to cache crosstalk or the generation of error reports.

[0031] In the specific implementation process, the report date can be determined based on the user input question and the original report date in the report request. Then, a left-closed, right-open interval from the cutoff time of the day before the report date to the cutoff time of the report date is constructed based on the business cutoff time as a business statistics window. This overcomes the problem of inconsistency between the time caliber and business semantics caused by simply using the time from midnight to midnight of a calendar day as the statistics window in the existing technology. This ensures that the statistics window is strictly aligned with the business cutoff time, guaranteeing the uniformity of the time boundaries for all tool calls and data statistics under the same report date. At this time, step S10 may include: The report date is determined based on the user input question and the original report date in the report request. A business statistics window is constructed based on the business cutoff time of the report request and the report date. The business statistics window is a left-closed and right-open interval from the business cutoff time of the day before the report date to the business cutoff time of the report date.

[0032] It should be noted that the report date refers to a standard format date used to uniformly identify the business date to which the report belongs after normalization processing. The business cutoff time refers to the statistical cycle switching time agreed upon in the security operation business, such as 08:00 AM every day. Its physical meaning is that data before the cutoff time is included in the previous day's statistical window, and data after the cutoff time is included in the current day's statistical window. Unlike the statistical scope from midnight to midnight of a calendar day, this application uses the business cutoff time to construct the statistical window, which can be aligned with the scheduling, alarm aggregation, and daily report delivery time of security operations, avoiding statistical inconsistencies caused by disputes over the ownership of cross-day data.

[0033] Understandably, this phase addresses the most critical issue of consistency in time-series safety reports. The system employs a three-tiered strategy of "rule priority, model fallback, and current date rollback" to determine the report date.

[0034] First, if the original report date is explicitly given in the request parameters. If so, normalization should be performed first; if If empty, then start from the user question. The system extracts the date representation according to rules; if rule extraction fails, it calls the date extraction model for supplementary identification; if the model still does not return a valid result, it reverts to the current system date. This process can be represented as:

[0035] in This represents a date normalization function that outputs a report date in a standard format. .

[0036] Date of receiving the report Subsequently, the system does not directly use the period from midnight to midnight of a calendar day as the statistical window, but instead uses the business cutoff time. Construct a statistics window The window is defined as:

[0037] in, Indicates the business cutoff time on the day prior to the report date. This indicates the business cutoff point for the reporting date. A left-closed, right-open interval means that all statistical results should fall within this business window.

[0038] It should be noted that the above outputs have a uniform reporting date. and its corresponding business statistics window These two factors will be crucial for all subsequent tool calls and disk write decisions.

[0039] Step S20: Determine the corresponding tool family based on the template identifier in the report request, and inject an isolation directory into the tool call parameters of each tool family to obtain the tool parameters.

[0040] It should be noted that template identifiers are used to distinguish different types of security reports. Each template corresponds to a specific set of data query, statistical analysis, and report rendering tools. A tool family refers to the collection of all tools associated with a particular template used to complete the report generation task (such as database query tools, statistical calculation tools, log retrieval tools, cache reading tools, file writing tools, etc.). An isolation directory is an independent storage path instantiated for the current report request and bound to the template identifier. Its function is to isolate cache reading and result writing operations between different templates, preventing cache crosstalk and erroneous reuse caused by different templates on the same date.

[0041] Understandably, after obtaining the report date and statistics window, the system selects the appropriate tool family based on the template identifier M. This process is represented as:

[0042] in, This represents the routing function from the template to the tool family. This represents the toolset corresponding to template M.

[0043] It should be noted that the key difference between this embodiment and the general tool routing scheme lies in the execution-level isolation of template boundaries. To this end, the system constructs an independent output directory for the current template. This is then injected as an enhancement parameter into each tool call parameter. For any original tool parameter object... The enhanced tool parameter object is denoted as:

[0044] in, This indicates that the template isolates the output directory. This indicates the tool parameters after injecting into the isolated directory.

[0045] Through this mechanism, the system ensures two things: First, the cache checking tool only searches for historical reports within the current template isolation directory, avoiding the misuse of results from different templates on the same date; second, when the report is officially written to disk, it is also written to the same template isolation directory, so that "reading the cache" and "writing results" always fall within the same boundary. In other words, the current stage is not simply "selecting tools", but "selecting tools and determining their execution boundaries".

[0046] Step S30: Fill in the date placeholders for the historical successful call experience according to the report date to obtain the template historical experience after the current report date.

[0047] It's important to note that historical successful call experience refers to the verified and feasible tool call sequences and related parameter patterns recorded and accumulated by the system when executing report generation tasks with the same template identifier in the past. This experience does not store specific date values; instead, it abstracts date-related parameters into placeholders, thus decoupling them from specific dates and enabling cross-date migration capabilities. Template historical experience refers to the call architecture that can be directly used under the current report date after replacing the placeholders with the actual date value corresponding to the current report request.

[0048] It should be understood that at this stage, the system does not allow the model to freely explore the call path from scratch, but first loads the successful call experience of the same template in the past. The so-called historical successful call experience refers to tool call skeletons that have been verified to work under the same template in the past. Date-related parameters are not stored as specific dates, but are uniformly abstracted as placeholders. When a new request arrives, the system uses the current report date. d The process of backfilling date placeholders in the experience can be represented as follows:

[0049] in, This represents a date backfill function. This indicates that the template's historical experience is combined with the current report date.

[0050] It is important to note that this stage does not hardcode historical paths into fixed processes, but rather transforms the skeleton of valid historical calls into a priori information that can be transferred to the current request, thereby reducing the probability of call path drift and improving the stability of the model in strongly constrained scenarios.

[0051] Step S40: Determine the prompt context based on the template history experience, the user input question, the report date, the business statistics window, and the tool parameters.

[0052] It should be noted that the contextual cue refers to the message sequence that is organized into a specific format and used to input a large language model. Its role is to provide the model with all the background information, constraints, descriptions of available tools, and transferable call skeletons required to complete the current report generation task.

[0053] It should be noted that, based on historical experience with templates... Then, the system compares it with the current problem. Report Date Statistics window Template identifier Together with the tool descriptions, they form the initial prompt context. This context serves as the input message queue for the 0th round of the model. .

[0054] Step S50: Input the prompt context as a message queue into the large language model and output the main report.

[0055] It should be noted that the main report is a security report presented in natural language, containing statistical summaries, analytical conclusions, and necessary charts and graphs. Its format and chapter structure are implicitly defined by the template identifier, but the specific data content is obtained and organized by the model through calling tools.

[0056] Understandably, the system uses the prompt context as the zeroth round message queue. Input a large language model. After receiving the message queue, the model does not directly generate the final report all at once, but enters a multi-round inference execution closed loop: the model output may contain tool call requests (such as querying the database, statistical data, retrieving logs, etc.), the system executes these tools and fills the results back into the next round message queue, and inputs them into the model again, and so on, until the model no longer outputs new tool call requests, but outputs natural language content as the main report.

[0057] It should be noted that this embodiment does not address a simple text generation problem, but rather a control problem requiring stable convergence. If the model is allowed to generate reports freely from the input problem, it is prone to instability in key areas such as time caliber, template boundaries, tool call paths, and saving timing. Through phased processing, the system can check and constrain upstream results before proceeding to the next stage, thus forming an "executable, controllable, and traceable" closed loop.

[0058] In this embodiment, a unified report date and business statistics window can be automatically determined based on the report request, and an isolated directory can be injected for tool calls of different templates. At the same time, based on the current report date, the date is backfilled based on the historical successful call experience, and a prompt context containing template historical experience, time caliber and execution boundary is constructed. This effectively avoids the unstable report generation problem caused by replacing all security analysis logic with a large language model, and improves the stability and reproducibility of time-series security report generation.

[0059] Reference Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the timing security report generation method of this application. Based on the first embodiment described above, a second embodiment of the timing security report generation method of this application is proposed.

[0060] In the second embodiment, step S50 includes: Step S501: Determine the message queue for the current round based on the prompt context, and input the message queue into the large language model to obtain the model output for the current round. The model output includes natural language content and a set of tool calls.

[0061] It should be noted that natural language content refers to the text response directly generated by the model, which may include descriptions of the current progress, intermediate analysis conclusions, or fragments of the final report; the tool call set refers to the structured call instructions of one or more external tools requested by the model, with each call instruction containing the tool name and parameter object.

[0062] Specifically, the system constructs the initial message queue. Then, it enters a closed loop of multiple rounds of "model reasoning - tool execution - result backfilling". Let the first... The input message queue for the wheel model is The model output is denoted as:

[0063] in, This represents a large language model with structured output capabilities. This indicates that the model is in the first... The output of the round. It's important to emphasize that this embodiment does not impose any special limitations on the model structure itself, only requiring that it be able to generate structured tool call requests and necessary text output based on the message queue. This model can be a general-purpose large language model that supports function calls, or a general-purpose large language model that can output constrained JSON; it can directly use a pre-trained model, or it can undergo hint optimization or lightweight fine-tuning. The focus of protection in this embodiment is on the subsequent stability control mechanism, not on any specific model itself.

[0064] In one implementation method It can be further broken down into two parts: one part is natural language content. The other part is the tool call set. .in, Indicates the first The wheel-in-the-wheel model requires all tool call requests to be executed. empty and When not empty, the system can proceed to the main report closing stage; when When the system is not empty, it does not execute immediately, but first enters the fingerprint calculation and repetition suppression control.

[0065] Step S502: When the number of tools in the tool call set is not empty, the execution result is determined based on the consecutive repeated call count of the current round.

[0066] It should be noted that the consecutive repeated call count refers to the cumulative value used to measure whether the tool call set in the current round is logically consecutive to the tool call set in the previous round. This count reflects whether the model is trapped in a loop of repeatedly calling the same tools and parameters. There are two possible execution results: when the consecutive repeated call count does not exceed the preset threshold, the execution result is the actual return value obtained after executing each tool in the tool call set (such as database query results, statistical values, etc.); when the consecutive repeated call count exceeds the preset threshold, the execution result is a strong constraint prompt (e.g., "Repeated calls detected, please stop repeatedly requesting the same tools and parameters, and directly generate the final report based on existing information"). This prompt will serve as the input for the next round of the model to guide the model out of the loop.

[0067] In the specific implementation process, a normalized fingerprint can be constructed for each round of tool call set, and a stop prompt can be triggered based on the continuous and repeated comparison results. This transforms the potentially infinitely looping model-tool closed loop into a finite-step convergence process, effectively avoiding resource waste and process deadlock, and improving the robustness of the system. At this point, step S502 includes: The tool call set is normalized to generate the call fingerprint for the current round; The call fingerprint of the current round is compared with the call fingerprint of the previous round, and the consecutive repeated call count is updated according to the comparison result; If the consecutive repeated call count is less than or equal to a preset threshold, then the tool in the tool call set is executed to obtain the execution result; If the number of consecutive repeated calls exceeds the preset threshold, a strong constraint hint is generated and used as the execution result of the current round. The strong constraint hint is used to prompt the large language model to stop repeated calls.

[0068] It should be noted that a call fingerprint refers to a stable and comparable normalized sequence obtained by normalizing the set of tool calls in a given round. This fingerprint can identify calls with "the same logic call but different parameter key order" or "only different injected fields" as having the same fingerprint, thus excluding differences unrelated to business logic. The preset threshold is a system-configurable integer representing the maximum number of consecutive repeated calls allowed by the model. The strong constraint hint is an explicit intervention message used to guide the model to stop invalid repeated calls, directly generating a report based on existing information.

[0069] Specifically, to determine whether logical duplication occurs in multiple rounds of tool calls, this embodiment analyzes the tool call set for each round. Perform normalization processing and construct a normalized call fingerprint. Defined as:

[0070] in, Indicates the first Wheel tool call count Indicates the first The name of the tool that the tool calls. This represents the corresponding parameter object. This represents the parameter normalization function. This means converting the entire set of calls into a stable, comparable canonical sequence.

[0071] in, The process includes at least the following steps: parsing JSON parameters; filtering injected fields, such as "_report_output_dir"; and sorting and serializing the parameter keys into a standard format. Through this process, the system can identify "the same logical call but with different parameter key orders" as the same fingerprint, and can also exclude cases where only the injected fields differ from duplicate checks.

[0072] To provide configurable control over repeated calls, this embodiment defines the first... The consecutive repeated call count of the round is And set the repetition suppression threshold as Next, the call fingerprint of the current round is compared with the call fingerprint of the previous round, and the consecutive repeated call count is updated according to the comparison result. The update rule is as follows:

[0073] in, When the fingerprint of the current call is consistent with that of the previous call, it indicates that the model may be repeatedly requesting the same tools and parameters, and the system will increment the consecutive repetition count by one; when the fingerprints of the two calls are inconsistent, it indicates that the call path has changed, and the consecutive repetition count will be reset to zero.

[0074] when At this point, the system stops executing the current tool call and instead injects a strong constraint prompt of "stop repeated calls and directly generate the final report" into the next round's message queue, skipping the current round of tool execution. Through this mechanism, this embodiment transforms what could have been an infinitely looping model-tool closed loop into a finite-step convergence process.

[0075] For the set of calls that are allowed to be executed The system executes tool calls one by one, and then encapsulates the return results into standard tool messages before filling them into the next round of message queues. In one implementation, the backfill message includes at least the following fields: tool message role, tool invocation identifier, tool name, and tool output content.

[0076] After completing the tool execution, the executor also synchronously records the tool's execution time, parameter key set, exception information, and result summary to support subsequent log management and execution backtracking. This stage includes a duplicate suppression check before tool execution and structured result backfilling after execution, thus forming a stable closed-loop control.

[0077] In one example, reference Figure 3 , Figure 3 This is a sub-flowchart for the duplication suppression mechanism in this application. The system first receives the output returned by the model and extracts the tool call set. Then, it performs normalization processing on each tool parameter in the tool call set and filters out injected fields unrelated to business logic. Based on the processed tool name and parameters, it constructs the call fingerprint for this round. Next, determine the fingerprint of this round of calls. fingerprint compared to the previous round of calls Are they equal? ​​If and If they are not equal, the continuous call count will be reset to zero, and the tool call in this round will be executed normally; if and If the counts are equal, the consecutive repeated call count is incremented by 1. After incrementing, it is further determined whether the updated consecutive repeated call count is greater than a preset threshold. If the count does not exceed the threshold, the tool call is executed normally. If the count exceeds the threshold, it is determined to be an abnormal repeated loop. In this case, the tool call is no longer executed, but a strong constraint prompt to stop repeated calls is injected into the next round's message queue, and the tool execution in this round is skipped, guiding the model directly to the final report generation stage. Through the above process, the system can effectively identify and suppress the repeated loop behavior of the model in the tool call stage, ensuring the finite-step convergence of the multi-round inference closed loop.

[0078] Step S503: Inject the execution result into the message queue of the next round, return to the step of inputting the message queue into the large language model, until the number of tools in the tool call set is empty, and use the natural language content as the main report corresponding to the report request.

[0079] It should be understood that when the system will After being re-entered into the large language model, the model determines its next action based on the newly added execution results. For example, if the execution result is data returned by a tool, the model might generate a partial report text based on this and continue calling another tool to obtain key IP details; if the execution result is a strong constraint prompt, the model should interpret this as a need to stop repeated calls and instead generate a report based on existing data. The model's new output is again parsed into natural language content and a new set of tool calls. This loop continues until a certain round of tool call sets is reached. Empty.

[0080] It should be noted that this embodiment explicitly distinguishes between "business zero value" and "execution error". For example, when a statistical function returns record_count = 0, this result may just mean "no relevant records were found in the current statistics window", which is a valid result in business terms, rather than an execution failure.

[0081] Therefore, in this embodiment, the result of returning a zero value does not trigger a process interruption, but continues to participate in the subsequent report generation, and the report text reflects factual descriptions such as "no record on the day" and "no relevant key objects found".

[0082] The necessity of this mechanism lies in the fact that many statistical items in the timing safety report may naturally be zero. If the system treats all zero values ​​as abnormal, it will not only mistakenly terminate the process but also prevent the delivery of a large number of normal reports in sparse scenarios. Therefore, this phase improves the stability of the system in a real production environment through a zero-value tolerance mechanism.

[0083] In this embodiment, a multi-round closed loop of "model inference - tool invocation - result backfilling" is iteratively executed, and the termination condition for the main report output is based on whether the tool invocation set is empty in each round. This expands the single large language model invocation into a controllable multi-round interactive mechanism, enabling the model to acquire external data step by step and gradually improve the report content.

[0084] Reference Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the timing security report generation method of this application. Based on the first embodiment described above, a third embodiment of the timing security report generation method of this application is proposed.

[0085] In the third embodiment, after step S50, the method further includes: Step S601: Select a set of key objects from the business statistics window based on the main filtering rules.

[0086] It should be noted that after the main report is generated, the system can decide whether to enable the key object analysis module based on template configuration or business rules. The key objects can be key IPs, key events, key assets, or other objects that need to be described separately in the report.

[0087] It should be noted that the master screening rule is a set of predefined screening conditions based on business indicators or statistical thresholds, used to automatically identify objects worthy of special attention from the raw data within the business statistics window. Unlike random sampling or simple sorting in general Q&A, the master screening rule in this application typically combines multiple dimensions such as risk level, frequency, and relevance for comprehensive judgment to ensure that the selected key objects have practical analytical value and business implications.

[0088] Understandably, the system can aggregate and statistically analyze various logs, alarms, and event data within the business statistics window, and filter out key object sets through the main filtering rules.

[0089] In the specific implementation process, after the main report is generated, the main rule can be used to filter key objects first. If the results are insufficient, backup completion can be automatically triggered, and then a summary can be generated and attached to the report, thereby improving the completeness of key analysis sections in data-sparse scenarios. At this time, step S601 may include: The first set of key objects is selected from the business statistics window based on the main filtering rules; If the number of objects in the first set of key objects is less than the preset upper limit, a backup query is triggered to obtain the second set of key objects. A set of key objects is generated based on the first set of key objects and the second set of key objects.

[0090] It should be noted that the first set of key objects refers to the objects directly filtered from the business statistics window data through the main filtering rules, which are typically based on business indicators such as risk level, frequency, and relevance. The preset quantity limit refers to the maximum number of key objects expected to be displayed in the final report; this value can be configured according to the template type or business needs. The backup query is a supplementary query mechanism automatically initiated by the system when the main filtering results are insufficient to reach the preset quantity limit. Its purpose is to ensure the structural integrity of the key object analysis paragraphs and avoid missing key content in the report due to data sparsity. The second set of key objects is the supplementary object set obtained through the backup query. The final generated set of key objects is usually formed by merging the first and second sets and then truncating the first preset quantity limit of objects according to a preset sorting rule.

[0091] Specifically, the system first selects from the statistics window based on the main filtering rules. Filter the key object set from the results. The main screening rules can be determined based on a combination of risk level, access frequency, alarm count, event correlation, or other business indicators.

[0092] If the number of primary selection results is insufficient, i.e., in the first priority object set:

[0093] in, Indicates the number of primary filter results. If the maximum number of key objects is specified, the system will trigger a backup query to obtain a complete set of second key objects. And construct the final set of key objects:

[0094] in, This indicates that the data is truncated according to the preset sorting rules. Each object. Through this mechanism, the system can still ensure the structural integrity of the key analysis sections even in data-sparse scenarios, and will not output a report with a missing key object section due to insufficient main screening results.

[0095] Step S602: Generate an object-level summary for each object in the set of key objects, and output the key object summary text corresponding to the object-level summary based on the summary generation module.

[0096] Step S603: Render the summary text of the key object based on the key analysis template, and add the rendering result to the main report to obtain a complete time-series security report.

[0097] It should be noted that object-level summaries refer to structured analytical text generated for a single object within a set of key objects. The summary generation module is the functional unit in the system responsible for converting raw statistical data and event records into natural language summaries. The key object summary text is the final text fragment output by this module.

[0098] As we can understand, rendering refers to filling the corresponding positions with the summary text of each object according to the template's format requirements, forming a structurally complete key analysis paragraph. Adding this paragraph to the end of the main report (or a specified position) yields a complete time-series security report containing an overall statistical summary and detailed analysis of key objects.

[0099] Specifically, after obtaining the final set of key objects Then, the system will extract statistical results, behavioral features and related event fragments for each object, and construct an object-level summary input; subsequently, the summary generation module will output the corresponding key object summary text, and after rendering according to the key analysis template, it will be attached to the main report.

[0100] In one implementation, the summary generation can be achieved by using either "rule organization + large language model generation" or "constrained template filling + large language model polishing". Its input includes at least object identifiers, statistical indicators, time windows and key event fragments, and the output is a structured summary analysis section.

[0101] Furthermore, since the focus analysis occurs after the main report is generated, the main report can still be delivered normally even if this module fails. This design enhances focus analysis capabilities without affecting the stability of the main report delivery.

[0102] In the specific implementation process, the report date, current time, deadline, and forced save flag can be jointly modeled to form a dynamic write-to-disk determination function, ensuring that the report is only solidified into a formal version when the business timing conditions are met. This transforms the aforementioned execution result from a "runtime artifact" into a "deliverable, auditable, and reusable" formal output, providing a complete process record for subsequent review and optimization. At this point, after step S603, the following is also included: Determine whether the complete timing security report contains a mandatory save flag; If the forced save flag does not exist, then determine whether the current system date is later than the report date, or whether the system date is equal to the report date and the system time has reached the business cutoff point; When the current system date is later than the report date, or when the system date is equal to the report date and the system time reaches the business deadline, the log information corresponding to the complete time-series security report is recorded, and the historical successful call experience is updated according to the tool call sequence corresponding to the complete time-series security report.

[0103] It should be noted that the forced save flag is a flag explicitly specified by the user or the upper-level system to override the default disk write timing judgment. Its value can be 0, 1, or empty. When the flag is 1, the report is forcibly saved regardless of the relationship between the current system date and the report date; when it is 0, it is forcibly not saved; when it is empty, the judgment is made according to dynamic rules based on business time points. The current system date and system time refer to the actual calendar time obtained from the operating system or time server when the disk write judgment is executed. Log information includes three categories: request logs, execution logs, and performance logs, which respectively record input parameters, call fingerprints, duplicate suppression triggering situations, tool consumption time, total number of iterations, etc.

[0104] It should be understood that security reports are typically required to be officially delivered after the business deadline. Saving them too early may result in incomplete data within the statistical window, while saving them too late may affect the timeliness of business operations. By jointly determining the mandatory save flag, system date, report date, and business deadline, the system can precisely control when the report is finalized.

[0105] It should be understood that, unlike general question-and-answer systems, time-series security reports not only require the content to be generated correctly, but also that it be saved at the correct business time and provide a complete process record for subsequent review and optimization. Therefore, this phase simultaneously undertakes three responsibilities: write control, log governance, and experience accumulation.

[0106] First, an explicit determination is made regarding whether to write the formal report to disk. If an explicit mandatory save flag exists, it is prioritized for decision-making. If no mandatory save flag exists, writing to disk is only permitted when "the current system date is later than the report date" or "the current system date is equal to the report date and the current system time has reached the business cutoff point." In all other cases, writing to disk is not permitted. Therefore, the disk write determination result is... Defined as:

[0107] in, Indicates a forced save flag; Indicates the current system date; Indicates the current system time; Indicates the report date; Indicates the end date of the business.

[0108] After determining the disk write result, the system synchronously records three types of logs. The first type is the request log, which records input parameters, template identifier, date source, statistical window construction result, and cache hit status. The second type is the execution log, which records each round of calls, call fingerprint, duplicate suppression trigger status, tool time consumption, parameter key set, and exception information. The third type is the performance log, which records metrics such as total time consumption, number of iterations, number of key objects, and disk write result.

[0109] Once the process is successfully completed, the system extracts the stable and valid tool call sequences and their key parameter patterns from the current call chain, and saves them as new historical call experiences according to the template dimension. Unlike retraining models, this mechanism can achieve post-execution learning without relying on retraining, thus forming a closed-loop improvement path of "execution-evaluation-retention-reuse".

[0110] In this embodiment, after the main report is generated, a set of key objects is obtained by filtering the data in the business statistics window using master rules. An object-level summary is then generated for each object, rendered according to a template, and added to the main report. This automates and structures the analysis of key objects, ensuring that the report includes both an overall statistical summary and detailed explanations of key points, thus improving the report's information completeness and readability.

[0111] For example, to help understand the implementation flow of the timing security report generation method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 5 , Figure 5 Here is a simplified flowchart of a time-series security report generation method, specifically: The system first receives user-input request parameters (including input question, date, and template identifier), performs parameter standardization and template validation. After successful validation, it proceeds to the date determination and statistics window construction phase, generating a unified report date and business statistics window. Subsequently, it performs template routing and isolated directory injection, determining the tool family corresponding to the current template and generating an isolated output directory. Next, it checks if the template cache is hit; if so, it directly returns the cached report; otherwise, it loads historical call experience for the same template and backfills the date placeholders in the experience. In this closed loop, it first checks if there are tool calls in the model output. If so, it calculates the call fingerprint and checks if consecutive repeated calls exceed a threshold. If the threshold is exceeded, it injects a stop-repeating prompt and skips the current round of tool execution; if not, it... If the threshold is reached, the tool is executed and the results are backfilled. Then, the loop start point is returned to re-evaluate the model output. If no tool call is found in the model output, the loop is exited and the main report closing stage is entered. After closing, it is determined whether key object analysis is enabled. If enabled, the main filtering, backup completion, and summary rendering are executed to generate key analysis content and add it to the report. If not enabled, it is skipped. Then, the output is cleaned up, and it is determined whether the point-in-time saving conditions are met (based on the comparison of system date, report date, and business cutoff time, as well as the forced saving flag). If the saving conditions are met, the complete report is saved to the template isolation directory. If not, only the report result is returned without persistence. Finally, the log is written and the experience is accumulated. The log information of this execution is recorded and the historical successful call experience is updated according to the call sequence.

[0112] This application divides the generation process of the time-series security report into seven stages: Stage A is request standardization and template verification; Stage B is report date determination and time-series window construction; Stage C is template-tool routing and isolation parameter injection; Stage D is experience memory backfilling and prompt construction; Stage E is multi-round inference execution and repeated call suppression; Stage F is two-stage completion analysis of key objects; Stage G is point-in-time saving, log persistence and experience accumulation.

[0113] From a data flow perspective, the system first receives user questions, date parameters, and template identifiers, and generates a unified report date and statistics window. Then, based on the template, it determines the execution boundaries and tool families. Building upon this, it constructs multi-round prompt contexts by incorporating historical success experiences. Subsequently, it enters a model-tool closed loop, implementing duplication suppression within the loop. After the main report is generated, it performs completion of key objects as needed. Finally, based on the business timeline, it decides whether to save the official report and synchronizes logs and experience. Because the responsibilities of each stage are clearly defined, the system can adapt to template expansion and facilitates auditing and regression analysis.

[0114] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the timing security report generation method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0115] This application also provides a timing security report generation device; please refer to... Figure 6 The timing security report generation device includes: The date determination module 10 is used to respond to a report request input by a user and determine the report date and business statistics window based on the user input question and the original report date in the report request; The tool determination module 20 is used to determine the corresponding tool family based on the template identifier in the report request, and inject an isolation directory into the tool call parameters of each tool in the tool family to obtain the tool parameters; The date backfilling module 30 is used to backfill the date placeholders of the historical successfully called experience according to the report date, so as to obtain the template historical experience after the current report date; The context determination module 40 is used to determine the prompt context based on the template historical experience, the user input question, the report date, the business statistics window, and the tool parameters; The model output module 50 is used to input the prompt context as a message queue into the large language model and output the main report.

[0116] The timing security report generation apparatus provided in this application, employing the timing security report generation method described in the above embodiments, can solve the technical problem of how to achieve unified determination of time caliber, explicit isolation of template boundaries, and effective transfer of historical successful experiences during the generation of timing security reports from large language models, thereby improving the stability and controllability of report generation. Compared with the prior art, the beneficial effects of the timing security report generation apparatus provided in this application are the same as those of the timing security report generation method provided in the above embodiments, and other technical features in the timing security report generation apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0117] This application provides a timing security report generation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the timing security report generation method in the first embodiment described above.

[0118] The following is for reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing the timing security report generation device of the present application embodiments. The timing security report generation device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The timing security report generation device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0119] like Figure 7 As shown, the timing security report generation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the timing security report generation device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the timing security report generation device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows timing security report generation devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0120] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0121] The timing security report generation device provided in this application, employing the timing security report generation method in the above embodiments, can solve the technical problem of how to achieve unified determination of time caliber, explicit isolation of template boundaries, and effective transfer of historical successful experience during the generation of timing security reports from large language models, thereby improving the stability and controllability of report generation. Compared with the prior art, the beneficial effects of the timing security report generation device provided in this application are the same as those of the timing security report generation method provided in the above embodiments, and other technical features in this timing security report generation device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0122] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0123] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0124] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the timing security report generation method in the above embodiments.

[0125] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0126] The aforementioned computer-readable storage medium may be included in the timing security report generation device; or it may exist independently and not assembled into the timing security report generation device.

[0127] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the timing security report generation device, cause the timing security report generation device to perform the timing security report generation method described above.

[0128] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0129] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0130] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0131] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned time-series security report generation method. This medium addresses the technical problem of how to achieve unified determination of time caliber, explicit isolation of template boundaries, and effective transfer of historical successful experiences during the generation of time-series security reports from large language models, thereby improving the stability and controllability of report generation. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the time-series security report generation method provided in the above embodiments, and will not be elaborated upon here.

[0132] The above description is only a part of the embodiments of this application and does not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

[0133] It should be noted that the data collection, tag management, rule setting, and push decision-making processes involved in this application are designed to work with other technical features to solve technical problems. They do not involve or support any illegal activities. Any data processing that may violate laws and regulations (such as unauthorized collection of privacy data, generation of discriminatory tags, setting unfair rules, or pushing illegal information) is not within the scope of protection of this application's technical solution. Of course, the user data in this application will be encrypted, anonymized, or de-identified before storage to ensure user data security.

Claims

1. A method for generating a time-sequential safety report, characterized by, The method for generating the time-series security report includes: In response to a user-inputted report request, the report date and business statistics window are determined based on the user-inputted question and the original report date. The corresponding tool family is determined based on the template identifier in the report request, and an isolation directory is injected into the tool call parameters of each tool family to obtain the tool parameters; Based on the report date, the date placeholders for the historical successfully invoked experience are filled in to obtain the template historical experience after the current report date; The prompt context is determined based on the template's historical experience, the user's input question, the report date, the business statistics window, and the tool parameters; The prompt context is input into the large language model as a message queue, and the main report is output. The step of inputting the prompt context as a message queue into the large language model and outputting a main report includes: The message queue for the current round is determined based on the context of the prompt, and the message queue is input into the large language model to obtain the model output for the current round. The model output includes natural language content and a set of tool calls. When the number of tools in the tool call set is not empty, the execution result is determined based on the consecutive repeated call count of the current round; The execution result is injected into the message queue of the next round, and the step of inputting the message queue into the large language model is returned until the number of tools in the tool call set is empty, and the natural language content is used as the main report corresponding to the report request. The step of determining the execution result based on the consecutive repeated call count of the current round includes: The tool call set is normalized to generate the call fingerprint for the current round; The call fingerprint of the current round is compared with the call fingerprint of the previous round, and the consecutive repeated call count is updated according to the comparison result; If the consecutive repeated call count is less than or equal to a preset threshold, then the tool in the tool call set is executed to obtain the execution result; If the number of consecutive repeated calls exceeds the preset threshold, a strong constraint hint is generated and used as the execution result of the current round. The strong constraint hint is used to prompt the large language model to stop repeated calls.

2. The time-critical report generation method of claim 1, wherein, After inputting the prompt context as a message queue into the large language model and outputting the main report, the method further includes: Based on the main filtering rules, a set of key objects is selected from the business statistics window; Generate an object-level summary for each object in the set of key objects, and output the key object summary text corresponding to the object-level summary based on the summary generation module; The summary text of the key objects is rendered based on the key analysis template, and the rendering result is added to the main report to obtain a complete time-series security report.

3. The time-critical report generation method of claim 2, wherein, The process of filtering the set of key objects from the business statistics window based on the main filtering rules includes: The first set of key objects is selected from the business statistics window based on the main filtering rules; If the number of objects in the first set of key objects is less than the preset upper limit, a backup query is triggered to obtain the second set of key objects. A set of key objects is generated based on the first set of key objects and the second set of key objects.

4. The time-critical report generation method of claim 2, wherein, After rendering the summary text of the key objects based on the key analysis template and adding the rendering result to the main report to obtain a complete time-series security report, the process also includes: Determine whether the complete timing security report contains a mandatory save flag; If the forced save flag does not exist, then determine whether the current system date is later than the report date, or whether the system date is equal to the report date and the system time has reached the business cutoff point; When the current system date is later than the report date, or when the system date is equal to the report date and the system time reaches the business deadline, the log information corresponding to the complete time-series security report is recorded, and the historical successful call experience is updated according to the tool call sequence corresponding to the complete time-series security report.

5. The method of claim 1, wherein, The process of determining the report date and business statistics window based on the user input question and the original report date in the report request includes: The report date is determined based on the user input question and the original report date in the report request. A business statistics window is constructed based on the business cutoff time of the report request and the report date. The business statistics window is a left-closed and right-open interval from the business cutoff time of the day before the report date to the business cutoff time of the report date.

6. A time-critical safety report generation apparatus characterized by The device includes: The date determination module is used to respond to a user-inputted report request and determine the report date and business statistics window based on the user-inputted question and the original report date in the report request; The tool determination module is used to determine the corresponding tool family based on the template identifier in the report request, and inject an isolation directory into the tool call parameters of each tool family to obtain the tool parameters; The date backfilling module is used to backfill the date placeholders of historical successfully called experiences according to the report date, so as to obtain the template historical experience after the current report date; The context determination module is used to determine the prompt context based on the template's historical experience, the user's input question, the report date, the business statistics window, and the tool parameters; The model output module is used to input the prompt context as a message queue into the large language model and output the main report; The model output module is further configured to determine the message queue for the current round based on the prompt context, and input the message queue into the large language model to obtain the model output for the current round. The model output includes natural language content and a tool call set. When the number of tools in the tool call set is not empty, the execution result is determined based on the consecutive repeated call count for the current round. The execution result is injected into the message queue for the next round, and the step of inputting the message queue into the large language model is returned until the number of tools in the tool call set is empty. The natural language content is then used as the main report corresponding to the report request. The model output module is further configured to normalize the tool call set to generate a call fingerprint for the current round; compare the call fingerprint of the current round with the call fingerprint of the previous round, and update the consecutive repeated call count based on the comparison result; if the consecutive repeated call count is less than or equal to a preset threshold, execute the tool in the tool call set to obtain the execution result; if the consecutive repeated call count is greater than the preset threshold, generate a strong constraint prompt and use the strong constraint prompt as the execution result of the current round, wherein the strong constraint prompt is used to prompt the large language model to stop repeated calls.

7. A time-critical safety report generating device, characterized by The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the timing security report generation method as described in any one of claims 1 to 5.

8. A storage medium, characterized by The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the timing security report generation method as described in any one of claims 1 to 5.

Images