A report generation method based on an intermediate instruction set and a security isolation layer
Patent Information
- Application Number
- CN202610953221.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-30
- Publication Date
- 2026-10-09
- Estimated Expiration
- 2046-06-30
AI Technical Summary
增加了用户的交互成本,延长了数据获取链路,增加了耗时,还有改进的空间
[0008]The above-described embodiments of this disclosure have the following beneficial effects: The report generation method based on intermediate instruction sets and security isolation layers in some embodiments of this disclosure achieves physical data isolation and fine-grained instruction access control, reducing the risk of unauthorized access and data tampering caused by abnormal instructions, and improving data security and operational stability during report generation. Specifically, the reasons for unauthorized data access and instruction execution errors are: large language models have non-deterministic characteristics when generating query statements, easily generating fields that do not exist in the database (data illusion), or generating non-standard instructions with data modification intentions. Directly applying the generated query instructions to the physical data source (database) easily increases the risk of exposing underlying sensitive data. Based on this, the report generation method based on intermediate instruction sets and security isolation layers in some embodiments of this disclosure first performs semantic parsing processing on the received natural language report request to obtain a structured intent object. Thus, the unstructured user language is transformed into a standardized data structure that can be processed by a computer, providing a clear intent basis for subsequent matching of the underlying business data source. Secondly, based on the pre-defined business data semantic layer mapping table, the structured intent objects are subjected to relational query processing to obtain a candidate data view set, which includes field contract configurations and organization isolation fields. This constructs a business semantic defense line above the physical data tables, pre-determining the allowed column-level data boundaries (field contracts) and row-level data ranges (organization isolation fields) for this query, thereby controlling the exposure of sensitive information. Next, based on the candidate data view set, the structured intent objects are subjected to instruction structure assembly processing to obtain an intermediate instruction set, which includes view reference declarations and query blocks restricted by the field contract configurations. This constrains the model's output within a predefined canonical structure, replacing the exposure of physical tables with "view references" and limiting the scope of "query blocks" to allowed fields, effectively reducing the execution risks caused by illegal SQL injection and data illusion. Then, for each intermediate instruction in the aforementioned intermediate instruction set, the following steps are performed: In response to the passing of the intermediate instruction's validity check, based on the view reference declaration of the intermediate instruction, field projection pruning is performed on the underlying physical data source to obtain an isolated sandbox environment. The validity check includes read-only attribute verification for the query block and field existence verification based on the field contract configuration. Thus, interception is performed before instruction execution, eliminating abnormal instructions with modification intent and phantom fields. Simultaneously, the data of the required fields is projected into memory to construct an independent sandbox, physically preventing the impact of illegal instructions on the database. Based on the isolated sandbox environment and the aforementioned organizational isolation fields, the query block corresponding to the intermediate instruction is processed into read-only mode to obtain structured query results.Therefore, by executing query operations in a secure, isolated in-memory computing environment and implementing row-level data filtering using organizational isolation fields, user data access boundaries are restricted, preventing unauthorized data reading or tampering across organizations. Finally, the obtained structured query results are transformed into visual blocks to generate reports, which are then rendered graphically and sent to the terminal display device for display. This process converts legitimate data, after strict security verification and access control, into visual charts, providing users with an intuitive understanding of the results.
Smart Images

Figure CN122489586B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a report generation method based on an intermediate instruction set and a security isolation layer. Background Technology
[0002] Report generation refers to the data processing process of obtaining business data from data sources and transforming it into visual charts to intuitively present the business status.
[0003] In related technologies, in natural language-based intelligent report generation scenarios, a common approach is to directly generate query commands using a large language model: The table structure information of the database is obtained and concatenated with the user's natural language query requirements, then input together into the large language model. The large language model performs inference and outputs the corresponding Structured Query Language (SQL) query statement. Subsequently, the SQL query statement is sent to the database for execution, and the returned data results are rendered into a report and displayed to the user.
[0004] Regarding the aforementioned technologies, large language models exhibit certain non-deterministic characteristics when generating query statements. For example, during inference, the model may generate instructions with fields that do not exist in the database (i.e., creating data illusions) or non-standard instructions with potential data modification intentions. Since the generated query statements are typically applied directly to the physical data source, there is a possibility of unauthorized data access, increasing the risk of sensitive data exposure. When generated instructions cause database execution errors due to erroneous characteristics, users usually need to manually analyze the error messages and readjust their requirements. This increases user interaction costs, prolongs the data acquisition process, and increases time consumption, leaving room for improvement. Summary of the Invention
[0005] To overcome the risks of execution errors and unauthorized access caused by data illusion when generating query commands from large language models, and to improve the efficiency of command error correction and the security of data execution, this application provides a report generation method based on an intermediate instruction set and a security isolation layer.
[0006] Firstly, this application provides a report generation method based on an intermediate instruction set and a security isolation layer, employing the following technical solution: The received natural language report request is semantically parsed to obtain a structured intent object. Based on a preset business data semantic layer mapping table, the structured intent object is subjected to association query processing to obtain a candidate data view set, which includes: field contract configuration and organization isolation fields. Based on the candidate data view set, the structured intent object is subjected to instruction structure assembly processing to obtain an intermediate instruction set, which includes view reference declarations and query blocks restricted by the field contract configuration. For each intermediate instruction in the intermediate instruction set, the following steps are performed: in response to the above... Once the intermediate instruction passes the validity check, based on the view reference declaration of the intermediate instruction, field projection and pruning are performed on the underlying physical data source to obtain an isolated sandbox environment. The validity check includes read-only attribute verification for the query block and field existence verification based on the field contract configuration. Based on the isolated sandbox environment and the organizational isolation field, the query block corresponding to the intermediate instruction is processed into a read-only state to obtain structured query results. Each structured query result is then transformed into a visualization block to generate a report. Finally, the report is rendered graphically and sent to the terminal display device for display.
[0007] Secondly, this application provides a report generation device based on an intermediate instruction set and a security isolation layer, employing the following technical solution: The module is used to acquire natural language report requirements; the memory is used to store the program of the above-mentioned report generation method based on intermediate instruction set and security isolation layer; the processor is used to load and execute the program in the memory and implement the above-mentioned report generation method based on intermediate instruction set and security isolation layer.
[0008] The above-described embodiments of this disclosure have the following beneficial effects: The report generation method based on intermediate instruction sets and security isolation layers in some embodiments of this disclosure achieves physical data isolation and fine-grained instruction access control, reducing the risk of unauthorized access and data tampering caused by abnormal instructions, and improving data security and operational stability during report generation. Specifically, the reasons for unauthorized data access and instruction execution errors are: large language models have non-deterministic characteristics when generating query statements, easily generating fields that do not exist in the database (data illusion), or generating non-standard instructions with data modification intentions. Directly applying the generated query instructions to the physical data source (database) easily increases the risk of exposing underlying sensitive data. Based on this, the report generation method based on intermediate instruction sets and security isolation layers in some embodiments of this disclosure first performs semantic parsing processing on the received natural language report request to obtain a structured intent object. Thus, the unstructured user language is transformed into a standardized data structure that can be processed by a computer, providing a clear intent basis for subsequent matching of the underlying business data source. Secondly, based on the pre-defined business data semantic layer mapping table, the structured intent objects are subjected to relational query processing to obtain a candidate data view set, which includes field contract configurations and organization isolation fields. This constructs a business semantic defense line above the physical data tables, pre-determining the allowed column-level data boundaries (field contracts) and row-level data ranges (organization isolation fields) for this query, thereby controlling the exposure of sensitive information. Next, based on the candidate data view set, the structured intent objects are subjected to instruction structure assembly processing to obtain an intermediate instruction set, which includes view reference declarations and query blocks restricted by the field contract configurations. This constrains the model's output within a predefined canonical structure, replacing the exposure of physical tables with "view references" and limiting the scope of "query blocks" to allowed fields, effectively reducing the execution risks caused by illegal SQL injection and data illusion. Then, for each intermediate instruction in the aforementioned intermediate instruction set, the following steps are performed: In response to the passing of the intermediate instruction's validity check, based on the view reference declaration of the intermediate instruction, field projection pruning is performed on the underlying physical data source to obtain an isolated sandbox environment. The validity check includes read-only attribute verification for the query block and field existence verification based on the field contract configuration. Thus, interception is performed before instruction execution, eliminating abnormal instructions with modification intent and phantom fields. Simultaneously, the data of the required fields is projected into memory to construct an independent sandbox, physically preventing the impact of illegal instructions on the database. Based on the isolated sandbox environment and the aforementioned organizational isolation fields, the query block corresponding to the intermediate instruction is processed into read-only mode to obtain structured query results.Therefore, by executing query operations in a secure, isolated in-memory computing environment and implementing row-level data filtering using organizational isolation fields, user data access boundaries are restricted, preventing unauthorized data reading or tampering across organizations. Finally, the obtained structured query results are transformed into visual blocks to generate reports, which are then rendered graphically and sent to the terminal display device for display. This process converts legitimate data, after strict security verification and access control, into visual charts, providing users with an intuitive understanding of the results. Attached Figure Description
[0009] Figure 1 This is a flowchart of some embodiments of the report generation method based on intermediate instruction sets and security isolation layers according to this disclosure. Detailed Implementation
[0010] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.
[0011] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.
[0012] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.
[0013] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".
[0014] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.
[0015] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.
[0016] refer to Figure 1The diagram illustrates a flow 100 of some embodiments of a report generation method based on an intermediate instruction set and a security isolation layer according to this disclosure. This report generation method based on an intermediate instruction set and a security isolation layer includes the following steps: Step 101: Perform semantic parsing on the received natural language report request to obtain a structured intent object.
[0017] In some embodiments, the executing entity (e.g., an electronic device) of the above-described report generation method based on intermediate instruction sets and security isolation layers can be hardware or software. When the computing device is hardware, it can be implemented as a distributed cluster composed of multiple servers or terminal devices, or as a single server or a single terminal device. When the computing device is software, it can be installed in the hardware devices listed above. It can be implemented as multiple software programs or software modules to provide distributed services, or as a single software program or software module. No specific limitations are made here.
[0018] In some embodiments, the aforementioned execution entity can perform semantic parsing processing on the received natural language reporting request to obtain a structured intent object. The natural language reporting request can be unstructured text input by business personnel. This unstructured text can contain data dimensions and metrics to be queried. For example, the natural language reporting request could be "Generate a quality and safety analysis report on adverse nursing events in Region A for the second quarter of 2026." The structured intent object can be a standard computer data structure that can be used by the subsequent business data semantic layer mapping module. This standard computer data structure can include: query dimensions, aggregation methods, and conditional filtering nodes. For example, the structured intent object can include, but is not limited to: time range (Time_Range), metrics (Metrics), dimension grouping (Group_By), and organizational constraints (Org_Constraint). The organizational constraints can be used for subsequent organizational isolation field filtering. The standard computer data structure can be in JSON (JavaScript Object Notation) format or an Abstract Syntax Tree (AST).
[0019] As an example, firstly, the aforementioned execution entity can obtain a pre-defined intent extraction prompt template (PromptTemplate). This template predefines output boundary constraints and marker bits for the report generation intent. The natural language report requirement and the intent extraction prompt template can be serialized and concatenated to generate intent parsing prompts. Secondly, the intent parsing prompts are input into a pre-deployed Large Language Model (LLM) to obtain the initial non-deterministic intent text output by the LLM. Then, a deployed structured parser can be used to perform pattern matching and boundary extraction on the initial non-deterministic intent text. Specifically, the structured parser uses a pre-defined regular expression or syntax tree parsing algorithm to capture valid key-value pairs related to report generation from the initial non-deterministic intent text and performs deserialization format conversion to obtain a structured intent object.
[0020] Optionally, the aforementioned execution entity can monitor the parsing status in real time. If the initial non-deterministic intent text fails to meet the preset JSON format constraints or lacks necessary report fields (i.e., intent loss or format illusion occurs in the large language model), causing the structured parser to fail to extract the data, the current parsing data stream is forcibly interrupted, and the data is routed to the exception handling node to perform an interception action. A format correction prompt is sent to the terminal display device to prevent non-standard features from entering subsequent stages.
[0021] Step 102: Based on the preset business data semantic layer mapping table, perform association query processing on the structured intent objects to obtain a candidate data view set.
[0022] In some embodiments, the aforementioned execution entity can perform relational query processing on the aforementioned structured intent object based on a preset business data semantic layer mapping table to obtain a candidate data view set, wherein the candidate data view set includes: field contract configuration and organization isolation fields. The preset business data semantic layer mapping table can be a mapping relationship table representing the relationship between business-side natural language terms and the underlying physical database. The aforementioned business-side natural language terms can be mapped to physical table names, physical column names, and permission levels in the underlying physical database. The preset business data semantic layer mapping table can be a dictionary table pre-configured in a relational database. For example, the business term "adverse event" can be mapped to the underlying physical column "adverse_events". The aforementioned candidate data view can be a logical data projection range from the underlying data source that satisfies the current structured intent. The aforementioned field contract configuration can be a legal boundary (i.e., a column-level data access whitelist) representing the underlying physical columns that are explicitly allowed to be accessed by the current query request, and can be used for subsequent field existence verification and interception in a sandbox isolation environment. For example, the aforementioned field contract configuration can be a set of data groups with legal column identifiers (e.g., "region_id"). The aforementioned organization isolation field can be a horizontal privilege escalation isolation attribute column representing row-level data security access control, which can be dynamically injected into conditional filter nodes later. For example, the organization isolation field can be the "quality_id" or "user_id" attribute column in the underlying physical data table.
[0023] As an example, firstly, the aforementioned execution entity performs node traversal and field extraction on the structured intent object, extracting business dimension features and business metric features (e.g., extracting the "dimensional grouping" and "metric" attributes from the abstract syntax tree). Secondly, for each business dimension feature and business metric feature, primary key traversal comparison and address mapping are performed in the business data semantic layer mapping table, mapping the business dimension feature and business metric feature to the real physical table name and real physical column name. Then, metadata assembly processing is performed based on the real physical table name and real physical column name to construct the basic view scope. Simultaneously, column-level whitelist features bound to the current real physical table name can be extracted from the permission attribute column of the aforementioned business data semantic layer mapping table as field contract configurations, and row-level security identifier columns bound to the current report business domain can be extracted as organization isolation fields. Finally, the constructed basic view scope, field contract configurations, and organization isolation fields are serialized, aggregated, and encapsulated to obtain a candidate data view set.
[0024] Optionally, if no matching primary key record is found for any extracted business dimension feature or business metric feature in the aforementioned business data semantic layer mapping table, indicating that the current reporting requirement has the risk of field illusion or unauthorized injection, the aforementioned execution entity will forcibly interrupt the current metadata assembly process, throw a semantic undefined exception, and return a query rejection instruction to the front-end device to prevent illegal fields from entering the subsequent sandbox environment.
[0025] Step 103: Based on the candidate data view set, perform instruction structure assembly processing on the structured intent object to obtain the intermediate instruction set.
[0026] In some embodiments, the execution entity can perform instruction structure assembly processing on the structured intent object based on the candidate data view set to obtain an intermediate instruction set. The intermediate instructions include view reference declarations and query blocks constrained by the field contract configuration. The intermediate instructions can be a standardized secure query language between natural language intents and executable physical SQL. For example, the intermediate instructions can be written in a Domain Specific Language (DSL), enabling security auditing and validity verification in an environment independent of direct connection to the physical data source. The view reference declaration can be a virtual reference identifier that logically masks and securely maps the underlying real physical table name. For example, the view reference declaration can be a logical view alias that does not contain the real physical database name and table name (e.g., "v_years_quality_data"). The query block can be a sequence of logical instructions for executing a specific query task. This sequence of logical instructions can encapsulate data aggregation calculation logic and conditional filtering logic, and can be used for controlled data reading in a subsequent isolated sandbox environment. For example, the query block mentioned above could be a predefined “Select-Where” instruction set object (e.g., SELECT year WHERE quality_id = “Good”).
[0027] As an example, firstly, the aforementioned execution entity parses and extracts the corresponding field contract configuration and security isolation mapping relationship from the candidate data view set. Simultaneously, it extracts the corresponding intent query node set (e.g., the dimension node and metric node to be queried) from the structured intent object. Secondly, for each intent query node in the intent query node set, a traversal filtering process is performed: the business fields corresponding to the intent query node are matched with the field contract configuration. Upon successful matching, the intent query node is converted into an intermediate syntax node and pushed into the allocated instruction assembly buffer. Then, each valid intermediate syntax node in the instruction assembly buffer is structurally linked according to a preset intermediate security language topology framework to generate a query block that conforms to the syntax specification. Simultaneously, the aforementioned execution entity generates a view reference declaration based on the aforementioned security isolation mapping relationship. Finally, the aforementioned view reference declaration and query block are logically assembled and serialized to generate intermediate instructions, thus obtaining an intermediate instruction set.
[0028] Step 104: For each intermediate instruction in the intermediate instruction set, perform the following steps: Step 1041: In response to the successful validity check of the intermediate instruction, the field projection and pruning process is performed on the underlying physical data source based on the view reference declaration of the intermediate instruction to obtain the isolated sandbox environment.
[0029] In some embodiments, the execution entity may, in response to the successful validity verification of the intermediate instruction, perform field projection pruning on the underlying physical data source based on the view reference declaration of the intermediate instruction to obtain an isolated sandbox environment. The validity verification includes read-only attribute verification for the query block and field existence verification based on the field contract configuration. The read-only attribute verification may be a security audit logic embedded in the computer system, used to scan the instruction text for non-read-only permission operation keywords (e.g., "DROP", "DELETE", and "UPDATE"). For example, if a non-read-only permission operation keyword is detected in the query block, the read-only attribute verification fails. The field existence verification may be a whitelist matching mechanism that uses a pre-defined security list to match the fields in the query instruction. By comparing the field contract configuration, it can be verified whether each physical field involved in the current query request is within the authorized field whitelist. For example, if the query block includes "pdca_fishbone", but this field is not in the whitelist configured in the field contract, the verification fails.
[0030] In some optional implementations of certain embodiments, before the execution entity performs field projection pruning on the underlying physical data source based on the view reference declaration of the intermediate instructions, the following steps are further included: The first step, in response to the failure of the aforementioned intermediate instruction validity check, is to analyze the abnormal event that triggered the check failure and extract the abnormal context features. These abnormal context features include the physical column identifier of unauthorized access or the phantom field name that does not exist in the aforementioned field contract configuration. The failure of the aforementioned validity check could be due to the identification of the aforementioned read-only attribute check or the failure of the aforementioned field existence check. The aforementioned abnormal context features can refer to auxiliary information that can locate the error in instruction generation. These abnormal context features can be the specific reason for the check being blocked and the related data path. For example, the physical column identifier of unauthorized access, or a fictitious field name that does not exist due to the intent offset of the large language model. For example, if the system identifies "user_password" as an abnormal context feature, it indicates that the large language model has attempted unauthorized behavior. The aforementioned phantom field name can be a seemingly reasonable name fabricated by the artificial intelligence model when generating text, but which does not actually exist in the database. For example, the aforementioned phantom field name could be a "mobile_no" field that does not exist in the actual database but is inferred and output to the intermediate instruction by the model, even though only a column named "phone_number" exists in the real database.
[0031] The second step is to concatenate and inject the above-mentioned abnormal context features, structured intent objects, and field contract configurations into a preset error correction prompt template to generate targeted repair request prompts.
[0032] The third step is to send the aforementioned targeted repair request prompts to the deployed large language model for local error correction inference to obtain the corrected query block.
[0033] In practice, targeted repair request prompts can be sent to a pre-configured large language model service node via an API interface. Upon receiving the non-deterministic response text from the large language model, a structured parser (e.g., a pre-defined regular expression engine) deployed in memory is used to remove irrelevant redundant natural language characters from the non-deterministic response text, extracting instruction objects that conform to the pre-defined syntax rules, thus obtaining the correction query block.
[0034] The fourth step is to replace the original query block in the intermediate instruction with the modified query block and re-trigger the validity verification process until the verification passes or the preset maximum retry circuit breaker threshold is triggered.
[0035] In practice, the original query block can be replaced in memory using the corrected query block through memory pointer redirection or Abstract Syntax Tree (AST) node overwriting. Simultaneously, a retry counter is initialized in the cache, and it is incremented each time the validity check is retried, with the counter's value monitored in real time. When the retry counter reaches the preset maximum retry threshold (e.g., 3 consecutive retries), the current error correction retry loop is forcibly interrupted, the context object of the current report generation request is immediately destroyed from memory to release computing resources, and a "Smart Error Correction Failure" blocking alarm log is sent to the terminal display device.
[0036] In some optional implementations of certain embodiments, the execution entity may concatenate and inject the aforementioned abnormal context features, the aforementioned structured intent object, and the aforementioned field contract configuration into a preset error correction prompt template to generate a targeted repair request prompt, which may include the following steps: The first step is to perform error type identification processing on the above-mentioned abnormal context features to obtain the target abnormal type. The target abnormal type can be a classification identifier indicating that the large model's generated results deviate from expectations or violate physical security rules. For example, the target abnormal type could be "Unauthorized Field Access" or "Syntax Format Mismatch".
[0037] The second step involves determining the dynamic prompt word topology based on a pre-defined template library for the aforementioned target exception types. This dynamic prompt word topology can be a prompt word construction framework that dynamically adjusts the arrangement and logical relationships of its internal nodes according to different input conditions. For example, the dynamic prompt word topology could be a JSON-formatted prompt word template dynamically assembled by the system when dealing with "illusion field name" errors, consisting of three logical nodes: "Current Physical Table Structure Description," "Error Field Indication," and "Remapping Baseline Requirements."
[0038] The third step is to obtain the current available context window capacity of the large language model. In practice, this can be done by calling the application programming interface (API) of the large language model provider.
[0039] The fourth step involves performing dependency pruning and token truncation based on the currently available context window capacity. This pruning is applied to the structured intent object and the corresponding field contract configurations of the intermediate instructions, using an abstract syntax tree (AST) hierarchy, to obtain a context that meets the capacity limit. The AST-based dependency pruning can be a dimensionality reduction operation in a tree-like data structure, removing specific branches based on the logical relationships between nodes. For example, AST-based dependency pruning represents an optimization process that removes irrelevant logical nodes from the syntactic structure level to adapt to the context window capacity of a large language model without compromising the core query intent. Specifically, AST-based dependency pruning can include identifying and pruning clause (e.g., WHERE clause) nodes or JOIN table related nodes that are not directly related to the illusion fields, thereby compressing the number of tokens without compromising the core query intent.
[0040] Fifth, based on the above dynamic prompt word topology, placeholder replacement and serialization encapsulation are performed on the above target exception type, the above context and the preset abstract syntax tree output structure constraints to obtain the encapsulated data structure information.
[0041] In practice, the string interpolation algorithm is used to inject and replace the corresponding placeholders with the target exception type, the context and the preset abstract syntax tree output structure constraints. Then, the replaced content is serialized and encapsulated using a preset data exchange protocol (e.g., JSON serialization protocol) to obtain the encapsulated data structure information.
[0042] The sixth step involves performing large-scale instruction injection prevention escaping processing on the encapsulated data structure information to generate a targeted repair request prompt. This large-scale instruction injection prevention escaping processing can be a mechanism to re-encode special control characters in the input stream to prevent external input from altering the preset program's security logic. For example, this processing could involve Unicode encoding conversion of SQL control characters (e.g., single quotes, semicolons) or specific jailbreak prompts (e.g., "Ignore previous instructions") in the intent object.
[0043] Furthermore, during the execution of the aforementioned intermediate instructions, in response to abnormal events that trigger legality verification failures, the embodiments of this disclosure introduce a multi-dimensional security error correction and retry circuit breaker mechanism. Specifically, by extracting abnormal context features and employing a dynamic prompt word topology structure, repairs can be implemented for different illusion types of the large model, improving the accuracy of instruction error correction. In addition, by performing dependency pruning and token truncation processing on the structured intent object and field contract configuration based on the Abstract Syntax Tree (AST) level, the number of context tokens input to the large model is effectively compressed without destroying the core query intent, reducing the problem of large model context window capacity overflow from a physical perspective and reducing computational overhead. At the same time, the introduction of large model instruction anti-injection escaping processing and a preset maximum retry circuit breaker threshold reduces malicious SQL injection attacks or jailbreaking instructions, lowering the risk of the system falling into an infinite loop due to the large model repeatedly generating erroneous instructions.
[0044] In some optional implementations of certain embodiments, the execution entity may, in response to the successful validity verification of the intermediate instruction, perform field projection pruning on the underlying physical data source based on the view reference declaration of the intermediate instruction to obtain an isolated sandbox environment, which may include the following steps: The first step is to parse the aforementioned view reference declaration to obtain the underlying physical table name, the set of legal field contracts, and the preset simulated data rows. The set of legal field contracts represents the physical meaning of the set of data columns in the computer system that defines the security attributes of the data columns authorized for access in a specific query request. For example, the set of legal field contracts can be a JSON array or a configuration whitelist containing explicitly authorized field names such as ["core_summary", "monthly_trend"].
[0045] The second step involves obtaining the runtime mode instruction of the current report generation request and extracting contextual information from it to obtain the current user's organizational isolation identifier. The runtime mode instruction can be a system-level parameter that controls the boundaries of the program's runtime environment and the branching of execution logic. For example, it can be a configuration string dynamically passed in from the system request context, such as "Mock_Mode" or "Real_Mode". The organizational isolation identifier can be an attribute code used to distinguish the organizational hierarchy and data ownership boundaries of different users. For example, it can be a key-value pair feature parsed from the user's login token, such as "tenant_id=1001" or "dept_id=HR", used for lateral data interception.
[0046] The third step is to extract and process the simulated data rows in response to the above-mentioned operating mode instruction, and obtain the initial result dataset.
[0047] In practice, the preset simulated data rows are read and deserialized from a preloaded memory configuration table or a local static JSON file, and converted into a two-dimensional array to obtain the initial result dataset.
[0048] The fourth step involves retrieving the organization isolation identifier from the above-mentioned operating mode command (which is in real mode) and using it as a row-level data access credential. This row-level data access credential can be an access filter token appended to the underlying query condition clause during database retrieval. For example, it could be a logical code fragment such as "AND department_id = 'HR'" implicitly concatenated into the WHERE clause of the SQL query framework.
[0049] The fifth step is to inject the aforementioned row-level data access credentials into the underlying query framework corresponding to the aforementioned underlying physical table name to obtain the target query statement.
[0050] In practice, the Abstract Syntax Tree (AST) rewriting technique can be used to locate the WHERE clause node corresponding to the basic query framework, and the above row-level data access credentials can be attached to the WHERE clause node to obtain the target query statement.
[0051] Step 6: Based on the target query statement, perform controlled reading processing on the underlying physical data source to obtain the initial result dataset. This initial result dataset can be the raw data blocks initially extracted and returned from the data source. These raw data blocks have undergone row-level filtering but have not undergone memory-level column pruning or format mapping. For example, the initial result dataset can be a two-dimensional ResultSet object returned by the relational database driver layer.
[0052] Step 7: Based on the aforementioned legal field contract set, perform column-level culling and field projection processing on the initial result dataset to obtain a standardized data snapshot. This standardized data snapshot can be a static, non-writable data object generated according to a uniform format. Alternatively, it can be obtained after performing memory-level safe cleaning and pointer reconfiguration on the data state at a specific time point. For example, it can be a read-only CSV file stream generated after physically destroying unauthorized column addresses.
[0053] Step 8: Instantiate an independent in-memory database engine in the allocated memory of the computing device, and perform a full load of the standardized data snapshot and disconnect the network connection to obtain an isolated sandbox environment. The aforementioned in-memory database engine can be a database engine that resides entirely in the main memory of the computing device, enabling high-speed retrieval and computation, and releasing storage space at the end of the process's lifecycle. For example, the aforementioned in-memory database engine can be a SQLite in-memory mode engine temporarily instantiated in an independent process space (started using the ":memory:" flag).
[0054] In practice, the standardized data snapshots mentioned above can be fully loaded by executing the bulk insert command of the in-memory database. Then, by calling the operating system's underlying network namespace isolation command, network connectivity can be severed, resulting in an isolated sandbox environment.
[0055] In some optional implementations of certain embodiments, the execution entity may perform column-level culling and field projection processing on the initial result dataset based on the aforementioned legal field contract set to obtain a standardized data snapshot, which may include the following steps: The first step involves performing attribute traversal and comparison processing on the aforementioned legal field contract set based on the column characteristics in the initial result dataset, thereby obtaining the set of unauthorized physical column identifiers. This set of unauthorized physical column identifiers can be a collection of sensitive field indexes or names, used to characterize fields in the data extraction results that do not conform to the current system security baseline or permission authorization whitelist. For example, the set of unauthorized physical column identifiers can be an array of strings representing sensitive underlying physical column labels such as "user_password_hash" and "id_card_num" output after attribute comparison failure.
[0056] The second step involves performing memory address mapping on the initial result dataset based on the aforementioned set of unauthorized physical column identifiers, to obtain the target storage block corresponding to the unauthorized field. This target storage block can be one or more physically contiguous or non-contiguous memory address spaces allocated from the computer's main memory to the initial result dataset. For example, the target storage block could be a data cache segment in a memory register with memory address space from 0x00A1 to 0x00B5.
[0057] The third step involves data destruction and address reclamation of the target storage blocks to obtain a cleaned dataset that blocks the physical penetration path of sensitive fields at the underlying level. This cleaned dataset can serve as a phased security data carrier, representing the security results after physical-level data erasure and memory pointer severing of the target memory blocks. For example, the cleaned dataset could be a structure object resulting from the system memory performing a zero-out (overwrite zero values) operation to erase sensitive data blocks.
[0058] The fourth step involves performing memory pointer reorganization and projection aggregation on the cleaned dataset to obtain a standardized data snapshot. The memory pointer reorganization process can involve rearranging physical memory address pointers, making the index continuous, and recalibrating the relative memory offset. For example, after removing unauthorized physical columns (e.g., password hashes), the memory pointer reorganization process can write the remaining valid column data pointers sequentially into a newly allocated contiguous memory control block to establish a new columnar index. The projection aggregation process can involve streaming the valid column data in memory, stripping write permission pointers, and mapping them to a specific static, read-only target data view object. For example, the projection aggregation process can involve instantiating the reorganized valid memory blocks into read-only structures using a data view configuration protocol.
[0059] In some optional implementations of certain embodiments, the execution entity may instantiate an independent in-memory database engine in the allocated memory of the computing device, and perform a full load of the standardized data snapshot and disconnect the network connection to obtain an isolated sandbox environment. This may include the following steps: The first step involves initializing the aforementioned in-memory database engine within the allocated memory of the computing device, resulting in a pre-allocated memory sandbox container. This memory sandbox container can be a restricted virtual execution environment, representing a resource isolation boundary allocated at the operating system level through resource constraints and isolation techniques, cutting off external disk mapping and network communication. For example, the memory sandbox container could be an independent Docker container instance process that has its bridge network association mechanism disconnected and lacks host directory mounting permissions (No Volume Mounts).
[0060] The second step is to write the standardized data snapshot to the memory sandbox container to obtain an instantiated data table.
[0061] As an example, firstly, a normalized data snapshot (e.g., a read-only CSV byte stream) can be pushed into the physical memory of a memory sandbox container via memory pipe communication. Next, the DDL parsing module of the in-memory database engine is invoked to automatically compile and execute table creation instructions (e.g., CREATE TABLE). Then, a batch load command flushes the data into memory pages, generating an instantiated data table that is no longer on disk.
[0062] The third step is to intercept and disconnect the external communication ports of the aforementioned memory sandbox container to obtain a network-isolated operating environment.
[0063] As an example, firstly, a network link suspension command (e.g., "ip link set dev veth_sandbox down") can be issued to the kernel via a network namespace resource configuration handle to physically disable the virtual network interface card bound to the memory sandbox container. Then, using kernel firewall management components (e.g., iptables or nftables), port blocking policies can be dynamically injected (e.g., dropping inbound and outbound TCP / UDP packets pointing to the container's IP and port) to physically isolate the communication path from the network control plane, thus obtaining a network-layer isolated runtime environment.
[0064] Fourth, based on the network-layer isolated operating environment described above, the write channel of the underlying transaction log mode of the aforementioned in-memory database engine is closed, resulting in a unidirectional computation engine. This unidirectional computation engine can be a one-way computation module, supporting both inward data reading and computation and outward unidirectional output of query results. For example, this unidirectional computation engine can be used for a specific database read-only query process that has forcibly disabled the WAL (Write-Ahead Logging) mechanism and refuses to respond to any Update / Insert operation commands.
[0065] The fifth step involves forcibly locking the access control interface of the aforementioned unidirectional computing engine to a read-only state, thus creating an isolated sandbox environment. In practice, this can be achieved by forcibly setting a read-only transaction attribute at the connection layer (e.g., "setReadOnly(true)"). At the permission layer, all DML write permissions for the user are revoked (e.g., "REVOKE INSERT", "UPDATE", "DELETE"), resulting in the isolated sandbox environment.
[0066] Step 1042: Based on the isolated sandbox environment and organization isolation field, the query block corresponding to the intermediate instruction is processed for read-only mode to obtain the structured query result.
[0067] In some embodiments, the execution entity can perform read-only processing on the query block corresponding to the intermediate instruction based on the isolated sandbox environment and the organizational isolation field to obtain a structured query result. The organizational isolation field can be an attribute declaration used to define the current user data access permissions and the physical data isolation boundary. For example, in a report generation scenario, the organizational isolation field can be a tenant identifier or a security context configuration key-value pair at the department level. The structured query result represents the physical meaning of encapsulating the underlying fragmented two-dimensional data matrix and converting it into a standard structured object that the front-end rendering module can directly parse and draw. For example, the structured query result can be a report DSL (Domain Specific Language) JSON format file that meets the rendering requirements of the front-end chart component.
[0068] In some optional implementations of certain embodiments, the execution entity may, based on the aforementioned isolated sandbox environment and the aforementioned organization isolation field, perform read-only processing on the query block corresponding to the aforementioned intermediate instruction to obtain structured query results, which may include the following steps: The first step is to parse the organization isolation field based on the current request context to obtain the target organization identifier for the current requesting user. This target organization identifier can be a unique coded identifier that identifies the current user's permission group and can be used for database column-level permission control. For example, the target organization identifier can be a string like "tenant_id = 'T10086' AND department = 'Sales'" used for organization scope filtering.
[0069] The second step involves parsing the query blocks corresponding to the intermediate instructions to construct the corresponding abstract syntax tree. This abstract syntax tree is a hierarchical tree-like data structure mapped into memory after lexical and syntactic analysis of the text query statement. For example, the abstract syntax tree could be a memory object tree containing nodes, operators, and clause branches generated after parsing the "SELECT" query block.
[0070] The third step is to identify the conditional filter nodes in the abstract syntax tree. These conditional filter nodes can be tree-level target pointer nodes used to carry out data row filtering and control logic branches. In practice, a degree-first search algorithm can be used to recursively scan all branch nodes in the abstract syntax tree. By comparing the syntax type identifiers (Token Type) of each node, the conditional filter nodes of type conditional statements (e.g., WhereClause nodes or Filter nodes) can be identified.
[0071] The fourth step involves using the target organization identifier as a mandatory filtering condition for row-level data, and dynamically injecting and rewriting the filtering nodes to obtain a reconstructed query block. This reconstructed query block can be a sequence of logical instructions used to force unauthorized access and prevent unauthorized access. For example, the reconstructed query block can be a new SQL query text generated in reverse after appending the target organization identifier constraint to the WHERE node branch of the AST.
[0072] Fifth, based on the reconstructed query block, the loaded memory data is read and processed in a controlled manner within the isolated sandbox environment to obtain structured query results.
[0073] In practice, firstly, the reconstructed query block can be pushed down to the in-memory database engine by isolating the read-only communication handle within the sandbox. Then, the engine executes instructions in memory to retrieve, filter, and aggregate standardized data snapshots, outputting the resulting data stream to the cursor buffer to obtain the target dataset. Finally, the report semantic layer transformation logic is invoked to encapsulate the dataset into a JSON structure according to the rendering contract, yielding structured query results.
[0074] In some optional implementations of certain embodiments, the execution entity may, based on the reconstructed query block, perform controlled reading of the loaded memory data in the isolated sandbox environment to obtain structured query results, which may include the following steps: The first step involves performing execution intent verification on the reconstructed query block before execution to obtain the characteristics of any violations. This execution intent verification can be a process of performing a security assessment on the code instruction stream to determine whether it contains any physically destructive intent beyond the scope of data presentation. For example, this execution intent verification can be a process of intercepting controlled SQL executions that contain high-risk DML / DDL operators such as "DELETE," "UPDATE," and "DROP" in the AST.
[0075] Optionally, in response to the aforementioned execution entity detecting the aforementioned characteristics of the violation instruction (i.e., the intent verification fails and a security threshold is triggered), the aforementioned execution entity forcibly blocks the execution link of the current reconstructed query block, intercepts the database I / O request, and routes it to the exception handling node to perform the actions of issuing a security alarm and returning a "query privilege violation" prompt message, thereby physically cutting off the potential data pollution path.
[0076] The second step involves allocating a data cursor with read-only constraints within the isolated sandbox environment, in response to the aforementioned reconstructed query block passing the execution intent verification process. This data cursor is a memory pointer object that represents a system that provides only a streaming read interface in memory or the database connection pool, forcibly shielding the reverse write channel from the hardware and driver levels. For example, this data cursor can be a database cursor instance configured with a read-only transaction isolation level.
[0077] The third step is to execute the reconstructed query block using the aforementioned data cursor to obtain the target dataset.
[0078] The fourth step involves serializing and encapsulating the target dataset based on a predefined report rendering contract format to obtain structured query results. This report rendering contract format can be a predefined protocol specification between the backend and frontend display components, ensuring that data can be deterministically converted into visual graphics. For example, the report rendering contract format could be a standard template for a report DSL (Domain Specific Language) that includes a dataset, dimension mapping, and chart type set.
[0079] Step 105: Perform visualization block transformation on the obtained structured query results to obtain a report, and send the report to the terminal display device for display after graphic rendering.
[0080] In some embodiments, the aforementioned execution entity can transform the obtained structured query results into visualization blocks to obtain a report, and then send the report to a terminal display device for display after graphical rendering. The visualization blocks can be chart component containers, used to bind logical data with specific graphical components in the front-end memory. For example, the visualization blocks can be bound to bar charts or line charts, and Canvas instances filled with business data. The report can be a composite digital page object, used to combine multiple visualization blocks according to a specific layout protocol to intuitively display multi-dimensional business data analysis results to the end user. The terminal display device can be a physical hardware device with graphical user interface rendering capabilities. For example, the terminal display device can be a smartphone screen or PC monitor used by business personnel.
[0081] As an example, firstly, for each structured query result, the corresponding target chart type features (e.g., pie chart, scatter plot, etc.) and multidimensional data sequences are extracted. Secondly, based on the aforementioned target chart type features, the corresponding target rendering template is called from a preset graphics component library, and the multidimensional data sequences are injected into the configuration location of the target rendering template to generate the corresponding visualization blocks. Then, a preset report layout protocol (e.g., CSS Grid layout parameters) is obtained, and based on the report layout protocol, the obtained visualization blocks are mapped and combined using a grid layout to generate a report. Next, the report is converted into a graphics drawing instruction stream that the front-end rendering engine can recognize, and sent to the terminal display device through a network communication interface to instruct the terminal display device to call the local rendering engine to perform graphics rendering processing and display the aforementioned report.
[0082] Optionally, during the execution of graphics rendering or command sending, the aforementioned execution entity can also monitor the rendering status of the front-end components and the response status of the communication link in real time. In response to triggering a preset rendering circuit breaker threshold (e.g., component loading failure or rendering timeout), the current visualization rendering link is blocked, the data table in plain text format is degraded to be output to the terminal display device, and a graphics reload prompt message is sent.
[0083] The above-described embodiments of this disclosure have the following beneficial effects: The report generation method based on intermediate instruction sets and security isolation layers in some embodiments of this disclosure achieves physical data isolation and fine-grained instruction access control, reducing the risk of unauthorized access and data tampering caused by abnormal instructions, and improving data security and operational stability during report generation. Specifically, the reasons for unauthorized data access and instruction execution errors are: large language models have non-deterministic characteristics when generating query statements, easily generating fields that do not exist in the database (data illusion), or generating non-standard instructions with data modification intentions. Directly applying the generated query instructions to the physical data source (database) easily increases the risk of exposing underlying sensitive data. Based on this, the report generation method based on intermediate instruction sets and security isolation layers in some embodiments of this disclosure first performs semantic parsing processing on the received natural language report request to obtain a structured intent object. Thus, the unstructured user language is transformed into a standardized data structure that can be processed by a computer, providing a clear intent basis for subsequent matching of the underlying business data source. Secondly, based on the pre-defined business data semantic layer mapping table, the structured intent objects are subjected to relational query processing to obtain a candidate data view set, which includes field contract configurations and organization isolation fields. This constructs a business semantic defense line above the physical data tables, pre-determining the allowed column-level data boundaries (field contracts) and row-level data ranges (organization isolation fields) for this query, thereby controlling the exposure of sensitive information. Next, based on the candidate data view set, the structured intent objects are subjected to instruction structure assembly processing to obtain an intermediate instruction set, which includes view reference declarations and query blocks restricted by the field contract configurations. This constrains the model's output within a predefined canonical structure, replacing the exposure of physical tables with "view references" and limiting the scope of "query blocks" to allowed fields, effectively reducing the execution risks caused by illegal SQL injection and data illusion. Then, for each intermediate instruction in the aforementioned intermediate instruction set, the following steps are performed: In response to the passing of the intermediate instruction's validity check, based on the view reference declaration of the intermediate instruction, field projection pruning is performed on the underlying physical data source to obtain an isolated sandbox environment. The validity check includes read-only attribute verification for the query block and field existence verification based on the field contract configuration. Thus, interception is performed before instruction execution, eliminating abnormal instructions with modification intent and phantom fields. Simultaneously, the data of the required fields is projected into memory to construct an independent sandbox, physically preventing the impact of illegal instructions on the database. Based on the isolated sandbox environment and the aforementioned organizational isolation fields, the query block corresponding to the intermediate instruction is processed into read-only mode to obtain structured query results.Therefore, by executing query operations in a secure, isolated in-memory computing environment and implementing row-level data filtering using organizational isolation fields, user data access boundaries are restricted, preventing unauthorized data reading or tampering across organizations. Finally, the obtained structured query results are transformed into visual blocks to generate reports, which are then rendered graphically and sent to the terminal display device for display. This process converts legitimate data, after strict security verification and access control, into visual charts, providing users with an intuitive understanding of the results.
[0084] Based on the same inventive concept, embodiments of this application provide a report generation apparatus based on an intermediate instruction set and a security isolation layer, comprising: The acquisition module is used to acquire natural language report requirements; The memory is used to store a program for a report generation method based on an intermediate instruction set and a security isolation layer; The processor can load and execute programs in memory, and implement a report generation method based on an intermediate instruction set and a security isolation layer.
[0085] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0086] This application provides a computer-readable storage medium storing a computer program that can be loaded and executed by a processor, which is a report generation method based on an intermediate instruction set and a security isolation layer.
[0087] Computer storage media include, for example, USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media that can store program code.
[0088] Based on the same inventive concept, embodiments of this application provide a smart terminal, including a memory and a processor. The memory stores a computer program that can be loaded and executed by the processor, which is a report generation method based on an intermediate instruction set and a security isolation layer.
[0089] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0090] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.
Claims
1. A report generation method based on an intermediate instruction set and a security isolation layer, characterized in that, include: The received natural language report requests are semantically parsed to obtain a structured intent object; Based on the preset business data semantic layer mapping table, the structured intent object is subjected to association query processing to obtain a candidate data view set, wherein the candidate data view set includes: field contract configuration and organization isolation field. The field contract configuration is a legal boundary of the underlying physical column that is explicitly allowed to be accessed by the current query request. The organization isolation field is a horizontal unauthorized isolation attribute column used to implement row-level data security access control. Based on the candidate data view set, the structured intent object is subjected to instruction structure assembly processing to obtain an intermediate instruction set, wherein the intermediate instructions include view reference declarations and query blocks restricted by the field contract configuration; For each intermediate instruction in the intermediate instruction set, perform the following steps: In response to the intermediate instruction's validity verification passing, based on the view reference declaration of the intermediate instruction, field projection pruning is performed on the underlying physical data source to obtain an isolated sandbox environment. The validity verification includes read-only attribute verification for the query block and field existence verification based on the field contract configuration. The step of performing field projection pruning on the underlying physical data source based on the view reference declaration of the intermediate instruction to obtain the isolated sandbox environment in response to the intermediate instruction's validity verification passing includes: The view reference declaration is parsed to obtain the underlying physical table name, the legal field contract set, and the preset simulated data row; Obtain the running mode instruction of the current report generation request, and extract the context environment information of the current report generation request to obtain the organization isolation identifier of the current user; In response to the running mode instruction being set to simulation mode, the simulation data rows are extracted and processed to obtain an initial result dataset; In response to the operating mode instruction being in real mode, the organization isolation identifier is extracted as a row-level data access credential. The row-level data access credentials are injected into the basic query framework corresponding to the underlying physical table name to obtain the target query statement; Based on the target query statement, the underlying physical data source is subjected to controlled reading processing to obtain an initial result dataset; Based on the legal field contract set, column-level culling and field projection processing are performed on the initial result dataset to obtain a standardized data snapshot. The step of performing column-level culling and field projection processing on the initial result dataset based on the legal field contract set to obtain a standardized data snapshot includes: Based on the column features in the initial result dataset, attribute traversal and comparison processing is performed on the legal field contract set to obtain the set of unauthorized physical column identifiers; Based on the set of unauthorized physical column identifiers, the initial result dataset is processed by memory address mapping to obtain the target storage block corresponding to the unauthorized field; Data destruction and address reclamation are performed on the target storage block to obtain a cleaned dataset that blocks the physical penetration path of sensitive fields at the underlying level; The cleaned dataset is subjected to memory pointer reorganization and projection aggregation to obtain a standardized data snapshot; An independent in-memory database engine is instantiated in the allocated memory of the computing device, and the standardized data snapshot is fully loaded and the network connection is cut off to obtain an isolated sandbox environment. Based on the isolated sandbox environment and the organization isolation field, the query block corresponding to the intermediate instruction is processed in read-only mode to obtain the structured query result; The obtained structured query results are transformed into visual blocks to obtain a report, and the report is sent to the terminal display device for display after being processed by graphics rendering.
2. The report generation method based on an intermediate instruction set and a security isolation layer according to claim 1, characterized in that, Before performing field projection pruning on the underlying physical data source based on the view reference declaration of the intermediate instruction, the following is also included: In response to the failure of the intermediate instruction validity check, the abnormal event that triggered the check failure is parsed and the abnormal context features are extracted. The abnormal context features include the physical column identifier of the unauthorized access or the phantom field name that does not exist in the field contract configuration. The abnormal context features, the structured intent object, and the field contract configuration are concatenated and injected into a preset error correction prompt word template to generate a targeted repair request prompt word; The targeted repair request prompt is sent to the deployed large language model for local error correction inference to obtain the corrected query block; The original query block in the intermediate instruction is replaced by the corrected query block, and the validity verification process is retried until the verification passes or the preset maximum retry circuit breaker threshold is triggered.
3. The report generation method based on an intermediate instruction set and a security isolation layer according to claim 2, characterized in that, The step of concatenating and injecting the abnormal context features, the structured intent object, and the field contract configuration into a preset error correction prompt template to generate a targeted repair request prompt includes: The abnormal context features are subjected to error type identification processing to obtain the target abnormal type; Based on a preset template library, the dynamic prompt word topology structure of the target anomaly type is determined; Obtain the current available context window capacity of the large language model; Based on the current available context window capacity, dependency pruning and tag truncation are performed on the field contract configurations corresponding to the structured intent object and the intermediate instruction, based on the abstract syntax tree level, to obtain a context that meets the capacity limit. Based on the dynamic prompt word topology, the target exception type, the context, and the preset abstract syntax tree output structure constraints are replaced with placeholders and serialized to encapsulate the data structure information. The encapsulated data structure information is subjected to large model instruction injection prevention escaping processing to generate targeted repair request prompts.
4. The report generation method based on an intermediate instruction set and a security isolation layer according to claim 1, characterized in that, The steps of instantiating an independent in-memory database engine in the allocated memory of the computing device, and performing a full load of the standardized data snapshot and disconnecting the network connection to obtain an isolated sandbox environment include: In the allocated memory of the computing device, the memory database engine is initialized to obtain a pre-allocated memory sandbox container. The standardized data snapshot is written to the memory sandbox container to obtain an instantiated data table. The external communication ports of the memory sandbox container are intercepted and disconnected to obtain a network-layer isolated operating environment; Based on the network layer isolated operating environment, the write channel of the underlying transaction log mode of the memory database engine is closed to obtain a unidirectional computing engine. The access control interface of the unidirectional computing engine is forced to be locked in a read-only state to obtain an isolated sandbox environment.
5. The report generation method based on an intermediate instruction set and a security isolation layer according to claim 1, characterized in that, The step of performing read-only processing on the query block corresponding to the intermediate instruction based on the isolated sandbox environment and the organization isolation field to obtain the structured query result includes: Based on the current request context, the organization isolation field is parsed to obtain the target organization identifier of the current requesting user; The query block corresponding to the intermediate instruction is parsed to construct the corresponding abstract syntax tree; Determine the conditional filter nodes in the abstract syntax tree; The target organization identifier is used as a row-level data forced filtering condition, and the condition filtering node is dynamically injected and rewritten to obtain a reconstructed query block. Based on the reconstructed query block, the loaded memory data is processed in a controlled manner in the isolated sandbox environment to obtain structured query results.
6. The report generation method based on an intermediate instruction set and a security isolation layer according to claim 5, characterized in that, The step of performing controlled reading processing of the loaded memory data in the isolated sandbox environment based on the reconstructed query block to obtain structured query results includes: In response to performing execution intent verification on the reconstructed query block before execution, the characteristics of the illegal instruction are obtained; In response to the reconstructed query block passing the execution intent verification process, a data cursor with read-only constraint attributes is allocated in the isolated sandbox environment; The target dataset is obtained by executing the reconstructed query block using the data cursor. Based on the preset report rendering contract format, the target dataset is serialized and encapsulated to obtain structured query results.
7. A report generation device based on an intermediate instruction set and a security isolation layer, characterized in that, include: The acquisition module is used to acquire natural language report requirements; A memory for storing a program for a report generation method based on an intermediate instruction set and a security isolation layer as described in any one of claims 1 to 6; The processor and the program in the memory can be loaded and executed by the processor to implement the report generation method based on an intermediate instruction set and a security isolation layer as described in any one of claims 1 to 6.
Citation Information
Patent Citations
Low-code application logic generation method and system based on large language model
CN121858094A
Dynamic sandbox data analysis method and system based on large language model
CN122197000A