Government affair data processing method, device, equipment, medium and product

Abstract

The invention discloses a government affair data processing method and device, equipment, a medium and a product, and relates to the field of data processing.The method comprises the steps that a government affair data asset directory and a data consanguinity map are obtained; according to the government affair data asset directory, the data consanguinity map and a preset policy file library, a domain knowledge base is determined, and the domain knowledge base comprises the incidence relation between government affair data and policies; determining a user demand based on the domain knowledge base and a preset large language model; generating a structured scene solution based on a preset large language model and a user demand; and generating an application prototype according to the structured scene solution. The technical problem that government affair data and policies cannot be flexibly fused in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a method, apparatus, equipment, medium, and product for processing government data. Background Technology

[0002] With the deepening of digital government construction, government departments at all levels have accumulated massive amounts of government data. This data is a core asset for promoting scientific government decision-making, precise social governance, and efficient public services. However, existing technological solutions face the following technical challenges in fully utilizing these data assets for application innovation and service optimization: Existing technologies typically separate data management platforms from policy research. When developers devise application scenarios, they struggle to quickly and comprehensively grasp all relevant policies and regulations, leading to application innovation often lagging behind policy requirements and potentially even crossing compliance red lines. Furthermore, the lack of machine-understandable semantic connections between data asset catalogs and policy documents fails to provide automated compliance guidance for innovation.

[0003] In summary, existing technologies have technical problems that prevent the flexible integration and processing of government data and policies. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, equipment, medium, and product for processing government data, which can solve the technical problem in the prior art that government data and policies cannot be flexibly integrated and processed.

[0005] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a method for processing government data, including: Obtain the catalog of government data assets and data lineage maps; Based on the government data asset catalog, data lineage map, and pre-set policy document library, a domain knowledge base is determined, which includes the relationship between government data and policies; Based on the domain knowledge base and the pre-set large language model, user needs are determined; Based on a pre-defined large language model and user needs, generate structured scenario solutions; Based on the structured scenario solution, generate an application prototype.

[0006] Optionally, a domain knowledge base is determined based on the government data asset catalog, data lineage graph, and a pre-set policy document library. Specifically, this includes: determining a data link diagram based on the government data asset catalog and data lineage graph, wherein the data link diagram is used to represent the relationships between government data; performing natural language processing on policy documents in the pre-set policy document library to obtain policy elements; and determining the domain knowledge base based on the data link diagram and policy elements.

[0007] Optionally, a data link diagram is determined based on the government data asset catalog and data lineage graph. Specifically, this includes: parsing the government data asset catalog using a preset parsing strategy to obtain table feature data for multiple data tables, wherein the table feature data includes the business meaning of multiple data tables, the field definitions of multiple data tables, and the relationships between multiple data tables; and determining the data link diagram based on the table feature data and data lineage graph.

[0008] Optionally, user needs are determined based on a domain knowledge base and a pre-defined large language model, specifically including: receiving the user's initial scenario needs through a human-computer interaction interface; generating requirement questions based on the domain knowledge base and initial scenario needs through a large language model; receiving the user's response data to the requirement questions through a human-computer interaction interface; and determining user needs based on the initial scenario needs and response data.

[0009] Optionally, based on a pre-defined large language model and user needs, a structured scenario solution is generated, specifically including: generating solution advantages, data sources, data flow paths, application logic descriptions, and interface interaction designs based on the pre-defined large language model and user needs; and determining the structured scenario solution based on the solution advantages, data sources, data flow paths, application logic descriptions, and interface interaction designs.

[0010] Optionally, based on the structured scenario solution, an application prototype is generated, specifically including: calling a preset code generation model to generate program source code based on the structured scenario solution; calling a preset compliance rule verification engine to perform abstract syntax tree parsing on the program source code and extract the data operation logic and interface call chain in the code; comparing the data operation logic and interface call chain with the compliance constraints in the domain knowledge base; if the comparison passes, an application prototype is generated based on the program source code; if the comparison fails, a correction instruction is generated and fed back to the preset code generation model. The generated application prototype is deployed on a shared platform and has a unique access path.

[0011] Secondly, this application provides a government data processing device, comprising: The acquisition module is used to acquire the catalog of government data assets and the data lineage map; The first determination module is used to determine the domain knowledge base based on the government data asset catalog, data lineage map and preset policy document library. The domain knowledge base includes the relationship between government data and policies. The second determination module is used to determine user needs based on the domain knowledge base and the preset large language model. The first generation module is used to generate structured scenario solutions based on a pre-set large language model and user needs; The second generation module is used to generate application prototypes based on the structured scenario solution.

[0012] As an optional implementation, the first determining module is further configured to: determine a data link diagram based on the government data asset catalog and data lineage map, wherein the data link diagram is used to represent the relationships between government data; perform natural language processing on policy documents in the preset policy document library to obtain policy elements; and determine a domain knowledge base based on the data link diagram and policy elements.

[0013] As an optional implementation, the first determining module is further configured to: parse the government data asset catalog using a preset parsing strategy to obtain table feature data of multiple data tables, wherein the table feature data includes the business meaning of multiple data tables, the field definitions of multiple data tables, and the relationship between multiple data tables; and determine the data link diagram based on the table feature data and the data lineage graph.

[0014] As an optional implementation, the second determining module is further configured to: receive the user's initial scenario requirements through a human-computer interaction interface; generate requirement questions based on the domain knowledge base and the initial scenario requirements using a large language model; receive the user's response data to the requirement questions through the human-computer interaction interface; and determine the user's requirements based on the initial scenario requirements and the response data.

[0015] As an optional implementation, the first generation module is also used to: generate the advantages of the solution, data sources, data flow paths, application logic descriptions, and interface interaction designs based on a preset large language model and user needs; and determine the structured scenario solution based on the advantages of the solution, data sources, data flow paths, application logic descriptions, and interface interaction designs.

[0016] As an optional implementation, the second generation module is also used to: call a preset code generation model to generate program source code based on a structured scenario solution; call a preset compliance rule verification engine to perform abstract syntax tree parsing on the program source code and extract data operation logic and interface call chains from the code; compare the data operation logic and interface call chains with compliance constraints in the domain knowledge base; if the comparison passes, generate an application prototype based on the program source code; if the comparison fails, generate correction instructions and feed them back to the preset code generation model. The generated application prototype is deployed on a shared platform and has a unique access path.

[0017] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the government data processing method described in any one of the above.

[0018] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the government data processing method described in any one of the above descriptions.

[0019] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the government data processing method described in any one of the above-mentioned methods.

[0020] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides a method, apparatus, equipment, medium, and product for processing government data. The method includes acquiring a government data asset catalog and a data lineage graph; determining a domain knowledge base based on the government data asset catalog, data lineage graph, and a preset policy document library, wherein the domain knowledge base includes the relationships between government data and policies; determining user needs based on the domain knowledge base and a preset large language model; generating a structured scenario solution based on the preset large language model and user needs; and generating an application prototype based on the structured scenario solution. The above steps first construct a domain knowledge base based on government data, a data lineage graph, and a preset policy document library to achieve data fusion; then, using a large language model based on the domain knowledge base to determine user needs; and finally, constructing an application prototype based on user needs to rationally utilize the fused data. This solves the technical problem in existing technologies where government data and policies cannot be flexibly fused and processed, achieving the technical effect of flexible fusion and rational utilization of government data and policies. Attached Figure Description

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

[0022] Figure 1 This is a diagram illustrating the application environment of a government data processing method according to an embodiment of this application. Figure 2 A flowchart illustrating a government data processing method according to an embodiment of this application; Figure 3 A schematic diagram of the structure of a government data processing device provided in one embodiment of this application; Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0025] The government data processing method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be set up independently, integrated into server 104, or placed in the cloud or on other servers. Terminal 102 can send a government data asset catalog and data lineage graph to server 104. After receiving the government data asset catalog and data lineage graph, server 104, based on the government data asset catalog, data lineage graph, and a preset policy document library, determines a domain knowledge base, which includes the relationships between government data and policies; based on the domain knowledge base and a preset large language model, it determines user requirements, which are natural language requirements; based on the preset large language model and user requirements, it generates a structured scenario solution; and based on the structured scenario solution, it generates an application prototype. Server 104 can then feed back the obtained application prototype to terminal 102. In addition, in some embodiments, the government data processing method can also be implemented by the server 104 or the terminal 102 separately. For example, the terminal 102 can directly process the government data asset catalog and data lineage map, or the server 104 can obtain the government data asset catalog and data lineage map from the data storage system and process them.

[0026] The terminal 102 can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The server 104 can be implemented using a standalone server or a server cluster composed of multiple servers, or it can be a cloud server.

[0027] In one exemplary embodiment, such as Figure 2As shown, a method for processing government data is provided. This method is executed by a computer device, specifically a terminal or server, or both. In this embodiment, the method is applied to... Figure 1 Taking server 104 as an example, the explanation includes the following steps 201 to 205. Wherein: Step S201: Obtain the government data asset catalog and data lineage map.

[0028] In this embodiment, the government data asset catalog is a dynamic ledger formed by the government after registering, classifying, and coding shareable, open, and controllable data according to unified metadata specifications. This transforms dormant data into searchable, authorizable, and auditable assets, enabling precise cross-departmental sharing, orderly social access, and end-to-end security control. The data lineage graph is a "data family tree" that uses a directed graph to completely record the entire lifecycle of government data from its generation, processing, flow, to its eventual disappearance. Each extraction, cleaning, merging, and transformation is marked as a traceable node and edge, allowing any field to be instantly traced back to its origin, process, transformation, and usage. This provides a comprehensive navigation for data quality accountability, impact analysis, compliance auditing, and asset valuation.

[0029] In step S201, the server can obtain the government data asset catalog and data lineage map from the data interaction interface of the client or data storage system. The catalog is aligned with the lineage primary key and can use "system + table + field" as a composite key to facilitate the fusion and splicing in subsequent steps. Here, the lineage primary key refers to the core identifier field in the data lineage map used to track data lineage relationships. For example, in the municipal household registration-social security data link, the lineage primary key is the ID card number; the link can be: ID card number in the upstream population information table → ID card number in the transit node (government data platform) → ID card number in the downstream social security payment table.

[0030] Optionally, the obtained government data asset catalog may include a standardized catalog package: a unified CSV / JSON format containing required fields such as "catalog code, name, responsible department, sharing type, security level, and update cycle". The obtained data lineage map may include a standardized lineage package: a triple <source table.field, relation type, target table.field>, along with a conversion function, timestamp, and job name.

[0031] For example, the government data asset catalog is structured data, with a minimum set of fields including catalog code, catalog name, responsible department, sharing type, openness type, security level, update cycle, dataset, information item name, data type, and dictionary code. The format is CSV / JSON, and each record corresponds to "one catalog + one information item".

[0032] For example, the data lineage graph is semi-structured data. The minimum set of fields includes source system, source table, source field, target system, target table, target field, transformation function, job name, and execution time. The format is a triple <source table.field, relation type, target table.field>.

[0033] Step S202: Determine the domain knowledge base based on the government data asset catalog, data lineage map, and preset policy document library. The domain knowledge base includes the relationship between government data and policies.

[0034] For example, the policy document repository is pre-defined as unstructured data, including laws (Data Security Law, Personal Information Protection Law), administrative regulations (Interim Measures for Sharing Government Information Resources), departmental rules, local regulations, and standards and specifications. The formats are a mix of PDF, Word, and HTML.

[0035] In this embodiment of the invention, the "Dataset (a collection of government data corresponding to a government scenario) - Information Item - Security Level / Sharing Type" in the government data asset catalog is used as the anchor point to comprehensively connect the field-level impact scope along the upstream and downstream relationships of the data lineage graph. A dataset consists of several business-related information items, which are the basic, indivisible data units that constitute the dataset. For example, a dataset is a municipal-level household registration population basic information dataset, which includes the following information items: ID number, name, gender, date of birth, registered address, ethnicity, and household registration type.

[0036] By leveraging a large language model to extract key elements such as policy themes, applicable conditions, incentive directions, and compliance requirements from a policy document repository, and after entity linking, path propagation, and conflict disambiguation, the corresponding directory codes, clause numbers, and sharing / security actions for each policy theme can be obtained. This "directory code ↔ clause number ↔ sharing / security action" structure is solidified into a domain knowledge base that can be queried in real time, tracked back to previous versions, and automatically alerted. Based on this domain knowledge base, compliance issues such as "which regulation a certain field is bound by, what conditions must be met for sharing, and whether its downstream derived tables synchronously inherit higher security levels" can be immediately determined in any scenario. It should be noted that the large language model, based on data lineage graphs and government data asset catalogs, associates extracted policy elements with specific government data entities. For example, cross-departmental sharing of government data is linked to directory code SZ-SJ-001 (municipal government data sharing catalog); the requirement to retain audit logs for shared data is linked to clause number ZZ-2025-012-03 (corresponding to the "Data Sharing Audit Responsibility" clause); and dynamic de-identification of sensitive data related to incentive directions is linked to security actions. Path propagation, based on the data lineage graph II and the government data asset catalog, extends the complete link from policy element to entity to related entity. During entity linking and path propagation, a single policy element may match multiple entities. Conflict disambiguation involves the large language model resolving contradictions, eliminating redundancy, and determining a unique and accurate match through semantic analysis and rule validation. Disambiguation can be performed using predefined disambiguation logic, which may include: matching the most suitable catalog range based on policy applicability conditions; comparing the binding strength of clauses and prioritizing mandatory clauses; and merging duplicate actions while retaining differentiated actions.

[0037] For example, the key elements of the policy are: policy theme, cross-departmental sharing of government data; applicable conditions, non-classified municipal departments; encouraged direction, standardized interface sharing; compliance requirements, retention of audit logs. The corresponding directory code is SZ-SJ-001 (Municipal Government Data Sharing Directory). The corresponding clause number is ZZ-2025-012-03 (Article 12, Paragraph 3 of the "XX Municipal Government Data Management Measures"). The corresponding actions are: sharing, standardized interface application; security, retention of audit logs.

[0038] Understandably, the domain knowledge base is a legal brain formed by integrating the government data asset catalog, data lineage graph, and policy document library, and then performing entity identification, relationship extraction, and conflict disambiguation. It records in real time which policy governs each piece of data, whether it can be shared, and who downstream needs to upgrade the security level simultaneously, using a "catalog-clause-action" triplet. This provides authoritative, traceable evidence that can be verified in seconds for subsequent compliance verification, intelligent Q&A, and scenario solution generation.

[0039] Step S203: Determine user needs based on the domain knowledge base and the preset large language model.

[0040] In this embodiment of the application, the domain knowledge base is used as the legal brain, and the preset large language model acts as the domain expert. Through multi-turn dialogue, users can use natural language to put forward scenario requirements. The model compares the policy constraints and data resources in the knowledge base in real time, and deeply understands and enhances the scenario requirements put forward by the customer. It automatically breaks down the ambiguous natural language requirements into structured requirements of "business objectives + available data + policy red lines + output format".

[0041] For example, a user's natural language input: "The leader wants to see tomorrow how social organizations in our province have driven employment over the past five years. It would be best if there were charts and graphs. Please don't disclose personal privacy, and the data must be publicly available." The model automatically followed up and clarified: "We have detected that you require the 'job creation rate' indicator, but social security details are core data and cannot be directly disclosed. Would you like to use the 'aggregate-level statistics (district / county / year) + differential privacy' method to output a visualization chart? Please reply 'yes' or 'no'." User confirms: "Yes".

[0042] Output structured requirements (JSON): { "goal":"Statistics on the number of jobs created by social organizations and their growth rate over the past five years", "data_assets":["11300001"], "policy_constraints":["Core data must not be made public","Output must be anonymized","Only summary-level results are provided"], "output_form":"Visual charts (bar + line) (district / county aggregation)", "security_level":"Important", "share_type":"Conditional sharing", "reviewer_approved":false }

[0043] Understandably, the above steps input natural language requirements into a large model that understands policies. The model instantly searches the domain knowledge base to automatically fill in "what data can be used, which red lines cannot be crossed, and what conclusions should be drawn," effectively translating vague colloquialisms into structured requirements with compliance constraints. This saves the manual time spent on back-and-forth confirmation and also eliminates the risk of developing first and then rectifying later.

[0044] Step S204: Generate a structured scenario solution based on the preset large language model and user needs.

[0045] In this embodiment of the invention, a pre-defined large language model acts as the architect: after reading user requirements, it queries the domain knowledge base to identify compliance red lines, automatically selects table fields along the data lineage graph, generates an SQL / ETL processing chain, inserts anonymized and encrypted nodes, and outputs a detailed scenario-based solution. The insertion of anonymized and encrypted nodes refers to adding a dedicated process node responsible for data anonymization and encryption within the SQL / ETL data processing chain automatically generated by the large language model. The insertion position can be set according to the actual needs of data processing. For example, the insertion position could be before the SQL query results are returned: dynamically anonymizing sensitive fields to ensure that unauthorized users are presented with anonymized data; or before data is transmitted across departments: encrypting data about to be transferred to external departments to ensure the security of the transmission link.

[0046] For example, a scenario-based solution includes at least an explanation of the solution's advantages, data sources and flow paths, application logic descriptions, and interface and interaction design.

[0047] Step S205: Generate an application prototype based on the structured scenario solution.

[0048] For example, after receiving the structured scenario solution, the server invokes a low-code engine to automatically import the DAG, SQL, anonymized encryption rules, and API specifications from the solution into a containerized template. This compiles an interactive web prototype containing login authentication, aggregated charts, download links, and compliance audit logs. Digital watermarking and differential privacy are embedded, generating a minimum usable application that is accessible, demonstratorable, and ready for deployment to the government cloud. Aggregated charts refer to data display components that present the aggregated analysis results of government data in a visual graphical form, and can include bar charts, column charts, line charts, and pie charts.

[0049] It should be noted that the de-identification and encryption rules are the rules that the aforementioned de-identification and encryption nodes must follow when performing de-identification and encryption. They are constraints and operational guidelines used for the standardized transformation of sensitive government data. For example, encryption involves "encryption transformation" of sensitive data, converting plaintext into ciphertext, so that only authorized entities with the key can decrypt and view the real data; de-identification involves "transformation processing" of sensitive data, retaining its value for business use while hiding the true information to prevent privacy leaks.

[0050] Implementing steps 201 to 205 above involves, firstly, constructing a domain knowledge base based on government data, data lineage graphs, and a pre-defined policy document library to achieve data fusion; then, using a large language model based on the domain knowledge base to determine user needs; and finally, constructing an application prototype based on these user needs, thus making reasonable use of the fused data. This solves the technical problem in existing technologies where government data and policies cannot be flexibly integrated and processed, achieving the technical effect of flexible integration and reasonable use of government data and policies.

[0051] In an optional embodiment of the present invention, step S202, determining the domain knowledge base based on the government data asset catalog, data lineage map, and preset policy document library, specifically includes: Step S2021: Based on the government data asset catalog and data lineage map, determine the data link diagram, which is used to represent the relationship between government data.

[0052] A data link diagram is a visualization tool used to describe the data flow path, data carrier, and link connection relationship within a system. It focuses on the data transmission process between different nodes, modules, or systems, and clarifies the data transmission link, interaction method, and dependency relationship from source to destination.

[0053] In this embodiment of the invention, the government data asset catalog is a list of all data resources in the government sector. It includes basic information about various types of data, such as data name, data source (e.g., business departments of government agency A, government agency B, government agency C, etc.), data type (e.g., structured population information tables, unstructured approval documents), data ownership, data format, and scope of permissions. When determining the data link diagram, the core data nodes must first be extracted from this catalog, which are the "starting point" (data source), "ending point" (data user), and "transfer point" (data processing / storage module) in the link. For example, the three core data categories of "basic population information," "social security payment records," and "medical insurance reimbursement data" are selected from the catalog; these are the key nodes in the link diagram.

[0054] Furthermore, by leveraging data lineage mapping, the flow and relationships of data can be clarified. Data lineage mapping records the entire lifecycle of data from generation, processing, transmission to use, clearly showing where the data comes from, what processes it undergoes, where it goes, and the derivation and dependency relationships between different data types. Specifically, for government data, lineage mapping will demonstrate: Horizontal correlation: For example, "basic population information" will serve as prerequisite data for "social security enrollment registration" and "housing provident fund account opening"; Vertical flow: For example, the complete path of a piece of data from the street government service station to the district government data center, and then to the municipal government cloud platform; Processing association: For example, the "Social Security Contribution Statistics Report" is generated by summarizing and calculating "Individual Social Security Contribution Records" and "Unit Participation List".

[0055] The purpose of this step is to provide the core basis for how and why data is connected in the link diagram.

[0056] Finally, the information is integrated to create a government data link diagram representing the relationships between data. Combining the information from the first two steps, the data nodes and connections are transformed into a visual link diagram. This link diagram is no longer a simple transmission path diagram, but a specialized diagram focusing on the relationships between government data. Two core elements are emphasized when creating this diagram: Node attributes: Label each data node with the corresponding government department, data type, and permission level; Relationships: Connect nodes with labeled links, clearly defining the relationship type represented by the links (such as dependency, derivative, and shared relationships), and supplementing the associated business scenarios (such as cross-departmental social security and medical insurance data verification).

[0057] Step S2022: Perform natural language processing on the policy documents in the preset policy document library to obtain policy elements.

[0058] In this embodiment of the application, natural language processing (NLP) technology is used to automatically extract valuable and standardized core policy elements from policy document text with low structure, transforming "unstructured policy text" into "structured information that can be recognized and used by the system".

[0059] For example, the documents in the policy document library are first processed to remove redundancy and interference, preparing for subsequent analysis. Then, the core elements to be extracted from the policy documents are identified. The elements of government policies typically include policy theme, applicable conditions, target audience, incentive directions, and compliance requirements. Based on the pre-defined element classification, corresponding NLP methods are used for precise extraction. Core technologies include keyword extraction, named entity recognition, relation extraction, and text classification. The extracted elements are then formatted to obtain standardized policy elements.

[0060] Step S2023: Determine the domain knowledge base based on the data link diagram and policy elements.

[0061] In this embodiment of the application, a semantic association model is used to vectorize and similarize data asset entities (such as tables and fields) and policy elements, establish an implicit association network between "data and policy", and construct a structured, machine-understandable domain knowledge base.

[0062] In the process of determining the domain knowledge base, policy elements are mapped to corresponding nodes in the data link graph to form an initial association state. Based on the directed transmission characteristics of the data link graph, the policy attributes of the upstream nodes are propagated and reasoned to the downstream nodes along the data flow path, so that the downstream nodes inherit the security level or restrictive constraints of the upstream nodes. If the same node has multiple conflicting policy attributes after propagation and reasoning, conflict disambiguation is performed based on the preset policy effectiveness weight model to determine the final association between government data and policies, thus obtaining the domain knowledge base.

[0063] For example, the process of determining the domain knowledge base is not a simple static mapping, but a dynamic graph reasoning process. Specifically, the server employs a graph-based attribute propagation algorithm.

[0064] (1) Attribute inheritance: Due to the "cleaning, processing and aggregation" characteristics of government data, downstream data (such as "social security statistics table") often contains sensitive information from upstream data (such as "ID number"). Therefore, the system will automatically detect the directed edges in the data lineage graph and automatically pass the strong constraint attributes of upstream nodes, such as "high sensitivity level" and "prohibited from leaving the country", to all downstream derived nodes.

[0065] (2) Conflict Disambiguation: During the propagation process, if a downstream node inherits both the "prohibited from disclosure" attribute from the upstream node and its own "should be disclosed" attribute, the system will trigger a disambiguation mechanism. The system has a built-in policy effectiveness weight model, assigning the highest weight to laws (1.0), followed by administrative regulations (0.8), and lower weight to departmental rules (0.6). In this example, the system will prioritize retaining the "prohibited from disclosure" attribute to ensure compliance with the bottom line of data processing.

[0066] In an optional embodiment of the present invention, step S2021, determining the data link diagram based on the government data asset catalog and data lineage map, specifically includes: Step S2021a: The government data asset catalog is parsed using a preset parsing strategy to obtain table feature data of multiple data tables. The table feature data includes the business meaning of multiple data tables, the field definitions of multiple data tables, and the relationship between multiple data tables. Step S2021b: Determine the data link diagram based on the table feature data and data lineage map.

[0067] In this embodiment of the invention, the scattered, structured / semi-structured information in the government data asset catalog is first parsed into standardized table feature data according to preset rules, providing basic data support for the subsequent construction of data link diagrams.

[0068] A pre-defined parsing strategy is a set of directory parsing rules and standards established in advance to ensure the consistency of parsing results. This strategy may include: Structured parsing rules: For content stored in database tables or Excel spreadsheets in the directory, extract information according to the hierarchy of "data table name → business affiliation → field information → association description"; Semantic matching rules: For semi-structured text descriptions in the directory (such as "This table is used to record basic information of the city's registered population"), the business meaning of the data table is extracted through keyword matching and semantic recognition. Association identification rules: For the "field association" information noted in the catalog (such as "the 'ID number' field in this table is associated with the 'ID number' field in the population information table"), extract the association relationships between the data tables.

[0069] Furthermore, based on table feature data as nodes: each parsed data table serves as the core node of the data link diagram, while marking the nodes with business meaning, core fields, and other feature information; based on table relationships as static connection basis: according to the cross-table relationships in the table feature data, basic connections are established between nodes (such as the connection between "Population Information Table" and "Social Security Payment Table", based on the "ID Number" field); and supplemented by data lineage graph as dynamic flow: the data flow paths in the lineage graph are overlaid to improve the direction and process of the link, such as marking the direction of data transmission (source node → target node), processing operations during transmission (such as field cleaning and format conversion), and government business scenarios of transmission (such as cross-departmental data sharing and business approval data verification). The final optimized data link diagram is generated by eliminating redundant connections and merging duplicate paths, forming a government data link diagram that reflects both the static relationship between data tables and the dynamic flow of data.

[0070] In an optional embodiment of the present invention, step S203, based on a domain knowledge base and a preset large language model, determines user needs, specifically including: Step S2031: Receive the user's initial scenario requirements through the human-computer interaction interface.

[0071] In this application embodiment, the human-computer interaction interface refers to the carrier or channel for information transmission between the user and the government data system. Common forms in government scenarios include: visual operation interface, command input interface and file upload interface.

[0072] Initial scenario requirements are the original requirements put forward by users based on specific government affairs business scenarios. They are usually descriptive and non-standardized, focusing on "what business needs to be done". Examples of requirements in government affairs scenarios are as follows: Business collaboration category: "Building a cross-departmental sharing link for household registration data and housing provident fund contribution data"; Data verification category: "Verify the consistency between medical insurance reimbursement data and hospital treatment data"; Policy matching category: "Find the policy elements that support social security subsidies for enterprises and match them with the corresponding enterprise social security participation data tables."

[0073] Understandably, the interface will capture the user's input requirements according to preset rules (such as text format validation and required field checks), filter invalid content (such as garbled characters and meaningless characters), and then convert unstructured user requirements (such as natural language text and document content) into a basic format that the system can recognize (such as strings and structured requirement fields) to facilitate parsing in subsequent stages.

[0074] Step S2032: Based on the domain knowledge base and initial scenario requirements, generate requirement questions through a large language model.

[0075] In this embodiment, the server invokes a large language model and performs deep understanding and enhancement of user needs based on a domain knowledge base. During this process, the large model acts as a domain expert, proactively generating questions to clarify ambiguous intentions and supplement key information through multiple rounds of interactive dialogue. It also recommends data assets and policy references related to the current needs that the user may not be aware of.

[0076] For example, users' initial scenario needs are usually descriptive and fragmented. For instance, a user might input, "I want to see how household registration data and social security data are related, and what policies support this."

[0077] The core working logic of the large language model is that it does not directly reuse the original requirements, but rather combines the domain knowledge base to decompose, professionally transform, and structurally reconstruct the requirements. This can be divided into three steps: Step 1: Identifying Request Intent The model, based on a domain knowledge base, analyzes the core intent of the user's initial needs. For example, for the above example needs, two core intents are identified: querying the relationship between the household registration data table and the social security data table; and matching the policy elements that support this data relationship.

[0078] Step 2: Terminology Alignment Transform users' colloquial expressions into standard terminology within the field. For example, transform "how to connect" into "the components of the data link, the associated fields, and the transmission path"; transform "what policies support it" into "applicable policy documents, policy measures, and responsible entities".

[0079] Step 3: Generate structured questions Based on a pre-defined question template (from a domain knowledge base), generate precise and actionable requirement questions. Questions typically have clearly defined query objects, query dimensions, and constraints to avoid ambiguity.

[0080] Step S2033: Receive the response data from the user's question regarding their needs through the human-computer interaction interface.

[0081] In this embodiment of the application, the feedback information (response data) of the user's needs questions generated in the preceding steps is collected through the human-computer interaction interface. This is a step of demand calibration and information completion, which aims to enable the system to obtain more accurate user intentions and provide clearer constraints for subsequent matching of data links and policy elements.

[0082] For example, response data, which consists of user replies to questions about needs, can be divided into two categories: Confirmation responses: These responses affirm or deny the content of the question, such as those requiring city-level links or including data sharing permission requirements. Supplementary responses: Add additional constraints to the question, such as replying with a city-level link, and it is necessary to include district and county-level data transfer nodes, and the permission requirements must be clearly stated to be limited to government approval scenarios.

[0083] These responses will be captured by the system in a structured form (such as key-value pairs and option identifiers) to avoid ambiguity.

[0084] Understandably, the pre-generated requirement questions address uncertainties in the user's initial needs, and the user's responses can eliminate these ambiguities. For example, if the initial requirement lacks a clear hierarchical level, the response will lock it into a city-level hierarchy. User responses also add new requirements constraints, making subsequent data link matching and policy element matching more aligned with actual business scenarios.

[0085] Step S2034: Determine user needs based on the initial scenario requirements and response data.

[0086] In this embodiment, step S2034 integrates the user's initial scenario requirements and the response data to the questions raised regarding those requirements. After sorting, verifying, and refining, a precise, complete, and actionable user requirement is ultimately formed, providing a clear target basis for subsequent matching of data links and policy elements. The final output user requirement is no longer a vague descriptive statement, but a structured, unambiguous instruction that can directly drive subsequent processes.

[0087] In an optional embodiment of the present invention, step S204, generating a structured scenario solution based on a preset large language model and user needs, specifically includes: Step S2041: Based on the preset large language model and user needs, generate the solution advantages, data sources, data flow paths, application logic descriptions, and interface interaction designs. Step S2042: Determine the structured scenario solution based on the advantages of the solution, data sources, data flow paths, application logic descriptions, and interface interaction design.

[0088] In this embodiment of the application, a pre-set large language model is used as the generation tool, and the five elements that constitute the scenario solution are output with the guidance of precise user needs. These elements cover the value of the solution, data support, flow logic, business rules and interaction carrier.

[0089] The advantages of the solution are explained as follows: by addressing pain points in government operations, the core value of the solution (such as improved efficiency, reduced costs, and compliance guarantees) is extracted, demonstrating the necessity of the solution. Example: Enables one-click sharing of household registration and housing provident fund data across departments at the municipal level, reducing manual reporting processes and improving approval efficiency by 30%; clarifies data usage permissions based on policy requirements, avoids the risk of data leakage, and complies with government data sharing standards.

[0090] The data source is explained as being based on the government data asset catalog and table characteristic data, clearly specifying the exact origin of the data required by the plan, including the data table name, the department to which it belongs, the data type, and the access level. Example: Household registration data: "City-level Household Registration Population Information Table" from the D Household Registration Management System of the government agency, with an access level of "government sharing level"; Housing provident fund data: "City-level Housing Provident Fund Contribution Details Table" from the Municipal Housing Provident Fund Management Center, with an access level of "government sharing level"; Transfer node: Data exchange module of the district government data platform.

[0091] The data flow path is explained as a combination of data lineage maps and data link diagrams to generate a complete flow of data from source to end user, marking transmission protocols, transit links, and data processing rules. Example: Government Agency D Household Registration System → (TCP / IP protocol + SSL encryption) → District Government Data Platform → (Data format standardization and cleaning) → Municipal Housing Provident Fund Management Center System; Data flow trigger condition: Automatic synchronization after the housing provident fund contribution qualification verification application is submitted.

[0092] Application logic description refers to the business execution rules that clearly define the implementation of the solution, including triggering conditions, data validation rules, exception handling mechanisms, policy matching logic, etc., and constitutes the core business process of the solution. Example: Triggering conditions: When an enterprise submits a housing provident fund account opening application, the legal representative's household registration information must be verified; Verification rules: The household registration form and the housing provident fund form are linked through the "ID number" field to compare the consistency between the household registration address and the enterprise's registered address; Anomaly handling: When the information is inconsistent, a notification is pushed to the government approval terminal for manual review; Policy matching: Automatically associates the "Cross-departmental data use filing" clause in the "XX Municipal Government Data Sharing Management Measures".

[0093] User interface (UI) design, based on the operating habits of users of government systems, involves generating a description of the corresponding user interface for the proposed solution. This includes interface module division, function buttons, data display areas, and interaction flows, ensuring the solution's feasibility for implementation. Example: Approval interface: divided into "Application Information Area", "Data Verification Result Area" and "Policy Clause Matching Area"; Interaction process: Approving personnel log in → select "Housing Provident Fund Account Opening Verification" → initiate data sharing request with one click → view verification results and policy basis → click "Approve / Reject" to complete the operation.

[0094] Step S2042 involves integrating, verifying, and encapsulating the five dispersed elements generated by the large language model according to the preset government affairs solution standard framework, ultimately forming a standardized, deliverable, and executable structured scenario solution. This step is crucial for transforming the solution from an "element set" into a "complete product."

[0095] For example, following the standard template for government service scenario solutions, the five key elements are filled into the corresponding modules to form a fixed structure. A typical government service solution framework is as follows: Solution Title → Solution Advantages (Value Proposition) → Data Source (Resource Support) → Data Flow Path (Transfer Link) → Application Logic Description (Business Rules) → Interface Interaction Design (Implementation Platform) → Solution Compliance Statement → Implementation Steps

[0096] Check for logical contradictions among the various elements to ensure the self-consistency of the solution. For example, transit nodes in the data flow path must correspond to the departments to which the data originates; policy matching clauses in the application logic must correspond to the compliance guarantees in the solution's advantages.

[0097] Standardize the content of the solution: unify the expression of government terminology (such as "government sharing level" instead of "internal use level"), unify the description of data formats (such as data table naming conventions), and unify the interface interaction terminology (such as "verification result area" instead of "result display page") to ensure that the solution meets the delivery standards of the government system.

[0098] The integrated solution is output in a standardized format (such as Word document, JSON structure, or government platform-specific solution template), and the solution version, applicable scenarios, scope of effect, and responsible entity are marked to form the final deliverable structured result.

[0099] Structured scenario solutions are guidance documents that government departments can directly use for business implementation. They include the value and logic of the solution, as well as specific execution steps and interface design, and can support subsequent system development, business process transformation, cross-departmental collaboration and other work.

[0100] In an optional embodiment of the present invention, step S205, generating an application prototype based on the structured scenario solution, specifically includes: Step S2051: Invoke the preset code generation model to generate program source code based on the structured scenario solution.

[0101] Step S1052: Call the preset compliance rule verification engine to perform abstract syntax tree parsing on the program source code and extract the data operation logic and interface call chain in the code; Step S1053: Compare the data operation logic and interface call chain with the compliance constraints in the domain knowledge base. If the comparison is successful, generate an application prototype based on the program source code. If the comparison fails, generate a correction instruction and feed it back to the preset code generation model. The generated application prototype is deployed on a shared platform and has a unique access path.

[0102] In this embodiment, the server invokes a preset code generation model, using the aforementioned generated structured scenario solution as input prompts. Based on the application logic description, interface and interaction design, and data flow path in the solution, the code generation model automatically generates compilable and deployable application source code that meets the requirements.

[0103] After obtaining the program's source code, the server uses a code parser to convert the generated source code into an Abstract Syntax Tree (AST). A pre-defined compliance rule verification engine traverses the AST nodes to detect any violations. For example, it checks whether the Select field of an SQL statement contains an unmasked "ID number" and whether the Masking() function is missing; it also checks whether the API interface exposes core data without authorization.

[0104] Subsequent compilation and deployment operations are only performed when the AST parsing result fully conforms to the "safe actions" constraints in the domain knowledge base. If the verification detects a risk, the system will automatically generate a prompt containing the error location and send it back to the code generation model for self-correction until the verification passes. This mechanism fundamentally eliminates the risk of deploying unauthorized code.

[0105] When the AST parsing result fully conforms to the "safe actions" constraints in the domain knowledge base, the server automatically builds, manages dependencies, and performs integrity testing on the generated source code to ensure its runnability. A runnable and interactive software application prototype is automatically generated, implementing the core functionality of the solution, which users can immediately experience and test.

[0106] Finally, the server provides a one-click deployment function to deploy the generated application prototype to the shared platform and generate a unique access link, supporting authorized access, reuse, and code-level secondary development, thereby realizing the rapid circulation and value transformation of data application scenarios.

[0107] This application's embodiments utilize the data lineage transmission characteristics to propagate and disambiguate policy attributes, and perform compliance verification based on abstract syntax trees after generating the source code, thereby ensuring the compliance and accuracy of government data applications.

[0108] It is understood that, based on the description of the above embodiments, the government data processing method provided in this application has the following technical effects: This significantly reduces the technical barriers and time costs for innovation in government applications: through natural language interaction and multi-turn dialogue, business personnel can accurately express their needs without needing to master professional technical terminology or data modeling knowledge, eliminating the tedious requirement alignment and documentation process in traditional development. The technology of automatically generating executable source code through code generation models shortens the development, coding, testing, and deployment work that originally required weeks or even months to minutes, achieving instant transformation from "idea" to "runnable software".

[0109] Significantly improved the circulation efficiency and utilization value of data assets: The "data-policy" knowledge graph constructed through semantic association breaks down information silos between data and regulations, enabling data to be quickly discovered and associated under the premise of compliance. The generated structured solution clearly lists the data list and circulation path, providing clear guidance for the authorized use of data, making cross-departmental and cross-domain data integration and application simple and efficient, thereby revitalizing dormant data assets.

[0110] This ensures the compliance and policy orientation of innovative application scenarios: policy provisions are transformed into machine-understandable elements and integrated into the knowledge base, injecting compliance constraints into all subsequent processes from the source. When understanding user needs, the system proactively recommends and associates relevant policy bases, avoiding compliance risks in advance, and ensuring that the generated application scenarios are not only technically feasible but also encouraged and supported by policies, achieving a deep integration of technological innovation and institutional requirements.

[0111] It achieves full automation and intelligence in the mining and implementation of data application scenarios: from data policy association and intelligent demand interaction to automatic solution generation and automatic writing, building and deployment of prototype code, the entire process is driven by servers and large language models, forming an end-to-end automated intelligent pipeline. This avoids the pain points of traditional models that rely heavily on human expert experience, repeated communication and manual coding, transforming the innovation process from one that is highly dependent on individual capabilities into a standardized, replicable and highly efficient industrial process.

[0112] Based on the same inventive concept, this application also provides a government data processing apparatus for implementing the aforementioned government data processing method. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more government data processing apparatus embodiments provided below can be found in the limitations of the government data processing method described above, and will not be repeated here.

[0113] In one exemplary embodiment, such as Figure 3 As shown, a government data processing device is provided, comprising: an acquisition module 301 for acquiring a government data asset catalog and a data lineage graph; a first determination module 302 for determining a domain knowledge base based on the government data asset catalog, the data lineage graph, and a preset policy document library, wherein the domain knowledge base includes the relationship between government data and policies; a second determination module 303 for determining user requirements based on the domain knowledge base and a preset large language model; a first generation module 304 for generating a structured scenario solution based on the preset large language model and user requirements; and a second generation module 305 for generating an application prototype based on the structured scenario solution.

[0114] As an optional implementation, the first determining module 302 is further configured to: determine a data link diagram based on the government data asset catalog and data lineage map, wherein the data link diagram is used to represent the relationships between government data; perform natural language processing on policy documents in the preset policy document library to obtain policy elements; and determine a domain knowledge base based on the data link diagram and policy elements.

[0115] As an optional implementation, the first determining module 302 is further configured to: parse the government data asset catalog using a preset parsing strategy to obtain table feature data of multiple data tables, wherein the table feature data includes the business meaning of multiple data tables, the field definitions of multiple data tables, and the relationship between multiple data tables; and determine the data link diagram based on the table feature data and the data lineage graph.

[0116] As an optional implementation, the second determining module 303 is further configured to: receive the user's initial scenario requirements through a human-computer interaction interface; generate requirement questions based on the domain knowledge base and the initial scenario requirements through a large language model; receive the user's response data to the requirement questions through the human-computer interaction interface; and determine the user's requirements based on the initial scenario requirements and the response data.

[0117] As an optional implementation, the first generation module 304 is also used to: generate the advantages of the solution, data sources, data flow paths, application logic descriptions, and interface interaction designs based on a preset large language model and user needs; and determine the structured scenario solution based on the advantages of the solution, data sources, data flow paths, application logic descriptions, and interface interaction designs.

[0118] As an optional implementation, the second generation module 305 is also used to: call a preset code generation model to generate program source code based on a structured scenario solution; call a preset compliance rule verification engine to perform abstract syntax tree parsing on the program source code and extract data operation logic and interface call chains from the code; compare the data operation logic and interface call chains with compliance constraints in the domain knowledge base; if the comparison passes, generate an application prototype based on the program source code; if the comparison fails, generate correction instructions and feed them back to the preset code generation model. The generated application prototype is deployed on a shared platform and has a unique access path.

[0119] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 4 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores video tag processing data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a government data processing method.

[0120] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0121] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0122] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0123] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0124] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0125] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0126] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0127] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0128] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for processing government data, characterized in that, The government data processing method includes: Obtain the catalog of government data assets and data lineage maps; Based on the government data asset catalog, the data lineage graph, and the preset policy document library, a domain knowledge base is determined, wherein the domain knowledge base includes the relationship between government data and policies; Based on the domain knowledge base and the preset large language model, user needs are determined; Based on the preset large language model and the user requirements, a structured scenario solution is generated; Based on the structured scenario solution, an application prototype is generated.

2. The government data processing method according to claim 1, characterized in that, The step of determining the domain knowledge base based on the government data asset catalog, the data lineage graph, and the preset policy document library specifically includes: Based on the government data asset catalog and the data lineage diagram, a data link diagram is determined, wherein the data link diagram is used to represent the relationship between the government data; Natural language processing is performed on the policy documents in the preset policy document library to obtain policy elements; The domain knowledge base is determined based on the data link diagram and the policy elements.

3. The government data processing method according to claim 2, characterized in that, The step of determining the data link diagram based on the government data asset catalog and the data lineage map specifically includes: The government data asset catalog is parsed using a preset parsing strategy to obtain table feature data of multiple data tables. The table feature data includes the business meaning of multiple data tables, the field definitions of multiple data tables, and the relationship between multiple data tables. The data link graph is determined based on the table feature data and the data lineage map.

4. The government data processing method according to claim 1, characterized in that, The process of determining user needs based on the domain knowledge base and the preset large language model specifically includes: Receive the user's initial scenario requirements through the human-computer interaction interface; Based on the domain knowledge base and the initial scenario requirements, a requirement question is generated using a large language model. Receive response data from users' questions regarding their needs through a human-computer interaction interface; Based on the initial scenario requirements and the response data, the user requirements are determined.

5. The government data processing method according to claim 1, characterized in that, The generation of a structured scenario solution based on the preset large language model and the user requirements specifically includes: Based on the preset large language model and the user needs, the advantages of the solution, data sources, data flow paths, application logic descriptions, and interface interaction design are generated. Based on the advantages of the proposed solution, the data source, the data flow path, the application logic description, and the interface interaction design, the structured scenario solution is determined.

6. The government data processing method according to claim 1, characterized in that, The step of generating an application prototype based on the structured scenario solution specifically includes: The preset code generation model is invoked to generate program source code based on the structured scenario solution; The preset compliance rule verification engine is invoked to perform abstract syntax tree parsing on the program source code and extract the data operation logic and interface call chain in the program source code. The data operation logic and the interface call chain are compared with the compliance constraints in the domain knowledge base. If the comparison is successful, the application prototype is generated based on the program source code. If the comparison fails, a correction instruction is generated and fed back to the preset code generation model. The application prototype is deployed on a shared platform and has a unique access path.

7. A government data processing device, characterized in that, The government data processing device includes: The acquisition module is used to acquire the catalog of government data assets and the data lineage map; The first determining module is used to determine a domain knowledge base based on the government data asset catalog, the data lineage map, and the preset policy document library, wherein the domain knowledge base includes the relationship between government data and policies; The second determining module is used to determine user needs based on the domain knowledge base and the preset large language model; The first generation module is used to generate a structured scenario solution based on the preset large language model and the user requirements; The second generation module is used to generate an application prototype based on the structured scenario solution.

8. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the steps of the government data processing method according to any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the government data processing method according to any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the government data processing method according to any one of claims 1-6.

Images