Data processing method and device based on context protocol, equipment and medium

Abstract

The invention relates to the technical field of data processing, can be applied to business scenes of financial science and technology, medical health and the like, and discloses a data processing method, device, equipment and medium based on a context agreement, comprising: receiving a business demand event, extracting a demand text, and disassembling the demand text to generate a plurality of subtasks; obtaining a data source context according to the sub-tasks and task subject information, generating a corresponding data extraction path and an analysis model strategy, connecting a target data source through an access strategy, collecting original data, preprocessing the original data, and dividing the original data into training data and verification data; and training the model based on the analysis model strategy and generating a reasoning result, and completing verification output through a result verification model. According to the method, task disassembly, data access and model generation processes are driven through a model context protocol, and a knowledge graph reasoning and verification mechanism is combined, so that a closed-loop automatic analysis path is formed, and the processing efficiency and intelligent adaptation capability of cross-domain data tasks are effectively improved.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, applicable to business scenarios such as financial technology and medical health, and in particular to a data processing method, device, equipment and storage medium based on a context protocol. Background Art

[0002] In the current evolution of enterprise data intelligence, automated data analysis systems have been widely adopted in various complex business scenarios, particularly in data-intensive industries such as fintech and healthcare. Existing data analysis processes often rely on manual configuration of task logic, manual model selection, and rule-driven data cleansing processes. These processes lack systematic semantic modeling capabilities and end-to-end collaboration mechanisms, resulting in delayed overall analysis processes, high task coupling, and a lack of feedback mechanisms, making it difficult to adapt to rapidly changing business needs.

[0003] In the fintech sector, automated analysis systems are widely used in scenarios such as credit assessment, risk monitoring, and capital flow identification. However, existing systems often rely on static rules to drive task analysis, data modeling, and result verification. These systems lack the ability to dynamically analyze task semantics and are unable to automatically update data extraction paths and model configurations based on changing business needs. Furthermore, financial services place extremely high demands on the compliance and accuracy of analytical results. However, current systems often separate model reasoning and result verification, lacking a closed-loop verification and feedback loop. This makes it difficult to promptly identify and correct abnormal analysis results.

[0004] In the healthcare sector, tasks such as clinical pathway prediction, health risk modeling, and assisted diagnosis rely on the integrated analysis of large-scale heterogeneous data. Existing solutions rely heavily on manually defined rules for multi-source data acquisition and preprocessing. Model selection lacks specificity and is difficult to adapt to individual patient characteristics. Task granularity is too coarse to dynamically generate personalized analysis tasks for fine-grained health indicators, limiting the model's adaptability and credibility in intelligent clinical decision-making.

[0005] From an underlying architectural perspective, most existing automated analysis platforms lack unified, task-driven semantic protocols, efficient task decomposition, and multi-model management mechanisms. Model selection strategies are statically bound, making it difficult to achieve a data-driven, dynamic linkage between task planning, model training, and verification results. During the analysis execution phase, most platforms still use serial processes or manual review to process model inference results. These processes lack intelligent evaluation standards and automated verification capabilities, impacting the overall intelligence and processing efficiency of the system.

[0006] To sum up, when dealing with complex and ever-changing financial technology and healthcare business analysis scenarios, existing technologies still face core bottlenecks such as insufficient task semantic understanding capabilities, lack of dynamic adaptation capabilities of analysis paths, and lack of feedback mechanisms in the analysis process. There is an urgent need for an automated data analysis architecture with a unified semantic coordination mechanism, support for automatic parsing and collaborative execution of multiple subtasks, and the ability to integrate upstream and downstream data paths and verification feedback capabilities to solve these problems. Summary of the Invention

[0007] The main purpose of the present invention is to provide a data processing method, device, equipment and storage medium based on a context protocol, aiming to solve the technical problem that the existing technology lacks a unified semantic protocol-driven automatic task disassembly, data path generation and model selection collaborative mechanism, which leads to the fragmentation of various links in the complex data analysis process and delayed response.

[0008] To achieve the above object, the present invention provides a data processing method based on a context protocol, comprising:

[0009] Receiving a business demand event, and extracting a demand text from the business demand event;

[0010] Extracting the task subject and time range from the requirement text through the model context protocol, and breaking the requirement text into multiple subtasks based on the complexity of the requirement text;

[0011] Based on the subtasks and task body, data source context information is obtained through the model context protocol interface, and the knowledge graph reasoning module is combined to generate a data extraction path and analysis model selection strategy for each subtask;

[0012] Connecting to a target data source based on the data extraction path corresponding to each subtask and the data source access policy defined by the model context protocol, combined with the access permissions in the data source context information, and collecting raw data from the target data source based on the time range;

[0013] Preprocessing the raw data, and splitting the preprocessed data into training data and validation data according to the partitioning strategy defined by the model context protocol;

[0014] Determine a target analysis model according to the analysis model selection strategy corresponding to each subtask, and train the target analysis model using the training data;

[0015] Performing reasoning based on the verification data using the trained target analysis model to generate subtask reasoning results;

[0016] The result verification model is called to verify the subtask reasoning result and generate a verification result.

[0017] Furthermore, to achieve the above-mentioned object, the present invention provides a data processing device based on a context protocol, comprising:

[0018] A demand receiving module is used to receive a business demand event and extract a demand text from the business demand event;

[0019] A task parsing module, configured to extract the task subject and time range from the requirement text through a model context protocol, and decompose the requirement text into multiple subtasks based on the complexity of the requirement text;

[0020] A path planning module is used to obtain data source context information through the model context protocol interface based on the subtasks and task body, and to generate a data extraction path and analysis model selection strategy for each subtask in combination with the knowledge graph reasoning module;

[0021] A data collection module is used to connect to a target data source based on the data extraction path corresponding to each subtask and the data source access policy defined by the model context protocol, combined with the access permissions in the data source context information, and collect raw data from the target data source according to the time range;

[0022] A data preprocessing module, configured to preprocess the raw data and split the preprocessed data into training data and validation data according to a partitioning strategy defined by the model context protocol;

[0023] A model training module is used to determine a target analysis model according to the analysis model selection strategy corresponding to each subtask, and train the target analysis model using the training data;

[0024] An inference execution module, configured to perform inference based on the verification data using the trained target analysis model to generate subtask inference results;

[0025] The result verification module is used to call the result verification model to verify the subtask reasoning result and generate a verification result.

[0026] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a context protocol-based data processing program stored in the memory and executable on the processor, wherein the context protocol-based data processing program, when executed by the processor, implements the steps of the context protocol-based data processing method as described above.

[0027] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a data processing program based on a context protocol is stored. When the data processing program based on the context protocol is executed by a processor, the steps of the data processing method based on the context protocol as described above are implemented.

[0028] Beneficial effects: The present invention relates to the field of data processing technology and can be applied to business scenarios such as financial technology and medical health. It discloses a data processing method based on a context protocol, including: receiving business demand events and extracting demand texts; extracting task subjects and time ranges through a model context protocol, and decomposing them into multiple subtasks according to the complexity of the demand text; obtaining data source context information based on the subtasks and task subjects, and generating data extraction paths and analysis model selection strategies in combination with a knowledge graph reasoning module; connecting to a target data source and collecting raw data based on the data extraction path and access strategy; preprocessing the raw data, and splitting the preprocessed data into training data and verification data based on a partitioning strategy; determining a target analysis model based on an analysis model selection strategy, and using training data to train the model; performing reasoning based on verification data using the trained model to generate subtask reasoning results; calling a result verification model to compare the subtask reasoning results to generate verification results. The present invention unifies the management of task elements and execution strategies through the model context protocol, combines knowledge graph reasoning to achieve the adaptation of data paths and model selection, and promotes the standardization of analysis processes with a training-verification structure. Ultimately, it builds an automated closed loop from task decomposition, data extraction, model training to result verification, greatly improving the execution efficiency and analysis accuracy of data analysis tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0030] Figure 1 A schematic diagram of an application environment of a data processing method based on a context protocol in an embodiment of the present invention;

[0031] Figure 2 This is a flow chart of an embodiment of a data processing method based on a context protocol according to the present invention;

[0032] Figure 3 Schematic diagram of functional modules of a preferred embodiment of a data processing device based on a context protocol of the present invention;

[0033] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0034] Figure 5 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0035] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0036] The data processing method based on context protocol provided by the embodiment of the present invention can be applied in the following situations: Figure 1 In an application environment, the user end communicates with the server end through a network. The server end can receive business demand events through the user end and extract the demand text; extract the task body and time range through the model context protocol, and decompose it into multiple subtasks according to the complexity of the demand text; obtain data source context information based on the subtasks and task body, and generate data extraction path and analysis model selection strategy in combination with the knowledge graph reasoning module; connect to the target data source and collect original data according to the data extraction path and access strategy; preprocess the original data, and split the preprocessed data into training data and verification data according to the partitioning strategy; determine the target analysis model based on the analysis model selection strategy, and use the training data to train the model; perform reasoning based on the verification data through the trained model to generate subtask reasoning results; call the result verification model to compare the subtask reasoning results to generate verification results. The present invention uniformly manages task elements and execution strategies through the model context protocol, combines knowledge graph reasoning to achieve adaptation of data path and model selection, and promotes standardization of analysis processes with training combined with verification structure, and finally constructs an automated closed loop from task decomposition, data extraction, model training to result verification, greatly improving the execution efficiency and analysis accuracy of data analysis tasks. The user end may be, but is not limited to, various personal computers, laptops, smartphones, tablet computers, and portable wearable devices. The server end may be implemented as an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below using specific embodiments.

[0037] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of a data processing method based on a context protocol provided by the present invention. It should be noted that although a logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0038] like Figure 2 As shown, the data processing method based on the context protocol proposed in the present invention includes the following steps:

[0039] S10, receiving a business demand event, and extracting a demand text from the business demand event;

[0040] In this embodiment, the system accesses the business request signal sent by the external system through the task scheduling mechanism. The request signal is defined as a business demand event within the system, which represents an automated data analysis task to be processed. Business demand events are usually passed in through an event encapsulation structure in a unified format. It can be a serialized object such as JSON, XML or protocol buffer, containing task identification, trigger source, user information, task target description field, additional parameters and data dependency tags, etc. The system first listens to these business demand events and identifies their structure in the event protocol field. In order to adapt to the heterogeneous interface formats that may be adopted by different business systems, the system has designed a multi-channel compatibility mechanism to normalize heterogeneous inputs into a standard intermediate event format.

[0041] After receiving a business demand event, the system needs to extract the demand text required for task execution. The demand text is usually natural language or structured statements, located in a specific field in the event structure, such as payload.description or event_metadata.task_description. This text field contains the user's analysis intention, such as semantic expressions such as "analyze the factors affecting customer churn rate in the past year" and "identify abnormal behavior in medical insurance reimbursement." The system calls the natural language parsing module to perform semantic recognition on the field and extracts it into unified string data for subsequent task decomposition and model matching. The extraction process of the demand text includes not only field reading, but also abnormal field correction and missing completion mechanisms, such as automatically calling the historical event completion strategy for null values.

[0042] The entire extraction process must be conducted within the parameters of the model context protocol to ensure compatibility between field extraction from event data and subsequent semantic structure analysis. The model context protocol predefines the possible locations of requirement text in different business scenarios, the agreed-upon content format, and keyword identification logic. This allows the system to achieve unified text extraction without relying on specific call system structures. The triple structure of task ID, user ID, and requirement text is extracted for task planning.

[0043] The Model Context Protocol (MCP) is a protocol mechanism for coordinating the interaction of multi-dimensional information, including task semantics, data features, model selection, and resource scheduling, within multi-model collaborative data analysis systems. Its core function is to bridge the gap between "task language" and "analysis resources" in task-driven analysis scenarios. Rather than a specific communication protocol (such as HTTP or TCP), it is a system-wide context-aware rule system and structured parameter transfer mechanism that enables models to understand the context of business requirements and automatically complete tasks such as model parameter initialization, path planning, and resource selection.

[0044] A model context protocol may include the following characteristics:

[0045] Task semantic mapping capability: Parse natural language or structured business requirement text into structured "analysis task semantics", such as task subject, time range, key indicators, analysis objectives, etc.

[0046] Model selection rule set: This stores a set of matching rules between task semantics and model structure. For example, if the key metric is "customer churn rate," then a logistic regression model is matched; if the task involves "time series forecasting," then an LSTM network is matched.

[0047] Data path configuration strategy: defines how to extract task-related fields from the data source, including field name mapping, data update frequency, data structure description, etc.

[0048] Resource scheduling interface specification: includes model initialization parameter range, training sample requirements, verification method, performance threshold, etc., serving as an intermediary between tasks and the execution engine.

[0049] Feedback information closed-loop mechanism: Supports feedback of user interaction behavior, verification results, model deviation, etc. back to the "context" to iteratively optimize model selection strategies or task decomposition rules.

[0050] In a financial scenario, the system integrates with the credit approval platform and monitors its event bus output. When the system receives an automated analysis request from the credit process, for example, an event containing the fields {"event_id":"REQ234","payload":{"description":"Evaluate common characteristics of loan defaulters in the past six months"}}, it identifies the description field as the request text. If this field is missing, the system retrieves the corresponding data in the historical event sequence with event_id="REQ234" for semantic restoration.

[0051] In healthcare scenarios, the medical insurance settlement system pushes business demand events containing requests for medical record analysis. The system identifies the task_content field as the source of the demand text. Because medical events may contain mixed or coded text in multiple languages, the system uses a multilingual word segmenter and entity disambiguation model to parse the content and extract clear business intent text for subsequent processing.

[0052] If the required text field cannot be identified immediately, the system can combine the business type field in the event payload and locate the field most likely to contain text content through the "Business Type-Field Mapping Table" defined in the model context protocol, and perform redundant field scanning and error correction to ensure that the task purpose extraction is not missed.

[0053] By extracting the semantic content of the analysis target from the business requirement event structure into structured requirement text, the system can automatically identify the user's analysis purpose without manual intervention. This operation provides a semantic basis for subsequent task decomposition, model path planning, and resource scheduling, bridging the critical gap between "task trigger signals" and "analysis resource activation," thereby implementing an automated analysis process generation mechanism centered on business objectives. This mechanism improves the system's adaptability to complex business descriptions, reduces reliance on manually predefined task templates, and significantly improves automation coverage and business response speed.

[0054] S20, extracting the task subject and time range from the requirement text through the model context protocol, and breaking the requirement text into multiple subtasks based on the complexity of the requirement text;

[0055] In this embodiment, the model context protocol is used to perform structured parsing of business requirement text in natural language and to divide its information into tasks. The model context protocol is a model interaction protocol system for task identification and configuration. It encapsulates multiple semantic rules, parsing strategies, and execution interfaces for requirement semantic recognition, entity extraction, temporal expression recognition, complexity judgment, and task planning. This allows the system to deeply understand and operationally decompose unstructured input content with contextual awareness.

[0056] The process of extracting the task subject relies on grammatical parsing of entity-like phrases in the requirement text. The text is first fed into the semantic structure parsing module provided by the model context protocol. This module, based on part-of-speech tagging and dependency syntactic graph generation algorithms, converts the text structure into a lexical relationship graph and identifies a set of entities with subject status or object references to controlling verbs. Phrases within this set that occur frequently or are reinforced by the context are labeled as task subjects, such as "customer credit," "health indicators," and "capital flow."

[0057] The extraction of time ranges relies on the time expression recognition strategy defined in the model context protocol. The system adopts a recognition mechanism based on a hybrid of rule-based and statistical models. It can extract various forms of time expressions from the text, such as absolute time (such as "the third quarter of 2023"), relative time (such as "the past 6 months"), or event-driven time windows (such as "within 30 days of the application date"), and convert them into standardized fields, such as start and end date pairs, duration periods, or sliding window parameters. The standardized time range will be used for subsequent data screening, model training window construction, and other operations.

[0058] The task decomposition part is completed based on the complexity assessment mechanism defined in the model context protocol. The complexity assessment strategy integrates multiple dimensions such as text syntactic depth, number of semantic targets, industry terminology density, nested structure level, etc. For example, multi-target compound expressions (such as "predict customer risks and analyze the causes") will be marked as high-complexity scenarios. According to different complexity levels, the model context protocol triggers the corresponding subtask planning rule library and outputs several subtask identifiers that can be run in parallel or have dependencies. Each subtask is bound to a specific analysis target, time range and expected data path guidance.

[0059] In actual implementation, the following different methods can be used for operation adaptation:

[0060] A dual-channel processing path based on the fusion of dependency syntax trees and entity recognition can be adopted. After word segmentation and part-of-speech tagging, the text is simultaneously input into the structured parsing channel and the named entity recognition channel. The former identifies syntactic hierarchies, while the latter captures industry-specific proper nouns. The outputs of these two channels are merged using fusion rules in the model context protocol for task subject identification.

[0061] A time expression recognition module that is jointly modeled using regular rules and BERT-like contextual semantic models can be used to deal with ambiguous time expressions in medical and health texts, such as "one year after surgery" or "during long-term medication." The normalization capability of time segments can be enhanced by training and fine-tuning the language model.

[0062] Adaptive parameter rule libraries can also be designed for text complexity assessment. For example, in the financial sector, if multiple "if...then..." conditional statements are identified in a sentence, the requirement can be automatically broken down into premise assessment subtasks and result analysis subtasks. In the healthcare sector, task granularity can be set based on the frequency of disease names and the number of indicators.

[0063] In different scenarios, the model context protocol can be configured with a task planning template library, such as a standard risk assessment process, a health intervention path prediction process, etc., to achieve rapid task decomposition and logical inheritance.

[0064] Example: In a healthcare scenario, a doctor enters a free-text request: "Please analyze the changing trends of the patient's inflammatory indicators within two months of surgery and assess whether there are recurrent fevers." Using the model context protocol, the system interprets the task as "inflammatory indicator changes" and "recurrent fevers," with a timeframe of "two months after surgery." The system then decomposes the task into two subtasks: trend analysis and anomaly identification, each bound to a different data extraction path and analysis model.

[0065] In a financial business scenario, an auditor enters the following requirement: "Assess abnormal fluctuations in the accounts of high-net-worth clients over the past six months." The system analyzes the task subject, "account fund fluctuations," and the time range, "past six months," identifying it as a highly complex multi-source data analysis task. It then breaks it down into subtasks: identifying fund fluctuations and correlating them with customer behavior. Subsequent processes automatically map the data table path, model structure, and visualization template for each subtask.

[0066] Through the above parsing process, the system achieves its goal of transforming raw unstructured text input into a clearly structured, traceable, and executable set of analysis tasks. This not only improves the accuracy of automated task recognition, but also ensures the consistency and reusability of task structure recognition across diverse textual expressions. Especially for financial and medical texts with diverse expressions and complex scenarios, the unified model context protocol ensures seamless collaboration between the parsing module and the task scheduling module, significantly reducing reliance on manual configuration.

[0067] S30, based on the subtasks and task body, obtain data source context information through the model context protocol interface, and generate a data extraction path and analysis model selection strategy for each subtask in combination with the knowledge graph reasoning module;

[0068] In this example, we automatically match structured analysis task objectives with available data resources within the system, and generate executable data access paths and analysis model selection strategies for each subtask based on the target requirements. The core of this process lies in the combined use of the model context protocol interface and the knowledge graph reasoning module to achieve dynamic collaboration between task, data, and model.

[0069] The Model Context Protocol Interface (MCPI) serves as a standard communication bridge between the mission planning module and the data resource management module. It defines a unified data source context description structure and interaction request method. Data source context information is a structured metadata collection established for each accessible data source. This information includes fields such as data table structure definition, field meanings, access permission restrictions, interface calling methods, update frequency, available time window, and data granularity level, comprehensively describing the accessibility and adaptability of the data source.

[0070] The knowledge graph reasoning module is built based on the data entity relationship graph maintained in the system. This graph describes the multi-level connection relationships between data tables, fields, and indicators through a graph structure. The nodes represent data tables, indicator items, and business-meaning entities, and the edges represent field mappings, indicator calculation paths, inter-table foreign key dependencies, API output correspondences, and so on. By searching the graph for paths and calculating rules, the system can identify data extraction paths that meet specific analysis goals and automatically perform path quality scoring, including indicators such as query efficiency (such as expected response time), data quality (such as missing rate and update lag), and field matching.

[0071] When a subtask is created, the system first requests contextual information about the data source associated with the task subject from the model context protocol interface, based on the task subject bound to the subtask, as initial screening criteria. After obtaining contextual information for multiple candidate data sources, the system performs a semantic adjacency search within the knowledge graph using the fields or indicator keywords in the task objective, generating a set of data extraction paths that satisfy the semantic associations. Each path starts from the original data node, undergoes field mapping and indicator conversion operations, and ultimately points to the computational data node that meets the analysis objective.

[0072] The system then invokes the path evaluation mechanism defined in the model context protocol to adjust the scoring weights of different paths based on the task priority tags. For example, for tasks with high real-time requirements, the system uses response speed and data freshness as the primary scoring factors. For tasks with higher precision requirements, the system increases field coverage and calculation path completeness. The scoring results are used to select the optimal path from multiple candidate paths.

[0073] After the data extraction path is selected, the system further performs matching in the analysis model set registered with the model context protocol based on the execution scenario label of the subtask (such as classification prediction, cluster analysis, trend modeling) and the set of key indicators extracted. The system first evaluates the model structure adaptability, analyzes the execution efficiency and expected accuracy of different models under the current data source structure, calculates the model load tolerance based on the data volume and update frequency in the data source context, and finally selects an optimal analysis model and generates a parameter configuration set for initializing the model, including learning rate, number of iterations, initialization weight mode, etc.

[0074] The final output is the optimal data extraction path and the corresponding analysis model selection strategy bound to each subtask. The strategy includes not only the model name, but also the initialization method, calling interface, expected running time, and the model performance evaluation mechanism associated with the subtask, ensuring that each subtask has an accurate starting point during subsequent training.

[0075] In different implementation environments, the following technical paths can be used for implementation:

[0076] By building a knowledge graph embedding model based on a graph neural network, we can leverage the vectorized representation of nodes to improve semantic similarity matching capabilities. For example, in financial analysis, the system can establish an implicit connection between "overdue risk score" and "customer loan history" through co-occurrence frequency and semantic context co-training. In healthcare, it can build an aggregate indicator path between "patient vital signs" and "medical records."

[0077] It is also possible to integrate access rights management for data source context information into the authentication mechanism of the model context protocol interface. For example, in a system with strict security policies, the list of accessible data sources can be dynamically loaded based on the business domain to which the task subject belongs and the current user role, preventing access to unauthorized data sources.

[0078] The path scoring mechanism can also be configured as a tunable parameter, allowing developers to set a mapping between task priorities and scoring dimension weights in the model context protocol configuration file. For example, in certain large-scale batch processing tasks, developers can manually increase the weight of the data coverage dimension, sacrificing response time in exchange for result completeness.

[0079] During the analysis model selection phase, the model performance database can also be used to compare the performance of different models on similar data structures in historical tasks, so as to infer the optimal model candidate set in advance without training data evaluation.

[0080] Example: In the healthcare sector, when the subtask objective is "predicting the probability of infection in hospitalized patients within 5 days after surgery," the system identifies the task subject as "postoperative infection" through the model context protocol interface, with key indicators being "temperature changes," "white blood cell count," and "antibiotic usage records." The knowledge graph reasoning module locates the field paths of the three tables: "vital signs monitoring table," "medical order record table," and "test report table." After evaluating the data quality across multiple paths, it selects a path combination that contains complete and non-missing timestamps. Furthermore, during the model matching phase, the system discovered that the random forest model possesses superior accuracy and fault tolerance in similar tasks, and thus automatically generates the data extraction path and random forest initialization parameter strategy for this subtask.

[0081] In the financial technology business field, when the subtask goal is to "analyze the capital outflow risk of high-net-worth clients in the past six months", the system locates the "account transaction flow sheet" and "customer asset sheet" in the knowledge graph based on the "high-net-worth clients" task subject and the key indicator of "capital outflow rate", and screens out data paths that meet the update frequency and authority control in the past six months, and selects the long short-term memory network model suitable for time series analysis as the analysis model, and configures the learning step size and historical window size parameters.

[0082] This embodiment uses the model context protocol interface to obtain context information associated with the data source based on the task body and subtask goals, and combines the knowledge graph reasoning module to generate a data extraction path that meets the analysis goals and a matching analysis model selection strategy. It realizes the entire process of automatic planning of data access paths and model configuration selection for complex business tasks without human intervention, improves the execution accuracy and adaptation efficiency of automated analysis tasks, effectively avoids the subjectivity and uncertainty in manual data and model selection, and is particularly suitable for multi-task processing scenarios with complex data structures and diverse model types, significantly enhancing the system's analysis stability and responsiveness in high-concurrency business environments.

[0083] S40, connecting to a target data source according to the data extraction path corresponding to each subtask and the data source access policy defined by the model context protocol, combined with the access rights in the data source context information, and collecting raw data from the target data source according to the time range;

[0084] In this embodiment, the system first obtains the data extraction path corresponding to the current subtask after task parsing is complete. The data extraction path is a graph structure path that combines the data source structure associated with the task body and the output of the knowledge graph inference module. The path identifies the data tables, field relationships, and operation interfaces required to traverse from the original data node to the target analysis field. This path is a sequence structure stored in the form of node pairs and operation rules, and can include database field reference chains, API call sequences, or hybrid path strategies.

[0085] Before establishing a data source connection, the system invokes the data source access policy defined in the model context protocol. The predefined data source access policy in the model context protocol is a standardized set of access control and authentication policies that specifies how to select the appropriate connection method, request format, authentication mechanism, and access rate adjustment method based on the data source type (e.g., database, object storage, REST API). This policy set may include OAuth authentication rules, database connection pool parameters, security protocol settings (e.g., HTTPS), request throttling strategies, and more.

[0086] When performing access operations, the system also needs to read the access rights recorded in the data source context. This access rights information includes the read / write level, field access scope, and role binding restrictions of the current system or proxy module for the specified data source. This access rights information is used to verify whether the target data source allows the operation requested by the current task within the policy constraints, and to adjust the access method or apply for additional permissions accordingly.

[0087] After successfully connecting to the target data source, the system will limit the data collection scope based on the time range extracted by the subtask in the previous step. The time range can be expressed as a continuous interval (such as the whole year of 2023) or multiple discontinuous intervals (such as the last four quarters). The time range will be converted into specific data query parameters, such as the WHEREtimestamp BETWEEN structure in SQL, the timestamp parameter field in the API, or the time window filter statement in the ES query syntax. The collection process can improve the efficiency and completeness of the collection through mechanisms such as paging pull, streaming parsing, or task-based concurrent decomposition. The collection result is the original data for subsequent preprocessing.

[0088] In database access scenarios, you can establish connections to MySQL or PostgreSQL databases based on the JDBC connection strategy defined in the model context protocol, preferably using a connection pool configuration. Access rights are verified by obtaining the current account's field-level access control list through the database metadata interface. If access rights are denied, the system automatically calls the permission application interface to trigger the approval process. During the time range mapping process, the system generates start and end dates based on the user's selected quarter, converts them into range query conditions for the time field in the WHERE clause, and then splices them into the final SQL statement.

[0089] In the RESTful API access scenario, the system calls the API access policy component in the model context protocol, selects the corresponding data source template from the preset API access template library, and automatically fills in the authentication token, header field and paging parameters. It constructs a GET or POST request body in JSON format based on the task body, field path and time range, accesses and merges the response results page by page.

[0090] In object storage scenarios (such as S3 and OSS), the data extraction path is usually expressed as a directory structure and object prefix. The system expands the path list of all target files based on the wildcard rules and time range in the path, and then initiates parallel download operations in sequence, using incremental identification bits to filter out processed data to form a consistent set of original data.

[0091] Example: In the healthcare sector, an intelligent medical consultation system aims to extract six months of laboratory indicator data for recently admitted chronic disease patients to construct a health trend chart. The system, through previous subtasks, decomposes the generated analysis model and data extraction path and, through the model context protocol, confirms the access policy for the hospital's HIS database. Based on the time range defined in this task, the system generates an SQL query statement to limit the date field range and connects to the data source through the registered access permission account to complete the data collection.

[0092] In a fintech business scenario, the risk analysis department needs to extract records of loan defaults from a specific high-risk industry customer group over the past year. Based on the task subject and data extraction path, the system determines the credit transaction flow table to access. It constructs an authentication request based on the API access policy in the model context protocol and retrieves monthly default data through paginated REST API calls, forming a complete raw data set for subsequent analysis.

[0093] This embodiment combines the data extraction path with the data source access strategy defined by the model context protocol to automatically identify the data source type and access method required for the current subtask, and completes the connection to the target data source under the permission constraints provided by the data source context information. It further combines the time range to limit the collection conditions to achieve accurate, efficient and controlled collection of raw data, avoiding connection failures or data omissions caused by policy configuration differences, permission conflicts or incorrect time window settings, and effectively supporting the stable operation of subsequent data analysis processes.

[0094] S50, preprocessing the original data, and splitting the preprocessed data into training data and verification data according to the partitioning strategy defined by the model context protocol;

[0095] In this embodiment, raw data is a collection of unprocessed data collected from the target data source within a time range. It may contain missing values, outliers, inconsistent encodings, or unstructured feature distributions. To ensure the stability of subsequent model training and the reliability of inference results, the system performs standardized preprocessing on this raw data. This preprocessing process includes multiple sub-processes, including data cleaning, type specification, feature conversion, and format unification.

[0096] Data cleaning operations rely on the data cleaning strategies defined in the model context protocol. Common strategies include missing value imputation, outlier identification and removal, data deduplication, and field standardization. For example, for missing value fields, methods such as mean filling, median substitution, forward / backward filling, and deletion of missing records can be used according to the cleaning parameters configured in the model context protocol. Outlier identification can be achieved by combining rule-based models (such as Z-score and IQR) with machine learning models (such as isolation forest) for multi-strategy fusion and screening.

[0097] After cleaning, feature engineering is required. The feature engineering strategy is also predefined by the model context protocol and includes category encoding (such as one-hot or label encoding), numerical normalization, timestamp-derived feature generation, and dimensionality reduction. This process outputs a featurized dataset with unified structure, consistent semantics, and standardized data format, providing the foundation for training and validation.

[0098] The model context protocol also defines a data partitioning strategy. This strategy specifies how to divide the featurized dataset into training and validation data. This partitioning strategy can use time window partitioning (for time series data), random sampling, or stratified sampling (for static data). Time window partitioning divides the data into training and validation intervals based on the temporal attributes of the subtasks, ensuring temporal consistency. Random sampling is used to shuffle and then partition proportionally, while stratified sampling maintains a balanced distribution of target variable categories before partitioning.

[0099] Finally, the system explicitly labels the training data and validation data as input for subsequent model initialization and performance verification.

[0100] When processing time series data, you can set the training time window to "past 6 months" and the verification time window to "last month" according to the partitioning strategy parameters in the model context protocol. The system will sort the characterized data by timestamp and segment it, outputting two sets of temporally continuous data sets.

[0101] For static structured data, the stratified sampling module defined in the model context protocol can be called to first calculate the distribution characteristics of the target variable, and then stratify the training and validation subsets according to a preset ratio (e.g., 80:20) to maintain sample distribution consistency. This partitioning process supports the calculation and adjustment of distribution deviation to ensure the representativeness of the validation set.

[0102] To improve processing efficiency in large-scale data environments, the system can enable a streaming preprocessing engine that performs simultaneous cleaning, feature conversion, and partitioning, caching intermediate results in a distributed storage structure. The partitioning operation supports multi-copy maintenance and label consistency verification.

[0103] This embodiment combines the cleaning strategy, feature engineering strategy, and partitioning strategy defined in the model context protocol to complete standardized preprocessing of the original data and divide it into training data and verification data. This not only improves data consistency and model input quality, but also enhances the ability to compare training and verification effects through flexible strategies such as time windows or stratified sampling, effectively supporting the model robustness assessment and parameter optimization process.

[0104] S60, determining a target analysis model according to the analysis model selection strategy corresponding to each subtask, and training the target analysis model using the training data;

[0105] In this embodiment, after each subtask is disassembled, the analysis model selection strategy has been determined in the previous step based on the task body, key indicator information, and context environment. This analysis model selection strategy is derived from the unified definition of the model context protocol, which includes the model type selection rules, evaluation criteria, constraints, and initialization process settings. The strategy is not only based on the task semantics and data structure characteristics, but can also be dynamically adjusted based on the computing resource constraints of the execution environment and the target optimization goals (such as accuracy priority or latency priority).

[0106] The system first reads the analysis model selection strategy for each subtask. This strategy may specify model categories including, but not limited to, logistic regression, gradient boosting trees, support vector machines, time series prediction models, graph neural networks, or deep learning structures. The choice of model type closely corresponds to the task objectives. For example, classification tasks tend to choose logistic regression or XGBoost, regression tasks choose linear regression or neural network structures, and sequence modeling tasks may use RNNs, Transformers, etc.

[0107] After determining the target analysis model, the system needs to provide it with an initial parameter configuration. This configuration, also provided by the model context protocol, includes the learning rate, regularization parameter, number of iterations, optimizer type, and more. Subsequently, the previously partitioned training data is fed into the target analysis model, and a standardized training process is executed. During training, the model continuously adjusts its internal weight parameters based on error feedback to adapt to the structural patterns in the training data.

[0108] The model training process can adopt batch-based, mini-batch, or incremental training (online), and can automatically switch based on data volume or resource constraints. During training, the system can call on the performance monitoring module to record real-time metrics such as training loss, precision, recall, and F1 score. After model training is completed, the system will output the trained model structure and weights and package them for inference.

[0109] When working with structured business scenarios, candidate analysis models can be set to logistic regression, decision trees, and lightweight neural network structures. The model context protocol predefines a set of training configurations for each model type. For example, for logistic regression, L2 regularization is used, a learning rate of 0.01 is set, and the maximum number of iterations is 200. For neural network models, a two-layer fully connected network structure with 64 neurons per layer is set, using the ReLU activation function and the Adam optimizer.

[0110] The system feeds training data into the model in batches, performing forward and backward propagation and adjusting parameters based on the error. If a distributed training framework is enabled, the training data can be divided and fed to multiple nodes in parallel, accelerating the training process. After model training is complete, the system verifies the model's performance stability. If it falls short of the specified performance targets, the system can adjust the number of training rounds or switch to an alternative model in the strategy.

[0111] Example: In the healthcare field, a subtask might involve predicting blood sugar fluctuations in diabetic patients. Based on the analytical model selection strategy, the system selects a time series neural network architecture, such as an LSTM. The training data consists of the patient's blood sugar levels over the past six months. The system trains the LSTM model for thirty epochs using the Adam optimizer with a learning rate of 0.001. After training, the model can accurately predict blood sugar levels for the next few days, enabling remote intervention.

[0112] In a financial scenario, a subtask might be modeling user credit scores. The analytical model selection strategy selected a gradient boosting decision tree (such as LightGBM) based on the metric type. The system used historical user behavior data and default labels as training data, configured the tree depth to 6, the subsample ratio to 0.8, and performed 100 rounds of iterative training. After training, the model performed stably in cross-validation and was ready for online use.

[0113] This embodiment determines the target analysis model by combining the analysis model selection strategy of the subtask and uses the training data to perform standardized training on the model. It not only achieves high adaptability between the task and the model, but also ensures that the model can fully learn its internal laws under the constraints of clearly structured data, thereby providing a stable and reliable algorithm foundation for subsequent reasoning and verification links, and improving the intelligence and accuracy of the overall data analysis process.

[0114] S70, performing reasoning based on the verification data using the trained target analysis model to generate a subtask reasoning result;

[0115] In this embodiment, after training, the target analysis model is capable of extracting relevant information from input features and making output decisions. To determine the model's generalization ability to unknown data, the system performs inference operations on datasets that were not involved in the training process. Validation data, derived from the data partitioning during the preprocessing phase, is a mutually exclusive complement of the training data in terms of time, content, or samples. It is representative but has not been "seen" by the model.

[0116] The inference process involves inputting each sample from the validation data into the trained target analysis model, passing through a forward propagation structure driven by the model parameters, and outputting a prediction result. Depending on the type of target analysis model, the output can be a class label (classification model), a numerical prediction value (regression model), a probability distribution (logistic regression, Bayesian model), a time series prediction value (time series model), a structured vector (graph model, embedding model), and so on.

[0117] The entire inference process is automatically triggered by the system, requiring no human intervention. The model context protocol provides an inference interface specification, standardizing input feature formats, output structure standards, batch processing methods, and fault tolerance mechanisms. Inference can be executed locally or in remote service nodes, with the system selecting the appropriate execution container based on model size and resource scheduling strategies.

[0118] Every inference operation is recorded, and the system can optionally enable output caching to support subsequent model result backtracking or comparison with historical outputs. The system also records the corresponding verification sample identifier, predicted value, and base model version for each inference result, forming a complete set of subtask inference results as input for subsequent result verification and closed-loop feedback.

[0119] For classification models, the inference result is a predicted class value for each sample. The system can enable a Softmax output layer when calling the model, mapping the model scores to probabilities and selecting the class with the highest probability as the final output. In the standard model context protocol, the output format is an array of key-value pairs, containing the predicted class and corresponding probability, to facilitate subsequent evaluation.

[0120] In regression tasks, the model output is a continuous numeric value. The system uses standard metrics such as mean squared error and mean absolute error to compare the output value with the true labels of validation samples in real time, generating a preliminary performance overview. For time series models, the inference process sequentially inputs multiple historical data segments into the model and outputs a sequence of values ​​in the future prediction window.

[0121] For large models or resource-constrained environments, the system can use an offline inference mechanism to deploy verification data and models to edge nodes or asynchronous computing clusters. Through the asynchronous queue protocol in the model context protocol, verification data is batched into the model inference interface, and the system asynchronously receives the results and records the status code.

[0122] This embodiment uses the target analysis model to perform inference on validation data after training, accurately restoring the model's behavior on unknown data and thereby obtaining the true predictive power of each subtask under the current policy configuration. This inference mechanism not only enhances the system's ability to assess model quality in real time but also provides clear data support for subsequent result verification, anomaly feedback, and model optimization.

[0123] S80, calling the result verification model to verify the subtask reasoning result and generate a verification result.

[0124] In this embodiment, the core function of the result verification model is to determine the validity of the subtask inference results generated by the trained target analysis model, assessing the accuracy and reliability of the model output in real-world business scenarios. The core concept of verification is to compare the deviation of model outputs from historical performance or industry standards using multiple reference dimensions to determine the credibility of the results and whether strategy adjustments or task restarts are necessary.

[0125] First, the subtask inference results are the direct output of the inference phase, typically containing predictions, classification labels, or other structured data. Each inference result corresponds to a validation data sample, so verification requires alignment.

[0126] The result verification model calls historical data associated with the current subtask's inference results from the historical data trend module. This historical data constitutes a collection of the model's past performance under similar input conditions, typically including continuous outputs of similar tasks over time, system feedback labels, and manual review data.

[0127] At the same time, the result verification model will also connect to the industry benchmark module to call standard rules, expected ranges, abnormal thresholds, national industry reports, field consensus parameters and other content related to the current task to form an industry comparison baseline.

[0128] When performing deviation analysis, the system compares the inference results with historical trends and industry benchmarks, including numerical differences, structural differences, and distribution similarities. For example, for regression tasks, metrics such as relative error rate and standard deviation offset are used for verification; for classification tasks, the confidence level of the results and label consistency are evaluated.

[0129] The validation model also generates a validation status marker, with marker types including "valid," "boundary deviation," and "significant anomaly." Each marker corresponds to a specific result processing strategy. The validation status marker is associated with the subtask identifier of the inference result and is accompanied by an abnormal data sample or a complete data sample for subsequent feedback adjustment mechanisms.

[0130] Finally, the verification results are output in a structured format, including: deviation value, verification status mark, subtask identifier, verification sample set, etc., providing an input basis for subsequent visualization, task feedback, and strategy update.

[0131] In specific implementation, the result verification model can work through the following process:

[0132] First, the system creates a unique identifier for each subtask's inference result, using this identifier to index and verify the dataset and reference data source. For financial risk control tasks, the system retrieves the historical mean and fluctuation range of default probabilities for that customer group from historical transaction records. For medical risk prediction tasks, the system extracts diagnostic pathways and outcome statistics for similar patients from past hospitalization data.

[0133] The system inputs the inference results and two reference values—historical trend data and industry standard values—into the deviation analysis engine. The deviation analysis module supports multiple comparison algorithms, such as Z-score evaluation, quantile shift analysis, and dynamic window trendline fitting. The system automatically selects the appropriate algorithm based on the task type.

[0134] The system also evaluates the confidence level of the predicted distribution on the validation sample. For example, if the confidence in the inference result is too low, the central tendency shift is obvious, or there are many abnormal results, the validation model will actively mark the result as "deviant" or "abnormal".

[0135] At the output level, the verification model constructs a structured JSON format, encapsulating the deviation value, verification status, original prediction value, reference value and related data samples of each subtask as verification results for use by the subsequent feedback mechanism.

[0136] Example: In the healthcare field, if the inference result of a subtask is a predicted score for the malignancy of a lung nodule, the system will use confirmed scoring samples from similar CT imaging data from the past six months as historical trends, and combine them with the malignancy score boundaries defined in authoritative medical literature as industry benchmarks. If the current model's predicted score deviates by more than two standard deviations from the historical median and is higher than the clinical risk value, the validation model will mark the prediction as "high-risk anomaly" and attach a suspected sample for doctor review.

[0137] In the financial sector, if a subtask's inference results in a downgrade of a company's credit rating, the validation model will retrieve the company's historical credit fluctuation range and the current industry rating standard. If the model's downgrade significantly exceeds the historical maximum fluctuation and differs from the industry rating by more than one level, the system will flag the result as "abnormal inference" and provide feedback to the policy engine to assess whether the analysis model needs to be reassigned.

[0138] This embodiment builds a result verification model. After the model completes inference, it evaluates the deviation of each subtask's inference results based on historical trends and industry benchmarks. This allows for dynamic assessment of the credibility of the prediction results without interrupting the main process. This verification status marking mechanism allows the system to promptly identify deviation risks and establish a closed-loop task feedback loop, improving the stability, reliability, and business adaptability of the automated data analysis system.

[0139] The present invention relates to the field of data processing technology and can be applied to business scenarios such as financial technology and medical health. A data processing method based on a context protocol is disclosed, comprising: receiving a business demand event and extracting the demand text; extracting the task body and time range through a model context protocol, and decomposing the task into multiple subtasks according to the complexity of the demand text; obtaining data source context information based on the subtasks and the task body, and generating a data extraction path and an analysis model selection strategy in combination with a knowledge graph reasoning module; connecting to a target data source and collecting raw data according to the data extraction path and access strategy; preprocessing the raw data and splitting the preprocessed data into training data and verification data according to a partitioning strategy; determining a target analysis model based on an analysis model selection strategy and training the model using the training data; executing reasoning based on the verification data using the trained model to generate a subtask reasoning result; calling a result verification model to compare the subtask reasoning result to generate a verification result. The present invention uniformly manages task elements and execution strategies through a model context protocol, combines knowledge graph reasoning to achieve adaptation of data paths and model selection, and promotes standardization of analysis processes with a training-verification structure, ultimately building an automated closed loop from task decomposition, data extraction, model training to result verification, significantly improving the execution efficiency and analysis accuracy of data analysis tasks.

[0140] In one embodiment, the above step S20 includes:

[0141] S201, calling the semantic structure parsing interface in the model context protocol, performing part-of-speech tagging and dependency syntax analysis on the demand text, and generating a lexical dependency graph;

[0142] S202, identifying entity phrases representing analysis targets in the requirement text based on the lexical dependency graph, and marking the entity phrases as task subjects;

[0143] S203, extracting the time range description in the requirement text based on the time expression recognition strategy defined in the model context protocol, and converting the time range description into a standardized time field;

[0144] S204: performing syntactic depth analysis, semantic target quantity statistics, and domain term density evaluation on the requirement text according to the semantic structure complexity evaluation parameters defined in the model context protocol to generate a complexity level;

[0145] S205 , based on the complexity level and in accordance with the subtask decomposition strategy in the model context protocol, decompose the requirement text into a plurality of subtasks, and generate a subtask identifier for each subtask.

[0146] In this embodiment, in the process of processing the demand text, it is first necessary to perform language-level parsing operations on the text through the semantic structure parsing interface in the model context protocol. The semantic structure parsing interface mainly provides grammatical analysis capabilities, including part-of-speech tagging and dependency syntax analysis. Part-of-speech tagging is used to identify the role attributes of each word in the syntactic structure of the text, such as whether it is a noun, verb or time modifier. Dependency syntax analysis is to establish a logical dependency graph between words to form a lexical dependency graph, which is used to characterize the subject-predicate relationship, modification relationship and prepositional structure in the sentence. The lexical dependency graph is the basis for subsequent analysis target extraction, time range identification and complexity assessment.

[0147] After constructing the lexical dependency graph, the system uses its topological structure to identify entity phrases with semantically central features. These entity phrases typically reside between the predicate and the object in a sentence and have a direct dependency path with the verb. Noun phrases with verb dependencies such as "analyze," "predict," and "monitor" are often identified as task subjects. For example, in the task "Analyze customer repayment behavior in 2023," "customer repayment behavior" is an entity phrase and can be marked as the task subject.

[0148] Next, the system invokes the time expression recognition strategy defined in the model context protocol. This strategy integrates regular expression templates, a sequence annotation model, and a contextual rule library to extract time interval descriptions contained in the requirement text, such as "the past six months" or "the fourth quarter of 2021." The recognized time expressions are converted into a unified start and end time format through a standardized mapping mechanism, forming standardized time fields for subsequent data extraction and modeling.

[0149] Next, the system needs to assess the semantic structural complexity of the requirement text. This assessment is based on a set of parameters defined in the model context protocol, typically including syntactic depth, number of semantic targets, and domain term density. Syntactic depth determines the text's nested complexity by parsing the syntax tree hierarchy, semantic target counts the number of explicitly stated analysis targets in the text, and domain term density determines the coverage of domain-related terms based on a specialized vocabulary dictionary. These metrics are then fed into the complexity level generation logic to form the text's semantic complexity score.

[0150] Based on the complexity level, the system then performs text decomposition according to the subtask decomposition strategy predefined in the model context protocol. This strategy maps complexity level to decomposition method. For example, a "high" complexity level requires decomposition into five or more subtasks, while a "medium" complexity level requires decomposition into three to five subtasks. Each subtask generates a unique subtask identifier based on its analysis objective, processing scope, time window, and other dimensions. This identifier is used to track the entire process of task scheduling, model matching, and result feedback.

[0151] In specific implementation, the Model Context Protocol interface integrates contextual semantic models such as BERT within the natural language processing platform to implement part-of-speech tagging and dependency parsing. It also extracts contextual entities by constructing a lexical dependency graph based on a directed graph structure. The edge weights of the lexical dependency graph represent the type of relationship between words, and the graph traversal uses a breadth-first search algorithm to determine the central term. The temporal expression recognition strategy uses a CRF model or a Transformer-based named entity recognition network to identify temporal phrases, combining regularization with normalization. For example, "the past six months" can be converted to start and end timestamps relative to the current system time. During complexity assessment, the system uses a predefined syntactic parse tree template to calculate syntactic depth. The analysis target identification module then detects the number of analysis dimensions in a requirement. For example, if "analyze customer behavior and predict risk levels" is included, two semantic targets are identified. Domain term matching utilizes multi-industry lexicons (e.g., finance and healthcare) for phrase matching and density calculation. The subtask decomposition strategy is defined in the strategy mapping table of the Model Context Protocol. For example, when the complexity level is "high", the system divides the requirement text into multiple task segments according to the target dimension. Each segment constitutes a subtask and generates task numbers such as T-20240418-001 to T-20240418-005 to facilitate task lifecycle management.

[0152] This example, by building a semantic structure parsing process, achieves a highly integrated approach to task subject identification, time range normalization, and semantic complexity assessment when processing business requirement text. Furthermore, through a structured subtask decomposition strategy, complex text is efficiently divided into multiple independently processable analysis tasks, improving the system's scalability and accuracy when handling cross-domain analysis objectives and complex language expressions.

[0153] In one embodiment, the above step S30 includes:

[0154] S301, extracting key indicator information from the requirement text through the model context protocol;

[0155] S302, based on the analysis target of the current subtask, access the data source context information associated with the task subject through the model context protocol interface;

[0156] S303, constructing a data source relationship graph based on the data structure description in the data source context information according to the dependency constraints of the current subtask;

[0157] S304: Calling the knowledge graph reasoning module to parse the data source relationship graph and generate a set of candidate data extraction paths that meet the analysis objectives of the current subtask;

[0158] S305, analyzing the query efficiency score and data quality score of each candidate data extraction path in the candidate data extraction path set using the path evaluation model defined in the model context protocol, adjusting the score ranking according to the priority weight of the current subtask, and selecting the optimal data extraction path;

[0159] S306, based on the execution scenario of the current subtask and the task subject and key indicator information, matching the set of candidate analysis models predefined in the model context protocol through the knowledge graph reasoning module;

[0160] S307, calling the model performance evaluation interface in the model context protocol, performing execution efficiency and accuracy prediction on each analysis model in the candidate analysis model set based on the update frequency and data level in the data source context information, and generating a model fitness score;

[0161] S308, selecting a target analysis model from the candidate analysis model set according to the model fitness score, and generating a corresponding model parameter initialization strategy;

[0162] S309: Using the optimal data extraction path and the target analysis model parameter initialization strategy as the data extraction path and analysis model selection strategy for the current subtask.

[0163] In this embodiment, to generate the data extraction path and analysis model selection strategy for each subtask, key indicator information, obtained from the requirement text parsing, is first obtained from the model context protocol. Key indicator information is fundamental variables used to guide subsequent model selection and data path planning. Its types can include but are not limited to classification indicators, regression indicators, interval statistics indicators, etc. After extraction during the semantic parsing phase, it is stored in the structured context for reference in the current phase.

[0164] Based on the analysis objective of the current subtask, the system accesses the data source context information associated with the task body through the model context protocol interface. Data source context information is a structured collection of resource descriptions, including data source access permissions (such as API keys and access control identifiers), data structure descriptions (such as field types, index information, and inter-table relationships), and dynamic dimensions such as data update frequency. The task body provides data scope limitations, while the analysis objective of the subtask further limits the field range and data time window.

[0165] After obtaining data source context, the system constructs a data source relationship graph based on the dependency constraints of the current subtask and the data structure description. This relationship graph represents structured data as a graph of nodes and edges, where nodes represent accessible data tables or API endpoints, and edges represent foreign key constraints, business dependencies, or interface call chains. This supports unified representation of cross-system, multi-source, and heterogeneous data mapping.

[0166] The system then calls the knowledge graph reasoning module to generate a set of candidate data extraction paths that meet the analysis objectives of the current subtask based on the topological structure and node attributes of the data source relationship graph. A candidate path is a set of connected paths from the data entry table to the analysis target field table. The path may include key steps such as field mapping, join conditions, and aggregation strategies.

[0167] Each candidate data extraction path is scored using the path evaluation model defined in the model context protocol. This model is based on two core metrics: query efficiency (e.g., response time prediction and index hit rate) and data quality (e.g., miss rate and update latency). Furthermore, the system adjusts the scoring and sorting logic based on the current subtask's priority weight, ensuring that high-quality paths are prioritized for critical tasks.

[0168] Based on the subtask's execution scenario, task subject, and key indicator information, the system calls the knowledge graph reasoning module to match the set of candidate analysis models predefined in the model context protocol. The candidate model set typically includes multiple algorithmic models and their corresponding constraints, such as logistic regression, random forest, and time series analysis network. Each model type has an explicit mapping relationship with its applicable indicator type and data volume range.

[0169] The system then calls the model performance evaluation interface in the model context protocol, combines the update frequency and data level in the data source context information, predicts the execution efficiency (such as training time, memory usage) and accuracy indicators (such as F1 value, mean square error) of each candidate analysis model, and generates a model fitness score.

[0170] Finally, the system selects the target analysis model based on the model fitness score and generates a model parameter initialization strategy for it. This strategy includes setting initial hyperparameter values, configuring regularization terms, and selecting an optimizer, ensuring rapid convergence and stable performance in subsequent training phases. The system then pairs the optimal data extraction path with the target model parameter initialization strategy and outputs it as the basis for executing the current subtask.

[0171] In implementation, the model context protocol interface is exposed to the data planning module as a JSON-RPC or gRPC service, allowing access to historical parsing results and parameter rules. Key metric information is extracted by the entity recognizer in the requirements parsing module. This information is then combined with the metric dictionary and metric classifier to construct a structured metric object, recording the metric name, value range, data type, and business domain. Data source context information can be provided by the metadata management platform and stored in a relational or graph database. The system retrieves context information by mapping data source identifiers to task entities. It further filters redundant metadata based on subtask field requirements, ensuring that the data source relationship graph only reflects entities directly related to the current task. The knowledge graph reasoning module can be implemented based on a graph neural network model, using a graph convolutional network to construct a path scoring function to measure the importance and reliability of a path. During path evaluation, the system combines graph topology weights, path length, and historical execution records to generate a query efficiency prediction function. It also calculates the data coverage and consistency of the target field in the path to generate a comprehensive score. The collection of candidate analysis models can be managed through configuration files or a model repository, with each model accompanied by metric adaptation rules and resource consumption descriptions. The system uses a rules engine to perform logical analysis on the indicator type, data volume, and real-time requirements of the current subtask. It then selects candidate models from the model set and performs estimated simulations to generate a ranking result. The model fitness score comprehensively considers training convergence time, prediction error upper bound, and system resource load. A weighted function is used to output a score, which drives the final model selection process.

[0172] This embodiment achieves subtask-level data path planning and analytical model adaptation capabilities by structuredly organizing data source context and key indicator information, combined with graph-based path reasoning and candidate model screening. Relying on the scoring rules and execution efficiency estimation methods defined by the model context protocol, the system can quickly locate high-quality data source paths in large-scale multi-source data scenarios and automatically match applicable analytical models, significantly improving the accuracy and stability of the automated analysis chain.

[0173] In one embodiment, the above step S50 includes:

[0174] S501, calling a data cleaning strategy predefined in a model context protocol to perform data cleaning processing on the raw data to generate a standardized data set;

[0175] S502, performing feature encoding and dimension compression operations on the standardized dataset based on the feature engineering strategy defined in the model context protocol to generate a feature-based dataset;

[0176] S503, performing a data partitioning operation on the characterized data set according to the partitioning strategy parameters defined in the model context protocol, wherein the partitioning strategy parameters include a time window length, a random sampling ratio, and / or a stratified sampling strategy;

[0177] S504, when the characterized data set includes a time series attribute, dividing the data in the characterized data set into training time window data and verification time window data according to the time window length;

[0178] S505, when the characterized data set is static structured data, dividing the data in the characterized data set into a training data subset and a validation data subset according to the random sampling ratio or stratified sampling strategy;

[0179] S506: Mark the training time window data or the training data subset as training data, and mark the verification time window data or the verification data subset as verification data.

[0180] In this embodiment, preprocessing of raw data is a key step in the data analysis process that connects data collection and model training, covering the entire process from raw data cleaning to feature extraction and structured transformation. In implementation, the system first initiates the cleaning process based on the data cleaning strategy predefined in the model context protocol. This strategy includes missing value filling, format standardization, outlier identification and removal, etc., and is used to remove redundant, invalid or contaminated samples. The data cleaning strategy can be customized based on the data source type, field attributes and exception rules. For example, financial transaction logs may set a range threshold for the amount field, while medical examination data may set a collection frequency tolerance upper limit.

[0181] After cleaning, the resulting standardized dataset enters the feature engineering phase. Feature engineering strategies are defined as a set of rules within the model context protocol. These include, but are not limited to, feature encoding methods (such as one-hot encoding, label encoding, and embedding mapping) and dimensionality reduction algorithms (such as principal component analysis, linear discriminant analysis, and autoencoder dimensionality reduction). Feature engineering operations transform raw fields into vector representations that are easier for the model to process, improving model learning efficiency while preventing the curse of dimensionality. The resulting featurized dataset exhibits structural consistency, dimensionality reduction, and domain adaptability.

[0182] The system then splits the featurized dataset according to the data partitioning strategy defined in the model context protocol. This partitioning strategy is driven by a set of parameters, including the time window length, random sampling ratio, and stratified sampling strategy, to support flexible partitioning of different data types. The system first identifies whether the featurized dataset contains time series attributes. If so, it prioritizes continuous window partitioning based on time window length. This process maintains the contextual continuity of the time series, ensuring that the training and validation data are consistent and non-overlapping in the temporal dimension.

[0183] If the data is statically structured, the system processes it based on the random sampling ratio or stratified sampling strategy configured in the partitioning strategy parameters. The random sampling ratio controls the partitioning ratio, for example, splitting a dataset in an 8:2 ratio, while the stratified sampling strategy achieves sample balance based on label categories or field distribution characteristics, and is often used for data partitioning in imbalanced classification tasks.

[0184] Finally, the subsets generated according to the division method are marked as training data or verification data. The training time window data or the training data subset is used as the input source for model parameter learning, and the verification time window data or the verification data subset is used for model performance evaluation to ensure the structural stability and source consistency of the data flow during the model training and verification stages.

[0185] During system deployment, the policy configuration platform centrally manages the set of preprocessing policies defined by the model context protocol. Data cleansing policies can be configured using a rule engine, for example, specifying "remove samples if the missing rate of field A exceeds 10%" or "treat field B as an error if the format doesn't match the regular expression, YYYY-MM-DD." The cleansing process can be executed by data processing engines such as Spark, Pandas, or Flink. Feature engineering strategies can be implemented by configuring an execution graph using predefined operator chains, such as: field label encoding → embedding representation → normalization → PCA dimensionality reduction. The system automatically matches the applicable policy set based on data source labels and constructs a featurized dataset through vector pipeline processing. The partitioning strategy execution process uses the policy scheduling module to dynamically match the partitioning method. If the data source contains a timestamp field, the system defaults to time window partitioning mode, generating training and validation time periods using sliding windows of a specified length. If the data lacks a clear temporal order, random sampling is used by default, and stratified sampling can be enabled to maintain consistent distribution of key fields (such as categorical fields) across the training and validation sets. The final partitioning result is written into a data container with the "training" or "validation" identifier for separate calls to the subsequent model training module and validation module.

[0186] This embodiment integrates the data cleaning strategy, feature engineering strategy and partitioning strategy defined in the model context protocol into the data preprocessing process, thereby realizing automatic control of the entire process of raw data from structural standardization to semantic encoding to partitioning output. It not only improves data quality and feature expression capabilities, but also ensures the temporal, semantic and structural isolation between training data and verification data, providing stable input for subsequent model training and evaluation, thereby improving the reliability, adaptability and generalization performance of the analysis model.

[0187] In one embodiment, the above step S80 includes:

[0188] S801, calling the historical data trend module to obtain historical time period data corresponding to the subtask reasoning result;

[0189] S802, calling the industry benchmark module to obtain the industry standard reference value related to the subtask reasoning result;

[0190] S803, analyzing the deviation between the subtask reasoning result and the historical time period data and the industry standard reference value through the result verification model;

[0191] S804, initializing the verification status mark of the subtask reasoning result;

[0192] S805, when the deviation exceeds a preset threshold, setting the value of the verification status mark to abnormal, and associating the verification status mark with the subtask identifier corresponding to the subtask reasoning result and the abnormal data sample;

[0193] S806, when the deviation does not exceed the preset threshold, setting the value of the verification status mark to valid, and associating the verification status mark with the subtask identifier and the complete data sample corresponding to the subtask reasoning result;

[0194] S807: Output the deviation, verification status mark, subtask identifier and data sample as the verification result.

[0195] In this embodiment, the result verification model is called to verify the subtask reasoning results, and a quality control and feedback closed-loop mechanism is established in the data analysis process. The process first relies on the historical data trend module to provide a reference basis for the horizontal time dimension, which is used to capture the evolution trajectory of the subtask reasoning results in the past time period. The historical data trend module can match the relevant historical data interval based on the task identifier or reasoning output type, and generate a data subset for the corresponding time period for comparative analysis. It is matched with the industry benchmark module, whose function is to provide vertical standardized indicators for comparing the reasoning results with the industry average level, regulatory threshold or market general reference standard in the current business field. The industry benchmark value can be derived from the parameter model published by the regulatory authorities, the quantitative indicators of the third-party risk rating agency, or the historical experience indicators of the enterprise's internal risk audit system.

[0196] After obtaining the reference data, the verification module uses a built-in deviation calculation model to analyze the degree of difference between the current subtask's inference results and the reference data. This deviation calculation model can include statistical deviation analysis methods (such as mean squared error and relative error percentage), distribution distance analysis methods (such as KL divergence and Wasserstein distance), or an evaluation mechanism that combines a weighted combination of domain prior rules. The calculation results output a numerical deviation indicator, indicating the offset between the inference result and the expected reference.

[0197] After performing the deviation analysis, the system will automatically initialize the verification status mark of the subtask reasoning result to record the verification conclusion. The verification status mark has a preset state set, usually including "abnormal", "valid", "need to be reviewed" and other states, and the default initial state is empty. In actual execution, if the deviation exceeds the preset threshold, the mark state is set to abnormal, and the abnormal state is recorded and mapped to the corresponding subtask identifier at the same time. At the same time, the abnormal samples in the reasoning result are extracted for subsequent model analysis; if the deviation is within an acceptable range, it is marked as valid, and the complete reasoning data sample is stored for verification log archiving and downstream visualization component loading.

[0198] Finally, the verification module packages and outputs the deviation value, verification status mark, subtask identifier, and data sample to form a structured verification result object, which is used for response processing, feedback optimization, or user display in subsequent analysis processes.

[0199] The above modules can be implemented using a component-oriented verification process design. The historical data trend module uses the task identifier recorded in the task management system to access timestamps of historical data from a relational database or data lake. It then uses partitioned queries or window functions to extract data segments for the past 7, 30, or multiple statistical periods. The industry benchmark module can access external industry interfaces (such as financial credit rating APIs and medical insurance benchmarking systems) or periodically load local standard templates to provide the industry threshold indicators required for the current task type. Deviation analysis can be configured in multiple modes, and the system supports dynamic switching of deviation calculation models based on task type. For example, for regression tasks, mean squared error and percentage error can be used as primary metrics; for classification tasks, the KL divergence between the confidence interval of the probability output and the true label distribution can be used to measure prediction deviation. For each calculation method, the system allows business operators or risk control policy makers to pre-configure acceptable deviation thresholds, allowing them to directly determine whether to trigger an abnormal state at runtime. Abnormal and valid state marking can be implemented as a state machine. During the verification phase, each subtask inference result generates a state object that is bound to the task ID. When the status is abnormal, the system automatically extracts the input samples, key intermediate features, and prediction results of the inference output to form an abnormal data sample package. If the verification is valid, the complete output structure and upstream and downstream reference information are extracted and retained as verification closed-loop materials. The final verification result object structure includes a scalar value (deviation), an enumeration value (verification status), a string (subtask identifier), and a data structure (sample), which is stored in a unified verification log management module.

[0200] This embodiment introduces a historical data trend module and an industry benchmark module as multi-dimensional reference bases, and combines them with a result verification model to implement a deviation calculation and status marking mechanism. It can not only accurately determine whether the reasoning results of the analysis model deviate from historical laws or industry norms, but also achieve closed-loop optimization through an abnormal sample feedback mechanism, thereby enhancing the reliability, transparency and explainability of the overall data analysis process, thereby effectively improving the system's result stability and risk control adaptability in high-risk scenarios.

[0201] In one embodiment, after the above step S80, the method further includes:

[0202] S901, matching a preset visualization template library according to the data type of the verification result;

[0203] S902, calling a visualization rendering engine to generate a graphical display component corresponding to the visualization template library;

[0204] S903, receiving a user interaction event and parsing a display adjustment instruction in the user interaction event;

[0205] S904, updating the coordinate axis scale and data label display position of the graphical display component according to the display adjustment instruction;

[0206] S905, record the user viewing time and click hotspot information in the user interaction event, pass the user viewing time and click hotspot information to the generation process of the analysis model selection strategy, and update the current subtask disassembly strategy based on the user viewing time and click hotspot information.

[0207] In this embodiment, after completing the verification of the subtask reasoning results, the verification results are further used to build a dynamic and interactive display interface to improve the perception ability and feedback efficiency of the analysis output. The first step is to match the appropriate template type from the preset visualization template library according to the data type of the verification result. Data types include but are not limited to numerical distribution classes, category comparison classes, time series evolution classes, spatial geography classes, etc. Different data types require different graphic components for display (such as line charts, radar charts, heat maps, map markers, etc.). The template library defines the mapping rules between various types of data and graphic templates in a structured manner, including coordinate dimension structure, graphic type, label layout, and color layering scheme.

[0208] Once the matching is complete, the system calls the visualization rendering engine to load the selected template and automatically populates the graphical parameters based on the verification results to generate the specific graphical display components. The rendering engine supports a dynamic response mechanism and features parameter mapping, scaling adaptation, layer overlay, and style switching capabilities. It can construct a complete visualization output in real time based on template definitions and data mapping rules.

[0209] During the presentation process, the system continuously monitors user interaction events on the graphical display components, including mouse clicks, hovers, zooms, layer switching, and axis stretching. These user interaction events include display adjustment commands, which express user requirements for changes to the graphical content display. These commands can include adjusting axis scale accuracy, switching data label display strategies, and reordering dimensions. The system interprets these interaction commands and executes graphical update logic, enabling the display content to respond to user preferences and analytical focus in real time.

[0210] During the interaction process, the system records user interaction behavior data, including behavioral characteristics such as user viewing time, click hotspots, and layer switching paths. This user behavior information is not only used to analyze user focus but also fed back into the generation process of the analysis model selection strategy, used to dynamically adjust the model's structural selection, feature selection weights, or algorithm path structure. At the same time, this behavioral data also drives the optimization of the subtask decomposition strategy. Based on the fields or indicators that the user focuses on during the presentation phase, the system identifies whether the current task is too coarse-grained or the decomposition direction does not match, and automatically adjusts the subsequent task generation logic accordingly.

[0211] In one specific embodiment, the above process can be implemented by collaborating with an event-driven graphics engine and a display logic module. The template matching module can make rule judgments based on the data field structure and label type. For example, it can automatically match the time series line chart template for data containing time fields, and match the stacked bar chart template for aggregated results containing classification fields. The visualization rendering engine uses a graphics engine framework (such as ECharts, D3.js, or a WebGL encapsulation framework) to load the graphics template and receive data-driven updates, supporting dynamic registration of coordinate axes, automatic layout of legends, and style responses. The embedded listener module in the display component can capture user operation actions through the DOM event binding mechanism and trigger visualization change instructions. User interaction events and click behaviors are captured by the front-end event stream and uploaded to the back-end behavior analysis module, which standardizes and encodes user behavior data and integrates it with the analysis model strategy engine. The analysis model strategy engine adjusts the model configuration parameters of the current task based on the current user behavior characteristics, such as increasing the feature weight of high-frequency click fields, adjusting the penalty coefficient in the model selection strategy, or the model integration structure. The subtask decomposition module adjusts the decomposition granularity strategy based on user behavior feedback (such as splitting the original task into finer indicator units or merging low-attention subtasks) and updates the decomposition rule library.

[0212] Example: A financial institution built an enterprise-level risk control system to perform periodic credit risk analysis and intelligent early warning for small and medium-sized enterprise (SME) clients. When an enterprise submits a credit application or a request for a periodic credit review, this business requirement is pushed to the event bus via the enterprise credit platform as an event. Upon detecting this request event, the event bus interprets the business type as "Enterprise Credit Assessment," assigns a "High" priority, and pushes the request event to the task parsing queue. Due to the current high queue load, the system triggers horizontal scaling, dynamically deploying a new parsing instance. After the queue is scheduled, the event is passed to the scheduling module, starting the formal analysis process. The system receives this business requirement event and extracts the required text for the enterprise credit assessment, such as "Analyze the tax compliance, order fulfillment capabilities, and credit default rates of manufacturing enterprises in the Shenzhen region over the past 18 months." The model context protocol parses the text, identifies the task subject as "Manufacturing enterprises in the Shenzhen region" and the time range as "the past 18 months." Based on syntactic complexity and term density, the task is broken down into multiple subtasks, including tax data analysis, contract performance analysis, and default rate prediction. The system accesses contextual information from data sources related to the task through the model context protocol interface. It identifies the enterprise's tax database, procurement compliance database, and credit default database. Based on the relationships modeled in the knowledge graph, it infers data extraction paths and matches key metrics (such as default rates) to analytical models such as logistic regression and XGBoost. After evaluating the suitability of each model, the system determines the use of XGBoost for modeling. Using data source access policies, combined with access keys and API gateway configuration, the system connects to the tax and compliance databases and extracts target data based on time ranges. The raw data undergoes cleansing, feature encoding, and dimension compression. The system then uses a hybrid partitioning strategy based on data type (static tables for tax and time series for compliance) to generate training and validation data. The system uses the training data to train the XGBoost model and the validation data to generate inference results, outputting the target enterprise's credit score for the next quarter. The result validation module compares the inference results with past industry default averages and historical trends. It finds that the score deviation is within the normal range and generates a valid validation mark. The system then uses radar charts and multi-line chart visualization templates to present the enterprise score trend charts to financial analysts. Analysts fine-tune the time axis and add anomaly markup through interface operations. The system records their interactive behavior (viewing duration and hotspot clicks) and updates their feedback information to the model selection strategy for reference in future model evaluation.

[0213] In the healthcare sector, a tertiary hospital launched an intelligent inpatient management analysis system to analyze the risk levels of newly admitted patients in real time, assisting with nursing resource allocation and bed management. When a nurse station accesses the HIS and enters new patient information, an inpatient assessment request event is triggered, which is sent to the data analysis platform via the event bus. The system captures this event, identifies it as "admission risk assessment," sets its priority to "medium," and automatically assigns it to the lowest-loaded parsing instance. If the queue backlog grows, it elastically scales container instances to ensure timeliness. The system extracts assessment text, such as "Identify the likelihood of acute complications in inpatients with cardiovascular disease within the next 72 hours," identifies the task subject as "inpatients with cardiovascular disease" and the timeframe as "next 72 hours." Based on the density of clinical terminology, the system then decomposes the task into subtasks, including vital sign monitoring and assessment, historical medical history analysis, and acute event risk prediction. The system extracts key metrics (such as complication rate) from the model context protocol and generates data extraction paths from the patient's vital sign database, historical diagnosis and treatment database, and medication usage record database. Based on the current task's dependencies, a mapping graph between database tables is generated. Using knowledge graph reasoning, the system prioritizes data paths for extracting specific fields from the heart rate monitoring system and previous hospitalization records. Using evaluation rules in the model context protocol, the system matches risk assessment tasks with various models (such as logistic regression and LSTM neural networks), ultimately selecting an LSTM model for processing time-series vital sign data. The system connects to various databases based on interface credentials and IP whitelisting policies, extracting raw data within a 72-hour time window. The system utilizes data cleansing strategies to address invalid values, null values, and device anomalies. Feature engineering strategies are used to align and normalize data with varying frequencies, and training and validation data are generated using a sliding window mechanism. After model training, inference operations are performed on the validation data to generate hourly updated risk scores. The validation module utilizes historical patient scoring data and national health industry standard scoring models to analyze the deviation of inference results and generate a risk prediction accuracy indicator. If a metric deviates significantly from the baseline, the system marks the score as abnormal and provides it for physician review. The system uses graphical templates (such as time-risk heat maps and interactive trend line charts) to display scoring trends. Doctors can adjust the score display range, add event annotations, and perform other operations through the interface. The system records their interactive behaviors and uses them as input for the next round of model optimization.

[0214] This embodiment combines verification results, user interaction, and the presentation process to achieve a closed loop between result visualization and dynamic feedback on task rules. This overcomes the disconnect between visualization results and model strategies and task planning in traditional data analysis processes, improving the system's adaptability and responsiveness to user feedback. By guiding the model's optimization path and task structure evolution through user behavior, the data analysis system's flexibility and intelligence are enhanced in multi-scenario, multi-objective environments.

[0215] In one embodiment, before step S10, the method further includes:

[0216] S1001, monitoring request events of the business system interface through the event bus;

[0217] S1002, parsing the event payload of the request event, and extracting the service type and priority tag in the event payload;

[0218] S1003: Push the request event to a task resolution queue according to the priority tag;

[0219] S1004, monitoring the current load status of the task resolution queue, and when it is monitored that the current load of the task resolution queue exceeds a preset load threshold, triggering a horizontal expansion operation to add a new task resolution instance to the task resolution cluster;

[0220] S1005, register the newly added task resolution instance to the event bus, and update the load distribution strategy of the task resolution queue. The task resolution queue is used to buffer the request events from the event bus and submit the request events that meet the distribution conditions to the task scheduling module to execute the business demand event processing operation.

[0221] In this embodiment, before entering the business demand event processing flow, an efficient and scalable event access and distribution mechanism can be established to ensure that the system can stably capture, parse, and orderly transmit events when facing high-concurrency business requests. Request events generated by business system interfaces are monitored through an event bus. The event bus uses an asynchronous messaging mechanism that complies with established communication protocols, such as the HTTP / WebSocket protocol combination, MQTT, or an event-driven model based on a service grid, to ensure unified event management across systems and multi-language environments.

[0222] After capturing a request event, the system automatically parses the event payload. The event payload refers to the structured request data carried by the business system during event transmission, typically encoded in JSON, XML, or Protocol Buffers. The parsing operation extracts two core pieces of information from the event payload: a business type tag, which identifies the processing domain to which the event belongs (e.g., risk control, customer service, product recommendations), and a priority tag, which identifies the urgency or policy weight of the event response (e.g., emergency, normal, low-frequency processing).

[0223] After extraction, events are routed to the task resolution queue based on their priority tags. The task resolution queue serves as a buffer for scheduling system event flows, caching and managing business requests awaiting scheduling. The queue management logic supports dynamic load-aware policies. The system prioritizes high-priority requests to less-loaded queue instances in real time based on each queue instance's current processing capacity and historical load, thereby optimizing resource utilization and reducing response latency.

[0224] As events accumulate during peak business periods, the system continuously monitors the real-time load status of the task resolution queue. If the request enqueue rate, queue length, or processing delay at a given moment exceeds a preset load threshold, a horizontal expansion operation is automatically triggered. This involves launching new resolution instances in the task resolution cluster through a container orchestration system (such as Kubernetes or Docker Swarm) or proprietary resource management components. These newly added instances are capable of independently processing request events, enhancing system resiliency.

[0225] After the instance is created, the system registers it with the event bus, enabling it to listen for and process new request events. Simultaneously, the load distribution strategy of the task resolution queue is updated to distribute new events to the most appropriate queue instance according to the updated load-aware model, maintaining overall queue load balancing. Finally, completed request events in the task resolution queue are passed to the task scheduling module, which serves as the starting point for initiating the business demand event processing process. This ensures that data analysis tasks are sequential, efficient, and scalable from the very beginning.

[0226] The event bus can be designed as an event proxy service that supports multi-protocol communication. This service allows business systems to submit events to the system via REST APIs or asynchronous push. The event listener module uses persistent connections or polling mechanisms to capture events in real time, and the parser module performs structured parsing of the event payload. Priority labels can be defined as preset numeric values, enumerations, or policy mapping tables, such as mapping "high," "medium," and "low" to scheduling priority values ​​of 1, 2, and 3, or dynamically calculating priorities based on the business rules of the event source system. The load status monitoring module uses system metric collection frameworks (such as Prometheus and Zabbix) to collect metrics such as queue length, processing time, and CPU utilization. It triggers expansion logic through sliding window statistics and custom threshold policies. Scaling of task parsing instances can be completed by the service orchestration system. After startup, the instance must automatically register with the service discovery module (such as etcd and Consul) and update the routing rules in the service directory maintained by the event bus. The task scheduling module pushes events into the formal processing channel through an event transmission bridge or an asynchronous event chain flow engine (such as Kafka Stream, Flume), entering the subsequent demand analysis and task planning stage.

[0227] This embodiment implements preparatory tasks for task scheduling in the automated data analysis process by introducing event bus-based request monitoring, priority-aware queue distribution, and load-based elastic expansion mechanisms before business demand events are received. This mechanism effectively alleviates queue congestion caused by sudden business traffic, ensures rapid response to high-priority events, and improves the system's resource utilization and elastic scalability, laying a stable operational foundation for subsequent task analysis and model reasoning.

[0228] In one embodiment, a data processing device based on a context protocol is provided, and the data processing device based on a context protocol corresponds one-to-one to the data processing method based on a context protocol in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of a context-based protocol data processing device according to the present invention. It includes a demand receiving module 10, a task parsing module 20, a path planning module 30, a data acquisition module 40, a data preprocessing module 50, a model training module 60, an inference execution module 70, and a result verification module 80. Each functional module is described in detail below:

[0229] The demand receiving module 10 is used to receive a business demand event and extract a demand text from the business demand event;

[0230] A task parsing module 20 is configured to extract the task subject and time range from the requirement text through a model context protocol, and decompose the requirement text into multiple subtasks based on the complexity of the requirement text;

[0231] A path planning module 30 is used to obtain data source context information through the model context protocol interface based on the subtasks and task body, and generate a data extraction path and analysis model selection strategy for each subtask in combination with the knowledge graph reasoning module;

[0232] The data collection module 40 is configured to connect to a target data source according to the data extraction path corresponding to each subtask and the data source access policy defined by the model context protocol, combined with the access rights in the data source context information, and collect raw data from the target data source according to the time range;

[0233] A data preprocessing module 50 is used to preprocess the raw data and split the preprocessed data into training data and validation data according to the partitioning strategy defined by the model context protocol;

[0234] A model training module 60 is configured to determine a target analysis model according to an analysis model selection strategy corresponding to each subtask, and train the target analysis model using the training data;

[0235] An inference execution module 70 is configured to execute inference based on the verification data using the trained target analysis model to generate a subtask inference result;

[0236] The result verification module 80 is used to call the result verification model to verify the subtask reasoning result and generate a verification result.

[0237] In one embodiment, the task parsing module 20 is specifically configured to:

[0238] Calling the semantic structure parsing interface in the model context protocol to perform part-of-speech tagging and dependency syntax analysis on the demand text to generate a lexical dependency graph;

[0239] identifying entity phrases representing analysis targets in the requirement text based on the lexical dependency graph, and marking the entity phrases as task subjects;

[0240] Extracting the time range description in the requirement text based on the time expression recognition strategy defined in the model context protocol, and converting the time range description into a standardized time field;

[0241] According to the semantic structure complexity evaluation parameters defined in the model context protocol, the requirement text is subjected to syntactic depth analysis, semantic target quantity statistics, and domain term density evaluation to generate a complexity level;

[0242] Based on the complexity level and in accordance with the subtask decomposition strategy in the model context protocol, the requirement text is decomposed into a plurality of subtasks, and a subtask identifier is generated for each subtask.

[0243] In one embodiment, the path planning module 30 is specifically configured to:

[0244] extracting key indicator information from the requirement text through the model context protocol;

[0245] Based on the analysis goal of the current subtask, access the data source context information associated with the task body through the model context protocol interface;

[0246] According to the dependency constraints of the current subtask, a data source relationship graph is constructed based on the data structure description in the data source context information;

[0247] Calling the knowledge graph reasoning module to parse the data source relationship graph and generate a set of candidate data extraction paths that meet the analysis objectives of the current subtask;

[0248] Analyze the query efficiency score and data quality score of each candidate data extraction path in the candidate data extraction path set through the path evaluation model defined in the model context protocol, adjust the score ranking according to the priority weight of the current subtask, and select the optimal data extraction path;

[0249] Based on the execution scenario of the current subtask and the task subject and key indicator information, the knowledge graph reasoning module is used to match the set of candidate analysis models predefined in the model context protocol;

[0250] Calling the model performance evaluation interface in the model context protocol to predict the execution efficiency and accuracy of each analysis model in the candidate analysis model set based on the update frequency and data level in the data source context information, and generating a model fitness score;

[0251] Selecting a target analysis model from the set of candidate analysis models according to the model fitness score, and generating a corresponding model parameter initialization strategy;

[0252] The optimal data extraction path and the target analysis model parameter initialization strategy are used as the data extraction path and analysis model selection strategy for the current subtask.

[0253] In one embodiment, the data preprocessing module 50 is specifically configured to:

[0254] Calling a data cleaning strategy predefined in the model context protocol to perform data cleaning processing on the raw data to generate a standardized data set;

[0255] Based on the feature engineering strategy defined in the model context protocol, perform feature encoding and dimension compression operations on the standardized dataset to generate a featurized dataset;

[0256] Performing a data partitioning operation on the characterized data set using partitioning strategy parameters defined in the model context protocol, wherein the partitioning strategy parameters include a time window length, a random sampling ratio, and / or a stratified sampling strategy;

[0257] When the characterized data set includes a time series attribute, dividing the data in the characterized data set into training time window data and validation time window data according to the time window length;

[0258] When the characterization data set is static structured data, dividing the data in the characterization data set into a training data subset and a validation data subset according to the random sampling ratio or stratified sampling strategy;

[0259] The training time window data or the training data subset is marked as training data, and the verification time window data or the verification data subset is marked as verification data.

[0260] In one embodiment, the result verification module 80 is specifically configured to:

[0261] Calling the historical data trend module to obtain historical time period data corresponding to the subtask reasoning result;

[0262] Calling an industry benchmark module to obtain industry standard reference values ​​related to the subtask reasoning result;

[0263] Analyzing the deviation between the subtask reasoning result and the historical time period data and the industry standard reference value through the result verification model;

[0264] Initialize the verification status mark of the subtask reasoning result;

[0265] When the deviation exceeds a preset threshold, the value of the verification status mark is set to abnormal, and the verification status mark is associated with the subtask identifier corresponding to the subtask reasoning result and the abnormal data sample;

[0266] When the deviation does not exceed the preset threshold, the value of the verification status mark is set to valid, and the verification status mark is associated with the subtask identifier and the complete data sample corresponding to the subtask reasoning result;

[0267] The deviation degree, verification status mark, subtask identifier and data sample are output as verification results.

[0268] In one embodiment, the result verification module 80 is specifically configured to:

[0269] Matching a preset visualization template library according to the data type of the verification result;

[0270] Invoking a visualization rendering engine to generate a graphical display component corresponding to the visualization template library;

[0271] receiving a user interaction event and parsing a display adjustment instruction in the user interaction event;

[0272] updating the coordinate axis scale and data label display position of the graphical display component according to the display adjustment instruction;

[0273] Record the user viewing time and click hotspot information in the user interaction event, pass the user viewing time and click hotspot information to the generation process of the analysis model selection strategy, and update the current subtask disassembly strategy based on the user viewing time and click hotspot information.

[0274] In one embodiment, the demand receiving module 10 is specifically configured to:

[0275] Monitor request events of the business system interface through the event bus;

[0276] Parsing the event payload of the request event and extracting the service type and priority tag in the event payload;

[0277] Pushing the request event to the task resolution queue according to the priority tag;

[0278] Monitoring the current load status of the task resolution queue, and when it is monitored that the current load of the task resolution queue exceeds a preset load threshold, triggering a horizontal expansion operation to add a new task resolution instance to the task resolution cluster;

[0279] Register the newly added task resolution instance to the event bus and update the load distribution strategy of the task resolution queue. The task resolution queue is used to buffer request events from the event bus and submit request events that meet the distribution conditions to the task scheduling module to execute business demand event processing operations.

[0280] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it implements the functions or steps of the service side of a data processing method based on a context protocol.

[0281] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of a data processing method based on a context protocol.

[0282] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0283] Receiving a business demand event, and extracting a demand text from the business demand event;

[0284] Extracting the task subject and time range from the requirement text through the model context protocol, and breaking the requirement text into multiple subtasks based on the complexity of the requirement text;

[0285] Based on the subtasks and task body, data source context information is obtained through the model context protocol interface, and the knowledge graph reasoning module is combined to generate a data extraction path and analysis model selection strategy for each subtask;

[0286] Connecting to a target data source based on the data extraction path corresponding to each subtask and the data source access policy defined by the model context protocol, combined with the access permissions in the data source context information, and collecting raw data from the target data source based on the time range;

[0287] Preprocessing the raw data, and splitting the preprocessed data into training data and validation data according to the partitioning strategy defined by the model context protocol;

[0288] Determine a target analysis model according to the analysis model selection strategy corresponding to each subtask, and train the target analysis model using the training data;

[0289] Performing reasoning based on the verification data using the trained target analysis model to generate subtask reasoning results;

[0290] The result verification model is called to verify the subtask reasoning result and generate a verification result.

[0291] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0292] Receiving a business demand event, and extracting a demand text from the business demand event;

[0293] Extracting the task subject and time range from the requirement text through the model context protocol, and breaking the requirement text into multiple subtasks based on the complexity of the requirement text;

[0294] Based on the subtasks and task body, data source context information is obtained through the model context protocol interface, and the knowledge graph reasoning module is combined to generate a data extraction path and analysis model selection strategy for each subtask;

[0295] Connecting to a target data source based on the data extraction path corresponding to each subtask and the data source access policy defined by the model context protocol, combined with the access permissions in the data source context information, and collecting raw data from the target data source based on the time range;

[0296] Preprocessing the raw data, and splitting the preprocessed data into training data and validation data according to the partitioning strategy defined by the model context protocol;

[0297] Determine a target analysis model according to the analysis model selection strategy corresponding to each subtask, and train the target analysis model using the training data;

[0298] Performing reasoning based on the verification data using the trained target analysis model to generate subtask reasoning results;

[0299] The result verification model is called to verify the subtask reasoning result and generate a verification result.

[0300] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0301] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0302] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0303] It should be noted that if any software tools or components other than those of the Company appear in the embodiments of this application, they are merely for illustration and do not represent actual use. The above embodiments are intended only to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some of the technical features therein with equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A data processing method based on context protocol, characterized in that: The following steps are involved: Receiving a business demand event, and extracting a demand text from the business demand event; Extracting the task subject and time range from the requirement text through the model context protocol, and breaking the requirement text into multiple subtasks based on the complexity of the requirement text; Based on the subtasks and task body, data source context information is obtained through the model context protocol interface, and the knowledge graph reasoning module is combined to generate a data extraction path and analysis model selection strategy for each subtask; Connecting to a target data source based on the data extraction path corresponding to each subtask and the data source access policy defined by the model context protocol, combined with the access permissions in the data source context information, and collecting raw data from the target data source based on the time range; Preprocessing the raw data, and splitting the preprocessed data into training data and validation data according to the partitioning strategy defined by the model context protocol; Determine a target analysis model according to the analysis model selection strategy corresponding to each subtask, and train the target analysis model using the training data; Performing reasoning based on the verification data using the trained target analysis model to generate subtask reasoning results; The result verification model is called to verify the subtask reasoning result and generate a verification result.

2. The data processing method based on context protocol according to claim 1, characterized in that: The task body and time range are extracted from the requirement text through the model context protocol, and the requirement text is broken down into multiple subtasks based on the complexity of the requirement text, including: Calling the semantic structure parsing interface in the model context protocol to perform part-of-speech tagging and dependency syntax analysis on the demand text to generate a lexical dependency graph; identifying entity phrases representing analysis targets in the requirement text based on the lexical dependency graph, and marking the entity phrases as task subjects; Extracting the time range description in the requirement text based on the time expression recognition strategy defined in the model context protocol, and converting the time range description into a standardized time field; According to the semantic structure complexity evaluation parameters defined in the model context protocol, the requirement text is subjected to syntactic depth analysis, semantic target quantity statistics, and domain term density evaluation to generate a complexity level; Based on the complexity level and in accordance with the subtask decomposition strategy in the model context protocol, the requirement text is decomposed into a plurality of subtasks, and a subtask identifier is generated for each subtask.

3. The data processing method based on context protocol according to claim 1, characterized in that: Based on the subtasks and task body, data source context information is obtained through the model context protocol interface, and combined with the knowledge graph reasoning module to generate a data extraction path and analysis model selection strategy for each subtask, including: extracting key indicator information from the requirement text through the model context protocol; Based on the analysis goal of the current subtask, access the data source context information associated with the task body through the model context protocol interface; According to the dependency constraints of the current subtask, a data source relationship graph is constructed based on the data structure description in the data source context information; Calling the knowledge graph reasoning module to parse the data source relationship graph and generate a set of candidate data extraction paths that meet the analysis objectives of the current subtask; Analyze the query efficiency score and data quality score of each candidate data extraction path in the candidate data extraction path set through the path evaluation model defined in the model context protocol, adjust the score ranking according to the priority weight of the current subtask, and select the optimal data extraction path; Based on the execution scenario of the current subtask and the task subject and key indicator information, the knowledge graph reasoning module is used to match the set of candidate analysis models predefined in the model context protocol; Calling the model performance evaluation interface in the model context protocol to predict the execution efficiency and accuracy of each analysis model in the candidate analysis model set based on the update frequency and data level in the data source context information, and generating a model fitness score; Selecting a target analysis model from the set of candidate analysis models according to the model fitness score, and generating a corresponding model parameter initialization strategy; The optimal data extraction path and the target analysis model parameter initialization strategy are used as the data extraction path and analysis model selection strategy for the current subtask.

4. The data processing method based on context protocol according to claim 1, characterized in that: Preprocessing the raw data and splitting the preprocessed data into training data and validation data according to the partitioning strategy defined by the model context protocol, including: Calling a data cleaning strategy predefined in the model context protocol to perform data cleaning processing on the raw data to generate a standardized data set; Based on the feature engineering strategy defined in the model context protocol, perform feature encoding and dimension compression operations on the standardized dataset to generate a featurized dataset; Performing a data partitioning operation on the characterized data set using partitioning strategy parameters defined in the model context protocol, wherein the partitioning strategy parameters include a time window length, a random sampling ratio, and / or a stratified sampling strategy; When the characterized data set includes a time series attribute, dividing the data in the characterized data set into training time window data and validation time window data according to the time window length; When the characterization data set is static structured data, dividing the data in the characterization data set into a training data subset and a validation data subset according to the random sampling ratio or stratified sampling strategy; The training time window data or the training data subset is marked as training data, and the verification time window data or the verification data subset is marked as verification data.

5. The data processing method based on context protocol according to claim 1, characterized in that: The result verification model is called to verify the subtask reasoning results and generate verification results, including: Calling the historical data trend module to obtain historical time period data corresponding to the subtask reasoning result; Calling an industry benchmark module to obtain industry standard reference values ​​related to the subtask reasoning result; Analyzing the deviation between the subtask reasoning result and the historical time period data and the industry standard reference value through the result verification model; Initialize the verification status mark of the subtask reasoning result; When the deviation exceeds a preset threshold, the value of the verification status mark is set to abnormal, and the verification status mark is associated with the subtask identifier corresponding to the subtask reasoning result and the abnormal data sample; When the deviation does not exceed the preset threshold, the value of the verification status mark is set to valid, and the verification status mark is associated with the subtask identifier and the complete data sample corresponding to the subtask reasoning result; The deviation degree, verification status mark, subtask identifier and data sample are output as verification results.

6. The data processing method based on context protocol according to claim 1, characterized in that: The result verification model is called to verify the subtask reasoning result. After the verification result is generated, the following steps are also included: Matching a preset visualization template library according to the data type of the verification result; Invoking a visualization rendering engine to generate a graphical display component corresponding to the visualization template library; receiving a user interaction event and parsing a display adjustment instruction in the user interaction event; updating the coordinate axis scale and data label display position of the graphical display component according to the display adjustment instruction; Record the user viewing time and click hotspot information in the user interaction event, pass the user viewing time and click hotspot information to the generation process of the analysis model selection strategy, and update the current subtask disassembly strategy based on the user viewing time and click hotspot information.

7. The data processing method based on context protocol according to claim 1, characterized in that: The method further includes receiving a business requirement event and extracting the requirement text from the business requirement event: Monitor request events of the business system interface through the event bus; Parsing the event payload of the request event and extracting the service type and priority tag in the event payload; Pushing the request event to the task resolution queue according to the priority tag; Monitoring the current load status of the task resolution queue, and when it is monitored that the current load of the task resolution queue exceeds a preset load threshold, triggering a horizontal expansion operation to add a new task resolution instance to the task resolution cluster; Register the newly added task resolution instance to the event bus and update the load distribution strategy of the task resolution queue. The task resolution queue is used to buffer request events from the event bus and submit request events that meet the distribution conditions to the task scheduling module to execute business demand event processing operations.

8. A data processing device based on a context protocol, characterized in that: The data processing device based on the context protocol includes: A demand receiving module is used to receive a business demand event and extract the demand text from the business demand event; A task parsing module, configured to extract the task subject and time range from the requirement text through a model context protocol, and decompose the requirement text into multiple subtasks based on the complexity of the requirement text; A path planning module is used to obtain data source context information through the model context protocol interface based on the subtasks and task body, and to generate a data extraction path and analysis model selection strategy for each subtask in combination with the knowledge graph reasoning module; A data collection module is used to connect to a target data source based on the data extraction path corresponding to each subtask and the data source access policy defined by the model context protocol, combined with the access permissions in the data source context information, and collect raw data from the target data source according to the time range; A data preprocessing module, configured to preprocess the raw data and split the preprocessed data into training data and validation data according to a partitioning strategy defined by the model context protocol; A model training module is used to determine a target analysis model according to the analysis model selection strategy corresponding to each subtask, and train the target analysis model using the training data; An inference execution module, configured to perform inference based on the verification data using the trained target analysis model to generate subtask inference results; The result verification module is used to call the result verification model to verify the subtask reasoning result and generate a verification result.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a context protocol-based data processing program stored in the memory and capable of running on the processor. When the context protocol-based data processing program is executed by the processor, the steps of the context protocol-based data processing method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The storage medium stores a data processing program based on a context protocol, and when the data processing program based on the context protocol is executed by the processor, the steps of the data processing method based on the context protocol according to any one of claims 1 to 7 are implemented.

Images