Intelligent undertaking unit recommendation method and system based on large model

Abstract

The invention discloses an intelligent undertaking unit recommendation method and system based on a large model, and belongs to the technical field of artificial intelligence and information retrieval. The method mainly comprises the following steps: fusing multi-source government affair data and constructing an Elasticsearch index; a LoRA and P-Tuning V2 hybrid fine tuning large model is adopted to accurately extract work order key information and generate a semantic vector; constructing a knowledge graph of multi-dimensional attributes; the method comprises the following steps: executing mixed retrieval of'geo-fencing filtering, vector retrieval and keyword retrieval 'through Elasticsearch to generate a candidate set; sequencing by using a dynamic strategy engine based on a double-tower model and reinforcement learning; and finally, realizing continuous optimization of the model and knowledge through a negative feedback closed loop. Through responsibility decoupling of a large model and Elasticsearch and deep fusion of a knowledge graph, a dynamic strategy and a retrieval process, the core problems that a traditional government affair recommendation system is weak in semantic understanding, poor in dynamic adaptation, low in retrieval efficiency, free of a closed loop in optimization and the like are effectively solved, and the recommendation accuracy, timeliness and interpretability are remarkably improved.

Description

Technical Field

[0001] This invention relates to the interdisciplinary field of artificial intelligence and information retrieval, specifically to an intelligent method and system for recommending service providers based on large models, knowledge graphs, and Elasticsearch, which is particularly suitable for automatic work order assignment and task allocation systems in government service scenarios. Background Technology

[0002] In existing government work order processing systems, recommendations for responsible units mainly rely on human experience or simple rule engines based on keyword matching. These traditional solutions have the following inherent flaws and pressing technical problems that need to be addressed: Weak semantic understanding: Hard-coded keyword rules (such as "noise → urban management bureau") cannot effectively handle polysemous words (such as "illegal construction" which can refer to "illegal building" or "illegal approval"), professional terms and colloquial descriptions in government documents, resulting in a recommendation accuracy of less than 60% for complex work orders.

[0003] Poor dynamic adaptability: The system cannot perceive and adapt to dynamic changes in government service scenarios in real time, for example: Time context: Unable to automatically adjust to 24-hour duty unit based on time periods such as nighttime and holidays.

[0004] Event Context: Unable to respond to warnings for emergencies such as heavy rain or epidemics, and priority is given to recommending the corresponding emergency response units.

[0005] Functional updates: It is difficult to synchronize the information on the addition or cancellation of functions by the responsible units in a timely manner, resulting in a lag in recommendation results, with a lag rate of over 30%.

[0006] Low retrieval efficiency: When using traditional relational databases (such as MySQL) to perform multi-condition queries such as "jurisdiction + event type + policy clause", the response time is as long as 2.5-3 seconds, which cannot meet the real-time requirements of "minute-level" work order assignment.

[0007] The system lacks a closed-loop optimization mechanism: the existing system only records simple operations such as "return / confirm," lacking a systematic negative feedback mechanism. This prevents the use of user feedback data for incremental model training and real-time knowledge base updates, causing system performance to continuously decline as business expands.

[0008] Knowledge representation is crude: Even if a knowledge graph is constructed, it usually only contains basic static information such as "unit-function" and lacks fine-grained and dynamically changing attributes such as "historical success rate", "average response time" and "policy relevance". Furthermore, it is not deeply integrated with an efficient search engine and cannot support complex semantic matching and decision reasoning.

[0009] No single advanced technology (such as using only large models or only knowledge graphs) can systematically solve the complex problems in the aforementioned government service scenarios. While large models possess powerful semantic understanding capabilities, they suffer from bottlenecks such as knowledge lag and low retrieval efficiency; while knowledge graphs can structure and connect data, they lack the ability to perceive dynamic context; and while traditional search engines can improve efficiency, they cannot understand semantic ambiguity. Therefore, a combination of technologies—"large models (semantic understanding) + knowledge graphs (structured knowledge) + Elasticsearch (efficient retrieval) + dynamic strategies (context adaptation) + negative feedback loop (continuous optimization)"—is necessary to overcome the existing bottlenecks. Summary of the Invention

[0010] The purpose of this invention is to provide an intelligent recommendation method and system for undertaking government affairs based on a large model, addressing the aforementioned problems. By decoupling the responsibilities of the large model from Elasticsearch and deeply integrating knowledge graphs, dynamic strategies, and retrieval processes, it effectively solves the core problems of traditional government affairs recommendation systems, such as weak semantic understanding, poor dynamic adaptation, low retrieval efficiency, and lack of optimization loops, significantly improving the accuracy, timeliness, and interpretability of recommendations.

[0011] The technical solution of the present invention is as follows: A method for recommending event organizers based on a large model includes the following steps: Multi-source government data is integrated and preprocessed, and then built into an Elasticsearch index; A hybrid fine-tuning scheme based on LoRA and P-Tuning V2 is adopted to adapt the pre-trained large model to the domain, so as to extract key information from the work order text and generate semantic vectors. Construct a knowledge graph of the undertaking unit, which should at least include the undertaking unit, historical work order cases, policy clauses, and geographical entities and the relationships between them; Hybrid retrieval based on Elasticsearch includes: initial screening based on geofencing, vector retrieval based on semantic vectors, and keyword retrieval based on the BM25 algorithm. The retrieval results are then weighted and fused to generate a candidate knowledge set. The candidate knowledge set is sorted using a dynamic policy engine. The dynamic policy engine uses a dual-tower model to calculate the basic matching degree and combines a weight adjustment module based on reinforcement learning to dynamically optimize the matching degree. The sorted results are input into a large model to generate the final recommendation list and explanatory notes; User feedback is collected through a negative feedback closed-loop mechanism, and incremental training of the large model is performed based on the feedback data, while the knowledge graph and Elasticsearch index are updated simultaneously.

[0012] Through the collaboration of multiple technology modules, the system systematically solves the complex problems of "weak semantic understanding, poor dynamic adaptation, low retrieval efficiency, and lack of closed-loop optimization" in government recommendation, achieving a balance between accuracy, timeliness, interpretability, and compliance. It automates the entire process from work order entry to unit recommendation and system self-optimization, reducing the average time for manual work order assignment from 8-12 minutes to seconds, and lowering the mismatch rate from 15%-20% to below 10%.

[0013] Furthermore, the hybrid retrieval specifically includes: First, based on the work order's jurisdiction code, event type, and time information, a preliminary screening is performed using Elasticsearch's Boolean query to obtain 10-15 candidate responsible units; Then, for the candidate host institutions, the following searches are performed in parallel: Based on work order keywords, Top-K related entries are retrieved from the policy clause index and historical work order index using the BM25 algorithm; Based on semantic vectors, cosine similarity is calculated with the functional vectors of candidate units in the knowledge graph and the semantic vectors of historical cases to recall Top-M semantic matching results; Finally, the keyword search results and vector search results are merged according to preset weights to output a candidate knowledge set containing candidate organizer files, related policy clauses, and similar historical cases.

[0014] By using an integrated search process within Elasticsearch that combines "geofencing → vectors → keywords," the response time of traditional multi-database searches has been reduced from 2.5-3 seconds to 200-500 milliseconds, improving efficiency by over 85%. At the same time, weighted fusion ensures both the accuracy of semantic matching and the relevance of policy provisions.

[0015] Furthermore, the state space of the dynamic strategy engine reinforcement learning weight adjustment module includes time, location, event type, historical response latency rate of the undertaking unit, and early warning level of sudden events. The action space is the weight adjustment coefficient, and the reward function is constructed based on processing time and user satisfaction, and the strategy parameters are updated periodically.

[0016] By using a dual-tower model and reinforcement learning weight adjustment, the system can automatically perceive and adapt to dynamic contexts such as nighttime, holidays, and emergencies, reducing the recommendation lag rate caused by scene changes from over 30% to less than 10%, and prioritizing recommendations for units with high satisfaction levels, thereby improving the public service experience.

[0017] Furthermore, the negative feedback closed-loop mechanism specifically includes: Feedback collection: Records users' actions and reasons for choosing the recommended results in real time; Data cleaning and automatic labeling: Filter out invalid feedback and mark "user selected unit and processing successful" as positive samples and "original recommended unit and processing failed" as negative samples; Incremental training: The LoRA technique is used to fine-tune the large model weekly using valid feedback data from the past 7 days. Knowledge synchronization: Update the attributes of entities in the knowledge graph based on the feedback results, and synchronize the corresponding indexes through Elasticsearch's Bulk API.

[0018] Through incremental training based on LoRA and synchronous updates of the knowledge base, the model can complete iterations in just 2 hours per week with an 80% reduction in cost, improving accuracy by 3%-5% per month and stabilizing at over 89% after 6 months, effectively solving the problems of model performance degradation and data lag.

[0019] Furthermore, during the system cold start phase, a rule engine is used to generate initial recommendations, which are then combined with manual review to generate seed data. For low-frequency event types, EDA data augmentation technology is used to generate synthetic work order texts to expand the training data.

[0020] By employing a cold start solution combining a "rule engine + manual review" approach and EDA data augmentation technology, the system can be quickly put into use even in the initial construction phase (first 3 months) when data is insufficient. This also increases the accuracy rate during the cold start phase from 70% to 82%, accelerating the system's maturation process.

[0021] This application also includes a large-model-based intelligent event organizer recommendation system, which implements a large-model-based intelligent event organizer recommendation method, including: The data preprocessing and indexing module is used to integrate multi-source government data and build an Elasticsearch index; Domain-adaptive large model module, used to perform key government information extraction and semantic vector generation; The knowledge graph management module is used to store and manage the relationships between implementing units, cases, policies, and geographical location entities. The hybrid search module, built into Elasticsearch, is used to perform geofencing filtering, vector search, and keyword search sequentially. The dynamic strategy ranking module is used to dynamically rank candidate units by weight using a dual-tower model and reinforcement learning. The recommendation generation and interpretation module is used to generate the final recommendation list and its interpretability description. The negative feedback optimization module is used to realize a closed loop of feedback collection, incremental training, and synchronous updating of the knowledge base.

[0022] The above system integrates various functional modules, forming a closed loop of data flow and control flow. This solves the problems of technology stacking and module fragmentation in traditional solutions, and improves the system's stability, maintainability, and deployment efficiency.

[0023] Furthermore, the hybrid retrieval module specifically includes: The initial screening and filtering unit is used for rapid filtering based on jurisdiction, event type, and duty status. The keyword retrieval unit is used for searching the policy and case index based on the BM25 algorithm. The vector retrieval unit is used to calculate the similarity between the semantic vector of the work order and the entity vector in the knowledge graph; The fusion unit is used to fuse the results of keyword retrieval and vector retrieval according to weights.

[0024] Through the above system, the various sub-units of the hybrid retrieval module have clear division of labor and work together to ensure that millisecond-level initial screening and accurate matching can still be achieved under massive government data.

[0025] Furthermore, the dynamic strategy sorting module specifically includes: The feature encoding unit is used to encode time, location, event type, and emergency warning into a structured feature vector; The dual-tower model unit includes a work order semantic tower and a context feature tower, which are used to output the basic matching degree; The reinforcement learning adjustment unit is used to adjust the weights of the basic matching degree according to the dynamic scenario.

[0026] Through the aforementioned system, the dynamic strategy ranking module transforms abstract government experience into quantifiable feature vectors and weight coefficients, making the recommendation decision-making process transparent and auditable instead of a "black box".

[0027] Furthermore, the negative feedback optimization module specifically includes: The feedback collection unit is used to record user actions and reasons; The data cleaning and labeling unit is used to automatically generate positive and negative training samples; LoRA incremental training units are used to periodically fine-tune domain-adaptive large model modules. Through the modules described above, the negative feedback optimization module realizes a fully automated pipeline from feedback to model and knowledge base updates, ensuring the timeliness and consistency of system optimization and reducing manual intervention.

[0028] The knowledge synchronization unit is used to trigger real-time updates of the knowledge graph and Elasticsearch index.

[0029] Furthermore, the system also deploys a keyword and vector retrieval result caching module to cache high-frequency query combinations in order to improve the response speed of repeated queries.

[0030] By caching high-frequency queries, the response time for repeated queries is reduced to less than 10 milliseconds, greatly improving the system's concurrent processing capabilities and user experience.

[0031] Compared with existing technologies, the advantages of this invention are: 1. Technical implementation of dynamic strategies: The "dual-tower model + reinforcement learning weights" architecture transforms contexts such as time, location, and event type into quantifiable dynamic weights, avoiding hard-coded rules and adapting to the dynamic changes in government scenarios. 2. Refined design of negative feedback loop: Integrating "incremental training + efficient LoRA parameter update + real-time knowledge graph synchronization" solves the problems of "no iteration and high cost" in traditional feedback mechanisms, and achieves continuous optimization of model performance; 3. Deep integration of knowledge graph and RAG: Construct a knowledge graph (including fine-grained attributes and relationships) for government affairs scenarios, and combine it with "vector + keyword" hybrid retrieval to solve the problems of "knowledge lag and lack of details" in large models, and support accurate recommendation and interpretability.

[0032] 4. Set up an integrated search within Elasticsearch using "geofencing → vectors → keywords → aggregation and fusion" to resolve latency issues from multi-database queries, improving search speed by 95%; 5. Decoupling the responsibilities of the large model and ES: It is clearly stated that the large model is only responsible for "information extraction + vector generation", while the entire retrieval process is handled by ES, reducing the computing power consumption of the large model by 30% and breaking through the bottleneck of retrieval efficiency; 6. The negative feedback closed loop links the ES index and knowledge graph updates, solving the problem of "model and knowledge disconnect" in general feedback, and improving the model by an average of 3%-5% per month. Attached Figure Description

[0033] Figure 1 This is the architecture diagram of the system in this application.

[0034] Figure 2 This is a data flow diagram for this application.

[0035] Figure 3 This is a flowchart of the model training and recommendation process.

[0036] Figure 4 A flowchart for RAG retrieval and large model recommendation generation.

[0037] Figure 5 This is a diagram illustrating the visual explanation interface.

[0038] Figure 6Flowchart for negative feedback optimization mechanism. Detailed Implementation

[0039] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0040] The features and performance of the present invention will be further described in detail below with reference to embodiments.

[0041] Please see Figure 1-6 A smart event organizer recommendation system based on a large model, such as... Figure 1 As shown, it includes: (1) Multi-source data fusion and Elasticsearch index construction; like Figure 2 As shown, multi-source data integration: By integrating three types of core data and unifying the format through the JSON-LD standardized interface, a government work order dataset containing 15 core fields is formed. Structured data: historical work orders (responsible unit, processing time, result status), administrative division code table (four-level code of province-city-district-street), and duty roster of responsible unit (24-hour / regular duty markers); Semi-structured data: policy documents (clause number - content - scope of application - effective date), and the list of functions on the official website of the implementing unit (time stamps for added / cancelled functions). Unstructured data: work order text (user description), social media updates from the responsible unit (emergency response notices), industry reports (emergency incident handling guidelines).

[0042] Elasticsearch index design: To address the characteristics of government data, three core indexes were constructed (using the IKAnalyzer word segmenter and adapted to government terminology), and the index structure is shown in the table below: Table 1 Index Structure

[0043] (2) Large model pre-training and domain fine-tuning (solving the problem of semantic understanding of government affairs); like Figure 3 As shown, the fine-tuning paradigm employs a hybrid fine-tuning scheme of "LoRA (low-rank adaptive) + P-Tuning V2", based on a DeepSeek-R1 (72-parameter) pre-trained model, freezing the backbone parameters (to reduce computational cost), and training only: The low-rank matrix (rank r=16) injected into the Transformer layer. Continuous prompt embedding (length L=128, adapted to the length of government documents).

[0044] Dual-task joint training: Key government information extraction task: Extracting "event type (complaints / consultations / approvals, etc., 8 categories), urgency level (0-10 points, quantified based on keywords such as "night / casualties"), policy basis (e.g., Article 5 of the "Noise Management Regulations of XX City"), and jurisdiction code (e.g., 310104, corresponding to Huangpu District, Shanghai)", with an F1 score of 92.3%; The task of classifying the undertaking units involves outputting the matching probability of candidate units and optimizing the cross-entropy loss function.

[0045] Government Document Adaptation Solution (Addressing Polysemous and Colloquial Issues): The "Government Affairs Terminology Dictionary" includes over 3200 professional terms and synonyms (such as "street vending → illegal street vending" and "VOCs → volatile organic compounds"), and marks the ambiguity mapping of polysemous words (such as "illegal construction → {illegal buildings: [illegal construction in residential areas, unauthorized construction], illegal approval: [approval of illegal construction projects, permit for illegal construction in planning]}"). T5 Model Standardization Conversion: Converting colloquial expressions (such as "The barbecue downstairs goes on until the early hours of the morning, it's too noisy and I can't sleep") into standard government labels ("Noise pollution complaint (nighttime)"). Contrastive learning disambiguation: For polysemous words (such as "illegal construction"), generate their contextual semantic vector (based on a large model), calculate the cosine similarity with the vectors (768-dimensional) of the entities "illegal building" and "irregular approval" in the knowledge graph, and take the entity with a similarity ≥ 0.85 as the correct meaning (e.g., "processing illegal construction in the community" and "illegal building" have a similarity of 0.92, and "approval of illegal construction in the project" and "irregular approval" have a similarity of 0.89).

[0046] (3) Construction of the knowledge graph of the undertaking unit (solving the problem of structured association); Schema design (core entities and relationships): Table 2 Core Entities and Relationships

[0047] Information extraction and knowledge fusion: 1. Extraction Technique: Joint extraction using "rule template + BERT-NER model"—the rule template extracts policy clause numbers (e.g., "Article X") and administrative division codes; the BERT-NER model identifies the responsible unit name and event type label, achieving an entity recognition accuracy of 91.5%. 2. Knowledge Integration: Entity alignment is achieved through the "Unified Social Credit Code of the Entity" (resolving the synonymy issue between "XX District Urban Management Bureau" and "XX District Urban Management Bureau"); for conflicting attributes such as "response time", the average value of the most recent 3 months is taken as the final value.

[0048] (4) Elasticsearch + RAG hybrid retrieval mechanism (to solve the problem of retrieval efficiency and accuracy). like Figure 4 As shown, the search process consists of four steps, achieving "efficient filtering + accurate matching," reducing the response time from the traditional 2.5 seconds to 0.3-0.5 seconds: 1. Elasticsearch structured filtering (initial screening): Enter the work order's "jurisdiction code (e.g., 310104), event type (e.g., noise complaint), and time (e.g., 23:00 at night)" and quickly filter it using an Elasticsearch Boolean query: Jurisdiction filtering: term:{jurisdiction code:"310104"}; Event type filtering: term:{area of ​​expertise:"noise complaints"}; Time filtering: term:{Duty status:"24-hour duty"}; Output 10-15 candidate host organizations that meet the basic constraints.

[0049] 2. Elasticsearch Keyword Search (Policy and Case Matching): For candidate organizations after initial screening, the ES BM25 algorithm is used to match "policy provisions" with "historical cases": Policy matching: Enter work order keywords (such as "nighttime construction noise"), search the policy clause index, and recall the top 5 relevant clauses (such as Article 12 of the "Regulations on the Prevention and Control of Environmental Noise Pollution in XX City"). Case matching: Search the historical work order index and recall the top 5 cases with "same jurisdiction + same event type + successfully processed" (e.g., case C045, the processing unit is the Urban Management Bureau of XX District, and the response time is 2 hours).

[0050] 3. Vector retrieval (semantic exact matching): The 768-dimensional semantic vector of the generated work order (based on the fine-tuned large model) is used to calculate the cosine similarity with the "functional vector" of the candidate unit in the knowledge graph and the "semantic vector" of historical cases, and the top 8 results with the highest semantic matching degree are recalled.

[0051] 4. Weighted Fusion (Generating Candidate Knowledge Sets): Based on the weighted fusion results of "ES keyword retrieval (0.4) + vector retrieval (0.6)," three types of core information are output: "candidate undertaking unit files + related policy clauses + similar historical cases," which serve as contextual support for the large model recommendation.

[0052] (5) Dynamic recommendation strategy module (replacing the traditional rule engine); A three-tiered architecture of "contextual feature encoding - dual-tower model ranking - reinforcement learning weight adjustment" is adopted to transform the dynamic constraints of government service scenarios (duty shifts, emergencies) into quantifiable weights: 1. Contextual feature encoding: Transform "time, location, event type, and emergency warning" into a structured feature vector (400 dimensions in total): Time characteristics (4 dimensions): whether it is a holiday (0 / 1), whether it is nighttime (22:00-6:00, 0 / 1), hourly segment (0-23), emergency warning level (0-3, such as a red rainstorm warning of level 3); Location features (128 dimensions): Administrative division code embedding vector (generated based on pre-trained GeoBERT, reflecting the hierarchical relationship of jurisdictions); Event type characteristics (8 dimensions): Unique hot coding (covering 8 major categories including complaints, inquiries, and approvals); Emergency features (260 dimensions): pre-trained vectors based on emergency event types (heavy rain / heavy snow / epidemic).

[0053] 2. Dual-Tower Model Fusion: Constructing a "work order semantic tower + context feature tower": Work order semantic tower: Processes work order embedding vectors (768 dimensions) generated by large models and outputs 256-dimensional semantic features; Context Feature Tower: Compresses 400-dimensional context features to 256 dimensions using a 3-layer MLP; The outputs of the two towers are used to calculate the basic matching degree (0-1) using cosine similarity, which is then used as the initial recommendation weight.

[0054] 3. Reinforcement learning dynamic weight adjustment: Design an LSTM-based reinforcement learning policy engine to solve the "dynamic constraint adaptation" problem: State space (12 dimensions): time, location, event type, historical response delay rate of the responsible unit, and emergency warning level; Action space: weight adjustment coefficient (0.5-2.0); Reward function: ( , (Full marks are awarded for processing time ≤ 24 hours and user satisfaction ≥ 90 points). Strategy Update: The strategy parameters are updated weekly based on the latest work order processing data to achieve adaptive weighting.

[0055] Quantification example: Noise complaint work orders at night (23:00): The basic weight (0.6) of the 24-hour duty unit is adjusted to 1.4 through reinforcement learning (because the historical nighttime response rate of this type of unit is 92% and the satisfaction rate is 95%). During a red alert for heavy rain: the basic weight of municipal drainage units (0.7) is adjusted to 2.0 (due to the need for priority response to emergencies, and a historical satisfaction rate of 98% in handling heavy rain).

[0056] (6) Negative feedback optimization closed-loop mechanism (to achieve low-cost continuous optimization); like Figure 6 As shown, a closed-loop process of "feedback collection - data cleaning - incremental training - knowledge base / ES index synchronization update" is constructed to solve the problems of "model performance degradation" and "data lag". 1. Feedback Collection: User actions (confirmation / rejection / modification of recommendation results) are recorded in real time, with associated fields including: original work order ID, original list of recommended units, user-selected unit, processing result (success / failure), and feedback reason (drop-down selection + text input, such as "functional mismatch", "response timeout", "jurisdiction misjudgment").

[0057] 2. Data cleaning and labeling: Cleaning rules: Filter duplicate feedback (only the last one is kept if the same work order is modified multiple times) and invalid feedback (test work orders / misoperations, work orders marked "test"); Automatic labeling: "User selects unit + processing successful" is marked as a positive sample (confidence level 1.0), and "original recommended unit (not selected by user) + processing failed" is marked as a negative sample (confidence level 0.9); samples with confidence level <0.7 (such as when the user did not fill in a reason) are subject to manual review and the error type is labeled (such as "policy matching error" or "duty status not updated").

[0058] 3. Incremental training (low-cost model update): Training cycle: Every Sunday morning, using only valid feedback data (≥50 pieces) from the past 7 days; Training strategy: Use LoRA technology to fine-tune large models - freeze the pre-trained layers and only update the low-rank matrix of the attention layer (learning rate 5e-5), which reduces the training cost by 80% compared to full retraining and shortens the training time from 12 hours to 2 hours. Results: The model accuracy improved by 3%-5% per month, and stabilized at over 89% after 6 months.

[0059] 4. The knowledge base and Elasticsearch index are updated synchronously: Knowledge graph update: If a user selects a new unit and the issue is successfully processed, add a "specialty tag" (such as "nighttime construction noise complaint") to that unit and associate it with the current work order as a "historical case"; if the feedback is "response timeout", update the unit's "average response time" (take the average of the last 3 cases). ES Index Update: After a knowledge graph attribute changes, the corresponding index is updated synchronously via the Elasticsearch Bulk API (e.g., "Duty status changes from 'regular' to '24 hours'") to ensure real-time data retrieval with an update delay of less than 1 minute.

[0060] 5. Cold start processing (to address initial data sparsity): In the initial phase (first 3 months), a transitional approach of "rule engine + manual review" was adopted: the rule engine generated initial recommendations based on keywords (such as "environmental complaint → environmental protection bureau"), and after manual review, "correctly matched cases" were marked as seed data (10,000 cases). Data augmentation: For low-frequency event types (such as "ancient tree protection", less than 10 work orders per month), EDA technology (synonym replacement, word order adjustment, context expansion) is used to generate 10 times more synthetic work order text to supplement training data. In the third month of cold start, the accuracy rate increased from 70% to 82%.

[0061] (7) Visual explanation interface (improving explainability); like Figure 5 As shown, each recommendation result is given a three-in-one explanation consisting of "text description + weight heatmap + knowledge source link", which meets the "traceability and auditability" requirements of government affairs scenarios. Text description: "Recommended [XX District Urban Management Bureau], based on: 1. Matching Article 5 of the 'XX City Noise Management Regulations' (policy matching degree 35%); 2. 92% success rate in handling similar nighttime noise complaints in the past 3 months (historical case similarity 28%); 3. Belonging to the jurisdiction of Wangjing Street (geographical location matching 22%); 4. 24-hour duty at night (time weight 15%)." Weighted Heatmap: The pie chart visually displays the proportions of "policy matching degree, historical case similarity, geographical location, and time / emergency event weight"; Knowledge source links: Click "Policy Clauses" to jump to the original text on the government's official website, click "Historical Cases" to view the processing details, and click "Weight Calculation" to view the reinforcement learning adjustment process.

[0062] Optional technical features: (1) High availability of ElasticSearch cluster: 3 masters + 5 data nodes + 2 coordinator nodes, running 24 hours a day; (2) Optimization of retrieval cache: The combination of "high frequency event + jurisdiction" (such as "noise complaint + 310105") is cached for 1 hour, and the time taken for repeated queries is ≤10ms; (3) Enhanced geographical location awareness: Within the same jurisdiction, priority is given to recommending units that are "≤3 kilometers away from the work order location", which shortens the response time by 0.5 hours.

[0063] In another specific embodiment, it includes: 1. Data Acquisition Module (Implementation Parameters): Data collection scope: Citywide government service order data from January to December 2024 (100,000 records, including fields for "service order text, processing unit, response time, and result status"); External data includes: ① Policy documents (over 500 city / district level regulations, such as the "XX City Urban Appearance Management Regulations"); ② Information on responsible units (functional lists from the official websites and social media posts of over 300 units); ③ Administrative division data (street-level coding table, covering 127 streets). Data collection tools: The Python Scrapy framework was used to crawl policy documents from government websites, raw work order data was obtained through government data interfaces, and ASR interfaces (such as Baidu Smart Cloud) were called to convert voice work orders into text.

[0064] 2. Data Cleaning and Labeling Module (Implementation Details): Cleaning rules: Remove invalid data (approximately 5%) that are "empty work order text" or "processing results not labeled"; standardize text format (e.g., "XX District Urban Management" → "XX District Urban Management Bureau"). Labeling tools: The LabelStudio labeling platform was used to manually label the metadata information of "event type, urgency level, and jurisdiction code" with a sample size of 10,000 (as seed data for fine-tuning the large model); the remaining 90,000 were automatically labeled (initial labeling through rule templates + manual spot checks and corrections, with a spot check rate of 10%).

[0065] 3. Large Model Fine-tuning and Feature Extraction Module (Implementation Steps): Pre-trained model selection: DeepSeek-R1 (7B parameters) was used, deployed based on the PyTorch framework; Fine-tuning configuration: LoRA rank r=16, learning rate 5e-5, batch size=16, training epochs 10; P-Tuning V2 cue length 128, MLP hidden layer dimension 256; Feature extraction output: For each work order, output a composite feature vector consisting of "768-dimensional semantic embedding vector + 4-dimensional time feature + 128-dimensional location feature + 8-dimensional event type feature" for subsequent sorting.

[0066] Deploy ElasticSearch, create indexes, and import the trained data into ElasticSearch.

[0067] 4. Knowledge Graph Construction Module for the Organizing Unit (Implementation Tools and Processes): Construction tools: Neo4j is used for graph database, and BERT-NER model (based on Chinese BERT pre-trained weight fine-tuning) is used for information extraction. Implementation process: Entity extraction: Extract the entities of "undertaking unit" and "historical cases" from the work order data, and extract the entity of "policy clause" from the policy documents, generating a total of 12,000+ entities; Relationship extraction: Relationships between entities are established through "rule templates (such as "processing → case ID") + relationship classification models (such as CNN-based relationship classifiers)," generating a total of 35,000+ relationships; Knowledge integration: Entity alignment is achieved by using "social credit code + name fuzzy matching" to resolve the issue of synonymous entities such as "XX District Urban Management Bureau" and "XX District Urban Management Bureau"; Real-time updates: Every day at midnight, the "Function Update" section of the official website of the undertaking unit is crawled, and the "Function List" attribute in the knowledge graph is automatically updated.

[0068] 5. RAG Search Module (Implementation Steps): For example, on October 1, 2025 at 23:30, a resident of Wangjing Street, XX District, submitted a work order for "complaint about nighttime construction noise in the community": Query construction: Keyword Query = "noise complaint, Wangjing Street, nighttime construction"; Vector Query = 768-dimensional work order semantic embedding generated by the large model; Geofence filtering: Filter the implementing units whose jurisdiction includes Wangjing Subdistrict (such as XX District Urban Management Bureau, Wangjing Subdistrict Office) from the knowledge graph. Vector retrieval: Match historical cases of "nighttime noise complaints" that were successfully handled (e.g., case C045, handled by the Urban Management Bureau of XX District), and recall the Top 10. Keyword search: Match policy clauses related to "nighttime construction noise" (such as Article 12 of the "Regulations on the Prevention and Control of Environmental Noise Pollution in XX City"), and recall the top 5. Fusion Output: Generate a candidate knowledge set containing "XX District Urban Management Bureau Archives, Case C045, and Article 12 of the Noise Regulation".

[0069] 6. Large-scale model recommendation module (implementation logic): Input content: Original work order text + RAG candidate knowledge set + dynamic strategy weight (weight of night shift unit + 0.8); The prompt is generated as follows: "Based on the following information, the responsible units are recommended and ranked: 1. Work order: Nighttime construction noise complaint from Wangjing Street, XX District; 2. Relevant policy: Article 12 of the 'Regulations on the Prevention and Control of Environmental Noise Pollution in XX City'; 3. Historical case: C045 (handled by the Urban Management Bureau of XX District, response time 2 hours); 4. Unit capability: The Urban Management Bureau of XX District has 24-hour duty, and the success rate of similar complaints in the past 3 months is 92%; 5. Time weight: Night duty units have a weight of +0.8." Output results: "1. Urban Management Bureau of XX District (recommendation probability 82%); 2. Emergency Management Office of Wangjing Subdistrict (recommendation probability 15%); 3. Ecological Environment Bureau of XX District (recommendation probability 3%)".

[0070] 7. Recommended Display and Explanation Module (Implementation Interface): The front-end display content includes: Recommended Organizations List: Sorted by probability, displaying organization name and contact information; Weighted heatmap: A pie chart showing "policy matching degree (35%), historical case similarity (28%), geographical location (22%), and time weight (15%)"; Knowledge source link: Click "Article 12 of the Noise Regulation" to jump to the original policy text, and click "Case C045" to view the handling details.

[0071] 8. Feedback Optimization Module (Implementation Cycle and Rules): Feedback collection: When a user clicks "Return" on the front end, they need to select a reason for the return (such as "job mismatch"), and the system records it to the database in real time; Data cleaning: A cleaning script is executed every Saturday to filter duplicate feedback (only the last feedback is kept for the same work order ID) and remove "test work orders" (work orders marked "test"). Incremental training: The training task starts at 3:00 AM every Sunday, loads valid feedback data (≥50 data points) from the past 7 days, fine-tunes the large model using LoRA, and replaces the online model after training is complete; Knowledge base update: If a user returns and selects "XX District Ecological Environment Bureau" and the process is successful, the system will automatically add "Area of ​​Expertise: Nighttime Construction Noise Complaints" for that unit in Neo4j and associate the current work order as a "Historical Case".

[0072] Case input: On July 20, 2025 (rainstorm warning) at 10:00, a resident of Fangxun Road (admin_code=310105) in XX District submitted a work order: "The water at the entrance of the community is almost up to the knees, and the elderly cannot go out. Please handle this matter immediately."

[0073] Implementation steps: 1. Large model preprocessing (information extraction and vector generation only): Key information: event type = flood control complaint, admin_code = 310105, policy keywords = rainstorm and waterlogging, urgency level = 10 points; generate ticket_embedding (768 dimensions) and write it to the ES temporary index gov_ticket_temp_index; 2. ElasticSearch retrieval (total process ≤200ms): Step 1: Geofencing Filtering (gov_unit_index): Filter units with admin_code=310105 and geo_shape containing the flood control road boundary (XX District Municipal Drainage Center U001, XX District Street Office U002), taking 50ms; Step 2: Vector retrieval (gov_case_index): ticket_embedding matches cases with "flood control complaint + response ≤ 2 hours", recalls the Top 10 (e.g., C123, associated with U001, similarity 0.92), taking 100ms; Step 3: Keyword search (gov_policy_index): admin_scope=310105 + "rainstorm waterlogging" matches Article 8 of the "XX City Flood Control Regulations" (P008, BM25 score 18.5, time taken 30ms); Step 4: Aggregation and Fusion: U001 score = 0.92 × 0.6 + 18.5 × 0.4 (0.88 after standardization), U002 score 0.52, output candidate set (U001 + C123 + P008), time taken 20ms; 3. Dynamic Recommendations: Basic weights for the two towers: U001 (0.7), U002 (0.5); Reinforcement learning adjustment: The rainstorm warning triggers "municipal unit weight +1.5", resulting in U001 (0.7×1.5=1.05) and U002 (0.5); Recommended results: U001 (92%, with 24-hour duty phone number), U002 (7%), XX District Emergency Management Bureau (1%); 4. Feedback optimization: If the user reports "U001 pump truck is out of service, select U003 for emergency management compliance": Feedback data is written to gov_feedback_index; Sunday Incremental Training: LoRA fine-tunes large models, increasing the weight of U003 in the "heavy rain and flood support" scenario; ES synchronization: gov_unit_index updated U003's function_list, adding "Area of ​​expertise: Heavy rain and flooding support".

[0074] The embodiments described above merely illustrate specific implementation methods of this application, and while the descriptions are detailed and specific, they should not be construed as limiting the scope of protection of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the technical solution of this application, and these modifications and improvements all fall within the scope of protection of this application.

Claims

1. A method for recommending intelligent event organizers based on a large model, characterized in that, Includes the following steps: Multi-source government data is integrated and preprocessed, and then built into an Elasticsearch index; A hybrid fine-tuning scheme based on LoRA and P-Tuning V2 is adopted to adapt the pre-trained large model to the domain, so as to extract key information from the work order text and generate semantic vectors. Construct a knowledge graph of the undertaking unit, which should at least include the undertaking unit, historical work order cases, policy clauses, and geographical entities and the relationships between them; Hybrid retrieval based on Elasticsearch includes: initial screening based on geofencing, vector retrieval based on semantic vectors, and keyword retrieval based on the BM25 algorithm. The retrieval results are then weighted and fused to generate a candidate knowledge set. The candidate knowledge set is sorted using a dynamic policy engine. The dynamic policy engine uses a dual-tower model to calculate the basic matching degree and combines a weight adjustment module based on reinforcement learning to dynamically optimize the matching degree. The sorted results are input into a large model to generate the final recommendation list and explanatory notes; User feedback is collected through a negative feedback closed-loop mechanism, and incremental training of the large model is performed based on the feedback data, while the knowledge graph and Elasticsearch index are updated simultaneously.

2. The intelligent event organizer recommendation method based on a large model according to claim 1, characterized in that, The hybrid retrieval specifically refers to: First, based on the work order's jurisdiction code, event type, and time information, a preliminary screening is performed using Elasticsearch's Boolean query to obtain 10-15 candidate responsible units; Then, for the candidate host institutions, the following searches are performed in parallel: Based on work order keywords, Top-K related entries are retrieved from the policy clause index and historical work order index using the BM25 algorithm; Based on semantic vectors, cosine similarity is calculated with the functional vectors of candidate units in the knowledge graph and the semantic vectors of historical cases to recall Top-M semantic matching results; Finally, the keyword search results and vector search results are merged according to preset weights to output a candidate knowledge set containing candidate organizer files, related policy clauses, and similar historical cases.

3. The intelligent event organizer recommendation method based on a large model according to claim 1, characterized in that, The state space of the reinforcement learning weight adjustment module of the dynamic strategy engine includes time, location, event type, historical response latency rate of the undertaking unit and early warning level of emergencies. The action space is the weight adjustment coefficient. The reward function is constructed based on processing time and user satisfaction, and the strategy parameters are updated periodically.

4. The intelligent event organizer recommendation method based on a large model according to claim 1, characterized in that, The negative feedback closed-loop mechanism specifically includes: Feedback collection: Records users' actions and reasons for choosing the recommended results in real time; Data cleaning and automatic labeling: Filter out invalid feedback and mark "user selected unit and processing successful" as positive samples and "original recommended unit and processing failed" as negative samples; Incremental training: The LoRA technique is used to fine-tune the large model weekly using valid feedback data from the past 7 days. Knowledge synchronization: Update the attributes of entities in the knowledge graph based on the feedback results, and synchronize the corresponding indexes through Elasticsearch's Bulk API.

5. The intelligent event organizer recommendation method based on a large model according to claim 1, characterized in that, During the system's cold start phase, an initial recommendation is generated using a rule engine, which is then combined with manual review to produce seed data. For low-frequency event types, EDA data augmentation techniques are used to generate synthetic work order text to expand the training data.

6. A smart event organizer recommendation system based on a large model, characterized in that, Implementing the intelligent event organizer recommendation method based on a large model as described in any one of claims 1-5, comprising: The data preprocessing and indexing module is used to integrate multi-source government data and build an Elasticsearch index; Domain-adaptive large model module, used to perform key government information extraction and semantic vector generation; The knowledge graph management module is used to store and manage the relationships between implementing units, cases, policies, and geographical location entities. The hybrid search module, built into Elasticsearch, is used to perform geofencing filtering, vector search, and keyword search sequentially. The dynamic strategy ranking module is used to dynamically rank candidate units by weight using a dual-tower model and reinforcement learning. The recommendation generation and interpretation module is used to generate the final recommendation list and its interpretability description. The negative feedback optimization module is used to realize a closed loop of feedback collection, incremental training, and synchronous updating of the knowledge base.

7. The intelligent event organizer recommendation system based on a large model according to claim 6, characterized in that, The hybrid retrieval module specifically includes: The initial screening and filtering unit is used for rapid filtering based on jurisdiction, event type, and duty status. The keyword retrieval unit is used for searching the policy and case index based on the BM25 algorithm. The vector retrieval unit is used to calculate the similarity between the semantic vector of the work order and the entity vector in the knowledge graph; The fusion unit is used to fuse the results of keyword retrieval and vector retrieval according to weights.

8. The intelligent event organizer recommendation system based on a large model according to claim 6, characterized in that, The dynamic strategy sorting module specifically includes: The feature encoding unit is used to encode time, location, event type, and emergency warning into a structured feature vector; The dual-tower model unit includes a work order semantic tower and a context feature tower, which are used to output the basic matching degree; The reinforcement learning adjustment unit is used to adjust the weights of the basic matching degree according to the dynamic scenario.

9. The intelligent event organizer recommendation system based on a large model according to claim 6, characterized in that, The negative feedback optimization module specifically includes: The feedback collection unit is used to record user actions and reasons; The data cleaning and labeling unit is used to automatically generate positive and negative training samples; LoRA incremental training units are used to periodically fine-tune domain-adaptive large model modules. The knowledge synchronization unit is used to trigger real-time updates of the knowledge graph and Elasticsearch index.

10. The intelligent event organizer recommendation system based on a large model according to claim 6, characterized in that, The system also has a keyword and vector retrieval result caching module, which is used to cache high-frequency query combinations to improve the response speed of repeated queries.

Images