Information intelligent matching method based on large language model semantic analysis and double verification

Abstract

The application discloses an information intelligent matching method based on big language model semantic analysis and double verification, which collects policy texts and inputs the policy texts into a database, carries out text format unification and metadata labeling to obtain policy clause texts; the big language model is used to analyze the processed texts into structured policy structured triples; when policy matching is needed, formal rule matching is performed, and the portrait data object of the matching personnel and the policy rule library are taken as inputs, and the output is a formal matching result set; the semantic understanding ability of the big language model is used to carry out secondary review and supplement on the output, and finally the final matching result is integrated into a service suggestion package and output to the grass-roots service personnel. The application uses the big language model to analyze the policy texts into structured rule data, constructs a policy rule library that can be executed by a machine, and adopts a double verification mechanism of formal rule verification and big language model semantic review in the matching stage, so that the reliability of the final matching result is ensured.

Description

Technical Field

[0001] This invention belongs to the field of information analysis technology, specifically relating to an intelligent information matching method based on semantic parsing of a large language model and dual verification. Background Technology

[0002] Intelligent information matching, simply put, uses computer technology to automatically find the most relevant and accurate answer or object from massive amounts of data to meet your current needs. For example, when grassroots service personnel process appropriate subsidies or benefits for children based on their actual circumstances, a corresponding intelligent information matching system or application can be built. By inputting the child's information data, suitable policy information can be obtained, and then the appropriate subsidies or benefits can be processed. This can significantly improve the work efficiency of grassroots service personnel and provide precise services to those in need.

[0003] Currently, the main problem in building intelligent information matching systems or applications is that information data (such as policy information) is mostly published in the form of natural language text. Applicable conditions, treatment standards, and processing procedures are embedded within the paragraphs of the text, lacking a structured, machine-readable representation. When matching, grassroots staff need to maintain various condition models simultaneously and compare them one by one with specific situations. This process lacks both systematic tools and automated verification mechanisms. Existing solutions mainly fall into two categories. The first is the traditional rule engine solution, where domain experts manually encode policy provisions into a set of if-then rules, and then use a rule reasoning engine for condition matching. The main drawback of this solution is that the rule encoding process is time-consuming and labor-intensive (on average, two to three domain experts need to work for a week to complete the encoding and verification of a moderately complex policy), and when policies are revised or new policies are introduced, the rule base updates are severely delayed, leading to frequent rule expiration issues during system operation. The second type is a question-answering scheme based on a large language model. Policy texts are stored in a vector database, and users ask natural language questions. The system retrieves relevant fragments and generates answers using a large language model. The main drawbacks of this scheme are the lack of structured rule constraints, the risk of errors in the model output, and the lack of determinism in the output results. The same input may produce different outputs in different calls. In addition, it lacks a systematic output verification mechanism, which cannot ensure the reliability and consistency of the matching results. Summary of the Invention

[0004] To address the aforementioned shortcomings, this invention discloses an intelligent information matching method based on semantic parsing and dual verification using a large language model. This method utilizes a large language model to parse policy text into structured rule data, constructing a machine-executable policy rule base. Furthermore, during the matching phase, a dual verification mechanism is employed, combining formal rule verification and semantic review by the large language model. This balances matching accuracy with the ability to handle ambiguous expressions in policy provisions. Simultaneously, the reliability of the final matching result is ensured through confidence evaluation and formal verification of the large language model output.

[0005] This invention is achieved using the following technical solution: An intelligent information matching method based on semantic parsing of a large language model and dual verification includes the following steps: S1. Policy Text Collection and Preprocessing: Collect policy texts and incorporate them into the database. Then, standardize the text format by converting PDF or Word files to plain text format while preserving paragraph structure. Next, perform metadata annotation, followed by clause segmentation. According to the policy's chapters and clause structure, the entire text is divided into independent clause text segments. Each segment retains its clause number from the original document, such as "Article 3, Paragraph 2". Then, deduplication and version association are performed. If a policy is detected as a revised version of a previously entered policy, the historical version is automatically associated, and the changed clauses are marked. S2. Using a large language model, the policy clause text obtained after processing in step S1 is parsed into structured policy structured triples (PSTs). The construction of the large language model includes the following steps: S21. Domain Fine-tuning Data Preparation: Select twenty to thirty representative policy clauses from the policy texts in the database. Two domain experts independently and manually parse these clauses into structured triples to form a comparison sample set of policy texts and structured triples. If the two experts' parsing results are inconsistent, organize a discussion to reach a consensus and use it as the final annotation. S22. Selection and Deployment of Large Language Models: Select a Chinese base large language model (such as the Qwen series, ChatGLM series, or Baichuan series) with a parameter scale between 7B and 70B. Deploy it on an inference server equipped with at least one GPU (with a video memory of no less than 24GB, such as NVIDIA A10 or RTX 4090). Then, use the control sample set obtained in step S21 to perform domain adaptation fine-tuning. During the domain adaptation fine-tuning process, only train the additional parameters that account for 0.1% to 1% of the total parameters, without changing the original parameters of the base model. The training time is 2 to 4 hours on a single GPU. After the domain adaptation fine-tuning is completed, evaluate the parsing accuracy of the model on the reserved test set. The parsing accuracy at the clause level should be no less than 90%, and the parsing accuracy at the conditional field level should be no less than 95%. S23. Prompt Template Configuration: Configure a prompt template for the policy structured parsing task. The prompt template includes the following elements: task instructions (explicitly requiring the model to parse the input policy clauses into structured triples), output format specifications (defining the output structure using JSON Schema, including arrays of applicable conditions, treatment standards, and processing procedures, with each applicable condition containing field names, operators, thresholds, and logical connectors), guidance on handling fuzzy conditions (requiring the model to provide a recommended formal coding scheme for fuzzy expressions, while also marking fuzzy tags to indicate that the condition requires manual review), and 3-5 parsing examples (Few-Shot Learning, selecting different types of examples from labeled data for the model's reference). S24. Batch parsing execution: Input the policy clause text obtained after step S1 into the adjusted large language model in step S22 one by one, and use the prompt template described in step S23 to output a JSON-formatted structured triple for each policy clause. During the parsing process, record the generation time of each result and the internal confidence information of the model. S25. Confidence Assessment and Manual Review Triage: For each parsing result, a comprehensive confidence score is calculated based on the concentration of the probability distribution of the model output, whether the output structure conforms to the predefined JSON Schema, whether the condition fields correspond to the existing standard attribute names in CPDO, and the model's labeling of fuzzy conditions. Results with a confidence score higher than 0.90 are automatically entered into the policy rule base. Results with a confidence score between 0.60 and 0.90 enter the manual review queue, where domain experts confirm or correct each result on the web review interface before entering the database. Results with a confidence score lower than 0.60 are marked as parsing anomalies, triggering an alarm to notify operations personnel to check the text quality of the policy clause or whether the prompt template needs adjustment. During the initial deployment of the system, it is expected that approximately 60% of the parsing results can be directly entered into the database, 35% will enter the review queue, and 5% will be marked as anomalies. As domain fine-tuning data accumulates and the model is continuously optimized, the proportion of results directly entered into the database will gradually increase. S26. Version Update of Policy Rule Base: The structured triples confirmed in step S25 are written into the policy rule base. The policy rule base adopts version management. Each policy change (such as addition, revision or repeal) generates a new rule base version number, recording the change timestamp, change type, policy clauses involved and differences in content before and after the change. When the matching engine is running, it can specify to use a specific version of the rule base (the latest version is used by default) to ensure that the matching judgment is based on the correct policy version. After the rule base is updated, the matching engine automatically hot-loads the new version of the rule data without restarting the service. S3. Formal rule matching (first stage of dual verification): When policy matching is required, formal rule matching is performed, taking the profile data object of the person to be matched and the latest version of the Policy Rule Base (PRB) as input, and the output is a formal matching result set; S4. Semantic review of the large language model (second stage of double verification): The semantic understanding ability of the large language model is used to conduct a second review and supplement to the output in step S3. The results of the confirmed matching set and the confirmed exclusion set in step S3 are used as inputs, and the large language model performs semantic-level review and check. At the same time, the results of the pending set in step S3 are used to perform semantic reasoning to make a final judgment. The core matching strategy employed in this invention consists of two sequential verification stages. The first stage is formal rule verification, which compares the attribute values ​​in the profile data object with the formal applicability conditions of all policy rules in the policy rule base, filtering out the set of policy items that meet all hard conditions, which is the formal matching result set. The second stage is semantic review by a large language model, which submits the formal matching result set, along with the complete profile information of the person, in natural language to a domain-fine-tuned large language model, requesting the model to conduct a second review at the semantic level, focusing on checking the following: whether there are policy items that have been missed by the rule engine due to the limitations of formal expression (e.g., the vague condition "family has real difficulties" in the policy text is conservatively encoded as a strict economic indicator threshold during formalization, and some children who are actually in difficulty but do not meet the indicator may be incorrectly excluded); whether there are inapplicable "false positive" items in the formal matching results (e.g., although a child meets all formal conditions, there are implicit exclusion conditions described in natural language in the policy text). The final matching result output after double verification has significantly better reliability than a single verification method. S5. Service Request Package Generation and Output: The final matching results processed in step S4 are integrated into a Service Request Package (SRP) and output to frontline service personnel.

[0006] The aforementioned Policy Structured Triplet (PST) refers to the standard output format after the structured parsing of each welfare policy clause in this invention. Each triplet consists of three parts: a set of applicable conditions, a set of benefit standards, and a set of processing procedures. The set of applicable conditions contains all the constraints of the policy clause on the applicant, with each condition represented by a formal expression of attribute fields, comparison operators, and thresholds (e.g., "Age < 18 years old", "Parents' status = both missing or incarcerated", "Disability level >= Level 2", etc.). The set of benefit standards describes the specific benefits that children who meet the policy conditions can enjoy (e.g., monthly subsidy amount, medical expense reimbursement ratio, list of free services, etc.). The set of processing procedures describes the materials required to apply for the policy benefits, the approval department, and the processing time limit.

[0007] The Policy Rule Base (PRB) mentioned above refers to the database constructed by this invention that stores all structured triples of welfare policies. The Policy Rule Base is maintained in a versioned management manner, and is automatically updated every time a policy is added or revised, while retaining a complete historical version record. It supports querying the set of policy rules that are effective at any time by time node. The Policy Rule Base is the core data source for the matching engine to perform automated matching.

[0008] Furthermore, in step S1, the following three methods are used to collect policy texts: Method 1 is to periodically crawl government gazette websites, policy databases, and official information release platforms of government departments to detect newly released or revised policy documents, and then automatically download and merge them into the database; Method 2 is to set up a web management interface that allows administrators to manually upload policy documents in PDF or Word format; Method 3 is to use an API connection channel to connect with the policy release interface of the superior government information sharing platform and receive policy change information pushed in real time.

[0009] Furthermore, the metadata annotation mentioned in step S1 is used by administrators or automatic identification tools to annotate policy documents with policy name, issuing agency, release date, effective date, expiration date, policy level (national / provincial / municipal) and applicable region.

[0010] Furthermore, the control sample set mentioned in step S21 includes the following typical scenarios: simple policies with clear conditions (such as age restrictions and household registration requirements), nested policies with complex conditions (such as "or" and "and" logical relationships between multiple conditions), policies containing vague expressions (such as "families that are indeed in difficulty" or "those who have been identified as needing assistance"), and policies containing exclusion conditions (such as "those who have already received the same type of subsidy will not receive it again").

[0011] Furthermore, in step S3, when policy matching is required, formal rule matching is performed, taking the profile data objects of the persons to be matched and the latest version of the Policy Rule Base (PRB) as inputs, and outputting a formal matching result set. The specific steps are as follows: S31. Extraction of profile data objects of the persons to be matched: Based on the collected profile data objects of the persons to be matched, extract all attribute fields and their current values. For attribute fields that are missing in the profile data objects (such as the psychological health assessment data of a child that has not yet been collected), mark them as unknown. S32. Rule-by-rule matching: Traverse all policy rules in the policy rule base and execute the following matching logic for each rule: Check each condition in the set of applicable conditions of the rule in turn, map the attribute field name in the condition to the corresponding attribute field in the profile data object, take out the current value of the attribute, and compare it with the threshold in the condition according to the specified comparison operator. If the corresponding attribute value in the profile data object is unknown, the judgment result of the condition is uncertain. All conditions are combined and judged according to the logical connector ("AND" "OR") specified in the rule. When the combined judgment result of all conditions is satisfied, the policy rule enters the formal matching result set. When the judgment result is not satisfied, the rule is excluded. When the judgment result contains uncertain conditions, the rule enters the pending set and is passed to the semantic review stage for processing along with the uncertain condition information. S33. Formal Matching Result Output: Output three sets, including the confirmed match set (a list of policy rules that meet all conditions), the confirmed exclusion set (a list of policy rules that do not meet at least one condition), and the pending set (a list of policy rules that cannot be determined). Each result in each set is accompanied by a detailed matching process log, which records the attribute name of each condition, the actual value in the profile data object, the threshold required by the rule, the comparison operator, and the single judgment result.

[0012] Furthermore, the profile data object mentioned in step S3 is a standardized data object maintained for the person to be matched, which gathers all the related information of the person to be matched in various departmental systems. The profile data object includes attribute fields in the following dimensions: basic information dimension (such as name, ID number, date of birth, gender, ethnicity, registered address, current residence address), family information dimension (such as family member list, identity status of each member, family economic income, housing type), health information dimension (such as disease diagnosis record, disability level, rehabilitation needs, vaccination status), education information dimension (such as school attended, grade, attendance rate, dropout status), service information dimension (such as list of policies enjoyed, service records, evaluation history), and special marker dimension (such as whether it is a left-behind child, whether it is a minority, guardian status, etc.).

[0013] Furthermore, in step S4, the semantic understanding capabilities of the large language model are used to perform a second review and supplementation of the output in step S3. The results from the confirmed matching set and confirmed exclusion set in step S3 are used as input, and the large language model performs a semantic-level review. Simultaneously, the results from the pending set in step S3 are used by the large language model to perform semantic reasoning to make a final judgment. The specific steps are as follows: S41. Semantic Review Context Construction: Construct a Semantic Review Context (SRC) for each matching call. The SRC contains the following information: a complete profile description of the target (converting the structured attribute values ​​of CPDO into natural language descriptions, such as "This child, male, 12 years old, Zhuang ethnicity, registered address is D Village, C Town, B County, A City. His father died in a traffic accident in 2023, his mother has been missing for more than two years, and he is currently under the guardianship of his 65-year-old grandmother, who suffers from hypertension. The family's economic resources are subsistence allowance and the grandmother's rural pension. The child is in the sixth grade of C Town Central Primary School, with an attendance rate of 92% this semester. In March 2024, he was assessed as a Level 2 (Orange) risk level"), the three sets output in step S3 and their matching process logs, and the full text of the relevant policy clauses (retrieving the full text of the corresponding clauses from the policy text library). S42. Hint Construction and Model Invocation: Combine the SRC constructed in step S41 with the dedicated semantic review hint template and input it into the large language model. The semantic review hint template requires the model to perform the following three review tasks: Task A is omission checking, which involves the model reviewing and confirming policy items in the exclusion set to determine if any items have been incorrectly excluded due to limitations in formal expression. (For example, focusing on scenarios such as: policy conditions containing vague expressions, such as a family facing genuine hardship but using strict numerical thresholds in formal coding, while the child's overall situation is indeed difficult even if the numerical threshold is not met; complex logical relationships between policy conditions, such as nested "or" and "and" combinations, where the logical structure may have been simplified in formal coding; and catch-all clauses such as policies applicable to other special circumstances, which are usually ignored in the formalization stage. If the model finds a suspected omission, it outputs the item and the reason for its omission.) Task B is a false positive check, whereby the model reviews and confirms policy items in the matching set to determine whether there are any items that formally meet the conditions but are not applicable in substance. (For example, it focuses on: implicit exclusion conditions described in natural language in policy provisions that are not formalized, such as not receiving duplicate subsidies if already receiving similar ones; this condition may not have a corresponding standard field in CPDO; there is a difference between the policy's spirit and the literal conditions, such as a policy aimed at helping families facing temporary difficulties due to unforeseen events, where the family's current economic indicators meet the criteria but their difficulties stem from long-term structural problems rather than unforeseen events; if the model finds a suspected false positive item, it outputs the item and the reason for its exclusion). Task C is the decision-making of pending items, which means that the model reviews the policy items in the pending set, uses the profile description and the original text of the policy clauses to perform semantic reasoning, and makes a judgment of matching, non-matching or recommending manual confirmation for each pending item, with an explanation of the reasoning process attached. S43. Formal Verification: For each judgment result output by the large language model in step S42, perform formal verification: Compare the omissions claimed by the model (items that the model believes should match but were excluded in the first stage) with the actual attribute values ​​in the CPDO of the person to be matched. If the model claims that the person meets a certain condition, but the corresponding attribute value in the CPDO does not actually meet the formal requirements of the condition, then the item is rejected by formal verification and is not included in the final result. The omissions and false positives that are still retained after formal verification, together with the items that the model judged to match in the pending items, are marked as semantic supplementation results. This formal verification step is the key mechanism of this invention to ensure the reliability of the output of the large language model. Through the dual guarantee of model reasoning and fact verification, the illusion output of the model is eliminated. S44. Secondary Confidence Assessment and Triage: For each item in the semantic supplementation results, a comprehensive confidence score is calculated based on the model's output probability, the logical completeness of the reasoning process, and the pass rate of formal verification. Items with a confidence score higher than 0.90 are directly included in the final matching results. Items between 0.70 and 0.90 are marked as requiring manual review and are pushed to the grassroots service personnel responsible for the person in charge of the item for confirmation, along with the model's reasoning explanation. Items with a confidence score lower than 0.70 are marked as low confidence and are only presented as reference information and are not included in the formal matching results.

[0014] Furthermore, in step S5, the final matching results processed in step S4 are integrated into a Service Request Package (SRP) and output to frontline service personnel. The specific steps are as follows: S51. Compilation of Policy Benefit List: Summarize all confirmed matching items and semantically supplemented matching items in the final matching results, and classify and arrange them according to two dimensions: policy level (e.g., national, provincial, municipal) and benefit type (e.g., basic living security, medical assistance, education subsidies, rehabilitation services, psychological care, housing assistance, legal aid). Each policy is marked with the policy name and document number, a summary of applicable conditions (e.g., indicating which conditions the child meets), benefit standards (e.g., specific subsidy amount or service content), application portal (e.g., online application link or offline acceptance window address), and a list of required materials. For semantically supplemented items that are recommended for manual review, they are marked separately in the list, and the reasoning explanation of the model is attached for reference by grassroots staff. S52. Service Resource Recommendation: Based on the individual's need tags (extracted from CPDO and risk assessment results, such as "psychological counseling needs," "rehabilitation training needs," "educational assistance needs," etc.) and location information, a matching search is performed in the service resource database. The service resource database includes information on registered social service organizations, professional service projects, service capabilities, service areas, contact information, and current queuing status within the jurisdiction. The search results are sorted by matching degree and geographical distance, and the top three recommended organizations under each need category are selected, with the organization name, service content, address, contact number, and estimated waiting time noted. S53. Service Priority Ranking: Based on the individual's risk level and the nature of each policy benefit, the service priority score is automatically calculated. The ranking rules are as follows: emergency intervention services involving personal safety take precedence over basic living security services; basic living security services take precedence over developmental services (such as education and psychology); services with time limits (such as enrollment assistance which must be applied for before the start of the school year) take precedence over services without time limits. The system also outputs the suggested order of service implementation and the suggested start time for each service. S54. SRP Formatted Output and Push: The outputs from steps S51 to S53 are integrated into a formatted service suggestion package document. The service suggestion package document supports three methods: PDF export, in-system viewing, and mobile push. The SRP is also written into the person's electronic case file as baseline data for service records. After the SRP is generated, the process engine is automatically triggered to create the corresponding service process instance and assign the various tasks in the SRP to the to-do queue of the corresponding role.

[0015] Furthermore, an application system is configured based on the aforementioned intelligent information matching method using large language model semantic parsing and dual verification. The application system includes the following functional modules: policy text collection and preprocessing module, large language model policy parsing service module, strategy rule base management module, child profile data management module, formal rule matching engine module, large language model semantic review service module, formal verification module, confidence assessment and manual review diversion module, service suggestion package generation module, service resource database module, and audit traceability log module.

[0016] Furthermore, the application system is deployed using a microservice architecture, with each functional module running as an independent containerized service (Docker Container). RESTful interfaces are uniformly exposed through an API gateway (such as Kong or Nginx), and inter-service communication uses a message queue (Apache Kafka) to achieve asynchronous decoupling, ensuring that time-consuming tasks such as policy parsing, rule matching, and semantic review do not block the main business process. The system is deployed on a municipal government cloud platform, utilizing the computing, storage, and network resources provided by the government cloud.

[0017] Compared with existing technologies, this technical solution has the following advantages: 1. This invention utilizes a domain-fine-tuned large language model to automatically parse welfare policy texts into structured rule data, constructing a machine-executable policy rule base. During the matching phase, a dual verification mechanism is employed, combining formal rule validation and semantic review of the large language model, balancing matching accuracy with the ability to handle ambiguous expressions in policy provisions. Simultaneously, confidence assessment and formal verification of the large language model output ensure the reliability of the final matching results. This method can automatically incorporate newly released policies into the system's rule base within hours, fundamentally solving the problem of delayed policy update transmission.

[0018] 2. This invention uses automatic semantic parsing of a large language model to shorten the time from the release of a new policy to its inclusion in the system's rule base from two to three weeks in the traditional manual coding scheme to a few hours (e.g., the large language model parsing takes about one hour, plus about two to three hours of manual review and confirmation), thus improving the timeliness of policy updates by dozens of times.

[0019] 3. The dual verification mechanism employed in this invention significantly improves the accuracy and coverage of matching. Formal rule verification ensures accurate matching under deterministic conditions (i.e., zero false positives), while the semantic review of the large language model captures policy items missed due to limitations in formal expression (reducing false negatives). The overall matching value is higher than that of conventional pure rule engine solutions. Furthermore, the formal verification mechanism effectively eliminates the illusionary risk of the large language model. By forcibly executing formal verification based on factual data after the model's semantic output, it compares the model's claimed matching conclusions with the actual attribute values ​​one by one, ensuring that every matching result in the final output has traceable factual basis.

[0020] 4. The versioned management and audit traceability mechanism of the policy rule base adopted in this invention meets the compliance requirements of administrative decision-making. The complete process of each matching judgment (including the comparison results of each condition, the reasoning process of the large language model, the conclusions of formal verification, and the final output) is recorded in the audit log, supporting post-event traceability and inspection, and providing a complete chain of technical evidence for administrative accountability. Simultaneously, the automatic generation of service suggestion packages frees grassroots staff from tedious policy inquiries and matching judgments, saving an estimated one to two hours per person per day. This freed-up time can be used for actual child visits and service work. Furthermore, standardized matching output eliminates judgment discrepancies between different staff members, ensuring service fairness. Attached Figure Description

[0021] Figure 1 This is a flowchart of the intelligent information matching method based on semantic parsing and dual verification of a large language model, as described in Example 1. Detailed Implementation

[0022] The present invention is further illustrated by the following examples, but these are not intended to limit the invention. Specific experimental conditions and methods not specified in the following examples are generally conventional methods well known to those skilled in the art.

[0023] Example 1: An intelligent information matching method based on semantic parsing and dual verification of a large language model, taking child welfare policy matching as an example, includes the following steps: S1. Policy Text Collection and Preprocessing: Policy texts are collected and incorporated into the database. The text format is then standardized by converting PDF or Word files to plain text while preserving paragraph structure. Next, metadata is annotated, where administrators or automated identification tools annotate policy documents with the policy name, issuing agency, release date, effective date, expiration date, policy level (national / provincial / municipal), and applicable region. Then, clauses are segmented according to the policy's chapters and clause structure, dividing the entire text into independent clause segments. Each segment retains its clause number from the original document, such as "Article 3, Paragraph 2." Finally, deduplication and version association are performed. If a policy is detected as a revised version of a previously entered policy, the historical version is automatically associated, and the changed clauses are marked. The following three methods are used for policy text collection: Method 1 is to regularly crawl government gazette websites, policy databases, and official information release platforms of government departments to detect newly released or revised policy documents, and then automatically download and merge them into the database; Method 2 is to deploy a web management interface that allows administrators to manually upload policy documents in PDF or Word format; Method 3 is to use an API connection channel to connect with the policy release interface of the superior government information sharing platform to receive policy change information pushed in real time. S2. Using a large language model, the policy clause text obtained after processing in step S1 is parsed into structured policy structured triples (PSTs). The construction of the large language model includes the following steps: S21. Domain Fine-tuning Data Preparation: Thirty representative policy clauses are selected from the policy texts in the database. Two domain experts independently and manually parse these clauses into structured triples, forming a comparison sample set of policy texts and structured triples. If the two experts' analysis results are inconsistent, a discussion is organized to reach a consensus, and the clauses are used as the final annotation. The comparison sample set includes the following typical scenarios: simple policies with clear conditions (such as age restrictions and household registration requirements), nested policies with complex conditions (such as multiple conditions with "or" and "and" logical relationships), policies containing vague expressions (such as "families with genuine difficulties" or "identified as needing assistance"), and policies containing exclusion conditions (such as "those who have already received the same type of subsidy will not receive it again"). S22. Selection and Deployment of Large Language Models: Select a Chinese base large language model (such as the Qwen series, ChatGLM series, or Baichuan series) with a parameter scale between 7B and 70B. Deploy it on an inference server equipped with at least one GPU (with a video memory of no less than 24GB, such as NVIDIA A10 or RTX 4090). Then, use the control sample set obtained in step S21 to perform domain adaptation fine-tuning. During the domain adaptation fine-tuning process, only train the additional parameters that account for 0.5% of the total parameters, without changing the original parameters of the base model. The training time is 3 hours on a single GPU. After the domain adaptation fine-tuning is completed, evaluate the parsing accuracy of the model on the reserved test set. The parsing accuracy at the clause level should be no less than 90%, and the parsing accuracy at the conditional field level should be no less than 95%. S23. Prompt Template Configuration: Configure a prompt template for the policy structured parsing task. The prompt template includes the following elements: task instructions (explicitly requiring the model to parse the input policy clauses into structured triples), output format specifications (defining the output structure using JSON Schema, including arrays of applicable conditions, treatment standards, and processing procedures, with each applicable condition containing field names, operators, thresholds, and logical connectors), guidance on handling fuzzy conditions (requiring the model to provide a recommended formal coding scheme for fuzzy expressions, while also marking fuzzy tags to indicate that the condition requires manual review), and 3-5 parsing examples (Few-Shot Learning, selecting different types of examples from labeled data for the model's reference). S24. Batch parsing execution: Input the policy clause text obtained after step S1 into the adjusted large language model in step S22 one by one, and use the prompt template described in step S23 to output a JSON-formatted structured triple for each policy clause. During the parsing process, record the generation time of each result and the internal confidence information of the model. S25. Confidence Assessment and Manual Review Triage: For each parsing result, a comprehensive confidence score is calculated based on the concentration of the probability distribution of the model output, whether the output structure conforms to the predefined JSON Schema, whether the condition fields correspond to the existing standard attribute names in the CPDO (Personnel Object to be Matched), and the model's marking of fuzzy conditions. Results with a confidence score higher than 0.90 are automatically entered into the policy rule base. Results with a confidence score between 0.60 and 0.90 enter the manual review queue, where domain experts confirm or correct each result on the web review interface before entering the database. Results with a confidence score lower than 0.60 are marked as parsing anomalies, triggering an alarm to notify operations personnel to check the text quality of the policy clause or whether the prompt template needs adjustment. During the initial deployment of the system, it is expected that approximately 60% of the parsing results can be directly entered into the database, 35% will enter the review queue, and 5% will be marked as anomalies. As domain fine-tuning data accumulates and the model is continuously optimized, the proportion of results directly entered into the database will gradually increase. S26. Version Update of Policy Rule Base: The structured triples confirmed in step S25 are written into the policy rule base. The policy rule base adopts version management. Each policy change (such as addition, revision or repeal) generates a new rule base version number, recording the change timestamp, change type, policy clauses involved and differences in content before and after the change. When the matching engine is running, it can specify to use a specific version of the rule base (the latest version is used by default) to ensure that the matching judgment is based on the correct policy version. After the rule base is updated, the matching engine automatically hot-loads the new version of the rule data without restarting the service. S3. Formal Rule Matching (Double Validation Phase 1): When policy matching is required for a child in distress, the system first performs formal rule matching. The inputs to this phase are the latest versions of the child profile data object (CPDO) and the policy rule base (PRB) for that child, and the output is the formal matching result set. The specific steps are as follows: S31. Extraction of profile data objects of the target person: Load the child profile data object (CPDO) of the target child from the database of children in distress, extract all attribute fields and their current values, and mark the missing attribute fields in the CPDO (such as the psychological health assessment data of a child has not been collected) as unknown; The aforementioned Child Profile Data Object (CPDO) is a standardized data object maintained for the target child, aggregating all related information of the target child in various departmental systems. Specifically, it includes attribute fields in the following dimensions: basic information dimension (such as name, ID number, date of birth, gender, ethnicity, registered address, current residence address), family information dimension (such as family member list, identity status of each member, family income, housing type), health information dimension (such as disease diagnosis records, disability level, rehabilitation needs, vaccination status), education information dimension (such as school attended, grade, attendance rate, dropout status), service information dimension (such as list of policies enjoyed, service records, assessment history), and special marker dimension (such as whether it is a left-behind child, whether it is a minority, guardian status, etc.). S32. Rule-by-rule matching: Traverse all policy rules in the policy rule base and execute the following matching logic for each rule: Check each condition in the set of applicable conditions of the rule in turn, map the attribute field name in the condition to the corresponding attribute field in CPDO, retrieve the current value of the attribute, and compare it with the threshold in the condition according to the specified comparison operator. If the corresponding attribute value in CPDO is unknown, the judgment result of the condition is uncertain. All conditions are combined and judged according to the logical connector ("AND" "OR") specified in the rule. When the combined judgment result of all conditions is satisfied, the policy rule enters the formal matching result set. When the judgment result is not satisfied, the rule is excluded. When the judgment result contains uncertain conditions, the rule enters the pending set and is passed to the semantic review stage for processing along with the uncertain condition information. S33. Formal Matching Result Output: Output three sets, including the confirmed match set (a list of policy rules that meet all conditions), the confirmed exclusion set (a list of policy rules that do not meet at least one condition), and the pending set (a list of policy rules that cannot be determined). Each result in each set is accompanied by a detailed matching process log, which records the attribute name of each condition, the actual value in CPDO, the threshold required by the rule, the comparison operator, and the single-item judgment result. S4. Semantic Review of the Large Language Model (Second Stage of Dual Verification): The semantic understanding capabilities of the large language model are used to perform a second review and supplement on the output of step S3. The results of the confirmed matching set and the confirmed exclusion set in step S3 are used as inputs, and the large language model performs semantic-level review and checks. At the same time, the results of the pending set in step S3 are used by the large language model to perform semantic reasoning to make a final judgment. The specific steps are as follows: S41. Semantic Review Context Construction: Construct a Semantic Review Context (SRC) for each matching call. The SRC contains the following information: a complete profile description of the target (converting the structured attribute values ​​of CPDO into natural language descriptions, such as "This child, male, 12 years old, Zhuang ethnicity, registered address is D Village, C Town, B County, A City. His father died in a traffic accident in 2023, his mother has been missing for more than two years, and he is currently under the guardianship of his 65-year-old grandmother, who suffers from hypertension. The family's economic resources are subsistence allowance and the grandmother's rural pension. The child is in the sixth grade of C Town Central Primary School, with an attendance rate of 92% this semester. In March 2024, he was assessed as a Level 2 (Orange) risk level"), the three sets output in step S3 and their matching process logs, and the full text of the relevant policy clauses (retrieving the full text of the corresponding clauses from the policy text library). S42. Hint Construction and Model Invocation: Combine the SRC constructed in step S41 with the dedicated semantic review hint template and input it into the large language model. The semantic review hint template requires the model to perform the following three review tasks: Task A is omission checking, which involves the model reviewing and confirming policy items in the exclusion set to determine if any items have been incorrectly excluded due to limitations in formal expression. (For example, focusing on scenarios such as: policy conditions containing vague expressions, such as a family facing genuine hardship but using strict numerical thresholds in formal coding, while the child's overall situation is indeed difficult even if the numerical threshold is not met; complex logical relationships between policy conditions, such as nested "or" and "and" combinations, where the logical structure may have been simplified in formal coding; and catch-all clauses such as policies applicable to other special circumstances, which are usually ignored in the formalization stage. If the model finds a suspected omission, it outputs the item and the reason for its omission.) Task B is a false positive check, whereby the model reviews and confirms policy items in the matching set to determine whether there are any items that formally meet the conditions but are not applicable in substance. (For example, it focuses on: implicit exclusion conditions described in natural language in policy provisions that are not formalized, such as not receiving duplicate subsidies if already receiving similar ones; this condition may not have a corresponding standard field in CPDO; there is a difference between the policy's spirit and the literal conditions, such as a policy aimed at helping families facing temporary difficulties due to unforeseen events, where the family's current economic indicators meet the criteria but their difficulties stem from long-term structural problems rather than unforeseen events; if the model finds a suspected false positive item, it outputs the item and the reason for its exclusion). Task C is the decision-making of pending items, which means that the model reviews the policy items in the pending set, uses the profile description and the original text of the policy clauses to perform semantic reasoning, and makes a judgment of matching, non-matching or recommending manual confirmation for each pending item, with an explanation of the reasoning process attached. S43. Formal Verification: For each judgment result output by the large language model in step S42, perform formal verification: Compare the omissions claimed by the model (items that the model believes should match but were excluded in the first stage) with the actual attribute values ​​in the target child's CPDO. If the model claims that the person meets a certain condition, but the corresponding attribute value in the CPDO does not actually meet the formal requirements of that condition, then the item is rejected by formal verification and is not included in the final result. The omissions and false positives that are still retained after formal verification, together with the items that the model judged to match in the pending items, are marked as semantic supplementation results. This formal verification step is the key mechanism of this invention to ensure the reliability of the output of the large language model. Through the dual guarantee of model reasoning and fact verification, the illusory output of the model is eliminated. S44. Confidence Level Secondary Assessment and Triage: For each item in the semantic supplementation results, a comprehensive confidence score is calculated based on the model's output probability, the logical completeness of the reasoning process, and the pass rate of formal verification. Items with a confidence level higher than 0.90 are directly included in the final matching results. Items between 0.70 and 0.90 are marked as requiring manual review and are pushed to the grassroots service personnel responsible for the person in charge of the item for confirmation, along with the model's reasoning explanation. Items with a confidence level lower than 0.70 are marked as low confidence and are only presented as reference information and are not included in the formal matching results. S5. Service Advisory Package Generation and Output: The final matching results processed in step S4 are integrated into a Service Advisory Package (SRP) and output to frontline service personnel. The specific steps are as follows: S51. Compilation of Policy Benefit List: Summarize all confirmed matching items and semantically supplemented matching items in the final matching results, and classify and arrange them according to two dimensions: policy level (e.g., national, provincial, municipal) and benefit type (e.g., basic living security, medical assistance, education subsidies, rehabilitation services, psychological care, housing assistance, legal aid). Each policy is marked with the policy name and document number, a summary of applicable conditions (e.g., indicating which conditions the child meets), benefit standards (e.g., specific subsidy amount or service content), application portal (e.g., online application link or offline acceptance window address), and a list of required materials. For semantically supplemented items that are recommended for manual review, they are marked separately in the list, and the reasoning explanation of the model is attached for reference by grassroots staff. S52. Service Resource Recommendation: Based on the child's need tags (extracted from CPDO and risk assessment results, such as "psychological counseling needs," "rehabilitation training needs," "educational assistance needs," etc.) and the area information, a matching search is performed in the service resource database. The service resource database includes information on registered social service organizations, professional service projects, service capabilities, service areas, contact information, and current queuing status within the jurisdiction. The search results are sorted by matching degree and geographical distance, and the top three recommended organizations under each need category are selected, with the organization name, service content, address, contact number, and estimated waiting time noted. S53. Service Priority Ranking: Based on the individual's risk level and the nature of each policy benefit, the service priority score is automatically calculated. The ranking rules are as follows: emergency intervention services involving personal safety take precedence over basic living security services; basic living security services take precedence over developmental services (such as education and psychology); services with time limits (such as enrollment assistance which must be applied for before the start of the school year) take precedence over services without time limits. The system also outputs the suggested order of service implementation and the suggested start time for each service. S54. SRP Formatted Output and Push: The outputs from steps S51 to S53 are integrated into a formatted service suggestion package document. The service suggestion package document supports three methods: PDF export, in-system viewing, and mobile push. The SRP is also written into the person's electronic case file as baseline data for service records. After the SRP is generated, the process engine is automatically triggered to create the corresponding service process instance and assign the various tasks in the SRP to the to-do queue of the corresponding role.

[0024] Example 2: Following the method described in Example 1, taking a twelve-year-old Zhuang child named Xiaoming (pseudonym) as an example, the complete matching process of the present invention is illustrated; Xiaoming's CPDO data is as follows: Male, 12 years old, Zhuang ethnicity, registered address: D Village, GL Town, B County, City A. His father died in a traffic accident in 2023, and his mother left home in 2022 and has not been found since. He is currently under the guardianship of his 65-year-old grandmother (who suffers from hypertension and arthritis). The family's annual income is about 8,000 yuan (mainly from minimum living allowance and his grandmother's rural pension). He is a sixth-grade student at GL Town Central Primary School. His attendance rate this semester is 88% (lower than the school average of 95%). The risk assessment result in March 2024 is Level 2 (orange). His needs include psychological counseling, educational assistance, and living allowance. Formal rule matching is performed: The rule engine traverses all 47 policies and 236 rules in the policy rule base, and compares Xiaoming's CPDO attribute value with the applicable conditions of each rule one by one; The matching results are as follows: The confirmed matching set contains eighteen policies (including basic living security for orphans, medical assistance for children in distress, and the nutrition improvement program for students in rural compulsory education, etc.); the confirmed exclusion set contains twenty-six policies (excluded due to reasons such as age mismatch, disability level mismatch, and household registration area mismatch); and the pending set contains three policies (which cannot be determined due to some conditions involving missing attribute values ​​in CPDO, such as the guardian losing the ability to work, i.e., Xiaoming's grandmother has a chronic disease but has not undergone a work capacity assessment, and the corresponding attribute value is unknown). Perform semantic review of the large language model: The system constructs a semantic review context (SRC), combines Xiaoming's complete profile description, matching logs from three sets, and relevant policy texts, and inputs them into the large language model. The model's review results are as follows: Task A (Omission Check): The model discovered that one policy (Temporary Relief Fund for Children in Difficult Circumstances) was incorrectly excluded from the exclusion set. The reason for the exclusion was that one of the applicable conditions of this policy was that the family encountered sudden and urgent difficulties. In the formal coding, this was set to the family's annual income being less than 1.5 times the local minimum living standard (i.e., 12,000 yuan). Although Xiaoming's family's annual income of 8,000 yuan met this condition, another condition, "the sudden event occurred within 6 months," was marked as not met because the system did not record the specific time of the father's death (the CPDO only recorded the father's status as "deceased," but not the time of death). The model believed that Xiaoming's father had been dead for less than two years and his mother was missing, and the family had indeed encountered sudden difficulties. It suggested that this condition be included in the matching. The formal verification step confirmed that in Xiaoming's CPDO, the father's status was indeed "deceased," the mother's status was indeed "missing," and the family income of 8,000 yuan was indeed lower than the 12,000 yuan threshold. The model's analysis was based on facts. This result was marked as semantic supplementary matching with a confidence level of 0.87 and was classified into the category of suggested manual review. Task B (False Positive Check): The model found that the "preschool education subsidy" policy in the confirmed match set was a false positive. Although Xiaoming's age (12 years old) was coded as ≤18 years old in the formal condition (satisfied), the actual applicable target of the policy is clearly limited to the preschool education stage (i.e., kindergarten), while Xiaoming is already in the sixth grade of primary school. The formal coding simply coded the applicable age as ≤18 years old instead of the more precise 3-6 years old, which led to a false positive. The formal verification step confirmed that Xiaoming's education stage is the sixth grade of primary school, which does not belong to the preschool education stage. This result was formally verified and removed from the confirmed match set, and classified into the semantic exclusion category. Task C (Decision on Pending Items): The model performs semantic reasoning on each of the three pending policies. For the "Guardian Loss of Working Capacity Subsidy," the model analysis concludes that although Xiaoming's grandmother suffers from hypertension and arthritis, these two diseases typically do not constitute the criteria for loss of working capacity, thus the model determines it as a mismatch. For the "Special Funding for Ethnic Minority Education," the model confirms that Xiaoming is Zhuang and studies in an ethnic minority area, meeting all the conditions of the policy, thus the model determines it as a match with a confidence level of 0.93, and it is directly included in the final result. For the "Psychological Care Services for Children in Difficult Circumstances," the model considers Xiaoming's low attendance rate and orange risk assessment, indicating a significant need for psychological care. However, the policy's applicable conditions, specifically the assessment confirming a need for psychological services, do not have a corresponding structured field in CPDO, so the model recommends manual confirmation with a confidence level of 0.78. Service suggestion packages were generated, and the final matching results are summarized as follows: Twenty policies were confirmed to match (eighteen formally matched, one semantically supplemented special subsidy for minority education, and one formally verified temporary relief fund awaiting manual confirmation); one policy was semantically excluded (preschool education subsidy); two policies were recommended for manual confirmation (temporary relief fund and psychological care services); the SRP was arranged according to policy level and benefit type, with each policy's applicable conditions summary, benefit standards, and application portal marked; simultaneously, based on Xiaoming's needs tags (psychological counseling, educational assistance, living allowance), three psychological counseling institutions, two educational assistance projects, and one legal aid hotline were recommended from the service resource database; the service priority ranking was suggested as follows: first priority is to process applications for basic living security and temporary relief funds for orphans (economic security); second priority is to connect with psychological counseling services (mental health); third priority is to apply for educational assistance projects and nutrition improvement programs (educational development); after the SRP was generated, it was pushed to the mobile workbench of the children's director in GL town responsible for Xiaoming, and a complete audit log of this matching was recorded in the electronic case file.

[0025] As can be seen from the above embodiments, the dual verification mechanism of the present invention simultaneously detects an omitted policy (temporary relief fund) and an incorrectly matched policy (preschool education subsidy) during a single matching process, and makes a reasonable determination on the two pending policies. This triple protection mechanism cannot be achieved in a single rule engine solution or a single large language model question answering solution.

[0026] Example 3: The intelligent information matching method based on semantic parsing and dual verification described in Example 1 is applied to configure an application system. The application system includes the following functional modules: policy text collection and preprocessing module, large language model policy parsing service module, strategy rule base management module, child profile data management module, formal rule matching engine module, large language model semantic review service module, formal verification module, confidence assessment and manual review diversion module, service suggestion package generation module, service resource database module, and audit traceability log module. The application system is deployed using a microservice architecture. Each functional module runs as an independent containerized service (Docker Container). RESTful interfaces are uniformly exposed through an API gateway (such as Kong or Nginx). Inter-service communication uses message queues (Apache Kafka) to achieve asynchronous decoupling, ensuring that time-consuming tasks such as policy parsing, rule matching, and semantic review do not block the main business process. The system is deployed on a municipal government cloud platform, utilizing the computing, storage, and network resources provided by the government cloud.

[0027] Example 4: Deploy the system as described in Example 3, and then take the initial database creation of 47 existing welfare policies for children in difficult circumstances in a certain city as an example to illustrate the entire process of policy database entry in this invention, as follows: After the system was deployed, administrators uploaded PDF files of 47 policies in batches through the web management interface; the preprocessing module automatically converted the PDFs into plain text and segmented them according to the clause structure, resulting in a total of 236 independent clause text segments; The large language model policy parsing service processes each clause sequentially, with an average processing time of about 25 seconds per clause (including model inference and confidence assessment). The total time for batch parsing of all clauses is about 90 minutes. After parsing, the confidence assessment module categorized the 236 results: 148 results (approximately 63%) with a confidence level above 0.90 were automatically written into the policy rule base; 79 results (approximately 33%) with a confidence level between 0.60 and 0.90 were placed in the manual review queue; and 9 results (approximately 4%) with a confidence level below 0.60 were marked as parsing anomalies. Domain experts reviewed each of the 79 pending results on the review interface, with an average review time of approximately two minutes per result (those that did not require modification were directly clicked "Pass," while those requiring correction were edited on the interface and then submitted), with a total review time of approximately two and a half hours. After investigation, it was found that five of the nine abnormal results were due to blurry printing of the original policy text, which caused OCR recognition errors. After re-uploading a clear version, the OCR was successful. The other four were due to overly general wording of the policy clauses (such as "implemented in accordance with relevant national regulations"), which could not be interpreted as specific applicable conditions. These were manually coded and then entered into the database. The total time for the initial database construction was approximately five hours, which is far less than the three months of the traditional manual coding scheme.

[0028] Three months after the database was built, the provincial civil affairs department released a new policy, the "Notice on Further Strengthening Mental Health Care Services for Children in Difficult Circumstances." The policy text collection module automatically downloaded the policy PDF file and added it to the database after detecting an update on the government gazette website. The preprocessing module segmented it into eight clauses. A large language model performed structured parsing, with six clauses having a confidence level higher than 0.90 and automatically added to the database, while two clauses entered the review queue. Domain experts completed the review and confirmation within 30 minutes of receiving the review notification. From policy release to the availability of updated policy rules, the entire process took approximately three hours. The matching engine automatically hot-loaded the new version of the rule data without requiring a service restart. When grassroots staff perform policy matching for the children in difficult circumstances under their care, the system automatically includes this new policy in the matching scope.

[0029] When used in the aforementioned application system, the deployment requirements for the large language model inference service are as follows: The model inference service is deployed independently on inference nodes equipped with GPUs. The minimum hardware configuration is a GPU with at least 24GB of dedicated video memory (such as NVIDIA A10, A30, or RTX 4090 level), 64GB of system memory, and 500GB of SSD storage. The inference service is deployed using a model service framework (such as vLLM, TGI, or Triton Inference Server), supporting request batching, streaming output, and hot model updates. By default, the inference service runs quantized models (quantized to INT8 or INT4 precision using GPTQ or AWQ), increasing inference speed by two to three times and reducing video memory usage by more than 50% without significantly affecting accuracy, enabling a single consumer-grade GPU to support online services for 7B to 14B level models.

[0030] The policy rule base is stored using a relational database (such as PostgreSQL or MySQL), with the core data tables designed as follows: Policy Metadata Table (stores metadata such as policy name, document number, issuing agency, effective date, expiration date, level, and region); Policy Clause Table (stores the original text, clause number, and policy ID of each clause); Structured Rule Table (stores the PST parsing results of each clause, storing arrays of applicable conditions, treatment standards, and processing procedures in JSON format); Rule Version Table (stores the version number, timestamp, change type, and JSON Diff of the differences before and after each change); Review Record Table (stores the manual review status, reviewer, review time, and modification content of each parsing result). The rule matching engine caches the structured data of all effective rules in memory (typically no more than a few thousand rules, with memory usage below 100MB), supporting millisecond-level matching responses.

[0031] The data for the Child Profile Data Object (CPDO) originates from the Information Database of Children in Difficult Circumstances. This database aggregates data from departments such as civil affairs, public security, education, health, disabled persons' federation, and justice. CPDO uses a wide table structure for storage, with the citizen's ID number as the primary key, and includes approximately 120 standard attribute fields across six dimensions. CPDO data maintains near real-time synchronization with the source systems of various departments through a data synchronization pipeline (based on the CDC mechanism or scheduled batch synchronization), with a latency not exceeding 24 hours.

[0032] The service resource database contains information on registered social service organizations and professional service projects within the jurisdiction. Each record includes: organization name, unified social credit code, organization type (social work organization, psychological counseling organization, rehabilitation organization, legal aid organization, etc.), service content tag list, service area (accurate to the township / street level), maximum service capacity (monthly service visits), current waiting list, contact information (telephone and address), and service quality rating (based on historical service evaluations). The service resource database is regularly maintained and updated by the civil affairs department, with a recommended update frequency of at least once a month.

[0033] The performance requirements for the application system are as follows: the end-to-end response time for a single policy matching request (including two stages: formal rule matching and semantic review of the large language model) shall not exceed 15 seconds (of which the formal matching stage shall not exceed 500 milliseconds, the semantic review of the large language model shall not exceed 10 seconds, and the remainder is for data transmission and formatting processing time); the average time for the policy parsing service to process a single policy clause shall not exceed 30 seconds; the number of concurrent matching requests supported by the system shall not be less than 50; the number of rule entries supported by the policy rule base shall not be less than 1,000 (covering all current policies at the national, provincial, and municipal levels and policies expected to be added in the next five years).

[0034] The application system's operation and maintenance management plan is as follows: Incremental retraining of the large language model is performed quarterly, using manually reviewed and corrected data accumulated in the current quarter as new training samples. After training and testing are completed on a spare GPU, the model is released to the production environment after review and confirmation by the operations team. Automatic backup of the policy rule base is performed daily at midnight, retaining a full backup of the most recent 90 days. System operation logs (including matching request logs, model call logs, review operation logs, and anomaly alarm logs) are centrally collected to a log management platform (such as ELK Stack), supporting full-text search and analysis. Health check probes (Liveness Probe and Readiness Probe) are deployed in the system, automatically restarting container instances when service anomalies are detected.

[0035] The construction and implementation of the application system consists of the following eight steps: Step 1: Deploy the basic environment, including applying for government cloud resources, configuring network policies, building a container orchestration platform, and initializing the database; Step 2: Deploy the data synchronization pipeline, configure access adapters for data sources from various departments, and complete the first full synchronization of children's profile data; Step 3: Deploy the large language model inference service, complete the download of the base model, domain fine-tuning, and performance testing; Step 4: Import current policy documents, perform the first batch parsing, and complete the initial database construction of the policy rule base; Step 5: Deploy the rule matching engine and semantic review service, and use historical case data to test matching accuracy and optimize parameters; Step 6: Deploy the service resource database and complete the input of information on service institutions within the jurisdiction; Step 7: Develop and deploy the front-end application (including the management backend web interface, the grassroots staff workbench, and the mobile APP); Step 8: Conduct a one-month trial run in the pilot area, collect feedback, make optimizations and adjustments, and then gradually promote it to the entire city.

[0036] The continuous optimization mechanism of the application system is as follows: During daily operation, the system automatically collects manual feedback data on matching results. When frontline service personnel perform "confirmation," "correction," or "mark as error" operations on a matching result, the system associates the feedback record with the corresponding matching log and model inference record. Each quarter, the operations team summarizes all manual feedback data for the quarter, filters out cases where model judgments have been corrected or marked as errors, analyzes the reasons for the errors (such as inaccurate prompt templates, insufficient coverage of domain fine-tuning data, or ambiguity in policy clauses), and updates the domain fine-tuning training set and prompt templates accordingly, performing incremental retraining of the model. This feedback loop mechanism ensures that the system's matching accuracy continuously improves with the accumulation of usage time. During the pilot operation phase, the system's overall F1 score for the first month is expected to be approximately 92%, and after three to four rounds of quarterly optimization iterations, it can be stably improved to over 95%.

[0037] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. An intelligent information matching method based on semantic parsing of a large language model and dual verification, characterized in that: Includes the following steps: S1. Policy Text Collection and Preprocessing: Collect policy texts and incorporate them into the database. Then, standardize the text format by converting PDF or Word files to plain text format while preserving paragraph structure. Next, perform metadata annotation, followed by clause segmentation. According to the policy's chapters and clause structure, the entire text is divided into independent clause text segments, with each segment retaining its clause number from the original file. Then, deduplication and version association are performed. If a policy is detected as a revised version of a previously entered policy, the historical version is automatically associated, and the changed clauses are marked. S2. Using a large language model, the policy clause text obtained after processing in step S1 is parsed into structured policy structured triples. The construction of the large language model includes the following steps: S21. Domain Fine-tuning Data Preparation: Select twenty to thirty representative policy clauses from the policy texts in the database. Two domain experts independently and manually parse these clauses into structured triples to form a comparison sample set of policy texts and structured triples. If the two experts' parsing results are inconsistent, organize a discussion to reach a consensus and use it as the final annotation. S22. Selection and Deployment of Large Language Model: Select a Chinese base large language model with a parameter scale between 7B and 70B, deploy it on an inference server equipped with at least one GPU, and then use the control sample set obtained in step S21 for domain adaptation fine-tuning. During the domain adaptation fine-tuning process, only 0.1% to 1% of the additional parameters accounting for the total parameters are trained, without changing the original parameters of the base model. The training time is 2 to 4 hours on a single GPU. After the domain adaptation fine-tuning is completed, evaluate the parsing accuracy of the model on the reserved test set. The parsing accuracy at the clause level should not be less than 90%, and the parsing accuracy at the condition field level should not be less than 95%. S23. Prompt Template Configuration: Configure a prompt template for the policy structured parsing task. The prompt template includes the following elements: task instructions, output format specifications, guidance on handling fuzzy conditions, and 3 to 5 parsing examples. S24. Batch parsing execution: Input the policy clause text obtained after step S1 into the adjusted large language model in step S22 one by one, and use the prompt template described in step S23 to output a JSON-formatted structured triple for each policy clause. During the parsing process, record the generation time of each result and the internal confidence information of the model. S25. Confidence Assessment and Manual Review Triage: For each parsing result, a comprehensive confidence score is calculated based on the concentration of the probability distribution of the model output, whether the output structure conforms to the predefined JSON Schema, whether the condition fields correspond to the existing standard attribute names in CPDO, and the model's labeling of fuzzy conditions. Results with a confidence score higher than 0.90 are automatically entered into the policy rule base. Results with a confidence score between 0.60 and 0.90 enter the manual review queue, where domain experts confirm or correct each result on the web review interface before entering the database. Results with a confidence score lower than 0.60 are marked as parsing anomalies, triggering an alarm to notify operations personnel to check the text quality of the policy clause or whether the prompt template needs adjustment. During the initial deployment of the system, it is expected that approximately 60% of the parsing results can be directly entered into the database, 35% will enter the review queue, and 5% will be marked as anomalies. As domain fine-tuning data accumulates and the model is continuously optimized, the proportion of results directly entered into the database will gradually increase. S26. Version Update of Policy Rule Base: The structured triples confirmed in step S25 are written into the policy rule base. The policy rule base adopts version management. Each policy change generates a new rule base version number, recording the change timestamp, change type, policy clauses involved, and differences in content before and after the change. When the matching engine is running, it can specify to use a specific version of the rule base to ensure that the matching judgment is based on the correct policy version. After the rule base is updated, the matching engine automatically hot-loads the new version of the rule data without restarting the service. S3. Formal rule matching: When policy matching is required, formal rule matching is performed, taking the profile data of the person to be matched and the latest version of the policy rule base as input, and the output is a formal matching result set; S4. Semantic review of the large language model: The semantic understanding ability of the large language model is used to conduct a second review and supplement to the output in step S3. The results of the confirmed matching set and the confirmed exclusion set in step S3 are used as inputs, and the large language model performs semantic review and check. At the same time, the results of the pending set in step S3 are used to perform semantic reasoning to make a final judgment. S5. Service suggestion package generation and output: The final matching results after step S4 are integrated into a service suggestion package and output to the front-line service personnel.

2. The intelligent information matching method according to claim 1, characterized in that: In step S1, the following three methods are used to collect policy texts: Method 1 is to periodically crawl government gazette websites, policy databases, and official information release platforms of government departments to detect newly released or revised policy documents, and then automatically download and merge them into the database; Method 2 is to set up a web management interface that allows administrators to manually upload policy documents in PDF or Word format; Method 3 is to use an API connection channel to connect with the policy release interface of the superior government information sharing platform to receive policy change information pushed in real time.

3. The intelligent information matching method according to claim 1, characterized in that: The metadata annotation mentioned in step S1 is used by administrators or automatic identification tools to annotate policy documents with policy name, issuing agency, release date, effective date, expiration date, policy level, and applicable region.

4. The intelligent information matching method according to claim 1, characterized in that: The control sample set mentioned in step S21 includes the following typical scenarios: simple policies with clear conditions, policies with vague expressions, and policies with exclusion conditions.

5. The intelligent information matching method according to claim 1, characterized in that: In step S3, when policy matching is required, formal rule matching is performed, taking the profile data of the person to be matched and the latest version of the policy rule base as input, and outputting a formal matching result set. The specific steps are as follows: S31. Extraction of profile data objects of the person to be matched: Based on the collected profile data objects of the person to be matched, extract all attribute fields and their current values. For attribute fields missing in the profile data objects, mark them as unknown. S32. Rule-by-rule matching: Traverse all policy rules in the policy rule base and execute the following matching logic for each rule: Check each condition in the set of applicable conditions of the rule in turn, map the attribute field name in the condition to the corresponding attribute field in the profile data object, retrieve the current value of the attribute, and compare it with the threshold in the condition according to the specified comparison operator. If the corresponding attribute value in the profile data object is unknown, the judgment result of the condition is uncertain. All conditions are combined and judged according to the logical connector specified in the rule. When the combined judgment result of all conditions is satisfied, the policy rule enters the formal matching result set. When the judgment result is not satisfied, the rule is excluded. When the judgment result contains uncertain conditions, the rule enters the pending set and is passed to the semantic review stage for processing along with the uncertain condition information. S33. Formal Matching Result Output: Output three sets, including a confirmed match set and a confirmed exclusion set. Each result in each set is accompanied by a detailed matching process log, which records the attribute name of each condition, the actual value in the profile data object, the threshold required by the rule, the comparison operator, and the single judgment result.

6. The intelligent information matching method according to claim 5, characterized in that: The profile data object mentioned in step S3 is a standardized data object maintained for the person to be matched, which gathers all the related information of the person to be matched in various departmental systems. The profile data object includes attribute fields of the following dimensions: basic information dimension, family information dimension, health information dimension, education information dimension, service information dimension, and special marker dimension.

7. The intelligent information matching method according to claim 1, characterized in that: In step S4, the semantic understanding capabilities of the large language model are used to perform a second review and supplement to the output of step S3. The results of the confirmed matching set and confirmed exclusion set in step S3 are used as input, and the large language model performs semantic-level verification. At the same time, the results of the pending set in step S3 are used by the large language model to perform semantic reasoning to make a final judgment. The specific steps are as follows: S41. Semantic Review Context Construction: Construct a semantic review context for each matching call. The SRC contains the following information: a complete profile description of the target, the three sets output in step S3 and their matching process logs, and the original text of relevant policy clauses. S42. Hint Construction and Model Invocation: Combine the SRC constructed in step S41 with the dedicated semantic review hint template and input it into the large language model. The semantic review hint template requires the model to perform the following three review tasks: Task A is omission check, which is to review and confirm the policy items in the exclusion set of the model and determine whether there are any items that have been incorrectly excluded due to the limitations of formal expression; Task B is a false positive check, which involves the model review confirming policy items in the matching set to determine whether there are any items that formally meet the conditions but are not applicable in substance. Task C is the decision-making of pending items, which means that the model reviews the policy items in the pending set, uses the profile description and the original text of the policy clauses to perform semantic reasoning, and makes a judgment of matching, non-matching or recommending manual confirmation for each pending item, with an explanation of the reasoning process attached. S43. Formal verification: Perform formal verification on each judgment result output by the large language model in step S42: compare the omissions claimed by the model with the actual attribute values ​​in the CPDO of the person to be matched one by one; the omissions and false positives that are still retained after formal verification, together with the items that the model judged to be matched in the pending items, are marked as semantic supplement results. S44. Secondary Confidence Assessment and Triage: For each item in the semantic supplementation results, a comprehensive confidence score is calculated based on the model's output probability, the logical completeness of the reasoning process, and the pass rate of formal verification. Items with a confidence score higher than 0.90 are directly included in the final matching results. Items between 0.70 and 0.90 are marked as requiring manual review and are pushed to the grassroots service personnel responsible for the person in charge of the item for confirmation, along with the model's reasoning explanation. Items with a confidence score lower than 0.70 are marked as low confidence and are only presented as reference information and are not included in the formal matching results.

8. The intelligent information matching method according to claim 1, characterized in that: In step S5, the final matching results processed in step S4 are integrated into a service suggestion package and output to the frontline service personnel. The specific steps are as follows: S51. Compilation of Policy Benefits List: Summarize all confirmed matching items and semantically supplemented matching items in the final matching results, and classify and arrange them according to two dimensions: policy level and benefit type. Each policy is marked with the policy name and document number, summary of applicable conditions, benefit standard, application portal and list of required materials. For semantically supplemented items that are recommended for manual review, they are marked separately in the list, and the reasoning explanation of the model is attached for reference by grassroots staff. S52. Service Resource Recommendation: Based on the person's needs tags and location information, a matching search is performed in the service resource database. The service resource database contains information on registered social service organizations, professional service projects, service capabilities, service areas, contact information, and current queuing status within the jurisdiction. The search results are sorted by matching degree and geographical distance, and the top three recommended organizations under each need category are selected, with the organization name, service content, address, contact number, and estimated waiting time marked. S53. Service Priority Ranking: Based on the risk level of the person and the nature of each policy benefit, the service priority score is automatically calculated. The ranking rule is that emergency intervention services involving personal safety take precedence over basic living security services, basic living security services take precedence over development services, and services without time limits take precedence over services. The system also outputs the suggested order of service implementation and the suggested start time for each service. S54. SRP Formatted Output and Push: The outputs from steps S51 to S53 are integrated into a formatted service suggestion package document. The service suggestion package document supports three methods: PDF export, in-system viewing, and mobile push. The SRP is also written into the person's electronic case file as baseline data for service records. After the SRP is generated, the process engine is automatically triggered to create the corresponding service process instance and assign the various tasks in the SRP to the to-do queue of the corresponding role.

9. The intelligent information matching method according to claim 1, characterized in that: The application system is configured based on the aforementioned intelligent information matching method using large language model semantic parsing and dual verification. The application system includes the following functional modules: policy text collection and preprocessing module, large language model policy parsing service module, strategy rule base management module, child profile data management module, formal rule matching engine module, large language model semantic review service module, formal verification module, confidence assessment and manual review diversion module, service suggestion package generation module, service resource database module, and audit traceability log module.

10. The intelligent information matching method according to claim 1, characterized in that: The application system is deployed using a microservice architecture, with each functional module running as an independent containerized service. RESTful interfaces are uniformly exposed through an API gateway, and asynchronous decoupling is achieved through message queues for inter-service communication. This ensures that time-consuming tasks such as policy parsing, rule matching, and semantic review do not block the main business process. The system is deployed on a municipal government cloud platform, utilizing the computing, storage, and network resources provided by the government cloud.

Images